Protokół datagramów użytkownika (UDP)

Rozdział 8. Protokół datagramów użytkownika (UDP) Dogłębnie Protokół datagramów użytkownika (UDP) jest wymaganym standardem TCP/IP określonym w specyfikacji RFC 768. Jest to zawodny protokół, który zapewnia bezpołączeniową usługę wykorzystującą dostępne możliwości i nie gwarantuje dostarczenia, ani sprawdzenia sekwencji wszystkich datagramów. Może być wykorzystywany do emisji pojedynczej typu jeden do jednego, albo do komunikacji typu jeden do wielu, które używają datagramów IP emisji lub multiemisji. Praca w sieci Microsoft wykorzystuje protokół UDP do logowania, przeglądania i rozpoznawania nazw. Protokół używany jest do szybkiego dostarczania małych komunikatów do jednego lub wielu odbiorców oraz do komunikacji, gdzie szybkość dostarczania jest ważniejsza niż niezawodność (jak ruch multimediów czasu rzeczywistego). Jako że dostarczanie datagramów UDP nie jest gwarantowane, aplikacje korzystające z UDP muszą zaopatrzyć się we własne mechanizmy zapewniające niezawodność. Jeżeli dana sieć jest przeciążona, pakiety UDP mogą ulegać zagubieniu, przy czym nie ma mechanizmu ich odzyskiwania. W bardzo ruchliwej sieci, która ma wysoki poziom gwarantowanego ruchu protokołu TCP jest więc możliwe, że pakiety UDP będą wypychane i że straty w ruchu staną się nie do przyjęcia. Jest to problem szczególny w przypadku aplikacji, które opierają się na ruchu sieciowym w czasie rzeczywistym, gdzie opóźnienia związane z protokołem TCP są niedopuszczalne, ale dopuszczalny jest pewien poziom utraty danych. Musi więc zostać zastosowany mechanizm, który zarówno rezerwuje szerokość pasma, jak i umożliwia współistnienie ruchu czasu rzeczywistego oraz ruchu tradycyjnego w tej samej sieci. Jakość usługi (QoS) zapewnia taki mechanizm przy zastosowaniu usługi kontroli wpływu danych Jakości usługi. Protokół datagramów użytkownika (UDP) Podobnie jak protokół TCP, protokół UDP opiera się na protokole IP w kwestii routingu i jest rozpoznawany po wartości równej 17 (dziesiętnej) w polu Protokół nagłówka IP (patrz: specyfikacja RFC 1700). Komunikaty protokołu UDP są kapsułowane i wysyłane wewnątrz

datagramów IP. Protokół ten jest protokołem transakcyjnym i bezpołączeniowym i nie ustanawia sesji pomiędzy hostami, ani nie inicjuje żadnych procedur uzgadniania. UDP zapewnia IP następujący zestaw funkcji dodatkowych: Numery portów UDP zapewnia 16-bitowe numery portów, aby wiele procesów mogło korzystać z usług UDP na jednym hoście. Adres UDP jest połączeniem adresu IP i 16-bitowego numeru portu. Sumy kontrolne UDP wykorzystuje sumy kontrolne dla zapewnienia integralności danych. Algorytm sumy kontrolnej jest taki sam, jak ten, z którego korzysta protokół TCP (patrz: rozdział 7). Jeżeli suma kontrolna jest niewłaściwa, to pakiet jest odrzucany i nie są podejmowane żadne dalsze działania. Wskazówka: W przeciwieństwie do protokołu TCP stosowanie protokołu UDP nie jest obowiązkowe. Niektóre aplikacje, które zazwyczaj działają tylko w sieciach lokalnych (LAN), wyłączają obliczanie sumy kontrolnej poprzez wysyłanie wartości zero w polu Suma kontrolna. Nie uważa się jednak, aby było to dobrą praktyką. Ogólnie rzecz biorąc brak informacji jest lepszy niż złe informacje. Protokół UDP wykorzystywany jest tam, gdzie protokół TCP jest zbyt złożony lub zbyt powolny. Nie segmentuje on komunikatu, nie składa go ponownie po drugiej stronie i nie sprawdza, czy segmenty są we właściwej kolejności. Jest on więc nieodpowiedni do dostarczania długich komunikatów. Aplikacje sieciowe wymieniające małe jednostki danych (i w związku z tym mające do wykonania niewiele ponownego składania komunikatów), wykorzystują protokół UDP zamiast TCP. Na przykład protokół transferu plików podstawowych (TFTP) korzysta z UDP przy małych aplikacjach. Porty UDP Porty UDP zapewniają lokalizację do wysyłania i odbierania komunikatów UDP. Port UDP funkcjonuje jako pojedyncza kolejka komunikatów, która służy do odbierania wszystkich datagramów dla programu określonego za pomocą numeru portu protokołu. Oznacza to, że programy UDP mogą jednocześnie odbierać kilka komunikatów. Programy po stronie serwera, które wykorzystują porty TCP, nasłuchują komunikatów przychodzących pod dobrze znany numer portu. Wszystkie numery portów serwerów TCP o wartościach mniejszych niż 1024 (oraz niektóre wyższe numery) są zarezerwowane i zarejestrowane przez organizację przydzielania numerów internetowych (IANA). Tabela 8.1 podaje najczęściej używane dobrze znane numery portów serwerów UDP. Listę wszystkich zarezerwowanych numerów portów UDP można uzyskać pod adresem www.isi.edu/innotes/iana/assignments/port-numbers. Rozpoznawanie nazw Rozwiązywanie nazw NetBIOS odbywa się poprzez port UDP 137 albo za pomocą emisji pojedynczej do serwera nazw NetBIOS, albo też za pomocą emisji podsieci. Kwerendy dotyczące przetłumaczenia nazwy hosta DNS na adres IP wykorzystują port UDP 53. Obie te usługi korzystają ze swoich własnych schematów retransmisji, jeżeli nie otrzymają żadnej odpowiedzi na zapytania. Ponieważ datagramy emisji UDP nie są normalnie przekazywane poprzez routery IP, rozwiązywanie nazw NetBIOS w środowisku routowanym wymaga albo serwera nazw, albo plików statycznej bazy danych.

Tabela 8.1. Numery portów UDP Numer portu UDP Opis 53 Zapytania o nazwę systemu nazw domen (DNS) 69 TFTP 137 Obsługa nazw NetBIOS 138 Obsługa datagramów NetBIOS 161 Protokół prostego zarządzania siecią (SNMP) 520 Protokół routingu internetowego (RIP) Skrzynki mailslot Skrzyka mailslot to drugorzędny, zawodny mechanizm służący do wysyłania komunikatu z jednego komputera do drugiego przy użyciu protokołu datagramów użytkownika (UDP), gdzie oba komputery są identyfikowane po ich nazwach NetBIOS. Komunikaty mailslot mogą być emitowane w podsieci lub kierowane do hosta zdalnego. Aby skierować komunikat mailslot, musisz mieć jakąś metodę rozpoznawania nazw NetBIOS, taką jak usługa nazw internetowych systemu Windows (WINS). Łączność międzywarstwowa UDP Podobnie jak TCP, UDP znajduje się w warstwie transportu czterowarstwowego modelu TCP/IP. Jeżeli otrzyma jakiekolwiek opcje IP (takie jak Trasa źródłowa, Trasa rekordu oraz Znacznik czasu) od protokołu IP w warstwie internetowej, to przekazuje je jawnie do warstwy aplikacji. UDP zazwyczaj nie przyjmuje żadnych założeń dotyczących formatu, albo zawartości opcji, które przekazuje do, albo od aplikacji. Przekazuje również do warstwy aplikacji wszystkie komunikaty o błędach protokołu ICMP. Po otrzymaniu datagramu UDP jego adres określonego miejsca docelowego zostaje przekazany w górę do warstwy aplikacji. Program użytkowy albo określa źródłowy adres IP, który ma zostać użyty do wysłania datagramu UDP, albo pozostawia ten adres nieokreślony; w tym wypadku oprogramowanie do pracy sieciowej wybiera odpowiedni adres źródłowy. Kiedy dany host wysyła datagram UDP, to adres źródłowy jest adresem źródłowym hosta (albo jednym z adresów, jeżeli host ma wiele podłączeń). Struktura pakietów UDP Rysunek 8.1, uzyskany z pliku przechwytywania login.cap na CD-ROM, przedstawia datagram UDP. Struktura pakietu jest następująca: Port źródłowy dodatkowe 16-bitowe pole, które identyfikuje port procesu wysyłającego i jest domyślnie portem, do którego powinna być zaadresowana odpowiedź. Jeżeli pole to nie jest wykorzystywane, wstawiana jest wartość zero. Port docelowy 16-bitowe pole, które identyfikuje port UDP hosta docelowego i zapewnia węzeł końcowy do komunikacji.

Długość 16-bitowe pole, które wskazuje długość datagramu, łącznie z nagłówkiem i dalszymi danymi, w oktetach. Minimalna wartość, jaką może zawierać to pole (przy założeniu, że nie ma żadnych danych) to 8. Suma kontrolna 16-bitowe pole, które zawiera sumę kontrolną i jest wykorzystywane do sprawdzania integralności danych. Wartość sumy kontrolnej równa zero oznacza, że aplikacja w host cie wysyłającym nie wygenerowała sumy kontrolnej. Rysunek 8.1. Datagram UDP Protokoły multimediów czasu rzeczywistego Ruch multimediów, w skład którego wchodzi znaczna część potencjalnego ruchu emisji pojedynczej i (szczególnie) multiemisji, posiada właściwości, które różnią się od konwencjonalnego ruchu sieciowego i w związku z tym ma inne wymagania. Jeżeli na przykład dany odbiorca czeka na retransmisję TCP, to występuje zauważalna i niedopuszczalna przerwa w odbiorze danych audio, wideo lub innych danych wrażliwych na opóźnienia. Ponadto mechanizm powolnego startu kontroli przeciążeń TCP (patrz: rozdział 7) może kolidować z prędkością odbioru audio i wideo. Ponieważ nie ma żadnej stałej ścieżki, po której datagramy mogłyby przepływać przez Internet, nie ma w tradycyjnej transmisji TCP żadnego mechanizmu gwarantującego, że będzie dostępna szerokość pasma potrzebna do przesyłu multimediów, a protokół TCP nie zapewnia informacji o synchronizacji, co jest wymogiem kluczowym w przypadku obsługi multimediów. W związku z niestosownością transmisji TCP wzrasta znaczenie stosowania protokołu UDP do transmisji multimediów w czasie rzeczywistym. Protokoły wysokopoziomowe, takie jak protokół transportowy czasu rzeczywistego (RTP), protokół kontrolny czasu rzeczywistego (RTCP) oraz protokół przesyłania strumieniowego czasu rzeczywistego (RTSP) zazwyczaj działają poprzez UDP, chociaż ich definicje nie wykluczają stosowania innych protokołów. Protokoły te wymagają gwarantowanej szerokości pasma i są tutaj opisane w kontekście zarówno UDP, jak i Jakości usługi (QoS). Protokół rezerwacji zasobów (RSVP) jest mechanizmem QoS i jest opisany, wraz z QoS, w dalszej części niniejszego rozdziału. Protokół transportowy czasu rzeczywistego Protokół RTP, określony w specyfikacji RFC 1889, zapewnia usługi dostawcze typu end-to-end, aby zapewnić obsługę aplikacji, które transmitują dane czasu rzeczywistego. Dokument RFC 1890 określa profil przenoszenia ruchu audio oraz wideo poprzez RTP. Microsoft Netmeeting jest przykładem aplikacji opartej na RTP. W skład usług RTP wchodzi rozpoznawanie typu ładunku, numerowanie sekwencji oraz nadawanie znaczników czasu. Protokół zapewnia usługi dostawcze typu end-to-end, ale nie zapewnia zestawu wszystkich funkcji protokołu transportowego. Zazwyczaj RTP działa na wierzchu protokołu UDP i wykorzystuje jego usługi multipleksowania i sumy kontrolnej. Nagłówek RTP dostarcza informacji dotyczących synchronizacji, które są wykorzystywane do synchronizacji i wyświetlania danych audio i wideo. Informacje te mogą również określać czy

pakiety uległy utracie, czy też doszły w niewłaściwej kolejności. Nagłówek określa również typ ładunku, przy czym dozwolonych jest wiele typów danych i kompresji. Specyfikacje profilu pomocniczego oraz formatu ładunku konfigurują RTP do określonej aplikacji na przykład format ładunku może określać typ kodowania audio lub wideo przenoszony w pakiecie RTP. Dane zakodowane mogą być poddawane kompresji przed dostarczeniem. Aby ustanowić sesję RTP, aplikacja określa parę adresów docelowych transportu (jeden adres sieciowy plus porty dla RTP oraz RTCP). Każde medium w transmisji multimedialnej przenoszone jest w oddzielnej sesji RTP, co daje odbiorcy wybór czy odbierać, czy nie odbierać określonego medium. Specyfikacja RFC 1889 przedstawia wykorzystanie RTP w scenariuszu audio-konferencji Więcej informacji można uzyskać z tej specyfikacji RFC. RTP nie zawiera żadnych mechanizmów gwarantujących dostawę na czas, czy też dających gwarancje jakości usługi. Nie gwarantuje on dostawy, ani nie sprawdza, czy pakiety są odbierane w kolejności transmitowania. Nie zakłada też, że wykorzystywana sieć jest niezawodna. Niektóre aplikacje adaptacyjne nie wymagają takich gwarancji, ale w przypadku tych, które ich wymagają, RTP musi być wspomagany przez mechanizmy zapewniające rezerwację zasobów, jak kontrola wpływu danych Jakości usługi. Nagłówek RTP zawiera następujące pola: Wersja to 2-bitowe pole identyfikuje wersję RTP, aktualnie 2. Wypełnienie to 1-bitowe pole wskazuje czy pakiet RTP zawiera jeden, czy więcej oktetów wypełniających, nie będących częścią ładunku. Wypełnienie może być wymagane w przypadku algorytmów szyfrowania, mających stałe rozmiary bloków, lub w przypadku przenoszenia kilku pakietów RTP w jednostce danych protokołu niższego poziomu. Rozszerzenie to 1-bitowe pole wskazuje, czy po stałym nagłówku RTP następuje rozszerzenie nagłówka. Liczba CSRC (CC) to 4-bitowe pole określa liczbę identyfikatorów źródeł zasilających (CSRC), które następują po stałym nagłówku. Znacznik (M) to 1-bitowe pole umożliwia zaznaczanie w strumieniu danych istotnych zdarzeń, takich jak granice ramek. Typ ładunku to 7-bitowe pole identyfikuje format ładunku RTP i określa sposób jego interpretacji przez aplikację. Numer sekwencji to 16-bitowe pole zawiera numer sekwencji, który wzrasta o jeden z każdym wysłanym pakietem danych RTP i może być wykorzystywany przez odbiorcę do wykrywania utraty danych oraz do przywracania sekwencji pakietów. Znacznik czasu to 32-bitowe pole zawiera znacznik czasu, który odzwierciedla moment próbkowania pierwszego oktetu w pakiecie danych RTP. Znacznik czasu wykorzystywany jest przy obliczeniach synchronizacji i rozsynchronizowania. Obliczanie i stosowanie znaczników jest skomplikowane. Aby uzyskać szczegóły, odwołaj się do specyfikacji RFC 1889.

SSRC to 32-bitowe pole identyfikuje źródło synchronizacji (SSRC). Identyfikator ten wybierany jest losowo, aby dwa źródła synchronizacji w obrębie tej samej sesji RTP nie miały tego samego identyfikatora SSRC. Lista SSRC to pole może zawierać od 0 do 15 pozycji, każda o długości 32 bitów. Lista CSRC identyfikuje źródła zasilające dla ładunku zawartego w pakiecie. Liczba identyfikatorów określona jest w polu CC. Wskazówka: Pierwszych 12 oktetów nagłówka RTP obecnych jest w każdym pakiecie RTP, ale lista identyfikatorów CSRC jest obecna tylko wtedy, jeżeli są źródła zasilające. Protokół kontrolny czasu rzeczywistego Specyfikacja RFC 1889 określa również protokół RTCP. Każdy z uczestników sesji RTP okresowo transmituje pakiety RTCP do wszystkich pozostałych uczestników. Informacje zwracane do aplikacji mogą być wykorzystywane do kontrolowania wydajności oraz do celów diagnostycznych. Poza tym RTCP spełnia następujące funkcje: Dostarczanie aplikacji informacji podstawową funkcją RTCP jest dostarczanie aplikacji informacji dotyczących jakości dystrybucji danych. Każdy z pakietów RTCP zawiera statystyki nadawcy i/lub odbiorcy zawierające informacje dotyczące liczby wysłanych pakietów, liczby utraconych pakietów, rozsynchronizowanie pomiędzy przybyciami i tak dalej. Nadawcy, odbiorcy oraz monitory niezależne korzystają z tych informacji zwrotnych dotyczących jakości odbioru. Na przykład nadawcy mogą modyfikować swoje transmisje; odbiorcy mogą określać czy problemy są lokalne, regionalne, czy globalne, a administratorzy sieci mogą wykorzystywać te informacje do oceny wydajności sieci. Identyfikowanie źródła RTP identyfikator poziomu transportu dla źródła RTP znany jest jako nazwa kanoniczna (CNAME). Jest ona wykorzystywana do śledzenia uczestników sesji RTP. Odbiorcy używają CNAME do łączenia wielu strumieni danych w zestaw powiązanych sesji RTP. Na przykład mogą być identyfikowane i synchronizowane strumienie audio i wideo z tego samego źródła. Kontrolowanie interwału transmisji RTCP ruch kontrolny ograniczony jest do pięciu procent ogólnego ruchu sesji. Uniemożliwia to ruchowi kontrolnemu obezwładnianie zasobów sieci i umożliwia RTP rozbudowę do dużej liczby uczestników sesji. Limit ten narzuca ustawienie tempa, w jakim wysyłane są pakiety RTCP. Każdy z uczestników wysyła pakiety kontrolne do wszystkich pozostałych i dlatego może śledzić całkowitą liczbę uczestników i wykorzystywać tę liczbę do obliczania tempa, w jakim należy wysyłać pakiety RTCP. Przekazywanie minimalnej informacji kontroli sesji RTCP może być wykorzystywany do przekazywania minimalnej ilości informacji wszystkim uczestnikom sesji. Na przykład RTCP może nieść osobiste imię w celu identyfikacji danego uczestnika na wyświetlaczu użytkownika. Funkcja ta jest przydatna (na przykład) w przypadku sesji telekonferencyjnych, gdzie uczestnicy dołączają do sesji i opuszczają ją nieformalnie. Format pakietu RTCP jest złożony. Pakiety RTCP są złożeniami kilku typów pakietów, przedstawionych w tabeli 8.2. Oto bezpośredni cytat z RFC 1889:

Każdy z pakietów RTCP zaczyna się od stałej części, podobnej do części pakietów danych RTP, po której następują ustrukturowane elementy mogące mieć zmienną długość w zależności od typu pakietu, ale zawsze kończące się na granicy 32-bitowej. Wymóg wyrównania oraz pole długości w stałej części dołączone są, aby uczynić pakiety RTCP wieżowymi. Wiele pakietów RTCP może być sklejanych bez żadnych znaków rozdzielających, by utworzyć złożony pakiet RTCP, wysyłany w pojedynczym pakiecie protokołu niższej warstwy, na przykład UDP. Nie ma żadnej jasnej liczby indywidualnych pakietów RTCP w pakiecie złożonym, ponieważ od protokołów niższej warstwy oczekuje się dostarczenia ogólnej długości, w celu ustalenia końca pakietu złożonego. RFC 1889 jest wysoce szczegółowym 75-stronicowym dokumentem, który dostarczy Ci wszelkich potrzebnych informacji, jeżeli chcesz dogłębnie zbadać RTCP i RTP. Protokół przesyłania strumieniowego czasu rzeczywistego (RTSP) RTSP, określony w specyfikacji 2326, przesyła strumieniowo dane multimedialne w aplikacjach typu jeden do wielu przy użyciu emisji pojedynczej oraz multiemisji i obsługuje współdziałanie pomiędzy klientami a serwerami pochodzącymi od różnych producentów. Przesył strumieniowy rozbija dane na pakiety, które mają rozmiary odzwierciedlające dostępną szerokość pasma pomiędzy klientem a serwerem. Oprogramowanie użytkownika może jednocześnie odtwarzać jeden pakiet, rozpakowywać drugi i odbierać trzeci. Użytkownik może zacząć słuchać danych audio i oglądać obraz wideo prawie natychmiast, bez potrzeby pobierania całego pliku medialnego. W skład źródeł przesyłu strumieniowego może wchodzić zarówno podawanie danych na żywo, jak i zapamiętane klipy. Tabela 8.2. Typy pakietów RTCP Typ pakietu SR RR SDES BYE APP Opis Raport nadawcy, do statystyk transmisji i odbierania od uczestników będących aktywnymi nadawcami. Raport odbiorcy, do statystyk odbierania od uczestników nie będących aktywnymi nadawcami. Pozycje opisu źródła, łącznie z CNAME. Wskazuje koniec uczestnictwa. Funkcje specyficzne dla aplikacji. RTSP kontroluje wiele sesji dostarczania danych i określa środki wybierania kanałów dostaw (UDP). Działa on na górze protokołu RTP, aby kontrolować i dostarczać zawartość czasu rzeczywistego. Chociaż RTSP można używać przy emisji pojedynczej, może on pomóc w wygładzaniu przejścia do multiemisji IP przy użyciu RTP. RTSP jest niezwykle złożonym i silnym protokołem tekstowym. Dokument RFC 2326 ma długość ponad 90 stron i nie jest ani wskazane, ani stosowne, aby wgłębiać się tutaj w taką ilość szczegółów. Jeżeli chcesz uzyskać więcej informacji, odwołaj się do tego dokumentu. RTSP może być stosowany wraz z RSVP do ustanawiania i zarządzania sesji przesyłu strumieniowego z zarezerwowaną szerokością pasma. RSVP opisany jest w dalszej części tego rozdziału.

Jakość usługi (QoS) QoS systemu Windows 2000 jest zestawem wymagań usług, które musi spełniać sieć, aby zagwarantować odpowiedni poziom usług dla transmisji danych. Zaimplementowanie QoS umożliwia programom czasu rzeczywistego wydajne wykorzystanie szerokości pasma sieci. Jako że QoS daje gwarancję wystarczających zasobów sieciowych, zapewnia ona poziom usług podobny do poziomu w prywatnej sieci, sieci dzielonej przez ruch RTP/UDP oraz tradycyjny ruch TCP. Gwarancja QoS wskazuje poziom usługi umożliwiający programowi transmisję danych w sposób możliwy do przyjęcia i mieszczący się w granicach dopuszczalnej ramy czasowej. W skład implementacji QoS w systemie Windows 2000 wchodzi usługa zarządzania przepustowością podsieci (SBM), służąca do kontrolowania szerokości pasma w podsieci, oraz usługi kontroli ruchu służące do określania priorytetów i zarządzania ruchem. System Windows 2000 obsługuje kilka mechanizmów QoS, takich jak RSVP, usługi zróżnicowane (DiffServ), standard 802.1p określony przez Instytut Inżynierów Elektryków i Elektroników (IEEE), oraz QoS nośnika transferu asynchronicznego (ATM). Te mechanizmy QoS wykorzystują mechanizm interfejsu programowania aplikacji (API) standardowej jakości usługi (GQoS), który jest rozszerzeniem interfejsu programowania Windows Sockets (Winsock). GQoS zapewnia aplikacjom metodę rezerwowania szerokości pasma sieci pomiędzy klientem a serwerem. RSVP jest protokołem sygnalizacyjnym służącym do rezerwowania szerokości pasma dla indywidualnych przepływów danych w sieci. Dokonuje on rezerwacji dla każdego z nich i jest w związku z tym określany mechanizmem QoS na przepływ. RSVP opisany jest bardziej szczegółowo w dalszej części tego rozdziału. DiffServ definiuje 6 bitów QoS w nagłówku IP, które określają, jakie są priorytety pakietu IP. Ruch DiffServ może być przydzielony do jednej z 64 możliwych klas, znanych jako zachowania na każdy przeskok (PHB). IEEE 802.1p jest mechanizmem QoS określającym, w jaki sposób urządzenia, takie jak przełączniki ethernetowe, mają wyznaczać priorytety ruchu; definiuje on osiem klas priorytetów. DiffServ oraz 802.1p określane są jako zespolone mechanizmy QoS, ponieważ klasyfikują ruch według skończonej liczby klas priorytetów. Wskazówka: 6 bitów definiowanych przez DiffServ było wcześniej znanych jako bity typu usługi (ToS). Ustawianie bitów ToS za pomocą interfejsu Winsock nie jest już obsługiwane i wszystkie żądania typu usługi IP muszą być zgłaszane poprzez API GQoS, chyba że zmodyfikowany został parametr Rejestru DisableUserTOSSetting (patrz: dodatek A). Usługi zintegrowane poprzez nośnik transferu asynchronicznego (ISATM) automatycznie odwzorowują żądania GQoS na jakość usługi ATM w sieciach IP/ATM. Usługi zintegrowane poprzez małą prędkość transmisji bitów (ISSLOW) poprawiają zwłokę w przypadku ruchu priorytetowego na powolnych łączach sieci WAN. Dodatkowo aplikacje kontroli i zarządzania mogą kontrolować ruch poprzez API kontroli ruchu (TC), który pozwala aplikacji kontroli lub zarządzania dostarczać trochę jakości usługi aplikacjom niezgodnym z QoS. System Windows 2000 zapewnia również usługę zasad pod nazwą usługa kontroli wpływu danych Jakości usługi (QoS ACS), która umożliwia administratorom sieci kontrolę nad tym, kto dostaje QoS w sieci. Aby uzyskać bardziej szczegółowe informacje, odwołaj się do specyfikacji RFC 2205.

Protokół rezerwacji zasobów (RSVP) RSVP (określony w specyfikacji RFC 2205, uaktualnionej przez RFC 2750) jest protokołem konfigurowania rezerwacji zasobów, zaprojektowanym dla sieci usług zintegrowanych. Aplikacje proszą RSVP, aby ten zażądał określonej jakości usług typu end-to-end dla strumienia danych, a RSVP rezerwuje gwarantowane zasoby QoS. Zasoby dostarczane przez RSVP obsługują protokoły routingu emisji pojedynczej i multiemisji, i dają się skalować do dużych grup dostaw multiemisji. Host odbierający wykorzystuje RSVP, aby żądać określonej jakości usługi dla konkretnego strumienia danych od źródła danych. Żądanie rezerwacji RSVP składa się z określenia pożądanej jakości usługi typu end-to-end oraz z definicji zestawu pakietów, które mają tę QoS otrzymać. RSVP stosowany jest w środowiskach, gdzie rezerwacje QoS obsługiwane są poprzez ponowną alokację, a nie dodawanie zasobów. W przypadku ruchu multiemisji host wysyła komunikaty protokołu zarządzania grupami internetowymi (IGMP), aby dołączyć do grupy, a następnie wysyła komunikaty RSVP, aby zarezerwować zasoby na ścieżce (ścieżkach) dostaw tej grupy. IGMP opisany jest w rozdziale 5. RSVP zapewnia dostęp do usług zintegrowanych sieci rozległej, w związku z czym wszystkie hosty, routery i inne elementy infrastruktury sieciowej pomiędzy odbiorcą a nadawcą muszą obsługiwać RSVP. Jeżeli jakiś router albo przełącznik nie jest zgodny z RSVP, to komunikaty rezerwacji przenikają przez przeskok i jakość usługi typu end-to-end nie może być zagwarantowana. Jeżeli wszystkie elementy na trasie są zgodne z RSVP, to każdy z nich rezerwuje zasoby systemowe takie jak szerokość pasma, procesor, bufory pamięci aby zaspokoić żądanie QoS. Komunikaty kontrolne jakości usługi protokołu RSVP są również wysyłane, aby zarezerwować zasoby na wszystkich węzłach (rouerach i hostach) na (odwrotnej) ścieżce dostaw do nadawcy. Na każdym z węzłów na ścieżce odbiorca nadawca, RSVP dokonuje rezerwacji zasobów dla żądanego strumienia. Na każdym z węzłów pośrednich podejmowane są na żądanie dwa rodzaje działań: Żądanie zostaje spełnione lub odrzucone zgodnie z kontrolą wpływu danych i zasad. Kontrola wpływu danych ustala, czy dany węzeł ma dostępną wystarczającą ilość zasobów, a kontrola zasad ustala, czy użytkownik posiada upoważnienie do dokonywania rezerwacji. Jeżeli rezerwacja zostanie odrzucona, RSVP zwróci odpowiedniemu odbiorcy (odbiorcom) komunikat o błędzie, a aplikacja ustali czy wysłać dane teraz (za pomocą dostarczania przy użyciu dostępnych możliwości), czy zaczekać i ponowić żądanie później. Jeżeli rezerwacja może zostać przyjęta, to węzeł konfiguruje klasyfikator pakietów, aby wybrać właściwe pakiety danych przychodzących oraz harmonogram pakietów, aby zaimplementować żądaną QoS na interfejsie wychodzącym. Żądanie jest propagowane do węzłów znajdujących się wyżej w kierunku odpowiednich nadawców. Protokół transmituje również komunikaty rozmontowania, które uwalniają zasoby. RSVP jest protokołem o zmiennym stanie i wymaga, aby rezerwacja była okresowo odświeżana. Informacje dotyczące rezerwacji, albo stan rezerwacji, są buforowane w pamięci podręcznej każdego z przeskoków. Jeżeli protokół routingu sieciowego zmieni ścieżkę danych, to RSVP automatycznie zainstaluje stan rezerwacji na nowej trasie. Jeżeli nie zostaną otrzymane komunikaty odświeżania, to rezerwacje ulegną przedatowaniu i zostaną porzucone.

Protokół jest inicjowany przez odbiorcę, ponieważ inicjacja przez nadawcę nie daje się skalować do dużych scenariuszy multiemisji, które mają niejednorodnych odbiorców. Każdy z odbiorców dokonuje swojej własnej rezerwacji, a wszelkie różnice pomiędzy rezerwacjami rozpoznawane są przez RSVP. Jeżeli różni odbiorcy wymagają różnych zasobów, to zarówno nadawca, jak i routery scalają żądania rezerwacji przyjmując maksymalne żądane wartości. Komunikaty RSVP RSVP wykorzystuje typy komunikatów podane w tabeli 8.3 do ustanawiania i utrzymywania zarezerwowanych ścieżek ruchu w podsieci. Tabela 8.3. Typy i wartości komunikatów RSVP Typ wiadomości Funkcja Wartość typu PATH RESV Przenosi informacje dotyczące przepływu danych od nadawcy do odbiorcy. Komunikat PATH rezerwuje ścieżkę, którą żądane dane muszą przebyć wracając do nadawcy. Komunikaty PATH zawierają wymagania dotyczące szerokości pasma, charakterystyki ruchu sieciowego i informacji adresowych, takich jak źródłowe i docelowe adresy IP. Przenosi żądanie rezerwacji od odbiorcy. Komunikat RESV zawiera rzeczywistą rezerwację szerokości pasma, wymagany poziom usług i źródłowy adres IP. PATH-ERR Wskazuje na błąd w odpowiedzi na komunikat PATH. 3 RESV-ERR Wskazuje na błąd w odpowiedzi na komunikat RESV. 4 PATH-TEAR Usuwa stan PATH z trasy. 5 RESV-TEAR Usuwa rezerwację z trasy. 6 RESV-CONF Jeżeli komunikat RESV zostanie wysłany z obiektem potwierdzenia i dostępna jest wystarczająca szerokość pasma do spełnienia żądania, to do odbiorcy wysłany zostaje komunikat RESV-CONF. Nie gwarantuje to rezerwacji, ponieważ w dalszej kolejności może zostać otrzymane żądanie o wyższym priorytecie. Komunikat RSVP składa się ze wspólnego nagłówka, po którym następuje ciało składające się ze zmiennej liczby typowych obiektów zmiennej długości. Komunikat ma wspólny nagłówek, a każdy z obiektów ma swój własny nagłówek. Wspólny nagłówek RSVP składa się z następujących pól: Vers to 4-bitowe pole zawiera numer wersji, aktualnie 1. Flags to 4-bitowe pole zarezerwowane jest dla znaczników. Msg Type to 8-bitowe pole identyfikuje typ komunikatu. Odwołaj się do tabeli 8.3, aby uzyskać wartości typów. 1 2 7

RSVP Checksum to 16-bitowe pole zawiera sumę kontrolną. Wartość równa zero oznacza, że nie została przetransmitowana żadna suma kontrolna. Send_TTL to 8-bitowe pole zawiera wartość czasu istnienia IP, z którą komunikat został wysłany. RSVP Length to 16-bitowe pole wskazuje całkowitą długość komunikatu RSVP w bajtach, łącznie ze wspólnym nagłówkiem oraz obiektami o zmiennej długości, które następują po tym nagłówku. Każdy obiekt RSVP składa się z jednego lub większej liczby słów 32-bitowych z nagłówkiem złożonym z jednego słowa. Format nagłówka obiektu jest następujący: Length to 16-bitowe pole zawiera całkowitą długość obiektu w bajtach. Jest to zawsze wielokrotność 4 bajtów (32 bitów), a wartość minimalna to 4. Class-Num to 8-bitowe pole identyfikuje klasę obiektu. Klasy obiektów to NULL, SESSION, RSVP_HOP, TIME_VALUES, STYLE, FLOWSPEC, FILTER_SPEC, SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC, ERROR_SPEC, POLICY_DATA, INTEGRITY, SCOPE oraz RESV_CONFIRM. Odwołaj się do dokumentów RFC, aby uzyskać opisy tych klas oraz odpowiadające im wartości. Dwa bity bardziej znaczące tego pola wykorzystywane są do ustalania jakie działanie dany węzeł podejmuje, jeśli nie rozpozna klasy obiektu. C-Type to 8-bitowe pole identyfikuje typ obiektu. Każdy z typów obiektu jest niepowtarzalny w obrębie danej klasy obiektów, a pola Class-Num oraz C-Type mogą być w związku z tym używane razem jako 16-bitowa liczba, która definiuje niepowtarzalny typ dla każdego z obiektów. Kontrola ruchu Kontrola ruchu jest mechanizmem QoS, który uruchamia się, kiedy program kliencki zażąda Jakości usługi, a spełnia następujące zadania: zmniejsza opóźnienie oraz zwłokę (skumulowane opóźnienie) w transmisji ruchu sieciowego; pracuje z usługą kontroli wpływu danych Jakości usługi (patrz: dalsza część tego rozdziału) i protokołem RSVP w celu zapewnienia poziomu i priorytetu usług określonego w żądaniu szerokości pasma; zapewnia usługę dla klientów podsieci, które nie są zgodne z usługą kontroli wpływu danych Jakości usługi (chociaż programy klienckie muszą być przystosowane do współpracy z usługą QoS); kontroluje przepływ danych przez urządzenia, które nie korzystają z protokołu RSVP. Biblioteka DLL kontroli ruchu konfiguruje i ustala priorytety ruchu przy użyciu procesu klasyfikacji i tworzenia harmonogramu pakietów. Klasyfikator pakietów ustala klasę usługi, do której należy poszczególny pakiet. Pakiety są następnie kolejkowane przez poziom usługi, aby zostały obsłużone przez harmonogram pakietów. Harmonogram pakietów ustala plan wysyłania każdej kolejki pakietów i kontroluje priorytety, kiedy kolejkowane pakiety jednocześnie potrzebują dostępu do zasobów sieci. Bierze on informacje od klasyfikatora pakietów, tworzy

kolejki dla każdego przepływu danych, a następnie opróżnia kolejki w tempie określonym przez RSVP w momencie utworzenia przepływu. Podrozdział rozwiązań natychmiastowych niniejszego rozdziału opisuje, w jaki sposób należy instalować harmonogram pakietów QoS. Poziomy usług QoS konfiguruje poziom usług jako część właściwości ruchu dla każdego przepływu danych. Aby określić jakie jest wymagane ustawienie poziomu usług, należy zrozumieć zasady ruchu. Te dzielą się na dwie główne grupy: Ruch elastyczny szybkość dostarczania jest funkcją dostępnej szerokości pasma. Ruch elastyczny jest powolny, gdy przepustowość jest ograniczona, a szybki kiedy obfita. Nadawca danych automatycznie dostraja się do szybkości sieci. Programy transakcyjne, takie jak transfery dużej ilości danych, zazwyczaj generują ruch elastyczny. Ruch czasu rzeczywistego interwał czasu przybycia pomiędzy dowolnymi dwoma pakietami u odbiorcy musi być bardzo zbliżony do ich interwału wysłania. Ruch czasu rzeczywistego ma ograniczoną zdolność adaptowania się do zmieniających się warunków w sieci, a opóźnienia mogą znacząco obniżać zrozumiałość. Na przykład jeżeli ruch danych wideo doświadcza opóźnień międzypakietowych, to obrazy stają się zniekształcone i nie można ich oglądać. Usługa kontroli wpływu danych Jakości usługi systemu Windows 2000 (patrz poniżej) obsługuje trzy poziomy usług: Dostępne możliwości bezpołączeniowy model dostaw, który jest odpowiedni dla ruchu elastycznego. Pakiety wysyłane są bez gwarancji małych opóźnień, lub odpowiedniej szerokości pasma. Kontrolowane obciążenie usługa uprzywilejowana, która jest ustanawiana dla każdego elementu sieci. Przepływ, który otrzymuje usługę kontrolowanego obciążenia na składniku sieci, doświadcza niewielkiego, lub żadnego opóźnienia, czy utraty związanej z przeciążeniem. Nie jest jednak gwarantowana alokacja szerokości pasma typu end-to-end. Usługa gwarantowana przydziela gwarantowaną szerokość pasma. Kiedy każdy host na ścieżce danych, łącznie z routerami i przełącznikami, zapewnia tę usługę (to znaczy jest zgodny z QoS i RSVP), to gwarantowana jest szerokość pasma typu end-to-end. Dostępne możliwości są odpowiednie dla ruchu elastycznego, a pozostałe dwa poziomy są odpowiednie dla programów czasu rzeczywistego. Wszelka nie zarezerwowana szerokość pasma, lub szerokość pasma nie będąca w bieżącym użyciu, pozostaje dostępna dla innego ruchu. Usługa gwarantowana poprawia jakość transmisji, ale poważnie uderza w zasoby sieci i nie powinno się jej określać w przypadku ruchu elastycznego. Kontrola wpływu danych QoS (ACS QoS) Programy czasu rzeczywistego zwykle korzystają z protokołu RTP lub UDP do przesyłania danych. Ponieważ protokoły RTP i UDP są protokołami bezpołączeniowymi, niezawodność usługi dostarczania danych jest ograniczona. Aby wdrażać programy czasu rzeczywistego przy możliwej do przyjęcia szybkości ruchu, zasoby sieciowe muszą gwarantować pewien poziom dostępności.

Usługa kontroli wpływu danych, we współpracy z jakością usług (QoS) systemu Windows 2000, daje tę gwarancję. Kontrola wpływu danych QoS wyznacza jak, przez kogo i kiedy wykorzystywane są wspólne zasoby sieciowe. Każdy serwer systemu Windows 2000 w podsieci może zostać skonfigurowany jako host ACS QoS i będzie wtedy kontrolować szerokość pasma dla tej podsieci. Klient w podsieci przedkłada żądania priorytetu szerokości pasma do tego hosta, który następnie ustala, czy dostępna jest odpowiednia szerokość pasma, aby spełnić to żądanie, w oparciu o bieżący stan dostępności zasobów w podsieci oraz prawa zasad użytkownika kontroli wpływu danych QoS. Klienty systemu Windows 2000 są automatycznie konfigurowane, aby korzystać z kontroli wpływu danych QoS. Kontrola wpływu danych QoS zapewnia również obsługę klientów każdego innego systemu operacyjnego, który współpracuje z SBM. Funkcje kontroli wpływu danych QoS Kontrola wpływu danych QoS systemu Windows 2000 zapewnia kilka funkcji i korzyści: jest przejrzysta dla użytkownika; może pracować z różnymi konfiguracjami sieci; zabezpiecza usługę dostaw typu end-to-end z gwarancją małych opóźnień; zapewnia konsolę kontroli wpływu danych QoS, która umożliwia administratorowi scentralizowanie zasad i konfiguracji podsieci; pozwala administratorowi stosować tożsamości użytkownika i podsieci jako kryteria rezerwowania zasobów sieci oraz ustalania priorytetów; pozwala administratorowi na rozdzielenie zasobów sieci pomiędzy ruch o niskim priorytecie i ruch o wysokim priorytecie; obsługuje transmisję multiemisyjną komunikatów rezerwacji szerokości pasma; może przetwarzać komunikaty rezerwacji szerokości pasma, zaszyfrowane za pomocą zabezpieczeń IP (IPSec) systemu Windows 2000. Jak działa kontrola wpływu danych QoS Na rysunku 8.2 Klienty A, B oraz C zgłaszają żądania rezerwacji do hosta kontroli wpływu danych QoS (Serwer 1), żądając 20 Mb/s szerokości pasma. W tym scenariuszu Klienty A, B oraz C są odbiorcami, którzy chcą przesyłać strumieniowo dane z Serwera 2. Serwer 1 skonfigurowany jest, aby zezwalać na maksymalną przepustowość 50 Mb/s. (1) (2) (3) Potrzebuję Potrzebuję Potrzebuję 20 Mb/s 20 Mb/s 20 Mb/s OK (Serwer 1) OK (Serwer 1) Odmawiam (Serwer 1) Utworzę ścieżkę Utworzę ścieżkę Utworzę ścieżkę

20 Mb/s typu 20 Mb/s typu Mogę spróbować Serwer 2 end-to-end do end-to-end do połączenia przy użyciu Serwer multimediów Serwera 2 Serwera 2 dostępnych możliwości do Serwera 2, albo zaczekać Klient A Klient B Klient C (1) Mam 50 Mb/s. Klient A sprawdzony. 20 Mb/s przydzielone. (2) Mam 30 Mb/s. Klient B sprawdzony. 20 Mb/s przydzielone. (3) Mam 10 Mb/s. Żądanie Klienta C odrzucone. Sygnał nawigacyjny Serwer 1 QoS ACS Rysunek 8.2. Przykład kontroli wpływu danych QoS Kontrola wpływu danych QoS działa następująco: 1. Serwer 1 dokonuje multiemisji sygnałów nawigacyjnych informujących klienty, że jest obecny i gotowy do odbierania żądań serwer QoS ACS. Klient nie wyśle żądania do hosta, który nie wysyła sygnałów nawigacyjnych. 2. Klient A żąda 20 Mb/s rezerwowanej szerokości pasma. 3. Na Serwerze 1 tożsamość Klienta A jest weryfikowana przy użyciu protokołu Kerberos 5 (patrz: rozdział 10), a zasady kontroli wpływu danych QoS dla Klienta A są pobierane z usługi Active Directory. 4. Serwer 1 sprawdza zasady, aby zobaczyć czy Klient A ma wystarczające prawa do żądania, a następnie sprawdza czy wystarczające są poziomy zasobów sieci. 5. Serwer 1 zatwierdza żądanie i udziela rezerwacji 20 Mb/s przepustowości Klientowi A. 6. Klient A wysyła komunikaty RSVP PATH, aby zarezerwować szerokość pasma typu endto-end pomiędzy sobą a Serwerem 2. Jeżeli na ścieżce pomiędzy Klientem A a Serwerem 2 jest jeden lub więcej routerów, to szerokość pasma na tych routerach jest również rezerwowana (przy założeniu, że są one zgodne z QoS).

7. Ilość możliwej do zarezerwowania szerokości pasma, jaką może przydzielić Serwer 1 zostaje obniżona do 20 Mb/s. 8. Klient B żąda 20 Mb/s rezerwowanej szerokości pasma. Proces zostaje powtórzony. 9. Klient C żąda 20 Mb/s rezerwowanej szerokości pasma. Ponieważ dostępna jest niewystarczająca priorytetowa szerokość pasma, Serwer 1 odrzuca rezerwację. Aplikacja na Kliencie C ustala czy żądać teraz danych od Serwera 2 na poziomie dostępnych możliwości usługi, czy też zaczekać aż zwolni się priorytetowa szerokość pasma. Przykład ten zakłada, że Klienty A, B oraz C mają odpowiednie prawa oraz, że te same zasady użytkowników stosują się do wszystkich trzech spośród nich. W następnej części zobaczymy, w jaki sposób implementowana jest kontrola wpływu danych QoS oraz zasady kontroli wpływu danych. Implementowanie kontroli wpływu danych QoS Kontrola wpływu danych QoS wymaga kart sieciowych zgodnych ze standardem IEEE 802.1p i musi być zainstalowana na serwerze systemu Windows 2000 w domenie zawierającej podsieć, którą zamierzasz zarządzać. Harmonogram pakietów powinien być zainstalowany na każdym systemie końcowym w podsieci, dokonującym rezerwacji u kontroli wpływu danych QoS. Procedury instalowania kontroli wpływu danych QoS oraz harmonogramu pakietów opisane są w podrozdziale rozwiązań natychmiastowych niniejszego rozdziału. Wskazówka: Możesz instalować kontrolę wpływu danych QoS na wielu komputerach w tej samej podsieci. Tylko jeden host kontroli wpływu danych QoS faktycznie wykonuje usługi zarządzania szerokością pasma w dowolnym momencie. Pozostałe hosty kontroli wpływu danych QoS pełnią rolę rezerwy, przy czym jeden z nich automatycznie się uaktywnia, jeżeli główny host kontroli wpływu danych QoS przestanie działać. Zasady kontroli wpływu danych QoS Zasady kontroli wpływu danych QoS są połączeniem dwóch zasad, zasady dla przedsiębiorstw Dowolny użytkownik uwierzytelniony oraz zasady dla przedsiębiorstw Użytkownik nieuwierzytelniony. Wszystkie inne zasady kontroli wpływu danych QoS, które stworzysz, są wyjątkami od ogólnych reguł w domyślnych zasadach dla przedsiębiorstw. Zasady są hierarchiczne, od najbardziej określonych (konkretny użytkownik w określonej sieci) do najmniej określonych (zasady użytkownika dla wszystkich podsieci zarządzanych przez kontrolę wpływu danych QoS). Do tworzenia zasad dla przedsiębiorstw i podsieci centralnie dla wszystkich użytkowników możesz wykorzystywać konsolę kontroli wpływu danych QoS (patrz: część Rozwiązania natychmiastowe). Zasady dla przedsiębiorstw Ustawienia dla przedsiębiorstw określają zasady dla użytkowników obowiązujące w całej sieci i stosują się do wszystkich podsieci zarządzanych przez kontrolę wpływu danych QoS. Ustawienia te określa się przez skonfigurowanie domyślnych zasad dla przedsiębiorstw Dowolny użytkownik uwierzytelniony. Zasady te stosują się do wszystkich uwierzytelnionych użytkowników w domenie. W przypadku specjalnych wymagań użytkowników należy stworzyć zasady wyjątkowe

dla tych użytkowników. Zasady wyjątkowe zawierają tylko te zasady, które różnią się od zasad domyślnych. Użytkownik nieuwierzytelniony to każdy użytkownik na komputerze z zainstalowanym systemem Windows 2000, który nie jest zalogowany na koncie domeny, ale mimo to jest podłączony do sieci na przykład każdy użytkownik, który zaloguje się na komputerze w sieci przy użyciu konta lokalnego. Konfigurowanie domyślnych zasad dla przedsiębiorstwa Użytkownika nieuwierzytelnionego pozwala na określenie działań podejmowanych przez kontrolę wpływu danych QoS, kiedy nieuwierzytelniony użytkownik zgłosi żądanie priorytetowej szerokości pasma. Ustawienia domyślne zasad dla przedsiębiorstw wypisane są w tabeli 8.4. Tabela 8.4. Domyślne ustawienia zasad na poziomie przedsiębiorstwa Właściwości ruchu Dowolny użytkownik uwierzytelniony Szybkość danych 500 kb/s 64 kb/s Szczytowa szybkość danych 500 kb/s 64 kb/s Liczba rzędów 2 1 Zasady podsieci Użytkownik nieuwierzytelniony Ustawienia podsieci zawierają obiekt podsieci, który reprezentuje faktyczną podsieć zarządzaną przez kontrolę wpływu danych QoS. Domyślnie każda utworzona zasada podsieci korzysta z ustawień pochodzących z zasad dla przedsiębiorstwa. Dla każdego obiektu podsieci kontroli wpływu danych QoS można utworzyć zasady dla użytkowników; będą one obowiązywać tylko w podsieci, która je zawiera. Kiedy użytkownik prześle żądanie priorytetowej szerokości pasma, host kontroli wpływu danych QoS przeszukuje usługę Active Directory w celu znalezienia zasad na poziomie podsieci dla użytkowników żądających priorytetowej szerokości pasma dla tej podsieci, a następnie przeszukuje ją w poszukiwaniu zasad dla użytkowników na poziomie przedsiębiorstwa. Konfiguracja podsieci Właściwości podsieci nie należy mylić z zasadami dla użytkowników na poziomie podsieci. Obiekt podsieci kontroli wpływu danych QoS tworzy się w celu ustawienia ograniczeń ruchu dla podsieci, a także aby ustawić właściwości usługi kontroli wpływu danych QoS dla każdego hosta kontroli wpływu danych QoS zarządzającego podsiecią. Obiekt podsieci jest połączony z fizyczną podsiecią i hostami usługi kontroli wpływu danych QoS za pomocą adresu IP podsieci. Właściwości obiektu podsieci określają: ograniczenia ruchu sieciowego dla podsieci, właściwości rejestracji i kont dla hostów kontroli wpływu danych QoS, właściwości kontroli wpływu danych QoS dla każdego hosta kontroli wpływu danych QoS. Po utworzeniu obiektu podsieci z usługą kontroli wpływu danych QoS można dodawać zasady użytkowników na poziomie podsieci.

Zasady użytkowników Aby spełnić ogólne potrzeby użytkowników, można modyfikować zasady na poziomie przedsiębiorstwa dla dowolnego użytkownika uwierzytelnionego. Dodatkowe zasady trzeba tworzyć tylko wtedy, kiedy jakiś użytkownik ma inne wymagania. W niektórych przypadkach określony użytkownik ma wyjątkowe wymagania dotyczące zasobów w konkretnej podsieci. Aby spełniać specjalne wymagania, można tworzyć zasady użytkowników na poziomie ustawień podsieci. Na tym poziomie zapewnione są domyślne zasady użytkowników uwierzytelnionych i nieuwierzytelnionych, które mogą być zmieniane, aby spełnić potrzeby użytkowników wysyłających dane w podsieci. Zasady dla przedsiębiorstw stosują się do wszystkich sieci, chyba że dany użytkownik ma zasady w ustawieniach podsieci. Jeżeli dany użytkownik ma jedne zasady w ustawieniach dla przedsiębiorstw, a inne zasady w ustawieniach podsieci dla Podsieci A, to wtedy stosują się zasady dla podsieci, poza przypadkami, kiedy użytkownik wysyła, lub odbiera dane w Podsieci A. Hierarchia zasad Proces budowania profilu zasad stosowanego przez kontrolę wpływu danych QoS wobec każdego z użytkowników jest procesem zbiorczym. Początkowe zasady użytkownika ustalane są przez globalną wartość domyślną. Wtedy wartość dowolnego atrybutu może być uaktualniana w miarę dodawania każdej bardziej określonej zasady. Jeżeli dany użytkownik nie zostanie rozpoznany, to stosowane są zasady użytkownika nieuwierzytelnionego. Umożliwia to tworzenie zasad, które uniemożliwiają użytkownikom odwiedzającym korzystanie z zarezerwowanych zasobów w podsieci. Kiedy dany użytkownik ma zdefiniowany profil grupowy, to zasady stosowane są w następującej kolejności: 1. Zasady użytkownika dla bieżącej podsieci. 2. Zasady grupy w bieżącej podsieci. 3. Uwierzytelniony użytkownik w bieżącej podsieci. 4. Użytkownik w kontenerze przedsiębiorstwa. 5. Uwierzytelniony użytkownik w kontenerze przedsiębiorstwa. Rejestrowanie kontroli wpływu danych QoS Komunikaty kontroli wpływu danych QoS w podsieci mogą być śledzone dla celów statystyk wykorzystania sieci oraz aby sprawdzać, czy klienty podsieci i hosty kontroli wpływu danych QoS wchodzą we właściwe interakcje. Rejestrowanie w dzienniku może również pomóc w rozwiązywaniu problemów i dać pewność, że komunikaty RSVP są wysyłane i odbierane. Dzienniki kont Usługę kont QoS można skonfigurować, aby zbierała informacje dotyczące wykorzystania zasobów sieciowych dla poszczególnych użytkowników. Dzienniki kont mogą pomóc w identyfikowaniu źródeł problemów w sieci, a także mogą wspomóc planowanie wykorzystanie

sieci. Dzienniki kont mówią, kto korzysta z zasobów sieciowych oraz podają datę, i czas poszczególnych sesji. Podają one również informacje adresowe dla każdej sesji. Tabela 8.5 podaje pola informacyjne wchodzące w skład wpisu dziennika kont. Tabela 8.5. Pola dzienników kont Pole Data/godzina Informacje adresowe IP sesji Typ zapisu Identyfikator użytkownika Informacje adresowe IP dla ostatniego przeskoku Stan komunikatu Szczegóły komunikatu Dzienniki protokołu RSVP Opis Data i godzina zapisania komunikatu w formacie GMT. Adres IP odbiorcy, numer portu docelowego danych oraz dziesiętna wartość identyfikatora używanego protokołu (patrz: RFC 1700). Może to być jeden z następujących: Start Sender, Start Receiver, Stop Sender, Stop Receiver, Reject Sender lub Reject Receiver. Nazwa domeny i użytkownika wysyłającego lub odbiorcy. Adres IP ostatniego przeskoku i numer portu docelowego danych lub adres karty sieciowej zapisany w kodzie szesnastkowym (jeżeli host przekazujący komunikat jest urządzeniem o wielu podłączeniach). Może to być jeden z następujących: New, Modify, Stop Sender Reason, Reject Sender lub źródłowy adres IP przepływu danych. Może zawierać informacje dotyczące ruchu nadawcy i odbiorcy, przyczynę zatrzymania odbiorcy oraz przyczynę odrzucenia odbiorcy. Usługę dzienników można również skonfigurować tak, aby przechwytywała komunikaty protokołu RSVP od hostów kontroli wpływu danych QoS. Informacje z dziennika protokołu RSVP są zazwyczaj wykorzystywane do rozwiązywania problemów. Dzienniki te identyfikują datę i godzinę komunikatu RSVP, oraz informacje adresowe dla nadawcy i odbiorcy komunikatu. Tabela 8.6 podaje pola informacyjne wchodzące w skład wpisu dziennika protokołu RSVP. Niektóre z parametrów pól są skomplikowane, przy czym dodatkowe informacje można znaleźć w dokumentach RFC 2205, 2210, 2215 oraz 2216. RFC 1700 zawiera listę tożsamości protokołu z odnośnymi nazwami protokołów. Tabela 8.6. Pola dzienników protokołu RSVP Pole Data/godzina Typ wiadomości Opis Data i godzina wpisania komunikatu w formacie GMT. Jeden z następujących: PATH, RESV, PATH-ERR, RESV- ERR, PATH-TEAR, RESV-TEAR z dodatkowymi parametrami: Żądanie potwierdzenia, Zasięg, Styl rezerwacji.

Informacje adresowe IP sesji Informacje adresowe IP dla ostatniego przeskoku Interwał odświeżania Informacje adresowe IP nadawcy (patrz: RFC 2205). Adres IP odbiorcy, numer portu docelowego danych i dziesiętna wartość identyfikatora protokołu (patrz: RFC 1700). Adres IP dla ostatniego przeskoku i numer portu docelowego danych lub adres karty sieciowej zapisany w kodzie szesnastkowym (jeżeli host przekazujący komunikat jest urządzeniem o wielu podłączeniach). Ta wartość (w milisekundach) określa częstotliwość w milisekundach, z jaką wiadomość jest wysyłana. Adres IP nadawcy, numer portu docelowego danych i dziesiętna wartość identyfikatora użytego protokołu. Szybkość łańcucha Szybkość przesyłania danych dla łańcucha (patrz: RFC 2210, 2215 i 2216). Rozmiar łańcucha Prędkość szczytowa Rozmiar pakietu Rozmiar maksymalnej jednostki transmisyjnej (MTU) Adspec Pliki dziennika Rozmiar łańcucha, w którym są zgrupowane pakiety do transmisji. Prędkość maksymalna przesyłania pakietów. Minimalny rozmiar pakietu do transmisji. Maksymalny rozmiar pakietu do transmisji. To pole i poprzednie cztery pola tworzą parametry Tspec (patrz: RFC 2205, 2210, 2215 i 2216). Pozostałe pola w rekordzie wskazują na parametry ruchu Adspec odbiorcy. Dla plików dziennika kont i protokołu RSVP można określać kilka opcji, w tym liczbę tworzonych plików i katalog, w którym są one umieszczane. Zarówno pliki dziennika kont, jak i pliki protokołu RSVP są cykliczne. Jeżeli określi się maksymalny rozmiar pliku i plik go osiągnie, to można określić jedną z dwóch poniższych opcji: Jeżeli nie zostanie osiągnięta maksymalna liczba plików dziennika, tworzony jest kolejny plik dziennika. Ta opcja jest użyteczna przy badaniu historii transakcji wzorca. Nie są tworzone żadne nowe pliki dziennika. Bieżący plik jest zastępowany za każdym razem, gdy zostanie osiągnięty maksymalny rozmiar. W tym przypadku badanie rejestrowanych danych jest ograniczone do bieżących informacji. Nowe wpisy do dziennika są generowane ilekroć klient zażąda szerokości pasma. Rozmiar pliku dziennika lub liczba plików dziennika rośnie w miarę przedstawiania żądań. Ważne jest znalezienie równowagi pomiędzy potrzebą otrzymywania szczegółowych danych i wymogiem ograniczenia liczby i rozmiaru plików. Bardzo duże pliki dziennika mogą narażać na szwank wydajność, a poza tym łatwiej jest wyszukiwać określone zdarzenia w mniejszych plikach dziennika.

Wskazówka: Aby przeglądać pliki dziennika, nie trzeba zatrzymywać usług kontroli wpływu danych QoS. Szkice internetowe kontroli wpływu danych QoS Szkice internetowe zawierają szczegółowe informacje techniczne dotyczące protokołu RSVP, SBM i kontroli ruchu. Zapewniają one metodę dystrybucji dokumentów, które mogą być ostatecznie podawane do publikacji jako specyfikacje RFC, a także metodę uzyskiwania uwag. Następujące Szkice internetowe podejmują tematy związane z kontrolą wpływu danych QoS: Providing Integrated Services Over Low-Bit-Rate Links (Udostępnianie zintegrowanych usług przez mało wydajne łącza); SBM (Subnet Bandwidth Manager): A Proposal for Admission Control Over IEEE 802- Style Networks (SBM [Menedżer przepustowości podsieci]: Propozycja kontroli wpływu danych dla sieci typu IEEE 802); A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies (Ogólne informacje na temat dostarczania usług zintegrowanych przez współużytkowane i przełączane technologie IEEE 802 LAN); Integrated Services over IEEE 802.1D/802.1p Networks (Usługi zintegrowane przez sieci IEEE 802.1D/802.1p); Integrated Service Mappings on IEEE 802 Networks (Zintegrowane mapowanie usług w sieciach IEEE 802); RSVP Cryptographic Authentication (Uwierzytelnianie kryptograficzne RSVP); RSVP Extensions for Policy Control (Rozszerzenia RSVP dla kontroli zasad); Partial Service Deployment in the Integrated Services Architecture (Częściowe rozmieszczenie usług w architekturze usług zintegrowanych). Powyższe szkice można uzyskać od zespołu jakości usług grupy roboczej do spraw sieci Internet (IETF) pod adresem www.ietf.org/html.charters/wg-dir.html. Wskazówka: Dokumenty te w momencie pisania niniejszej książki są szkicami. W międzyczasie mogły już stać się specyfikacjami RFC. W celu uzyskania listy najnowszych specyfikacji RFC wejdź do witryny http://info.internet.isi.edu/in-notes/rfc/files. Rozwiązania natychmiastowe Przechwytywanie ruchu UDP Praca sieciowa Microsoft wykorzystuje UDP do logowania, przeglądania oraz do rozwiązywania nazw. W toku niniejszej procedury przechwytywany jest ruch rejestracyjny od klienta do kontrolera domeny (DC). Aby zmniejszyć rozmiary przechwycenia, ustawiany jest filtr