Sieci domowe (cz. V)

VHN (Versatile Home Network)

Specyfikacja VHN została opracowana przez VESA (Video Electronics Standards Association) Home Network Committee, a sfinalizowana przez VESA /CEA R7.4 Committee. Jest zdefiniowana w EIA/CEA-851 Version 1 z października 2000 r.; EIA jest akredytowanym przy ANSI organem standaryzującym.

VHN jest "domowym Internetem" w takim rozumieniu, że określa, jak podsieci w rodzaju Ethernetu lub Bluetootha mogą być zintegrowane w jedną, szerokopasmową sieć cyfrową. Definiuje szkieletową architekturę używającą IEEE 1394b, długodystansowej wersji IEEE 1394. Określa IP jako protokół warstwy sieciowej, specyfikuje podzbiór TCP/IP dla transportu sieciowego oraz definiuje metody przydzielania urządzeniom adresów IP. Urządzenia lub podsieci nie-IP zostaną przystosowane przez użycie proxy IP w sterownikach klastrów.

VHN specyfikuje medium i wszystkie siedem warstw dla sieci szkieletowej IEEE 1394. Określa także warstwy od trzeciej do siódmej dla podsieci, która łączy się ze szkieletem. Pierwsza wersja specyfikacji definiuje częściowo metodę sterowania w połączeniach użytkownik-urządzenie (User-to-Device) i urządzenie-urządzenie (Device-to-Device) oraz sposób rozpoznawania. Druga wersja będzie skompletowana prawdopodobnie na początku 2002 r. Uzupełni ona te specyfikacje o telefonię IP, bezpieczeństwo sieciowe i zarządzanie siecią.

VHN próbuje sformułować porozumienia z UPnP, gdyż ta specyfikacja jest bardzo podobna do VHN, i z OSGi. Współpracuje także z HAVi w celu opracowania interfejsu VHN/HAVi. Chociaż VHN jest oparty na szkielecie IEEE 1394b, to nie jest zależny od protokołu 1394, lecz tylko od transportu w szkielecie. Urządzenia nie muszą być kompatybilne z IEEE 1394, aby mogły uzyskać dostęp do sieci domowej VHN.

Sieci domowe w ujęciu IETF

Rozstrzyganie problematyki normalizacyjnej sieci domowych na forum IETF zalicza się do najważniejszych wydarzeń. Jak można się było przekonać, istnieje sporo technologii umożliwiających utworzenie sieci w domu. Przykładami mogą być X.10, LonWorks, VHN, Jini, UPnP czy HAVi/1394. Jednak dzień dzisiejszy tych technologii charakteryzuje się brakiem szerokiego wsparcia kontroli dostępu od strony Internetu i współpracy między urządzeniami przystosowanymi do różnych technologii sieciowych. Zdolność do zapewnienia takiego wsparcia zaowocuje z pewnością nowymi pomysłami. Dobrze byłoby przed opuszczeniem biura połączyć się ze swoją siecią domową i nastawić kuchenkę mikrofalową lub wyregulować temperaturę... Można wymyślić wiele scenariuszy. Ale powstał już dokument, w którym zestawiono wiele warunków, których spełnienie umożliwi współpracę sieci oraz dostępność.

W dokumencie IETF Requirements for Networked Appliances: Wide-Area Access, Control, and Interworking z marca 2001 znajdują się najważniejsze wymagania, które w przyszłości będą stanowiły podstawę zintegrowanej sieci domowej, komunikującej się ze światem zewnętrznym za pośrednictwem bramy rezydentnej, czyli bramy usług.

Wybrane terminy

  • Interpretacja terminów zawartych w RFC 2119 - MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY i OPTIONAL - jest w sieciach domowych taka sama jak we wszystkich sieciach opartych na protokołach IETF lub zaakceptowanych przez to gremium.

  • NA (Networked Appliances) - jedno z najważniejszych określeń oznaczające w pewnym uproszczeniu urządzenie przystosowane do pracy w sieci. Definicja jest trudna, gdyż takim urządzeniem może być również pralka, lodówka, telewizor, ekspres do kawy czy budzik. Najogólniej NA jest urządzeniem dedykowanym, wyposażonym w przynajmniej jeden układ scalony, dzięki któremu może funkcjonować w sieci. NA może mieć globalny adres IP lub lokalny (kiedy znajduje się za proxy lub zaporą ogniową). A kiedy nie wspiera IP, musi mieć przypisany adres ogólny.

  • RGW (Residential GateWay) - brama rezydentna, brama usług, określona na rysunku 3.

    Niektóre wymagania

  • Oprócz wspomnianych wcześniej dostępności urządzeń NA zdefiniowano także funkcje jednostki sterującej - kontrolera AC (Appliance Controller). Kontroler musi zapewnić komunikację między NA a siecią IP. Jednak zasadniczym kryterium jest przezroczystość: współpraca między sieciami w różnych technologiach musi być przezroczysta. Warunek ten stosuje się zarówno do sieci w rodzaju X.10, IEEE 802.3 i 802.11 czy Bluetooth, jak też HAVi, UPnP oraz Jini.

  • Urządzenia NA powinny być przenośne w obrębie domeny domowej, między domenami domowymi, w domenie dostawcy usług i między usługami domen operatorów powiązanych umowami. Konfigurowanie NA powinno się charakteryzować opcjami autokonfiguracji, dzięki którym uprości się i zminimalizuje proces konfiguracji użytkownika.

  • Ponieważ specyficzna nazwa NA może nie być znana, musi istnieć mechanizm wyszukiwania oparty na dobrze znanych językach i schematach nazw.

  • Musi istnieć powiązanie między klasyfikacją adresów a wyborem przypadków. Innymi słowy - muszą być na przykład wyszukiwane wszystkie kamery monitorujące lub tylko określona.

  • Wszystkie znaki w schemacie adresowania muszą być zgodne z UTF-8.


  • TOP 200