X.25 X.25 jest zbiorem rekomendacji definiowanym przez CCITT dla transmitowania danych przez sieci komutowane. Dostarcza interfejsu standardu CCITT do sieci komutowanych i stał się najszerzej używanym interfejsem dla sieci WAN. Ten interfejs obejmuje trzy niższe warstwy w Modelu Referencyjnym OSI. Przy warstwie fizycznej , standard X.25 zakłada interfejs X.21, ale może również wspierać intrfejsy V.35 i EIA RS232-D. W warstwie łącza danych, X.25 zakłada użycie LAPB (Link Access Protocol,Balanced) ale również wsparcie innych protokołów, takich jak starszy LAP i IBM Bisync (BSC) .W warstwie sieciowej, X.25 używa PLP (Packet -Level Protocol). X.25 jest przeznaczony do transmisji danych (ale nie głosu). Definiuje procedury dla wymiany danych między DTE (takim jak komputer) a siecią. Połączenie do tej sieci jest przedstawiane przez DTE, którym może być modem, multiplekser lub PAD (packet assembler/disassembler). Urządzenia asynchroniczne (takie jak PC) mogą być podłączone do sieci X.25
poprzez użycie PAD. X.25 używa LCN (logical channel numer) dla rozróżniania połączeń między DTE po obu stronach komunikacji. Te LCN′y czynią możliwym wysyłanie pakietów do sieci komutowanych na jednym końcu (bez kontroli drogi pakietów) a następnie wybranie pakietu na końcu odbiorczym. Interfejs obsługuje prędkość transmisji do 64 kilobitów na sekundę W 1992 roku została ona zwiększona do 2 Mbps/ X.25 również ma relatywnie wysoki narzut na sprawdzanie błędów i kolejność pakietów. X.25 nie określa jak pakiet powinien być dosatrczany przez sieć. Faktycznie, X.25 nie ma nic do powiedzenia o szczegółach transmisji sieciowych. Sam WAN jest reprezentowana jako sieć "chmury"(zakładając połączenia). X.25 jest odpowiedzialny za uzyskanie pakietów w tej chmurze na jednym końcu i pobranie ich na drugim. :
X.400 : X.400 jest standardem obsługi komunikatów zdefiniowanym przez CCITT. X.400 wydany został w dwóch głównych wersjach:
• Oryginał z 1984 oku, X.400/84, dostarczał podstawowych definicji i modelu.
• Wersja z 1988 roku, X.400/88.
Korekta z 1992 roku skierowana był dla dodatkowych błędów i niejasności, a także również definiował dwa nowe typu zawartości komunikatów : komunikaty EDI (Electronic Data Interchange) dla zastosowania w transakcjach biznesowych i komunikatach głosowych. Pojęcie Message Handling System (MHA) ma istotne znaczenie w obu wersjach, ale szczegóły MHS są nieco inne. Podobnie obie wersje obejmują Message Transfer Service (MTS) jak i komponent MHS, ale zawartość tych MTS się różni. Wersja X.400/84 działała tylko z interfejsem MHS dla użytkowników końcowych. W X.400/88, MHS jest obiektem, który ma interfejsy dla komunikacji z użytkownikami końcowymi, z innymi usługami CCITT i specjalnymi i możliwie z innymi sieciami. Seria zaleceń X.400 odnosi się do treści i funkcjonowania MHS i sposobu w jaki MHS komunikuje się z jednostkami zewnętrznymi. Dokumenty nic nie mówi o tym jak implementować te zalecenia. MHS zawiera kilka innych obiektów jako komponenty, w tym MTS.
Składowe X.400
MHS składa się z następujących elementów:
• UA (User Agent) : Proces aplikacji (AP) , który zapewnia użytkownikowi końcowemu dostęp do MHS. UA są wykorzystywane w obu wersjach.
• AU (Access Unit) : Proces, który zapewnia bramkę między MTS a innymi usługami CCITT. AU są używane tylko w wersji 88
• PDAU (Physical Delivery Access Unit) : Typ AU , który zapewnia bramkę między MTS a usługami, które obejmują fizyczne dostarczanie. Używane tylko w wersji 88
• MS (Message Store) : Archiwum używane jako czasowy magazyn dla komunikatów dopóki nie zostaną przekazane do miejsca przeznaczenia. Message Store Access Protocol (MSAP) jest używane do komunikowania się z tym magazynem. MS są używane tylko w wersji 88
• MTS (Message Transfer System) : Proces, który przesyła wiadomości między użytkownikami.. MTS′y opierają się na własnych komponentach dla uzyskania tego transferu. MTS są używane w obu wersjach.
• MTA (Message Transfer Agent) : Składowa MTS, MTA przesyła komunikaty do innego MTA lub jednostki przeznaczenia (którą może być UA, MS, AU lub PDAU). MTA są używane w obu wersjach , ale różnią się szczegółami
Dystrybucja elementów MHS
Elementy MHS mogą być dystrybuowane na kilka sposobów. Te warianty różnią się w położeniach MTA i elementach, które zapewniają interfejs dla MHS (na przykład UA i AU). Wersja 1984 dostarcza tylko UA dla takiego interfejsu. Elementy mogą być dystrybuowane jak następuje:
• Tylko interfejsy na maszynie, jeśli kiedy stacje robocze mają dostęp do MHS przez serwer. W tym przypadku, serwer ma MTA, a stacja robocza musi uruchomić tylko UA
• Tylko MTA na maszynie, takie jak na serwerze, który zapewnia dostęp MHS do stacji roboczej, opisany powyżej
• MTA i interfejsy na tej samej maszynie, kiedy dostęp jest przez terminal
Zarządzanie domenami
Aby uczynić e-mail prawdziwie przydatnym, musi być globalny, co oznacza ,że MHS musi być dostępny na całym świecie. Aby działać ze światowym MHS, X.400 definiuje zarządzanie domenami (MD).Zarządzanie domenami jest ograniczonym - ale nie koniecznie ciągłym - obszarem którego możliwości zarządzania komunikatami działa pod kontrolą jednostki zarządzającej,. Zdefiniowano dwa typy zarządzania domenami:
ADMD(Administration Management Domain) : Obszar sieci zarządzanej przez CCITT. Na przykład, ADMD może być usługa pocztowa.
• PRMD (Private Management Domain) : Obszar sieci zarządzanej przez organizację prywatną. ADMD mogą łączyć się z PRMD ale PRMD nie mogą łączyć dwóch ADMD
X.400 i Model Referencyjne OSI
Związki między X.400 a Modelem Referencyjnym OSI zależą od wersji X.400. Wersja 1984 pokrywa warstwy prezentacji i aplikacji. Dodatkowo X.400/84 subdzieli warstwę aplikacji na górną warstwę UA (UAL) i niższą warstwę transferu komunikatów (MTL). Użytkownicy współdziałają z UAL, a UAL w rezultacie komunikuje się z MTL poniżej. UAE przenosi funkcje warstw przy UAL. Wersja 1984 definiuje interpersonalny protokół komunikowania (znany jako P2) dla komunikacji między UAE. Wersja 1988 odrzuca podwarstwy, ogranicza definicję modelu do warstwy aplikacji. Czyni to łatwiejszym implementację wersji 1988.
X.500 : Specyfikacja CCITT X.500 Directory Services zapewnia standardy i przewodniki dla przedstawienia, dostępu i używania informacji przechowywanej w Directory. W tym kontekście, Directory zawiera informacje o obiektach. Obiekty te mogą być plikami, jednostkami sieci lub innym typem jednostek.
Funkcje Directory Service
X.500 Directory Services są procesami warstwy aplikacji. Usługi Dirrectory mogą być używane dla różnych zadań, w tym:
• Zapewnienie globalnej, zunifikowanej usługi nazewniczej dla wszystkich elementów w sieci
• Tłumaczenie między nazwami i adresami sieci
• Zapewnienie opisowych obiektów w katalogu. Opisowe są listingi atrybutów i wartości powiązanych z tymi obiektami.
• Zapewnienie unikalnych nazw dla wszystkich obiektów w Directory. Wszystkie aliasy dla obiektu szacowane dla unikalnej nazwy obiektu
W zależności od kontekstu w którym usługa Directory będzie używana, informacja może być zorganizowana jako przestrzeń nazw lub jako książka adresowa.
Direcotry Information Bases (DIB)
Informacje dla usługi Directory jest przechowywana w Directory Information Base (DIB). Ta informacja jest zorganizowana pod względem pozycji i atrybutów. Pozycje odpowiadają obiektom w sieci; atrybuty odpowiadają właściwościom powiązanym z obiektami. Informacja jest przedstawiana za pomocą ASN.1 (Abstract Syntax Notation 1). Informacja w DIB jest zorganizowana w strukturze drzewa, znanej jako Directory Information Tree (DIT). DIT przedstawia logiczną organizację zawartości Directory. Każdy węzeł w drzewie przedstawia typ obiektu. Węzły pośrednie (elementy z subdrzewami pochodzą od nich) generalnie służą funkcjom organizacyjnym. Subdrzewa takiego węzła pośredniczącego przedstawiają obiekty pochodząc z typów obiektu węzła. Liście węzła, które są elementami bez subdrzew, odpowiadają określonym obiektom. Relative Distingushed Name (RDN) jest jednym z atrybutów powiązanym z każdym obiektem w katalogu. RDN określa lokalną nazwę obietu, która może lub nie być unikalna.. Ponieważ istnieją ograniczenia w sposbie w jaki obiekty są ze sobą powiązane , etykiety powiązane z każdym obiektem dostarczają informacje o relatywnych położeniach obiektów w DIT:
• C, które przedstawia Country i jest najwyżej zgrupowanym polem w DIT. Takie pole może być umieszczone tylko bezpośrednio poniżej roota
• O, które oznacz Organization i jest kolejnym bardziej ogólnym pogrupowanym polem (po Country). Jeśli jest, pole O musi być umieszczone albo bezpośrednio poniżej roota lub bezpośrednio poniżej węzła Country
• OU, który przedstawia Organizational Unit, i jest poziomeme pośrednim grupowanych pól. Pole OU może poajwić się tylko poniżej pola O
• CN, przedstawia Common Name i jest polem dolnego poziomu. Pole CN może być użyte tylko z węzłem liścia
Zasady określające dostępność położeń dla różnych pól są częścią schematu dla katalogu. Każdy obiekt ma unikalne położenie w DIT. Aby zidentyfikować obiekt jednoznacznie, musisz określić wszystkie nazwy w ścieżce do tego obiektu. Aby to zrobić, wylistuj każdy RDN w ścieżce z roota do tego obiektu. Łańcuch tych RDN′ów jest jednoznacznym Distinguished Name , lub DN , obiektu. DIB może być dystrybuowany przez sieć lub sieć wewnętrzną. Dla uproszczenia dostępu i użycia, część lub wszystkie Direcotry mogą być zreplikowane w wielu położeniach w sieci lub sieci wewnętrznej. Kiedy istnieją repliki, trzeba podjąć decyzję jak obsłużyć aktualizacje. Istnieją trzy możliwości dla dokonania zmian w Directory:
• Nie są dozwolone zmiany ani w oryginale ani replikach
&bull. Zmiany muszą być dokonane w oryginale, który musi potem okresowo informować wszystkie repliki o aktualizacji. Jest to znane jako ułożenie master/shadow ponieważ shadow jest określeniem repliki. To pojęcie zostało wprowadzone w specyfikacji 1992 X.500
• Zmiany muszą być dokonane albo w oryginale albo replice. Inne położenia będą aktualizowane zgodnie z harmonogramem. W niektórych sieciach, aktualizacje muszą być natychmiastowe; w innych aktualizacje są dokonywane w regularnych odstępach czasu. Jest to znane jako mechanizm aktualizacji peer-to-peer. Pomimo takiej samej nazwy, taki mechanizm nie jest koniecznie powiązany z siecią peer-to-peer
DIB może być modyfikowany lub aktualizowane często. Jeśli repliki są również modyfikowane, wtedy synchronizacja zmian jest zasadnicza. Synchronizacja zapewnia ,że wszystkie wersje ionformacji Directory są aktualne i ,że każdy używa tej samej wersji. Aktualizacja zależy od dostępności wspólnej ramki czasowej jako odniesienia. Czas odniesienie nie musi być poprawny; musi być tylko współdzielony przez DIB i wszystkie repliki.
Używanie DIB
Dostęp do informacji w DIB, X.500 zapewnia przez Directory User i Directory System Agents (DUA i DSA, odpowiednio) Końcowy użytkownik uzyskuje informację z usługi Directory przez pracę z DUA. DUA komunikuje się z DSA, którego zadaniem jest dostęp i działanie z aktualnym DIB. DUA komunikuje się z DSA przez DAP (Directory Access Protocol). Komunikacja między DUA a DSA używa dowolnego z trzech portów, które są określone w X.500:Read, Search lub Modify (port jest dostępem do usługi z perspektywy użytownika protokołu) Każdy z tych portów może obsłużyć ograniczoną liczbę i zakres działań:
• Port Read może obsłużyć Read, Compare i Abandon
• Port Search może obsłużyć List i Search
• Port Modify może obsłużyć Add Entry, Remove Entry. Modify Entry i Modify RDN
W niektórych przypadkach, szczególnie z dystrybuowaniem Directory, DSA mogą używać się wzajemnie do pomocy. Taka interakcja używa DSP (Direcotry System Protocol). Wersja 1988 rekomendacji X.500 polega na usługach uwierzytelniania dostępu do informacji Directory lub elementów. Poprawka 1992 dodaje kontrolę dostępu jako mechanizm. Z nią, Directory może mieć powiązaną z nim listę kontroli dostępu. Lista ta określa to może mieć dostęp do elementów Directory jak również rodzaj dostępu na jaki zezwala
Miary bezpieczeństwa X.500
Aby pomóc zapewnić ,że nieautoryzowani użytkownicy nie uzyskają dostępu do DIP, podejmowane są kroki dla uwierzytelnienia każdego użytkownika. Środowisko uwierzytelniania X.500 określa dwa poziomy uwierzytelnienia:
• Proste uwierzytelnienie, które wymaga tylko poprawnego hasła od użytkownika
• Silne uwierzytelnienie, które używa szyfrowania aby pomóc chronić informacje.
Dodatkowo, środowisko uwierzytelniania wspiera użycie podpisów cyfrowych pomagających zabezpieczyć komunikat lub informację przed sfałszowaniem, i stosowanie certyfikatów dla zapewnienia ,że klucze szyfrowania są jednoznaczne i znane tylko uwierzytelnionym stronom
xB/tB szyfrowanie : Szyfrowanie xB/tB jest ogólną etykietą dla dowolnych kilku schematów tłumaczenia danych , który może służyć jako wstęp do kodowania sygnału w telekomunikacji lub kontekście sieciowym. W xB/tB, każda grupa z bitów jest przedstawiana jako symbol y-bitowy. Symbol ten jest powiązany ze wzorcem bitowym , który jest potem kodowany przy użyciu standardowej metody kodowania sygnały (zazwyczaj NRZI). Tu mamy powszechnie używane schematy translacji tego rodzaju:
• 4B/5B, używane w sieciach FDDI
• 5B/6B używane w standardzie 100Base VG fast Ethernet, proponowanym przez Hewllet=Packard
• 8B/10B, używanym w sieciach SNA (System Network Administration)
XDR (Eternal Data Representation) : Abstrakcyjna (niezależna od maszyny) składnia dla opisania struktyury danych. XDR stworzył Sun Microsystem jako część ich Network File System (NFS), i funkcyjnie jest porównywalny z Abstract Sytnax Notation One (ASN.1) używanym w Modelu referencyjnym OSI
Xmodem : Xmodem jest popularnym protokołem transferu plików dostępnym w wielu "półkowych" pakietach komunikacyjnych. Xmodem dzieli dane do transmisji na bloki. Każdy blok składa się ze znaku startu nagłówka, numeru bloku, 128 bajtow danych i sumy kontrolnej. Xmodem-CRC dodaje bardziej rygorystyczną metodę kontroli błędów przez użycie cyklicznej kontroli redundacji (CRC) dla wykrywania błędów transmisji
XMS (Extended Memory Specification) : Specyfikacja Microsoft dla pamięci rozszerzonej. Aby uzyskać dostęp do pamięci rozszerzonej, programista powinien użyć sterownika XMS (np. HIMEM.SYS)
XON/XOFF : W asynchronicznej komunikacji, znaki używane do kontroli przepływu danych. XOFF (ASCII 19 lub Ctrl-S) mówi nadawcy aby zatrzymał transmisję do odwołania; XON (ASCII 17 , lub Ctrl-Q) mówi nadawcy aby wznowił transmisję po XOFF