On delimiting video rebuffering for stream
Transkrypt
On delimiting video rebuffering for stream
Jordi Mongay Batalla Piotr Krawiec Instytut Telekomunikacji, Politechnika Warszawska ul. Nowowiejska 15/19, 00-665 Warszawa {jordim, pkrawiec}@tele.pw.edu.pl Łukasz Łopatowski Poznańskie Centrum Superkomputerowo-Sieciowe ul. Noskowskiego 10, 61-704 Poznań [email protected] REALIZACJA ZARZĄDZANYCH I NIEZARZĄDZANYCH USŁUG DOSTARCZANIA TREŚCI W SIECIACH ŚWIADOMYCH TREŚCI Streszczenie: Artykuł prezentuje zaawansowane funkcjonalności systemu zarządzania usługami dla Sieci Świadomych Treści, umożliwiające realizację zarządzanych i niezarządzanych usług dostarczania multimediów. Proponowany system korzysta z posiadanej wiedzy o użytkowniku, treści oraz sieci, i aktywnie współpracuje z eksploatowaną infrastrukturą Sieci Świadomych Treści. Współpraca ta pozwala na wprowadzenie nowych mechanizmów umożliwiających dynamiczne przełączanie serwera treści i ścieżki przekazu w przypadku wystąpienia zakłóceń transferu. Nadrzędnym celem proponowanych rozwiązań jest poprawa funkcjonalności systemu dla pełnego cyklu życia usługi, ze szczególnym uwzględnieniem procesu dostarczania treści multimedialnych, maksymalizujących zadowolenie użytkownika z odbioru usługi. 1. WSTĘP Jednym z głównych trendów w obszarze badań nad Internetem Przyszłości (ang. Future Internet) jest ukierunkowanie na przekaz informacji, a w szczególności ukierunkowanie na przekaz treści multimedialnych [1]. Zaproponowane zostały nowe koncepcje i architektury, takie jak Information-Centric Networking (ICN) czy też Content-Oriented/-Centric/-Aware Networking (oznaczone odpowiednio: CON/CCN/CAN) [2]-[9]. Jednakże dotychczasowe badania dotyczące koncepcji CON/CCN wskazują potencjalne problemy związane z ich wdrożeniem do rzeczywistych sieci, takie jak konieczność zmiany podstawowych procesów w sieci, czy też problemy ze skalowalnością wynikające ze złożoności funkcji wykonywanych przez węzły sieciowe (operacje przekazu treści z zachowaniem stanu, przechowywanie replik treści, obsługa olbrzymiego zbioru nazw treści, sposób sterowania połączeniami zbliżony do występującego w sieciach z protokołem RSVP itp.). Podejściem pośrednim jest koncepcja sieci świadomej przekazywanej treści CAN (ang. Content Aware Network) przyjęta w [2] i [4], która ogranicza stopień „świadomości” sieci jedynie do typu treści, likwidując tym samym problemy ze skalowalnością charakteryzujące podejście CON/CCN. Architektura CAN jest w głównej mierze dedykowana do dostarczania usług multimedialnych i jej podstawowym celem jest zdefiniowanie zorientowanej na przekaz treści, dynamicznej i elastycznej platformy zarządzania i sterowania, umożliwiającej wielu podmiotom biznesowym (tj. dostawcom usług, dostawcom treści, operatorom sieci, użytkownikom końcowym) współdziałanie w celu efektywnej realizacji usług multimedialnych w środowisku rozległych, wielodomenowych sieci IP. Niniejszy artykuł prezentuje system zarządzania usługami SM (ang. Service Management), jaki został zdefiniowany dla ww. architektury CAN w projektach ALICANTE [2],[3] i DISEDAN [4], oraz zaimplementowany w prototypach stworzonych w ramach tych projektów. W szczególności, przedstawione zostaną aspekty techniczne dotyczące sposobu realizacji w systemie SM zarządzanych i niezarządzanych usług dostarczania treści multimedialnych. System SM jest wykorzystywany przez dostawcę usług do zarządzania cyklem życia usługi multimedialnej, obejmującym etapy kreacji, planowania, publikacji, dostarczania i usuwania usługi, z których to faza dostarczania jest kluczowa dla uzyskania najwyższego poziomu postrzeganej przez użytkownika jakości odbioru treści multimedialnej QoE (ang. Quality of Experience). Z fazą dostarczania związana jest koncepcja usług zarządzanych i niezarządzanych, które odnoszą się do możliwości transferu poprzez sieć treści multimedialnej z wykorzystaniem kontrolowanych (rezerwowanych) zasobów (usługa zarządzana), bądź też przekazu danych zgodnie z modelem typu best-effort, kiedy zasoby sieciowe nie są w żaden sposób kontrolowane przez dostawcę usług (usługa niezarządzana). Struktura artykułu jest następująca. W rozdziale drugim przedstawiono koncepcję zarządzanych i niezarządzanych usług w sieci CAN. Rozdziały 3 i 4 prezentują szczegółowo proponowane sposoby realizacji usług zarządzanych i niezarządzanych, zaś rozdział 5 stanowi podsumowanie artykułu. 2. USŁUGI ZARZĄDZANE I NIEZARZĄDZANE W SIECIACH CAN Cechą płaszczyzny zarządzania i sterowania M&C (ang. Management and Control) sieci świadomych przekazywanej treści CAN jest udostępnienie informacji o użytkowniku, treści oraz sieci różnorodnym podmiotom współdziałającym ze sobą tak, żeby każdy z nich mógł uzyskać dodatkowe profity z realizowanego wspólnie procesu dostarczania treści. Rysunek 1 ilustruje interakcje pomiędzy poszczególnymi podmiotami skutkujące „świadomością” kontekstu użytkownika (ang. User Context Awareness), treści (ang. Content Awareness) oraz sieci (ang. Network Awareness). Na przykład: aplikacja użytkownika końcowego świadoma sieci (tj. mająca dostęp do informacji o stanie sieci) może optymalizować swoje decyzje związane z adaptacją treści (np. obniżeniem rozdzielczości przesyłanego materiału wideo w celu zachowania płynności); z kolei dostawca usług może wykorzystać informacje o profilu oraz kontekście użytkownika (jaki terminal? jaka sieć dostępowa?) dla zwiększenia efektywności procesu dostarczania treści i jego szybszej adaptacji do wymagań użytkownika. Ponadto, informacje o użytkowniku mają fundamentalne znaczenie dla procesu przygotowania treści do transmisji (np. dołączenie treści reklamowych). User Context Awareness Service Providers Service Providers Content Providers Content Providers Content Awareness CAN 1 Network Awareness CAN 2 CAN 3 Rys. 1. Interakcje pomiędzy środowiskiem użytkownika, usług i sieci. Z kolei sieć pozyskuje informacje o rodzaju przesyłanej treści, dzięki czemu może zaoferować usługę zestawiania na żądanie połączenia koniec-koniec z różnym poziomem jakości obsługi QoS (ang. Quality of Service), uzyskując zarazem możliwość optymalnej alokacji zasobów sieciowych. Świadomość sieci po stronie dostawcy usług rozumiemy jako możliwość przekazania przez dostawcę usług zgłoszenia do operatora sieci CAN dotyczącego zestawienia wirtualnych sieci CAN (ang. Virtual CAN – VCAN). Sieć VCAN realizowana jest w oparciu o jedną lub wiele domen IP, zaś oferowane przez nią parametry jakości transmisji mogą być dostosowane do wymagań konkretnych usług (IPTV, VoD itp.), dla których dany VCAN jest zestawiany. Operator sieci CAN może stosować różnorodne mechanizmy różnicujące parametry przekazu pakietów na poziomie sieciowym, zapewniając w ten sposób gwarancje QoS dla danej sieci VCAN. Dedykowana wirtualna sieć VCAN umożliwia realizację usługi zarządzanej przez proponowany system SM. Jak już wspomniano, koncepcja takiej usługi odnosi się do dostarczenia treści multimedialnej w sposób kontrolowany, z punktu widzenia parametrów jakości przekazu QoS, z wykorzystaniem dedykowanych zasobów sieciowych [10]. Realizacja usługi zarządzanej wymaga spełnienia dwóch założeń: 1) świadomość treści i alokacja zasobów na poziomie sieci, oraz 2) świadomość sieci na poziomie aplikacji. Dzięki nim powstaje pętla sprzężenia zwrotnego pomiędzy warstwą sieci, warstwą aplikacji i warstwą usługową, umożliwiająca przeprowadzenie skutecznych procesów optymalizacyjnych. W związku z tym, przedstawiony w następnym rozdziale sposób realizacji usług zarządzanych zakłada, dla scenariusza wielodomenowego, współdziałanie operatorów siecio- wych mające na celu dostarczenie wspólnej warstwy pośredniczącej (VCAN) skupiającej w sobie świadomość sieci oraz świadomość treści. Warstwa ta odpowiedzialna jest za dostarczenie informacji wynikających ze świadomości sieci do systemu zarządzania usługami SM, jak również przekazanie informacji wynikających ze świadomości treści do systemu zarządzania siecią NM (ang. Network Manager). Usługi niezarządzane wymagają dynamicznych reakcji systemu zarządzania usługami SM na występujące zakłócenia poprawnego działania sieci i/lub źródeł treści (tj. serwerów strumieniujących multimedia). Zakłócenia te wynikają z braku gwarancji rezerwacji zasobów infrastruktury realizującej przekaz treści dla tego typu usług. Proponowany system SM wprowadza możliwość zmiany serwera treści oraz ścieżki wykorzystywanej do transmisji treści multimedialnej w sytuacji, kiedy pogorszeniu ulegają warunki panujące w sieci. Jest to realizowane poprzez implementację mechanizmu adaptacji źródła i ścieżki CSPA (ang. Content Source and Path Adaptation). Moduł CSPA systemu SM odpowiedzialny jest za gromadzenie i analizę informacji (w czasie rzeczywistym) o błędach uzyskiwanych od użytkownika (obniżenie wartości QoE), jak również otrzymanych od sieci (obniżenie wartości QoS), następnie zaś podejmowanie odpowiednich decyzji dotyczących adaptacji źródła treści i/lub ścieżki przekazu w celu przywrócenia pożądanych poziomów jakości QoE i QoS. Moduł CSPA został szczegółowo przedstawiony w rozdziale 4, włącznie z wynikami symulacyjnymi algorytmu zaproponowanego do lokalizacji błędów w sieci, dzięki czemu możliwe jest przeprowadzenie prawidłowej adaptacji źródła i ścieżki przekazu. 3. ROZWIĄZANIE DLA USŁUG ZARZĄDZANYCH: VCAN Podejście dla wirtualnej sieci CAN (VCAN) przyjęte w niniejszym artykule zakłada wykorzystanie nowej koncepcji wprowadzającej świadomość treści na poziomie sieci oraz świadomość sieci na poziomie aplikacji, co ma na celu optymalizację procesu transferu danych w ramach zarządzanej usługi dostarczania treści multimedialnych [11]. Proces zestawienia sieci VCAN jest przeprowadzany po uzyskaniu przez dostawcę usług informacji odnośnie potencjalnej liczby i dyslokacji użytkowników usługi, jak również o planowanym rozmieszczeniu, w sposób zagregowany, treści multimedialnych w sieci. Sieć VCAN stanowi infrastrukturę nakładkową (ang. overlay) umożliwiającą realizację połączeń typu koniec-koniec, których parametry dopasowane są do wymagań projektowych opracowanych przez danego dostawcę usług. Pojedynczy VCAN może być zestawiony na infrastrukturze fizycznej obejmującej wiele odrębnych domen, z których każda zarządzana jest przez niezależnego operatora sieciowego NP (ang. Network Provider) i może oferować różnorodne poziomy gwarancji QoS obsługi strumieni multimedialnych. Zarządzanie zasobami VCAN bazuje na wertykalnych i horyzontalnych umowach SLA (ang. Service Level Agreement) negocjowanych i zawieranych, na płaszczyźnie zarządzania i sterowania M&C, pomiędzy dostawcą usług, operatorem sieci CAN i operatorami sieci fizycznych. Na poziomie płaszczyzny danych, informacje dotyczące treści oraz usług są przenoszone w pakietach strumienia multimedialnego generowanego przez serwer treści i odpowiednio obsługiwane przez inteligentne węzły sieciowe warstwy VCAN, tzw. węzły MANE (ang. Media-Aware Network Element). Zatem świadomość treści na poziomie sieci jest realizowana na dwa sposoby: na poziomie płaszczyzny M&C oraz na poziomie płaszczyzny danych. Rysunek 2 przedstawia elementy architektury VCAN konieczne do realizacji usług, z zaznaczonymi interakcjami zachodzącymi pomiędzy modułem zarządzania siecią wirtualną VCAN (VCAN Manager), warstwą sieciową i systemem zarządzania usługami SM. Przyjmujemy, że istnieje jeden VCAN Manager dla każdej z domen sieciowych, co zapewnia jednorodność procesów planowania, wymiarowania, negocjacji, zestawiania i eksploatacji sieci VCAN w każdej z fizycznych domen sieciowych. Ponadto, każda z domen fizycznych posiada tradycyjny moduł zarządzania zasobami IntraNRM (ang. Intra-domain Network Resource Manager), który jako jedyny ma uprawnienia do przeprowadzenia odpowiedniej konfiguracji urządzeń sieciowych danej domeny dla zagwarantowania wymaganych parametrów QoS. CAN RM SLS CSPA 1 Service Provider Environment Service Manager 3 VCAN Manager VCAN Environment VCAN Manager SLS 2 4 Intra-Network Resource Manager Intra-Network Network Resource Manager Interconnection AS1 5 MANE Access Network Content server Agreements AS2 Multi-domain VCAN QoS enabled MANE MANE MANE Access Network Set-Top-Box Home Network End User Terminal Rys. 2. Architektura systemu do realizacji sieci VCAN; 1,2,3,4,5 – interakcje procesów zarządzania i sterowania (RM – Resource Manager, SLS – Service Level Specification, AS – Autonomous System). Moduł VCAN Manager przypisany do danej domeny negocjuje przydział zasobów z modułem IntraNRM tej domeny, jak również z innymi modułami VCAN Manager w sytuacji, kiedy zestawiany VCAN obejmuje więcej niż jedną domenę sieciową. W takim przypadku konieczne jest uprzednie zawarcie porozumienia NIA (ang. Network Interconnection Agreement) pomiędzy operatorami poszczególnych domen, umożliwiającego ich kooperację na poziomie sieciowym dla zapewnienia gwarancji QoS w relacji od końca do końca. Moduł VCAN Manager mapuje sieć VCAN na fizyczne zasoby dostępne u operatorów sieciowych, następnie zaś generuje żądanie zestawienia sieci VCAN i nadzoruje, w kooperacji z operatorami zaangażowanych domen sieciowych, jej działanie. W systemie SM moduł zarządzania zasobami CAN, nazwany CAN RM (ang. CAN Resource Manager), jest odpowiedzialny za wykonywanie wszystkich następujących po sobie procesów niezbędnych dla obsługi VCAN: planowanie sieci VCAN, jej wymiarowanie (przeprowadzane poprzez negocjacje z VCAN Manager) oraz nadzór nad jej działaniem. Na rysunku 2 zaprezentowano wszystkie interakcje płaszczyzny M&C (oznaczone: 1,2,3,4,5), jakie są konieczne dla zestawienia sieci VCAN. Zbiór interakcji (1,2,3) odpowiada za dwuetapowe negocjacje parametrów VCAN prowadzane w oparciu o wcześniejsze negocjacje pomiędzy operatorami sieci (oznaczonymi jako interakcja (4)). Po ich zakończeniu następuje interakcja (5) związana z zestawieniem sieci VCAN. Moduł CAN RM dostawcy usług wysyła do inicjującego modułu VCAN Manager żądanie instalacji sieci VCAN wraz ze specyfikacją wymagań obejmującą: (1) informacje dotyczące topologii i pojemności ścieżek, tj. macierz ścieżek wirtualnych (przepustowość, identyfikator wejściowy, identyfikator wyjściowy), (2) klasy usług sieci VCAN (opóźnienie, zmienność opóźnienia, poziom strat pakietów), oraz (3) przedziały czasowe, w których sieć VCAN powinna być aktywna. Identyfikatory wejściowe (którymi mogą być np. prefiksy IP) identyfikują domeny, w których zlokalizowane są serwery treści, podczas gdy identyfikatory wyjściowe odnoszą się do domen użytkowników. Inicjujący VCAN Manager, biorąc pod uwagę porozumienia SLA zawarte z innymi modułami VCAN Manager oraz z modułem IntraNRM swojej domeny, sprawdza dostępność zasobów w fizycznych domenach sieciowych i zwraca odpowiedź pozytywną lub negatywną. W przypadku odpowiedzi pozytywnej, zwraca on również listę wszystkich zaakceptowanych ścieżek wirtualnych wraz z zaakceptowanymi przedziałami czasowymi ich funkcjonowania, jak również listę etykiet treści/usługi dla każdej ze ścieżek wirtualnych, którymi będą oznaczone pakiety strumieni przesyłanych za pomocą danej sieci VCAN. Dodatkowo, VCAN Manager może przekazać do modułu CAN RM informacje o odległościach (wyrażonych w liczbie przeskoków) pomiędzy poszczególnymi węzłami sieci VCAN, co umożliwi modułowi adaptacji źródła treści podjęcie zoptymalizowanych decyzji dotyczących wyboru źródła treści oraz ewentualnej replikacji kopii treści na serwerach w fazie dostarczania usługi sieciowej. Operację wstawienia odpowiednich etykiet treści/usług do pakietów danych realizuje serwer treści, któremu informację o etykietach przekazuje moduł CAN RM (należący do systemu zarządzania usługami SM). Warto zwrócić uwagę, iż w proponowanym rozwiązaniu świadomość treści na poziomie sieciowym może być uzyskana nie tylko poprzez płaszczyznę M&C, ale również dzięki mechanizmom pełnej analizy pakietów DPI (ang. Deep Packet Inspection) zaimplementowanym w węzłach MANE. Dzięki tym mechanizmom możliwa jest, na poziomie warstwy sieciowej, identyfikacja i odpowiednia obsługa (celem zapewnienia gwarancji QoS) pakietów przenoszących treści multimedialne, które nie są opatrzone stosownymi etykietami. Zwiększa to elastyczność proponowanego rozwiązania, gdyż po- zwala na wykorzystanie standardowych serwerów nieposiadających mechanizmu wstawiania etykiet do generowanych pakietów. Implementacja interfejsu zarządzania i sterowania pomiędzy modułami CAN RM i VCAN Manager została wykonana w oparciu o technologię Web Services z wykorzystaniem protokołu SOAP (ang. Simple Object Access Protocol). Zaprezentowana architektura sieci VCAN jest skalowalna, otwarta oraz umożliwia dalszą ewolucję; jest to zgodne z najnowszymi trendami, silnie wspieranymi przez producentów sprzętu sieciowego, takimi jak Sieci Programowalne SDN (ang. Software Defined Networks) [12], które wprowadzają do sieci wyraźny podział pomiędzy płaszczyzną sterowania a płaszczyzną przekazu danych i zakładają bardziej scentralizowany sposób zarządzani siecią w porównaniu do obecnie stosowanych metod. Podobnie do podejścia proponowanego dla SDN, opracowane przez nas rozwiązanie przenosi proces decyzyjny oraz inteligencję działania z węzłów sieciowych (przełączników/ruterów) do zewnętrznych jednostek, zlokalizowanych na jednej lub wielu maszynach fizycznych (zależnie od decyzji podjętych w procesie wymiarowania sieci). 4. ROZWIĄZANIE DLA USŁUG NIEZARZĄDZANYCH: CSPA Głównym zadaniem modułu adaptacji źródła i ścieżki CSPA, będącego częścią systemu zarządzania usługami SM, jest reakcja na pogorszenie warunków sieciowych i zwiększenie jakości usług oferowanych przez dostawcę usług. Moduł CSPA otrzymuje w czasie rzeczywistym zgłoszenia od użytkowników wskazujące, iż treść multimedialna jest strumieniowana ze złą jakością. W proponowanym rozwiązaniu zaimplementowany został jedynie interfejs pomiędzy dostawcą usług a użytkownikiem, umożliwiający monitorowanie wartości QoE w oparciu o wartości MOS (ang. Mean Opinion Score) wyznaczone na podstawie pomiarów przeprowadzonych na poziomie aplikacji (np. opóźnienie odtwarzania), jednakże nie powinno stanowić problemu opracowanie podobnego interfejsu z operatorem sieci, w celu monitorowania parametrów QoS (opóźnienie, straty pakietów itp.). Przyjmujemy, iż aplikacja użytkownika końcowego posiada funkcjonalność konieczną do monitorowania jakości odbieranego strumienia multimedialnego i generowania odpowiednich alertów przekazywanych do modułu CSPA. Proces decyzyjny zaimplementowany w module CSPA odpowiedzialny jest za uruchomienie właściwych działań adaptacyjnych. Za każdym razem kiedy proces ten jest wywoływany (odstęp pomiędzy kolejnymi wywołaniami określony jest zmienną konfiguracyjną TO), moduł CSPA wykonuje dwie operacje: (1) stara się zidentyfikować i zlokalizować przyczynę zgłaszanych problemów (przeciążenie w sieci? zbyt duże obciążenie serwera?) poprzez uruchomienie algorytmu lokalizacji błędów FLA (ang. Fault Localization Algorithm), który bierze pod uwagę topologię sieci oraz alerty otrzymane podczas ostatniego okresu TO (każdy z alertów zawiera następujące informacje: identyfikator treści aktualnie pobieranej przez użytkownika, adres IP serwera strumieniującego daną treść, adres IP terminala użytkownika); następnie zaś (2) CSPA uruchamia jedną z trzech przedstawionych poniżej akcji adaptacyjnych, uwzględniając odebrane alerty oraz wykonywane uprzednio działania adaptacyjne. Każda z rozważanych akcji adaptacyjnych wiąże się z wysłaniem żądania do innych elementów systemu, wraz z informacjami koniecznymi do przeprowadzenia wywoływanej operacji. Możliwe są następujące akcje adaptacyjne: 1. Moduł CSPA żąda przeprowadzenia operacji replikacji treści, obejmującej stworzenie dodatkowych kopii popularnej treści i umieszczenie ich na wybranych serwerach treści. Akcja ta jest uruchamiana w przypadku, kiedy część z odebranych alertów dotyczy tej samej treści i różnych serwerów treści, i bierze pod uwagę również informacje o dystansie sieciowym (wyrażonym liczbą przeskoków) wcześniej utworzonych kopii danej treści. Dodatkowe kopie treści tworzone są dynamicznie, wywołując w razie konieczności odpowiednią operację transkodowania, i wgrywane na wyselekcjonowane serwery treści. Następnie przeprowadzana jest aktualizacja informacji o dostępnych treściach multimedialnych, dzięki czemu obsługa nadchodzących żądań dostarczenia treści jest realizowana z uwzględnieniem nowych kopii. 2. Dodatkowo moduł CSPA może uruchomić procedurę przełączania połączenia charakteryzującego się słabą jakością, na nowy, wybrany serwer treści i na nową ścieżkę. Następuje to w sytuacji, gdy znaczna część z odebranych alertów odnosi się do tego samego serwera treści. Moduł CSPA wysyła wówczas żądanie do terminala użytkownika w celu wywołania procedury przełączania, przekazując w nim informacje o błędnie działających serwerach treści. W tej sytuacji terminal użytkownika powinien posiadać mechanizm płynnego przełączania, dzięki któremu zmiana serwera treści zostanie przeprowadzona w sposób niezauważalny dla użytkownika. Przykład implementacji takiego mechanizmu, uwzględniający strumieniowanie treści za pomocą protokołów RTP/RTSP oraz HTTP, został zaprezentowany w artykule [13]. 3. Ponadto, moduł CSPA może uaktualnić dane wejściowe do algorytmu selekcji serwerów treści o informacje dotyczące bieżących warunków sieciowych, dzięki czemu nadchodzące żądania strumieniowania treści nie będą obsługiwane przez serwery które zostały zidentyfikowane jako będące w stanie przeciążenia. Akcja ta jest wywoływana na skutek odebrania kilku alertów dotyczących tego samego serwera w sytuacji, gdy podczas ostatniego okresu TO nastąpiła zmiana serwera treści. Przedstawione akcje adaptacyjne mają wpływ na poprawę obciążenia systemu w różnych skalach czasowych. Podsumowując, w przypadku usług niezarządzanych (tj. bez gwarancji QoS oferowanych przez sieć) moduł CSPA ma możliwość: (1) niwelacji skutków pojedynczych zakłóceń (poprzez przełączenie źródła transmisji), (2) występujących lokalnie, bieżących przeciążeń (poprzez adaptację procesu wyboru serwera tre- ści), oraz (3) potencjalnych przeciążeń dużej grupy serwerów (poprzez replikację treści). 4.1. Specyfikacja algorytmu FLA Zaproponowany algorytm FLA, zaimplementowany w module CSPA, wykorzystuje podejście wyznaczania metryki wnioskowania [14] będącym jedną z technik lokalizacji błędów bazujących na wnioskowaniu Bayesowskim. Algorytm FLA odpowiedzialny jest za wskazanie hipotezy dotyczącej błędu w sieci (tj. przeciążenie łącza lub/i serwera treści), najlepiej wyjaśniającej występujące symptomy (tj. otrzymywane alerty o złej jakości połączeń strumieniujących treści multimedialne). Proponowany algorytm FLA został oparty o rozwiązanie zaprezentowane w [15], odpowiednio zmodyfikowane w celu dopasowania do opracowywanego systemu. W implementacji algorytmu wykorzystano tzw. model propagacji błędów, zwany również mapą przyczynowo-skutkową. Reprezentuje on wpływ błędu jednego z elementów systemu (serwera lub łącza) na inny element (w naszym przypadku terminal użytkownika), a zatem przechowuje informacje o związkach przyczynowo-skutkowych pomiędzy zbiorem błędów F a zbiorem symptomów S. W celu stworzenia takiego modelu propagacji błędów, konieczne jest wprowadzenie do FLA informacji dotyczących: (1) topologii sieci (tj. utworzonych sieci VCAN); (2) zbioru wszystkich możliwych błędów F które mogą spowodować symptomy S; zbiór ten obejmują błędy łączy, błędy węzłów sieciowych oraz błędy serwerów; (3) wartości prawdopodobieństwa wystąpienia każdego z błędów serwerów Pr(FS) oraz błędów łączy Pr(FL) (tj. wystąpienia przeciążeń). Informacje o wartościach prawdopodobieństw błędów mogą być uzyskane na podstawie własności infrastruktury fizycznej, na której zestawiony jest dany VCAN (np. dostępne przepustowości łączy, parametry serwerów), oraz informacji o błędach występujących w przeszłości. Selekcja zbioru błędów Fset, będących skutkiem zaobserwowanych symptomów SO, bazuje na wyznaczeniu metryki wnioskowania B(Fset) zgodnie z równaniem (1), które określa prawdopodobieństwo sytuacji, iż wszystkie błędy należące do zbioru Fset wystąpiły, i jednocześnie błędy te stanowią wyjaśnienie wszystkich symptomów zbioru SO, jakie pojawiły się w ostatnim okresie obserwacji TO (a więc od chwili ostatniego uruchomienia algorytmu FLA). Jako wynik, FLA zwraca najbardziej prawdopodobną hipotezę, tj. zbiór błędów Fset dla którego metryka B(Fset) osiąga najwyższą wartość. Zbiór ten zawiera listę błędów wskazujących elementy będące przyczyną nieprawidłowego działania sieci. B( Fset ) Pr(Fi X ) 1 1 Pr(S j | Fi X ) F X F S S F X F i set i set j O (1) 4.2. Wyniki symulacyjne dla algorytmu FLA W celu walidacji, czy proponowany algorytm jest wystarczającym narzędziem do wykrywania przyczyn raportowanych problemów dotyczących strumieniowania treści w rozważanym systemie dostarczania treści multimedialnych, przeprowadzono szereg testów symu- lacyjnych. Zbadane zostały parametry działania algorytmu FLA (szybkość oraz dokładność) przy założeniu różnych rozmiarów sieci oraz zmiennej liczbie analizowanych alertów (symptomów). Przyjęty scenariusz testowy zakłada, iż błąd w sieci jest traktowany jako przeciążenie łącza lub serwera treści. Wartość określająca pojemność została przypisana do każdego z łączy (LkCap) oraz serwerów (SkCap). Prawdopodobieństwa błędów łączy (PL) oraz serwerów (PS) są ściśle powiązane, zgodnie z równaniem (2). Lk Cap Pr(F L ) Sk Cap Pr(F S ) (2) Przyjęliśmy, że pojemność łączy LkCap = 32, zaś serwerów SkCap = 30 równoczesnych połączeń. Wartości te zostały użyte w algorytmie FLA do wyznaczenia za pomocą formuły (1) zbioru najbardziej prawdopodobnych błędów dla zgłoszonych alertów, przy założeniu że wartość Pr(Sj/FiX) jest równa 1 jeśli błąd FiX powoduje wystąpienie symptomu Sj; w przeciwnym wypadku Pr(Sj/FiX) wynosi 0. Struktura topologii sieci użytych do badań symulacyjnych zostały wygenerowane za pomocą narzędzia Network Manipulator [16]. Podczas symulacji wyszukane zostały węzły brzegowe sieci, do których w sposób losowy dołączono terminale użytkowników oraz serwery treści. W kolejnym kroku wyznaczone zostały prawdopodobieństwa błędów dla każdego łącza oraz serwera treści. Następnie generowano losowe połączenia pomiędzy terminalami a serwerami treści, monitorując na bieżąco obciążenie wszystkich łączy i serwerów do momentu, aż w systemie wystąpiła zdefiniowana wcześniej liczba błędów Nf (co oznaczało, że Nf łączy i/lub serwerów weszło w stan przeciążenia, tj. liczba obsługiwanych przez nie połączeń była większa niż przypisana pojemność LkCap lub SkCap). W przeprowadzonych testach przyjęto że Nf = {1,2,3} błędy. Spośród zbioru terminali użytkowników realizujących połączenia po przeciążonych łączach i/lub od przeciążonych serwerów, wylosowano Na terminali zgłaszających alert. W badaniach przyjęto, iż Na = {2, 5, 10, 20} alertów. Mając zdefiniowany zbiór wygenerowanych błędów, odebranych alertów oraz topologię sieci, uruchomiono algorytm FLA celem lokalizacji błędów skutkujących otrzymanymi alertami. Zbiór błędów otrzymany w wyniku działania algorytmu FLA został porównany ze zbiorem rzeczywistych błędów celem określenia liczby błędów zlokalizowanych poprawnie oraz błędnie. Dokładność algorytmu FLA określa relację pomiędzy prawidłowo i błędnie zlokalizowanymi błędami. Przedstawiona powyżej procedura testowa została wykonana dla sieci o topologii składającej się z określonej liczby węzłów Nn wynoszącej {100, 200, 300, 400}. Dla każdej wartości Nn wygenerowanych zostało 10 różnych topologii sieci, zaś wyniki symulacyjne zgromadzono poprzez wykonanie trzech iteracji testów dla każdej z topologii. Uzyskane wartości średnie wraz z przedziałami ufności (na poziomie 0.95) zostały zaprezentowane na wykresach poniżej. Warto zwrócić uwagę, iż każdy z przeprowadzonych testów obejmował 1000 niezależnych operacji algorytmu FLA. Accuracy Accuracy 0,8 0,6 0,4 0,2 0,8 0,6 0,4 0,2 0,0 2 5 10 20 No. of processed alerts (Na) [alerts] 0,0 2 5 10 20 No. of processed alerts (Na) [alerts] C) Nf = 3 faults Accuracy 1,0 Nn= 100 nodes 0,8 0,6 0,4 Nn= 200 nodes 0,2 Nn= 300 nodes 0,0 2 5 10 20 (o różnej liczbie Nn) wzrastają wraz ze zwiększaniem się liczby jednoczesnych błędów Nf. Dla przykładu, różnica w dokładności algorytmu dla dwóch przypadków: Nn = 400 i Nn = 300, wynosi jedynie 0,035 kiedy Nf = 1 błąd (dla Na = 5 alertów), ale zwiększa się do 0,178 kiedy Nf wynosi 3 błędy (również przy założeniu Na = 5 alertów). Przyczyna jest czysto statystyczna: w przypadku jednego błędu, liczba jego potencjalnych lokalizacji jest niewielka dla każdej z rozpatrywanych topologii. Z kolei dla przypadku trzech występujących równolegle błędów, liczba potencjalnych lokalizacji (dla zbioru trzech błędów) gwałtownie rośnie, szczególnie dla topologii składających się z dużej liczby węzłów. Nn= 400 nodes No. of processed alerts (Na) [alerts] Rys. 3. Dokładność algorytmu FLA w zależności do liczby przetwarzanych alertów. Podsumowując, w wykonanych symulacjach zmiennymi były następujące parametry: Nn, Nf i Na. Należy oczekiwać, że większa topologia (tj. większa wartość Nn) jak również większa liczba jednoczesnych błędów w sieci (tj. większa wartość Nf) skutkują obniżeniem dokładności algorytmu FLA, zwiększając zarazem jego złożoność (a więc wydłużając czas wykonania). Z kolei wzrost liczby zgłoszonych alertów (tj. większa wartość Na) prowadzi do zwiększenia dokładności, lecz także złożoności algorytmu. Rysunek 3 przedstawia dokładność algorytmu FLA w funkcji parametrów Nn, Nf i Na. Wykres 3A wyznaczono dla przypadku wystąpienia jednego błędu w sieci (proces generacji błędów został zatrzymany w chwili pojawienia się pierwszego przeciążenia); wykres 3B związany jest z wystąpieniem dwóch jednoczesnych błędów, zaś wykres 3C – trzech. Wszystkie wykresy zaprezentowane zostały w tej samej skali, zaś oś pozioma określa liczbę zgłoszonych alertów Na. Jak możemy zaobserwować, uzyskane charakterystyki dokładności algorytmu FLA w większości przypadków są zgodne z oczekiwaniami. Pewnym zaskoczeniem może być znaczące obniżenie dokładności algorytmu zaprezentowane na wykresie 3C (tj. dla przypadku najwyższej wartości Nf). Na tej podstawie możemy stwierdzić, iż FLA działa prawidłowo kiedy liczba jednocześnie występujących błędów jest niewielka. Jednakże możemy przyjąć, iż taka wartość jest akceptowalna, gdyż w normalnych warunkach działania sieci jednoczesne przeciążenie wielu różnych serwerów lub łączy występuje bardzo rzadko. We wszystkich badanych przypadkach już 10 odebranych alertów pozwalało uzyskać wystarczającą dokładność algorytmu lokalizacji błędów. Dlatego też czas TO określający odstęp pomiędzy kolejnymi wywołaniami FLA może być ustawiony na małą wartość, co obniża prawdopodobieństwo równoczesnego wystąpienia więcej niż dwóch błędów w jednym okresie TO. W opracowanej implementacji przyjęto TO = 200 ms. Wykresy przedstawione na rysunku 3 wskazują również, iż początkowo liczba węzłów w sieci nie ma zbyt dużego wpływu na uzyskane wyniki, jednakże różnice pomiędzy wynikami dla poszczególnych topologii 50 A) Variable No. of nodes and Nf= 3 faults B) Variable No. of processed alerts and Nn= 100 nodes 50 Execution time [ms] B) Nf = 2 faults 1,0 Execution time [ms] A) Nf = 1 fault 1,0 40 30 20 10 0 100 200 300 400 No. of nodes (Nn) [nodes] Na= 2 alerts Na= 5 alerts Na= 10 alerts Na= 20 alerts 40 30 20 10 0 2 5 10 20 No. of processed alerts (Na) [alerts] Nf= 1 fault Nf= 2 faults Nf= 3 faults Rys. 4. Czas wykonania algorytmu FLA w zależności od A) liczby węzłów w sieci, B) liczby przetwarzanych alertów. Rysunek 4 prezentuje wartości czasu wykonania algorytmu FLA dla różnej liczby Nn węzłów w sieci (wykres 4A) oraz różnej liczby Na zgłoszonych alertów (wykres 4B). Symulacje zostały przeprowadzone na serwerze HP ProLiant DL360G6 z 64-bitowym systemem operacyjnym Linuks (jądro 2.6.34). Wykres 4A wskazuje wykładniczy wzrost czasu wykonania algorytmu wraz ze wzrostem struktury sieci (zwiększeniem liczby węzłów Nn). Ponadto, złożoność algorytmu FLA jest wprost proporcjonalna do liczby przetwarzanych alertów (co pokazuje wykres 4B), ponieważ FLA wykonuje jedną iterację więcej dla każdego kolejnego alertu. Podobnie możemy zaobserwować liniowy wzrost czasu wykonania FLA w wyniku zwiększania liczby jednoczesnych błędów Nf. Możemy zatem przyjąć, iż otrzymane charakterystyki są zgodne z oczekiwaniami. 5. PODSUMOWANIE Niniejszy artykuł prezentuje rozwiązanie przyjęte dla realizacji systemu zarządzania usługami SM w projektach ALICANTE i DISEDAN, umożliwiające wdrożenie zarządzanych i niezarządzanych usług dostarczania multimediów. Ponadto wskazuje on korzyści rozszerzenia procesu dostarczania treści o świadomość użytkownika, świadomość sieci i świadomość treści, umożliwiając w ten sposób zwiększenie poziomu zadowolenia użytkownika z jakości odbioru treści multimedialnych. Wdrożenie usług zarządzanych, bazujących na alokacji wydzielonych zasobów dla różnych typów usług multimedialnych, jest możliwe dzięki znajomości typu transferowanej treści na poziomie sieciowym. Dodatkowo, adaptację źródła treści oraz ścieżki przekazu uzyskano poprzez wprowadzenie świadomości użytkownika, sieci i treści do płaszczyzny zarządzania usługami. Adaptacja źródła treści oraz ścieżki przekazu zwiększa efektywność procesu dostarczania treści w przypadku usług niezarządzanych. Ponadto, w artykule zademonstrowano, za pomocą badań symulacyjnych, dokładność działania algorytmu lokalizacji błędów FLA dla różnych scenariuszy, zakładających zmienną liczbę węzłów w sieci, występujących błędów oraz zgłaszanych alertów. Algorytm FLA wykorzystywany jest m.in. do adaptacji schematu rozmieszczenia treści na serwerach, zależnie od aktualnego stanu sieci oraz serwerów treści, i opiera się na zgłaszanych przez użytkowników alertach sygnalizujących błędy w procesie przekazu treści. W ten sposób zaprezentowana architektura może wykorzystywać dwie metody dla zwiększenia parametrów jakości obsługi QoS: alokację zasobów (odpowiednich do obsługi określonego typu treści) dla danej sieci VCAN, przeprowadzaną na żądanie dostawcy usług (operacje wykonywane w średniej i długiej skali czasowej), oraz przełączanie serwerów treści (zbiór dynamicznych akcji wykonywanych w krótkiej skali czasowej). Podsumowując, nowe funkcjonalności systemu zarządzania usługami SM w środowisku sieci CAN mają na celu zwiększenie jakości oferowanych usług poprzez zapewnienie kooperacji pomiędzy różnymi podmiotami zaangażowanymi w proces strumieniowania treści multimedialnych. Dalsze badania będą ukierunkowane na opracowanie systemu nakładkowego (ang. overlay) usprawniającego proces kooperacji pomiędzy podmiotami, rozszerzając tym samym zbiór możliwych funkcjonalności. Prace badawcze, których wyniki przedstawiono w niniejszym artykule, zostały wykonane w ramach dwóch projektów: ALICANTE, dofinansowanego ze środków 7. Programu Ramowego Unii Europejskiej (numer kontraktu: 248652), oraz CHIST-ERA DISEDAN (numer umowy: ERA-NET-CHIST-ERAII/01/2014) SPIS LITERATURY [1] J. Schönwälder et. al., “Future Internet = Content + Services + Management”, IEEE Communications Magazine, vol. 47, no. 7, pp. 27-33, Jul. 2009 [2] FP7 ICT project, “MediA Ecosystem Deployment Through Ubiquitous Content-Aware Network Environments”, ALICANTE, No248652, http://www.ictalicante.eu [3] H. Koumaras et al., “Media Ecosystems: A Novel Approach for Content-Awareness in Future Networks”, FIA Book 2010 [4] Strona WWW projektu CHIST-ERA DISEDAN: http://wp2.tele.pw.edu.pl/disedan/ [5] V. Jacobson et al., “Networking Named Content,” CoNEXT ’09, New York, USA, pp. 1–12, 2009 [6] T. Koponen et al.: “A data-oriented (and beyond) network architecture”, ACM SIGCOMM 2007 [7] K Katsaros, G. Xylomenos, G. Polyzos, “MultiCache: An overlay architecture for information-centric networking”, Computer Networks, Elsevier, vol. 55, no. 4, pp. 938-947, March 2011 [8] A. Detti, N. Blefari-Melazzi, S. Salsano, M. Pomposini, “CONET: A Content Centric Inter-Networking Architecture”, ACM Information-Centric Networking. 2011 [9] J. Choi, J. Han, E. Cho, T. Kwon, and Y. Choi, “A Survey on Content-Oriented Networking for Efficient Content Delivery”, IEEE Communications Magazine, March 2011 [10] A. Bourdena, E. Pallis, G. Kormentzas, H. Skianis, G. Mastorakis, “QoS provisioning and policy management in a broker-based CR network architecture”, in Proc. IEEE Globecom 2012, Anaheim, California, USA, 03-07 December, 2012, pp. 1841-1846 [11] E. Borcoci et al, “Connectivity Services Management in Multi-domain Content-Aware Networks for Multimedia Applications”, Proc. of. INTERNET 2011, Luxembourg, June 2011 [12] S.H. Yeganeh, A. Tootoonchian, and Y. Ganjali, “On Scalability of Software-Defined Networking” IEEE Communications Magazine, pp.136-141, February 2013 [13] J. Mongay Batalla, L. Lopatowski et al., „Dynamic Seamless Handover of Video Servers”. 12th International Conference on Telecommunications ConTEL 2013. Zagreb (Croatia). June 2013 [14] M. Steinder and A. S. Sethi, “A survey of fault localization techniques in computer networks,” Elsevier, Science Computer Programming, vol. 53, pp. 165–194, 2004 [15] H. Dong et al., “Fast Fault Localization for Largescale IP-based Communication Systems Using Bayesian Networks”. In Chinese Journal of Electronics Vol.18, No. 4, pp. 735-740, October 2009 [16] Network Manipulator software, dostęp online: http://www.labri.fr/perso/magoni/nem/, kwiecień 2014