PRACA DYPLOMOWA MAGISTERSKA - …zskl.p.lodz.pl/~morawski/Dyplomy/Praca dyplomowa p...Politechnika...

Politechnika Łódzka Instytut Informatyki

Instytut Informatyki

90-924 Łódź, ul. Wólczańska 215, budynek B9

tel. 042 631 27 97, 042 632 97 57, fax 042 630 34 14 email: [email protected]

PRACA DYPLOMOWA MAGISTERSKA

PRZESYŁANIE SYGNAŁU TELEWIZJI CYFROWEJ W OPARCIU O SIEĆ IP

Wydział Fizyki Technicznej, Informatyki i Matematyki Stosowanej

Promotor: dr inż. Michał Morawski

Dyplomant: Marek Dwórznik

Nr albumu: 141274

Łódź 2008

Dwórznik Marek

Przesyłanie sygnału telewizji cyfrowej w oparciu o sieć IP 1

Spis treści

WYKAZ SKRÓTÓW .............................................................................................................................................. 2

WYKAZ RYSUNKÓW .......................................................................................................................................... 3

WYKAZ TABEL....................................................................................................................................................... 3

1 WSTĘP ............................................................................................................................................................. 4

2 CEL I ZAKRES PRACY .............................................................................................................................. 6

3 WPROWADZENIE ...................................................................................................................................... 8

3.1 TELEWIZJA CYFROWA ................................................................................................................................ 8 3.2 TECHNOLOGIE DOSTARCZANIA OBRAZU W SIECI IP .............................................................................. 8

3.2.1 IPTV ..................................................................................................................................................... 9 3.2.2 Internet TV ........................................................................................................................................ 9

3.3 KORZYŚCI WYKORZYSTANIA SIECI IP ................................................................................................... 10 3.4 PRZYSZŁOŚĆ IPTV ................................................................................................................................. 11

4 ARCHITEKTURA SYSTEMU IPTV ..................................................................................................... 13

4.1 ASPEKT FUNKCJONALNY SIECI DLA IPTV .............................................................................................. 18 4.1.1 TVoDSL – opis transportu treści ............................................................................................. 18

4.2 SIEĆ DOSTĘPOWA ................................................................................................................................... 20 4.2.1 DSLAM .............................................................................................................................................. 22 4.2.2 Set-top-boxes ................................................................................................................................ 25

4.3 SIEĆ AGREGACYJNA ................................................................................................................................ 28 4.3.1 Wymagania przepustowości sieci dla IPTV ......................................................................... 30

5 PRZESYŁANIE STRUMIENI WIDEO W SIECI IP..................................................................... 31

5.1 IP MULTICAST ......................................................................................................................................... 31 5.1.1 Sposoby dostarczania danych w IP Multicast .................................................................... 32 5.1.2 Adresacja dla IP Multicast a programy w IPTV ................................................................. 33

6 PROTOKOŁY WYKORZYSTYWANE W IP MULTICAST .......................................................... 35

6.1 PIM .......................................................................................................................................................... 37 6.1.1 Konfiguracja protokołu PIM SSM ............................................................................................ 42

6.2 IGMP ....................................................................................................................................................... 45 6.2.1 Konfiguracja protokołu IGMP dla IPTV ................................................................................. 49

7 MECHANIZMY BEZPIECZEŃSTWA W IPTV ................................................................................ 51

7.1 DHCP SNOOPING ................................................................................................................................... 51 7.2 DYNAMIC ARP INSPECTION ................................................................................................................... 52 7.3 UNICAST REVERSE PATH FORWARDING ............................................................................................... 53

8 ZARZĄDZANIE DOSTĘPEM DO USŁUGI IPTV .......................................................................... 57

9 QOS ................................................................................................................................................................. 61

9.1 WPŁYW SIECI NA JAKOŚĆ PRZESYŁANIA STRUMIENI WIDEO ............................................................... 61 9.2 ZAPEWNIENIE JAKOŚCI TRANSMISJI W SIECI AGREGACYJNEJ ............................................................. 65 9.3 ZAPEWNIENIE JAKOŚCI TRANSMISJI W SIECI DOSTĘPOWEJ ................................................................ 69

10 POSUMOWANIE ....................................................................................................................................... 70

Dwórznik Marek


Wykaz skrótów AF Assured Forwarding AR Agregated Router

ASM Any Source Multicast ATM Asynchronous Transfer Mode

BTV Broadcast Television

CAPEX Capital Expenditures - wydatki inwestycyjne na rozwój produktu lub wdrożenie systemu

CBR Constant Bit Rate COPS Common Open Policy Service

DAI Dynamic Arp Inspection DHCP Dynamic Host Configuration Protocol

DoS Denial of Service Attack DSL Digital Subscriber Line

DSLAM DSL Access Module EF Express Forwarding

EMM Entitlement Management Message EMMi Entitlement Management Message injector

EPG Electronic Program Guide ETH Ethernet

GPON Gigabit Passive Optical Network

HAG Home Access Gateway HDTV High Definition Television

HE Head End IANA Internet Addressing and Numbering Authority

IGMP Internet Group Management Protocol IPTV Usługa telewizji w oparciu o protokół IP

MPLS Multi Protocol Label Switching NGN Next Generation Network

PIM Protocol Independent Multicast PVC Permanent Virtual Circuit

QOS Quality Of Service SAS Subscriber Authorization System

SHE Super Head End SMS Subscriber Management System

SPF Service Platform

SSM Source Specific Multicast STB Set-Top-Box

Triple Play Usługa, która łączy w jednym pakiecie Internet, telefon i telewizję.

TS Transport Stream UBR Unspecified Bit Rate

uRPF Unicast Reverse Path Forwarding VBR-rt Variable Bit Rate real-time

VOD Video On Demand

Dwórznik Marek


Wykaz rysunków Rysunek 1 Uproszczony schemat sieci dla Internet TV[1] .............................................. 10 Rysunek 2 Wzrost liczby klientów IPTV we France Telecom w latach 2004 – 2006.[1] ...... 12 Rysunek 3 Wykres pokazujący przyrost liczby klientów wideostrady TP [20] ................... 12 Rysunek 4 Uproszczony schemat sieci IPTV[1] ............................................................ 14 Rysunek 5 Architektura IPTV zaprezentowana prze firmę Cisco.[3] ................................ 15 Rysunek 6 Architektura funkcjonalna IPTV zaprezentowana przez firmę Sofrecom.[32] .... 17 Rysunek 7 Transmisja unicast pomiędzy platformą a STB związany z zarządzaniem usługą 20 Rysunek 8 Schemat obrazujący technologię DSL.......................................................... 21 Rysunek 9 Realizacja styku L2 pomiędzy DSLAM a routerem ......................................... 23 Rysunek 10 Strona przedstawiająca mozaikę umożliwiającą wybór programu

telewizyjnego.[36] ................................................................................................... 27 Rysunek 11 Proces inicjujący oglądanie programu telewizyjnego.[36] ............................ 28 Rysunek 12 Architektura fizyczna sieci dla IPTV ........................................................... 29 Rysunek 13 Transmisja danych typu unicast ............................................................... 32 Rysunek 14 Transmisja danych typu multicast ............................................................ 32 Rysunek 15 Mapowanie multicastowego adresu IP do adresu MAC. [6] ........................... 35 Rysunek 16 Protokoły w sieciach rozgłoszeniowych ...................................................... 36 Rysunek 17 Protokoły IP Multicast w prezentowanym rozwiązaniu ................................. 37 Rysunek 18 Drzewo dystrybucyjne z korzeniem źródła ................................................. 38 Rysunek 19 Drzewo dystrybucyjne z korzeniem współdzielonym .................................... 39 Rysunek 20 Obsługa ruchu BTV i VOD ........................................................................ 48 Rysunek 21 Proces DHCP Snooping ............................................................................ 51 Rysunek 22 Zabezpieczenie prze Denial Of Service ...................................................... 53 Rysunek 23 Zebezpieczenie przed DHCP Spoofing ........................................................ 53 Rysunek 24 Proces dla uRPF w przypadku powodzenia ................................................. 55 Rysunek 25 Proces dla uRPF w przypadku ataku .......................................................... 56 Rysunek 26 Zasada działania systemu warunkowego dostępu (CAS). [33] ...................... 58 Rysunek 27 Architektura Viaccess – CAS.[36] ............................................................. 59 Rysunek 28 Przykład pokazujący realizację usługi triple play w sieci agregacyjnej i

dostępowej.[10] ...................................................................................................... 61 Rysunek 29 Obraz z widocznymi artefaktami w przypadku problemów z transmisją.[34] .. 62 Rysunek 30 Przykład GOP (Group Of Pictures).[41] ...................................................... 63 Rysunek 31 Wpływ utraty pakietów na jakość odbieranego obrazu MPEG2. ..................... 64 Rysunek 32 Menadżer przepustowości używający protokołu COPS dla komunikacji z

serwerem VOD.[33] ................................................................................................. 66 Rysunek 33 Przykład konfiguracji Triple Play na DSLAM ................................................ 69

Wykaz tabel Tabela 1 Wykaz parametrów dla różnych technologii DSL ............................................. 21 Tabela 2 Format pola opcji 82 dla DHCP relay[39] ....................................................... 23 Tabela 3 Format podpola dla opcji 82[39] ................................................................... 23 Tabela 4 Opis przeznaczenia pod pól w opcji 82.[39] .................................................... 24 Tabela 5 Schemat Circuit ID dla DSLAM ...................................................................... 24 Tabela 6 Adresacja dla IP Multicast ............................................................................ 34 Tabela 7 Konfiguracja globalna na wszystkich routerach w sieci ..................................... 43 Tabela 8 Wiadomość IGMP w wersji 2 ......................................................................... 46 Tabela 9 Lista komunikatów IGMP .............................................................................. 47 Tabela 10 Konfiguracja w trybie globalnym w celu mapowania IGMP do PIM SSM ............ 49 Tabela 11 Klasy QOS dla Triple Play ........................................................................... 68 Tabela 12 Przykład konfiguracji QOS na DSLAM dla usługi Triple Play ............................. 69

Dwórznik Marek


1 Wstęp

Od wielu dekad telewizja jest jednym z głównych mediów

komunikacyjnych. Początki telewizji sięgają roku 1923. Wtedy to właśnie

skonstruowany został kineskop przez Władimira Zworykina.[9] Technologia

ta, od początku jej narodzin, cały czas ewoluuje, żeby sprostać

wymaganiom, które są przed nią stawiane. Dostarcza ona niezastąpionych

informacji, rozrywki a dla niejednego telewidza jest jedynym zaufanym

źródłem wiedzy.

Od jakiegoś czasu, dostawcy usług, żeby sprostać oczekiwaniom

klientów, muszą oferować bardziej zintegrowane rozwiązania. Każdy

operator, chcący być konkurencyjnym na obecnym rynku, musi dążyć do

oferowania usług takich jak telewizja, Internet, telefon. Jedną z technologii,

która pozwoli nam osiągnąć najważniejszy aspekt tego celu jest IPTV. To

rozwiązanie pozwala sprostać oczekiwaniom klientów, którzy stają się coraz

bardziej wymagający. W dzisiejszych czasach klient oczekuje żeby obraz w

telewizorze był najwyższej jakości, a niezawodność w odbiorze była na

najwyższym poziomie. Użytkownicy również oczekują, żeby telewizja była

interaktywna i pozwalała na wybór żądanych treści.

W związku z szybkim rozwojem sieci IP, a chodzi tu przede wszystkim o

zwiększającą się przepustowość łączy do klientów, operatorzy zauważyli

możliwość oferowania usługi telewizji, na istniejącej już infrastrukturze..

Wykorzystując tą samą infrastrukturę co do usługi dostępu do Internetu,

operatorzy mają możliwość zmniejszenia swoich kosztów, a zarazem

możliwość dążenia do konwergencji usług.

Obecne rozwiązania IPTV, które są stosowane przez operatorów

telekomunikacyjnych są realizowane głównie w oparciu o technologię DSL,

jako sposób dostarczenia sygnału do klienta. Jest to podyktowane głownie

aspektem ekonomicznym. Istnieją inne rozwiązania, m.in. takie jak GPON,

które pozwala na przesyłanie danych w kierunku klienta do 2,5 Gb/s, ale

wymaga od operatora posiadania infrastruktury światłowodowej do klienta. Z

aspektu technicznego jest to lepsza technologia dla IPTV niż DSL, ze względu

na coraz większe wymagania odnośnie jakości obrazu a co za tym idzie,

wymagania większej przepustowości. Stawia jednak operatorów

telekomunikacyjnych przed koniecznością dokonania bilansu ekonomicznego

ponieważ wiąże się to ze znaczącym nakładem finansowym w przypadku

braku odpowiedniej infrastruktury. Natomiast rozwiązanie DSL jest od

jakiegoś czasu wykorzystywane do świadczenia usługi dostępu do Internetu

co pozwala operatorowi na ograniczenie CAPEX, związanego z IPTV.

Dostawcy takie rozwiązanie nazywają TVoDSL. Przy wykorzystaniu DSL i

Dwórznik Marek


sieci IP do przesyłania obrazu, należy rozpatrzyć wiele aspektów związanych

z odpowiednim skonfigurowaniem urządzeń. Należy zwrócić uwagę na

zapewnienie odpowiedniego priorytetu dla przesyłanego sygnału a także na

optymalny sposób przesyłania tej samej zawartości do wielu odbiorców. Nie

uwzględniając tych aspektów, przyczynilibyśmy się do szybkiego

wykorzystania dostępnej przepustowości a obraz byłby niemożliwy do

odebrania z powodu jego wrażliwości na opóźnienia (opis znajduje się w

rozdziale 8).

Ze względu na obszerność tematu jakim jest IPTV, postanowiłem, że w

mojej pracy dyplomowej zajmę się sposobem realizacji usługi na poziomie

warstwy sieci. Przedstawię aspekty związane z bezpieczeństwem, jakością

usług i optymalnego przesyłania sygnału telewizji cyfrowej poprzez sieć IP.

Dwórznik Marek


2 Cel i zakres pracy

Celem pracy jest przedstawienie sposobu dostarczania usługi telewizji

cyfrowej do użytkownika końcowego poprzez sieć IP. Realizacja rozwiązania

opiera się na technologii DSL w części sieci, terminującej połączenia klientów

a pozostała część sieci, wykorzystuje protokół Ethernet w celu transportu

treści multimedialnych od źródła. W pracy zostanie zaprezentowana

architektura IPTV, IP Multicast i jego implementacja na routerach. Zostanie

zaprezentowana konfiguracja protokołu routingu takiego jak PIM SSM oraz

protokołu zarządzającego żądaniami strumieni multicastowych IGMP. Praca

zostanie oparta na rozwiązaniu zrealizowanym przez firmę

telekomunikacyjną. Ze względu na fakt, że chciałbym pokazać w pracy

sposób przesyłania sygnału telewizji w sieci IP, większa część mojej pracy

dyplomowej będzie dotyczyła sposobu implementacji usługi na routerach.

Pozostałe składniki architektury systemu zostaną omówione mniej

szczegółowo, lecz bez wspomnienia o nich chociaż w ograniczonym zakresie,

niemożliwe byłoby zrozumienie i przedstawienie głównego celu pracy.

W pierwszym rozdziale chciałbym bliżej przybliżyć koncepcję telewizji

cyfrowej i obecne sposoby realizacji przesyłu sygnału przez sieć IP. Zostanie

dokładniej przedstawiona technologia IPTV, na której będzie się opierała

dalsza część mojej pracy magisterskiej. Zaprezentuję korzyści wynikające z

zastosowania tej technologii i jak się przedstawia rozwój tej usługi w

przyszłości.

W kolejnym rozdziale zostanie przedstawiona architektura IPTV, jaka

jest wykorzystywana przez operatorów telekomunikacyjnych do świadczenia

usługi telewizji dla swoich klientów. Z uwagi na fakt, że jest to całkiem nowa

technologia, postaram się dokładniej przedstawić niektóre elementy

prezentowane w architekturze systemu. W prezentowanym rozwiązaniu sieć

IP jest zbudowana w oparciu o routery CISCO 7606. Są to routery, które

producent specjalnie stworzył na potrzeby realizacji usług Triple Play.

Następne dwa rozdziały to przedstawienie sposobu przesyłania

strumieni wideo w sieci IP przy wykorzystaniu IP Multicast. Zostaną

zaprezentowane korzyści z zastosowania transmisji multicastowej zamiast

transmisji unicastowej. W tej części pracy przedstawię sposób implementacji

usługi na routerach Cisco. Zostaną bliżej omówione protokoły IGMP, PIM

SSM. W rozdziale zostanie zaprezentowana konfiguracja na routerach, która

została wykorzystana przez operatora telekomunikacyjnego do świadczenia

usługi telewizji dla klientów.

Kolejny rozdział zostanie poświęcony na zaprezentowanie technik

wykorzystywanych w celu zabezpieczenia sieci agregacyjnej przed różnymi

Dwórznik Marek


atakami od strony urządzeń klienckich. Zostanie przedstawiony sposób

konfiguracji na routerach Cisco takich funkcjonalności jak DAI, DHCP

snooping, uRPF.

Przedostatni rozdział dotyczył będzie sposobu zarządzania dostępem do

usługi telewizji cyfrowej opartej o sieć IP. Zostanie przedstawione

rozwiązanie, które wykorzystał operator telekomunikacyjny do komercyjnego

świadczenia usługi. Przedstawię interfejs umożliwiający biling usługi IPTV.

Ostatni rozdział chciałbym poświęcić zarządzaniu jakością usługi (QOS).

Ze względu na fakt, że transmisja wideo w sieci IP jest wrażliwa na

przeciążenia, opóźnienia i utraty pakietów, wymagane jest zagwarantowanie

odpowiedniego pasma i priorytetu dla tej usługi. Zostaną przedstawione

mechanizmy wykorzystywane do zapewnienia odpowiedniej jakości usługi w

sieci IP. Przedstawię sposób realizacji QOS na routerach CISCO i jak jest to

realizowane w praktyce.

Dwórznik Marek


3 Wprowadzenie

3.1 Telewizja cyfrowa

Telewizja jest od wielu dekad ważnym medium do komunikacji i

dostarczania rozrywki. Początkowo obraz był transmitowany w formie

analogowej. Nadejście ery układów scalonych i komputerów zapoczątkowało

cyfryzację obrazu i próby kompresji w celu przesyłania tego sygnału na

odległość. Kompresja wideo stała się ważnym obszarem badań w latach

1980 – 1990 i jest cały czas tematem badań w celu optymalizacji rozmiaru

danych reprezentujących sygnał wideo.

Telewizja cyfrowa może być przedstawiona jako reprezentacja metody

transmisji obrazu i dźwięku w postaci sygnału cyfrowego, składającego się z

0 i 1. W przeciwieństwie do telewizji analogowej, która używa do transmisji

kanałów telewizyjnych częstotliwości UHF lub VHF, programy telewizyjne są

skompresowane do strumieni wideo i są przesyłane w jednym strumieniu

danych. Takie rozwiązanie pozwala na znacznie większą ilość możliwych do

przesłania programów.

Do odebrania sygnału telewizji cyfrowej wymagany jest cyfrowy

odbiornik, którym może być cyfrowy telewizor lub odpowiedni dekoder (set-

top box). Sygnał cyfrowy wideo może być generowany np. za pomocą

kamery cyfrowej lub poprzez poddanie sygnału analogowego konwersji.

Przekształcenie do postaci cyfrowej wymaga procesu próbkowania

(samplingu) i kwantyzacji (quantization).

Sygnał w postaci cyfrowej, w przeciwieństwie do postaci analogowej,

ma możliwość wykorzystania technik kompresji w celu zmniejszenia

przepustowości wymaganej do transmisji i ograniczenie miejsca potrzebnego

na przechowywanie na nośnikach danych.

3.2 Technologie dostarczania obrazu w sieci IP

W tej części pracy chciałem przedstawić dwie główne technologie

dostarczania obrazu w sieci IP. Rozwiązania te ciągle są ulepszane i

realizowane równolegle do siebie. Jedną z tych technologii przedstawię

dokładniej w kolejnych rozdziałach.

Dwórznik Marek


3.2.1 IPTV

IPTV (Internet Protocol Television) jest szybko rozwijającą się

technologią, której za zadaniem jest dostarczanie telewizji i treści wideo dla

użytkowników końcowych.

Definicję IPTV możemy przedstawić jako „treści wideo, włączając w to

również telewizję, które są przesyłane przy wykorzystaniu protokołu IP”.[5]

IPTV odnosi się do IP jako mechanizmu transmisji w sieci Internet, która

reprezentuje publiczną sieć IP, jak również IPTV może wykorzystywać do

transmisji prywatną sieć IP.

IPTV powstała w celu oferowania usług takich samych jak w sieci

kablowej czy telewizji satelitarnej oraz usług przewyższających możliwości

tych rozwiązań. Główną dominującą cechą IPTV jest możliwość świadczenia

prawdziwych usług interaktywnych dla użytkownika. Jest to spowodowane

tym, że usługa została oparta o protokół IP.

Dostawcy usług, którzy chcą dostarczać do klientów rozwiązania triple

play, często wybierają technologię IP ponieważ pozwala na dostarczanie

telewizji, szybkiej transmisji danych i telefonu za pomocą jednej sieci

teleinformatycznej. Typowe rozwiązanie zbudowane jest na wydzielonej

prywatnej sieci IP o wysokiej przepustowości, gdzie telewizja jest

dostarczana równocześnie do tysięcy odbiorców.[1]

IPTV dostarcza do odbiorcy programy telewizyjne w czasie

rzeczywistym. Zazwyczaj dostawcami treści są źródła takie same jak dla

telewizji satelitarnej czy telewizji kablowej. W Polsce są to np. firmy takie jak

Cyfra+ lub TP Emitel. Treści takie są kodowane i przygotowywane do

transmisji w sieci IP w tzw. Head-end. Jest to element systemu IPTV, gdzie

sygnał jest przekształcany w czasie rzeczywistym do postaci możliwej do

przesłania do odbiorcy poprzez sieć IP.

3.2.2 Internet TV

Technologia Internet TV jest obok IPTV drugą szybko rozwijającą się

usługą.[1] Ten system możemy podzielić na dwie sekcje funkcjonalne:

produkcyjną i dystrybucyjną. W części produkcyjnej jest wykonywana

obróbka treści wideo pozyskiwanych np. z kamery. W tym miejscu dane są

zamieniane na postać cyfrową, dokonywana jest kompresja, modyfikacja a

następnie w postaci plików, dane są zapisywane na serwerze, skąd są

udostępniane w celu pobrania przez użytkownika. W części dystrybucyjnej są

odbiorcy, którzy za pomocą dostępu do Internetu łączą się z serwerem w

celu pobrania plików lub żądania strumienia wideo. Odbiornikiem jest

komputer PC z zainstalowanym odpowiednim oprogramowaniem. Na rysunku

Dwórznik Marek


2 został przedstawiony uproszczony schemat Internet TV w celu lepszego

zobrazowania tej technologii.

Rysunek 1 Uproszczony schemat sieci dla Internet TV[1]

W tej technologii użytkownik chcąc oglądać daną treść wideo musi znać

adres docelowy serwera wraz ze ścieżką do pliku. Najczęściej odnośniki

znajdują się na stronach internetowych różnych serwisów. Użytkownik

klikając na wybrany link jest łączony z odpowiednim serwerem gdzie

ustanawiana jest sesja pomiędzy aplikacją odbiorcy a serwerem. Zawartość

jest pobierana w całości na komputer klienta lub jest buforowana tylko cześć

danych w zależności od konfiguracji aplikacji po stronie klienta.

3.3 Korzyści wykorzystania sieci IP

W przeciwieństwie do obecnych rozwiązań dostarczania telewizji do

odbiorców, protokół IP i sieci oparte na tej technologii dają wiele korzyści w

dostarczaniu usług wideo. Spowodowało to, że usługi IPTV czy Internet TV

rozwijają się w bardzo szybkim tempie. Za tak szybkim rozwojem

przemawiają następujące argumenty:

Możliwość osiągnięcia prawdziwej interaktywności z odbiorcą, którą

umożliwia zastosowanie protokołu IP

Bogata infrastruktura szerokopasmowej sieci IP, która dociera do

wielkiej liczby gospodarstw domowych. Dzięki temu dostawcy usług

nie muszą budować dodatkowej sieci.

Dzięki interaktywności dostawca może lepiej poznać potrzeby

klientów i w ten sposób precyzyjniej dostosować ofertę.

Sieci IP są doskonałą technologią dla wielu innych usług takich jak

szybka transmisja danych, telefonia IP

Dwórznik Marek


Liczba klientów coraz szybszego Internetu ciągle rośnie, co

umożliwi świadczenie usługi HDTV do coraz większej liczby

użytkowników

Protokół IP jest wykorzystywany w wielu technologiach takich jak:

Ethernet LAN, bezprzewodowa sieć Wi-Fi, czy sieć komórkowa

3.4 Przyszłość IPTV

Rozwój usługi IPTV jest ściśle związany ze wzrostem liczby i

przepustowości szerokopasmowego dostępu do Internetu. Obecnie ze

względu na coraz większą konkurencję w świadczeniu usług dostępu do

Internetu, dostawcy usług chcąc uatrakcyjnić swoją ofertę, zwiększają

przepustowość oferowanych usług. Daje to możliwość oferowania usługi IPTV

bez ponoszenia dodatkowych kosztów związanych z dostarczaniem łącza do

klienta tylko pod usługę telewizji. Takie rozwiązanie daje nie tylko korzyści

finansowe dla operatora ale również dla klienta. Kupując usługi w pakiecie

triple play oferta cenowa jest bardziej atrakcyjna w porównaniu do usług,

które musimy kupować oddzielnie.

IPTV ma możliwość oferowania usług, które były do tej pory nie możliwe

do zrealizowania w oparciu o telewizję naziemną, kablową czy satelitarną. Ta

technologia pozwala na oferowanie znacznie większej ilości programów, daje

możliwość udostępnienia różnorodnych rodzajów treści do wszystkich

odbiorców lub do wyspecjalizowanej grupy. W przeciwieństwie do

tradycyjnej telewizji, gdzie wszystkie programy są równocześnie przesyłane

do odbiorcy, IPTV dostarcza tylko te programy, które są obecnie oglądane

przez użytkownika. Ze względu na fakt, że ta technologia jest oparta o

protokół IP, daje możliwość interakcji. Pozwala to użytkownikowi na

kontrolę tego co chce oglądać.

We wrześniu 2006 firma France Telecom miała ponad 420,000 klientów

usługi IPTV.[1] Jak widać na rysunku 2, w przeciągu dwóch lat liczba

klientów wzrosła kilkukrotnie, co obrazuje nam i daje możliwość prognozy,

że w kolejnych latach usługa powinna cieszyć się dużym zainteresowaniem.

Dwórznik Marek


Rysunek 2 Wzrost liczby klientów IPTV we France Telecom w latach 2004 –

2006.[1]

Telekomunikacja Polska S.A. rozpoczęła świadczenie usługi IPTV pod

nazwą wideostrada TP. Testy usługi rozpoczęły się w pierwszym kwartale

2006 a pod koniec roku zaczęto sprzedawać usługę klientom. Jak widać na

rysunku 3, usługa IPTV również cieszy się znacznym dobrym powodzeniem

na rynku polskim. Widząc wynik w ostatnim kwartale 2007, który jest

zbliżony do wyników z France Telecom w grudniu 2004, można

przypuszczać, że również w Polsce usługa IPTV odniesie podobny sukces.

Liczba klientów usług telewizji internetowej (w tys.)

0

5

10

15

20

25

30

35

40

45

1 kw.

2006

2 kw.

2006

3 kw.

2006

4 kw.

2006

1 kw.

2007

2 kw.

2007

3 kw.

2007

4 kw.

2007

Rysunek 3 Wykres pokazujący przyrost liczby klientów wideostrady TP [20]

Dwórznik Marek


4 Architektura systemu IPTV

Architektura IPTV składa się z wielu funkcjonalnych elementów, lecz

występuje kilka standardów dotyczących implementacji usługi telewizji

rozsiewczej czy telewizji na żądanie. Sposoby realizacji tego rozwiązania

różnią się w zależności od producenta komponentów i środowiska w jakim

ma zostać zaimplementowane rozwiązanie. Jednak istnieją główne

komponenty, które możemy wyróżnić w architekturze bez względu na

sposób implementacji. [3]

Podstawowe elementy systemu:

SHE (Super Head End)

VHO (Video Head End Office)

VSO (Video Serving Office lub Video Switching Office)

LEO (Local End Office)

Super Head End jest podstawowym źródłem dostarczania programów

telewizyjnych dla systemu. Ten funkcjonalny składnik odpowiedzialny jest za

gromadzenie programów telewizyjnych otrzymywanych od dostawców treści,

konwertowanie ich do odpowiedniej postaci dla IPTV i transmisję tej

zawartości do VSO. W większości przypadków w tym miejscu znajduje się

serwer zarządzający usługą dla wszystkich użytkowników.

Video Head End Office jest miejscem gdzie znajdują się serwery usługi

wideo na żądanie. Znajdują się tu również kodery czasu rzeczywistego dla

lokalnej telewizji. Zazwyczaj VHO jest w każdej większej metropolii, gdzie

jest świadczona usługa dla przedziału od 100,000 do 1,000,000 gospodarstw

domowych.[3]

Video Switching Office jest miejscem gdzie są agregowane łącza do

DSLAM. Znajduje się tutaj router, który dostarcza sygnał telewizji i wideo na

żądanie do DSLAM. Czasami się zdarza, że znajdują się tutaj serwery VOD i

streamery dla telewizji lokalnej.

Local End Office zawiera urządzenia potrzebne do dostarczenia usługi do

klienta. W prezentowanej przeze mnie pracy jest to DSLAM (w lokalizacji

usługodawcy) i modem DSL (zlokalizowany u klienta).

Dwórznik Marek


Rysunek 4 Uproszczony schemat sieci IPTV[1]

Rysunek 4 przedstawia uproszczony schemat systemu IPTV. Super Head

End, Video Serving Office i Local End Office są łączone za pomocą sieci IP o

wysokiej przepustowości. W pętli lokalnej jako protokół warstwy 1 został

wykorzystany DSL. Wyposażenie abonenckie wymagane do odbioru telewizji

to modem DSL i STB. Ten rodzaj technologii przesyłania obrazu zostanie

opisany w dalszej części pracy.

Dwórznik Marek


Rysunek 5 Architektura IPTV zaprezentowana prze firmę Cisco.[3]

Na rysunku 5 została przedstawiona architektura transportowa usługi

IPTV, którą zaprezentowała firma Cisco. Została tu dokładnie pokazana

struktura sieci, gdzie widzimy podział na warstwę dostępową, agregacyjną i

dystrybucyjną. Każda warstwa to logiczny podział sieci na części, które

pozwalają na hierarchiczne zaprojektowanie rozwiązania. Warstwa

dostępowa w tym przykładzie to technologia DSL, która pozwala na

podłączenie urządzeń klienckich jak HAG i STB. Warstwa agregacyjna

pozwala na podłączanie wielu DSLAM do jednego routera sieci IP. Router w

tej warstwie nazywany jest routerem agregacyjnym. Gromadzi połączenia z

wielu DSLAM, z jednej metropolii. Ilość takich routerów w danej lokalizacji

zależy od ilości agregowanych DSLAM. Warstwa dystrybucyjna zawiera

urządzenia sieci, które odpowiedzialne są za przesyłanie danych ze źródeł

jak HE czy SPF do routerów warstwy agregacyjnej. W zależności od

implementacji wykorzystuje się sieć szkieletową IP/MPLS do połączeń

pomiędzy routerami warstwy dystrybucyjnej lub łącza bezpośrednie , które

zazwyczaj mają pojemność n x 10 GE/s. Firma telekomunikacyjna, na której

rozwiązaniu opieram się w mojej pracy, stosuje właśnie linki bezpośrednie a

jako routery agregacyjne i dystrybucyjne wykorzystuje Cisco 7600. W

kolejnych rozdziałach zostanie przedstawiona odpowiednia konfiguracja sieci

transportowej dla usługi IPTV na tych urządzeniach.

Rysunek 6 przedstawia architekturę funkcjonalną usługi IPTV, która

pokazuje złożoność całego systemu. Główne części to:

Dwórznik Marek


platforma usługowa

dostawcy treści

sieć transportowa

system informacyjny

Ze względu na obszerność tematu w dalszej części pracy skupię się

tylko na warstwie sieci.

Dwórznik Marek


Rysunek 6 Architektura funkcjonalna IPTV zaprezentowana przez firmę

Sofrecom.[32]

Dwórznik Marek


4.1 Aspekt funkcjonalny sieci dla IPTV

Funkcją sieci dla technologii IPTV jest transport różnego rodzaju treści

pomiędzy komponentami tej usługi: programów TV ze stacji czołowej (head

end) do dekoderów (Set-Top-Box), treści video z platformy usług do

serwerów VOD itd. W sieci dla usługi IPTV musi być zapewniona odpowiednia

jakość przesyłania sygnału (Quality Of Service) tzn., że różne strumienie

treści muszą docierać do odpowiednich miejsc w odpowiednim czasie, z

odpowiednim zapewnieniem kompletności tych danych. Dla utrzymania

usługi na odpowiednim poziomie musi być również zapewnione odpowiednie

zabezpieczenie sieci przed różnymi atakami jak Denial Of Service, Spoofing

itd. Dokładniej QOS zostanie wytłumaczony w ostatnim rozdziale mojej

pracy natomiast bezpieczeństwo sieci w rozdziale „Mechanizmy

bezpieczeństwa w IPTV”.

4.1.1 TVoDSL – opis transportu treści

Najbardziej popularną obecnie usługą IPTV jest rozwiązanie oparte na

dostarczaniu sygnału do klienta poprzez wykorzystanie koncentratorów

DSLAM. Operatorzy telekomunikacyjni nazwali takie rozwiązanie TV over

DSL i takim rozwiązaniu opiera się moja praca dyplomowa.

W usłudze TVoDSL występują różne rodzaje ruchu przesyłanego w sieci

transportowej:

Zarządzanie pomiędzy platformą usługową a STB lub serwerami VOD

Treści programów telewizyjnych pomiędzy stacją czołową (Head End) a

dekoderem (STB)

Treści VOD (telewizji na żądanie) pomiędzy serwerami VOD a

dekoderem (STB)

Treści wideo pomiędzy platformą usługową a serwerami VOD w celu

zaopatrzenia serwerów w odpowiednie zasoby

Ruch zarządzający przełączaniem programów pomiędzy DSLAM a STB

Treści programów telewizyjnych są przesyłane w postaci transmisji

multicastowej do ruterów brzegowych sieci dystrybucyjnej. Do ruterów

brzegowych są przesyłane wszystkie możliwe programy a następnie na

podstawie żądań z STB są przesyłane tylko wybrane kanały.

Ruch związany z przełączaniem programów występuje wtedy gdy

użytkownik chce zmienić oglądany program na inny. Transmisja taka

występuje pomiędzy STB a DSLAM lub STB a przełącznikiem, do którego jest

podłączony DSLAM. Dekoder wysyła wiadomość IGMP z adresem

multicastowym żądanego programu.

Dwórznik Marek


Na ruch zarządzający (STB-SPF) pomiędzy STB a platformą usługową

składa się kilka różnych protokołów:

DHCP umożliwiający pobranie odpowiednich parametrów sieciowych

dla STB (opis protokołu RFC 2131)

SNMP dla celów zarządzania urządzeniem STB (opis protokołu RFC

1157)

NTP w celu synchronizacji czasu na STB (opis protokołu RFC 958)

TFTP dla celów aktualizacji oprogramowania STB (opis protokołu RFC

1350)

HTTP dla portalu webowego umożliwiającego użytkownikowi dostęp do

usługi (opis protokołu RFC 2616)

RTSP w celu kontroli treści wideo dla usługi VOD (opis protokołu RFC

2326)

Ruch STB-SPF przesyłany jest w postaci transmisji unicastowej jak

przedstawia to Rysunek 7.

Dwórznik Marek


Rysunek 7 Transmisja unicast pomiędzy platformą a STB związany z zarządzaniem

usługą

4.2 Sieć dostępowa

Na elementy sieci dostępowej dla usługi IPTV, która jest prezentowana

w mojej pracy składają się:

DSLAM

Modem DSL (HAG)

Dwórznik Marek


STB

DSL (Digital Subscriber Lines) to technologia, która pozwala na

dostarczanie usług szerokopasmowych za pomocą jednej lub dwóch par

skrętki telefonicznej. Powstała w celu umożliwienia operatorom

posiadającym rozwinięta infrastrukturę telefoniczną, na świadczenie usługi

dostępu do Internetu o wysokiej przepustowości. [1]

Rysunek 8 Schemat obrazujący technologię DSL

Technologia DSL jest jedną z możliwych technik dostarczenia do klienta

usługi IPTV. W niedalekiej przyszłości, zostanie jednak wypierana przez

rozwiązania oparte na światłowodach, ze względu na coraz większe

zapotrzebowanie na pasmo. Obecnie większość kanałów telewizyjnych jest

przesyłana w jakości SDTV, które w kompresji MPEG-2 potrzebują pasma od

2 do 6 Mb/s. Takie wymagania potrafi sprostać właśnie technologia ADSL.

Obecnie występuje ulepszony standard ADSL2+. Pozwala on na przesyłanie

do klienta danych z prędkością nawet do 24 Mb/s. Jednak taką prędkość

możemy uzyskać na dość krótkim dystansie. W Tabela 1 zostały

przedstawione parametry technologii DSL najczęściej stosowanych przez

dostawców usług.

Tabela 1 Wykaz parametrów dla różnych technologii DSL

ADSL ADSL2 ADSL2+ VDSL

Downstream Data Rate

(z DSLAM do klienta) Max. 8 Mb/s Max. 12 Mb/s Max. 24 Mb/s Max. 52 Mb/s

Upstream Date Rate

(od klienta do DSLAM)

Max. 640

kb/s Max. 1Mb/s Max. 2 Mb/s Max. 6 Mb/s

Odległość Max. 5,5 km Max. 3,7 km Max. 2,7 km Max. 300 m

Standardy (ITU) G 992.1,

G 992.2

G 992.3,

G.994 G 992.5 H.610-H.619

Dwórznik Marek


4.2.1 DSLAM

W celu świadczenia usługi IPTV z wykorzystaniem technologii DSL

wykorzystuje się tzw. IP DSLAM-y. Wspierają one takie usługi jak IGMP

Proxy, IGMP snooping, czy DHCP relay, które umożliwiają implementację

IPTV. [7] W stronę sieci agregacyjnej najczęściej stosuje się Interfejsy

optyczne GigabitEthernet.

Dla świadczenia usługi IPTV, w sieci dostępowej opartej o DSLAM

stosuje się model N:1 VLAN, który został zaprezentowany na DSL Forum -

TR-101 - Migration to Ethernet-Based DSL Aggregation.[30] Jest to schemat

mapowania jeden-do-wielu pomiędzy portami użytkowników a danym VLAN.

Każdy N:1 VLAN na DSLAM jest oddzielną instancją tzw. Virtual Brigde (VB).

Ruch związany z VLAN-ami usługowymi jest przenoszony pomiędzy routerem

agregującym a DSLAM za pomocą połączenia typu trunk gdzie

wykorzystywane są protokoły 802.1q (IEEE Standard P802.1Q IEEE

Standards for Local and Metropolitan Area Networks: Virtual Bridged Local

Area Networks) i 802.1p (IEEE 802.1 P,Q - QoS on the MAC level). Do danej

instancji VB przypisywane są porty klienckie, które mają korzystać z danej

usługi (w tym przypadku BTV). Od strony klienckiej wykorzystuje się tzw.

architekturę multi-vc, gdzie dany vc przypisuje się do danej instancji VB. W

ten sposób, w stronę HAG od DSLAM, ruch związany z BTV, VOD, Internet,

jest postrzegany jako różne VC w ATM. Takie rozwiązanie jest stosowane

miedzy innymi dlatego, żeby była możliwość priorytetyzacji ruchu na łączu

klienckim, co zostało dokładniej wyjaśnione w ostatnim rozdziale dotyczącym

QOS.

DSLAM na swoim interfejsie Ethernet wystawia w kierunku sieci

agregacyjnej swoje VLANy usługowe. Są to takie VLANy, które pozwalają

logicznie rozdzielić ruch związany z danymi usługami BTV, VoD, Internet

Access. Router otrzymując ruch w różnych VLAN-ach, ma możliwość

rozróżnienia poszczególnych usług zapewniając im odpowiednią obsługę w

sieci , dla ruchu typu multicast (BTV), unicast (VOD i ruch STB-SPF), jak

również tunelowanie L2 (jest to rozwiązanie pozwalające na emulację

switcha warstwy 2 w sieci MPLS, stosowane do przenoszenia ruchu np. do

Internetu) itp. Rysunek 9 przedstawia w sposób poglądowy realizację

połączenia pomiędzy DSLAM a routerem agregującym.

Dwórznik Marek


Rysunek 9 Realizacja styku L2 pomiędzy DSLAM a routerem

DSLAM, jak wspomniano na początku podrozdziału, pełni rolę agenta

DHCP Relay. Ta funkcjonalność jest wykorzystywana w przypadku gdy klient

i serwer DHCP znajdują się w różnych podsieciach. Agent DHCP Relay

pośredniczy w wymianie komunikatów pomiędzy nimi. W rozwiązaniu IPTV

prezentowanym w mojej pracy, w celu zabezpieczenia przed atakami

związanymi z DHCP i lepszej skalowalności rozwiązania, zastosowano funkcję

DHCP Relay Agent Information Option (RFC 3046). Jest to opcja, która ma

numer 82. Pozwala na jednoznaczne określenie użytkownika, od którego

przyszedł DHCP request. W ten sposób DSLAM ma informacje, na jaki

dokładnie port i kanał VC ma przesłać odpowiedź od serwera DHCP co

eliminuje możliwość podsłuchiwania transmisji przez innych użytkowników.

DHCP Relay Agent Information Option jest kontenerem dla

przenoszenia informacji zawartych w pod polach. Tabela 2 przedstawia jego

format. Liczba N to wielkość w bajtach określająca wielkość kontenera.

Liczba jest sumą wszystkich zawartych podpól, których format przedstawia

Tabela 3. Każde pod pole składa się z sekwencji numer pod

pola/długość/wartość.

Tabela 2 Format pola opcji 82 dla DHCP relay[39]

Code Len Agent Information Field

82 N i1 i2 i3 i4 ... iN

Tabela 3 Format podpola dla opcji 82[39]

SubOpt Len Sub-option value

1 N s1 s2 s3 s4 ... sN

2 N i1 i2 i3 i4 ... iN

Dwórznik Marek


Domyślnie są już zdefiniowane dwa pod pola, które zostały

przeznaczone do przenoszenia informacji o identyfikatorze obwodu i

identyfikatorze agenta DHCP relay. Identyfikator obwodu pozwala na

przesłanie informacji do DHCP serwera o lokalizacji użytkownika, od którego

przyszło żądanie DHCP.

Tabela 4 Opis przeznaczenia pod pól w opcji 82.[39]

DHCP

Sub-option

Code

Description

1

2

Agent Circuit ID

Agent Remote ID

W celu załączenia Circuit id do DHCP request, DSLAM musi mieć

zdolność do automatycznego załączania unikatowego identyfikatora pętli

lokalnej dla każdego użytkownika. Domyślnie dla DSLAM format Circuit id

wygląda następująco: “Identyfikator_DSLAM atm slot/port:vpi.vci”. Operator

może jednak ustawić ten parametr manualnie dla każdego portu na DSLAM

w celu lepszego dostosowania do funkcjonalności platformy. W

prezentowanym przeze mnie rozwiązaniu operator telekomunikacyjny przyjął

schemat jak w Tabela 5.

Tabela 5 Schemat Circuit ID dla DSLAM

Przykład: 000A.0A.14.9F#2#16/72:8.38#489

Circuit ID = identyfikator_DSLAMa#n1#n2/n3:n4.n5#vc

gdzie:

identyfikator_DSLAM – ciąg znaków identyfikujący DSLAM : adres IP (10.10.20.151)w

wersji heksadecymalnej uzupełniony na dwóch początkowych pozycjach o wartość 00;

długość identyfikatora wynosi 13 znaków.

n1 – zmienna identyfikująca numer półki, w której umieszczony jest DSLAM w danej

lokalizacji; długość zmiennej n1 nie może przekroczyć 1 znaku

n2 – zmienna identyfikująca numer slotu na DSLAMie, w którym znajduje się karta

liniowa; długość zmiennej n2 nie może przekroczyć 2 znaków

n3 – zmienna identyfikująca dany port na karcie liniowej; długość zmiennej n3 nie może

przekroczyć 2 znaków

n4 – zmienna identyfikująca VPI dla terminowanego połączenia dla VoD; maksymalna

długość zmiennej n4 – 1 znak

n5 – zmienna identyfikująca VCI dla terminowanego połączenia dla VoD; maksymalna

długość zmiennej n4 – 2 znaki

vc – zmienna wyliczana ze wzoru przedstawionego poniżej (maksymalna długość zmiennej

– 4 znaki):

Dwórznik Marek


dla n2 <=7 vc = (n2 - 1) * 72 + n3 +1

dla n2 >=10 vc = (n2 - 3) * 72 + n3 +1

W rozwiązaniu, które zaimplementował operator, identyfikator został

zarejestrowany na platformie co umożliwiło przypisanie odpowiedniej puli

adresów możliwych do przydzielenia użytkownikom danego DSLAM. Circuit

ID przez operatorów nazywany jest również jako CLID (Client ID).

4.2.2 Set-top-boxes

Głównym zadaniem STB jest konwersja odebranego sygnału IPTV.

Odbierany sygnał jest w postaci pakietów IP i jest przekształcany w sygnał

wideo możliwy do odebrania przez odbiornik telewizyjny.

Set-top-box zawiera następujące funkcjonalne elementy:

Interfejs sieciowy – służy do odbierania strumieni video i wysyłania

komend użytkownika do platformy.

Wyjścia wideo i audio – umożliwiają podłączenie telewizora i

zestawu głośników

Interfejs użytkownika – daje możliwość użytkownikowi na

sterowanie set-top-boxem na pomocą pilota lub przycisków na

przednim panelu urządzenia.

Identyfikacja STB w systemie IPTV

W prezentowanym przeze mnie rozwiązaniu, STB jest identyfikowany

w systemie IPTV poprzez numer seryjny urządzenia. Informacja ta jest

przesyłana do SPF w parametrach sieciowych protokołu DHCP (DHCP

request).

Proces identyfikacji:

Pierwsze podłączenie STB

o STB wysyła komunikat typu DHCP request do SPF z

parametrami sieciowymi gdzie jest zawarty numer seryjny

urządzenia. Platforma tworzy w bazie danych nowy wpis o

danym terminalu gdzie zapisuje numer seryjny urządzenia.

o Użytkownik podaje loguje się na prezentowanej na ekranie

stronie podając nazwę użytkownika i hasło

o Plik cookie jest tworzony na STB w celu automatycznego

uwierzytelniania przy kolejnym podłączeniu urządzenia

o Jeśli uwierzytelnianie się udało STB jest gotowy do

korzystania z usługi

Kolejne podłączenie STB

Dwórznik Marek


o Urządzenie wysyła komunikat DHCP request jak w

poprzednim przypadku w celu pobrania odpowiednich

parametrów sieciowych

o STB korzysta z zapisanego pliku cookie w celu

automatycznego uwierzytelnienia

STB posiada wbudowaną przeglądarkę www, która pozwala na dostęp

do portalu znajdującego się na platformie. Po zalogowaniu się do platformy,

gdy użytkownik chce oglądać telewizję, zostaje pobrany:

GUI – Graficzny interfejs użytkownika, pozwalający na wybór

programu

Spis programów zawierający:

o Id kanału

o Nazwę kanału

o Multicastowy adres IP programu

Informacje EPG – elektroniczny informator programowy

W celu eliminacji dużej ilości zapytań do platformy, powyższe

informacje są pobierane do STB i lokalnie przetrzymywane w pamięci

urządzenia. Po tej operacji STB używa lokalnie zapisanych danych a

aktualizacja odbywa się co jakiś odstęp czasu.

Rysunek 10 przedstawia mozaikę programów, która ukazuje się

użytkownikowi po wybraniu opcji oglądania telewizji.

Dwórznik Marek


Rysunek 10 Strona przedstawiająca mozaikę umożliwiającą wybór programu

telewizyjnego.[36]

Mozaika jest animowaną tabelą dostępnych programów. Dla każdego

programu konkretna komórka w tabeli pokazuje aktualną jego zawartość.

Użytkownik może za pomocą pilota poruszać się po kolejnych komórkach i

wybrać program, który chce oglądać.

Rysunek 11 przedstawia proces inicjujący oglądanie danego programu

telewizyjnego.

Dwórznik Marek


Rysunek 11 Proces inicjujący oglądanie programu telewizyjnego.[36]

Kolejne kroki prezentowanego procesu:

[1] Użytkownik może wybrać program za pomocą udostępnionego

portalu przy pomocy protokołu http. Jak zostało wspomniane wcześniej,

komunikacja z platformą odbywa się tylko za pierwszym razem. Przy

kolejnej próbie STB korzysta z lokalnie zapisanych informacji

[2] Przy pierwszym połączeniu STB, platforma dostarcza wszystkie

adresy multicastowe dostępnych programów telewizyjnych.

[3] STB wysyła żądanie do sieci żądanie odpowiedniej grupy

multicastowej

[4] W zależności czy dany strumień multicastowy jest już odbierany

przez dany DSLAM lub nie, następuje replikacja strumienia lub wysłanie

żądania do źródła.

4.3 Sieć agregacyjna

Sieć agregacyjna w rozwiązaniu IPTV jest nazywana Video Switching

Office. Znajdują się tu rutery, których zadaniem jest agregowanie ruchu z

lokalnie i zdalnie umieszczonych DSLAM.

Dwórznik Marek


Content Manager

BTV Source

AR

DR

AR

AR

10GE

10GE10GE

10GE1GE

1GE

Rysunek 12 Architektura fizyczna sieci dla IPTV

W sieci agregacyjnej dla IPTV router wspiera protokoły dla transmisji

unicast jak i multicast.

Pomiędzy DSLAM a routerem agregującym wykorzystuje się połączenia

Gigabit Ethernet, na których ruch przenoszony jest w odpowiednich VLAN-

ach. Routery łączy się przy wykorzystaniu 10 Gigabit Ethernet lub ich

wielokrotności gdzie interfejsy pracują w trybie L3 w przeciwieństwie do

połączeń DSALM-router gdzie jest to L2.

Od strony routera agregującego, ruch związany z usługą BTV jest

postrzegany jako VLAN lub kilka VLANów, w których przesyłane są

komunikaty IGMP związane z zapotrzebowaniem na poszczególne grupy

multicastowe (kanały) oferowane przez platformę BTV. Zadaniem sieci

agregującej jest dostarczenie strumieni multicastowych do DSLAMa, na które

zgłoszone zostało zapotrzebowanie. Router pełni funkcję igmp-querier.

Komunikacja igmp jest terminowana na interfejsie logicznym, z którego

odebrano komunikat igmp. DSLAM wspiera funkcjonalność igmv2-snooping,

która przesyła niezmodyfikowane komunikaty igmpv2 od klienta do routera.

Do dystrybucji strumieni multicastowych w ramach sieci agregacyjnej

wykorzystuje się protokół PIM SSM. Wspomniane powyżej protokoły zostały

dokładniej opisane w podrozdziale 6.1 i 6.2.

Dwórznik Marek


4.3.1 Wymagania przepustowości sieci dla IPTV

Wielkość przepustowości, którą sieć musi być zdolna transportować dla

wspierania usług wideo, jest zazwyczaj większa niż wymagana dla usług

takich jak głos lub dostęp do Internetu. Typowy strumień wideo SDTV, który

jest przenoszony jako MPEG-2 SPTS (Single program transport stream) z

nagłówkiem RTP, używa około 3,75 Mb/s pasma, a strumień HDTV (ta sama

kompresja i nagłówek) potrzebuje od 16 do 18 Mb/s pasma. Rodzaje

transmisji strumieni wideo dla usługi IPTV, jakie występują w sieci to:

unicastowa dla VOD i multicastowa dla BTV. Wymagania przepustowości dla

strumieni VOD są większe niż dla BTV. Jest to związane z tym, że wielkość

transmisji dla multicast zależy od liczby udostępnionych kanałów

telewizyjnych, a dla transmisji unicastowej zależy od ilości użytkowników.

Przy projektowaniu wymaganej pojemności sieci uwzględnia się zatem, że

pojemność łączy powinna być przynajmniej jak sumaryczna przepustowość

wszystkich dostępnych kanałów BTV, plus maksymalna szacunkowa ilość

oglądanych strumieni VOD w danym momencie. [3]

Dwórznik Marek


5 Przesyłanie strumieni wideo w sieci IP

W celu przesyłania strumieni wideo w sieci IP, wykorzystuje się

najczęściej technologię IP Multicast. Ze względu na fakt, że pliki

multimedialne potrzebują dużej pojemności łączy, jest to metoda na

optymalne wykorzystanie zasobów sieciowych. W kolejnych podrozdziałach

postaram się przybliżyć tą technologię oraz inne aspekty związane z

transmisją wideo.

5.1 IP Multicast

IP Multicast jest technologią pozwalającą na optymalne przesyłanie

danych w celu oszczędności dostępnej przepustowości w sieci IP. Polega na

redukcji ruchu poprzez przesyłanie jednego strumienia danych, równocześnie

do wielu odbiorców. IP Multicast jest drogą do efektywnego wykorzystania

zasobów sieciowych. Technologia ta jest wykorzystywana szczególnie tam,

gdzie występują usługi intensywnie wykorzystujące przepustowość takie jak

transmisja dźwięku i obrazu.[9]

W celu przedstawienia różnic pomiędzy standardową transmisją unicast

a wykorzystaniem multicastingu, poniżej zaprezentowałem dwa rozwiązania.

W przypadku zastosowania transmisji, którą widzimy Rysunek 13, dostawca

treści potrzebowałby wysłać tyle razy dany program, ilu odbiorców zgłosiło

zapotrzebowanie. Przy ilości np. 10 tyś. klientów, gdzie jeden strumień video

ma 3,5 Mb/s, wymagana przepustowość łącza pomiędzy head-end a ruterem

brzegowym byłaby 35 Gb/s. Taka sytuacja spowodowałaby duże nakłady

finansowe związane z rozbudową przeustowości łączy pomiędzy węzłami.

Mogłoby to doprowadzić do nieopłacalności przedsięwzięcia. Dlatego też do

przesyłania strumieni wideo wykorzystuje się transmisję multicastową

(przykład Rysunek 14). W takim rozwiązaniu obciążenie sieci nie zależy od

ilości odbiorców a jedynie od ilości dostępnych i oglądanych programów

telewizyjnych.

Dwórznik Marek


Rysunek 13 Transmisja danych typu unicast

Rysunek 14 Transmisja danych typu multicast

Źródła transmisji multicastowej wysyłają jedną kopię danych używając

jednego adresu dla całej grupy odbiorców. Ruter znajdujący się pomiędzy

źródłem a odbiorcami wyznacza trasę przesyłania danych na podstawie

adresu grupy multicastowej (pakiety multicastowe są przesyłane do tzw.

grupy multicastowej). Grupa multicastowa określa zbiór odbiorców, którzy są

zainteresowani otrzymywaniem określonego strumienia danych i jest

reprezentowana przez specyficzną pulę adresów IP.[22]

Do realizacji transmisji multicastowej poprzez sieć, wykorzystuje się

odpowiednie protokoły. W kolejnych podrozdziałach zostaną przedstawione

niektóre z nich.

5.1.1 Sposoby dostarczania danych w IP Multicast

Sposoby dostarczania danych w IP Multicast, różnią się tylko od strony

odbiorców. Serwer danych zawsze wysyła pakiet multicastowy, gdzie

źródłem jest jego adres IP a jako adres docelowy jest zamieszczany adres

grupy multicastowej. Możemy wyróżnić dwa tryby dostarczania danych:[9]

Dwórznik Marek


ASM (Any Source Multicast) – W tym trybie odbiorcy, wysyłają

żądanie tylko z informacją o grupie multicastowej, do której chcą

się podłączyć. Brak jest informacji o adresie źródła, co oznacza, że

ruch będzie odbierany ze wszystkich źródeł, które wysyłają dane do

żądanej grupy. Taki stan mógłby spowodować nieoczekiwane

obciążenie sieci i nieprawidłowe działanie aplikacji po stronie

odbiorcy. Dlatego też, ASM wymaga, żeby dana grupa

multicastowa była wykorzystywana tylko przez jedno źródło.

SSM (Source Specific Multicast) - W tym trybie odbiorcy,

wysyłają żądanie, w którym jest informacja o grupie multicastowej

i adresie źródła dla tej grupy. Rezultatem tego jest sytuacja, gdzie

odbiorca wybiera konkretne źródło, z którego chce otrzymywać

dane. W przeciwieństwie do ASM, ten tryb pozwala na

wykorzystywanie danej grupy multicastowej przez wiele źródeł.

Tryb SSM, poprzez swoją skalowalność jest często wybierany przez

dostawców do świadczenia usługi telewizji cyfrowej w oparciu o sieć IP. To

rozwiązanie daje dla sieci następujące korzyści:[8]

Zwiększenie bezpieczeństwa – Sieć jest bardziej bezpieczna

ponieważ zostaje wprowadzone zabezpieczenie przed nieuczciwymi

źródłami, które próbują wysyłać do grup multicastowych swoją

zawartość. Zabezpiecza również przed atakami Denial of Service

dla odbiorców, którzy w danej chwili oglądają telewizję

Łatwe zarządzanie i instalacja – Sieć nie potrzebuje utrzymywać

stanu aktywnych źródeł, co powoduje łatwą wymianę serwerów

wideo. Jest to bardzo użyteczne w sieciach, które się szybko

rozwijają i jest potrzeba częstych modyfikacji serwerów.

5.1.2 Adresacja dla IP Multicast a programy w IPTV

Do adresacji pakietów w transmisji multicastowej, wykorzystuje się

odpowiednie pule adresów IPv4. Do tego celu została dedykowana pula z

klasy D (w pierwszym oktecie 1110). Administratorzy sieci, którzy chcą

wykorzystywać adresy multicastowe, muszą się stosować do reguł

ustalonych przez IANA. W Tabela 1Tabela 6 została zaprezentowana

adresacja dedykowana dla IP Multicast.

Dwórznik Marek


Tabela 6 Adresacja dla IP Multicast

Nazwa Zakres Opis

Zarezerwowana pula

adresów dla połączeń

lokalnych

224.0.0.0 do

224.0.0.225

Pula adresowa zarezerwowana dla

protokołów sieciowych w

połączeniach lokalnych. Adresy nie

rutowane w sieci. Np. adres

224.0.0.5 i 224.0.0.4

wykorzystywany przez protokół

OSPF.

Globalna pula

adresów

224.0.1.0 do

238.255.255.255

Jest to globalna pula adresów

wykorzystywana do transmisji

multicastowej pomiędzy

organizacjami. Niektóre adresy

zostały zarezerwowane przez IANA

dla konkretnych aplikacji, np.

224.0.1.1 dla protokołu NTP

SSM 232.0.0.0 do

232.255.255.255

Pula adresowa zarezerwowana przez

IANA dla trybu SSM (Specific Source

Multicast)

Adresacja GLOP 233.0.0.0 do

233.255.255.255

Jest pula statycznie zdefiniowana dla

organizacji posiadających własny AS.

Numer AS jest odpowiednio

zapisywany na drugim i trzecim

oktecie adresu i taka podsieć jest

możliwa do wykorzystania przez

dany AS.

Zarezerwowana pula

adresów

239.0.0.0 do

239.255.255.255

Prywatna pula adresowa, możliwa do

wykorzystania w danym AS. Możliwa

do wykorzystania dla lokalnych

aplikacji.

Pula adresów wykorzystywana dla usługi IPTV zależy od sposobu

dostarczania danych. Dla trybu SSM został sprecyzowany odpowiedni zakres

adresów IP 232.0.0.0 z maską 8 bitów i tylko do tego może być

wykorzystany. Dla trybu ASM jest wykorzystywana prywatna pula adresów

239.0.0.0 z maską 8 bitów. Dla ASM każdy program telewizyjny jest

identyfikowany przez unikalną grupę multicastową. Dzieje się tak dlatego, że

odbiorca wysyła żądanie IGMP tylko grupy, do której chce się dołączyć,

natomiast dla SSM jest możliwość wysyłania kilku strumieni wideo na taki

sam adres grupy. Jest to dozwolone, jeżeli programy są wysyłane z różnych

adresów źródłowych.

IANA również zarezerwowała odpowiednią pulę adresów MAC w sieci

Ethernet dla adresacji grup multicastowych. Zakres dostępny to

01:00:5e:00:00:00 do 01:00:5e:7f:ff:ff. W ten sposób mamy dostępne 23

bity możliwe do mapowania z adresami IP. Określony standard mówi, że

Dwórznik Marek


mapujemy najniższe 23 bity adresu IP do tych 23 bitów dostępnych w

warstwie Ethernet. Przy tej transformacji tracone jest 5 bitów z adresu IP, co

oznacza, że 32 adresy IP są mapowane do jednego adresu MAC. Rysunek 15

przedstawia dokładniej tą operację.

Rysunek 15 Mapowanie multicastowego adresu IP do adresu MAC. [6]

6 Protokoły wykorzystywane w IP Multicast

Router, żeby mógł obsługiwać transmisję strumieni multicastowych

musi wiedzieć na jaki interfejs ma wysyłać ten ruch. W związku z tym musi

mieć informację, na której podsieci znajdują się członkowie grup

multicastowych lub inny router mający zdolność do transmisji takiego

strumienia. W tym celu stworzono wiele protokołów, które pozwalają na

implementację IP multicast w sieciach IP.

Protokoły obecne w sieciach rozgłoszeniowych:

Między domenowy multicast

o PIM-SM (RFC 2362)

o PIM-SSM (RFC 3569)

o IPv6 multicast (RFC 2375)

o PIM snooping (draft-ietf-l2vpn-vpls-pim-snooping-01.txt)

o mVPN (RFC 5266)

o MBGP (RFC 2858)

o MSDP (RFC 3618)

Dwórznik Marek


Enterprise multicast

o IGMP (RFC 2236, 3376)

o IGMP snooping (RFC 4541)

o PIM-SM (RFC 2362)

o Bidir-PIM (RFC 5015)

o MLD (RFC 2710, 3810)

o MLD snooping (RFC 4541)

o IPv6 multicast (RFC 2375)

Rysunek 16 Protokoły w sieciach rozgłoszeniowych

W IP Multicast do kontroli członkostwa w grupie używa się protokołu

IGMP, natomiast do wyznaczania trasy protokół PIM. W prezentowanym

przeze mnie rozwiązaniu, została wykorzystana wersja 2 protokołu IGMP i

PIM SSM. Prezentację tego rozwiązania pokazuje Rysunek 17.

PIM-SM Bidir PIM IPv6 Multicast

IGMP/ MLD

IGMP/MLD snooping

Enterprise

Odbiorcy

Odbiorcy

Źródła

RP

DR

ISP

PIM Snooping

Źródła

ISP

MSDP

PIM-SM PIM-SSM IPv6 Multicast

RP

RP

Dwórznik Marek


W kolejnych podrozdziałach została przedstawiona konfiguracja na

routerze 7600 i dokładniejszy opis tych protokołów.

Rysunek 17 Protokoły IP Multicast w prezentowanym rozwiązaniu

6.1 PIM

Routery uczestniczące w transmisji rozgłoszeniowej tworzą tzw. drzewa

dystrybucyjne w celu kontrolowania ścieżki ruchu multicast poprzez sieć

pomiędzy źródłem a odbiorcami. Wyróżnia się dwa rodzaje drzew używanych

w zależności od zastosowanego protokołu: source tree, shared tree.

Source tree jest to drzewo dystrybucyjne, w którym korzeniem jest

źródło transmisji rozgłoszeniowej. W celu wyznaczenia trasy, od źródła do

odbiorcy, jest używana najkrótsza ścieżka. Z tego powodu to rozwiązanie

nazywane jest również jako drzewo najkrótszej ścieżki (SPT – shortest path

tree). Dla każdego źródła jest tworzone oddzielne drzewo dystrybucyjne.

Rysunek 18 przedstawia przykład wykorzystujący SPT.

Dwórznik Marek


Rysunek 18 Drzewo dystrybucyjne z korzeniem źródła

Odpowiednia notacja (S;G) określa adres źródła strumienia i adres

grupy rozgłoszeniowej. Używając takiego oznaczenia dla powyższego

rysunku byłoby to (192.1.1.1;224.1.1.1).

Shared tree, w przeciwieństwie do source tree, korzeniem jest

wspólny dla wszystkich aktywnych źródeł punkt w sieci. Takie zdefiniowane

miejsce nazywane jest randezvous point (RP). Rolą RP jest rejestrowanie

aktywnych źródeł, nadających do grup rozgłoszeniowych oraz interfejsów, na

które należy wysłać pakiety przeznaczone do danej grupy. Kiedy używamy

drzewa współdzielonego, źródło musi wysłać strumień rozgłoszeniowy do

korzenia, dopiero wtedy transmisja jest przesyłana do odbiorców. Rysunek

19 przedstawia przykład takiego drzewa. Ruch ze źródła A i D jest

przesyłany do korzenia, którym jest router D a następnie drzewem

współdzielonym do odbiorców B i C. Ze względu na to, że źródła korzystają z

tego samego drzewa, używa się notacji (*;G) gdzie * oznacza wszystkie

źródła a G daną grupę rozgłoszeniową. Dla poniższego rysunku byłoby to

(*;224.2.2.2).

Host A

Host B Host C

A B D

C

F

źródło

odbiorca

E

odbiorca

224.1.1.1 stumień

192.1.1.1

192.2.2.2 192.3.3.3

Notacja: (S;G) S= źródło G=grupa

Dwórznik Marek


Rysunek 19 Drzewo dystrybucyjne z korzeniem współdzielonym

Przy omawianiu protokołu routingu dla transmisji rozgłoszeniowej

należy wspomnieć o mechanizmie jakim jest RPF (Reverse Path Forwarding).

Głównym jego zadaniem jest zapobieganie powstawania pętli w transmisji

multicast. Router wykorzystuje tablicę routingu unicast w celu określenia

sąsiadów upstream (w kierunku źródła) i downstream (w kierunku

odbiorców). Ze względu, że router nie zna adresów odbiorców opiera się na

trasie unicast w kierunku źródła. Zasada jest taka, że wysyła strumień

multicastowy jeżeli dostał go z interfejsu upstream i wysyła tylko na

interfejsy downstream. Algorytm używany przez RFP nazywany jest RPF

Check.

Jednym z protokołów routingu dla multicast jest PIM (Protocol

Independent Multicast). Jego nazwa powstała od tego, że jest niezależny od

konkretnego protokołu routingu unicast. Wykorzystuje on dowolny protokół

jak OSPF, EIGRP, ISIS, BGP. Unikastową tablicę routingu wykorzystuje dla

funkcji jaką jest RPF check. Wyróżnia się dwa główne rodzaje PIM:

DM – Dense Mode

SM – Sparce Mode

Protokół PIM-DM (Dense Mode) opiera się na modelu wpychania

strumienia grupy multicastowej do sieci (push model) i wykorzystuje drzewo

dystrybucyjne z korzeniem w źródle. Router z skonfigurowanym PIM DM

przyjmuje, że kiedy źródło zaczyna wysyłać strumień, wszystkie interfejsy

Host A

Host B Host C

A B D

C

F

Źródło 1

odbiorca

E

odbiorca

224.2.2.2 stumień

192.1.1.1

192.2.2.2 192.3.3.3

Notacja: (*;G) *= wszystkie źródła G=grupa

Host D

192.4.4.4

Źródło 2

Randezvous point

Dwórznik Marek


downstream chcą odbierać tą transmisję. Powoduje to sytuację, że strumień

początkowo jest przesyłany do wszystkich obszarów w sieci. Przy wysyłaniu

strumienia obowiązuje oczywiście mechanizm RPF check, który został

wcześniej wspomniany. Jeżeli w danym obszarze nie ma członków danej

grupy, to odbywa się proces przycinania (prune) gałęzi drzewa

dystrybucyjnego. Stan przycięcia ma określony czas po którym ponownie

rozpoczyna się wysyłanie strumienia do danej gałęzi. Przycinanie odbywa się

dla każdej pary (S;G). W przypadku gdy pojawi się zapotrzebowanie na daną

grupę, używany jest komunikat „graft” przesyłany w kierunku źródła. Na

podstawie tego gałąź znowu otrzymuje dany strumień multicastowy. W celu

zminimalizowania ruchu związanego z przycinaniem i powracaniem gałezi,

PIM-DM wykorzystuje tzw. komunikaty odświeżające (refresh messages). Ta

wiadomość jest propagowana w sieci przez router bezpośrednio podłączony

do źródla. Kiedy zostanie odebrana na interfejsie RPF przez któryś z

routerów, gdzie jest interfejs w stanie przycięcia, to zostaje odświeżony czas

dla tego stanu.

Powyższy rodzaj protokołu PIM jest najczęściej używany gdy źródło i

odbiorcy są podłączeni do tego samego routera. W rozwiązaniach bardziej

złożonych nie stosuje się raczej tego typu rozwiązań.

Protokół PIM-SM opiera się na modelu ściągania (pull model).

Wykorzystuje drzewo współdzielone gdzie występuje RP. Lokalizacja

Randezvous Point jest możliwa przez statyczne lub dynamiczne

skonfigurowanie. Od źródła do RP jest wyznaczana ścieżka na podstawie

tablicy routingu unicast, natomiast od RP w kierunku downstream jest

shared tree. Router, do którego podłączeni są bezpośrednio odbiorcy,

nazywany jest Designated router i odpowiedzialny jest za wysyłanie

komunikatów join/prune w stronę RP. Na interfejsach, na których otrzymana

została wiadomość join, uczestniczy w przesyłaniu strumienia danej grupy

multicastowej. Pomiędzy routerem gdzie bezpośrednio jest podłączone

źródło a RP są wymieniane komunikaty register, register-stop, register-null.

Służą one do rejestrowania aktywnego źródła w RP. Przy spełnieniu

odpowiednich warunków jest możliwość ustanowienia drzewa SPT dla

konkretnej grupy pomiędzy źródłem a DR bez uczestnictwa RP.

Poniżej zostało zaprezentowane, jak odbywa się proces join/prune.

Informacje pochodzą z routera Cisco 7600 w środowisku produkcyjnym dla

IPTV (komenda debug ip pim).

2056783: Jun 9 07:46:25: PIM(0): Insert (10.1.11.130,232.0.6.41) join in nbr 10.81.1.73’s queue 2056784: Jun 9 07:46:25: PIM(0): Building Join/Prune packet for nbr 10.81.1.73 2056785: Jun 9 07:46:25: PIM(0): Adding v2 (10.1.11.130/32, 232.0.6.41), S-bit Join 2056786: Jun 9 07:46:25: PIM(0): Send v2 join/prune to 10.81.1.73 (TenGigabitEthernet3/2) 2056787: Jun 9 07:46:26: PIM(0): Received v2 Join/Prune on Port-channel2 from 10.81.1.37, to us 2056788: Jun 9 07:46:26: PIM(0): Join-list: (10.1.13.3/32, 232.0.1.143), S-bit set

Dwórznik Marek


2056789: Jun 9 07:46:26: PIM(0): Add Port-channel2/10.81.1.37 to (10.1.13.3, 232.0.1.143), Forward state, by PIM SG Join 2056790: Jun 9 07:46:26: PIM(0): Insert (10.1.11.130,232.0.6.27) join in nbr 10.81.1.73’s queue 2056791: Jun 9 07:46:26: PIM(0): Building Join/Prune packet for nbr 10.81.1.73 2056792: Jun 9 07:46:26: PIM(0): Adding v2 (10.1.11.130/32, 232.0.6.27), S-bit Join 2056793: Jun 9 07:46:26: PIM(0): Send v2 join/prune to 10.81.1.73 (TenGigabitEthernet3/2) 2056794: Jun 9 07:46:26: PIM(0): Insert (10.1.13.3,232.0.1.119) join in nbr 10.81.1.73’s queue 2056795: Jun 9 07:46:26: PIM(0): Building Join/Prune packet for nbr 10.81.1.73 2056796: Jun 9 07:46:26: PIM(0): Adding v2 (10.1.13.3/32, 232.0.1.119), S-bit Join 2056797: Jun 9 07:46:26: PIM(0): Send v2 join/prune to 10.81.1.73 (TenGigabitEthernet3/2) 2056798: Jun 9 07:46:26: PIM(0): Received v2 Join/Prune on Port-channel1 from 10.81.1.49, to us 2056799: Jun 9 07:46:26: PIM(0): Join-list: (10.1.11.35/32, 232.0.3.13), S-bit set 2056800: Jun 9 07:46:26: PIM(0): Update Port-channel1/10.81.1.49 to (10.1.11.35, 232.0.3.13), Forward state, by PIM SG Join 2056801: Jun 9 07:46:26: PIM(0): Received v2 Join/Prune on Port-channel1 from 10.81.1.49, to us 2056802: Jun 9 07:46:26: PIM(0): Join-list: (10.1.11.3/32, 232.0.2.1), S-bit set 2056803: Jun 9 07:46:26: PIM(0): Update Port-channel1/10.81.1.49 to (10.1.11.3, 232.0.2.1), Forward state, by PIM SG Join 2056804: Jun 9 07:46:27: PIM(0): Insert (10.1.11.130,232.0.6.44) join in nbr 10.81.1.73’s queue 2056805: Jun 9 07:46:27: PIM(0): Building Join/Prune packet for nbr 10.81.1.73 2056806: Jun 9 07:46:27: PIM(0): Adding v2 (10.1.11.130/32, 232.0.6.44), S-bit Join 2056807: Jun 9 07:46:27: PIM(0): Send v2 join/prune to 10.81.1.73 (TenGigabitEthernet3/2) 2056808: Jun 9 07:46:27: PIM(0): Received v2 Join/Prune on Port-channel4 from 10.81.1.66, to us 2056809: Jun 9 07:46:27: PIM(0): Join-list: (10.1.11.3/32, 232.0.2.2), S-bit set 2056810: Jun 9 07:46:27: PIM(0): Update Port-channel4/10.81.1.66 to (10.1.11.3, 232.0.2.2), Forward state, by PIM SG Join 2056811: Jun 9 07:46:27: PIM(0): Insert (10.1.28.146,232.0.4.1) join in nbr 10.81.1.73’s queue 2056812: Jun 9 07:46:27: PIM(0): Building Join/Prune packet for nbr 10.81.1.73 2056813: Jun 9 07:46:27: PIM(0): Adding v2 (10.1.28.146/32, 232.0.4.1), S-bit Join 2056814: Jun 9 07:46:27: PIM(0): Send v2 join/prune to 10.81.1.73 (TenGigabitEthernet3/2) 2056815: Jun 9 07:46:27: PIM(0): Insert (10.1.11.130,232.0.6.17) join in nbr 10.81.1.73’s queue 2056816: Jun 9 07:46:27: PIM(0): Building Join/Prune packet for nbr 10.81.1.73 2056817: Jun 9 07:46:27: PIM(0): Adding v2 (10.1.11.130/32, 232.0.6.17), S-bit Join 2056818: Jun 9 07:46:27: PIM(0): Send v2 join/prune to 10.81.1.73 (TenGigabitEthernet3/2) 2056819: Jun 9 07:46:27: PIM(0): Received v2 Join/Prune on Port-channel2 from 10.81.1.37, to us

Urządzenia firmy Cisco oferują możliwość implementacji odmiany

protokołu PIM SM jakim jest PIM SSM. Jest to rozszerzenie standardu ISM

(Internet Multicast Standard), które pozwala odbiorcy (set-top-box) określić,

z którego źródła chce pobierać daną grupę mulicastową. W tym trybie PIM

SM nie wykorzystuje RP a bezpośrednio tworzone jest drzewo SPT pomiędzy

źródłem a desygnowanym routerem (DR). Takie rozwiązanie jest często

wybierane przez operatorów telekomunikacyjnych ze względu na wysoką

skalowalność tego rozwiązania i bezpieczeństwo. Opis Source-Specific

Multicast (SSM) został przedstawiony w RFC 3569.

Główna charakterystyka PIM-SSM:

Wybrane cechy

o Idealny dla aplikacji typu 1-do-wielu, czyli Wideo/TV Broadcast

o Wspiera jedynie drzewo multicastowe typu SPT (podrodzina PIM-

SM)

o Odbiorca musi znać źródło

o Nie istnieje Rendezvous Point

o Tablica routingu zawiera jedynie wpisy typu: (S,G)

Zalety:

o Łatwiejsza alokacja adresów grup multicastowych (jedna grupa,

różne źródła)

Dwórznik Marek


o Oferuje większą kontrolę nad ruchem multicastowym (odbiorcy i

źródła)

Wady:

o Większe wymagania wobec odbiorców: IGMPv3

o Konieczność powiadomienia odbiorcy o adresie źródła

o Duża liczna wpisów (S,G) w tablicy routingu

6.1.1 Konfiguracja protokołu PIM SSM

Dla IPTV najbardziej odpowiedni protokół wg. wielu źródeł to PIM SSM.

Daje on wiele korzyści jak lepsza kontrola przesyłanych treści czy

zwiększone bezpieczeństwo przed Denial of Service. Operator

telekomunikacyjny, na którego rozwiązaniu opieram się w mojej pracy,

również stosuje taką implementację. Protokół PIM SSM wymaga korzystania

z IGMP w wersji 3, ponieważ tylko ta wersja pozwala na przesyłanie zgłoszeń

zawierających grupę multicastową i adres źródła. Obecnie większość STB nie

obsługuje jeszcze wersji 3 a jedynie 2 lub 1. W okresie przejściowym stosuje

się rozwiązanie SSM Mapping, które jest implementowane na routerach,

które odbierają komunikaty report od STB. Dokładny opis komunikatów

IGMP został przedstawiony w podrozdziale 6.2.

W wielu publikacjach i książkach można przeczytać, że komendę ip

igmp ssm-map enable, włączającą SSM mapping na urządzeniach Cisco,

wystarczy wpisać na tych routerach, które uczestniczą w komunikacji

protokołu IGMP. Natomiast w jednej z dokumentacji firmy Cisco, możemy

dowiedzieć się, że zaleca się konfigurację na wszystkich routerach, na

których jest uruchomiony PIM.[3] Zostały przeprowadzone testy czasu

odzyskania poprawnego działania usługi po wystąpieniu awarii. Zbadano, że

jeżeli mapowanie jest włączone tylko na routerze gdzie jest IGMP to czas

zbieżności dla protokołu PIM był w niektórych przypadkach dłuższy niż kiedy

włączony został również po stronie stacji czołowej (head end).

W rozwiązaniu, które opisuje, na podstawie przeprowadzonych testów,

w celu zmniejszenia czasów zbieżności protokołu PIM, również zastosowano

implementację na wszystkich routerach w sieci. Dodatkowo w celu

przyśpieszenia czasu przełączania programów (tzw. zapping), włączono na

routerach, do których podłączone są źródła, statyczne mapowanie

wszystkich dostępnych grup dla IGMP (opisane w kolejnym podrozdziale).

Powoduje to, że do sieci od źródła są bez przerwy przesyłane strumienie

multicastowe bez względu czy jest na nie zapotrzebowanie w danym

momencie.

Dwórznik Marek


Tabela 7 Konfiguracja globalna na wszystkich routerach w sieci ip multicast-routing Włączenie IP Multicast na routerze

ip access-list standard ssm_range permit 232.0.2.0 0.0.0.255 permit 232.0.1.0 0.0.0.255 permit 232.0.16.0 0.0.0.255 permit 232.0.10.0 0.0.0.255 permit 232.0.3.0 0.0.0.255 permit 232.0.4.0 0.0.0.255 permit 232.0.5.0 0.0.0.255

Określenie adresacji, która będzie

wykorzystywana przez PIM SSM. Domyślnie

jest używana cała pula adresów określona

przez IANA dla SSM. Można jednak określić

adresację, która będzie wyłącznie

wykorzystywana przez ten protokół i żadna

poza tym nie będzie brana pod uwagę.

Można w ten sposób przypisać adresy dla

SSM spoza adresacji określonej przez IANA.

ip pim ssm range ssm_range Przypisanie access-listy do SSM, która

została wcześniej określona

ip igmp ssm-map enable Włączenie SSM Mapping na routerze

no ip igmp ssm-map query dns Wyłączenie domyślnie włączonej

funkcjonalności, która odwołuje się do

serwera DNS w celu przetłumaczenia nazwy

źródła na adres IP. Wyłączenie opcji

ponieważ ustawione jest statyczne

mapowanie grup do określonego źródła. ip igmp ssm-map static acl_ssm_map1

10.1.11.3 Statyczne przypisanie grup multicastowych

dla konkretnego źródła ip access-list standard acl_ssm_map1 permit 232.0.6.78 permit 232.0.6.79 permit 232.0.6.76 permit 232.0.6.77 permit 232.0.6.74 permit 232.0.6.72 permit 232.0.6.73 permit 232.0.6.71 permit 232.0.6.44 permit 232.0.6.43 permit 232.0.6.50 permit 232.0.6.51 permit 232.0.6.48 permit 232.0.6.49 permit 232.0.6.12 permit 232.0.6.0 0.0.0.31 permit 232.0.6.32 0.0.0.15

Określenie grup multicastowych dla

konkretnego źródła

Konfiguracja interfejsu router-dslam:

interface Vlan2001 description vlan/mcast mac-address 0013.c420.0121 ip address 10.80.133.1 255.255.255.252 ip access-group btv-2001-in in ip access-group btv-out out no ip proxy-arp ip pim sparse-mode ip igmp query-interval 20 no ip igmp snooping load-interval 30 mac packet-classify

Dwórznik Marek


no mop enabled !

Na interfejsie vlan, na którym jest uruchomiony protokół IGMP,

wydajemy tylko komendę włączającą PIM. Na pozostałych interfejsach, na

których ma odbywać się ruch multicastowy, również wydajemy powyższą

komendę, czyli pomiędzy węzłami w sieci i pomiędzy na interfejsie w

kierunku źródła.

Protokół PIM utrzymuje sąsiedztwo pomiędzy routerami, które

uczestniczą w IP Multicast, które można sprawdzić na routerze Cisco za

pomocą komendy:

Router#show ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 10.81.1.49 Port-channel1 1w2d/00:01:35 v2 1 / S P 10.81.1.37 Port-channel2 1w1d/00:01:27 v2 1 / S P 10.81.1.54 Port-channel3 7w5d/00:01:40 v2 1 / DR S P 10.81.1.66 Port-channel4 1w1d/00:01:44 v2 1 / DR S P 10.81.1.2 TenGigabitEthernet3/1 14w6d/00:01:18 v2 1 / DR S P 10.81.1.73 TenGigabitEthernet3/2 5d20h/00:01:39 v2 1 / S P

Natomiast jeżeli chcemy sprawdzić, wszystkie porty uczestniczące w IP

Multicast możemy to używamy komendy:

Router#show ip pim interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.81.1.50 Port-channel1 v2/S 1 30 1

10.81.1.50 10.81.1.38 Port-channel2 v2/S 1 30 1

10.81.1.38 10.81.1.53 Port-channel3 v2/S 1 30 1

10.81.1.54 10.81.1.65 Port-channel4 v2/S 1 30 1

10.81.1.66 10.81.1.1 TenGigabitEthernet3/1 v2/S 1 30 1 10.81.1.2 10.81.14.30 TenGigabitEthernet3/3 v2/S 0 30 1 0.0.0.0 10.81.1.5 TenGigabitEthernet4/1 v2/S 0 30 1 0.0.0.0 10.81.14.46 TenGigabitEthernet4/3 v2/S 0 30 1 0.0.0.0 10.80.16.1 Vlan2001 v2/S 0 30 1

10.80.16.1 10.80.16.5 Vlan2002 v2/S 0 30 1

10.80.16.5 10.80.16.9 Vlan2003 v2/S 0 30 1

10.80.16.9 10.80.16.13 Vlan2004 v2/S 0 30 1

10.80.16.13 10.80.16.17 Vlan2005 v2/S 0 30 1

10.80.16.17 10.80.16.21 Vlan2006 v2/S 0 30 1

10.80.16.21 10.80.16.25 Vlan2007 v2/S 0 30 1

10.80.16.25

Dwórznik Marek


10.80.16.29 Vlan2008 v2/S 0 30 1 10.80.16.29

10.80.16.33 Vlan2009 v2/S 0 30 1 10.80.16.33

10.80.16.37 Vlan2010 v2/S 0 30 1 10.80.16.37

10.81.1.74 TenGigabitEthernet3/2 v2/S 1 30 1 10.81.1.74

Po skonfigurowaniu PIM i IGMP, jeżeli chcemy sprawdzić jakie są

aktywne grupy multicastowe w sieci na danym routerze, możemy sprawdzić

to przy pomocy komendy:

Router# show ip mroute active Active IP Multicast Sources - sending >= 4 kbps Group: 232.0.3.4, (?) Source: 10.1.11.35 (?) Rate: 302 pps/3254 kbps(1sec), 3254 kbps(last 20 secs), 3256 kbps(life avg) Group: 232.0.3.5, (?) Source: 10.1.11.35 (?) Rate: 314 pps/3381 kbps(1sec), 3381 kbps(last 40 secs), 3349 kbps(life avg) Group: 232.0.3.6, (?) Source: 10.1.11.35 (?) Rate: 317 pps/3417 kbps(1sec), 3417 kbps(last 40 secs), 3381 kbps(life avg) Group: 232.0.3.7, (?) Source: 10.1.11.35 (?) Rate: 302 pps/3257 kbps(1sec), 3257 kbps(last 10 secs), 3256 kbps(life avg) Group: 232.0.3.8, (?) Source: 10.1.11.35 (?) Rate: 302 pps/3252 kbps(1sec), 3252 kbps(last 40 secs), 3256 kbps(life avg) Group: 232.0.3.9, (?) Source: 10.1.11.35 (?) Rate: 302 pps/3254 kbps(1sec), 3254 kbps(last 40 secs), 3254 kbps(life avg) Group: 232.0.3.10, (?) Source: 10.1.11.35 (?) Rate: 303 pps/3259 kbps(1sec), 3259 kbps(last 40 secs), 3258 kbps(life avg) Group: 232.0.3.11, (?) Source: 10.1.11.35 (?) Rate: 302 pps/3256 kbps(1sec), 3256 kbps(last 20 secs), 3255 kbps(life avg) Group: 232.0.3.12, (?) Source: 10.1.11.35 (?) Rate: 302 pps/3257 kbps(1sec), 3257 kbps(last 20 secs), 3256 kbps(life avg)

Z powyższej komendy możemy zobaczyć, jakiej wielkości są

przesyłane strumienie wideo w danej grupie multicastowej. Ta komenda

często przydaje się przy rozwiązywaniu problemów w sieci, kiedy chcemy

sprawdzić czy jest faktycznie przesyłany strumień o wielkości, której się

spodziewamy. Czasami zdarza się tak, że w tablicy routingu multicast

istnieje dana grupa, natomiast jest brak transmisji strumienia. Porównując

wielkości na routerach, na ścieżce do źródła, można stwierdzić gdzie

występuje problem.

6.2 IGMP

W przypadku kiedy router otrzymuje ruch multicastowy dla danej

grupy, potrzebuje on wiedzy, na który interfejs ma to przesłać. Decyzję o

Dwórznik Marek


tym podejmuje na podstawie czy w danej podsieci posiada zgłoszonych

członków tej grupy lub czy znajduje się router, który może przesyłać ruch

dalej. Tak jak wspomniałem w poprzednim podrozdziale, pomiędzy routerami

uruchomiony jest protokołów routingu multicastowego PIM. Pomiędzy

hostem a routerem, w celu komunikacji związanej z multicastingiem używa

się protokołu IGMP.

IGMP (Internet Group Management Protocol) jest to protokół używany

do dynamicznego rejestrowania użytkowników w odpowiedniej grupie

multicastowej. Pozwala na automatyczną kontrolę i ograniczenie ruchu

przesyłanego poprzez sieć do odpowiedniej grupy. Wyróżniamy dwa rodzaje

obiektów, które wymieniają między sobą informacje:

Querier – jest to ruter, który wysyła wiadomości typu query do

urządzeń w sieci, żeby dowiedzieć się, kto znajduje się w danej grupie

multicastowej

Host – jest to urządzenie w sieci, które wysyła wiadomość typu report

do rutera (querier), zgłaszając w ten sposób chęć lub potwierdzenie

uczestnictwa w danej grupie multicastowej

Do tej pory zostały wydane 3 wersje tego protokołu.

W usłudze IPTV hostem jest set-top-box a ruter z sieci agregacyjnej

pełni funkcję jako querier. Wiadomości protokołu IGMP są wysyłane w celu

dołączenia lub opuszczenia grupy.

Bazując na wersji 2 protokołu, wiadomość ma format jak prezentuje

Tabela 8.

Tabela 8 Wiadomość IGMP w wersji 2

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Max Response Time IGMP Checksum

Group Address

W polu „type” zamieszczane są różne rodzaje komunikatów w

zależności od celu wysyłanej wiadomości IGMP. Wyróżnia się trzy główne

typy występujące w komunikacji pomiędzy STB a routerem agregującym,

które zostały opisane w Tabela 9.

Dwórznik Marek


Tabela 9 Lista komunikatów IGMP

Typ komunikatu IGMP Opis

Raport o członkostwie hosta (0x16 -

membership report)

Wysyłany, gdy host dołącza do grupy

multiemisji, aby zadeklarować członkostwo w

specyficznej grupie hostów. Komunikaty

raportów IGMP o członkostwie hostów są

także wysyłane przez router w odpowiedzi na

kwerendę IGMP członkostwa hostów. W

przypadku komunikatu raportu o

członkostwie hostów protokołu IGMP w

wersji 3 host może żądać otrzymywania

ruchu multiemisji albo z określonych źródeł,

albo z wszystkich źródeł oprócz określonego

zestawu źródeł. Raportowanie uzależnione

od źródła zapobiega dostarczaniu przez

routery obsługujące multiemisje ruchu

multiemisji do podsieci, w których nie ma

nasłuchujących hostów.

Kwerenda członkostwa hostów (0x11 -

membeship query)

Używana przez router multiemisji do

okresowego sondowania sieci w celu

uzyskania informacji o członkach grupy. W

przypadku komunikatu kwerendy o

członkostwo hostów protokołu IGMP w wersji

3 router może sprawdzić, czy dany host jest

zainteresowany otrzymywaniem ruchu

multiemisji z określonej listy źródeł.

Opuszczenie grupy (0x17 - leave group) Komunikat wysyłany przez hosta przy

opuszczaniu grupy hostów, jeśli host jest

ostatnim członkiem tej grupy

zlokalizowanym w danym segmencie sieci.

Poniżej zostały przedstawione wyniki komend związane z weryfikacją

poprawności działania protokołu IGMP na routerach Cisco 7600.

Wynik komendy debug ip igmp:

Jun 9 07:43:18: IGMP(0): Received v2 Report on Vlan2004 from 10.144.15.125 for

232.0.1.112 Jun 9 07:43:18: IGMP(0): Convert IGMPv2 report (*, 232.0.1.112) to IGMPv3 with

1 source(s) using STATIC Jun 9 07:43:18: IGMP(0): Received Group record for group 232.0.1.112, mode 1

from 10.144.15.125 for 1 sourcesx‘ Jun 9 07:43:18: IGMP(0): Setting CSR group timer for group 232.0.1.112 Jun 9 07:43:18: IGMP(0): MRT Add/Update Vlan2004 for (10.1.13.3,232.0.1.112)

by 2 Jun 9 07:43:18: IGMP(0): Updating CSR expiration time on

(10.1.13.3,232.0.1.112) to 60 secs

Dwórznik Marek


Rysunek 20 Obsługa ruchu BTV i VOD

Router#show ip igmp membership Channel/Group Reporter Uptime Exp. Flags Interface /*,232.0.2.12 10.144.84.225 13w0d stop 2MA Vl2028 10.1.11.3,232.0.2.12 13w0d stop SA Vl2028 /*,232.0.2.12 10.144.92.2 13w0d stop 2MA Vl2030 10.1.11.3,232.0.2.12 13w0d stop SA Vl2030 /*,232.0.2.12 10.144.105.181 13w0d stop 2MA Vl2033 10.1.11.3,232.0.2.12 13w0d stop SA Vl2033 /*,232.0.2.12 10.144.108.146 13w0d stop 2MA Vl2034 10.1.11.3,232.0.2.12 13w0d stop SA Vl2034 /*,232.0.2.12 10.144.17.23 13w0d stop 2MA Vl2005 10.1.11.3,232.0.2.12 13w0d stop SA Vl2005 /*,232.0.2.12 10.144.76.73 13w0d stop 2MA Vl2026 10.1.11.3,232.0.2.12 13w0d stop SA Vl2026 /*,232.0.2.12 10.144.24.186 13w0d stop 2MA Vl2007 10.1.11.3,232.0.2.12 13w0d stop SA Vl2007

Komenda pokazująca użytkowników, którzy odbierają daną grupę

multicastową (program telewizyjny)

Router#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 232.0.4.1 Vlan2028 00:40:35 stopped 10.144.85.39 232.0.4.1 Vlan2008 00:43:08 stopped 10.144.28.224 232.0.4.1 Vlan2006 1d11h stopped 10.144.20.205 232.0.2.1 Vlan2009 01:49:00 stopped 10.144.32.109 232.0.2.1 Vlan2008 03:22:18 stopped 10.144.28.125 232.0.2.1 Vlan2007 10:08:08 stopped 10.144.24.241 232.0.2.1 Vlan2029 17:30:32 stopped 10.144.88.154 232.0.6.25 Vlan2004 16:07:42 stopped 10.144.12.94 232.0.2.12 Vlan2028 13w0d stopped 10.144.84.225 232.0.2.12 Vlan2030 13w0d stopped 10.144.92.2 232.0.2.13 Vlan2033 00:00:03 stopped 10.144.105.181 232.0.2.13 Vlan2003 00:09:03 stopped 10.144.9.132

Dwórznik Marek


6.2.1 Konfiguracja protokołu IGMP dla IPTV

W prezentowanym w mojej pracy rozwiązaniu występuje styk

pomiędzy routerem a DSLAM. Jest to interfejs L2, gdzie jest uruchomiony

trunk w stronę multipleksera, przenoszący dane w odpowiednich VLAN.

Protokół IGMP należy konfigurować na interfejsie SVI, na którym ma być

przenoszony ruch multicastowy. Przedstawiana konfiguracja oparta jest o

protokół IGMP w wersji 2 i PIM SSM. Ze względu na to, że wersja 2 nie

przenosi informacji o żądanym źródle grupy a PIM SSM wymaga podania

takiego adresu, należy wykonać statyczne mapowanie.

Tabela 10 Konfiguracja w trybie globalnym w celu mapowania IGMP do PIM SSM ip igmp ssm-map enable przed wykonaniem mapowania należy

włączyć taką opcję

no ip igmp ssm-map query dns w celu wyłączenia zapytań do DNS o

źródła

ip igmp ssm-map static ssm_map_source1 10.1.11.3

włączenie statycznego mapowania grup

multicastowych sprecyzowanych za

pomocą ACL

ip access-list standard ssm_map_source1 permit 232.0.2.0 0.0.0.255

Sprecyzowanie grup multicastowych,

które chcemy przypisać do danego

źródła

W celu włączenia igmp na danym interfejsie należy wykonać komendy

jakie widać poniżej wytłuszczonym drukiem.

interface Vlan2001 description vlan/mcast mac-address 0013.c420.0121 ip address 10.80.133.1 255.255.255.252 ip access-group btv-2001-in in ip access-group btv-out out no ip proxy-arp ip pim sparse-mode ip igmp query-interval 20 no ip igmp snooping load-interval 30 mac packet-classify no mop enabled !

Query interval jest to odstęp czasu między wysyłanymi komunikatami

na dany interfejs w celu otrzymania informacji czy aktywni członkowie danej

grupy multicastowej. Domyślny odstęp czasu to 60 sekund. W celu

optymalizacji zazwyczaj zmniejsza się ten parametr.

Kolejny parametr to igmp snooping. Jest on domyślnie włączony gdy

uruchamiamy protokół IGMP na routerze Cisco 7600. Ta funkcjonalność jest

Dwórznik Marek


przydatna kiedy router pełni funkcję przełącznika L2 i do wielu portów są

podłączeni odbiorcy. Domyślnie na przełącznikach pakiety multicast są

traktowane jak broadcast. W celu uniknięcia przesyłania strumienia na

interfejsy gdzie nie ma odbiorcy, przełącznik zagląda do nagłówka L3 i na

podstawie żądania IGMP report, przypisuje tylko wybrany port. W przypadku

połączenia dslam – router nie jest to potrzebne. Ta funkcja jest włączana

dopiero na multiplekserze, co powoduje, że z routera jest przesyłany tylko

jeden strumień video a następnie w razie potrzeby na DSLAM jest ten sygnał

zwielokrotniany.

Na podstawie analizy częstości odbierania danych grup multicastowych

stosuje się statyczne przypisanie danych strumieni na konkretnym interfejsie

vlan. Powoduje to sytuację, że dany strumień jest zawsze wysyłany do

DSLAM nawet jeżeli nikt nie zgłasza żądania. Stosując takie rozwiązanie

umożliwia to szybsze pojawienie się obrazu na ekranie odbiornika TV po

włączeniu danego programu. Zakładając, że w Polsce najczęściej oglądane

są programy TVP1 i TVN, można ustawić statycznie te grupy multicastowe w

celu optymalizacji.

Konfiguracja polega na wydaniu następującej komendy na danym

interfejsie:

interface Vlan2001 description vlan/mcast mac-address 0013.c420.0121 ip address 10.80.133.1 255.255.255.252 ip access-group btv-2001-in in ip access-group btv-out out no ip proxy-arp ip pim sparse-mode ip igmp static-group 232.0.1.142 source ssm-map ip igmp static-group 232.0.2.12 source ssm-map ip igmp query-interval 20 no ip igmp snooping load-interval 30

Dwórznik Marek


7 Mechanizmy bezpieczeństwa w IPTV

7.1 DHCP Snooping

Funkcja DHCP Snooping ma za zadanie zabezpieczyć sieć przed

podstawieniem fałszywych serwerów DHCP. W tym celu porty na ruterze

które uczestniczą w tym procesie są odpowiednio określane jako zaufane

(trusted) lub niezaufane (untrusted). Porty zaufane to te w kierunku naszego

serwera dhcp (zaufany serwer DHCP) natomiast niezaufane to te w kierunku

klientów czyli w kierunku dslam. Zadania funkcji DHCP Snooping to:

Śledzenie zapytań (Discover)

Śledzenie odpowiedzi (Offer)

Ograniczenie pasma dla zapytań na portach Trusted. Eliminuje ataki

DoS na serwer DHCP

Odrzuca odpowiedzi (Offers) na portach Untrusted. Eliminuje

podstawione serwery DHCP

Rysunek 21 Proces DHCP Snooping

DHCP Snooping jest także odpowiedzialny za budowanie i utrzymanie

tablicy dhcp snooping binding, która zawiera informacje o przydzielonych

adresach ip, mac klientów, czas dzierżawy oraz interfejs, przez który

nastąpiło przydzielenie adresu ip. Wpis w tablicy następuje w momencie gdy

router odbiera pakiet z serwera DHCP (pakiet DHCPACL). Wpis zostaje

wykasowany z bazy kiedy czas dzierżawy się kończy lub gdy router odbiera

pakiet DHCPRELEASE od klienta.

Router7600#show ip dhcp snooping binding MacAddress IpAddress Lease(sec) Type VLAN Interface ------------------ --------------- ---------- ------------- ---- ---------

----------- 00:15:56:D6:61:95 10.144.14.102 77937 dhcp-snooping 2104

GigabitEthernet1/4

Dwórznik Marek


00:15:56:D7:E1:EC 10.144.92.159 47324 dhcp-snooping 2130 GigabitEthernet2/6

00:19:4B:EA:EE:74 10.144.32.150 65283 dhcp-snooping 2109 GigabitEthernet1/9

00:15:56:D8:62:D5 10.144.13.51 83476 dhcp-snooping 2104 GigabitEthernet1/4

00:15:56:D6:7E:AF 10.144.28.165 57700 dhcp-snooping 2108 GigabitEthernet1/8

00:15:56:D8:6A:F7 10.144.0.76 40624 dhcp-snooping 2101 GigabitEthernet1/1

00:15:56:D7:9B:39 10.144.32.110 83686 dhcp-snooping 2109 GigabitEthernet1/9

Total number of bindings: 1175

Komendy umożliwiające konfigurację DHCP Snooping na routerze

7600:

ip dhcp snooping vlan [zakres VLANów] – VLANy, na których

chcemy włączyć usługę

ip dhcp snooping information option allow-untrusted – włączenie

opcji na niezaufanych portach, która umożliwi przesyłanie z DSLAM

pakietów DHCP z opcją 82 (opcja 82 pozwala na przesłanie

identyfikatora przez DSLAM, co umożliwia na przypisywanie adresów

IP przez platformę z konkretnej puli)

no ip dhcp snooping information option – wyłączenie opcji, która

jest domyślnie włączona i powoduje dodatkowe oznaczanie pakietów

opcją 82 (opis patrz podrozdział 4.2.1)

ip dhcp snooping database

tftp://adres_serwera_dla_zapisania_bazy - włączenie

zapisywania bazy snooping na serwer tftp

ip dhcp snooping - włączenie globalne na switchu/ruterze funkcji

DHCP Snooping

7.2 Dynamic ARP Inspection

Dynamic ARP Inspection jest mechanizmem, który pozwala na

wpisanie do tablicy ARP, na danym przełączniku tylko i wyłącznie te adresy

IP, które zostały przyznane przez DHCP (dla użytkowników obsługiwanych

przez ten przełącznik). Mechanizm ten opiera się na informacji z bazy DHCP

Snooping, zawierającej przypisania poszczególnych adresów MAC do

konkretnych adresów IP przyznanych przez serwer DHCP. DAI odrzuca

zapytania ARP od tych hostów (Set-Top-Box), których adresy IP i MAC nie

zgadzają się z zapisami w tablicy binding_table, utworzonej przez DHCP

snooping. Mechanizm ten zabezpiecza przed sytuacją, kiedy użytkownik

próbuje zamienić adres IP dla Set-Top-Boxa, przypisany już do innego

abonenta.

Dwórznik Marek


Rysunek 22 Zabezpieczenie prze Denial Of Service

Rysunek 23 Zebezpieczenie przed DHCP Spoofing


7600:

ip arp inspection vlan [zakres VLANów] - Włączenie mechanizmu

DAI dla zakresu VLANów

ip arp inspection vlan [zakres VLANów] logging dhcp-bindings

all – uruchomienie logowania wszystkich zdarzeń dla DAI

ip arp inspection validate src-mac dst-mac ip – włącza dodatkowe

sprawdzenie parametrów takich jak źródłowy i docelowy adres mac

ip arp inspection log-buffer entries 1024 - Konfiguracja rozmiaru

bufora logowania (0-1024)

ip arp inspection log-buffer logs 200 interval 600 -

Konfigurowanie bufora logowania

7.3 Unicast Reverse Path Forwarding

Mechanizm Unicast Reverse Path Forwarding (uRPF) jest

wykorzystywany w celu dodatkowego zabezpieczenia DAI. W sytuacji, kiedy

Dwórznik Marek


przypisywany jest adres IP, nie przyznany jeszcze nikomu przez serwer

DHCP, DAI nie zadziała, gdyż nie posiada odpowiedniego wpisu w swojej

tablicy. Funkcja uRPF jest włączana na interfejsie VLAN (gdzie odbywa się

ruch DHCP), na którym terminujemy podłączenie do DSLAM. Gdy na takim

interfejsie jest skonfigurowany DHCP Relay (ip helper-address <ip serwera

DHCP>), dla każdego adresu IP przyznanego przez DHCP, automatycznie

tworzony jest wpis w tablicy routing’u dla tego adresu, z maską /32, tzw.

host-route (jest to funkcja DHCP Relay’a). Wówczas działanie uRPF’a polega

na sprawdzeniu każdego przychodzącego na dany interface pakietu, czy

przyszedł z interface’u najlepszej drogi do źródła. Sprawdzany jest adres

źródłowy pakietu, czy odpowiadający mu wpis w tablicy routingu (host-

route) reprezentujący najlepszą ścieżkę do źródła (najlepszą ścieżkę

powrotną - Unicast Reverse Path Forwarding), wskazuje na interface z

którego pakiet przyszedł. Jeśli interface’y (z którego przyszedł pakiet i który

wskazuje wpis w tabeli routing’u) się zgadzają pakiet uznawany jest za

poprawny, zaś jeśli się różnią oznacza to, że adres źródłowy został

zmodyfikowany i pakiet jest odrzucany (lub przekazywany – w zależności od

zdefiniowanych list ACL). W pierwszej kolejności oznacza to, że blokowany

będzie ruch użytkowników, którzy nie mają wpisów (host-route) w tabeli

routing’u dokonanych przez DHCP, czyli takich, którzy sami sobie nadali

adres bez udziału serwera DHCP.

Dwórznik Marek


Rysunek 24 Proces dla uRPF w przypadku powodzenia

Routing table: 192.168.0.0 via 172.19.66.7 172.19.0.0 is directly connected, GigabitEthernet 2/1

CEF table: 192.168.0.0 172.19.66.7 GigabitEthernet 2/1 172.19.0.0 attached GigabitEthernet 2/1

Adjacency table: GigabitEthernet 2/1 172.19.66.7 50000603E.AAAA03000800

Data IP header

Data IP header

RPF sprawdza ścieżkę powrotną dla adresu źródłowego czy przychodzi na odpowiedni port

Adres docelowy x.x.x.x

Adres źródłowy 192.168.1.1

Wejście Wyjście

Unicast RPF

Jeśli jest w porządku, to pakiet jest przesyłany przez CEF

Dwórznik Marek


Rysunek 25 Proces dla uRPF w przypadku ataku


7600:

ip verify unicast source reachable-via rx allow-default 155 –

włączenie funkcji uRPF. Komendę wydajemy na interfejsie na, którym jest

skonfigurowany ip helper-address

access-list 155 permit udp any eq bootpc host 255.255.255.255

eq bootps – access lista, która definiuje co ma być domyślnie

przepuszczane. W tym przypadku wszystkie zapytania DHCP będą zawsze

przesyłane do serwera.

Routing table: 192.168.0.0 via 172.19.66.7 172.19.0.0 is directly connected, GigabitEthernet 2/1

CEF table: 192.168.0.0 172.19.66.7 GigabitEthernet 2/1 172.19.0.0 attached GigabitEthernet 2/1

Adjacency table: GigabitEthernet 2/1 172.19.66.7 50000603E.AAAA03000800

Data IP header

Data IP header

RPF sprawdza ścieżkę powrotną dla adresu źródłowego czy przychodzi na odpowiedni port

Adres docelowy x.x.x.x

Adres źródłowy 209.165.200.225

Wejście Wyjście

Unicast RPF

Jeśli nie jest w porządku, to pakiet jest odrzucany

DROP

Dwórznik Marek


8 Zarządzanie dostępem do usługi IPTV

Technologia IPTV, jak zostało przedstawione w poprzednich

rozdziałach, pozwala dostawcom usług dostarczać telewizję dla swoich

klientów. Operator chcąc efektywnie zarabiać na takim produkcie, musi mieć

możliwość kontroli dostępu do usługi. Powinna być możliwość

jednoznacznego identyfikowania każdego klienta i weryfikowania praw do

odbierania wybranej treści.

Do tego celu używa się systemów warunkowego dostępu (CAS –

Conditional Access System). Rozwiązanie to zapewnia, że tylko użytkownicy,

którzy spełniają odpowiednie kryteria mają możliwość odbioru konkretnych

programów.

Dostęp warunkowy (Conditional Access) jest to grupa technik

używanych w celu zapewnienia, że tylko użytkownicy, którzy spełniają

odpowiednie warunki mogą odbierać określone treści. Podstawową

technologią umożliwiającą to zrealizować jest kodowanie transmisji

(scrambling), co powoduje, że nieautoryzowany użytkownik nie może

oglądać odebranego sygnału. Autoryzowani użytkownicy używają

numerycznego klucza, który pozwala za pomocą sprzętowego lub

programowego modułu w STB, odkodować strumień (descrambling).[1]

Występuje wiele sposobów realizacji szyfrowania strumienia lecz wszystkie

systemy opierają się na trzech głównych zasadach:

Szyfrowanie i deszyfrowanie strumienia powinno być mało

skomplikowane jeżeli klucz numeryczny jest znany

Deszyfrowanie strumienia musi być trudne do wykonania jeżeli nie

jest znany klucz

Klucz musi być łatwy w zarządzaniu tak, żeby można było by go

łatwo dystrybuować do użytkownika

Jedną z metod, którą obecnie używa się do szyfrowania jest używanie

tzw. smart cards. Rysunek 26 przedstawia zasadę działania systemu

warunkowego dostępu opierającego się o szyfrowanie przy wykorzystaniu

smart card. Jest to rozwiązanie oparte o SimulScript przedstawiony w

dokumencie ETSI TS 101 197.

Dwórznik Marek


Rysunek 26 Zasada działania systemu warunkowego dostępu (CAS). [33]

W rozwiązaniu IPTV, które opisuje w pracy, został wykorzystany

system Viaccess – CAS. Produkt ten został stworzony w celu zabezpieczenia

strumieni TV poprzez różne sieci szerokopasmowe i jest oparty o standard

SimulCrypt. System pozwala usługodawcom na kontrolę dostępu do usługi

TV poprzez następujące funkcjonalności:[36]

Dostęp określany przedziałem czasu

Dostęp do wybranych kanałów

Kontrola rodzicielska

System Viaccess- CAS składa się z następujących komponentów:

SAS (Subscriber Authorization System) – jest używany do

zarządzania kartami chipowymi (smart cards, które są

zainstalowane w STB) i uprawnieniami użytkowników

EMMi (Entitlement Management Message injector) – służy do

wysyłania wiadomości EMM (są to pakiety, które zawierają

prywatne informacje dostępu warunkowego np. określają poziom

dostępu użytkowników do wybranej grupy programów TV).

ECMg (Entitlement Control Message generator) – jest to komponent

odpowiedzialny za generowanie wiadomości kontrolujących

uprawnienia (ECM) i generowanie słowa kontrolnego (CW) na

podstawie informacji dostępu kontrolowanego. Wiadomości ECM

zawierają słowo kluczowe i informacje z uprawnieniami

Dwórznik Marek


Rysunek 27 Architektura Viaccess – CAS.72[36]

Rysunek 27 przedstawia architekturę funkcjonalną komponentów

systemu Viaccess-CAS. Głównym składnikiem rozwiązania jest SAS

(Subscriber Authorization System). Zarządza on bazą danych kart chipowych

(smart cards) i generuje wiadomości EMM zawierające uprawnienia

użytkowników. Ma możliwość kooperowania z SMS (Subscriber Management

System), który jest używany przez usługodawcę do zarządzania

użytkownikami.

SMS (Subscriber Management System) jest rozwiązaniem, które

pozwala usługodawcy na:

Zarządzanie użytkownikami

Biling

Dwórznik Marek


Zarządzanie uprawnieniami użytkowników

Zarządzenie ofertą sprzedażową

SMS posiada interfejsy zewnętrzne, które umożliwiają połączenie z

zewnętrznymi aplikacjami operatora.

Dwórznik Marek


9 QOS

Jedną z ważniejszych rzeczy, o którą powinniśmy się zatroszczyć przy

implementacji usługi IPTV jest QOS (Quality Of Service). Spowodowane jest

to faktem, że transmisja wideo w sieci IP jest bardzo wrażliwa na utratę

pakietów. Mimo, że utrata jednego lub kilku pakietów nie wpływa znacząco

na jakość odebranego sygnału, to sytuacja taka trwająca dłużej niż sekundę

będzie powodować obniżenie jakości obrazu. [10]

Strumień programów telewizyjnych i VOD konsumuje dużo

przepustowości łącza i jest wrażliwy na zmienność opóźnień występujących

przy przesyłaniu pakietów IP.

Rysunek 28 Przykład pokazujący realizację usługi triple play w sieci agregacyjnej i

dostępowej.[10]

9.1 Wpływ sieci na jakość przesyłania strumieni wideo

Podstawowy model sieci IP jest oparty o przesyłanie pakietów w sposób

best-effort, bez gwarancji dostarczenia. Taki sposób traktowania pakietów

jest realizowany w sieci Internet. Jak wspomniano na początku tego

rozdziału, strumień wideo jest bardzo wrażliwy na różne czynniki

występujące w sieci IP. Chcąc świadczyć usługę IPTV musimy zatroszczyć się

o odpowiednie traktowanie strumieni wideo, żeby uniknąć słabej jakości

dostarczanego sygnału.

Główne czynniki mające wpływ na jakość przesyłania sygnału wideo to:

Utrata pakietów

End-to-end delay

Jitter

Dwórznik Marek


Utrata pakietów jest jednym z najczęstszych problemów występujących

przy przesyłaniu strumieni wideo w sieci IP. Źródłami przyczyn tego zjawiska

są błędy powodujące uszkodzenie nagłówka pakietu IP, przeciążenie łączy,

przepełnienie bufora lub uszkodzenie podzespołów urządzeń w sieci. Zakłada

się, że dopuszczalna liczba tzw. artefaktów (patrz Rysunek 29) to 1 na

godzinę. Wskaźnik stopy błędów pakietów IP, który powoduje taki artefakt

zależy od wielkości przesyłanego strumienia danych. Przy strumieniu MPEG2-

TS 4Mb/s z siedmioma pakietami TS w jednym pakiecie IP, stopa błędów

przesłanych pakietów IP powinna być mniejsza niż 1 x 10-6.[35]

Rysunek 29 Obraz z widocznymi artefaktami w przypadku problemów z

transmisją.[34]

End-to-end delay jest to suma wszystkich występujących typów

opóźnień od źródła sygnału do odbiorcy.

Jitter jest to różnica mierzona pomiędzy opóźnieniami dwóch pakietów.

Przyjmuje się, że dla MPEG2-TS maksymalna dopuszczalna wartość to +/-

20 ms.[33]

Transmisja telewizji cyfrowej w oparciu o sieć IP jest najbardziej

wrażliwa na utratę pakietów. Jest to związane ze specyfiką kompresji obrazu

jaka jest wykonywana w standardzie MPEG2. Technika ta jest podobna do

stosowanej w standardzie JPEG. Występuje tu jednak zakodowanie nie

jednego statycznego obrazka, ale wielu klatek filmowych. Dla

Dwórznik Marek


zaoszczędzenia miejsca enkoder MPEG łączy pojedyncze obrazy (tzw.

ramki), tworząc w ten sposób grupę obrazów GOP (Group of Pictures). W

procesie kompresji powstają ramki kluczowe (Intra Frame), które zawierają

pełną informację o obrazie oraz ramki pośrednie (Predicted Frame i

Bidirectional Frame), wykorzystujące podobieństwa w następujących po

sobie obrazach. Właśnie ramki typu P i B stanowią ogromną większość w

każdej grupie GOP. Jednocześnie do ich zapisania wymagana jest znacznie

mniejsza ilość danych, ponieważ nie zawierają one pełnej informacji o

obrazie, a opisują jedynie różnice między kolejnymi ramkami. W ramach

tworzonych grup obrazów GOP stosuje się także przewidywanie ruchu

(Motion Estimation), które działa z wykorzystaniem metody blokowej.

Oznacza to, że enkoder MPEG dzieli obraz wideo na tzw. makro bloki, każdy

o rozmiarach 16x16 pikseli. Następnie sprawdza, w jaki sposób zmienia się

pozycja makro bloków w poprzednich i w następnych ramkach. Informacje o

zmianach zapisywane są w formie wektorów przesunięć i obrazów

różnicowych (ramki typu P i B), co zapewnia dalszą redukcję danych. [40]

Rysunek 30 Przykład GOP (Group Of Pictures).[41]

Utrata ramki I powoduje, że pozostałe ramki w GOP są nieużyteczne.

Transmisja Group of Pictures odbywa się w wielu pakietach IP. Tak więc w

przypadku utraty pakietu IP, w którym nie ma ramki I wpływ na pogorszenie

obrazu może być niewielki. Natomiast utrata pakietu, w którym jest

przenoszona część informacji o ramce I, powoduje utratę całości GOP. Taka

sytuacja może spowodować utratę obrazu na 1-2 sekundy.[42] Rysunek 31

prezentuje jak może wyglądać jakość odbieranego obrazu przy procentowej

ilości utraconych pakietów IP.

Dwórznik Marek


Rysunek 31 Wpływ utraty pakietów na jakość odbieranego obrazu MPEG2.

Przykład ilości pakietów IP przenoszących jedną informację GOP

wygląda następująco:

Strumień MPEG2-ts = 4.8828 Mb/s

Strumień IP MPEG2-ts = 427,35 pps

Przy wielkości pakietu IP = 1487 bajtów (IP+UDP+RTP)

Rozmiar GOP w ms = 480

Ilość pakietów IP składających się na GOP = 205

W sieci, gdzie świadczona jest usługa TriplePlay występują trzy główne

typy transmisji:

Głos

Dwórznik Marek


Wideo

Dane

Bez implementacji jakiegokolwiek mechanizmu kolejkowania czy

buforowania, wszystkie rodzaje transmisji będą traktowane w ten sam

sposób co spowoduje, że niektóre usługi przestaną działać.

9.2 Zapewnienie jakości transmisji w sieci agregacyjnej

W sieci agregacyjnej dla usługi IPTV są przesyłane różne rodzaje danych

tak jak wspomniano wcześniej: wideo, głos, dane. Usługa BTV wykorzystuje

transmisję multicastową co umożliwia zaprojektowanie sieci w sposób

umożliwiający określenie maksymalnej wymaganej przepustowości łączy dla

tej usługi. Dla takiego rodzaju transmisji zapewnienie jakości polega na

zapewnieniu odpowiedniej pojemności łączy. Sytuacja zmienia się natomiast

kiedy trzeba rozważyć zapewnienie jakości transmisji dla strumienia VOD.

Nie ma możliwości dokładnego określenia jak wiele filmów będzie oglądanych

w danym momencie. Ten rodzaj transmisji wykorzystuje transmisję

unicastową co powoduje, że kolejny strumień, przesyłany w tym samym

momencie, powoduje zwielokrotnienie wymaganej przepustowości na

każdym łączu od serwera VOD w kierunku DSLAM. Operatorzy

telekomunikacyjni przy planowaniu sieci prognozują jak wiele filmów będzie

oglądanych w danym momencie i na tej podstawie jest określana wymagana

pojemność łączy. W celu zapewnienia odpowiedniej jakości transmisji dla

takiego typu ruchu, stosuje się odpowiednie mechanizmy ograniczające ilość

takich strumieni w danym momencie.

Jednym z rozwiązań, które jest wykorzystywane przez operatorów

telekomunikacyjnych to zarządzanie ruchem VOD poprzez serwer, który

pełni rolę menadżera przepustowości w platformie usługowej. Nie rezerwuje

on odpowiedniego pasma w sieci ale kontroluje ilość sesji użytkowników na

podstawie skonfigurowanych parametrów i monitoruje dostępne pasmo na

urządzeniach biorących udział w transmisji. Przy określaniu zasobów jest

konfigurowana topologia sieci na trzech poziomach z określeniem atrybutów:

Router sieci agregacyjnej

o Dostępna przepustowość dla VOD

o Powiązany z kilkoma serwerami VOD

o Powiązany z kilkoma DSLAM

DSLAM


o Powiązany tylko z jednym ruterem

o Powiązany z podsiecią IP

Dwórznik Marek


Serwer VOD


o Powiązany tylko z jednym ruterem

Za każdym razem, kiedy jest dodawany nowy składnik w topologii,

administrator musi dodać ten element do topologii na serwerze platformy

usługowej. Każdy składnik musi być skonfigurowany z podanymi wyżej

atrybutami. Kiedy do serwera przychodzi nowe żądanie sesji VOD, są

sprawdzane wszystkie parametry skonfigurowanej topologii sieci, na

podstawie źródłowego adresu IP (adres STB). W przypadku braku

wystarczających zasobów VOD dla DSLAM, połączenie zostaje odrzucone.

Użytkownik w takim przypadku otrzymuje komunikat na ekranie, że nie

może w tym momencie obejrzeć danego filmu.

Rysunek 32 Menadżer przepustowości używający protokołu COPS dla komunikacji

z serwerem VOD.[33]

Powyższy Rysunek 32 przedstawia sposób nawiązania połączenia STB

– serwer VOD w celu rozpoczęcia transmisji wideo.

Do kontroli transmisji pomiędzy STB a serwerem VOD jest używany

protokół RTSP (RFC 2326). Nie ma to jednak nic wspólnego z QOS. Steruje

on strumieniami ciągłych danych jak obraz czy głos. Protokół RTSP steruje

strumieniem, który może być przesyłany za pomocą odrębnego protokołu,

niezależnego od kanału kontrolnego. Np. sterowanie RTSP może pojawiać się

w połączeniu TCP, gdy dane przesyłane są z użyciem protokołu UDP.

Powoduje to, że dane dostarczane są nieprzerwanie, nawet gdy żądania

Dwórznik Marek


RTSP nie zostaną odebrane przez serwer mediów. Jednakże serwer musi

zachowywać tzw. stan sesji by móc dobrze kontrolować współdziałanie żądań

RTSP ze strumieniem. Pomiędzy STB a serwerem VOD przesyłane są

następujące rodzaje komunikatów RSTP:[43]

SETUP – powoduje umieszczenie zasobów serwera w strumieniu i

utworzenie sesji RTSP,

PLAY – uruchamia transmisję danych zawartych w strumieniu po

wcześniejszej komendzie SETUP,

PAUSE – okresowo zatrzymuje strumień (transmisję) bez zwalniania

zasobów serwera,

REDIRECT – wykrywa, że sesja powinna zostać przeniesiona na

nowy serwer (do innego miejsca),

PING – chroni sesje przed przeterminowaniem (ang. timeout),

TEARDOWN – zwalnia zasoby serwera połączone ze strumieniem.

W celu nawiązania połączenia w usłudze VOD stosuje się, jak

wspomniano wcześniej, menadżer przepustowości, który ma za zadanie

sprawdzić czy są warunki do ustanowienia nowej sesji RSTP. Do komunikacji

między serwerem VOD a menadżerem wykorzystuje się protokół COPS

(Common Open Policy Service – RFC 2748). Jest to protokół typu

klient/serwer, który wspiera kontrolę polityk dla protokołów sygnalizacji w

QOS jak RSVP (RFC 2205).

Powyżej wspomniane metody zapewnienia QOS odnoszą się do sytuacji

gdy w sieci występuje tylko usługa BTV, VOD i ruch zarządzający. Natomiast

w przypadku przesyłania w sieci IP transmisji wideo, głosu i Internet musimy

zastosować dodatkowo odpowiednie klasy QOS dla danego ruchu. W celu

zapewnienia odpowiedniej jakości usług wykorzystuje się model DiffServ

(RFC 2475). W wielkim skrócie polega to na tym, że dany ruch w sieci jest

postrzegany na podstawie odpowienio oznakowanych pakietów IP, przy

pomocy znaczników opisujących daną klasę usług. Natomiast odpowiednie

traktowanie tego ruchu odbywa się odpowiednio na każdym urządzeniu

znajdującym się na ścieżce tzw. PHB (per hop behaviour). W celu

poprawnego działania QOS, ten mechanizm musi być zaimplementowany na

każdym routerze znajdującym się w sieci. Do klasyfikacji zostały stworzone

odpowiednie klasy, które zostały opisane w RFC 2474. Poniżej zostało

przedstawione jakie przypisać klasy do usługi Triple Play.

Dwórznik Marek


Tabela 11 Klasy QOS dla Triple Play

Usługa Klasa DSCP Traktowanie ruchu

w sieci

Głos i sygnalizacja głosu EF Niskie opóźnienie,

najwyższy priorytet w

sieci

BTV AF41 Gwarancja przesyłu z

bardzo małą utratą

pakietów

VOD AF42 Gwarancja przesyłu z

małą utratą pakietów

Internet BE Best Effort – brak

jakiejkolwiek

gwarancji.

Wykorzystuje pasmo,

które nie zostało

wykorzystane przez

inne klasy

Klasa EF ma na celu zapewnienie niskostratnej, bezzwłocznej, stałej i

szybkiej transmisji pakietów. Dlatego najlepiej nadaje się do usługi głosowej,

która potrzebuje małej przepustowości ale jest najbardziej wrażliwa na

opóźnienia.

Klasy AF mają na celu zapewnienie jakości o zróżnicowanych

parametrach. Klasy te idealnie nadają się do przypisania im usług BTV i

VOD. Transmisja wideo jest najbardziej wrażliwa na utraty pakietów co było

przedstawione w poprzednim podrozdziale, ale jest bardziej tolerancyjna na

opóźnienia niż głos. W klasie AF pierwsza cyfra oznacza priorytet w sieci

natomiast druga cyfra oznacza prawdopodobieństwo odrzucenia pakietu w

przypadku przeciążenia łącza. Czym mniejsza cyfra, tym

prawdopodobieństwo jest niższe. Ze względu na fakt, że BTV i VOD używają

tego standardu MPEG-TS wymagania QOS dla utraty pakietów i opóźnienia

są takie same. Przy przypisywaniu klasy do usług BTV i VOD zakłada się jaka

powinna być dostępność danej usługi. Charakterystyka BTV jest taka, że

wymagana przepustowość w porównaniu do VOD jest niższa a oglądalność

telewizji jest większa w tym samym czasie niż VOD. Dodatkowo użytkownik

oglądając telewizję po wystąpieniu przerwy w transmisji, nie ma możliwości

powrócenia do momentu, w którym nastąpiła przerwa. Natomiast w VOD

taka możliwość występuje. Dlatego klasę, w której jest większe

prawdopodobieństwo utraty pakietów, przypisuje się do telewizji na żądanie

(VOD).

Dwórznik Marek


9.3 Zapewnienie jakości transmisji w sieci dostępowej

Użycie dedykowanego połączenia Ethernet pomiędzy STB a modemem

dostarcza wystarczającą przepustowość dla strumieni BTV, VOD i

zarządzania. Jednak mimo tego modem dostarcza ograniczenie pasma i

priorytetyzację dla każdego typu ruchu.

Sieć dostępowa zbudowana w oparciu o technologię DSL powoduje

ograniczoną przepustowość. Dlatego też, do priorytetyzacji ruchu są

używane klasy ATM. Tabela 12 przedstawia sposób przypisania

poszczególnych strumieni do właściwych klas. Pomiędzy modemem DSL a

DSLAM są kreowane oddzielne ścieżki PVC dla wideo, głosu i transmisji

danych.

Tabela 12 Przykład konfiguracji QOS na DSLAM dla usługi Triple Play

Dane usługi Triple Play jak wspomniano w poprzednich rozdziałach, na

routerze agregującym w kierunku DSLAM są separowane w oddzielnych

VLAN tzw. SVLAN. DSLAM widzi usługi jako oddzielne VLANy i mapuje je do

odpowiednich ścieżek ATM, do których są przypisane klasy ruchu. W ten

sposób ruch związany z wideo ma większy priorytet niż Internet. Nie ma

jednak tak

Rysunek 33 Przykład konfiguracji Triple Play na DSLAM

Dwórznik Marek


10 Posumowanie

Przesyłanie sygnału telewizji cyfrowej w oparciu o sieci IP, jak zostało

zaprezentowane w pracy, to technologia, która od jakiegoś czasu szybko się

rozwija. Jest alternatywą dla obecnych rozwiązań udostępniających usługę

telewizji cyfrowej. Statystyki sprzedaży pokazują, że jest to rozwiązanie,

które w przyszłości będzie generować wysokie zyski dla firm, które

zdecydują się oferować je dla swoich klientów. Usługa oferuje ogromne

możliwości poprzez prawdziwą interaktywność, której alternatywne usługi

nie mają. Klient w przyszłości będzie mógł oglądać wybrane filmy,

wiadomości, bajki, które sam sobie wybierze bez względu na porę dnia.

Jak zostało zaprezentowane w pracy, istnieją protokoły sieciowe, które

pozwalają na przesyłanie sygnału telewizji cyfrowej w sposób optymalny i

umożliwiają prawidłowe zarządzanie zgłoszeniami żądań użytkowników.

Duża skalowalność rozwiązania pokazuję, że w przyszłości będzie możliwe

świadczenie usługi wszędzie tam, gdzie jest wykorzystywany protokół IP.

W pracy dyplomowej przedstawienie usługi IPTV zostało oparte na

moim doświadczeniu zawodowym, które zdobyłem w jednej z firm

telekomunikacyjnych. Przedstawiłem sposób konfiguracji urządzeń w sieci

IP/Ethernet dla usługi IPTV opierając się na rozwiązaniu w środowisku

produkcyjnym. Ze względu na fakt, że w książkach dotyczących tego

zagadnienia brak jest praktycznych przykładów, które zostały gdzieś

zaimplementowane, zdecydowałem się opisać jeden z nich. Przedstawiłem

jak ważne jest zapewnienie mechanizmów jakości usług i jakie należy

zastosować mechanizmy bezpieczeństwa, bez których to, nie możliwe byłoby

w praktyce wdrożenie tego produktu.

Dwórznik Marek


Bibliografia

[1] Wes Simpson and Howard Greenfield - IPTV and Internet Video –

Expanding the Reach of Television Broadcasting

[2] Iain E. G. Richardson - H.264 and MPEG-4 video compression

[3] Cisco Systems - Cisco Gigabit-Ethernet Optimized IPTV/Video

over Broadband Solution, Release 1.0

[4] Edward M. Schwalb - iTV Handbook: Technologies and Standards

[5] Gilbert Held - Understanding IPTV

[6] InTellon - IPTV Distribution in Home Networks

[7] Laurel Networks - The Future of IPTV: Business and Technology

Challenges

[8] Cisco Systems - Optimizing Video Transport in Your IP Triple Play

Network

[9] Cisco Systems – Cisco IOS IP Multicast Configuration Guide –

release 12.4

[10] Cisco Systems – Delivering Video Quality in Your IPTV

Deployement – white paper

[11] Cisco Systems – Cisco IP/TV Administration and Configuration

Guide – version 3.4

[12] Cisco Systems - Cisco IPTV Video Headend

[13] Cisco Systems - Cisco End-to-End Solutions for IPTV

[14] Cisco Systems - IP Next-Generation Network Requirements for

Scalable and Reliable Broadcast IPTV Services

[15] Jarnicki Jacek – Politechnika Wrocławska -wykłady – Telewizja

[16] FlexLight networks - Deploying IPTV and Video-on-demand

(VoD) using FlexLight’s GPON systems

[17] John G. Apostolopoulos, Wai- tian Tan, Susie J. Wee - Video

Streaming: Concepts, Algorithms, and Systems

[18] HP INTEL SOLUTION CENTER BLUEPRINT - End-to-end IPTV to

the Digital

[19] Heavy Dreading - Assuring Quality of Experience for IPTV – 2006

White paper

Dwórznik Marek


[20] http://www.gsmonline.pl/portal/news/news.jsp?s0n_id=18904 -

informacja o wzroście liczby użytkowników wideostrady

[21] http://www.dvb.free.pl/ - telewizja cyfrowa

[22] Alcatel-Lucent - 7750 SR OS Triple Play Guide – luty 2007

[23] http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/conf

iguration/guide/snoodhcp.html

[24] http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_r

pf.html

[25] http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/gui

de/1cfdhcp.html

[26] RFC 3376 – IGMP v3 - ftp://ftp.rfc-editor.org/in-

notes/rfc3376.txt

[27] William R. Parkhurst - Cisco Multicast - Routing and Switching

[28] RFC3973 - Protocol Independent Multicast - Dense Mode (PIM-

DM)

[29] RFC 3569 - An Overview of Source-Specific Multicast (SSM)

[30] DSL Forum - TR-101 - Migration to Ethernet-Based DSL

Aggregation – kwiecień 2006

[31] OECD Ministerial Meeting – Convergence and Next Generation

Network – czerwiec 2008

[32] IPTV functional architecture synthesis – Network Overview –

prezentacja przedstawiona przez firmę Sofrecom – 2005

[33] Thomas Kernen - IPTV/Video over Broadband – maj 2006

[34] http://en.wikipedia.org/wiki/Image:Artifact.png

[35] ETSI TS 102 034 V1.1.1 - Digital Video Broadcasting (DVB) -

Transport of MPEG-2 Based DVB Services over IP Based Networks –

marzec 2005

[36] TV over DSL – prezentacja przedstawiona przez France Telecom

– 2005

[37] http://technet2.microsoft.com/windowsserver/pl/library/ffa6231

a-bf9b-4691-a63d-81c9cf66a34e1045.mspx?mfr=true

[38] http://slaptijack.com/networking/what-is-dhcp-option-82/

[39] RFC 3046 - DHCP Relay Agent Information Option

http://www.gsmonline.pl/portal/news/news.jsp?s0n_id=18904

http://www.dvb.free.pl/

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/snoodhcp.html

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/snoodhcp.html

http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_rpf.html

http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_rpf.html

http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfdhcp.html

http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfdhcp.html

ftp://ftp.rfc-editor.org/in-notes/rfc3376.txt

ftp://ftp.rfc-editor.org/in-notes/rfc3376.txt

http://en.wikipedia.org/wiki/Image:Artifact.png

Dwórznik Marek


[40] http://www.chip.pl/arts/archiwum/n/articlear_77624.html

[41] Steffan Kollar – IP Video Transport in SP Networks – Cisco Expo

2008

[42] Greg Shepherd - IPTV Multicast Video End-to-End Service – Cisco

Systems

[43] http://pl.wikipedia.org/wiki/Real_Time_Streaming_Protocol

PRACA DYPLOMOWA MAGISTERSKA - …zskl.p.lodz.pl/~morawski/Dyplomy/Praca dyplomowa p...Politechnika...

Documents

Transcript of PRACA DYPLOMOWA MAGISTERSKA - …zskl.p.lodz.pl/~morawski/Dyplomy/Praca dyplomowa p...Politechnika...