Технический обзор
Всплеск поддержки новых схем соединений ISDN
Производители ISDN-устройств, похоже, в состоянии разглядеть хороший протокол соединения, когда он им попадается на глаза.
Вместо того чтобы ждать, пока IETF формально поддержит протоколы CCP (Compression Control Protocol - протокол управления сжатием) и BACP (Bandwidth Allocation Control Protocol - протокол управления распределением пропускной способности), некоторые производители просто включили поддержку CCP и BACP в свои продукты, а затем протестировали их на семинаре по совместной работе устройств, поддерживающих протокол множественных соединений "точка - точка" МР Multilink Point-to-Point Protocol Interoperability Workshop в конце мая, и они выдержали испытание.
Семинар, организованный Pacific Bell, PC Week Labs и California ISDN Users Group, проходил 20 - 24 мая.
Показательно, что большинство представленных на семинаре продуктов поддерживало CCP, а некоторые из них уже поставляются в течение нескольких месяцев.
Напротив, BACP все еще остается слишком новым протоколом. Поэтому, несмотря на впечатляющие результаты тестирования нескольких представленных на семинаре продуктов, до начала 1997 г. поддерживающие его устройства не будут широко доступны.
Любопытно, что индустрия ISDN стала движущей силой нескольких стандартов на протоколы связи, которые постепенно находят путь во все сетевые устройства. Например, протокол MP был разработан, чтобы позволить объединять два B-канала на линии Basic Rate Interface ISDN с пропускной способностью по 64 Кбит/с в одно соединение 128 Кбит/с. Корпорация Microsoft, однако, сделала следующий шаг в использовании этой идеи, реализовав MP в бета-версиях Windows NT в виде средства объединения практически любого набора устройств (включая B-каналы ISDN и аналоговые модемы) для достижения большей пропускной способности.
MP: общее место
Практически все ISDN-продукты, которые тестировались на семинаре, поддерживали протокол MP. Это не удивительно, если учесть, что MP представляет собой наиболее зрелый из тестировавшихся протоколов - он даже является полноценным стандартом IETF.
Некоторые продукты, однако, по-разному интерпретировали необязательную часть спецификации MP, касающуюся EID (endpoint identifiers - идентификаторы конечных станций), что вызвало некоторые проблемы. EID - это общие коды, присваиваемые отдельным одновременно активным сетевым соединениям, которые позволяют ISDN-устройствам отслеживать, какие сеансы следует объединять в одно сетевое соединение.
Вместо того чтобы присваивать одно и то же число или идентификатор каждому новому каналу, используемому для одного сетевого соединения, некоторые устройства удаленного доступа использовали для поддержания порядка в различных частях MP-соединения идентификатор и пароль пользователя.
Другие производители, спроектировавшие терминальные адаптеры с учетом EID, столкнулись с трудностями при попытке открыть второй канал связи с этими устройствами удаленного доступа.
Небольшие исправления в ПО терминального адаптера решили эти проблемы, но участники семинара единодушно согласились, что в спецификацию MP нужно внести поправки, предписывающие использование EID.
Отсутствие поддержки двунаправленной аутентификации также мешало некоторым большим устройствам удаленного доступа. Эти устройства проверяли идентификаторы и пароли для поступающих звонков, но не посылали собственные идентификаторы для аутентификации на удаленном устройстве. Эта проблема была преодолена с помощью небольших изменений в коде терминального адаптера, которые позволили устанавливать MP-соединения без аутентификации хост-системы.
CCP: безобразия с авторскими правами
Из-за юридической неопределенности реализации CCP появились поздно, хотя промышленность уже почти год имела довольно стабильную спецификацию.
Некоторые компании уже начали поставлять продукты, соответствующие протоколу CCP, но большая их часть была показана на семинаре впервые.
По взаимному соглашению производители решили использовать алгоритмы сжатия STAC, которые могут распространяться свободно, но фирма Motorola запатентовала протокол, используемый для обеспечения целостности данных при согласовании между устройствами параметров соединения со сжатием. Фактически окончательный текст RFC по протоколу CCP будет содержать примечание, объявляющее о праве Motorola собирать плату за лицензию с каждого, кто использует CCP.
Различные реализации CCP в основном хорошо работали вместе, однако было замечено несколько аномалий, особенно в тех случаях, когда производители реализовали собственные методы, чтобы обойти ограничения, связанные с авторскими правами.
BACP: становимся умнее
Но настоящий ажиотаж вызвал на семинаре новейший коммуникационный протокол - BACP.
Хотя первоначально только пять производителей объявило о намерении представить бета-версии ПО, реализующего BACP, в действительности их привезла целая дюжина компаний.
Всплеск поддержки объясняется главным образом назревшей потребностью в более интеллектуальных способах управления сетями, соответствующими протоколу MP. BACP дает устройствам возможность согласовывать, сколько каналов должно оставаться открытыми, вместо того чтобы заставлять их слепо открывать вторичные сетевые сеансы, как это делает MP.
Телефонные номера в протоколе BACP передаются автоматически, так что пользователям не нужно для установления многоканальных сетевых ISDN-соединений вводить несколько номеров для набора.
Реализации BACP остаются пока в младенческой стадии, и некоторые продукты смогли выполнить лишь ограниченный набор тестов.
Майкл Суркан
Становление стандарта
Процедура прохождения запросов о комментариях (RFC - Request for Comments) в IETF (Internet Engineering Task Force - Специальная группа по технологии Internet)
Письменный проект направляется в список рассылки рабочей группы IETF для обсуждения
Обсуждение
Проект представляется на заседании IETF
Обсуждение
Когда проект стабилизируется, он получает номер RFC и становится "предложенным стандартом"; проект помещается на Web-узел IETF
Обсуждение Реализация
Если существует хотя бы две реализации стандарта, через четыре месяца предложенный стандарт становится "проектом стандарта"; проект автоматически удаляется, если в течение двух лет не происходит никакого прогресса
Обсуждение Дальнейшая реализация
Еще через шесть месяцев проект становится "стандартом", ему присваивается номер стандарта IETF
За дополнительной информацией обратитесь на Web-узел IETF по адресу: http://www.lETF.org.
