Podczas gdy zarówno ATM, jak i IP są w stanie przesyłać dane wideo, staje się niezmiernie istotnym przeanalizowanie, która technologia jest najodpowiedniejsza i najbardziej opłacalna w zależności od typu transferowanych danych wideo. Niniejsze opracowanie prezentuje wszystkie najważniejsze plusy i minusy obydwu technologii w odniesieniu do transmisji obrazu wideo w czasie rzeczywistym. W dalszej części tego dokumentu zawarta jest odpowiedź na następujące pytanie: w jakich aplikacjach stosowanie ATM i IP ma największy sens pod względem QoS (poziomu jakości usług), dostępnych technologii oraz kosztów rozwiązania? Na zakończenie zaprezentowane są prognozy dotyczące rozwoju technologii transmisji wysokiej jakości danych wideo czasu rzeczywistego poprzez IP/ATM. Dużo obecnie słyszy się o wykorzystywaniu IP do transferu strumieni MPEG-2 audio i wideo oraz czy ATM jest lepszym wyborem od IP do takich zastosowań. To opracowanie wyjaśnia zagadnienia niezbędne do uzyskania odpowiedzi na powyższe pytanie.
Przed porównaniem ATM i IP oraz wskazaniem plusów i minusów poszczególnych technologii w przesyłaniu cyfrowych obrazów wideo koniecznym jest przeanalizowanie podstaw poszczególnych protokołów, związanych z interesującym nas zastosowaniem (pomoże to nam zrozumieć, dlaczego dana technologia ma określoną charakterystykę), jak również zagadnień związanych z QoS w odniesieniu do takich usług jak broadcastowa transmisja cyfrowego wideo.
ATM pojawiło się na scenie protokołów komunikacyjnych we wczesnych latach 80., przeżywając szczyt rozwoju oraz działań standaryzacyjnych w połowie lat 90. ATM jest obecnie powszechnie wykorzystywanym protokołem do transmisji cyfrowej TV. Podstawową zaletą ATM jest naturalne przystosowanie – przy takich założeniach protokół ten był projektowany – do transportu usług o różnych poziomach wymagań QoS poprzez tę samą infrastrukturę sieciową. Zazwyczaj usługi wideo, danych i głosowe mają bardzo odmienne wymogi co do funkcjonowania sieci pod względem QoS. Transfer danych takich jak poczta e-mail, surfowanie po Internecie czy przesyłanie plików jest wrażliwy na straty pakietów oraz błędy transmisji, podczas gdy opóźnienia i jitter są w tym przypadku stosunkowo mało istotne. Odmienną sytuację mamy w przypadku usług głosowych i wideo, które wrażliwe są na opóźnienia i jitter, natomiast straty i błędy w transmisji mają tu ograniczone znaczenie. Historycznie te trzy główne typy usług wykorzystywały oddzielne infrastruktury sieciowe przystosowane do spełniania wymogów przesyłanych przez nie danych. ATM został zaprojektowany w celu umożliwienia transportu powyższych usług w jednej sieci. Dodatkowo w związku z zagadnieniem QoS ATM został wyposażony w mechanizm elastycznego przydzielania pasma, umożliwiający zagwarantowanie dla danej usługi dokładnie takiej przepustowości, jaka jest dla niej przewidziana zgodnie ze zdefiniowanym profilem ruchu. Jednakże z powodu wykorzystywanej w ATM multipleksacji statystycznej może dojść do wystąpienia sytuacji, w których sieć będzie przez pewien okres czasu przeciążona. Fakt ten wraz z innymi czynnikami może doprowadzić do powstania nieprawidłowości w transmisji komórek ATM. Zdefiniowano pięć podstawowych zakłóceń transmisji komórek ATM:
Zakłócenia te pojawiają się głównie w wskutek nierównomiernego zapełniania/przepełniania buforów w przełącznikach ATM (powodując opóźnienia, jitter i straty komórek), długości linii transmisyjnych (powodując opóźnienia), szumów występujących w kanałach (błędy komórek). Zaburzenia te są w stanie wpłynąć na jakość świadczonych usług (wideo).
Bez wątpienia jedną z głównych zalet ATM jest zdolność do zapewnienia QoS. Warstwa ATM sama w sobie nie posiada zaimplementowanych mechanizmów do realizacji Qos. W jaki więc sposób jest to osiągane w sieciach ATM? Niektóre z istotniejszych metod to:
Funkcjonalność AAL (ATM Adaptation Layer)
Do transmisji sygnałów MPEG-2 w sieciach ATM wykorzystywane są dwie warstwy AAL – AAL-1 i AAL-5. AAL-1 została zaprojektowana w celu emulacji pseudosynchronicznych połączeń realizowanych w z natury asynchronicznych sieciach ATM. Podejście takie miało na celu wsparcie istniejących usług działających w sieciach PDH, oferujących gwarantowane (stałe) pasmo ze stałymi opóźnieniami. Mechanizmy synchronizacji koderów z dekoderami sygnału MPEG-2 zostały zaprojektowane w oparciu o założenie istnienia stałych wartości opóźnień występujących w sieci, w związku z tym zagwarantowanie takich warunków jest niezbędnym warunkiem do realizacji transmisji danych MPEG-2. AAL-1 ma możliwość transmisji znaczników czasowych, w celu zapewnienia w sieci stałej prędkości bitowej, poprzez mechanizm zwany SRTS (Synchronous Residual Time Stamp). Do transmisji danych MPEG-2 zazwyczaj wykorzystywana jest metoda zwana ACR (Adaptive Clock Recovery), bazująca na mechanizmie buforowania odbieranych danych, umożliwiającym, po pewnym czasie integracji, ustalenie stałej prędkości bitowej na wyjściu odbiornika przy nieznacznych zmianach prędkości docierających do odbiornika danych. W celu zmniejszenia bitowej stopy błędów/strat komórek zaimplementowano mechanizm Reed-Salomon umożliwiający korekcję 2 bajtów ze 128 lub 4 straconych komórek ATM na 128. Niniejszym strumień transportowy MPEG-2 został zabezpieczony zarówno przed jitter jak i stratą/błędem komórek ATM. AAL-5 (pierwotnie zaprojektowana z myślą o aplikacjach transportujących dane, np. łączenie sieci LAN) nie oferuję żadnych mechanizmów zabezpieczających przed opóźnieniami czy błędami, z tego też powodu wykorzystywanie go do aplikacji typu real-time-video jest bardzo sporadyczne.
Connection Admission Control i Traffic Contracts
Przed włączeniem do sieci ATM użytkownika koniecznym jest sprecyzowanie parametrów połączenia, jak również zaakceptowanie ich przez sieć. W praktyce urządzenie po stronie użytkownika/klienta (którym w przypadku cyfrowego wideo jest zazwyczaj adapter ATM z interfejsem ASI), chcącego skorzystać z sieci ATM (rozpatrywany jest tu przypadek SVC), generuje „wiadomość startową” z wyszczególnionymi „elementami informacyjnymi”, określającymi ilość żądanego pasma, profil ruchu, parametry QoS itp. Po wysłaniu wiadomości startowej elementy sieciowe oszacowują czy zawarte w niej zasoby są aktualnie dostępne. Jeśli żądania mogą zostać spełnione na całej długości toru transmisyjnego, bez wpływu na pracę korzystających już z sieci użytkowników, połączenie zostanie przyznane oraz na czas jego trwania zostanie rozpisany „kontrakt ruchu” pomiędzy użytkownikiem a siecią ATM.
Jeśli dostępna ilość zasobów jest niewystarczająca, próba połączenia się użytkownika z siecią zostanie odrzucona. Abonent w takiej sytuacji ma możliwość ponownej próby połączenia z siecią z obniżonym poziomem żądanych zasobów, lub zaprzestać prób łączenia na pewien okres czasu. Przy takim podejściu sieć ATM może zabezpieczać wykorzystujących ją użytkowników przed zmianą (pogorszeniem) parametrów przyznanych im połączeń, podczas gdy nowi użytkownicy będą dołączani do sieci. W przypadku PVC (stałych połączeń wirtualnych) zasada postępowania jest identyczna z tą różnicą, że czynności te dokonywane są ręcznie (przez administratora).
Traffic Shaping i Policing
Możemy wyróżnić kilka rodzajów ruchu w sieciach ATM, włączając w to CBR, VBR, ABR (Available Bit Rate) czy UBR (Unspecified Bit Rate). Ze względu na naturę statystycznego multipleksowania i faktu, iż wielu operatorów świadomie przeciąża swoje sieci, mogą pojawić się sytuacje, w których przychodzący do portu przełącznika ATM ruch o stałej w czasie prędkości może przekroczyć możliwości tego portu. W takiej sytuacji system buforów będzie się starał rozłożyć w czasie napływający, nadmiarowy ruch. W sytuacjach gdy jeden lub więcej użytkowników generuje większą ilość danych od wartości określonej w przyznanych im kontraktom, switch ATM może odrzucić (skasować) lub oznaczyć (ustawiając pole CLP w nagłówku ATM) komórki przekraczające dozwolone ilości, czyniąc je tym samym ruchem o najniższym priorytecie.
Początki protokołu IP datowane są na środek lat 60. Początkowo został on zaprojektowany z myślą o transmisji takich danych jak: poczta email, FTP, Telnet itp. Z powodu iż IP stał się dominującym protokołem komunikacyjnym na świecie, efekt „ekonomii skali” w znaczący sposób obniżył koszt sprzętu IP, czyniąc go niezwykle atrakcyjnym w porównaniu ze sprzętem opartym na pozostałych protokołach. Jednym z najbardziej zajmujących projektantów tematem jest niezwykle popularna usługa transmisji skompresowanych strumieni wideo MPEG-2 poprzez sieci IP.
Głównym wyzwaniem projektantów protokołów sieciowych jest stworzenie narzędzi i mechanizmów do transportu multimedialnych usług czasu rzeczywistego poprzez sieci, które od samego początku były projektowane z myślą o transmisji jedynie danych nieczułych na opóźnienia czasowe. Najważniejsze protokoły związane z transportem multimedialnych danych (głos czy wideo) poprzez sieci IP w skrócie opisano poniżej.
IP jest zasadniczo protokołem routingu. Poprzez analizę poszczególnych części adresu IP podejmowane są decyzje doboru trasy pakietów. Istnieją różne wersje protokołu IP; najpopularniejszą, obecnie wykorzystywaną jest wersja czwarta, pomimo, iż wersja szósta (obsługująca znacznie szerszą przestrzeń adresową) została zdefiniowana parę lat temu.
Podczas, gdy IP nie gwarantuje transferu danych, TCP jest konieczne do kontroli nad tym, aby wszystkie części (np. pliku) zostały bezproblemowo przetransportowane poprzez sieć. Jeśli jakieś części strumienia danych zostaną uszkodzone, stracone lub dotrą w niewłaściwej kolejności, TCP zapewni retransmisję/zmianę kolejności niewłaściwych części pliku.
Został stworzony do usług, w których retransmisja informacji nie ma sensu, zazwyczaj ze względu na fakt, iż transmitowany strumień danych jest strumieniem czasu rzeczywistego. UDP nie posiada funkcjonalności umożliwiających retransmisję czy zmianę kolejności przesyłanych danych.
Jest wykorzystywany do enkapsulacji usług czasu rzeczywistego, dodając opcję radzenia sobie ze złą kolejnością pakietów (numer sekwencyjny), jak również pole na znacznik czasowy, wykorzystywane do transmisji informacji synchronizacyjnych.
Poprzez RTCP wydajność sieci (w znaczeniu opóźnień itp.) może być raportowana wstecznie do strony żądającej danej usługi, w celu umożliwienia nadajnikowi lub innej części sieci zmodyfikowania jego parametrów/priorytetów.
Pozwala wszystkim urządzeniom w sieci na utrzymywanie tego samego zegara i pozwala na uzyskanie synchronizacji w ciągu około 1 msec poprzez rozgłaszanie informacji taktujących na podstawowych zasadach.
Sieci przesyłające dane są zazwyczaj typu bezpołączeniowego. Jednakże poprzez zastosowanie RSVP sieć IP przyjmuje bardziej połączeniowo zorientowany charakter. RSVP jest metodą na zarezerwowanie zasobów sieciowych. RCVP ustala „ścieżkę”, upewniając się, że wszystkie routery biorące udział w transmisji danych danego połączenia mają zarezerwowane dla niego zasoby.
Pozwala klientom na dołączanie się do sesji transmisji multicast i uzyskanie jej kopii danych od transmitującego je routera.
Niższe warstwy (warstwa fizyczna i sieciowa) w tym kontekście nie zostały zdefiniowane, mogą jednak bazować na protokole Ethernet, MPLS czy nawet ATM. Istotnym jest, iż są zdolne do zarządzania pasmem/zasobami sieciowymi wystarczająco dobrze aby zapewnić potrzebny poziom QoS lub posiadają wystarczającą ilość pasma umożliwiającego uniknięcie zatorów, omijając w ten sposób potrzebę kontroli QoS.
DVB pracuje obecnie na infrastrukturze DVB IP (DVB IPI). Ta specyfikacja pokrywa dystrybucję usług DVB poprzez sieci IP w bardzo szerokim zakresie. Aspekt transportowy tej specyfikacji organizowany jest poprzez wykorzystanie wyżej wymienionych protokołów, a przede wszystkim poprzez mapowanie strumieni MPEG-2 na RTP, które transportowane są wtedy za pomocą UDP/IP. Ten format bazuje na dokumencie RFC 2250, opisującym algorytm pakietyzacji MPEG-1 i 2 poprzez IP, bazującym na RTP.
ATM posiada zaimplementowany bardzo zaawansowany mechanizm QoS i z założenia jest w stanie wspierać wiele typów usług w jednej sieci. Ceną zarządzalności, elastyczności i QoS jest oczywiście zwiększona złożoność i opóźnienia sieci. Mimo iż ATM jest szeroko stosowany na całym świecie, nigdy nie udało się mu zbliżyć do ilości sprzętu bazującego na protokole IP. W związku z tym ceny tego rozwiązania pozostają wyższe od odpowiadających mu projektów IP. IP jest prostym i niedrogim rozwiązaniem nie wnoszącym dużych opóźnień – tak długo, jak wykorzystywaną usługą jest transport danych, a ilość pasma jest wystarczająca. Gdy tylko pojawia się konieczność zapewnienia określonego poziomu QoS dla usług czasu rzeczywistego, sytuacja może zacząć się zmieniać, gdyż dołączane są wymagania protokołów RSVP, DiffServ, MPLS i innych technologii wymaganych do realizacji QoS. Dodanie tych usług w naturalny sposób zwiększa skomplikowanie i koszt rozwiązania.
W przeciwieństwie do ATM IP ciągle nie jest tak szeroko stosowany do transportu cyfrowego obrazu wideo czasu rzeczywistego w formacie MPEG-2, w związku z tym poziom doświadczeń w tym zakresie jest w pewien sposób ograniczony. Niemniej jednak wiele testów i badań jest obecnie przeprowadzanych w celu zdobycia praktycznych doświadczeń w tym temacie.
Gdzie obecnie stosowanie ATM ma sens, a gdzie IP?
Należy rozważyć możliwości QoS, dostępność sprzętu, dojrzałość, koszt poszczególnych elementów aplikacji, jak również opcje dostępnych rozwiązać sieciowych. Jednakże na ogólnym poziomie planowania możemy wyróżnić następujące zasady:
Z perspektywy QoS ATM jest obecnie ciągle jedyną droga do zapewnienia QoS w wielousługowych sieciach (gdzie pasmo jest ograniczonym zasobem), zachowującą elastyczność rozwiązania. Sprzęt do transmisji MPEG-2 prze sieć ATM (np. adaptery ATM) są dostępne już od dłuższego czasu i osiągnęły dojrzały stan rozwoju. Konsekwencją tego jest również znaczący spadek kosztu tych rozwiązań. Oprócz zoptymalizowania adapterów ATM do efektywnego pod względem kosztów rozwiązania transferu wideo poprzez sieci ATM, adaptery ATM umożliwiają realizacją łączy LAN poprzez SDTI oraz telefoniczne/PBX łącze pomiędzy np. studiami. Z punktu widzenia standardów transfer MPEG-2 poprzez ATM jest bardzo dokładnie zdefiniowany, zarówno przez ATM Forum i ITU-T, jak również przez DVB/ETSI. Z tego powodu wykorzystywanie protokołu ATM ma sens w następujących sytuacjach:
W przypadku IP mechanizm QoS jest już w drodze, jednak nie dotarł jeszcze do w pełni dojrzałego stanu. Szeroki zestaw protokołów jest dostępny lub jest w fazie zatwierdzania przez ETSI, jednakże izolujący protokół ciągle odgrywa bardzo istotną rolę – musi być albo bardzo dobrze zarządzany (wykorzystywanie MPLS lub ATM) lub alternatywnie ilość dostępnego pasma musi być bardzo duża (większa od potrzebnej). Niemniej jednak IP staje się coraz bardziej interesującą alternatywą dla transmisji obrazu wideo za sprawą niskich kosztów tych rozwiązań, wynikających z popularności sieci IP. Podstawowy sprzęt IP jest łatwo dostępny, natomiast urządzenia do transmisji MPEG-2 poprzez sieć IP w coraz większej ilości pojawiają się na rynku. Najlepszymi sytuacjami dla implementacji protokołu IP są:
Spoglądanie w kryształową kulę nigdy nie jest prostym zadaniem, jednakże wydaje się być rozsądnym przypuszczeniem, iż…
Operatorzy sieci i nadawcy muszą w dzisiejszych czasach dokonać wyboru pomiędzy IP i ATM jako głównym technologiami sieciowymi. Podstawowe plusy i minusy tych technologii zostały przeanalizowane i wynikająca z nich konkluzja jest taka, iż obydwie technologie mają swoje uzasadnienie do transmisji w odniesieniu do transmisji cyfrowego wideo. ATM jest skutecznym rozwiązaniem, które udowodniło swoją skuteczność w wykonywaniu wyżej wspomnianego zadania i pozostanie dobrym wyborem do aplikacji zasilających jak i dystrybucyjnych przez przynajmniej kilka następnych lat. IP zyskuje coraz solidniejsze podstawy i funkcjonalność QoS staje się w nim bardziej dojrzała. Ze względu na ekonomikę rozmiaru/skali rozwiązania oparte na urządzeniach IP mają przewagę cenową nad innym sprzętem sieciowym. Z tego powodu już dzisiaj możemy czerpać z tego korzyści, tworząc pochłaniające duże ilości pasma aplikacje typu VoD.