Модул атм компютърни комуникации
Изтегляне 125.74 Kb.
|
- Навигация на страницата:
- Фигура 5-1 Връзка на АТМ функционалните нива с OSI относителният модел
- Как работи LAN емулацията
- Фигура 5-4 Напълно свързана емулирана LAN
- АТМ интерфейс за обмен на данни
- Фигура 5-6 Формат на АТМ DXI пакета
- Фигура 5-7 АТМ DXI Mode 1a и Mode 1b протоколна архитектура за AAL5
- ATM интерфейсна процесорна карта
- Фигура 5-9 AIP свързва LAN-овете към ATM Fabric
|
Модул 6. АТМ Асинхронният трансферен режим (ATM) е развиваща се технология създадена за високоскоростен трансфер на глас, видео и данни в частни и обществени мрежи по начин спестяващ значително средства. ATM е плод на усилията на Study Group XVIII от International Telecommunication Union Telecommunication Standardization Sector (ITU-T, бившият Consultative Committee for International Telegraph and Telephone [CCITT]) и American National Standards Institute (ANSI) за прилагане на технология за много високо ниво на интеграция (VLSI) при трансфера на данни в обществените мрежи. Официално АТМ е дефиниран в CCITT I.361, като раздел от Broadband Integrated Services Digital Network (BISDN). В момента се правят усилия за въвеждане на АТМ технологията в частните мрежи и гарантиране на съвместната работа на частни и обществени мрежи от така нареченият ATM Forum, който е основан съвместно от Cisco Systems, NET/ADAPTIVE, Northern Telecom и Sprint през 1991 година. Тази глава разглежда текущите ATM технологии, които мрежовите специалисти могат да използват при изграждане на своите мрежи. Тя също така съдържа препоръки за изграждане на мрежи неизползващи АТМ в момента по такъв начин, че да бъде въвеждането на АТМ в бъдеще максимално изгодно. Засегнати са следните теми:
АТМ общо описание АТМ съчетава силните страни на поделеното по време мултиплексиране (TDM), чиито фиксирани времеви интервали се използват от телефонните компании за пренасяне на глас без изкривявания и предимствата на мрежите основани на пакетен пренос на информацията, чиито променливи по размер информационни единици се използват от компютърни мрежи като Internet, за ефективно доставяне на информацията. Използвайки силните страни на TDM, АТМ избягва същевременно неговите слабости, както и слабостите на PSDN. Чрез използването на клетки с фиксиран размер, АТМ комбинира независимостта от времето на TDM и ефективността на PSDN. ATM формат на клетката ATM клетките се състоят от 5 служебни байта и 48 байта за данни. Две от служебните полета се използват за направление на АТМ клетката през АТМ мрежата.
VPI и VCI полетата идентифицират следващият мрежови сегмент, през който клетката трябва да премине по пътя към крайното си назначение. Понятието “виртуален канал” е еквивалентно на това “виртуална връзка”, тоест и двете описват логическа връзка между двата края на комуникационната линия. “Виртуален път” представлява логическото групиране на виртуални връзки позволяващо на АТМ комутатора да извършва действия с групи от виртуални връзки. АТМ функционални нива АТМ се състои от три функционални нива – АТМ физическо ниво, АТМ същинско ниво и АТМ адаптационно ниво – които отговарят като цяло на ниво 1 и части от ниво 2 (като контрола за грешки и разделянето на данните) на Open System Interconnection (OSI ) относителен модел както е показано на фиг. 5-1. Фигура 5-1 Връзка на АТМ функционалните нива с OSI относителният модел 
АТМ физическото ниво контролира предаването и приемането на данни от физическата среда. То също така следи за границите на АТМ клетките и ги пакетира в подходящият тип опаковка в зависимост от използваната физическа среда. Над физическото ниво се намира същинското АТМ ниво, което се грижи за установяването на виртуални връзки и пропускането на АТМ клетките през АТМ мрежата. Веднага над АТМ същинското ниво се намира АТМ адаптационното ниво, което извършва прехода от големи service data units (SDUs) (например видео потоци и пакети от данни) на процеси от по-високи нива и АТМ клетки. Няколко АТМ адаптационни нива са описани засега. Те са разгледани по-нататък в тази глава. Cisco маршрутизаторите в момента поддържат АТМ адаптационно ниво 5 (AAL5), което се използва за пренос на по-голяма част от не-SMDS данните, като класически IP през АТМ и LAN емулация, а AAL3/4 за SMDS трафик. АТМ адресация Атм форумът е адаптирал подмрежови модел на адресиране, при който АТМ нивото е отговорно за преобразуване на адресите от мрежовото ниво към АТМ адреси. Реазработени са няколко формата на АТМ адреси. Обществените АТМ мрежи обикновено използват Е.164 цифри, които са употребявани също така от теснолентовите ISDN (N-ISDN) мрежи. АТМ адресните формати са разработени на базата на ISO Network Service Access Point (NSAP) адреси, но те сочат SubNetwork Point of Attachment (SNPA) адреси. Включването на МАС адреса в АТМ адреса прави лесно назначението на АТМ адреси във вече съществуващата LAN мрежа. LAN емулация LAN емулацията (LANE) е услуга която осигурява съвместна работа на АТМ работни станции и устройства свързани към съществуваща стандартна LAN техника. АТМ форумът е дефинирал стандарт за LANE който осигурява на работните станции свързани чрез ATM същите възможности които са получавали от стандартни LAN. LANE използва МАС опаковка (OSI Layer 2), защото този подход поддържа по-голям брой от съществуващите OSI Layer 3 протоколи. Крайният резултат е че всички устройства свързани към емулиран LAN изглеждат, като върху един свързан сегмент. По този начин AppleTalk, IPX и други протоколи трябва да имат еднакви работни показатели, както в традиционната свързана среда. В АТМ LANE средите, АТМ комутаторът поема трафика принадлежащ на същата емулирана LAN (ELAN), а маршрутизатори поемат трафика между различните ELAN. LANE компонентите са следните:
BUS-ът също така работи като multicast сървър. LANE е дефиниран на ATM адаптационно ниво 5 (AAL5), което определя несложна опашка която да бъде добавена към поредицата преди тя да се раздели на АТМ клетки. Проблемът е в това, че няма начин да се разграничат АТМ клетките изпратени от различни изсточници, когато са мултиплексирани на виртуален канал. Предполага се че получените клетки ще са в поредица и когато пристигне End of Message (EOM) клетката, трябва да просто да съберете наново клетките получени до момента. BUS-ът взема поредицата от клетки на всеки Multicast Send VCC и ги събира в поредица. Когато е получена пълна поредица тя се нарежда в опашка за изпращане към всички LEC на Multicast Forward VCC. По този начин се гарантира, че всички клетки от определена поредица ще се изпратят в правилен ред и няма да бъдат преплетени с клетки от други поредици в point-to-multipoint VCC.
Нужно е да се отбележи, че поради това че LANE е дефиниран на OSI Layer 2, LECS е единствената налична контролна точка. След като му е посочено къде да намери LES и след успешното му включване в ELAN, LEC е свободен да изпраща какъвто и да е трафик (бил той вреден или не) в свързаната ELAN. Единственото място където се прилагат OSI Layer 3 филтри за сигурност е в маршрутизатора, който насочва тази ELAN към други ELAN. Поради това колкото по-голяма е ELAN, толкова по-голяма е опасността от излагане на нарушения в сигурността. Как работи LAN емулацията При обичайна LANE работа, LEC трябва първо да намери LECS за да разбере към коя ELAN да се присъедини. По-точно LEC търси ATM адреса на LECS които обслужват желаната ELAN. За да намери АТМ адреса на LECS, LEC прави следното:
LEC изработва пакет за връзка с АТМ адреса на LECS. Той се обръща към Configure Direct VCC и издава LE_CONFIGURE_REQUEST на този VCC. Информацията в това запитване се сравнява с данните в LECS базата данни. АТМ адресът източник най-често се използва за поставяне на LEC в определена ELAN. Също така може да има общоприети LES за онези LEC, които не са намерени в базата данни. Ако е намерен съответстващ запис се връща LE_CONFIGURE_RE SPONSE заедно с АТМ адреса на LES, който обслужва желаната ELAN. При първото въвеждане на LANE от Cisco, LECS е разположен на подниво на ATM Interface Processor (AIP). Вероятно тази функция в бъдеще ще се премести в станцията за мрежово управление защото там е мястото където се намира цялата информация за членовете на VLAN-a. Присъединяване към LES След като LEC е открил АТМ адресът на желаната LES, той прекъсва връзката с LECS, издава пакет за връзка с АТМ адреса на LES и посочва Control Direct VCC. При успешен VCC сетъп, LES изпраща LE_JOIN_REQUEST. Тази молба съдържа АТМ адресът на LEC, както и MAC адресът, на който LES иска да се регистрира в ELAN. Тази информация се помни, така че два LEC немогат да се регистрират с еднакви MAC или ATM адреси. При получаването на LE_JOIN_REQUEST, LES проверява запитването, чрез своята собствена отворена връзка с LECS, с това потвърждавайки членството на клиента. При успешна проверка, LES добавя LEC като част от неговия point-to-multipoint Control Distribute VCC. Най0накрая LES издава на LEC успешен LE_JOIN_RESPONSE, който съдържа LANE клиентският ID, който представлява идентификатор уникален за новият клиент. Този идентификатор се използва от LEC за да отделя неговите съобщения от BUS-а. Фигура 5-2 LES връзки 
Намиране на BUS-ът След като LEC успешно се е присъединил към LES, неговата първа задача е да намери АТМ адреса на BUS-а и да се присъедини към предаващата група. LEC създава LE_ARP_REQUEST пакет със МАС адрес 0xFFFFFFFF. Този специален LE_ARP пакет се изпраща по Control Direct VCC към LES. LES разпознава, че LEC търси BUS-ът, отговаря с АТМ адреса на BUS-а и предава този отговор на Control Distribute VCC. Присъединяване към BUS-ът Когато LEC има АТМ адреса на BUS-ът, следващото му действие е да създаде сигнален пакет с този адрес и да обяви Multicast Send VCC. При получаването на сигналната заявка, BUS ът добавя LEC, като листо от своя point-to-multipoint Multicast Forward VCC. В този момент LEC е станал член на емулираната LAN. Фигура 5-3 BUS връзки 
Адресна резолюция Предимството на LANE е в АТМ препращащата линия, която той осигурява за трафик между LEC. Когато LEC има да изпраща пакет с данни към неизвестен получател, той генерира LE_ARP_REQUEST към LES на Control Direct VCC. LES препраща запитването на Control Distribute VCC, така че да го получат всички LEC станции. Успоредно с това уникест пакетите с данни се изпращат към BUS-а, за да се препратят към всички крайни точки. Това “наводняване” не е оптималният път за уникест трафика и предавателният канал има ограничение от 10 пакета за секунда. Уникест пакетите продължават да използват BUS-ът докато LE_ARP_REQUEST няма отговор. Ако свързващите или комутиращи устройства с LEC софтуер участват в ELAN-ът, те превеждат и препращат ARP на техните LAN интерфейси. Един от всички LEC трябва да издаде LE_ARP_RESPONSE и да го изпрати към LES, който го препраща към Control Distribute VCC, така че всички LEC могат да разберат новата MAC-към-ATM адресна връзка. Когато изискващият LEC получи LE_ARP_REQUEST, той вече има АТМ адреса на LEC, който представлява търсения MAC адрес. LEC трябва да сигнализира на другия LEC директно и да установи Data Direct VCC предназначен за трафик между тях. Докато чака за LE_ARP резолюция, LEC-ът изпраща уникестове към BUS. След LE_ARP резолюцията вече съществува нов “оптимален” път. Ако LEC превключи незабавно към него, рискува да получи грешни пакети данни. За да се предпази в тази ситуация, LANE стандартът предвижда нулиращ (FLUSH) пакет. Когато Data Direct VCC стане достъпен, LEC генерира нулиращ пакет и го изпраща към BUS. Когато LEC получи собствения си нулиращ пакет по Multicast Forward VCC, той разбира че всички предишни уникестове са били вече предадени. В този момент вече е безопасно да започне да използва Data Direct VCC. Фигура 5-4 Напълно свързана емулирана LAN 
Приложение на LAN емулацията Cisco въвежда LECS, LEC, LES и BUS функциите в AIP, в Cisco IOS Software Release 11.0. Тези функции са дефинирани на АТМ подинтерфейсите, където един физически интерфейс, като OC-3 кабел е логически разделен на 255 логически интерфейса. Следните особености трябва да се имат в предвид при проектирането на LANE:
- Различни подинтерфейси на една AIP - Различни AIP на един маршрутизатор - Различни AIP на различни маршрутизатори
АТМ интерфейс за обмен на данни За да напреви по-бързо достъпни функциите на АТМ, ATM Forum-ът е развил стандарт известен като ATM Data Exchange Interface (DXI). Проектантите на мрежи могат да използват DXI за да осигурят User-Network Interface (UNI) поддръжка между Cisco маршрутизаторите и АТМ мрежите, както е показано на фигура 5-5. Фигура 5-5 АТМ DXI топология 
АТМ data service unit (ADSU) получава данни от маршрутизатора в АТМ DXI формат чрез High-Speed Serial Interface (HSSI). DSU превръща данните в АТМ клетки и ги изпраща към АТМ мрежата по DS-3/E3 линия. АТМ DXI работи в няколко различни режима: - Режим 1а (Mode 1a) – Поддържа само AAL5, 9232 байта максимално и 16-битов FCS, и осигурява 1023 виртуални схеми - Режим 1b (Mode 1b) – Поддържа AAL3/4 и AAL5, 9224 байта максимално и 16-битов FCS. AAL5 поддръжката е същата като при режим 1а. AAL3/4 се поддържа само на една виртуални схема. - Ражим 2а (Mode 2) – Поддържа AAL3/4 и ААL5 с 16 777 215 виртуални схеми, 65 535 байта максимално и 32-битов FCS.
НА фигура 5-7, маршрутизатор конфигуриран като data terminal equipment (DTE) устройство е свързан към ADSU. ADSU е конфигуриран като data communications equipment (DCE) устройство. Маршрутизаторът изпраща АТМ DXI пакети към ADSU, който ги превръща в АТМ клетки преработвайки ги чрез ААL5 convergence sublayer (CS) и segmentation and reasembly sublayer (SAR). АТМ нивото прибавя началото (header), и клетките изпращат през АТМ UNI интерфейса. Фигура 5-7 АТМ DXI Mode 1a и Mode 1b протоколна архитектура за AAL5 
ATM DXI адресирането се състои DFA, който е еквивалентен на Frame Relay data link connection identifier (DLCI). DSU намества DFA в правилните VPI и VCI стойности в АТМ клетката. Фигура 5-8 показва как DSU извършва адресното напасване. Фигура 5-8 АТМ DXI Adress Mapping 
ATM интерфейсна процесорна карта АТМ интерфейсната процесорна (AIP) карта поддържа естествен АТМ в Cisco 7000 и Cisco 7010 маршрутизаторите работещи със Cisco IOS Software Release 10.0 или по-нова. Cisco IOS Software Release 10.0 поддържа АТМ Forum UNI Specification V3.0, която включва user-to-network АТМ сигнална спецификация. AIP картата използва RFC 1483 (Multiprotocol Encapsulation през AAL5) за транспорт на данни през АТМ мрежата. RFC 1483 указва употребата на LLC/SNAP 8-битов header за идентификация на пакетирания протокол. Указва също така употребата на нулево пакетиране (VC Mux), което вместо хедъри създава отделни виртуални схеми за всеки протокол. AIP поддържа следните протоколи: • AppleTalk • Banyan Virtual Network System (VINES) • Connectionless Network Service (CLNS) • DECnet
• Internet Protocol (IP) • Novell Internetwork Packet Exchange (IPX) Следните physical layer interface modules (PLIMs) са на разположение на AIP:
• SONET/SDH 155-Mbps fiber-optic (STS-3c or STM1) cable • SONET/SDH 155-Mbps single-mode fiber-optic (STS-3c or STM1) cable • E3 34-Mbps coaxial cable • DS-3 45-Mbps cable
- 1 SONET and one E3 Interface - 2 SONET Interfaces, one of which is slightly used
- Backward peak cell rate - Forward sustainable cell rate - Backward sustainable cell rate - Forward maximum burst - Backward maximum burst Фигура 5-9 показва как маршрутизиращата таблица и address resolution таблицата на маршрутизатор А са използвани за предаването на данни към работната станция зад маршрутизатора С. Фигура 5-9 AIP свързва LAN-овете към ATM Fabric 
Маршрутизиращата таблица на маршрутизатор А изпълнява обичайната си функция на определяна на следващият hop чрез напасване на мрежовият номер на местоназначението към IP адреса на маршрутизатора към който мрежата цел е свързана. Маршрутизатор А сигнализира на Маршрутизатор C по АТМ мрежата за установяване на виртуална връзка и Маршрутизатор А използва тази връзка за изпращане на пакет към Маршрутизатор C. Фигура 5-10 показва нивата през които минава пакета. Фигура 5-10 Път на IP пакет през АТМ Fabric  Каталог: docs -> Bachelor -> IV%20Kurs -> Sem%20VIII -> KIK KIK -> Модул tcp/ip компютърни комуникации KIK -> Дисциплина: Компютърни мрежи Упражнение 11 Дисциплина: Компютърни комуникации Упражнение 11 KIK -> Модул Frame Relay Компютърни комуникации KIK -> Модул ppp & isdn компютърни комуникации KIK -> Дисциплина: Компютърни мрежи Упражнение 12 Дисциплина: Компютърни комуникации Упражнение 12 KIK -> Дисциплина: Компютърни комуникации Упражнение 8 KIK -> Дисциплина: Компютърни мрежи Упражнение 10 Дисциплина: Компютърни комуникации Упражнение 10 KIK -> Модул 2 Методически аспекти при изучаването и проектиране на компютърно базирани комуникационни системи (кбкс) KIK -> Модул Компютърни мрежи – комуникационната подсистема като обект за проектиране Изтегляне 125.74 Kb. Сподели с приятели:
|