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

Politechnika Łódzka Instytut Informatyki 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 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: office@ics.p.lodz.pl

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

2 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

3 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

4 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

5 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.

6 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

7 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.

8 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 (settop 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.

9 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

10 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

11 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.

12 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.) 45 40 35 30 25 20 15 10 5 0 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]

13 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).

14 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.

15 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:

16 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.

17 Rysunek 6 Architektura funkcjonalna IPTV zaprezentowana przez firmę Sofrecom.[32]

18 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.

19 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.

20 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)

21 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) Upstream Date Rate (od klienta do DSLAM) Max. 8 Mb/s Max. 12 Mb/s Max. 24 Mb/s Max. 52 Mb/s 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

22 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.

23 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

24 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 Description Sub-option Code 1 Agent Circuit ID 2 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):

25 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

26 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.

27 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.

28 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.

29 AR Content Manager 10GE 10GE DR 1GE AR 10GE AR 10GE 1GE BTV Source 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 VLANach. 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.

30 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]

31 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.

32 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]

33 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.

34 Tabela 6 Adresacja dla IP Multicast Nazwa Zakres Opis Zarezerwowana pula adresów dla połączeń lokalnych Globalna pula adresów SSM Adresacja GLOP Zarezerwowana pula adresów 224.0.0.0 do 224.0.0.225 224.0.1.0 do 238.255.255.255 232.0.0.0 do 232.255.255.255 233.0.0.0 do 233.255.255.255 239.0.0.0 do 239.255.255.255 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. 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 Pula adresowa zarezerwowana przez IANA dla trybu SSM (Specific Source Multicast) 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. 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

35 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)

36 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) PIM-SM PIM-SSM IPv6 Multicast MSDP ISP ISP RP RP Źródła PIM Snooping Enterprise DR RP PIM-SM Bidir PIM IPv6 Multicast Odbiorcy IGMP/ MLD IGMP/MLD snooping Odbiorcy Źródła 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.

37 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.

38 źródło Host A 192.1.1.1 Notacja: (S;G) S= źródło G=grupa A B D F 224.1.1.1 stumień C E 192.2.2.2 192.3.3.3 odbiorca Host B odbiorca Host C 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).

39 Źródło 1 Host A 192.1.1.1 Notacja: (*;G) *= wszystkie źródła G=grupa Źródło 2 A B D F Randezvous point Host D 192.4.4.4 224.2.2.2 stumień C E 192.2.2.2 192.3.3.3 odbiorca Host B odbiorca Host C 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

40 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

41 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)

42 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.

43 Tabela 7 Konfiguracja globalna na wszystkich routerach w sieci ip multicast-routing Włączenie IP Multicast na routerze ip access-list standard ssm_range Określenie adresacji, która będzie permit 232.0.2.0 0.0.0.255 permit 232.0.1.0 0.0.0.255 wykorzystywana przez PIM SSM. Domyślnie permit 232.0.16.0 0.0.0.255 jest używana cała pula adresów określona permit 232.0.10.0 0.0.0.255 przez IANA dla SSM. Można jednak określić permit 232.0.3.0 0.0.0.255 permit 232.0.4.0 0.0.0.255 adresację, która będzie wyłącznie permit 232.0.5.0 0.0.0.255 wykorzystywana przez ten protokół i żadna ip pim ssm range ssm_range ip igmp ssm-map enable no ip igmp ssm-map query dns ip igmp ssm-map static acl_ssm_map1 10.1.11.3 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 poza tym nie będzie brana pod uwagę. Można w ten sposób przypisać adresy dla SSM spoza adresacji określonej przez IANA. Przypisanie access-listy do SSM, która została wcześniej określona Włączenie SSM Mapping na routerze 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. Statyczne przypisanie grup multicastowych dla konkretnego źródła 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

44 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

45 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

46 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.

47 Tabela 9 Lista komunikatów IGMP Typ komunikatu IGMP Raport o członkostwie hosta (0x16 - membership report) Kwerenda członkostwa hostów (0x11 - membeship query) Opuszczenie grupy (0x17 - leave group) Opis 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. 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ł. 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

48 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

49 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 no ip igmp ssm-map query dns ip igmp ssm-map static ssm_map_source1 10.1.11.3 ip access-list standard ssm_map_source1 permit 232.0.2.0 0.0.0.255 włączyć taką opcję w celu wyłączenia zapytań do DNS o źródła włączenie statycznego mapowania grup multicastowych sprecyzowanych za pomocą ACL 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

50 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

51 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

52 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.

53 Rysunek 22 Zabezpieczenie prze Denial Of Service Rysunek 23 Zebezpieczenie przed DHCP Spoofing Komendy umożliwiające konfigurację DHCP Snooping na routerze 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

54 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 (hostroute) 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.

55 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 Jeśli jest w porządku, to pakiet jest przesyłany przez CEF Unicast Data IP header RPF Data IP header Adres docelowy x.x.x.x Adres źródłowy 192.168.1.1 Wejście Wyjście RPF sprawdza ścieżkę powrotną dla adresu źródłowego czy przychodzi na odpowiedni port Rysunek 24 Proces dla urpf w przypadku powodzenia

56 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 Adres docelowy x.x.x.x Adres źródłowy 209.165.200.225 Unicast RPF Wejście Wyjście DROP Jeśli nie jest w porządku, to pakiet jest odrzucany RPF sprawdza ścieżkę powrotną dla adresu źródłowego czy przychodzi na odpowiedni port Data IP header Rysunek 25 Proces dla urpf w przypadku ataku Komendy umożliwiające konfigurację DHCP Snooping na routerze 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.