Что Ethernet-инженеру нужно знать об ATM

Я, кстати, не согласен...

Когда рассказыаешь вкратце что такое Frame Relay, а потом переходишь к ATM,  часто возникает вопрос - "А в чем, собственно, разница?". Хочется ответить, что во всем. Сегодня попытаемся предметно обсудить ATM. Про Frame Relay вы можете почитать вот в этом посте.

Когда я начал разбираться в ATM, я был поражен тем, на сколько "навороченная" и непростая эта технология. Её на самом-то деле очень сложно сравнить с Frame Relay. Тут тебе и некое подобие NATa, что-то вроде VPNa, автоматическая сигнализация секитов через всю ATM сеть, динамическая маршрутизация, Tag Switching и многое другое. Даже Explicit Path можно указать для секита. Что-то знакомое, не правда ли? А я в своё время удивлялся, когда встретил большую межконтинентальную ATM сеть, которая впоследствии была заменена MPLSом. Ладно, давайте по порядку.

Немного лирики

ATM рождался в смутные времена перехода с канальной передачи данных (PDH/SDH) на пакетную (Frame Relay, ATM, Ethernet). Поэтому он характеризуется такими вещами как:

1. Фиксированный маленький размер фрейма (ячейки). Что дает возможность уйти от концепции синхронизации. Дело в том, что при передаче таких маленьких ячеек вероятность возникновения ошибок довольно мала, потому что сама передача занимает очень короткий промежуток времени.
2. Возможность одинаково эффективно передавать как критичные к задержкам данные (голос, видео), так и просто данные.
3. Виртуальные каналы. Вся информация в ATM передается по виртуальным каналам. Для того чтобы даные вообще пошли хоть куда-то, он должен существовать.

В ATM многое наследуется от классических телефонных сетей, несколько деталей будет обозначено по ходу.

Базовый принцип.

ATM подобно Frame Relay использует некие указатели для коммутации, но здесь они испольщуются иначе и имеют другой смысл. В заголовке ATM есть два поля - VPI (Virtual Path Identifier) и VCI (Virtual Channel Identifier). Они имеют только локальное значение на интерфейсе, как и во Frame Relay. Но, в отличии от FR, их никак нельзя сравнить с MAC адресами в Ethernet. Они никаким образом не определяют устройство и могут меняться от линка к линку.

ATM свитч может оперировать двумя этими числами. Разберем простой пример.

Большая консервная банка на картинке выше - ATM свитч. С левой стороны в него входят 4 канала. Это могут быть каналы пользователей или непосредственные данные от соседнего ATM коммутатора. Наша банка с картинки может делать с этими каналами две вещи:

• VC Swithing. Комутатор будет оперировать виртуальными каналами (VC). В нашем примере, виртуальный канал, который можно описать как VPI 1/VCI 1 будет скоммутирован в канал VPI 12/VCI 40. А VPI 1/VCI 2 - в канал VPI 13/VCI 10. Таким образом, коммутатор произвел смену значений VPI/VCI. Стоит сказать, что это не должно быть именно так, значения могли остаться прежними. Тут важно понять смысл, что коммутатор разбирает VPI до уровня VCI и может уже дальше засунуть эти VCI в любой другую трубу (VPI).
• VP Switching. Коммутатор будет оперировать только виртуальными "путями" (VP). В нашем примере, когда к коммутатору придут данные из каналов VPI 2/VCI 1, VPI 2/VCI 2, он просто посмотрит на значение VPI и примерт решение о том, что весь этот канал нужно отправить в определенный интерфейс сменив VPI на 20. Опять же, менять VPI не обязательно. Главный смысл в том, что коммутатор принимает решение только на основе VPI. Ясно, что это дает некий выигрыш в производительности. Именно такой подход часть применяется на магистральных коммутаторах. Это некая транспортная аггрегация каналов.

Как вы уже поняли, значения VPI/VCI объединяются в некое подобие иерархии. Несколько Virtual Channel'ов, которые определены значением VCI, объединяются в один Virtual Path, который задан VPI. Если рассматривать левую сторону примера выше, то мы видеть два Virtual Path'a с номерами 1 и 2. Каждый из них состоит из двух каналов, первого и второго соответсвтенно.

В примере учавствовал один коммутатор, но, понятное дело, на сети их несколько, и каждый из них делает одну и ту же работу по части коммутации:

1. Посмотреть на:
1. VPI в случае VP коммутации
2. Пару VPI/VCI в случае VC коммутации
2. Полагаясь на значения VPI/VCI выбрать исходящий порт.
3. Произвести или не производить замену значений VPI/VCI.
4. Отправить данные дальше. 

Virtual Connections

ATM - это connection-oriented сеть, что подразумевает установление соединения между двумя точками для передачи трафика. Типов таких соединений в ATM довольно много.

Во-первых, они делятся по тому какой тип коммутации выбран (VC или VP).

Во-вторых, такие соединения бывают постоянные и коммутируемы (permanent, switched).
В первом случае (permanent), на каждом коммутаторе по пути нужно прописать соответсвие входящий VPI/VCI, исходящий порт, исходящий VPI/VCI. Такое соединение будет всегда присутствовать на сети, независимо от наличия трафика в нем. Используется, например, для каналов по которым идет сигнализация.
Для второго типа (switched) характерна обратная ситуация. Когда появляется интересный трафик, начинает сигнализироваться соединение. Для этой цели используется специальный протокол сигнализации и маршрутизации, о котором чуть ниже. Плюсы очевидны. Во-первых, соединение поднимается по надобности, во-вторых, можно использовать все прелести динамической маршрутизации (поиск картчайшего пути, скажем).

Суммируем всю классификацию:

• Permanent Virtual Connection (PVC)
• Permanent Virtual Channel Connection (PVCC)
• Permanent Virtual Path Connection (PVPC)
• Switched Virtual Connection (SVC)
• Switched Virtual Channel Connection (SVCC)
• Switched Virtual Path Connection (SVPC) 
• Soft Permanent Virtual Connection (soft PVC)
• Soft Permanent Virtual Channel Connection (soft PVCC)
• Soft Permanent Virtual Path Connection (soft PVPC)

Как видите, к классификации я добавил ещё и Soft PVC. Это некий гибрид между permanent и switched каналами. Из названия понятно, что он устанавливается перманентно. Однако его не нужно прописывать на каждом устройстве, такой соединение сигнализируется как SVC. Последнее обстоятельство значит, что для выбора кратчайшего пути будет использоваться протокол маршрутизации со всеми его возможностями. Представьте ситуацию, когда вы прописали PVC в своей ATM сети, а какой-либо коммутатор по пути взял да упал. В случае PVC единственным для вас вариантом будет судорожно прописывать новое соединение в обход (если он есть, разумеется). В случае Soft PVC такое соединение будет проложено по другому пути автоматичеки (reroute).

Сигнализация

Мы плавно подошли к вопросу сигнализации. Напомню, для установления SVC и Soft PVC нужен какой-то механизм, чтобы установить соединение. Сам процесс происходит в несколько этапов и выглядит довольно просто и лаконично, если не вдаваться в подробности.

Процесс на картинке выше идет следующим образом:

1. Устройства А хочет отправит трафик устройству Z, для этого нужно сигнализировать SVC. A отправляет запрос на установление соединения, в котором содержится адрес устроства A и адрес назначения. В литературе часто можно встретить названия calling party и called party. В нашем случае это A и Z соответсвтенно. Вызывающая и вызываемая стороны. Важно так же, что в реквесте содержится необходимая информация о классе трафика и необходимых параметров для его передачи. Что-то вроде RSVP-TE прям.
2. ATM 1 устройство, получив запрос, проверяет есть ли у него адрем устройтсва Z в его таблице коммутации. Далее проверяется, сможет ли ATM 1 выделить необходимые ресурсы для прохождения трафика. Если ответ положительный, то такие ресурсы выдеряются и запрос передается дальше.
3. ATM 1 и ATM2 повторяют процедуру. 
4. Устройство Z, получив запрос и осознав по адресу, что это для него, проверяет сможет ли оно выделить необходимые ресурсы. Если сможет, то в ответ отправляеся Accept сообщение, которое по такому же пути доходит обратно до устройтсва A. 
5. VC сигнализирован.

Каждый интерфейс в ATM сети (да и в любой другой в принципе) можно охарактеризовать как NNI (network-network interface) или UNI (user-network interface). Названия говорят сами за себя. Первый интерфейс обычно смотрит в сторону сети, второй - в сторону конечного пользователя. От типа интерфейса будет зависеть поведение коммутатора. Например то, как будет выполнятся сигнализация. Зачем клиенту передавать информацию, которая нужна для построения кратчайшего пути, например. А вот сигнализация по NNI секитам происходит средствами протокола PNNI (Private Network Node Interface), который также отвечает за маршрутизацию. О нем мы поговорим сразу после адресации.

Адресация

В последовательсти шагов выше, я упоминал адреса, которые передаются вместе с сигнальными кадрами. Можно сразу привести какой-нибудь типичный адрес в ATM для затравки... 47.00918100000000E04FACB401.00E04FACB401.00 А вы говорите IPv6...

Адреса в ATM глобально бывают двух видов:

1. E.164. Выглядит как телефонный номер в формате X-XXX-XXX-XXXX. Словом, обычный телефонный номер. Как я понимаю, такая адресация используется в глобальных ATM сетях.
2. NSAP. Если вы знакомы с IS-IS, то вы знаете что это формат адреса разработанный в стародавние времена OSI. Да-да, как модель OSI. Адрес имеет довольно сложную структуру, для ATM он обычно генерируется следующим образом (пример для Cisco):

AA.IIII HHHHHHHH SSSSSSSSSSSS.MMMMMMMMMMMM.SS

• AA - AFI - Authority and Format Identifier. Например, 39 - выдан ISO, 45 - закодированный E.164 в NSAP. На деле практически всегда это одно число.
• IIII - ICD - International Code Designator. На деле для Cisco это всегда 0091
• HHHHHHHH - часть HO-DSP - High-Order Domain Specific Part. Для Cisco 81000000.
• SSSSSSSSSSSS - MAC. MAC аддрес коммутатора.
• MMMMMMMMMMMM - MAC. Mac аддрес интерфейса. 
• SS - SEL. На деле всегда по нулям, а вообще это что-то вроде порта в TCP/IP.

Как видите, подобно IS-IS, сложный адрес генериться довольно простыми правилами. Также глобально адрес можно разделить ещё на две части. Первые 13 байт (47.0091810000) представляет из себя некое подобие префикса. Оставшаяся часть - идентификатор хоста. Стоит упомянуть важный момент, что в иерархичный ATM сетях схему генерации адреса придется серьезно доработать, в угоду масштабируемости. С измененной струкрурой можно суммаризировать адреса, например, наподобии того, как мы привыкли делать это в IP.

ILMI (Integrated Local Management Interface)

Как и во Frame relay, у ATMа есть свой протокол для упрощения жизни на "последних милях". Здесь он называется ILMI и выполняет несколько отличную от LMI во Frame Relay функцию. После подключения конечного устроства к ATM коммутатору через UNI линк, первый сообщает второму свой MAC адрес, коммутатор добавляет к нему свой префикс (13 байт, о которых я говорил ранее) и отправляет полный адрес назад хосту. Такая процедура составляет таблицу адресов на ATM интефейсе.

PNNI (Private Network Node Interface)

Строго говоря, в ATM есть два протокола. Interim Interswitch Signaling Protocol (IISP) и Private Network-Node Interface (PNNI). Первый позволяет прописывать статически маршруты на коммутаторах, а второй пользоваться всеми прелестями динамической маршрутизации. Поэтому далее речь пойдет только про второй.

Итак, PNNI это протокол, который:

1. Устанавливает соседство с помощью Hello-сообщений.
2. Динамически изучает топологию сети.
3. Способен учитывать QoS параметры при выборе маршрута.
4. Подерживает иерархичные топологии.
5. Отвечает за SVC сигнализацию в том числе.

PNNI работает схожим с любым другим протоколом маршрутицации. Как я думаю, многое скопировано с OSPF:

1. Установление соседства. С помощью Hello-сообщений, соседние коммутаторы устанавливают отношения сосетства. Я ранее упоминал, что в иерерхичных сетях аддресацию ATM придется немного поменять. В его часть должен входить идентификатор Peer Group. Если он совмадает на обоих соседях, то линк между ними считается внутренним, а если нет - внешним.
2. Синхронизация. Каждый сосед отправляет все свои знания о сети соседу, а потом запрашивает разницу. В результате этого шага, на двух соседях должна быть одинаковая база знаний.
3. Обновление состояний. Изменение топологий шлется с помощью PTSP (PNNI Topology State Packets) пакета, который содержит в себе несколько PTSE (PNNI Topology State Elements). Обновления так же содержат информацию необходимую для того, чтобы учитывать параметры QoS при прокладке маршрута.

PNNI использует простую метрику, которая по умолчанию равна 5040 у Cisco. Если никаких изменений не производить, то логика выбора маршрута становится сильно похожа на hop-count у RIP. Но вы всегда вольны настраивать метрику на интерфейсах, что скорее смахивает на IS-IS.

Помимо метрики, PNNI учитывает довольно большой список сложных атрибутов. Ниже некая информация по ним.

1. Cell delay variation (CDV) - максимальный delay на линке
2. Maximum cell transfer delay (MCTD) - CDV + прочие фиксированные задержки на линке
3. Available cell rate (AvCR) - доступный bandwidth на линке.
4. Cell loss ratio (CLR) - потери на линке.

Каждое изменение этих атрибутов должно анонсироваться соседям и, чтобы они не умерли от такого количества информации, обновление тригериться только если изменения существенны.

Теперь, мы можем немного расширить описание предыдущей картинки.

Итак, устройство A по прежнему сигнализирует VC до устройтсва Z.

1. Первый request приходит от конечного устроства A. Он содержит адрес источника и назначения.
2. ATM1 по своей локальной базе ищет адрес назначения и понимает, что конечная станция Z находится за устроством ATM3.
3. ATM1 производит просчет кратчайшего пути учитывая все метрики и атрибуты. После этого, он составляет лист, который включает в себя все ноды по пути. Этот лист добавляется в request и отправляется соседу ATM2. Лист на данном этапе содержит список ATM2-ATM3.
4. Каждая нода по пути проверяет, удовлетворяет ли требованиям путь из листа в реквесте. Если что-то идет не так, промежуточная нода пытается просчитать какой-то обходной маршрут до точки назначения. Если у неё это получается, то она сообщает информацию о причине и алтернативном пути тому, кто сгенерировал первоначальный лист. Тот пытается снова сигнализировать канал, но уже по другому пути. В нашем примере, ATM2 понимает, что трафик не пролезет в линк до ATM3, он понимает это по значению AvCR.
5. ATM2 просчитывает обходной путь до ATM3 через коммутатор ATMx. Генерируется новый лист ATMx-ATM3 и отправляется на ноду, которая сгенерировала первоначальный список (ATM1).
6. ATM1 получив такой совет от своего соседа, пытается сигнализировать канал, но уже по другому пути ATMx-ATM3. Снова отправляется request.
7. ATMx получив запрос проверяет соответсвует ли путь заданным требованиям и отправляет запрос дальше.
8. В итоге, запрос доходит до точки назначения и та отвечает сообщение Connect. 
9. Ответное сообщение по тому же пути доходит до точки отправки трафика, после чего канал считается сигнализированным. Наконец-то можно отправлять трафик.

E.164 или плюс семь четыре семь четыре два...

ATM, как и многие другие протоколы и сетевые технологии, унаследовал многое от телефонных сетей. В нашем случае, это глобальная адрессация, в том числе.

На схеме ниже можно увидеть две приватные ATM сети, которые используют PNNI сигнализацию. Две эти сети связаны между собой через публичную ATM сеть, в которой используется E.164 сигнализация. Кроме того, что в этих двух сетях используется разный тип сигнализации, так ещё и адресация разная. В первом случае это NSAP, а во втором E.164. Ничего не напоминает? Подождите, дальше лучше.

NSAP адреса из приватных сетей не могут передаваться в открытом виде в публичных сетях, поэтому некие граничные коммутаторы должны производить что-то вроде трансляции из NSAP в E.164 и обратно. Ну как вам?

Для того, чтобы обеспечить приватным сетям связность через публичную сеть, адрес нужно конвертировать. Типов такой конвертации несколько:

1. Gateway. Что-то вроде статического маршрута, который проинструктирует левый коммутатор с картинки отправлять данные на E.164 адрес правого коммутатора.
2. Autoconversion. В таком случае NSAP адрес будет сконверторован в E.164 адрес по определенному правилу, а на принимающей стороне будет произведена обратная операция.
3. Translation. Моё любимое. Настраивается таблица соответсвий NSAP адресов к E.164. После чего происходит трансляция один к одному. "Дык это ж NAT?", может воскликнуть читатель. Ну, в общем-то, да.

LANE (LAN Emulation)

Рано или поздно, инженеры столкнулись с проблемой эмуляции LAN в ATM. Учитывая тот факт, что концепции broadcast трафика в ATM нет как таковой, задача была не из легких. Да и вообще, ATM это Poin-to-Point технология... а нужно было Point-to-Multipoint... Пришлось обкладывать всю сеть костылями.

LANE довольно сложная тема, но мы не будем сильно на ней останавливаться. Для меня главное понять концепцию. А концепция проста, для того чтобы эмулировать broadcast придется использовать unicast.

Различают следующие типы устройств в LANE:

• LANE Client (LEC) - клиент, который хочет думать, что он подключен к локалке, а не к ATM сети.
• LANE Server (LES) - сущность, которая регистрирует клиентов. По сути, отвечает на ARPы и строить таблицу коммутации.
• Broadcast and Unknown Unicast Server (BUS) - принимает broadcast от хостов и отправляет его юникастом к другим клиентам.
• LANE Configuration Server (LECS) - хранит базу "какой клиент к какой сети принадлежит".

Т.е. для того, чтобы объединить два устроства в одну LAN сеть, нам понадобиться полный набор сущностей - один LES, BUS и LECS. Звучит непросто, выглядит тоже.
 
Я нашел неплохое описание процесса подключения к LANE, отправки ARPа и передачи BUS трафика в одном из стареньких гайдов от Cisco, по нему и пробежимся.

Подключение происходит следующим образом:

1. Наш клиент (LEC1) хочет подключиться к сети. Для этого ему нужно узнать, кто в этой сети LEC Server. Он сигнализирует VC до LECSа (VC 1). Его адрес он уже знает либо из статической конфигурации, либо через ILMI, либо это один из well-known стандартных адресов. VC которая только что была сигнализирована, к слову, двунаправленная. Обратите внимание на стрелки в обе стороны.
2. LECS узнает клиента и возвращает ему адрес LESа для нужной сети через тот же VC 1.
3. LEC сигнализирует VC до LES (VC 2).
4. LES идентифицирует клиента, после чего решает проверить, можно ли ему подключиться к этой эмулируемой сети.
5. Для этого LES сигнализирует VC до LECSа (VC 3).
6. Если подтверждение получено, LES сигнализирует VC до клиента для передачи трафика (VC 4).
7. Для того чтобы начать передавать трафик, для начала нужно узнать ATM адрес удаленной стороны. Значит, нужно отправить ARP (LE_ARP в терминах LANE). Для этого наш клиент должен узнать адрес BUSа. Для этого он отправляет LE_ARP с запросом broadcast адреса.
8. В ответ LECу от LESa приходит адрес BUS. После чего, он сигнализирует контрольный VC до BUSа (VC 5).
9. В обратном направлении, BUS сигнализирует до LEC VC 6 для передачи broadcast, multicast, unknown unicast трафика.
10. Почти Profit!11
11. Пришло время попробовать отправить трафик другому клиенту (LEC 2). Для этого LEC 1 отправляет LE_ARP на LES через уже сигнализированный VC 2. Цель данного мероприятия - получить уже наконец ATM адрес LEC 2, что бы уже докинуть до него VC  и начать передавать трафик.
12. Если соответсвие MAC-ATM у LESa есть, то в ответ на запрос LEC 1 получит долгожданный адрес. Но это было бы не так интересно. Представим, что соответсвие не найдено. В таком случае, LES передает LE_ARP от LEC1 другим LECам. К LEC2 такой запрос попадает через VC 4', которая уже должна быть сигнализирована (похожим образом, как описано в пункте 6).
13. Допустим, LEC2 узнал себя. После чего он отвечает своим ATM адресом через VC 2'. Этот VC также был сигнализирован ранее (см. пункт 3).
14. LES отправляет ответ от LEC2  в сторону LEC1 через VC 4.
15. LEC1 добавляет себе в кеш соответсвие MAC-ATM.
16. Теперь LEC1 в состоянии сигнализировать VC до LEC2 (VC 7). Что он и делает.
17. Profit!11
18. А что если LEC1 захочет отправить широковещательный кадр.
19. LEC1 уже знает адрес BUS, поэтому трафик прямико направится на BUS через VC 5 (он ждет своего часа ещё с пункта 8).
20. BUS множит трафик и отправляет его через ранее сигнализированные VC 6 и VC 6'.
21. Вот теперь точно Profit!111

Пора заканчивать. В ATM есть ещё много-много интересного, взять хотя бы аналог VPN - Closed User Group Signaling. Или тот же Tag Switching, который представляет из себя не что иное, как реализацию MPLS в ATM сетях. Ну и про QoS я умолчал, конечно... 

Думаю, этого пока достаточно для Ethernet-инженера.