Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Передача IP-Дейтаграмм по сети ATM




Протокол IP поверх ATM

Стек протоколов TCP/IP хорошо знаком сетевым специалистам. Но с появлени­ем ATM возник вопрос: «Не отказаться ли полностью от TCP/IP и не взять ли на вооружение ATM?» Жизнь показала, что правильнее всего — объединить до­стоинства этих двух технологий.

За прошедшее время стек TCP/IP не только не утратил своей популярности, но и с каждым годом завоевывает все новые позиции. Основные причины успеха TCP/IP заключаются в доступности его спецификаций и открытости архитекту­ры. TCP/IP поддерживается практически всеми операционными системами и сетевыми продуктами. Другого своего конкурента, протокол IPX компании No­vell, TCP/IP превосходит по масштабируемости, так как TCP/IP одинаковохорошо работает как в небольших сетях с несколькими пользователями, так и в крупных сетях масштаба предприятия.

К сожалению, из-за того, что стандарт на протокол TCP/IP разработан доста­точно давно, он не может удовлетворить все современные требования, например передачу видеоинформации в реальном времени, так как не поддерживает резер­вирование части полосы пропускания. Правила обработки информации в прото­коле TCP/IP одинаковы для всех приложений, будь то электронная почта или видеоконференции. В любом случае данные имеют одинаковый приоритет при обработке и передаются с одной и той же скоростью — несмотря на то, что, очевидно, данные последнего приложения более приоритетны. Кроме того, про­токол не учитывает, что для передачи информации критичной к задержкам, соответствующие пакеты должны пересылаться в строго определенной последо­вательности и в первую очередь.

Технология ATM имеет значительные преимущества по сравнению с про­токолом IP: благодаря ориентации на установление логического соединения между абонентами она гарантирует эффективную и устойчивую работу и тем самым идеально подходит для передачи по сети аудио- и видеоинформации. Протокол IP целесообразно интегрировать с ATM только в том случае, если большинство компьютеров в организации не подключены напрямую к сети ATM. Такая ситуация в настоящее время типична, так как ATM, в основном, применяется для построения магистрали, связывающей отдельные локальные сети организации.

Поиском решения упомянутых проблем протокола IP занимаются рабочие группы IETF, но пройдет некоторое время до принятия соответствующих стан­дартов. В любом случае протокол TCP/IP и его модернизации будут широко применяться в сетях с ATM.

 

Для выработки стандартов, описывающих механизм функционирования прото­кола IP в сетях ATM, была сформирована рабочая группа ION (Internetworking Over ATM) комитета IETF. Прежде всего были стандартизованы методы пере­дачи пакетов сетевого уровня через соединения ATM, а также способы муль­типлексирования этих пакетов при работе с одним соединением. При приеме пакетов различных типов получатель должен иметь возможность определить тип переданного — возможно, с применением мультиплексирования — пакета и то, какому приложению его следует передать. Следовательно, пакет должен иметь префикс с необходимыми для демультиплексирования полями.

Для поддержки мультиплексирования/демультиплексирования пакетов сущест­вуют два метода, определенных в документе RFC 1483 (Multiprotocol Encapsu­lation over ATM Adaptation Layer 5), июль 1993 года.

Согласно первому методу пакеты различных протоколов передаются через одно соединение с добавлением к ним стандартного заголовка LLC/SNAP. Па­кеты с добавленным заголовком LLC/SNAP инкапсулируются в кадры уровня адаптации ATM (AAL5). На рис. 16.1 показан общий механизм формирования и передачи пакетов протоколов сетевого уровня через виртуальное соединение.

 

 

Напомним, что уровень адаптации ATM является самым верхним из опреде­ленных в модели ATM и, возможно, самым важным. Пользовательские данные передаются на уровень адаптации ATM и там разбиваются на кадры (блоки) переменной длины. После этого кадр упаковывается в ячейки, которые и пере­даются по сети.

Заголовок LLC/SNAP имеет длину 8 байт и состоит из трех полей: LLC (Lo­gical Link Control) (3 байта), OUI (Organizationally Unique Identifier) (3 байта) и PID (Protocol Identifier) (2 байта) (рис. 16.2). Именно последнее поле исполь­зуется для идентификации протокола. Например, значение 0х0800 указывает на то, что передаются дейтаграммы IP, значение 0х0806 указывает на передачу слу­жебного сообщения протокола ARP и т. д. Полный список значений этого поля можно найти в документе RFC 1700.

 

Структура заголовка LLC/SNAP позволяет передавать данные нескольких протоколов сетевого уровня через одно виртуальное соединение, что уменьшает количество требующихся соединений, хотя при этом вносится избыточность в размере 8 байт на кадр уровня адаптации. Данный метод используется по умол­чанию в классическом IP для ATM (см. ниже).

Второй метод, описанный в документе RFC 1483, называется мультиплек­сированием виртуальных соединений (multiplexing VC) или нулевой инкапсуля­цией (Null encapsulation). Согласно этому методу, через соединение передаются данные только одного протокола, и тип протокола явно указывается при уста­новлении соединения. В результате не требуются мультиплексирование и иденти­фикация протокола. Такой метод может использоваться там, где осуществляется прямое взаимодействие между приложениями, в обход протоколов нижних уровней. При этом взаимодействие устройств, находящихся за границами сети ATM, становится невозможным. Кроме того, в многопротокольных сетях такой метод требует установления множества виртуальных соединений, что не всегда приемлемо.

Рабочая группа ION также определила размер максимальной единицы пере­дачи (MTU) для сетей ATM (RFC 1626, май 1994 года). Некоторые приложе­ния, например NFS (Network File System), лучше работают с большим MTU. Для повышения производительности желательно уменьшить количество фраг­ментации дейтаграмм IP. В документе RFC 1209 размер MTU определен равным 9180 байт для SMDS (Switched Multi-Megalit Data Service) — коммутируемой службы передачи данных, обеспечивающей передачу по стандарту IEEE 802.6. Данное значение признано приемлемым и для сетей ATM.

Как указано в документе RFC 1626, два клиента, поддерживающие протокол TCP/IP и связанные между собой постоянным виртуальным соединением, до­лжны использовать MTU с размером 9180 байт, если они заранее не определили меньшее или большее значение. В случае использования коммутируемого вир­туального соединения клиенты будут договариваться о размере MTU во время установления этого соединения. Отправитель может указать значение MTU по умолчанию или другое значение в служебном сообщении, посылаемом при уста­новлении соединения. Получатель может принять это значение или указать меньшее в ответном сообщении.

Отправитель и получатель могут также договориться об использовании MTU, превышающего заданный по умолчанию, если они согласятся с фрагментацией посылаемых данных. Существует метод, который позволяет определить макси­мально возможное значение MTU на пути передачи. Для этого устройства (рабочие станции, маршрутизаторы и т. д.) должны поддерживать механизм, описанный в документе RFC 1191 в ноябре 1994 года. Цель введения этого ме­ханизма состоит в минимизации фрагментации на промежуточных узлах.

 




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


Дата добавления: 2015-07-13; Просмотров: 305; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.008 сек.