Модул атм компютърни комуникации



Дата10.04.2017
Размер125.74 Kb.

Модул 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 технологии, които мрежовите специалисти могат да използват при изграждане на своите мрежи. Тя също така съдържа препоръки за изграждане на мрежи неизползващи АТМ в момента по такъв начин, че да бъде въвеждането на АТМ в бъдеще максимално изгодно.
Засегнати са следните теми:


  • Общо описание на АТМ

  • LAN емулация

  • Интерфейс за обмен на данни на АТМ

  • Процесорна карта на АТМ интерфейса

  • Cisco Light Stream 100

  • ATM среда


АТМ общо описание
АТМ съчетава силните страни на поделеното по време мултиплексиране (TDM), чиито фиксирани времеви интервали се използват от телефонните компании за пренасяне на глас без изкривявания и предимствата на мрежите основани на пакетен пренос на информацията, чиито променливи по размер информационни единици се използват от компютърни мрежи като Internet, за ефективно доставяне на информацията. Използвайки силните страни на TDM, АТМ избягва същевременно неговите слабости, както и слабостите на PSDN. Чрез използването на клетки с фиксиран размер, АТМ комбинира независимостта от времето на TDM и ефективността на PSDN.
ATM формат на клетката
ATM клетките се състоят от 5 служебни байта и 48 байта за данни. Две от служебните полета се използват за направление на АТМ клетката през АТМ мрежата.


  • VPI – Виртуален идентификатор на пътя

  • VCI – Виртуален идентификатор на канала

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 компонентите са следните:




  • LAN emulation client (LEC) – Крайна система поддържаща LANE, като работна станция свързана чрез мрежова карта, Catalyst 5000 комутатори и маршрутизатори от серията Cisco 7000 изисква въвеждането на LEC. LEC-ът емулира интерфейс за обичайна LAN към протоколи от по-високо ниво. Той извършва препращане на данни, адресно поделяне и регистриране на MAC адреси в LANE сървъра и комуникира с други LEC чрез АТМ virtual channel connections (VCCs).




  • LAN emulation server (LES) – LES осигурява централен контрол за всички LEC. LEC поддържат Control Direct VCC към LES за препращане на регистрационна и контролна информация. LES поддържа point-to-multipoint VCC, известна още като Control Distribute VCC към всички LEC. Control Distribute VDD се използва само за препращане на контролна информация. С присъединяването на нови LEC към АТМ емулираната LAN (ELAN), всеки LEC се добавя като листо към контролното разпределително дърво.




  • Broadcast and unknown Server (BUS) – BUS действа като централна точка за разпределението на broadcasts и multicasts. АТМ основно е “точка-към-точка” технология без да поддържа “any-to-any” или “broadcast”. LANE решава този проблем чрез централизиране на broadcast поддръжката в BUS. Всеки LEC трябва да установи Multicast Send VCC към BUS-ът. Тогава BUS-ът добавя LEC-ът като листо към неговият point-to-multipoint VCC.

BUS-ът също така работи като multicast сървър. LANE е дефиниран на ATM адаптационно ниво 5 (AAL5), което определя несложна опашка която да бъде добавена към поредицата преди тя да се раздели на АТМ клетки. Проблемът е в това, че няма начин да се разграничат АТМ клетките изпратени от различни изсточници, когато са мултиплексирани на виртуален канал. Предполага се че получените клетки ще са в поредица и когато пристигне End of Message (EOM) клетката, трябва да просто да съберете наново клетките получени до момента.


BUS-ът взема поредицата от клетки на всеки Multicast Send VCC и ги събира в поредица. Когато е получена пълна поредица тя се нарежда в опашка за изпращане към всички LEC на Multicast Forward VCC. По този начин се гарантира, че всички клетки от определена поредица ще се изпратят в правилен ред и няма да бъдат преплетени с клетки от други поредици в point-to-multipoint VCC.


  • LAN emulation configuration server (LECS) – Той поддържа база данни на LEC и ELAN-овете към които те принадлежат. Той приема запитвания от LEC и отговаря със съответният VLAN идентификатор, всъщност АТМ адресът който обслужва съответният VLAN или ELAN. Тази база данни се поддържа от мрежовият администратор.

Нужно е да се отбележи, че поради това че 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 прави следното:


  1. Запитва АТМ комутатора чрез Interim Local Management Interface (ILMI). Комутаторът има променлива настройка със АТМ адресът на LECS. LEC тогава може да използва UNI комуникация за да се свърже със LECS.

  2. Търси фиксиран АТМ адрес, който е посочен от АТМ Forum като LECS ATM адрес.

  3. Свързва се със PVC 0/17, “широко известен” PVC.

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 е ограничен до 60К пакета за секунда (pps) двупосочно

  • Един LEC поддържа всички ELAN

  • Във всеки ELAN има една LES/BUS двойка и известен брой LEC

  • LES и BUS функциите трябва да бъдат дефинирани на един и същ подинтерфейс и немогат да бъдат разделяни

  • Може да има само една LES/BUS двойка на подинтерфейс

  • Може да има само една LES/BUS двойка на ELAN

  • Текущият LANE Phase 1 стандарт не поддържа множество LES/BUS

  • LECS и LES/BUS могат да са различни маршрутизатори, бриджове или работни станции

  • VCC могат да са или комутируеми виртуални схеми (SVC), или постоянни виртуални схеми (PVC), макар че PVC конфигурирането и сложност биха вероятно направили всяка друга освен някоя малка мрежа изключително трудна за поддръжка и твърде сложна

  • Когато се дефинират VLAN с комутаторът Catalyst 5000, всеки цвят VLAN трябва да е назначен на различни ELAN. LES/BUS двойката за всеки ELAN може да се намира на което и да е от следните места:

- Различни подинтерфейси на една AIP

- Различни AIP на един маршрутизатор

- Различни AIP на различни маршрутизатори




  • Може да има само един LEC на подинтерфейс. Ако LEC и LES/BUS двойка си поделят подинтерфейс те по дефиниция са в една и съща ELAN

  • Ако LEC на маршрутизаторен подинтерфейс е назначен на IP, IPX или AppleTalk адрес, този протокол е маршрутизуем през този LEC. Ако съществуват множество LEC на един маршрутизатор и са им назначени протоколни адреси, ще се получи маршрутизиране между ELAN. За да работи маршрутизирането между няколкото ELAN превилно, един ELAN трябва да е само в една подмрежа за определения протокол.


АТМ интерфейс за обмен на данни
За да напреви по-бързо достъпни функциите на АТМ, 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.
На маршрутизатора, данните от протоколите с по-високо ниво се затварят в АТМ DXI рамков формат. Фигура 5-6 показва формата на АТМ DXI пакета в режим 1a.
Фигура 5-6 Формат на АТМ DXI пакета


Flag

Header

SDU

FCS

Flag

1

2

0-9232

2

1

НА фигура 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:
• TAXI 4B/5B 100-megabits-per-second (Mbps) multimode fiber-optic cable

• 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
Общата пропускателна способност на всички АIP конфигурирани в маршрутизатор трябва да е ограничена на 200Mbps в режим пълен дуплекс. По тази причина са поддържани само следните комбинации:
- 2 TAXI Interfaces

- 1 SONET and one E3 Interface

- 2 SONET Interfaces, one of which is slightly used
Изброени са конфигурируемите параметри на AIP:
- Forward peak cell rate

- 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 -> Модул Компютърни мрежи – комуникационната подсистема като обект за проектиране


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©obuch.info 2019
отнасят до администрацията

    Начална страница