|
|
||||
|
Предисловие
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||
|
Telecommunication technologies - телекоммуникационные технологии (v2.1) Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001, 1100 стр.) и "Протоколы Internet для электронной торговли" ("Горячая линия - Телеком", М. 2003, 730стр.), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".
В последней из книг содержится раздел, где выпускник кафедры ТСС МФТИ С.Джужа, рассказывает о своем опыте разработок в данной сфере. В сумме эти книги содержат около 2550 страниц, а на данном сервере размещается более 2800 стандартных книжных страниц (формат A4, times-12, следует заметить, что содержимое книг частично перекрывается). Причин здесь несколько. Во-первых, ограниченность времени и жанр лекций не позволяют разместить полные описания протоколов (конспективность здесь неизбежна) и представить необходимые справочные материалы. Сервер, включая рисунки и формулы, содержит более 1000 файлов. Во-вторых, данное направление науки и технологии развивается стремительно и отследить прогресс в этой отрасли с использованием техники книжных издательств практически невозможно (первая книга готовилась к печати с уровня машинных файлов около года, вторая - 4 месяца). Автор решил попытаться решить эту проблему методами современных сетевых технологий. Ускорение, которое достижимо в этом случае очевидно. Но у этого метода есть и несомненные недостатки - в книжном издательстве за ошибки отвечает редактор и корректор, а здесь автору это свалить не на кого. Практически невозможно избежать и некорректности сетевых ссылок, в Интернет все меняется слишком быстро. То что ещё вчера было доступно, сегодня может более не существовать. Зато вместо этого появляется несколько новых, чаще всего более емких ссылок. По этой причине я заранее прошу извинения за ошибки, содержащиеся в текстах, размещенных на сервере. Эта работа заняла несколько лет, сейчас мне очень трудно обнаружить даже некоторые очевидные описки и ошибки, ведь я вижу не тот текст, что читаете вы, а тот, который я намеревался написать, а это не одно и то же. Буду весьма признателен читателям, обнаружившим любые ошибки и приславшим замечания. Это позволит мало-помалу привести материалы в должный порядок, сделать их более полными (общими силами это будет сделать легче). Надеюсь, что неизбежные ошибки не слишком испортят настроение читателей. Будут приниматься и пожелания по размещению новых материалов. Предполагается размещение новых материалов и других авторов. Окончательное решение по вопросу постановки таких статей будет приниматься мной. Авторские права в таких случаях будут неукоснительно соблюдаться. Форма сервера позволяет непрерывно дополнять и корректировать материалы. В настоящее время содержимое сервера ориентировано на широкий круг читателей и в силу этого страдает недостаточной строгостью, например, здесь отсутствуют теоретические обоснования многих формул или выбора того или иного сетевого решения. Позднее это может быть устранено путем введения дополнительных глав, посвященных теории телекоммуникаций. Помимо стандартных гиперссылок каждая из статей содержит в верхней части кнопки управления. <previous> - для перехода к предыдущей статье; <up> - к предыдущему разделу; <down> - к следующему разделу; <next> - для перехода к следующей статье; а также кнопка <index>, которая служит для обращения к оглавлению. Объем статей (в килобайтах) указан с учетом рисунков, хранящихся в виде отдельных файлов. Самая правая клавиша <ПОИСК> осуществляет переход на страницу, где размещена форма, позволяющая выполнить поиск в пределах данного сервера. При этом выдаются ссылки на все статьи (и позиции), где имеются представленные ключевые слова. Надеюсь, что данный сервер окажется для вас полезным. В дальнейшем предполагается предложить версию сервера на CD со встроенной поисковой системой. Для студентов и всех желающих создан тренажер для проверки знаний по отдельным разделам (saturn.itep.ru и http://knowtest.itep.ru). Для просмотра сервера желательно использовать версии Netscape communicator v4+ и MS Internet Explorer с версией 5+. Тренажер и многие программы из http:/saturn.itep.ru работают исключительно с MS Internet Explorer. Для некоммерческих целей читатели могут использовать данные тексты без ограничений. Размещение полных текстов или фрагментов на других серверах без согласия автора не допускается. ╘ Данная версия сервера сформирована с использованием базы данных MySQL, куда были помещены все статьи. Дизайн страниц и формирование индексов определяется шаблонами, что облегчает любые изменения. Программы для этого были подготовлены сотрудником ИТЭФ Михаилом Крикуном (admin@ol.ru). Им же была поставлена поисковая система. Сервер размещен на ЭВМ saturn.itep.ru, администратор - Роман Нилов (Roman@itep.ru). По вопросам приобретения книг "Протоколы Интернет. Энциклопедия" и "Протоколы Internet для электронной торговли" ("Горячая линия - Телеком", Москва, 2003г) следует обращаться к Занину Евгению Александровичу по телефону 287-49-56 (radios_hl@mtu-net.ru)
|
||||
|
|
|
|
|
1 Введение (общие принципы построения сетей)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Интернет является сетью виртуальных сетей. В 1991 году у нас (тогда еще в СССР) о нем знали несколько десятков человек, которые только что освоили электронную почту (через RELCOM) и попробовали, что такое FidoNet. Первое сообщение по электронной почте было послано президентом США Биллом Клинтоном 2 марта 1993 года. Первая новелла Стивена Кинга была опубликована по каналам Интернет 19 сентября 1993 года (до появления печатной копии), к тому же году относится начало синхронной передачи радио-программ по сетям Интернет. В конце 1993 года заработала первая очередь оптоволоконной опорной сети Москвы, полностью профинансированная Джорджем Соросом. В 1994 году НАТО организовало первую конференцию по Интернет в России (в Голицыно под Москвой). С помощью DFN (Deutsche Forschung Naetze), а затем Дж. Сороса и RELARN круг любителей Интернет расширился до сотен и тысяч, а после включения программ Минвуза и Министерства науки РФ счет пошел на десятки тысяч. Это произошло прежде всего потому, что созрели условия - в различных учреждениях (сначала научных, а затем коммерческих и государственных) и у частных лиц оказались сотни тысяч персональных ЭВМ. К этому же времени (1992-93 годы) в мире стала формироваться сеть депозитариев, доступных через анонимный доступ (FTP), а несколько позднее и WWW-серверов. На рис. 1.1 показан рост числа ЭВМ, подключенных к Интернет по годам с 1989 по 1998 годы. Видно, что рост числа узлов сети имеет экспоненциальный характер. Можно смело утверждать, что протоколы Интернет, созданные для осуществления связи в случае нанесения десятков ядерных ударов по США со стороны СССР, явились одним из немногих (возможно единственным) положительным результатом холодной войны.
Сегодня, когда Интернетом заинтересовались широкие массы трудящихся, и определенная часть их подключилась к расширению этой сети, стала актуальной проблема оптимального проектирования сетей и их подключения к общенациональной и международной сети Интернет. Современные сети Интернет объединяют в единое целое многие десятки (а может быть уже и сотни) тысяч локальных сетей по всему миру, построенных на базе самых разных физических и логических протоколов (ethernet, Token Ring, ISDN, X.25, Frame Relay, Arcnet и т.д.). Эти сети объединяются друг с другом с помощью последовательных каналов (протоколы SLIP, PPP), сетей типа FDDI(часто используется и в локальных сетях), ATM, SDH(Sonet) и многих других. В самих сетях используются протоколы TCP/IP (Интернет), IPX/SPX (Novell), Appletalk, Decnet, Netbios и бесконечное множество других, признанных международными, являющихся фирменными и т.д. Картина будет неполной, если не отметить многообразие сетевых программных продуктов. На следующем уровне представлены разнообразные внутренние (RIP, IGRP, OSPF) и внешние (BGP и т.д.) протоколы маршрутизации и маршрутной политики, конфигурация сети и задание огромного числа параметров, проблемы диагностики и сетевой безопасности. Немалую трудность может вызвать и выбор прикладных программных средств (Netscape, MS Internet Explorer и пр.). В последнее время сети внедряются в управление (CAN), сферу развлечений, торговлю, происходит соединение сетей Интернет и кабельного телевидения. Что явилось причиной стремительного роста сети Интернет? Создатели базовых протоколов (TCP/IP) заложили в них несколько простых и эффективных принципов: инкапсуляцию пакетов, фрагментацию/дефрагментацию сообщений и динамическую маршрутизацию путей доставки. Именно эти идеи позволили объединить сети, базирующиеся на самых разных операционных системах (Windows, Unix, Sunos и пр.), использующих различное оборудование (Ethernet, Token Ring, FDDI, ISDN, ATM, SDH и т.д.) и сделать сеть нечувствительной к локальным отказам аппаратуры. Огромный размер современной сети порождает ряд серьезных проблем. Любое усовершенствование протоколов должно проводиться так, чтобы это не приводило к замене оборудования или программ во всей или даже части сети. Достигается это за счет того, что при установлении связи стороны автоматически выясняют сначала, какие протоколы они поддерживают, и связь реализуется на общем для обеих сторон наиболее современном протоколе (примером может служить использование расширения протокола smtp - MIME). В кабельном сегменте современной локальной сети можно обнаружить пакеты TCP/IP, IPX/SPX (Novell), Appletalk, которые успешно сосуществуют. Проектировщикам и создателям сетей приходится учитывать многие десятки факторов при выборе того или иного типа сети, сетевого оборудования, операционной системы (UNIX, MS-DOS, IRIS, Windows-NT, SOLARIS или что-то еще), программного обеспечения, внешних каналов связи (выделенный канал, коммутируемая телефонная сеть, цифровая сеть, радио или спутниковый канал) и в конце концов сервис-провайдера. За всем этим стоят как технологические проблемы, так и финансовые трудности, тяжелый выбор между дешевой и хорошей сетью. Если вас интересуют оригинальные тексты протоколов Интернет, вы можете получить их, например, через анонимное FTP по адресу ds.internic.net (в каталоге RFC) или на нашем сервере store.in.ru/rfcs (зеркало). Эти документы можно найти и в других депозитариях. Документы RFC делятся на стандарты, проекты стандартов, временные (экспериментальные) регламентации и предложения. Чем больше номер RFC, тем более поздней дате этот документ соответствует. О статусе тех или иных RFCможно узнать из RFC-1500 и -1780 (см. также файл std-inde.txt из того же депозитария, что и rfc-index.txt). Если вы хотите найти какой-то RFC-документ, начните с просмотра индексного файла (напр. rfc-index.txt). Первый документ RFC был выпущен в 1969 году более 30 лет тому назад. Далее темп публикаций варьировался в довольно широких пределах, в 1997-99 годах наблюдается заметный всплеск активности, связанный с потребностями мультимедиа (RTP, RSVP, PIM и т.д.), безопасностью и IPv6. Вариация публикаций документов RFC по годам представлена на рис 1.2.
Рис. 1.2. Распределение публикаций документов RFC по годам с 1969 по 1999 Из этого распределения видно, что к 1979 году окончательно сформировался стек базовых протоколов и начался экстенсивный рост сети Интернет. По мере выявления недостатков протоколов и новых потребностей после 1989 года началась активная разработка новых направлений и приложений в Интернет. Но все по порядку. Начнем с того, как устроен Интернет. На рис. 1.3 показана общая схема, которая облегчит дальнейшее обсуждение данной проблематики (буквами R отмечены маршрутизаторы-порты локальных сетей). Каждая из сетей, составляющих Интернет, может быть реализована на разных принципах, это может быть Ethernet (наиболее популярное оборудование), Token Ring (вторая по популярности сеть), ISDN, X.25, FDDI или Arcnet. Все внешние связи локальной сети осуществляются через порты-маршрутизаторы (R). Если в локальной сети использованы сети с разными протоколами на физическом уровне, они объединяются через специальные шлюзы (например, Ethernet-Fast_Ethernet, Ethernet-Arcnet, Ethernet-FDDI и т.д.). Выбор топологии связей определяется многими факторами, не последнюю роль играет надежность. Использование современных динамических внешних протоколов маршрутизации, например BGP-4, позволяет автоматически переключаться на один из альтернативных маршрутов, если основной внешний канал отказал. Поэтому для обеспечения надежности желательно иметь не менее двух внешних связей. Сеть LAN-6 (см. рис. 1.3) при выходе из строя канала R2-R6 окажется изолированной, а узел LAN-7 останется в сети Интернет даже после отказа трех внешних каналов. Широкому распространению Интернет способствует возможность интегрировать самые разные сети, при построении которых использованы разные аппаратные и программные принципы. Достигается это за счет того, что для подключения к Интернет не требуется какого-либо специального оборудования (маршрутизаторы не в счет, ведь это ЭВМ, где программа маршрутизации реализована аппаратно). Некоторые протоколы из набора TCP/IP (ARP, SNMP) стали универсальными и используются в сетях, построенных по совершенно иным принципам.
Рис. 1.3. Схема построения сети Интернет В некотором смысле Интернет возник эволюционно - в начале был Bitnet, fidonet, usenet и т.д. Со временем стало ясно, что конкуренция сетей должна быть заменена их объединением, так как от этого выигрывают все и пользователи и сервис-провайдеры. Ведь объединенная сеть имеет большие информационные ресурсы, может предложить более широкий список услуг и становится по этой причине привлекательной для еще большего числа клиентов. Технология WWW-серверов сделала Интернет важной средой для целевой рекламы, приближенной к конечному потребителю. Стремительный рост числа узлов www продемонстрирован на рис. 1.4. Здесь также наблюдается экспоненциальный рост. Сам факт использования Интернет для обливания грязью кандидатов во время предвыборной компании, говорит о том, что эта технология освоена и признана эффективной нашими политиками. Наше общество с удивительным упорством сначала осваивают все негативное, оставляя, очевидно, позитивное на десерт.
Рис. 1.4. Рост числа узлов WWW в период 1994-99 годы В перспективе Интернет может стать и всемирной ярмаркой товаров и услуг. Ведь клиент может не только увидеть изображение товара и ознакомиться с условиями поставки, но и в диалоговом режиме получить ответы на интересующие его вопросы, а затем одним нажатием на клавишу мышки сделать заказ на понравившийся ему товар или услугу. В принципе для этого не нужен даже номер кредитной карточки, его заменит зашифрованный соответствующим образом идентификатор пользователя (сертификат) или его IP-адрес (если он работает на своей домашней машине). Таким образом, можно будет заказывать билеты на самолет или в театр, планировать программу своего телевизора на неделю вперед и т. д. Современные системы мультимедиа позволяют совместить телевизор, видеомагнитофон, факс и видеотелефон, причем это не фантазия на тему далекого будущего - это услуги доступные уже сегодня (при наличии широкополосного канала связи (64-512 Кбит/с)). Если вы имеете доступ к Интернет, вам уже не нужно платить за международные телефонные переговоры, вы можете сделать это с помощью ip-phone или другого аналогичного продукта, при условии что ваш партнер также имеет доступ к Интернет (данное требование в ближайшем будущем перестанет быть обязательным). Все более широкий круг услуг предлагает Интернет и в сфере развлечений. Здесь имеются игровые серверы, аренда обычных и сетевых компьютерных игр, различные конкурсы и соревнования. Теперь рассмотрим, как строятся каналы связи (стрелки на рис. 1.5). В простейшем случае связь можно организовать через городскую коммутируемую телефонную сеть, для этого нужны модемы - по одному на каждой из сторон канала (Рис. 1.5a). Традиционные модемы могут обеспечить при хорошем качестве коммутируемой аналоговой телефонной сети пропускную способность до 56 Кбит/с (кабельные широкополосные модемы при длине соединения порядка 2км могут обеспечить 2 Мбит/с). Привлекательность такого решения заключается в возможности подключения к любому узлу, имеющему модемный вход. Наиболее широко указанный метод связи используется для подключения к узлам Интернет домашних ЭВМ. Недостатком такого решения является низкая надежность канала (особенно в России), малая пропускная способность и необходимость большого числа входных телефонных каналов и модемов. Использование выделенной 2- или 4-проводной линии (рис. 1.5Б) обеспечивает большую надежность и пропускную способность (до 256 кбит/с при длинах канала < 10 км). Но и здесь на каждый вход требуется отдельный модем, да и скоростные модемы, работающие на выделенную линию, относительно дороги. Выделенные линии чаще служат для межсетевого соединения (рис. 1.5В). Функциональным аналогом выделенных линий являются оптоволоконные, спутниковые и радио-релейные каналы. Этот вариант позволяет строить сети с пропускной способностью в несколько 1-100 Мбит/с и более. Привлекательные возможности предлагают цифровые сети ISDN. Здесь можно использовать групповые телефонные номера, когда пара модемов обслуживает 10 и более пользователей (ведь они работают, как правило, не все одновременно). Кроме того, ISDN предлагает пользователям каналы с пропускной способностью не ниже 64кбит/c, а при необходимости возможно формирование и более широкополосных каналов. ISDN позволяет делить один и тот же канал между многими пользователями для передачи данных, факсов и телефонных переговоров. isdn органично стыкуется с внешними каналами X.25. К недостаткам системы следует отнести ограниченность ширины окна (число переданных пакетов без получения подтверждения приема), что делает неэффективным использование широкополосных и особенно спутниковых каналов. В области межсетевых связей свою нишу занимает Frame Relay. Этот протокол имеет контроль перегрузок, работающий на аппаратном уровне
Рис. 1.5. Схемы каналов, использующих городскую телефонную сеть На рис. 1.5 показана схема построения сети с использованием исключительно соединений типа точка-точка. Это наиболее часто встречающийся, но не единственный вариант. Дорога 'от околицы до околицы' прокладывается там, где она нужна и теми, кому она нужна непосредственно, но, согласитесь, построить так магистраль Москва Санкт-Петербург нельзя. При построении крупных общенациональных и интернациональных сетей применяются сверхширокополосные каналы и схемы типа опорной сети (backbone). Узлы такой сети могут располагаться в каких-то крупных организациях или быть самостоятельными (принадлежать государственным PTT). Такие сети обычно базируются на протоколах SDH (Sonet). Информация в этих сетях передается в виде больших блоков (виртуальных контейнеров). Использование опорной сети обычно оправдано при организации интернациональных связей, но бывают и исключения. Примером такого исключения является Московская опорная сеть, построенная на основе FDDI (100Мбит/с) и объединяющая более десяти научных организаций (длина первой очереди около 30 км). Московская сеть выполнена по схеме с 'прозрачными' IP-мостами, обычно же более мощные опорные сети маршрутизируемы, то есть блоки данных адресуются конкретным узлам, где они разбираются и сортируются. Контейнер может содержать сообщения, адресованные разным получателям, что несколько противоречит идеологии протоколов TCP/IP. IP-пакеты могут вкладываться в эти контейнеры и транспортироваться до заданного узла опорной сети. Классическим примером опорной сети является E-bone (Европейская опорная сеть). Эта сеть объединяет 27 стран (России в этом списке нет) и более 60 сервис-провайдеров, пропускная способность для различных участков лежит в пределах 2-34Мбит/с. Опорная сеть подобна международной автомагистрали, по ней добираются до ближайшего к точке назначения узла, а далее по 'проселочным' каналам до конечного адресата. Резкое увеличение передаваемых объемов информации в локальных и региональных сетях привело к исчерпанию имеющихся ресурсов, а реальные прогнозы потребностей указывают на продолжение роста потоков в десятки и сотни раз. Единственной технологией, которая способна удовлетворить эти потребности, являются оптоволоконные сети (Sonet, SDH, ATM, FDDI, Fiber Channel). Каналы этих сетей уже сегодня способны обеспечить пропускную способность 155-622 Мбит/с, ведутся разработки и испытания каналов с пропускной способностью в 2-20 раз больше, например, гигабитного ethernet. Осваивается техника мультиплексирования частот в оптоволокне (WDM), что позволяет поднять его широкополосность в 32 раза и в перспективе довести быстродействие каналов до 80 Гбит/с и более. По мере роста пропускной способности возрастают проблемы управления, синхронизации и надежности. Практически все сети строятся сегодня с использованием последовательных каналов. Это связано прежде всего со стоимостью кабелей, хотя и здесь существуют исключения (например, HIPPI). Разные сетевые услуги предъявляют разные требования к широкополосности канала. На рис. 1.6 представлены частотные диапазоны для основных видов телекоммуникационных услуг. В Интернет практически все перечисленные услуги доступны уже сегодня (кроме ТВ высокого разрешения). Стремительно развиваются распределенные системы вычислений (например, проект GREED), управления и информационного обслуживания. Современная технология микропроцессоров предполагает достижение быстродействия в 5 Гбит/с к 2003-4 годам (технология с характеристическим размером объектов на кристалле 80-130 нм).
Рис. 1.6. Требования к пропускной способности канала для различных видов сервиса. Рассмотрев диаграмму, можно сделать определенные прогнозы на ближайшее будущее сетей. Через несколько лет можно ожидать слияния функций телевизора и ЭВМ, а это потребует пропускных способностей от магистральных каналов на уровне 0,1-10 Гбит/с. Широкополосность каналов, приходящих в каждый семейный дом составит 1-10 Мбит/с, что позволит реализовать видео-телефонию, цифровое телевидение высокого разрешения, доступ к централизованным информационным службам и многое другое. Уже существующие оптоволоконные системы обеспечивают и в 10 раз большую пропускную способность. Можно предположить и появление локальных сетей внутри жилища. Такие сети способны взять под контроль кондиционирование воздуха, безопасность дома в самом широком смысле этого слова, например, оповещение о нежелательном вторжении, пожаре или возможном землетрясении (в сейсмически опасных районах), появление вредных примесей в воздухе. Такая система разбудит хозяина в указанное время, подогреет завтрак, напомнит о предстоящих делах на день, запросит и предоставит хозяину свежий прогноз погоды и справку о состоянии дорог, своевременно сделает заказ на авиабилет и т.д. Все это технологически возможно уже сегодня, пока относительно дорого, но цены весьма быстро падают. Примером может служить сеть CAN, разработанная для сбора данных и управления автомобилем. Стремительное расширение сети Интернет не имеет аналогов в истории, так что любой самый фантастический прогноз в этой области может сбыться. Протоколы Интернет (TCP/IP) существуют уже около 30 лет. Требования к телекоммуникационным каналам и услугам выросли, и этот набор протоколов не удовлетворяет современным требованиям. Появляются новые протоколы Delta-t (для управления соединением), NetBLT (для передачи больших объемов данных), VMTP (для транзакций; RFC-1045) и XTP для повышения эффективности передачи данных (замена TCP), блоки протоколов для работы с мультимедиа (RTP, RSVP, PIM, ST-II и пр.), но, безусловно, наиболее революционные преобразования вызовет внедрение IPv6. |
|
Previous:
Предисловие
UP:
Предисловие
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Оглавление
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.1 Рекомендации CCITT по телекоммуникациям
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Коды названий документов ITU, CCITT, ANSI и ECMA по телекоммуникационной тематике начинаются с латинской прописной буквы, за которой следует точка и номер документа. Ниже приведен список кодировок документов и перечень наиболее важных рекомендаций.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10 Приложения
UP:
10 Приложения
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.4 Таблица операций и субопераций NCP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.3 Стандартные мультикастинг-адреса Интернет
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.6 Таблица типов кадров управления доступом для сети Token Ring
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.5 Таблица операций службы каталогов Netware
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.8 Управляющие регистры модемов и их функции
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Таблица 10.8.1. Управляющие регистры модема
1) Значения по умолчанию приведены для модема Zyxel U-1496 Содержимое битовых регистров модема сохраняется в энергонезависимой памяти. На этом список регистров, используемых в современном модеме не завершается, их число обычно превышает 50. Но функции этих регистров не стандартизованы и для получения информации о них рекомендуется обратиться к оригинальной документации по конкретным модемам. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.7 Типы субвекторов кадров управления доступом
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.9 Набор AT-команд модемов
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
AT-команды посылаются ЭВМ или терминалом модему через последовательный интерфейс RS-232 (модем должен быть при этом в командном режиме). Все эти команды начинаются с префикса AT, за исключением A/, A> и +++. Код A/ вызывает выполнение модемом предыдущей команды, A> заставляет модем выполнять предыдущую команду до 9 раз или пока не будет нажата какая-либо клавиша терминала или управляющей панели модема, или пока не будет установлена связь с удаленным модемом. Команда +++ (ESC-последовательность) переводит модем в командный режим или возвращает его в режим передачи данных. Таблица 10.9.1. Стандартные AT-команды
Символ "+" указывает на то, что данный режим является режимом по умолчанию. Команда X0 заставляет модем посылать сообщения в короткой форме. Номер набирается после паузы вне зависимости от наличия гудка. Состояние "занято" не распознается. После команды X1 модем посылает сообщения в полной форме. Команда X2 отличается от X1 и X0 тем, что набор номера выполняется лишь при наличии гудка. Команда X3 требует полной формы сообщений, номер набирается после паузы вне зависимости от наличия гудка, сигнал занято идентифицируется. Команда X4 сходна с X3, но требует для набора наличия гудка. При получении команд X2 или X4 модем разрывает связь и кладет трубку, если удаленный модем переведет линию в состояние BREAK на 1,6 секунды. Существует несколько команд вывода справочной информации (работают не на всех модемах):
Таблица 10.9.2. Команды модема из расширенного набора (различие для разных типов модемов здесь может быть значительным).
Пример записи AT-команды: ATDnnnnnnnnn, где последовательность символов n включает номер телефона и модификаторы набора (к модификаторам можно отнести P и T, указывающие на импульсный и тоновый тип набора соответственно. Допускается и более удобная для восприятия запись: ATD 8, (095) 123-94-42. Таблица 10.9.3. Сообщения модема (коды результата Xn)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.8 Управляющие регистры модемов и их функции
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.26 [Z]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.1 [A]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.2 [B]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.1 [A]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.3 [C]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.2 [B]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.4 [D]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.3 [C]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.5 [E]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.4 [D]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.6 [F]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.5 [E]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.7 [G]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.6 [F]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.8 [H]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.7 [G]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.9 [I]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.8 [H]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.10 [J]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.9 [I]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||
|
10.10.11 [K]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.10 [J]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.12 [L]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.11 [K]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.13 [M]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.12 [L]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.14 [N]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.13 [M]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.15 [O]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.14 [N]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.16 [P]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.15 [O]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.17 [Q]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.16 [P]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.18 [R]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.17 [Q]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.19 [S]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.18 [R]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.20 [T]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.19 [S]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.21 [U]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.20 [T]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.22 [V]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.21 [U]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.23 [W]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.22 [V]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.10.24 [X]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.23 [W]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||
|
10.10.25 [Y]
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||
|
||||||||||||
|
Previous:
10.10.24 [X]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||
|
10.10.26 [Z]
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||
|
Previous:
10.10.25 [Y]
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|
10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Обширный файл английских сокращений по данной тематике можно найти по адресу ftp.temple.edu /pub/info/help-net/babel95c.txt. Возможен доступ к этому файлу и через listserv@vm.temple.edu или с помощью gopher.temple.edu, существуют и другие источники аналогичной информации, например, http://acm.org/~jochen _hayek/jochan_hayer_18.html#sec291 или www.srl.rmit.edu.au /pg/general/diction.html. Там же можно найти много и других справочных данных.
|
|
Previous:
10.9 Набор AT-команд модемов
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.12 Национальные коды доменов в Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Обычно завершающий код Internet-адреса определяет государственную принадлежность узла, сервера или ЭВМ (информация взята на сервере RIPE Network Coordination Center (X.500 в ISO 3166)). Информация упорядочена согласно англоязычным названиям стран.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
||||||||||||||||||||||||||||||||||||||||||||
|
10.13 Список кодов и откликов на почтовые команды и сообщения
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.12 Национальные коды доменов в Интернет
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
||||||||||||||||||||||||
|
10.14 Принципы формирования кода отклика в системе SMTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||
|
Любой код отклика содержит три цифры. Первая цифра говорит о том, является ли отклик положительным, отрицательным или промежуточным. Отправитель, проанализировав первую цифру, может решить, продолжать выполнение задачи, повторить последнюю операцию или отказаться от своей затеи. Для уточнения типа ошибки отправитель может проанализировать вторую цифру, последняя цифра уточняет диагноз.
Вторая цифра кода может иметь следующие значения:
Третья цифра уточняет смысл второй. |
||||||||||||||||||||||||
|
Previous:
10.13 Список кодов и откликов на почтовые команды и сообщения
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.15 Базовые протоколы Internet
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.14 Принципы формирования кода отклика в системе SMTP
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
10.16 Разъем AUI
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.15 Базовые протоколы Internet
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.17 Разводка разъемов
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
RJ-11 (6 контактов)
Телефонный разъем
Применение неэкранированных скрученных пар
TX - передача; RX - прием; BI - двунаправленная передача/прием.
Интерфейс RS-530
Интерфейс V.24/RS-232 (9-контактный)
Интерфейс V.35
Интерфейс X.21
Интерфейс V.36/RS-449
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.16 Разъем AUI
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.18 Краткий справочник по командам UNIX
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Первая версия UNIX была создана в 1971 году, в 1979 году была подготовлена 7-я редакция (Bourne Shell и компилятор С, разработанная Керниганом и Ритчи; тогда же фирма Microsoft купила права и разработала свою версию для РС - XENIX). Первая версия BSD (Беркли) была подготовлена в 1978 году. В 1981 году закончена версия, поддерживающая стек протоколов TCP/IP (4.2BSD). В 1990 году в UNIX была встроена система NFS. Несколько лет назад в университете Хельсинки (Линусом Торвальдсом) была разработана версия UNIX, известная под названием LINUX. UNIX имеет двухуровневую структуру: ядро, где сконцентрированы базовые услуги и оболочка, куда входят редакторы, интерпретаторы, например СС, а также lp, routed, inetd, init и т.д. Код UNIX написан на Си (на 30% больше по объему и на 20% ниже по производительности, чем версия на ассемблере). Система открытая, рассчитанная на многозадачность и большое число пользователей. Интерфейс системных вызовов предоставляет набор услуг ядра и определяет формат запросов. Ядро состоит из трех частей:
Файловая система обеспечивает интерфейс доступа к данным на дисковых накопителях и в периферийных устройствах ввода/вывода. Одни и те же функции open(), read(0, write() могут использоваться при чтении/записи на диске и при выводе данных на принтер или терминал. Файловая система управляет правами доступа и привилегиями. Она обеспечивает перенаправление запросов, адресованных периферийным устройствам. Система управления процессами ЭВМ, причем их число обычно превышает число ЦПУ. Специальной задачей ядра является планирование выполнением процессов (scheduler). Сюда входит управление ресурсами системы (временем ЦПУ, дисковым пространством, распределением памяти и т.д.). Данная система занимается созданием и удалением процессов, синхронизацией их работы и взаимодействием процессов (например, обменом данными). Система ввода/вывода обслуживает запросы файловой системы и системы управления процессами для доступа к периферийным устройствам (дискам, лентам, печати, терминалам). Эта система организует взаимодействие с драйверами этих устройств. Файловая система UNIX представляет собой древовидную структуру. Каждый файл имеет имя, которое определяет его место на дереве файловой системы. Корнем этой системы является корневой каталог с именем /. В этом каталоге обычно содержатся каталоги:
Полные имена остальных файлов содержат путь - список каталогов, размещенных между / и данным файлом. По этой причине полное имя любого файла начинается с символа / (не содержит в отличие от Windows имени диска (например, CD), другого внешнего устройства или удаленной ЭВМ). UNIX, тем не менее, не предполагает наличия лишь одной файловой системы. Число таких файловых систем в этой ОС не лимитировано, они могут располагаться на одном дисковом накопителе, на разных устройствах или даже на разных ЭВМ. Каждый файл имеет сопряженные с ним метаданные, записанные в индексных дескрипторах - inode. Имя файла является указателем на его метаданные (метаданные не содержат указателя на имя файла). Существует 6 типов файлов:
Обычный файл является наиболее распространенным типом. Для операционной системы такой файл представляется простой последовательностью байтов. Интерпретация содержимого такого файла находится в зоне ответственности прикладной программы, которая с ним работает. Каталог - это файл, содержащий имена находящихся в нем файлов и указатели на информацию, позволяющую ОС производить операции над этими файлами. Запись в каталог имеет право только ядро. Каталог представляет собой таблицу, каждая запись в которой соответствует некоторому файлу. Файл внешнего устройства обеспечивает доступ к этому прибору. UNIX различает символьные и блочные файлы. Символьные файлы служат для не буферизованного обмена, а блочные предполагают обмен порциями данных фиксированной длины. Каналы с именем (FIFO) - это файлы, служащие для связи между процессами. Файловая система допускает наличие нескольких имен у одного файла. Связь имени файла с его метаданными называется жесткой связью. С помощью команды ln можно создать еще одно имя для файла. Особым типом файла является символическая связь, позволяющей косвенно обращаться к файлу. Символическая связь является особым типом файла. Socket служит для взаимодействия между процессами. Интерфейс socket используется, например, для доступа к сети TCP/IP. Любой файл имеет двух владельцев - собственно создателя и группу (chown, chgrp и chmod). Файл создается не пользователем, а процессом, им запущенным. Атрибуты этого процесс присваиваются и файлу (r, w и x). Имеется также несколько дополнительных атрибутов, среди них sticky bit , который требует сохранения образа \исполняемого файла в памяти после завершения его работы. Атрибуты SUID и GUID позволяют изменить права пользователя в направлении расширения (до уровня создателя файла) на время исполнения данной программы (это используется, например, в случае работы с файлом /etc/passwd) . В случае каталогов sticky bit позволяет стереть только файлы, которыми владеет пользователь. Различается несколько типов процессов.
Процессы создаются процедурой fork и характеризуются набором атрибутов:
Для запуска задачи процесс должен выполнить системный вызов exec. При этом не порождается новый процесс, а код процесса замещается полностью кодом запускаемой программы. Так, когда пользователь вводит команду ls, текущий процесс shell осуществляет вызов fork, порождая новый процесс - копию shell. Порожденный процесс осуществит вызов exec, указав в качестве параметра имя исполняемого файла (ls). Ls замещает shell, а по завершении работы процесс уничтожается.
Сигналы
Сигналы служат для того, чтобы передавать от одного процесса к другому или от ядра к какому-то процессу, уведомление о происхождении некоторого события. Примером такого события может быть нажатие клавиши мышки или нажатие клавиш <Ctrl><C> (SIGINIT)или <Ctrl><Alt><Del>. Для отправления сигнала служит команда kill pid, где sig_no - номер или символическое название сигнала, pid - идентификатор процесса, которому адресован сигнал. Для остановки процесса, выполняемого в фоновом режиме можно послать сигнал SIGTERM. Например, kill $!, где $! - переменная, где хранится идентификатор процесса (PID), запущенного последним. Таблица 1. Сигналы
Сигнал может игнорироваться, могут быть предприняты действия, предусмотренные по умолчанию, или процесс может взять на себя функцию обработки сигнала. Если процесс не остановился, существует способ заставить его выполнить это требование, послав команду: kill -9 pid Иногда и это может не помочь, например, в случае процессов зомби (процесса нет а запись о нем имеется), операции в NFS или с ленточным ЗУ. Атрибуты пользователя в файле /etc/passwd (одна строка - одна запись): имя:passwd-encod:UID:GID:комментарии:home-dir:shell имя уникальное регистрационное имя пользователя (вводится при login) passwd-encod закодированный пароль пользователя. Часто пароль хранится в отдельном файле, а здесь вместо него проставляется символ х. Если в этом поле стоит символ *, то данный пользователь в систему войти не может (используется для псевдопользователей) UID Идентификатор пользователя, который наследуется порожденными им процессами. ROOT имеет UID=0. GID Идентификатор первичной группы пользователя, который соответствует идентификатору в файле /etc/group, где содержится список имен пользователей-членов группы. Комментарии Обычно здесь записывается истинное имя пользователя, здесь может быть записана дополнительная информация, например, телефон или e-mail пользователя, считываемые программой finger. home-dir Базовый каталог пользователя, где он оказывается после входа в систему. Shell Название программы, используемой системой в качестве командного интерпретатора (например, /bin/sh). Разные интерпретаторы используют разные скрипты инициализации (.profole, .login и т.д.). В первой строке скрипта помещается строка #! /bin/sh, указывающая на тип и размещения интерпретатора. Поскольку скрипт исполняется интерпретатором, работает он медленно. Значение PID сохраняется в переменной $$, что можно использовать при формировании имен временных файлов, гарантируя их уникальность. Переменные $1, $2 и т.д. несут в себе значения параметров, переданных скрипту. Число таких параметров записывается в переменной $#. Результат работы скрипта заносится в переменную $?. Ненулевое значение $? свидетельствует об ошибке. В переменной $! Хранится PID последнего процесса, запущенного в фоновом режиме. Переменная $* хранит в себе все переменные, переданные скрипту в виде единой строки вида: "$1 $2 $3 .". Другое представление переданных параметров предлагает переменная $@= "$1" "$2" "$3" . Таблица 2. Перенаправление потоков ввода/вывода
Символ | иногда называется конвейером. Например, команда: ps - ef | grep proс осуществляет вывод данных о конкретном процессе proс. Несколько более корректна команда: ps - ef | grep proс grep -v grep так как в потоке, формируемом командой ps , присутствуют две строки, содержащие proс - строка процесса proс и строка процесса grep с параметром proс. Для запуска выполнения команды в фоновом режиме достаточно завершить ее символов &. Виртуальная память процесса состоит из сегментов памяти. Размер, содержимое и размещение сегментов определяется самой программой (например, применением библиотек). Исполняемые файлы могут иметь формат COFF (Common Object File Format) и ELF (Executable and Linking Format). Функция main() является первой, определенной пользователем. Именное ей будет передано управление после формирования соответствующего окружения запускаемой программы. Функция main определяется следующим образом. main(int argc, char *argv[], char *envp[]); Аргумент argc определяет число параметров, переданных программе. Указатели на эти параметры передаются с помощью массива argv[], так через argv[0] передается имя программы, argv[1] - несет в себе первый параметр и т.д. до argv[argc-1]. Массив envp[] несет в себе список указателей на переменные окружения, передаваемые программе. Переменные представляют собой строки имя=значение_переменной. В среде UNIX существует два базовых интерфейса для файлового ввода/вывода.
С файлом ассоциируется дескриптор, который в свою очередь связан с файловым указателем смещения, начиная с которого будет произведена последующая операция чтения/записи. Каждая операция чтения или записи увеличивает этот указатель на число переданных байтов. При открытии файла указатель принимает значение нуль. Процессы Процесс характеризуется набором атрибутов и идентификаторов. Важнейшим из них является идентификатор процесса PID и идентификатор родительского процесса PPID. PID является именем процесса в ОС. Существует еще 4 идентификатора, которые определяют доступ к системным ресурсам.
Процессы с идентификаторами SUID и SGID ни при каких обстоятельствах не должны порождать других процессов . Процесс при реализации использует разные системные ресурсы - память, процессор, возможности файловой системы и ввод/вывод. ОС создает иллюзию одновременного исполнения нескольких процессов (предполагается, что имеется только один процессор), распределяя ресурсы между ними и препятствуя злоупотреблениям. Выполнение процесса может происходить в двух режимах - в режиме ядра (kernel mode) и в режиме пользователя (user mode). В режиме пользователя процесс исполняет команды прикладной программы, доступные на непривилегированном уровне. Для получения каких-либо услуг ядра процесс делает системный вызов. При этом могут исполняться инструкции ядра, но от имени процесса, реализующего системный вызов. Выполнение процесса переходит в режим ядра, что защищает адресное пространство ядра. Следует иметь в виду, что некоторые инструкции, например, изменение содержимого регистров управления памятью, возможно только в режиме ядра. По этой причине образ процесса состоит из двух частей: данных режима ядра и режима пользователя. Каждый процесс представляется в системе двумя основными структурами данных - proc и user, описанными в файлах <sys/proc.h> и <say/user.h>, соответственно. Структура proc является записью системной таблицы процессов, которая всегда находится в оперативной памяти. Запись этой таблицы для активного в данный момент процесса адресуется системной переменной curproc. Каждый раз при переключении контекста, когда ресурсы процессора передаются другому процессу, соответственно изменяется содержимое переменной curproc, которая теперь будет указывать на proc активного процесса. Структура user, называемая также u-area или u block, содержит данные о процессе, которые нужны ядру при выполнении процесса. В отличие от структуры proc, адресуемой с помощью указателя curproc, данные user размещаются в определенном месте виртуальной памяти ядра и адресуются через переменную u. u area также содержит стек фиксированного размера - системный стек или стек ядра (kernel stack). При выполнении процесса в режиме ядра операционная система использует стек, а не стек процесса. Современные процессоры поддерживают разбивку адресного пространства на области переменного размера - сегменты, и области фиксированного объема - страницы. Процессоры Intel позволяют разделить память на несколько логических сегментов. Виртуальный адрес при этом состоит из двух частей - селектора сегмента и смещения в пределах сегмента. Поле селектора INDEX указывает на дескриптор сегмента, где записано его положение, размер и права доступа RPL (Descriptor Privilege Level). При запуске программы командный интерпретатор порождает процесс, который наследует все 4 идентификатора и имеет те же права, что и shell.Так как в сеансе пользователя прародителем всех процессов является login shell, то их идентификаторы будут идентичны. При запуске программы сначала порождается новый процесс, а затем загружается программа. Процесс порождается с помощью системного вызова fork : #include <sys/types.h> Порожденный процесс (дочерний) является точной копией родительского процесса. Дочерний процесс наследует следующие атрибуты:
Конфигурация виртуальной памяти также сохраняется (те же сегменты программ, данных, стека и пр.). После завершения вызова fork оба процесса будут выполнять одну и ту же инструкцию. Отличаются эти процессы PID, PPID (идентификатор родительского процесса), дочерний процесс не имеет сигналов, ждущих доставки, отличаются и код, возвращаемый системным вызовом fork (родителю возвращается PID дочернего процесса, а дочернему - 0). Если код =0, то возврат осуществляется только в родительский процесс. Для загрузки исполняемого файла используется вызов exec (аргумент - запускаемая программа). При этом существующий процесс замещается новым, соответствующим исполняемому файлу.
Процессы могут уведомлять друг друга о произошедших событиях с помощью сигналов, каждый из которых имеет символьное имя и номер. Сигнал может инициировать попытка деления на 0 или обращение по недопустимому адресу. ОС UNIX создает иллюзию одновременного исполнения процессов, стараясь эффективно распределять между ними имеющиеся ресурсы. Выполнение процесса возможно в режиме ядра (kernel mode) и в режиме задачи (user mode). В последнем случае процесс реализует инструкции прикладной программы, допустимые на непривилегированном уровне защиты процессора. При этом системные структуры данных недоступны. Для получения таких данных процесс делает системный вызов (на время происходит переход процесса в режим ядра). Каждый процесс представляется в системе двумя основными структурами данных - proc и user, описанными в файлах <sys/proc.h> и <sys/user.h>. Структура proc представляет собой системную таблицу процессов, которая находится в оперативной памяти резидентно. Текущий процесс адресуется системной переменной curproc . Структура user размещается в виртуальной памяти. Область user содержит также системный стек и стек ядра. Распределение оперативной памяти всегда бывает динамическим. Процессы выполняются в своем виртуальном адресном пространстве. Виртуальные адреса преобразуются в физические на аппаратном уровне при активном участии ОС. Объем виртуальной памяти может значительно превышать объем физической. Процессоры обычно поддерживают разделение адресного пространства области переменного размера - сегменты и фиксированного размера - страницы. Для каждой страницы может быть задано собственная схема преобразования виртуальных адресов в физические. Intel поддерживает работу с сегментами (сегментные регистры), где задается селектор сегмента (дескриптор) и смещение в пределах сегмента. Распределение ресурсов процессора осуществляется планировщиком, который выделяет кванты времени каждому из активных процессов. Здесь приложения делятся на три класса:
Каждый процесс в UNIX имеет свой контекст (контекст сохраняется при прерывании процесса). Контекст определяется следующими составляющими:
Работа планировщика UNIX основана на использовании приоритетов процессов. Если процесс имеет наивысший приоритет и готов к работе, планировщик прервет работу текущего процесса, если у него более низкий приоритет, даже при условии, что он не выбрал до конца свой квант времени. Работа программы ядра обычно не прерывается. Это касается и процессов user, если они в данный момент осуществляют системный вызов. Каждый процесс имеет два атрибута приоритета - текущий и относительный (nice) . Первый служит для реализации планирования, второй присваивается при порождении процесса и воздействует на значение текущего приоритета. Текущий приоритет может характеризоваться кодами 0 (низший) - 127 (высший). Для режима user используются коды приоритета 0-65, а для ядра - 66-94 (системный диапазон). Процессы с кодами 96-127 имеют фиксированный приоритет, который не может изменить ОС (обычно служат для процессов реального времени). Процессу, ожидающему освобождения какого-то ресурса, система присваивает значение кода приоритета сна, выбираемое из диапазона системных приоритетов (в версии BSD большему коду соответствует меньший приоритет). Процессы типа "ожидание ввода с клавиатуры" имеют высокий приоритет сна и им сразу предоставляется ресурс процессора. Фоновые же процессы, забирающие много времени ЦПУ, получают относительно низкий приоритет. Каждую секунду ядро пересчитывает текущие значения кодов приоритета для процессов, ожидающих запуска (коды<65), повышая вероятность получения ими требуемого ресурса. Так 4.3BSD использует для расчета приоритета процесса следующую формулу: p_cpu = p_cpu*(2*load)/(2*load+1), где load - среднее число процессов в очереди за последнюю секунду. В результате после долгого ожидания даже низкоприоритетный процесс имеет определенный шанс получить требуемый ресурс. Ядро генерирует и посылает процессу сигнал в ответ на определенные события, вызванные самим процессом, другим процессом, прерыванием (например, терминальным) или внешним событием. Это могут быть Alarm, нарушение по выделенным квотам, особые ситуации, например деление на нуль и т.д. Некоторые сигналы можно заблокировать, отложить их обработку, или проигнорировать, для других (например, SIGKILL и SIGSTOP) это невозможно. Взаимное влияние процессов в UNIX минимизировано (многозадачность!), но система была бы неэффективной, если бы она не позволяла процессам обмениваться данными и сигналами (IPC - Inter Process Communications). Для реализации этой задачи в UNIX предусмотрены:
Для создания канала используется системный вызов pipe int pipe(int *filedes); который возвращает два дескриптора файла filedes[0] - для записи в канал и filedes[1] для чтения из канала. Когда один процесс записывает данные в filedes[0], другой получает их из filedes[1]. Здесь уместен вопрос, как этот другой процесс узнает дескриптор filedes[1]? Нужно вспомнить, что дочерний процесс наследует все дескрипторы файлов родительского процесса. Таким образом, к дескрипторам имеет доступ процесс, сформировавший канал, и все его дочерние процессы, что позволяет работать каналам только между родственными процессами. Для независимых процессов такой метод обмена недоступен. Канальный обмен может быть запущен и с консоли. Например: cat file.txt | wc Здесь символ | олицетворяет создание канала между выводом из файла file.txt и программой wc, подсчитывающей число символов в словах. Процессы эти не являются независимыми, так как оба порождены процессом shell. Метод FIFO (в BSD не реализован) сходен с канальным обменом, так как также организует лишь однонаправленный обмен. Такие каналы имеют имена, что позволяет их применять при обмене между независимыми процессами. FIFO - это отдельный тип файла в файловой системе UNIX. Для формирования FIFO используется системный вызов mknod. int mknod(char *pathname, int mode, int dev); где pathname - имя файла (FIFO), Допускается создание FIFO и из командной строки: mknod name p.
Сообщения Очереди сообщения являются составной частью UNIX System V. Процесс, заносящий сообщение в очередь, может не ожидать чтения этого сообщения каким-либо другим процессом. Сообщения имеют следующие атрибуты:
Очередь сообщений имеет вид списка в адресном пространстве ядра. Для каждой очереди ядро формирует заголовок(msqid_ds), где размещаются данные о правах доступа к очереди (msg_perm), о текущем состоянии очереди (msg_cbytes - число байтов msg_qnum - число сообщений в очереди), а также указатели на первое и последнее сообщение. Создание новой очереди сообщений осуществляется посредством системного вызова msgget: #include <sys/types.h> Эта функция выдает дескриптор элемента очереди, или -1 - в случае ошибки. Процесс может с помощью оператора msgsnd поместить сообщение в очередь, получить сообщение из очереди посредством msgrcv и манипулировать сообщениями с помощью msgctl. Семафоры Для управления доступом нескольких процессов к разделяемым ресурсам используются семафоры. Семафоры являются одной из форм IPC (Inter-Process Communication). Для обеспечения работы нужно обеспечить выполнение следующих условий:
Помимо значения семафора в структуре sem записывается идентификатор процесса, вызвавшего последнюю операцию над семафором, число процессов, ожидающих увеличения значения семафора. Разделяемая память Активное использование каналов, FIFO и очередей сообщений может привести к снижению производительности машины. Это сопряжено с тем, что передаваемые данные сначала из буфера передающего процесса в буфер ядра, и только затем в буфер принимающего процесса. Техника разделяемой памяти позволяет избавиться от этих потерь, предоставив доступ двум или более процессам доступ общей зоне памяти. Пока один процесс читает данные из разделяемой памяти, другой не должен туда писать и наоборот. Такого рода согласование работы осуществляется посредством семафоров. Файловая система В настоящее время UNIX использует виртуальную файловую систему, которая допускает работу с несколькими физическими файловыми системами самых разных типов. Система S5FS занимает раздел диска и состоит из трех компонентов.
Индексный дескриптор (inode) несет в себе информацию о файле, необходимую для обработки метаданных файла. Каждый файл ассоциируется с одним inode. При открытии файла ядро записывает копию inode в таблицу in-core inode. Слабой точкой файловой системы F5FS является суперблок. Он записан на диске в одном экземпляре и по этой причине уязвим. Низкая производительность этой файловой системы связана с тем, что метаданные файлов размещены в начале диска, а данные на относительном расстоянии от них. Это вызывает постоянные перемещения считывающих головок, снижая быстродействие системы. Имена файлов хранятся в специальных файлах, называемых каталогами. По этой причине любой реальный файл данных может иметь любое число имен. Каталог файловой системы представляет собой таблицу, каждый элемент которой имеет длину 16 байтов: 2 байта номер индексного дескриптора, 14 - его имя. Число inode не может превышать 65535. Имя файла в этой системе (S5FS) не должно превышать 14 символов. имеет имя "..".При удалении имени файла из каталога номер соответствующего inode устанавливается равным 0. Ядро не удаляет свободные элементы, по этой причине размер каталога при удалении файлов не уменьшается. Новая файловая система FFS (Berkeley Fast File System) использует те же структуры длинные имена файлов (до 255 символов). Записи каталога имеют следующую структуру: d_namlen - Длина имени файла Имя файла имеет переменную длину, дополняемую нулями до 4-байтовой границы. Метаданные активных файлов, на которые ссылаются один или более процессов, представлены в памяти в виде in-core inode. В виртуальной файловой системе в качестве in-core inode выступает vnode. Структура vnode одинакова для всех файлов и не зависит от типа файловой системы. vnode содержит данные, необходимые для работы виртуальной файловой системы, а также характеристики файла, такие как его тип. Получение описания инструкций (Help): man <имя объекта> Уход из UNIX Ctrl-d или logout.
ls [-флаги...] имя... Распечатка каталога Флаги:
Например: mkdir A B (образует 2 каталога)
Доступ к каталогу. Проверка существования файлов и каталогов, а также установленных для них возможностей.
Команда test позволяет также сравнивать целые числа (напр., test "$X" -eq "$Y"). <параметр> возвращает значение true, если файл существует и:
Копирование файлов (файла в файл или файлов в каталог) cp файл1 файл2 или cp файл1 файл2 .... файлN каталог.
uucp [флаги] файл1 имя_ЭВМ!файл2 имя ЭВМ отделяется от имени файла с помощью "!". Перед именем файл2 необходимо указать также имя каталога или поставить "~", если оно неизвестно.
Флаги:
Переименование файлов или каталогов mv файл1 файл2 или mv каталог1 каталог2 Печать файлов Печать содержимого одного или нескольких файлов c автоматическим разбиением на страницы и с заголовком на каждой странице; pr [флаги]...[файл]... Флаги:
Печать файлов одновременно с выполнением других операций lpr [флаги]...[файл]... Флаги:
lp [флаги] [файл_1, файл_2,....файл_N] Флаги:
Сравнение файлов Сравнение файлов и выдача отчета о различиях; cmp [-l][-s] файл1 файл2 Флаги:
Удаление файлов rm [флаги] файл Флаги:
Поиск файлов find каталог ... аргументы ... Просматриваются рекурсивно все подкаталоги для каждого указанного каталога и ищутся файлы отвечающие условиям, заданным в аргументах. Числовые аргументы со знаком "+" означают "больше чем", а числовой аргумент со знаком "-" "меньше чем". Аргументы - это условия поиска; любому аргументу предшествует знак "-", все аргументы считаются соединенными знаком "И". -o соединитель ИЛИ, перед каждым символом "ИЛИ" должен ставиться знак "\"; Допускаются аргументы:
Очистка индексного дескриптора clri файл-система индекс... Удаляет индексный дескриптор для файла, отсутствующего в каталогах. Библиотекарь ar флаги [имя] библиотека [файл...] Флаги:
Построение таблицы с содержанием библиотеки ranlib [библиотека] Служит для подготовки работы редактора связей.
chmod код_защиты файл ... 4000 разрешение смены идентификатора пользователя; Символьная форма позволяет установить биты кода защиты индивидуально и имеет вид: [ugoa][+-=][rwxstugo], где
Проверка корректности каталогов dcheck [индексы][файловая система] Сравнивает счетчик числа связей в индексном дескрипторе с числом записей в каталогах, ссылающихся на данный дескриптор. Индексы генерируются командой icheck. Проверка распределения памяти в файловой системе icheck [-s][-b блок...][файловая система] Исследуется файловая система, проверяется правильность списков свободных и используемых блоков, выводит общее число файлов, каталогов, число используемых блоков, число свободных блоков и т.д. Флаги: -b выдача диагностических сообщений для заданных блоков. -s создание списка свободных блоков; Генерация имен файлов по заданным индексам nchek [-i индексы] [-a][-s][файловая система] Генерирует полные имена файлов для заданного списка индексов файловой системы, осуществляет поиск имен поврежденных файлов. Флаги:
Создание файловой системы /etc/mkfs [файловая система][размер] Создает новую файловую систему на диске или части диска согласно числу блоков, заданному аргументом размер. Такая система может быть присоединена к основной файловой системе с помощью команды mount. Создание специальных файлов /etc/mknod имя [c][b] тип устройство Создание специальных файлов, располагающихся в каталоге /dev, где описываются характеристики драйверов устройств и файловых систем. Аргументы тип и устройство относятся к драйверу и к специальному входу в драйвер. Монтирование файловой системы /etc/mount файловая-система [-r] имя файла Демонтирование файловой системы /etc/umount файловая-система Временная смена идентификатора пользователя su [идентификатор] Изменяет идентификатор пользователя, и выполняет операции, которые возможно было бы нельзя выполнить с другим идентификатором из-за отсутствия права доступа. Для возврата к исходной среде следует нажать ctrl-d. Модификация суперблока - sync Освобождаются буферы и модифицируется файловая система на диске. Sync автоматически выполняется через заданный промежуток времени, задаваемый администратором. Библиотекарь магнитной ленты (или дискеты) tar [флаги][имя] Сохраняет и восстанавливает файлы и каталоги с использованием магнитной ленты (или дискет). Флаги:
Смена владельца файла chown chown имя файл Смена группы chgrp chgrp группа файл Изменение направления ввода/вывода
tr [-cds][строка_1][строка_1] Считывает данные из стандартного ввода. Символы, не совпадающие с символом в аргументе "строка_1", передается на стандартный вывод без изменения. Символы же, совпадающие с символом в аргументе "строка_1", заменяются на соответствующие символы из аргумента "строка_2". Асинхронное выполнение команд
wait вводится, когда нужно подождать завершения какого-то процесса. Появление приглашения после ввода команды wait указывает на завершение всех запущенных ранее процессов. at время [дата_и_время][приращение] список_команд Команда планирования выполнения заданий. Позволяет выполнить команду в указанный день и час, которые могут модифицироваться необязательным приращением. at -r идентификатор_задания Отменяет запрос. batch планирует задания на то время, когда это будет позволять система. Системные команды mail имя файла или mail [-r] [-q] [-p] [-f файл] Обращение к почтовому серверу. Флаги:
При чтении почты можно пользоваться командами:
Сообщение всем работающим пользователям wall администратор что-то сообщает всем. Конец сообщения по ctrl/d. Посылка сообщения другому пользователю write имя [терминал] Разрешение или отмена сообщений mesg [y] [n] (флаги - "y" и "n") присылаемых другими пользователями. Команды обработки файлов
1 - строки встречаются только в файле1; Преобразование файла
Аргументы:
Поиск строк с заданным шаблоном grep [флаг] ... выражение [файл] Служит для поиска соответствующих выражений (строк) в одном или нескольких файлах. Флаги:
Восьмеричный дамп файла od[-флаги] файл[[+] смещение [.][b]]. Флаги:
Сохранение (зашита) файловой системы dump [флаги[аргумент...] файловая система] Используется администратором для обеспечения сохранности всех данных в файловой системе. Флаги:
Восстановление файловой системы restor флаги [аргументы] Чтение магнитных лент, записанных командой dump. Разбиение файла на части split [-n][файл[имя]] разбивает файл на части по n строк (по умолчанию n=1000). Если задано имя выходного файла, то генерируется последовательность файлов с данным именем и буквами aa, ab, ac,... в конце. Если имя выходного файла не задано, используется имя "x". Подсчет числа слов wc[-lwc] [файл] Определяет число строк, слов и символов в одном или более файлов. Строки в файле разделяются символом "\n", слова - пробелами, горизонтальной табуляцией или переводом строки. Флаги:
Вывод одинаковых строк файла uniq [-флаги[+n][-n]][вход][выход] Находит одинаковые соседние строки файла. По умолчанию все одинаковые строки кроме одной удаляются. Флаги:
Обнаружение различий в файлах diff[-флаги]файл1 файл2 Определяются изменения, которые должны быть произведены в файлах, чтобы сделать их идентичными. Позволяет экономить место при хранении ряда версий файла. Флаги:
Сортировка и слияние файлов sort[-флаги...][+поз1[-поз2]]...[-o имя][-T каталог][имя]... соединяет и сортирует файлы, помещает результат в заданный файл. Если ключ сортировки не задан, при сравнении используется вся строка. Флаги:
Управление выполнением программы Вывод аргументов echo[-n][аргумент] Выводит в стандартный файл заданные ей аргументы, разделяя их пробелами и завершая вывод переводом строки. Служит для сообщения о выполнении последовательности команд. Флаг -n предоставляет возможность отменить перевод строки после вывода аргументов. Уничтожение процесса kill [-флаг] процесс... единственный флаг, допустимый в команде kill, - номер сигнала, например флаг -9 безусловно ликвидирует процесс. Задержка выполнения команды sleep время Задерживает выполнение команды на время, заданное в секундах. Понижение приоритета команды nice [-число]команда[аргументы] Позволяет выполнить другую команду, с более низким приоритетом. Аргумент-число определяет степень понижения приоритета. Чем больше число, тем меньше приоритет. Дублирование стандартного вывода tee [флаг]...[флаг]... команда читает информацию из стандартного ввода и выводит ее одновременно на терминал и в заданные файлы. Флаги:
Печать и установка времени date [ггммддччмм][.сс]]
Кто работает в системе? who [файл] [am I] выдает список всех пользователей, работающих в данный момент, и имена их терминалов. [файл] - имя файла, где хранится информация о текущих пользователях. По умолчанию /etc/utmp. [am I] - дает возможность сообщить под каким именем вы вошли в систему. Получение имени терминала tty печатает имя терминала, за которым вы работаете. Состояние процессов ps [флаг...][файл] предоставляет информацию об активных процессах в системе. Флаги:
Сведения об использовании диска du[-s][-a][имя...] Флаги:
Сведения о свободных блоках на диске df [файловая система] выводит количество блоков, доступных в заданной файловой системе. Печать календаря cal [месяц]год Установка функций терминала stty [аргументы...] позволяет узнать состояние любого терминала и настроить его на требуемый режим работы. Аргументы:
Установка табуляции tabs [аргументы] Устанавливает параметры табуляции для любого терминала. Аргументы:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.17 Разводка разъемов
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.19 Символьный набор HTML
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Символьный набор документов HTML, заданный "SGML Declaration for HTML". Этот набор базируется на документе [ISO-8859-1].
<!-- Набор символьных объектов. Типичное обращение: <!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1//EN//HTML">
Эталонные символьные объекты для символов, математических символов и греческих букв Эталонные символьные объекты в этом разделе производят символы, которые могут быть представлены глифами из широко известного шрифта Adobe Symbol, включая греческие буквы, различные скобки, а также секцией математических операторов (+ . - и т.д.). Чтобы поддержать эти объекты агенты пользователя могут поддерживать целиком ISO10646 или использовать другие средства. Отображение глифов для этих символов может быть реализовано через отображение соответствующих символов ISO10646 или другими способами, такими как установление внутреннего соответствия перечисленных объектов, коды символов и порядковые номера символов в заданном шрифтовом наборе. Использование греческих символов. Этот символьный набор содержит все буквы, используемые в современном греческом алфавите. Однако, он не включает в себя греческую пунктуацию, символы со знаками ударения или безпробельные акценты (tonos, dialytika), необходимые для их формирования. Здесь нет архаичных букв, уникальных коптских букв или комбинированных букв политонического греческого языка. Определенные здесь объекты предназначены не для представления современного греческого текста, а для применения в технических математических текстах. Список символов <!-- Математические, греческие и другие символы HTML --> <!-- Ниже приводится набор соответствующих объектов ISO, если не введены новые имена. Новые имена (напр., не из списка ISO 8879) не противоречат другим существующим именам объектов ISO 8879. Коды символов ISO 10646 даны для каждого символа в шестнадцатеричной нотации. Значения CDATA приведены в десятичном виде ISO 10646 и относятся к символьному набору документа. Имена соответствуют Unicode 2.0. -->
*) Не существует Sigmaf, и нет также символа U+03A2
**) bullet не тождественен оператору bullet, U+2219
***) Cимвол alef не тождественен букве иврита alef, U+05D0 хотя тот же самый глиф может быть использован для отображения обоих символов
+ ) Уникод не утверждает, что lArr тождественно 'implied by' но не имеет какого-либо другого символа для этих целей. Так ? lArr может использоваться для 'is implied by' как это рекомендует ISOtech++ ) Уникод не утверждает, что это 'implies' символ, но не имеет другого символа для этих целей, таким образом, ? rArr может использоваться для 'implies' как это рекомендует ISOtech
# ) prod не тождественен символу U+03A0 'греческая прописная буква pi' хотя один и тот же глиф может быть использован для отображения обоих## ) sum не тождественен символу U+03A3 'греческая прописная буква сигма' хотя один и тот же глиф может быть использован для отображения обоих### ) tilde оператор не тождественен символу U+007E, хотя один и тот же глиф может быть использован для отображения обоих#### ) Оператор dot не тождественен символу U+00B7 центральная точка
Эталонные символьные объекты для символов разметки текста и интернационализации Эталонные символьные объекты в этой секции предназначены для символов разметки текста (markup) (они те же, что и в HTML 2.0 и 3.2), для обозначения пробелов и дефисов. Остальные символы в этой секции используются для интернационализации. Добавлены некоторые символы из CP-1252, которые не встречаются в наборах HTMLlat1 или HTMLsymbol. Все они из диапазона 128 - 159 символьного набора cp-1252. Эти объекты позволяют обозначать символы независимо от платформы. Для поддержки этих объектов агенты пользователя могут поддерживать полный набор ISO10646 или использовать другие средства. Отображение глифов этих символов может быть реализовано, если возможно отображение символов ISO10646 или другими средствами. Список символов <!-- Набор символьных объектов: <!-- Используется набор объектов ISO, если не введены новые имена. Новые имена (напр., не из списка ISO 8879) не будут конфликтовать с любыми существующими именами объектов ISO 8879. Коды символов ISO 10646 приводятся для всех символов в шестнадцатеричном виде. Значения CDATA представляют собой десятичные коды ISO 10646. Имена соответствуют именам Unicode 2.0. -->
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.18 Краткий справочник по командам UNIX
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||
|
10.20 Справочные данные по математике
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||
Приводимые в данном разделе определения вляются "шпаргалкой" на случай, когда вы знаете предмет, но что-то забыли. Для первичного изучения математических основ рекомендую обратиться к серьезным монографиям и учебникам. Условная вероятность .В теории вероятностей характеристикой связи событий А и B служит условная вероятность P(А|B) события А при условии B, определяемая как P(А|B) =
Если событие B ведет к обязательному осуществлению А:
b
Если имеется полная система несовместимых событий B =B1, B2,. т.е. такая система непересекающихся событий, одно из которых обязательно осуществляется, то вероятность события A (P(A)) выражается через условные вероятности P(A|B) следующим образом:
Множества .
Множество
- это совокупность некоторых элементов. Если элемент х входит в множество А, это записывается как x О A. Соотношения A1 Н A2 или A2
К A1 означает, что A1 содержится во множестве A2 (каждый элемент х множества A1 входит в множество A2;
A1 является подмножеством A2).
.Счетно-гильбертово пространство Х называется ядерным , если для любого р найдется такое q и такой ядерный оператор А в гильбертовом пространстве Х со скалярным произведением (х1,x2)=(х1,х2)q, что (х1,x2)p=(Ax1,x2)q. Действительное число M является
верхней границей
или
нижней границей
множества Sy
действительных чисел y, если для всех y
О Sy
соответственно y ё M или yЁ M. Множество действительных или комплексных чисел
ограничено
(имеет абсолютную границу), если верхнюю границу имеет множество абсолютных величин этих чисел; в противном случае множество не ограничено. Каждое непустое
множество Sy
действительных чисел y, имеющее верхнюю границу, имеет
точную верхнюю границу
(наименьшую верхнюю границу) sup y, а каждое непустое множество действительных чисел y, имеющее нижнюю границу, имеет
точную нижнюю
границу
(наибольшую нижнюю границу) inf y. Если множество Sy
конечно, то его точная верхняя граница sup y необходимо равна наибольшему значению (максимуму) max y, фактически принимаемому числом y в Sy
, а точная нижняя граница inf y равна минимуму min y.
Компакт.
Система множеств G называется
центрированной
, если пересечение конечного числа любых множеств из G не пусто. Замкнутое множество A Н X называется
компактом
, если всякая центрированная система G его замкнутых подмножеств F имеет непустое пересечение: Гауссовы случайные процессы . Действительная случайная величина x называется гауссовой, если ее характеристическая функция j =j (u) имеет вид
Марковские случайные процессы . Случайный процесс x =x(t) на множестве T действительной прямой в фазовом пространстве ( E,B ) называется марковским, если условные вероятности P(A| U (-╔,s) событий AО U (t,╔ ) относительно s-алгебры U (-╔,s) таковы, что при s ёt с вероятностью 1 ,здесь U (u,v) означает s-алгебру порождаемую всевозможными событиями вида { x(t) О B}, t О[u,v]З T, BО B . Если параметр t интерпретировать как время, то описанное марковское свойство случайного процесса x =x (t) состоит в том, что поведение процесса после момента t при фиксированном состоянии x= x (t) не зависит от поведения процесса до момента t. Для любых событий А О U (-╔,t1) и A2 О U (t1, ╔) и при любом t О T t1 ёtё t2 с вероятностью 1 P(A1A2|x (t)) = P(A1|x (t)) P(A2|x(t)). Цепи Маркова . Пусть x (t) - состояние системы в момент времени t, и пусть соблюдается следующая закономерность: если в данный момент времени s система находится в фазовом состоянии i, то в последующий момент времени t система будет находиться в состоянии j с некоторой вероятностью pij(s,t) независимо от поведения системы до указанного момента s. Описывающий поведение системы процесс x (t) называется цепью Маркова. Вероятности pij(s,t) = p{x (t)=j|x (s)=i} (i,j = 1, 2, .) называются переходными вероятностями марковской цепи x (t).Марковская цепь x (t) называется однородной , если переходные вероятности pij(s,t) зависят лишь от разности t-s: pij(s,t) = pij(s-t) (i,j=1,2,.) Финальные вероятности . Пусть состояния однородной марковской цепи x (t) образует один замкнутый положительный непериодический класс. Тогда для любого состояния j существует предел
(j=1, 2,.), один и тот же при всех исходных состояниях i=1,2,.. Предельные значения P1, P2,. представляют собой распределение вероятностей: pj есть финальная вероятность находиться в состоянии j; при этом Pj=
(j=1,2,...),где Qj - среднее время возвращения в состояние j в дискретные моменты t = 0, 1, 2, . . Коэффициент эргодичности . Пусть x =x (t) - случайный марковский процесс в фазовом пространстве (E, B ) с переходной функцией P(s,x,t,B). С вероятностью 1 имеет место равенство
b
(s,t) =
Величина k(s,t) = 1 -
называется коэффициентом эргодичности марковского процесса x =x (t). Переходная функция. Функция P(s,x,t,B) переменных s, tО T, s ё t и xО E, bО b называется переходной функцией марковского случайного процесса x =x (t) на множестве T в фазовом пространстве (E, B ), если эта функция при фиксированных s, tО T и xО E представляет собой распределение вероятностей на s -алгебре b и при фиксированных s, tО T и BО b является измеримой функцией от x О E.Стационарные случайные процессы . Стационарный действительный или комплексный случайный процесс x =x (t), рассматриваемый как функция параметра t со значениями в гильбертовом пространстве L2(W) всех действительных или комплексных случайных величин h =h (w), M|h |2<╔ (со скалярным произведением(h 1, h 2)= M h 1 h 2), может быть представлен в виде
Белый шум. Простейшим по структуре стационарным процессом с дискретным временем является процесс z =z (t) с некоррелированными значениями:Mz(t)=0, M|z(t)|2=1, В случае непрерывного времени t аналогом такого процесса является так называемый "белый шум" - обобщенный стационарный процесс z = б u, z с вида
Mz (D )=0, M|z (D )|2 =t-s при D =(s,t), Mz (D 1) z (D 2)=0 для любых непересекающихся D 1 и D 2. Стационарный процесс x=
x(t), Mx(t)=0, называется линейно-регулярным, если
Стационарный процесс x =x(t) линейно-регулярен тогда и только тогда, когда он получается некоторым физически осуществимым линейным преобразованием из процесса z = z(t) с некоррелированными значениями - в случае дискретного t:
x(t) =
и из процесса z =б u, z с "белого шума" - в случае непрерывного t:
x(t) =
Регулярность . Реальные стационарные процессы часто возникают в результате некоторого случайного стационарного возмущения Z = z (t) типа "белого шума". Процесс z = z(t) подвергается некоторому линейному преобразованию и превращается в стационарный процесс x =x(t). Спектральная плотность f= f(l) такого процесса в диапазоне -p ё l ё p для целочисленного времени и -╔ <l <╔ для непрерывного времени t не может обращаться тождественно в нуль ни на каком интервале: в противном случае стационарный процесс x (t) будет сингулярным, что означает возможность его восстановления лишь на полуоси -╔ ,t0. Процессы, спектр которых практически сосредоточен в полосе частот -W< l <W, не обладают свойствами сингулярных процессов. С энергетической точки зрения эти процессы имеют ограниченный спектр. Составляющие их гармонические колебания вида Ф(dl )eilt с частотами вне интервала (-W,W) имеют весьма малые энергии, но они существенно влияют на линейный прогноз значений x (t+t) на основе x (s) на временной полуоси sёt. Линейные устройства, используемые при решении конкретных задач, должны иметь вполне определенную постоянную времени T (определяет длительность переходных процессов). Это означает, что весовая функция h=h(t) рассматриваемого линейного устройства, связанная с соответствующей передаточной функцией Y =Y(p) равенством Линейное устройство, отвечающее поставленным требованиям, должно иметь такую передаточную функцию Y=Y(p), чтобы соответствующая спектральная характеристика Где Закон больших чисел . Пусть x 1,., x n - независимые случайные величины, имеющие одно и то же распределение вероятностей, в частности одни и те же математические ожидания a = M x k и дисперсииs 2=Dx k, k=1,.,n. Каковы бы ни были e >0 и d >0, при достаточно большом n арифметическое среднее
(таким образом
) с вероятностью, не меньшей 1-d, будет отличаться от математического ожидания a лишь не более чем на
Распределение Эрланга Рассмотрим систему, которая способна обслуживать m запросов одновременно. Предположим, что имеется m линий и очередной запрос поступает на одну из них, если хотя бы одна из них свободна. В противном случае поступивший запрос будет отвергнут. Поток запросов считается пуассоновским с параметром l 0 , а время обслуживания запроса (в каждом из каналов) распределено по показательному закону с параметром l , причем запросы обслуживаются независимо друг от друга. Рассмотрим состояния E0, E1,.,Em, где Ek означает, что занято k линий. В частности E0 означает, что система свободна, а Em - система полностью занята. Переход из одного состояния в другое представляет собой марковский процесс, для которого плотности перехода можно описать как:
При t ╝ ╔ переходные вероятности pij(t) экспоненциально стремятся к своим окончательным значениям Pj, j=0,.,m. Окончательные вероятности Pj могут быть найдены из системы: -l 0P0+lP1=0 l 0Pk-1 - (l 0+kl)Pk + (k+1)lPk+1 =0 (1ё k<m) l 0pm-1+ml Pm=0 решение которой имеет вид:
Эти выражения для вероятностей называются формулами (распределением) Эрланга. |
|||||
|
Previous:
10.19 Символьный набор HTML
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.21 Элементы теории графов
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Графы представляют собой наиболее абстрактную структуру, с которой приходится сталкиваться в теории ЭВМ (computer science). Графы используются для описания алгоритмов автоматического проектирования, в диаграммах машины конечных состояний, при решении задач маршрутизации потоков и т.д. Любая система, предполагающая наличие дискретных состояний или наличие узлов и переходов между ними может быть описана графом. Соединения между узлами графа называются ребрами. Если узлы графа не нумерованы, то ребра являются неориентированными. У графа с нумерованными узлами ребра ориентированы. Ребрам могут быть присвоены определенные веса или метки. На рис. 10.21.1А и 10.21.1Б приведены примеры обычного и ориентированного графа.
Рис. 10.21.1 Примеры неориентированного и ориентированного графов (А и Б) Введем более строгие определения. Граф представляет собой структуру П = <V,E>, в которой V представляет собой конечный набор узлов, а EН VЕV представляет собой конечный набор ребер. Для ориентированного графа E Н V╢ V - конечный набор ориентированных ребер. Ребром может быть прямая или кривая линия. Ребра не могут иметь общих точек кроме вершин (узлов) графа. Замкнутая кривая в E может иметь только одну точку из множества V, а каждая незамкнутая кривая в E имеет ровно две точки множества V. Если V и E конечные множества, то и граф им соответствующий называется конечным . Граф называется вырожденным , если он не имеет ребер. Параллельными ребрами графа называются такие, которые имеют общие узлы начала и конца. Графы отображаются на плоскости набором точек и соединяющих их линий или векторов. При этом грани могут отображаться и кривыми линиями, а их длина не играет никакой роли. Граф G называется плоским , если его можно отобразить в плоскости без пересечения его граней. Очертанием графа (face) считается любая топологически связанная область, ограниченная ребрами графа. Неориентированный граф G = <V,E> называется связанным , если для любых двух узлов x,y О V существует последовательность ребер из набора E, соединяющий x и y. Граф G связан тогда и только тогда, когда множество его вершин нельзя разбить на два непустых подмножества V1 и V2 так, чтобы обе граничные точки каждого ребра находились в одном и том же подмножестве. Граф G называется k-связным (k Ё 1), если не существует набора из k-1 или меньшего числа узлов V`Н V, такого, что удаление всех узлов V` и сопряженных с ними ребер, сделают граф G несвязанным. Теорема Менгера: граф G является k-связанным тогда и только тогда, когда любые два различные узла x и y графа G соединены по крайне мере k путями, не содержащими общих узлов. k-связанные графы представляют особый интерес для сетевых приложений. Определенную проблему составляет автоматическое отображение графа на экране или бумаге. Кроме того, для многих приложений (например, CAD) все узлы графа должны совпадать с узлами технологической сетки. Возникают и другие ограничения, например необходимость размещения всех узлов на прямой линии. В этом случае ребра графа могут представлять собой кривые линии, дуги или ломаные линии, состоящие из отрезков прямых. Смотри, например, рисунок 10.21.2.
Рис. 10.21.2 Граф слева безусловно легче воспринять, чем граф справа, хотя они эквивалентны. Существует ряд алгоритмов, позволяющих определить, является ли граф плоским. Так граф на рис. 10.21.3 на первый взгляд не является плоским (ведь его ребра пересекаются в нескольких местах). Но он может быть перерисован (см. рис. 10.21.3а), после чего его плоскостность уже не подвергается сомнению.
Матрица смежности графа G
Рис. 10.21.3. Граф и его матрица смежности
Рис. 10.21.3а. Преобразование графа с рис 3 Матрица смежности, характеризующая этот граф, эквивалентна приведенной на рис. 10.21.3, а сами графы изоморфны . Для представления графа может использоваться Булева функция S(x,y), для которой S(i,j)=1 тогда и только тогда, когда (i,j)О E. S(i,j) обозначает ребро графа, соединяющее узлы i и j. Одной из возможностей реализации s является использование матрицы смежности А графа g. А - двухмерная матрица. Для описания графа с помощью матрицы смежности A(i,j), где (i,j)О E, необходимо пронумеровать узлы графа. Элементы матрицы могут принимать значения 0 или 1. Так как представленный на рисунке граф не имеет ребер исходящих и завершающихся в одном и том же узле (нет петель), диагональные элементы матрицы равны нулю. Единицы присутствуют в позициях, которые соответствуют парам узлов, соединенных ребрами, например, 1-3, 1-4 или 5-2 и 5-3. Число ребер, исходящих из вершины (петля учитывается дважды), называется степенью вершины d(v). В конечном графе число вершин с нечетной степенью всегда четно. Другой способ представления графа обеспечивает функция, которая выдает списки узлов, с которыми данный узел связан непосредственно. Для графа, отображенного на рис. 10.21.4, такое описание можно представить в виде структуры (таблица 10.21.1). В колонке s представлены номера узлов, далее в строке таблицы следует список соседних узлов. По этой причине число колонок в каждой из строк различно.
Рис. 10.21.4 Таблица 10.21.1.
Нули и единицы в матрице смежности могут быть заменены целыми числами, характеризующими путь из точки i в точку j (например, метрика маршрута телекоммуникационной сети). Такая матрица называется матрицей оценки . Граф называется обыкновенным , если он не содержит петель и параллельных ребер. Граф называется полным , если любые две вершины являются смежными. Если для всех вершин d(v) = k, то граф называется однородным графом степени k или k-однородным. Граф на рис. 10.21.5 является полным и 3-однородным.
Рис. 10.21.5. Конечная последовательность ребер графа e 1, e2,.,en называется маршрутом длины n. Маршрут называется замкнутым, если вершины начала и конца маршрута совпадают. Если ребра, образующие маршрут различны, то такой маршрут называется цепью . Граф называется деревом , если он связан и не имеет циклов. Граф является деревом тогда и только тогда, когда каждая пара различных вершин соединяется одной и только одной цепью. Каждое дерево с n вершинами имеет ровно n-1 ребро. Удаление любого ребра в дереве делает его несвязным. По этой причине дерево можно считать минимальным связным графом. Если все вершины графа G принадлежат дереву Т, то считается, что дерево покрывает граф G. Граф, не имеющий циклов и состоящий из k компонент, называется лесом из k деревьев. Лес из k деревьев, содержащий n вершин имеет в точности n-k ребер. Пусть G=(v,e) связный граф и FМ E подмножество его ребер. При этом F называется разделяющим подмножеством тогда и только тогда, когда подграф G'=(V, E-F) несвязан. E-F обозначает множество ребер, которое принадлежит Е, но не принадлежит F. Если узлы графа могут быть соединены несколькими путями, сеть, описываемая таким графом, обладает повышенной надежностью. Рассмотрим задачу выбора оптимального дерева маршрутов, лишенного циклов, в такой сети (см. рис. 10.21.6). Алгоритм используется в схеме "расширяющееся дерево" для локальных сетей со сложной топологией. Алгоритм преобразует многосвязный граф в плоский без замкнутых структур.
Рис. 10.21.6. В качестве начального выбираем узел 1. Матрица оценки формируется поэтапно (А-E). На этапе А выбирается узел 5, так как к нему ведет ребро с метрикой 1. Здесь становятся доступными ребра, ведущие к узлам 2, 4, 6 и 7. Ребро 1-5 из рассмотрения устраняется. На следующем этапе выбирается узел 7, к нему от узла 5 ведет ребро с метрикой 1. Здесь в рассмотрение включаются ребра 7-4 и 7-8. Следующим выбранным узлом становится 4 и включается в перечень ребро 4-2. Далее рассматривается узел 6 и ребра 6-8 и 6-3.
В результате граф приобретает вид, показанный на рисунке 10.21.7.
Рис. 10.21.7. Рассмотренный алгоритм сходен с алгоритмом Дикстры, используемым для поиска наилучшего пути во внутреннем протоколе маршрутизации ospf. Выбранный метод аналитического представления графа достаточно прост, но требует для графа с N узлами N2 ячеек памяти (бит). Впрочем, для неориентированного графа матрица является симметричной и для ее хранения в памяти ЭВМ достаточно N(N-1)/2 ячеек. Это справедливо и для ориентированных графов без петель. Петлей называется ребро графа, которое начинается и завершается в одном и том же узле (рис. 10.21.8).
Рис. 10.21.8. Справедливо следующее утверждение. Узлы i,j соединены путем длиной k тогда и только тогда, когда Ak(i,j)=1. Надо сказать, что графы являются весьма удобным средством описания и оптимизации алгоритмов вычисления. В качестве примера рассмотрим вычисление квадратного полинома ax2+bx+c по схеме Горнера (рис. 10.21.9).
Рис. 10.21.9. Граф вычисления квадратного полинома по схеме Горнера. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.20 Справочные данные по математике
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||
|
10.23 Модель машины конечных состояний
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||
|
Базовой концепцией построения многих современных протоколов является машина конечных состояний (FSM - Finite State Machine). При этом подходе каждый протокол характеризуется машиной, которая в любой момент времени находится в каком-то конкретном состоянии. Каждому состоянию соответствует определнный набор значений системных переменных. Такой подход требует определенного уровня абстрагирования. Например, для того чтобы ЭВМ перешла из состояния ожидания в состояние, когда получено некоторое сообщение, реализуется достаточно много промежуточных операций (проверка качества сигнала, контроль целостности сообщения, проверка отсутствия переполнения буфера и многие другие). Все эти промежуточные операции и состояния считаются переходными и в данной модели не рассматриваются. Таким образом, состояние протокольной машины полностью определяется набором значений определенных системных переменных. Так состояние протокольной машины канала определяется состояниями клиента и сервера. Если состояние как отправителя так и получателя характеризуются двумя битами, то состояние системы будет характеризоваться 16 состояниями. Из любого состояния может быть нуль или более возможных переходов в другое состояние. Переход из одного состояние в другое происходит при наступлении определенного события (например, полчение сообщения, прерывание, таймаут и т.д.). Машина состояний протокола может быть охарактеризована с помощью ориентированного графа, в котором число узлов равно числу конечных состояний системы, а число ребер всей совокупности возможных переходов из одного состояния в другое. Одно из состояний выбирается в качестве исходного. Из этого состояния система может попасть в некоторые (все) другие состояния с помощью последовательности переходов. Данный подход позволяет часто выявить слабые места протокола (например, возможности "повисаний"). Машина конечных состояний протокола характеризуется следующими наборами переменных
В начальный момент все процессы находятся в исходных состояниях. Дальнейшие переходы из состояния в состояние определяются событиями, происходящими в системе. Каждое событие может вызвать переход в новое состояние какого-то процесса или канала. Если в результате анализа графа машины конечных состояний выясняется, что в случае прихода кадра некоторого типа, не определено, в какое состояние должна перейти машина, это свидетельствует о наличии ошибки в протоколе. Если обнаруживается одно или несколько состояний, из которых нет перехода куда-либо во вне (тупик), такое положение также свидетельствует об ошибке. В качестве примера машины конечных состояний можно рассмотреть граф протокола TCP. |
||||||||
|
Previous:
10.22 Имена временных зон
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.2 Коды протоколов в Ethernet II
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.1 Рекомендации CCITT по телекоммуникациям
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.3 Стандартные мультикастинг-адреса Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.2 Коды протоколов в Ethernet II
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.5 Таблица операций службы каталогов Netware
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.4 Таблица операций и субопераций NCP
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
||||||||||||||||||||
|
10.22 Имена временных зон
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||
|
||||||||||||||||||||
|
Previous:
10.21 Элементы теории графов
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
|
10.24 Сети Петри
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Протоколы можно описывать не только с помощью модели машины конечных состояний. Альтернативой можно считать сети Петри (смотри, также книгу "Сети Петри", Котов В.Е., Москва, "Наука", ГРФМЛ, 1984 откуда взяты некоторые примеры и фрагменты данной статьи). Модель сети Петри является принципиально асинхронной и служит для отображения и анализа причинно-следственных связей в системе. Для привязки к определенным моментам времени тех или иных переходов в синхронных системах используются события. Переходы из состояния в состояния считаются "мгновенными". Если переход реально происходит через какие-то промежуточные состояния, а нам существенно учесть в модели эти обстоятельства, то вводятся соответствующие "подсобытия". Сеть Петри имеет четыре базовых элемента: позиции (places), переходы, дуги и метки (token). Позиция (место) - это состояние, в котором находится система или определенная ее часть. Смотри рис. 10.24.1.
Рис. 10.24.1. Сеть Петри с двумя позициями и двумя переходами. Цифрами 1 и 2 обозначены переходы, а буквами А и Б - позиции. Состояние системы формируется в результате реализации локальных операций, называемых условиями реализации событий. Условие имеет емкость:
Определенная комбинация условий может стимулировать определенное событие, которое вызовет в свою очередь изменение изменение условий. В сетях Петри события и условия отображаются абстрактными символами, называемыми переходами(вертикальными или горизонатальными полосками - "барьерами") и позициями (кружками). Условия-позиции и события-переходы связаны отношениями зависимости, которые отображаются с помощью ориентированных дуг. Позиции, из которых исходят дуги данного перехода, называются входными позициями. Позиции же, к которым ведут дуги данного перехода, называются выходными позициями. Выполнение условий отображается помещением соотвествтующего числа меток в соответствующую позицию. Если число меток велико (более 2-3), емкость условия может быть отображена числом. В исходный момент система находится в состоянии А, что отмечено на рис. 4.9. меткой в виде синего кружочка. Переходы обозначаются горизонтальными или вертикальными линиями. Каждый переход имеет нуль или более входных дуг, исходящих из позиций, и нуль или более исходящих дуг, направленных к выходным позициям. Переход разрешен, если имеется как минимум одна входая метка в каждой из его исходных позиций. Любой разрешенный переход может произойти (fire), удалив все входные метки и установив метки в выходных позициях, что отражает изменение условий (и емкостей). Если числа входных и выходных дуг отличаются, число меток не сохраняется. Если разрешено более одного перехода, может произойти любой из них. Причем один из осуществившихся переходов, может блокировать реализацию всех остальных переходов из данного набора. Формализм сетей Петри не предусматривает каких-либо механизмов преодоления подобных конфликтов. Переход осуществляется, если выполнены все условия реализации данного события. Если два или более переходов могут осуществиться (выполнены все условия) и они не имеют общих входных позиций, то из реализация некоррелирована и может происходить параллельно или в любой последовательности. Выбор перехода, вообще говоря, не определен. В отличии от модели машины конечных состояний здесь отсутствуют комбинированные состояния типа отправитель-канал-получатель, и переходы из состояния в состояние для каждого процесса или объекта рассматриваются независимо. Если условия ни для одного из переходов не реализованы, сеть переходит в заблокированное состояние. Аналитическое определение. Сеть Петри - набор N = (P, T, F, W, M0), где (P, T, F) - конечная сеть (множество Х = ЗuT конечно), а W: F→ N\ {O} (знак \ здесь означает разность множеств) и M0: P→N - две функции, называемые кратностью дуг и начальной пометкой. Первая ставит в соответствие каждой дуге число N>0 (кратность дуги). Если N>0, то при графическом
представлении сети число N выписывается рядом с короткой чертой, пересекающей дугу. Дуги с кратностью 1 не помечаются. Каждой позиции p Формально работа сети Петри описывается множеством последовательностей срабатываний и множеством реализуемых разметок позиций. Для сетей Петри существует удобная алгебраическая нотация. Каждому переходу ставится в соответствие правило грамматики. Каждое правило специфицирует входную и выходную позиции. Текущее состояние сети Петри характеризуется неупорядоченным набором позиций. Каждая позиция присутствует в этом наборе столько раз, сколько меток она имеет. |
|
Previous:
10.23 Модель машины конечных состояний
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
|
10.25 Интернет вчера, сегодня и завтра
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Если считать началом Интернет реализацию проекта ARPA-Net, то время его существования насчитывает более 31 года. Ведь в 1969 году был подготовлен документ RFC-1. Замечу, что протоколы Ethernet были сформированы лишь в 1973-79 годах. Интернет в РФ на 20 лет моложе. Динамику развития этой технологии можно проследить по темпу выпуска RFC (смотри рис. 1). В 2000 году ожидается не менее 250 публикаций.
Рис. 1. Число выпущенных документов RFC по годам. К 1979 году полностью сформировался пакет протоколов TCP/IP и их приложений, началось внедрение. К 1989 году выявились некоторые недостатки старых протоколов, возникла необходимость разработки новых. Рост числа публикаций в период 1989-99 в основном определяется разработками в области безопасности (TLS (RFC-2246, -2817), RADIUS (RFC-2058), а также RFC-2817, -2845, -2875 и многие др.), мультимедиа (MIME; RFC-1590, -2045, -2046, -2047, -2048, -2049) и специальных приложений (например, протокол IOTP). Рост числа узлов Интернет за этот же интервал времени (рис. 2) и количества WEB-серверов (рис. 3) также впечатляет.
Рис. 2. Рост числа узлов Интернет в 1989-99 годах
Рис. 3. Рост числа WEB-серверов в период 1994-2000 годы К числу новейших достижений Интернет следует отнести электронную торговлю (протоколы IOTP, SET, CyberCash и др.), IP-телефонию, мощные поисковые системы, электронную прессу и многое другое. IP-телефония уже сегодня существенно понизила тарифы на международные переговоры. Схема реализации IP-телефонной сети показана на рис. 4.
Рис. 4. Схема IP-телефонной сети На рисунке MVW-модуль (Multiflex Voice/WAN), включаемый в маршрутизатор, например, CISCO-3662, служит для связи с общедоступной телефонной сетью. Если сеть "А" размещена в Рио-де-Жанейро, а "В" в Москве, то любой клиент нижней сети сможет разговаривать с клиентом в Рио "бесплатно", а с клиентами телефонных сетей "А" и "B" по локальным тарифам. В левой части рисунка показаны телефонные аппараты, которые подключаются непосредственно к сегменту локальной сети. Такие приборы уже поступили в продажу. Грядет интеграция цифрового телевидения, телефонии (включая видео-телефонию) и Интернет, звуковые и видео письма уже реальность. Схема построения интерактивной сети цифрового кабельного телевидения показана на рис. 5.
Рис. 5. Схема реализации интерактивного цифрового телевидения Данная схема, реализованная в США и Канаде несколько лет назад, позволяет клиентам индивидуально заказывать программу телевидения на неделю вперед. Помимо этого в режиме меню можно получить данные о погоде, состоянии дорог, заказать билеты в театр или на самолет, а также вызвать на экран нужную статью какой-то газеты. Заказанные фильмы копятся в сервере буферизации и в требуемое время транслируются для клиента-заказчика. Существующая инфраструктура кабельного телевидения в США вполне пригодна для решения таких задач. В реальном масштабе времени здесь передаются только новости и спортивные соревнования. Помимо ставшей уже привычной электронной почты Интернет дал нам WEB-технологию, глобальные поисковые системы, электронные журналы, оперативный доступ к прессе, электронную торговлю и многое другое. Молодые люди объясняются в любви по электронной почте, в реальном масштабе времени общаются с людьми на других континентах, играют в шахматы с партнерами из других стран. Все шире внедряются IP- и ISDN видео конференции. Перспективы 1. IP-телефония. IP-телефония уже сегодня теснит традиционную не только потому, что может предложить новые разновидности услуг, но и за счет снижения тарифов. В настоящее время внедряются протоколы RTP, RTCP и RSVP, которые вместе с расширением полосы пропускания магистральных каналов уберут последние барьеры на пути внедрения этой технологии. Можно вполне ожидать дальнейшего снижения требований, налагаемых на полосы пропускания, для реализации одного разговора. Там, где достаточно донести до партнера текст сообщения (например, пейджерная связь), можно реализовать распознавание и преобразование сообщения в ASCII-последовательность, что снизит требования к полосе пропускания в сотни раз. Еще большего эффекта можно достичь, используя схему, показанную на рис. 6 (технологии для этого по большей части уже существуют, но схема пока не реализована).
Рис. 6. Схема возможного снижения требуемой полосы пропускания при передаче голоса Символьное отображение голоса приводит к потере индивидуальных особенностей говорящего и эмоциональной окраски его речи. Системы распознавания людей по голосу уже существуют. Индивидуальные особенности голоса вещь достаточно стабильная. Если произвести анализ голоса конкретного человека и параметризовать эти особенности, то их можно будет использовать в дальнейшем в течение длительного времени. Если набор этих параметров записать на телефонную магнитную карту, то этой картой не сможет воспользоваться никто другой. Передача этих данных принимающей стороне может производиться в процессе установления телефонного соединения. В принципе можно параметризовать и эмоциональную окраску речи говорящего, но в этом случае это нужно делать в реальном масштабе времени. Реализация предлагаемой схемы будет приводить к дополнительным задержкам, но при использовании быстродействующих процессоров эти задержки можно минимизировать. Снижение требуемой полосы пропускания вместе с повсеместным внедрением протоколов RTP и RSVP сделает беседу через Интернет общедоступной. 2. Электронные книги и сфера развлечений. Если индивидуальные особенности голоса и эмоциональная окраска факторизованы, появляется возможность сделать плейеры, которые будут воспроизводить текст голосом определенного актера. Это потребует разработки специального языка разметки текста (вроде HTML) с учетом требуемой эмоциональной окраски. В этом случае на одном CD можно записать целую библиотеку. Мало того, что появляется возможность заказывать программу телепередач на неделю вперед, получать различную справочную информацию, в принципе могут стать доступными многосюжетные фильмы, где сценарий адаптируется под вкус и желание зрителя (такие фильмы уже снимаются). Зритель может вмешиваться по ходу фильма и направлять линию сценария по одному из нескольких возможных путей. Сети Интернет открывают новые возможности для интерактивных сетевых развлечений. Ограничения здесь иногда возникают лишь из-за полосы пропускания каналов. Развитие технологии виртуальной реальности будет еще более разнообразить возможности сетевых развлечений.
Дистанционное обучение может решить проблему учебников и откроет новые возможности в дополнительном образовании, которое крайне важно при массовом перепрофилировании производств. В сочетании с технологией MBONE и IP-видеоконференциями это позволит сделать уроки высококлассных преподавателей доступными в общероссийском масштабе. Хорошие же учителя также редки, как и хорошие врачи. В отличие от телевизионных учебных программ здесь возможно задавание вопросов и получение на них ответов в процессе занятия.
Интернет - новое средство массовой информации. Здесь предстоит решить не только технические, финансовые, правовые, но и политические проблемы. Развитие Интернет впервые предоставляет возможность общения любого гражданина земли с любым, даже с тем, о существовании которого он и не подозревал (многие с этим познакомились через SPAM J). Это качественно меняет современную цивилизацию, создавая невиданные возможности и неведанные до сих пор угрозы. Темпы технического прогресса зависят от скорости накопления информации об окружающем нас мире и о нас самих. Одним из параметров, определяющих этот процесс, является задержка с момента получения информации (в результате измерения, исследования или обработки уже известных данных) и до получения ее заинтересованными лицами. Последние сто лет эта задержка оставалась почти постоянной. В науке время публикации статьи в журнале занимало до полугода (книги до года). В сфере общественной жизни (газеты) задержка составляла около суток. За последние годы сначала радио и телевидение сократило эту задержку в общественной сфере до часа-двух. Интернет сократил задержку с момента появления научных данных до их опубликования до нескольких часов (в реферируемых журналах до месяца), то есть более чем в 5 раз за десять лет. Это неизбежно скажется на темпах технического прогресса в сторону его существенного ускорения, причем в самое ближайшее время. Нерешенные пока проблемы:
Данный список выглядит коротким потому, что проблем всегда видно меньше, чем их есть на самом деле. Некоторые материалы по рассмотренным в данном сообщении проблемам можно найти на сервере http://book.itep.ru . В этом году в издательстве "Горячая линия - Телеком" должна выйти моя книга "Протоколы Интернет. Энциклопедия" объемом около 1100 страниц. Приложение Предложение по совершенствованию цифровой телефонии Современные системы цифровой телефонии (например, ISDN) предполагают выделение 32 кбит/с на каждый разговор. Если же перевести все, что говорит человек в символьное представление, то это будет эквивалентно потоку примерно в 64 бит/c (примерно такова же предельная скорость ввода данных с клавиатуры). Разрыв в требуемых пропускных способностях соответствует 5000. Понятно, что символьное представление не содержит индивидуальных особенностей голоса и эмоциональной окраски речи. Современные системы сжатия голосовой информации позволяют сократить требования к полосе пропускания до 7,5 кбит/с, но уже с некоторым ухудшением качества воспроизведения. Наилучшие современные системы (например, VOCODER) позволяют обходиться полосой в 1 кбит/c, при весьма серьезном ухудшении качества (голос неузнаваем и напоминает речь робота). Любое сокращение требования к полосе при сохранении качества передачи голоса крайне желательно. Современная телефония - это высокодоходная отрасль, и любая фирма готова будет заплатить за такого рода разработку, так как это решит конкурентное противостояние в ее пользу. Рост пропускной способности каналов не решает проблемы, так как все телефонные компании используют эту сеть, но преуспеет та, которая сможет предложить более низкие тарифы. В США планируется выпуск автомобилей с бортовым компьютером, управляемым голосом водителя (руки у него заняты). Таким образом, проблема преобразования голоса в последовательность символов можно считать практически решенной. Еще большего эффекта можно достичь, используя схему, показанную на рис. 6 (технологии для этого уже существуют, но схема пока не реализована). Символьное отображение голоса приводит к потере индивидуальных особенностей говорящего и эмоциональной окраски его речи. Системы распознавания людей по голосу уже существуют (например, в системах идентификации). Индивидуальные особенности голоса вещь достаточно стабильная. Если произвести анализ голоса конкретного человека и параметризовать эти особенности, то их можно будет использовать в дальнейшем в течение длительного времени. Если набор этих параметров записать на телефонную магнитную карту, то этой картой не сможет воспользоваться никто другой. Передача этих данных принимающей стороне может производиться в процессе установления телефонного соединения. В принципе можно параметризовать и эмоциональную окраску речи говорящего, но в этом случае это нужно делать в реальном масштабе времени. Реализация предлагаемой схемы будет приводить к дополнительным задержкам, но при использовании быстродействующих процессоров, или аппаратных средств эти задержки можно минимизировать. На пути реализации проекта надо решить проблему синтеза речи с учетом индивидуальных и эмоциональных особенностей голоса говорящего. Голосовые синтезаторы существуют, но все они крайне не совершенны. Понятно, что все перечисленные проблемы не будут решены сразу. Но вполне реально внедрять систему поэтапно, предоставляя клиенту в этом случае выбор: высокое качество и высокий тариф или низкий тариф при пониженном качестве передачи голоса. Возможные приложения при частичном или полном успехе проекта:
Грубые оценки показывают, что высокого качества передачи голоса методом параметризации можно достичь при полосе 1кбит/c. |
|
Previous:
10.24 Сети Петри
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.26 Таблица цветов, их имен и кодов
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Надеюсь, эта таблица окажется полезной для WEB-дизайнеров. Пожалуйста, не пытайтесь печатать эти страницы, ничего хорошего не получится! Цвета отображены с использованием атрибута bgcolor. Ю.А.С.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.25 Интернет вчера, сегодня и завтра
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
|
10.27 Законы Мерфи для программистов
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Интернет - это система сотрудничающих программ, а программы, как известно, пишутcя программистами. Некоторые мои студенты, правда, пытаются оспаривать этот факт и считают, что стоит как следует поискать в сети, и найдешь, то что нужно. Я сам являюсь программистом и мне близки эти проблемы. Предлагаю вашему вниманию мой перевод избранных законов Мерфи для программистов. Полный "свод законов" можно найти на сайте Законы Мерфи
|
|
Previous:
10.26 Таблица цветов, их имен и кодов
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10 Приложения
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
9 Литература
UP:
9 Литература
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.7 Типы субвекторов кадров управления доступом
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
10.6 Таблица типов кадров управления доступом для сети Token Ring
UP:
10.1 Рекомендации CCITT по телекоммуникациям
|
|
|
|
11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Этот сервер официально зарегистрирован на Rambler лишь в марте 2002 года, но существует он уже с
конца 1999 года. Отклики интересны, прежде всего, тем, что они написаны по
инициативе отправителя. Я полагаю, что многие из читателей время от времени
просматривают самые разные сайты в Интернет. Но вряд ли многие пишут на них
отклики...
From
: Andrey Cherezov andrey@cherezov.koenig.su
Date
: Sat, 27 Mar 1999 20:38:37
Date
: Mon, 6 Mar 2000 03:56:49
Date
: Thu, 1 Jun 2000 13:47:11
Date
: Wed, 14 Jun 2000 16:25:45
Date
: Wed, 12 Jul 2000 16:45:27
Date
: Fri, 4 Aug 2000 15:32:33
Date
: Tue, 15 Aug 2000 05:16:31
Date
: Thu, 31 Aug 2000 12:49:28
Date
: Thu, 31 Aug 2000 13:48:14
Date
: Mon, 04 Sep 2000 10:59:47
Date
: Mon, 4 Sep 2000 18:34:03
From
: "Lex"
<3694_KAN@nw.ie.tasur.edu.ru>
Date
: Wed, 01 Nov 2000 11:53:59
Date
: Mon, 18 Dec 2000 00:49:29
Здравствуйте,
Date
: Mon, 05 Feb 2001 16:44:31
Thu, 15
Feb 2001 22:31:43
Date
: Thu, 22 Feb 2001 17:40:26
Date
: Mon, 12 Mar 2001 18:25:34
Date
: Wed, 28 Mar 2001 14:52:42 +0400
From:
"Digitman" <digitman@dax.ru>
Date
: Mon, 9 Apr 2001 13:41:42
From
: "Shefanovski
Dennis" <shefanovski@infosec.ru> Это единственный негативный отклик. Именно по этой причине позволю себе краткий комментарий. Во-первых у меня давно устойчивая аллергия на машины конечных состояний. Во-вторых, с моей точки зрения нужно быть большим педантом, чтобы диалоговый алгоритм описывать с помощью формализма FSM. Скажем, протокол TCP, еще куда ни шло, а SSL, эту уж действительно чересчур. В-третьих, то, что помещено на сервере, взято было со страницы компании NetScape. Но, признаю, нет предела совершенству, и я не хотел бы утверждать, что создал образец для подражания. Интернет прекрасен тем, что если вы знаете как что-то сделать лучше, - сделайте это и дайте другим воспользоваться.
Date
: Fri, 20 Apr 2001 16:46:44
Date
: Wed, 16 May 2001 04:04:29
Date
: Sat, 2 Jun 2001 15:38:00
Date
: Mon, 11 Jun 2001 10:54:20
From
: "Alexandr
Ivanov" <ivanov@kons.ru>
Date
: Wed, 27 Jun 2001 10:26:15
Date
: Tue, 03 Jul 2001 19:05:35>
Date:
Mon, 9 Jul 2001 17:40:10 Уважаемый господин Семенов Ю.А. Должен Вам сообщить о некоторой неточности, которая присутствует в перечислении компаний, работающих в области телекоммуникаций. ( сайт http://book.itep.ru/1/intro1.htm раздел 10 ). Компаний Wandel Goltermann и Wavetek в настоящее время не существует, т к в 1998 году они путем слияния были преобразованы в корпорацию Wavetek Wandel Goltermann с соответствующим сайтом в Интернете www.wwgsolutions.com . Однако это не последнее преобразование фирмы. В 2000 году произошло следующее слияние компаний WWG и американской ТТС. В результате образованная компания получила название ACTERNA. Именно под этим названием компания и работает в настоящее время. Сайт в Интернете называется - www.acterna.com (или российский сайт - www.acterna.ru )
From: "spartak@nojabrsk.ru"
Date:
Wed, 29 May 2002 13:03:21 From: "Eugene Rybakov" <rybakov@bhv.ru> From: "AdminAtlas" <kisasoft@atlas-nsk.ru> From: <anatoly@podgoretsky.com> Я веду ряд проектов электронной библиотеки, в частности и проект Интернет.
Ваша книга "Telecommunication technologies - телекоммуникационные
технологии" была бы ценным приобретением для данного проекта, естественно,
что без вашего соглаисия я не могу ее разместить на своем сайте
http://www.podgoretsky.com/internet.html/.
Проект абсолютно не коммерческий.
Если вы дадите свое согласие, то я буду очень благодарен. From: <safonov@tih.ru> From: <worker@smtn.stavropol.ru > statel.stavropol.ru (statel.stavropol.ru [212.96.96.1]) Я являюсь администратором сервера зеркал http://mirrors.smtn.stavropol.ru , целью которого является развлечение и образование "подрастающего поколения", поскольку сервер расположен в зоне городской Интранет-сети, доступ к которой в пределах города Ставрополя по коммутируемой линии дешевле доступа к Интернет в 2-3 раза, что позволяет пользоваться услугами сети молодежи и людям с невысокими доходами. Блуждая по бескрайним просторам Интернет я наткнулся на Ваш информационный ресурс http://book.itep.ru, который показался мне очень полезным для целей образования. В свете вышесказанного у меня к Вам вопрос: не рассматривали ли Вы возможность зеркалирования сайта (с учетом наличия скриптов контроля знаний) и как Вы отнесетесь к размещению зеркала сайта на нашем сервере? С уважением!Лещенко Владимир Николаевич |
|
Previous:
10.27 Законы Мерфи для программистов
UP:
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
|
|
|
|
2.10 Статистическая теория каналов связи
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Данная статья имеет целью познакомить с терминологией и математическими основами статистической теории передачи данных. Именно на этой математической основе зиждятся приведенные выше теоремы Шеннона и Найквиста. Статья является компиляцией из нескольких источников (Ю.В.Прохоров, Ю.А.Розанов "Теория вероятностей. Основные понятия, предельные теоремы, случайные процессы" Наука, М. 1967; Л.Ф. Куликовский, В.В.Мотов, "Теоретические основы информационных процессов", Высшая школа, 1987; Р. Галлагер "Теория информации и надежная связь" Советское радио, 1974 и др.). Материалы, предлагаемые здесь не могут считаться исчерпывающими и призваны быть поводом для более углубленного изучения по существующим монографиям. Канал связи предназначен для транспортировки сообщений. Математическая модель канала связи описывается некоторой совокупностью Х 1 элементов х1 (X1 = {x11, x12,, .x1j }), называемых сигналами на входе канала, совокупностью Х2 элементов х 2 (x2 = {x21, x22,, .x2k}), называемых выходными сигналами, и условными распределениями вероятностей p2=p2(a2 |x1) в пространстве x2 выходных сигналов x2 . Если посланный сигнал (сигнал на входе) есть х1 , то с вероятностью P2=P2(A2|x1 ) на выходе канала будет принят сигнал х2 из некоторого множества A2 М Х2 (распределения задают вероятности того или иного искажения посланного сигнала х1 ). Совокупность всех возможных сообщений обозначим символом x0. Предполагается, что каждое из сообщений x0 О X0 может поступать с определенной вероятностью. То есть, в пространстве X0 имеется определенное распределение вероятностей P0=P0(A0 ). Сообщения х0 не могут быть переданы по каналу связи непосредственно, для их пересылки используются сигналы x1 О X1 . Кодирование сообщений х0 в сигналы х1 описывается при помощи условного распределения вероятностей P1=P1(A1 |x0). Если поступает сообщение х0, то с вероятностью P1=P1(A1|x0) будет послан один из сигналов х1 , входящих в множество A1 М Х1 (условные распределения P1(A1|x0) учитывают возможные искажения при кодировании сообщений). Аналогичным образом описывается декодирование принимаемых сигналов х2 в сообщения x3 . Оно задается условным распределением вероятностей P3=P3(A3|x2) на пространстве Х3 сообщений х3 , принимаемых на выходе канала связи. На вход канала связи поступает случайное сообщение x 0 с заданным распределением вероятностей P0=P0(A0 ). При его поступлении передается сигнал x 1, распределение вероятностей которого задается правилом кодирования P1=P1(A1|x0): P{x 2 О A2|x 0, x 1} = P2(A2|x 1) Принятый сигнал x 2 декодируется, в результате чего получается сообщение x 3: P{x 3 О A3|x 0, x 1, x 2} = P3(A3| x 2) Последовательность x 0 ╝ x 1 ╝ x 2 ╝ x 3 является марковской. При любых правилах кодирования и декодирования описанного типа имеет место неравенство: I(x 0, x 3) ё I(x 1, x 2), где I( x 0, x 3) - количество информации о x 0 в принятом сообщении x 3, I(x 1, x 2) - количество информации о x 1 в принятом сигнале x 2. Предположим, что распределение вероятности входного сигнала x 1 не может быть произвольным и ограничено определенными требованиями, например, оно должно принадлежать классу W. Величина C = sup I(( x 1 , x 2) , где верхняя грань берется по всем возможным распределениям P1 О W, называется емкостью канала и характеризует максимальное количество информации, которое может быть передано по данному каналу связи (теорема Шеннона). Предположим далее, что передача сообщений x 0 ╝ x 3 должна удовлетворять определенным требованиям точности, например, совместное распределение вероятностей P x0 x1 передаваемого и принимаемого сообщений x 0 и x 3 должно принадлежать некоторому классу V. Величина H= inf I( x 0 x 3), где нижняя грань берется по всем возможным распределениям P x0 x3 О V, характеризует минимальное количество информации, которое должно заключать в себе принимаемое сообщение x 3 о x 0, чтобы было выполнено условие точности передачи. Величина H называется энтропией источника сообщений. Если возможна передача x 0 ╝ x 1 ╝ x 2 ╝ x 3 с соблюдением требований V и W, то есть существуют соответствующие способы кодирования и декодирования (существуют условные распределения P1, P2 и P3), то H ё С. Для выполнения этого неравенства передача является возможной, т.е. возможна передача последовательно поступающих сообщений
Предположим, что совокупность Х0 всех возможных сообщений х0 является дискретной (имеется не более чем счетное число различных сообщений x0 , поступающих с соответствующими вероятностями P0(x0), x0 О X0 ) и условие точности передачи v состоит в том, что принимаемое сообщение x 3 должно просто совпадать с переданным сообщением x 3 = x 0 с вероятностью 1. Тогда
Предположим далее, что имеется лишь конечное число N различных входных сигналов х1 и нет никаких ограничений на вероятности P{ x 1 = x1}, x1 О X1. Кроме того, предположим, что передаваемые сигналы принимаются без искажений, то есть с вероятностью 1 x 2= x 1 . Тогда емкость канала выражается формулой C = log 2N, т.е. передаваемое количество информации I( x 1, x 2 ) будет максимальным в том случае, когда сигналы x1 О X1 равновероятны. Если сообщения
Пусть H<C, положим также d=(1/2)(C-H).
Согласно закону больших чисел, примененному к последовательности независимых и одинаково
распределенных случайных величин с математическим ожиданием P{-H-d ё (1/n)logP( x 0n) ё H+d } Ё 1-e, где
Mn ё 2n(H+d ) Ко второму классу
Каждую группу высоковероятных сообщений х0n можно в принципе передать, закодировав ее соответствующей комбинацией сигналов
При выполнении неравенства H < C оказывается возможной передача достаточно длинных сообщений
Количество информации I( x 0, x 3 ) для абстрактных случайных величин x 0 и x 3 со значениями в пространствах Х0 и Х3 может быть записано в виде: I( x 0, x 3) = Mi(x 0, x 3), где
I(
x
0,
x
3) ╝ ╔ и Рассмотренная выше последовательность (
x
0n,
x
3n), x
3n= x
0n
поступающих сообщений x 0n =(
и существуют информационно устойчивые последовательности пар ( x 0n, x 3n ) и ( x 1n, x2n ), для которых одновременно
то при весьма широких предположениях для любого наперед заданного e >0 существует такое n(e), что по всем каналам связи с параметром n Ё n(e) возможна передача с точностью до e. Как было указано выше, канал характеризуется условными распределениями З2, задающими вероятности тех или иных искажений посылаемого сигнала х1. Несколько изменим схему канала связи, считая, что имеется некоторое множество Z возможных состояний z канала связи, причем если канал находится в некотором состоянии z и на входе возникает сигнал x1, то независимо от других предшествующих обстоятельств канал переходит в другое состояние z1. Этот переход подвержен случайностям и описывается условными распределениями P(C|x1, z) (P(C|x1, z) - вероятность того, что новое состояние z1 будет входить в множество C М Z). При этом уже считается, что выходной сигнал х2 однозначно определяется состоянием канала z1, т.е. существует некоторая функция j = j (z) на пространстве z возможных состояний канала такая, что х2= j (z1). Эта более общая схема позволяет учитывать те изменения, которые в принципе могут возникать в канале по мере его работы. Рассмотрим стационарный режим работы канала связи. Предположим, что последовательно передаваемые сигналы Предположим, что поступающие на вход канала связи сообщения {x 0(n)}, n =., -1, 0, 1 ,., образуют случайную последовательность. Будем считать правило кодирования заданным, если при всех k, m и k 1,., km Ё k определены условные вероятности P{x 1(k1) О B1,., x 1 (km)О Bm|x 0(-╔ ,k)} Того, что при поступлении последовательности сообщений x 0(-╔ ,k) = ., x 0(k-1), x 0(k)на соответствующих местах будут переданы сигналы x 1(k1),., x 1(km), входящие в указанные множества B 1, ., Bm. Эти вероятности считаются стационарными в том смысле, что они не меняются при одновременной замене индексов k и k1,.,km на k+l и k1+l,.,km+l при любом целом l. Аналогичными вероятностями p{ x 3(k1) О D1,., x 3(km) О Dm|x 2(-╔ ,k)} задается правило декодирования. Определим величину H формулой H = inf I( x 0,x 3), где I(x 0, x 3) - скорость передачи информации о стационарной последовательности {x 0(n)} последовательностью {x 3(n)}, n = ., -1, 0, 1,. (эти последовательности предполагаются стационарно связанными), и нижняя грань берется по всем допустимым распределениям вероятностей, удовлетворяющим требованиям точности передачи {x 0(n)} ╝ { x 3(n)}. Неравенство H ё C является необходимым условием возможности передачи {x 0(n)} ╝ {x 1(n)} ╝ {x 2(n)} ╝ {x 3(n)}. Напомним, что каждое сообщение x 0(n) представляет собой некоторый элемент х0 из совокупности Х 0 . Можно интерпретировать Х0 как некоторый алфавит, состоящий из символов х0 . Предположим, что этот алфавит Х0 является конечным и требование точности передачи состоит в безошибочном воспроизведении передаваемых символов: P{x 3(k) = x 3(k)} =1 для любого целого k. Предположим также, что имеется лишь конечное число входных сигналов х1 и состояний канала z. Обозначим состояния канала целыми числами 1, 2, ., N, и пусть p(k, x1,j) - соответствующие вероятности перехода из состояния k в состояние j при входном сигнале x1: p(k,x1,j) = P{z (x+1) = j|z (n)=k, x 1(n+1)=x1}. Дополнительно предположим, что любые произведения вида p(k0,x1(1),k1)p(k1,x1(2),k2). p(kn-1,x1(n),kn) являются стохастическими матрицами, задающими эргодические цепи Маркова. Это условие будет выполнено, если, например, каждая из переходных матриц {p(k,x1,j)} имеет положительный коэффициент эргодичности. Тогда при выполнении неравенства H<C и соблюдении условия эргодичности стационарной последовательности {x 0(n)} сообщений на входе передача возможна с точностью до любого e >0, т.е. при соответствующих способах кодирования и декодирования принимаемая последовательность сообщений {x 3(n)} будет обладать тем свойством, что p{x 3(k) N x 0(k)} < e для любого целого k. Пусть x 1 = {x (t), t
О T1} и x 2= {x (t),
t О T2} - два семейства случайных величин, имеющих совместное гауссово распределение
вероятностей, и пусть H1 и H
2 - замкнутые линейные оболочки величин
x (t), t О T1, и x (t),
t О T2, в гильбертовом пространстве L2
(W). Обозначим буквами P1 и P2 операторы проектирования на пространства
H1 и H2 и положим P(1) = P1P2P1,
P(2) = P2P1P2. Количество информации
I(x
1,x 2) о семействе величин
x
1, содержащееся в семействе x
2,
конечно тогда и только тогда, когда один из операторов P(1) или P(2) представляет собой ядерный
оператор, т.е. последовательность l 1, l 2,.
его собственных значений (все они неотрицательны) удовлетворяет условию
В случае, когда x 1 и x 2 образованы конечным числом гауссовых величин: x 1={x (1),., x (m)}, x 2 = {x (m+1),., x (m+n)}, причем корреляционная матрица B общей совокупности x (1),., x (m+n) является невырожденной, количество информации I(x 1 , x 2) может быть выражено следующей формулой:
где B1 и B2 - корреляционные матрицы соответствующих совокупностей x 1 и x 2 . Гауссовы распределения обладают следующим экстремальным свойством. Для произвольных распределений вероятностей величин x 1 = {x (1), ., x (m)} и x 2 = {x (m+1), ., x (m+n)}с соответствующими корреляционными матрицами B1, B2 и B количество информации I(x 1 , x 2) удовлетворяет неравенству
Пусть x = (x 1,.,x n) и h = (h 1,.,h n) - векторные случайные величины в n-мерном евклидовом пространстве X и r(x,y) - некоторая неотрицательная функция, определяющая условие близости величин x и h, которое выражается следующим соотношением: Mr(x ,h ) ё e . Величину H=H e , определенную как H e = inf I(x, h), обычно называют e-энтропией случайной величины x (нижняя грань берется по всем случайным величинам h, удовлетворяющим указанному условию e-близости случайной величине x). Пусть r(x,y) = r(|x-y|) и существует производная r'(0), 0< r'(0)<╔. Тогда при e ╝ 0 имеет место асимптотическая формула, в которой логарифмы берутся по основанию e:
где g() - гамма функция и h(x) - дифференциальная энтропия случайной величины x:
(p
x
(x) - плотность распределения
вероятностей, удовлетворяющая весьма широким условиям, которые выполняются, например, если
плотность p
x
(x) ограничена и
h(x ) > -╔ ). Тогда
В частности, при a =2, b =1 имеет место асимптотическая формула
Пусть пара случайных процессов (x
1(t),
x 2(t)) образует стационарный в узком смысле процесс,
x [u,v]
- совокупность значений
x (t), u ё t ё v, и пусть
Фигурирующая здесь величина I(x1 , x2 ) называется средней скоростью передачи информации стационарным процессом x2 о стационарном процессе x 1 или просто - скоростью передачи информации. Скорость передачи информации
I(x
1,x
2)
обладает рядом свойств, аналогичных свойствам количества информации. Но она имеет и специфические свойства. Так для всякого
сингулярного случайного процесса x
2
, т.е. такого процесса, все значения
x
2(t) которого являются функциями от совокупности величин
Для всякого регулярного случайного процесса x 2 равенство I(x 1,x 2)=0 справедливо лишь тогда, когда случайный процесс x 1 не зависит от процесса x 2 (это говорит о том, что в некоторых случаях I(x 1,x 2) N I(x 2,x 1) ). При дополнительных условиях типа регулярности скорость передачи информации I(x 1,x 2) совпадает с пределом
где
0< c ё l 2nf(l ) ё c < ╔ Пусть стационарный процесс x = x (t) представляет собой последовательность величин, каждая из которых принимает значения из некоторого алфавита x, состоящего из конечного числа символов x1, x2,.,xn. Предположим, что вероятность появления на фиксированном месте определенного символа xi есть pi, а вероятность появиться за ним символу xj не зависит от предшествующих xi значений и есть pij: P{x (t) = xi} = pi, P{x(t+1) = xi xi|x(t) = xi, x(t-1),., } = pij Другими словами x = x (t) - стационарная цепь Маркова с переходными вероятностями {p ij} и стационарным распределением {p i}. Тогда скорость передачи информации стационарным процессом x(t) будет
I(x,x)
= -
В частности, если x = x(t) - последовательность независимых величин (в случае p ij = pj), то I (x,x) = -
Пусть x 1 = x 1(t) и x 2 = x 2(t) - стационарные гауссовы процессы со спектральными плотностями f11(l), f22(l) и взаимной спектральной плотностью f12(l) причем процесс x 2 = x 2(t) является регулярным. Тогда
I(x
1,
x
2) = -
Рассмотрим следующее условие близости гауссовых стационарных процессов x 1 (t) и x 2(t): M|x 1(t) - x 2(t)|2 ё d 2 Наименьшая скорость передачи информации
а параметр q 2 определяется из равенства
Эта формула показывает, какого типа спектральная плотность f22(l)
должна быть у регулярного стационарного процесса
x 2(t), который несет минимальную информацию
I
(x
1,x 2) " H
о процессе
x
1(t). В случае дискретного времени, когда
f11(l ) Ё
q 2 при всех l , -p
ё l ё p,
нижняя грань H скорости передачи достигается для такого процесса x
2
(t) (со спектральной плотностью f22(l), задаваемой приведенной выше формулой),
который связан с процессом x
1
(t) формулой В случае, когда спектральная плотность f 11(l) приближенно выражается формулой
соответствующая минимальная скорость передачи информации
H может быть вычислена по приближенной формуле
2.10.3. Симметричный канал без памяти Рассмотрим симметричный канал передачи данных без памяти c конечным числом входных сигналов х1
, когда передаваемый сигнал х1
с вероятностью 1-p правильно принимается на выходе канала связи, а с вероятностью p искажается, причем все возможные искажения равновероятны: вероятность того, что на выходе будет сигнал х2
, равна
Рассмотрим канал связи, на входе которого сигналы образуют стационарный процесс x 1 = x 1(t), M[x 1(t)]2 < ╔. Пусть при прохождении сигнала x 1 = x 1(t) он подвергается линейному преобразованию Aj со спектральной характеристикой j (l) и, кроме того, на него накладывается аддитивный стационарный гауссов шум z =z (t), так что на выходе канала имеется случайный процесс x 2(t) вида x 2(t) = aj x 1(t) + z (t). Предположим также, что ограничения на входной процесс состоит в том, что M[ x 1(t)]2 ё D 2 (постоянная D 2 ограничивает среднюю энергию входного сигнала). Пропускная способность такого канала может быть вычислена по формуле
(в последнем выражении интегрирование ведется в пределах -p ё l ё p для дискретного времени t и в пределах -╔ <l <╔ для непрерывного t), где fz z (l) - спектральная плотность гауссова процесса z (t), функция f(l) имеет вид
а параметр q
2 определяется из равенства
Нужно сказать, что если функция f(l ) представляет собой спектральную плотность регулярного стационарного гауссова процесса x 1(t), то этот процесс, рассматриваемый как входной сигнал, обеспечивает максимальную скорость передачи информации: I(x 1,x 2) = C. Однако в наиболее интересных случаях, когда время t меняется непрерывно, функция f(l ) обращается в нуль на тех интервалах частот l, где уровень шума сравнительно высок (отличные от нуля значения f(l ) сосредоточены в основном на тех интервалах частот l, где уровень шума сравнительно мал), и поэтому не может служить спектральной плотностью регулярного процесса. Более того, если в качестве входного сигнала выбрать процесс x 1(t) с спектральной плотностью f(l ), то этот сигнал будет сингулярным и соответствующая скорость передачи информации I(x 1,x 2) будет равна нулю, а не максимально возможному значению C, указанному выше. Тем не менее, приведенные выражения полезны, так как позволяют приблизительно представить вид спектральной плотности f(l ) регулярного входного сигнала x 1(t), обеспечивающей скорость передачи I(x 1, x 2), близкую к максимальному значению C. С практической точки зрения наиболее интересен случай, когда канал связи имеет ограниченную полосу w пропускаемых частот, т.е. когда спектральная характеристика выражается формулой
а проходящий через канал шум имеет равномерный спектр:
В этом случае пропускная способность может быть вычислена по приближенной формуле
При этом входной сигнал x 1(t), обеспечивающий скорость передачи информации I(x 1, x 2 ), близкую к максимальной, является гауссовым стационарным процессом со спектральной плотностью f(l ) вида
так что параметры D 2 и s 2 имеют следующий физический смысл:
|
|
Previous:
2.9.1 Используемые стандарты
UP:
2.6 Методы сжатия информации
|
|
|
|
2.1.1 Влияние шумов и помех
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Шумы определяют емкость канала и задают частоту ошибок при передаче цифровых данных. Шум по своей природе нестабилен и можно говорить лишь о том, что его величина с некоторой вероятностью лежит в определенном интервале значений. Плотность вероятности p(x) определяет вероятность того, что случайный сигнал X имеет значение амплитуды в интервале между x и x+Dx. При этом вероятность того, что значение х лежит в интервале между x1 и x2 определяется равенством:
, условием нормировки при этом является равенство
.
P(x) - вероятность, а p(x) - плотность вероятности. Вероятность того, что x меньше некоторой величины y равна
, откуда следует, что P{x1
Так называемый белый шум подчиняется непрерывному нормальному (Гауссову) распределению
В этом случае, если мы хотим знать вероятность того, что амплитуда шумового сигнала лежит в пределах ╠ v, то можно воспользоваться выражением
и
.
Тогда P{x1
=
.
Распределение P(x) обычно называется функцией ошибок (erf(x) = -erf(-x)). Полезной с практической точки зрения является вероятность P{-ks
Из числа дискретных распределений наиболее часто используемым является распределение Пуассона. Как уже говорилось, во многих случаях шум имеет гауссово распределение с нулевым средним значением амплитуды. В этих случаях среднее значение мощности шумового сигнала равно вариации функции плотности вероятности. В этом случае отношение сигнал-шум будет равно
Шум определяет вероятность ошибки при передаче сообщения по каналу связи и, в конечном итоге, пропускную способность канала (см. теорему Шеннона; раздел 2.1 Передача сигналов по линиям связи ). |
|
Previous:
2.1 Передача сигналов по линиям связи
UP:
2 Преобразование, кодировка и передача информации
|
|
|
|
2.1 Передача сигналов по линиям связи
Семенов Ю.А. (ГНЦ ИТЭФ) |
Теорема Шеннона ограничивает предельную пропускную способность канала I с заданной полосой пропускания F и отношением сигнал/шум S/N : Для стандартного телефонного канала F=3кГц, N/S=30db, следовательно, теоретический предел для публичной коммутируемой телефонной сети равен примерно 30кбит/с. Ослабление для телефонных скрученных пар составляет около 15 дБ/км, дополнительные ограничения возникают из-за перекрестных наводок. Стандартные проводные линии связи имеют ослабление 6 дБ/км на частоте 800 Гц, или 10 дБ/км на частоте 1600 Гц. На рис. 2.1.1 показана зависимость ослабления от частоты передаваемого сигнала для медной линии с сечением 0,5 мм.
От частоты зависит фаза (из расчета на километр) и волновое сопротивление скрученной пары (см. рис. 2.1.2), по этой причине искажения формы сигнала при заметной длине линии неизбежны. Из формулы [2.1] видно, что расширять пропускную способность канала можно за счет широкополосности и высокого отношения сигнал-шум. Существует много источников шума, один из главных тепловые шумы (N = kTB, где T - температура в градусах Кельвина, B - полоса пропускания приемника, а k - постоянная Больцмана). На практике существенно большее влияние оказывают различного рода наводки. Увеличeние пропускной способности сети достигается путем сокращения длины кабеля (уменьшение расстояния между узлами сети), заменой типа кабеля, например, на провод с большим сечением, или применив оптоволоконный кабель. Определенный эффект может быть получен и с помощью усовершенствованной системы шумоподавления (новый, более эффективный модем).
Сопротивление скрученной пары от коммутатора до терминального оборудования может лежать в пределах 800-20000 Ом. Следует учитывать, что при подаче питания на терминальное оборудование (телефон) по подводящему кабелю, большое его сопротивление, помимо прочего, приведет к падению питающего напряжения. В многожильных кабелях определенные проблемы создают перекрестные наводки и шумы. Обычно рассматриваются два случая перекрестных наводок:
NEXT-наводки при большом числе пар проводов в кабеле подчиняются закону f1.5 , а их уровень составляет около 55 дБ при частоте 100 кГц. FEXT-наводки сильно зависят от схемы коммутации и разводки проводов и обычно менее опасны, чем NEXT. Еще одним источников наводок является импульсный шум внешних электромагнитных переходных процессов. Этот вид наводок обычно характеризуется процентом времени, в течении которого его уровень превышает порог чувствительности, и варьируется в зависимости от обстоятельств в очень широких пределах. При передаче по линии сигналы модулируются, при этом важно обеспечить сохранение среднего уровня сигнала (постоянной составляющей). Определенные искажения сигнала вносит сам кабель. Заметное влияние на характер искажений оказывает межсимвольная интерференция (ISI - Intersymbol Interference). Эта интерференция возникает из-за расплывания импульсов в процессе их передачи по линии и наезжания их друг на друга. Проблема усложняется тем, что характеристики передающей линии могут меняться со временем (коммутаторы и маршрутизаторы). По этой причине очень важно обеспечить идентичность условий передачи различных частот при наличии таких вариаций. Для решения этой задачи используются линейные эквилайзеры (рис. 2.1.3 и 2.1.4), которые выполняют эту операцию во всем спектре частот, или после стробирования для реального спектра сигнала. Этот метод чувствителен к шумам в системе. Эквилайзеры с решающей обратной связью (DFE - Decision Feedback Equalizer) не чувствительны к шумам, они управляются принятой информацией. Но влияние ошибок при приеме информации в этом случае может быть усилено.
На практике линейное выравнивание и эквилизация с обратной связью совмещаются друг с другом и со специальными методами формирования передаваемых сигналов. Проблема усугубляется тем, что одна и та же линия используется для передачи данных в обоих направлениях одновременно. Для улучшения отношения сигнал/шум следует поднимать амплитуду передаваемого по линии сигнала. Выбранное значение определяется требованиями перекрестных наводок и возможностями существующих БИС. В результате компромисса выбрана амплитуда 2.5 В на нагрузке 135 ом. Любые нелинейные искажения должны быть менее 36 дБ по отношению к основному сигналу. Учитывая динамический диапазон сигналов в линиях связи, отношение сигнал шум предполагается равным 20 дБ, что соответствует ограничению 6дБ на число ошибок 1/106 для гауссова распределения шума. При аналого-цифровом преобразовании одному биту соответствует 6 дБ. Обычно двухпроводная линия (тем более 4-х проводная) используется для одновременного двухстороннего обмена (full duplex). Эта задача может быть решена схемотехнически мультиплексированием по времени (TDD - Time Division Duplex) или частоте (FDD - Frequency Division Duplex). TDD довольно легко реализовать, этот метод не требует сложных фильтров и эквилайзеров. Метод TDD привлекателен при малых длинах кабеля для коммутируемых телефонных сетей.
Более широко для реализации двухстороннего обмена по одной паре проводов используется метод эхо-компенсации. Этот метод предполагает вычитание передаваемого сигнала из принимаемого, определяя тем самым истинную форму входного сигнала. Если на приведенном рисунке 2.1.5 Zвх равно волновому сопротивлению линии, то выходной сигнал передатчика не будет влиять на работу приемника. Здесь предполагается, что выходное сопротивление передатчика много меньше z= zлинии. Учитывая вариации ослабления сигнала, схема эхо-компенсации должна уметь работать в очень широком динамическом диапазоне амплитуд, сохраняя удовлетворительную линейность. Это обстоятельство, а также зависимость zлинии от частоты, приводит к заметному усложнению схем эхо-компенсации (Рис. 2.1.6). Системы эхо-компенсации весьма чувствительны к временному разбросу срабатывания пороговых схем, так как это приводит к фазовому сдвигу вычитаемых друг из друга сигналов.
На рис. 2.1.7 показана зависимость скорости пропускания от сопротивления петли передающей линии для разных схем кодирования сигнала (пунктирной линией отображен вариант четырехуровневого кодирования). Те, кто работал с выделенными линиями, усвоили эту зависимость на практике. Если сопротивление линии более 1,5 кОм вы скоро будете знать дежурных вашей телефонной станции по имени, узнаете, что такое грозовые вставки и что они имеют привычку окисляться.
Различные методы модуляции приводят к разным уровням перекрестных наводок, и, как следствие, могут обеспечить разные скорости пропускания сигналов. Так применение линейной эквилизации при амплитудной модуляции дает улучшение пропускной способности примерно в 5 раз. Из рисунка 2.1.8 видно, что переход от линейного выравнивания к эквилизации с обратной связью позволяет добиться улучшения почти в 1,5 раза. Многоуровневый метод кодирования увеличивает скорость пропускания еще на 30%. Следует, правда, иметь в виду, что многоуровневый метод кодирования характеризуется большим уровнем импульсных помех и, следовательно, ошибок.
На рис. 2.1.8 показана зависимость отношения сигнал-шум от сопротивления петли для разных схем передающего канала. Пунктиром проведены зависимости для случая четырехуровневого кодирования. Кривые 1 соответствует случаю амплитудной модуляции с линейным выравниванием, а кривые 2 - варианту эквилизации с обратной связью. |
|
Previous:
2 Преобразование, кодировка и передача информации
UP:
2 Преобразование, кодировка и передача информации
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.2 Представление электрических сигналов в цифровой форме
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Прогресс последних лет в области повышения пропускной способности каналов в заметной мере связан с развитием технологии передачи цифровых данных. Здесь нужно решить проблемы синхронизации, эффективного кодирования и надежной передачи. Чем шире импульс, тем большую энергию он несет, тем лучше отношение сигнал/шум, но тем ниже и предельная скорость передачи. Раньше каждому двоичному разряду соответствовал импульс или перепад в кодовой последовательности. Сегодня перепад возникает лишь при смене последовательности нулей на последовательность единиц или наоборот. Цифровой метод имеет целый ряд преимуществ перед аналоговым:
На рисунке 2.2.1В представлена уже не последовательность импульсов, а последовательность переходов из одного состояния в другое. При этом уровень +V соответствует логической <1>, а -V - логическому <0>. Переключение из состояния <0> в состояние <1> и наоборот (бод) уже не соответствует передаче одного бита.
Рис. 2.2.1 Передача цифровых кодов по передающей линии На практике число нулей или единиц следующих подряд не лимитировано. По этой причине на принимающей стороне при этом рано или поздно возникает проблема синхронизации временных шкал передатчика и приемника. Для решения этой проблемы существует два метода передачи данных: синхронный и асинхронный . Асинхронный метод используется для относительно низкоскоростных каналов передачи и автономного оборудования. Синхронный метод применяется в скоростных каналах и базируется на пересылке синхронизующего тактового сигнала по отдельному каналу или путем совмещения его с передаваемыми данными. При наличии синхронизации приемника и передатчика можно допустить более длинные последовательности нулей или единиц, что способствует повышению пропускной способности. На рис. 2.2.2 показана схема канала, использующая технику импульсно-кодовой модуляции. Импульсно-кодовая модуляция (ИКМ) была предложена в 30-ые годы 20-го века, но реализована лишь в 1962 году.
Рис. 2.2.2. Система коммуникаций с использованием кодово-импульсной модуляции (pcm) Шаг квантования в АЦП должен быть много меньше диапазона вариации входного сигнала. Число уровней квантования n выбирается из соображений минимизации искажений сигнала и повышения уровня s/n. При разумных предположениях (биполярность сигнала (+V -V), однородность распределения уровня сигнала в рабочем диапазоне, ошибка квантования не более S/2, где S шаг квантования, и т.д.) [S/N]db = 10 log10(22n) = 6n (N - шум квантования при этом равен S 2/12). Это означает, что при 2n уровнях квантования и при условии, что входной сигнал может варьироваться во всем рабочем диапазоне АЦП, отношение сигнал-шум (S/N), связанное с самим процессом квантования, будет равно 6n при n=8 это составит 48 дБ). Отсюда следует известное значение относительного расстояния между уровнями квантования, равное 6 дБ. Звуковой сигнал может иметь динамический диапазон 40 дБ, что создает определенные проблемы, которые преодолеваются путем прямого и обратного логарифмического преобразования (см. рис. 2.4.1). Типичный кадр данных в асинхронном канале начинается со стартового бита, за которым следует 8 битов данных. Завершается такой кадр одним или двумя стоп-битами. Стартовый бит имеет полярность противоположную пассивному состоянию линии и переводит приемник в активное состояние. Пример передачи такого кадра показан на рис. 2.2.3.
Рис. 2.2.3. Пример передачи кадра в асинхронном режиме Одним из способов обеспечения надежной синхронизации является применение в приемнике частоты, например, в 8 раз больше частоты следования данных. При этом стробирование данных может производиться примерно в середине сигнала бита (см. рис. 2.2.4).
Рис. 2.2.4. Схема синхронизации и стробирования с 8-кратной тактовой частотой приемника Начальный и стоп-биты на каждый байт данных снижают пропускную способность канала и по этой причине используются только для низких скоростей обмена. Увеличение же длины блока данных приводит к ужесточению требований к точности синхронизации. При использовании синхронного метода передачи необходимы специальные меры для выделения кадра в общем потоке данных. Для решения этой задачи используется специальная сигнатура. Если такая последовательность встретится внутри кадра, она видоизменяется путем ввода в нее двоичных нулей (bit stuffing). Синхронный приемник нуждается в синхронизирующем сигнале, передаваемом передатчиком. Обычно это реализуется путем введения определенного вида кодирования сигнала, например, биполярного кодирования. В этом случае используется три уровня сигнала: +v соответствует логической 1; -v - логическому нулю, а 0 вольт логическому нулю или единице. Пример такого типа кодирования показан на рис. 2.2.5.
Рис. 2.2.5. Пример биполярного кодирования сигнала (схема RZ - return-to-zero) Другой разновидностью такого рода кодирования является использование манчестерского кода. В этой схеме логической единице и нулю соответствует не уровни напряжения, а перепады. Так логической единице поставлен в соответствие переход с низкого уровня на высокий, а логическому нулю - с высокого на низкий (схема NRZ - non-return-to-zero). Пример представления сигнала с использованием манчестерского кода показан на рис. 2.2.6.
Рис. 2.2.6. Кодирование сигнала с использованием манчестерского кода. Манчестерский код достаточно неэффективно использует пропускную способность канала. Оба описанные выше кода требуют удвоения полосы для передачи данных. Этого можно избежать, используя схему цифровой фазировки DPLL - Digital Phase Locked Loop). Эта схема предполагает применение кодирования NRZI (non-return-zero-inverted). Здесь сигнал сначала кодируется с использованием кода NRZ и только затем последовательность преобразуется в NRZI. В процессе такого преобразования логический нуль из NRZ вызывает определенную модификацию исходного кода, в то время как логическая единица не приводит ни к каким вариациям. Здесь создаются условия, при которых количество переходов 0/1 и 1/0 в единицу времени достаточно велико, чтобы обеспечить надежную синхронизацию. Схема NRZI кодирования с использованием DPLL проиллюстрирована на рис. 2.2.7.
Рис. 2.2.7. NRZI-кодирование Симметричная скрученная пара проводов с волновым сопротивлением 120 Ом обеспечивает пропускную способность 2048 Мбит/с (система кодирования HDB3, длина проводов ~100м), а 100 Ом - 1544 Мбит/с (амплитуда сигналов 3 в, система кодирования B8ZS). Номинальное значение перепада обычно составляет 750 мВ. Наиболее простая схема передача данных путем представления <0> и <1> с помощью двух уровней напряжения не применяется из-за того, что линия обычно используется для подачи на оконечное (терминальное) оборудование. Проблема может быть решена, если <0> характеризуется 0 вольт (приращение над постоянным уровнем), а <1> попеременно сигналами положительной и отрицательной полярности (AMI - Alternate Mark Inversion). Такая схема создает проблему синхронизации, когда подряд следует большое число нулей. Необходимо, чтобы было достаточное число переходов 0->1 и 1->0 в единицу времени. Существует также схема ADI (Alternate Digit Inversion), где инверсия полярности производится для каждого из передаваемых двоичных разрядов. Но эта схема менее эффективна. По этой причине система кодирования AMI была модифицирована в HDB3 (High Density Bipolar 3). Цифра 3 указывает на максимально возможное число последовательных нулей в кодовой последовательности. AMI требует, чтобы <1> передавались попеременно сигналами противоположной полярности, так последовательность 11011 должна быть передана как +-0+-. HDB3 заменяет любую группу из 4 нулей последовательностью из 3 нулей, за которой следует нарушение последовательности отображения единиц. Таким образом, последовательность 11000001 будет отображена как +-000-0+ (возможен инверсный вариант, когда символы + заменяются на - и наоборот). Дальнейшего улучшения балансировки сигнала можно достичь, если заменить код, содержащий 4 нуля подряд, последовательностью b00v (b - обычный биполярный сигнал, v - нарушение последовательности). В США используют схему кодировки B8ZS (Bipolar with 8 Zeros Substitution), где 8 нулей кодируются как 00b0vb0v. В 1986 году ansi принял решение о введение схемы кодирования 2B1Q (2 Binary into 1 Quaternary). При этой схеме каждая пара бит преобразуется в четверичные элементы +3 +1 -1 -3. Код синхронизации (SW - Synchronization Word) при этом содержит 9 четверичных элементов, повторяющихся каждые 1.5 мс: +3 +3 -3 -3 -3 +3 -3 +3 +3 (+3 соответствует +2.5 В) В Германии используется схема кодировки 4B3T (4 двоичных разряда кодируются в 3 циклических кода). Двоичная информация передается блоками, обычно зазываемыми кадрами (или пакетами). В рамках системы 2B1Q для передачи 144 кбит/с требуется частота модуляции не менее 72 кбод. На практике для передачи кадров и выполнения функций управления необходимо создать дополнительные виртуальные каналы. Это доводит требуемую частоту модуляции до 80 кбод. Сводные данные по наиболее популярным схемам кодирования приведены в табл. 2.2.1. Таблица 2.2.1.
Кадр содержит 120 пар бит (quats), что соответствует 240 бит, 8 кадров образуют мультифрэйм. Первый кадр мультифрэйма выделяется путем посылки Inverted Synchronization Word (ISW). В конце каждого кадра всегда присутствуют специальные биты, которые служат для целей управления (бит активации, бит холодного старта, биты состояния питания, биты управления синхронизацией и т.д.). Структура кадра выглядит следующим образом:
Кадры следуют каждые 1.5мс. Здесь нужно следить за тем, чтобы не было корреляции между сигналами, следующими в противоположных направлениях. Для этого используются скрэмблеры. В традиционной телефонной сети для соединения с требуемым клиентом используются аппаратные коммутаторы. Если коммутатор имеет n входов и n выходов, то одновременно можно реализовать не более n связей. Реально это число всегда меньше и клиент слышит в трубке "короткие гудки" сигнала "занято". В случае комбинирования традиционного коммутатора с m-канальными мультиплексорами пакетов по времени можно осуществить до m*n связей одновременно. При этом становится возможным объединить нескольких клиентов так, что они все одновременно могут говорить друг с другом. Схема такого переключателя каналов показана на рис. 2.2.8.
Рис. 2.2.8. Схема переключателя каналов с мультиплексированием по времени. Кружочки на пересечениях линий представляют собой ключи, замыкая которые можно соединить i-й входной канал с j-м выходным. На каждой линии может быть только один замкнутый ключ. Такая схема коммутации называется TST (Time-Space-Time). Именно она преобладает сегодня при построении сетей ISDN. Магистральные каналы ISDN строятся в соответствии со стандартом T1. Такая схема при числе входных и выходных каналов равном N=1000 требует миллиона элементарных переключателей. Можно рассмотреть вариант когда используются коммутаторы с n входами и k выходами. Схема коммутатора с N=16, n=4 и k=2 показана на рис. 2.2.9. Число элементаных переключателей в таком коммутаторе М равно: M = 2kN + k(N/n)2 Первое слагаемое характеризует число элементарных переключателей во входной и выходной секциях системы, а второе - число элементарных переключателей в k внутренних модулях При N=1000, n=50 и k=10 требуется 24000 элементарных переключателей вместо миллиона (но и число одновременно формируемых каналов становится много меньше 1000).
Рис. 2.2.9. Каскадный переключатель-мультиплексор. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
2.1.1 Влияние шумов и помех
UP:
2 Преобразование, кодировка и передача информации
|
|
|
|
2.3 Цифровые каналы T1 и Е1
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Системы (каналы) T1 имеют пропускную способность, соответствующую 24 аналоговым каналам с полосой 0-3.3 кГц (американская версия стандарта). Частота стробирования равна 8 кГц, что соответствует передаче 8000 кадров в сек. После каждых 6000 футов коаксиального кабеля ставятся системы регенерации сигналов. Все 24 канала мультиплексируются на общий коаксиальный кабель, предварительно производится PCM-преобразование сигналов. 24 канала по 8 бит (при 8-битном АЦП) дает 192 бита на кадр. Один дополнительный (193-ий) бит используется для целей синхронизации (F). Таким образом частота бит в канале Т1 составляет 193*8000=1,554 Мбит/с (это стандарт США, его европейский аналог - Е1 имеет 30 каналов и пропускную способность 2048 кбит/c). Это соответствует частоте кадров 667/с. Каждый восьмой бит (младший) байта (временного домена на рис. 2.3.1) используется для целей управления, что несколько снижает пропускную способность. В ISDN каналы 1,544 и 2,048 Мбит/с, форматы которых здесь описаны, называются первичными. 8-битовые pcm-блоки генерируются каждые 125мксек (8000/с). Структура данных при передаче со скоростью 1,544 Мбит/с представлена ниже (isdn 2*B+D):
Рис. 2.3.1. Структура кадров для американского (вверху) и европейского (внизу) стандартов передачи данных Скорости передачи 1,544 (кодирование B8ZS) и 2,048 Мбит/с (HDB3) называются первичными скоростями. Кадры структурированы так, что временные домены (таймдомен на рис. 2.3.1) для передачи данных по каналам B1 и B2 чередуются. В Европе используется 2048Мбит/с интерфейс. Каждый 6-ой кадр используется для сигнальных целей. Количество временных доменов в кадре определяет число телефонных разговоров, которые могут осуществляться одновременно. Для американского стандарта это число равно 24, а для европейского 30 (в последнем случае учтено то, что часть доменов используется в служебных целях). Все современные коммутаторы управляются центральным процессором. Такие коммутаторы обычно называются коммутаторами, управляемыми встроенной памятью (SPC - Stored Program Controlled exchanges). |
|
Previous:
2.2 Представление электрических сигналов в цифровой форме
UP:
2 Преобразование, кодировка и передача информации
|
|
|
|
2.4.1 Дельта-модуляция
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Дельта-модуляция представляет собой вариант дифференциальной импульсно-кодовой модуляции, где для кодирования разностного сигнала используется только один бит. Этот бит служит для того, чтобы увеличить или уменьшить оценочный уровень. Примером реализации дельта-модуляции может служить схема, показанная на рис. 2.4.1.1. Сигнал ЦАП отслеживает входной сигнал in(t). Здесь компаратор заменил дифференциальный усилитель, который используется в дифференциальном импульсно-кодовом модуляторе.
Рис. 2.4.1.1 Схема устройства линейной дельта-модуляции Если скорость нарастания входного сигнала велика, то уровень на выходе ЦАП будет отставать и сможет нагнать In(t) только, когда входной сигнал начнет уменьшаться. Данный метод не является разумной альтернативой PCM. Для улучшения характеристик дельта-преобразователя реверсивный счетчик можно заменить цифровым процессором, при этом шаг S становится переменным, но кратным некоторому базовому значению. Существуют много других способов кодирования человеческого голоса, среди них наиболее эффективный реализован в приборах, носящих название - вокодер (VOCODER). |
|
Previous:
2.4 Методы преобразования и передачи звуковых сигналов
UP:
2.4 Методы преобразования и передачи звуковых сигналов
|
|
|
|
2.4.2 Кодировщики голоса (Vocoder)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Эта технология находит применение в военных системах связи, в диспетчерских службах, а также в системах пейджерной связи. Разработчики преобразователей голоса учли особенности работы горла, голосовых связок и всего речевого аппарата. Звонкие и глухие звуки воспроизводятся здесь различными способами (с помощью импульсного генератора и генератора шума, соответственно). Блок-схема преобразователя звука типа вокодер показана на рис. 2.4.2.1. Исходный спектр человеческого голоса здесь делится на ряд субдиапазонов (на рис. 2.4.2.1 их число равно16) по 200 Гц каждый. Эти субдиапазоны выделяются узкополосными фильтрами, за которыми следуют выпрямители и фильтры низких частот (20 Гц). Выходные сигналы этих фильтров мультиплексируются и преобразуются в цифровую форму. Частота стробирования этих сигналов составляет примерно 50 Гц. Разрядность АЦП в этом случае может составлять 3 бита. На принимающей стороне осуществляется цифро-аналоговое преобразование (ЦАП) и мультиплексирование. Сбалансированные амплитудные модуляторы, управляемые ЦАП и переключателем, выдают сигналы на узкополосные фильтры. Все эти сигналы смешиваются в сумматоре, а результат воспроизводится. Не трудно видеть, что в случае схемы, показанной на рис. 2.4.2.1, необходимое быстродействие передающей линии составляет 3 бита * 50 Гц * 16 каналов = 2,4 Кбит/с. Дальнейший выигрыш может быть получен за счет цифрового сжатия. Число каналов (фильтров) и ширина пропускаемой полосы частот может варьироваться, соответственно будет меняться и качество воспроизведения звука. Минимально возможная полоса пропускания передающей линии, при которой значение передаваемого текста еще воспринимается правильно, лежит ниже 1 Кбит/с. Предшествующая фраза, включая пробелы и знаки препинания, содержит около 150 символов. Для ее произношения требуется около 10 сек (15 символов в сек). Но даже вокодеру потребуется для этого предложения передать не менее 10000 бит. Откуда такое отличие? Во-первых, человеческая речь индивидуальна и эта фраза, произнесенная разными людьми, будет звучать по-разному, кроме того, существует эмоциональная окраска, которой практически лишена буквенная запись. Во-вторых, даже самая совершенная современная система сжатия звуковой информации не идеальна и остается широкое поле для дальнейшего совершенствования. Пути могут быть разными в зависимости от поставленной задачи. Если требуется передать только информацию, следует преобразовать звук в символьную (буквенную) форму, передать эти данные в цифровом виде, а на принимающей стороне осуществить обратное преобразование. Само буквенное представление может быть также подвергнуто некоторому сжатию, но это неизбежно увеличит задержку воспроизведения. В сущности, данная схема является развитием идей, заложенных в вокодере. В случае необходимости передачи индивидуальных особенностей голоса, сначала должен проводиться анализ этих персональных отличий. Особенности голоса в закодированном виде передаются принимающей стороне, где эти данные используются в дальнейшем при воспроизведении закодированного текста. Эти схемы потребуют довольно мощных сигнальных процессоров и, вероятно, найдут применение лишь в следующем веке.
Рис. 2.4.2.1. Блок-схема кодирования/декодирования человеческого голоса (Vocoder) |
|
Previous:
2.4.1 Дельта-модуляция
UP:
2.4 Методы преобразования и передачи звуковых сигналов
|
|
|
||||||||||||||||||||||
|
2.4.3 Передача голоса по каналам Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||
|
Несколько лет назад появился новый вид услуг в Интернет - голосовая связь (IP-phone, Vocaltec). Сегодня имеется 30 миллионов абонентов, регулярно пользующихся IP-phone и его аналогами, ожидается до 200 миллионов до конца текущего десятилетия, качество передачи постепенно приближается к уровню цифровой телефонии. Среди пользователей есть те, для кого это лишь возможность общения, как для радиолюбителей; но все больше людей использует IP-phone для деловых контактов или даже как объект бизнеса. Существуют два алгоритма сжатия звуковой информации, используемых для ip-телефонных переговоров: GSM (global system for mobile communications, ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm), которая обеспечивает коэффициент сжатия 5, и алгоритм DSP-группы (true speech) с коэффициентом сжатия данных 18 (работает при частотах 7.7 кбит/с). Добавление аппаратных средств сжатия информации позволяет сократить необходимую полосу до 6.72 Кбит/с. Потеря 2-5% пакетов остается незамеченной, 20% оставляет разговор понятным. В таблице 2.4.3.1 представлена зависимость необходимой полосы телекоммуникационного канала от частоты стробирования звукового сигнала, которая определяет качество воспроизведения. Таблица 2.4.3.1.
Для подключения к сети ip-phone необходима мультимедийная карта, микрофон, динамики (или наушники), 8 Мбайт оперативной памяти, доступ к Интернет и соответствующее программное обеспечение. Качество передачи звука зависит от загруженности IP-канала. В качестве транспорта используется протокол UDP. Для обеспечения высокого качества звука нужна гарантированная ширина IP-канала, ведь задержанные сверх меры UDP-дейтограммы теряются безвозвратно, что и приводит к искажениям. Внедрение протоколов, гарантирующих определенную ширину канала сделают IP-phone значительно более привлекательным. Многие компании уже предлагают такое оборудование и программы. Программы и описания этого вида услуг можно найти по адресам: ftp://cs.ucl.ac.uk/mice/videoconferencehttp://www.pulver.com/netwatch http://www.planeteers.com http://www.newparadigm.com http://www.vocaltec.com http://www.itelco.com http://www.quarterdeck.com В последнее время технология передачи звука по каналам Интернет стала широко использоваться для трансляции новостей и музыки. При этом обеспечивается вполне удовлетворительное качество даже при передаче стерео программ. В этом случае имеется возможность применить более эффективное сжатие информации и протоколы типа RTP и RTCP. Задержка при передаче в этом случае никакого значения не имеет, а качество доставки гарантировано. Современные системы ip-телефонии снабжены гибкой системой буферов, позволяющих использовать для передачи паузы, когда один из партнеров молчит. (См. также "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. H. Schulzrinne, S. Petrack. May 2000" RFC-2833 и "URLs for Telephone Calls. A. Vaha-Sipila. April 2000". RFC-2806). В настоящее время имеется практически полный набор технологий, чтобы создать электронную книгу. Такая книга будет представлять собой систему размером с ноут-бук, снабженное устройством для чтения CD-дисков. Текст книги вместе с иллюстрациями и необходимыми командными последовательностями записывается на CD. При этом в перспективе можно рассматривать возможность того, что такое устройство будет читать "книгу" вслух (вывод на наушники). В настоящее время имеется достаточно большое количество книг, записанных на cd. Это, прежде всего, энциклопедические словари, альбомы музеев, библия и многие другие. Преимущество такой формы книги уже сегодня ощутимо - вы можете использовать современные поисковые средства, чтобы найти нужный раздел или какую-то конкретную информацию. По мере развития этой технологии и интеграции ее с сетями можно будет осуществлять поиск не только по данной книге, но и по книгам или журналам, ссылки на которые в данной книге содержатся, что может быть особенно полезно при первичном знакомстве с какой-то проблемой. Я здесь не говорю о компактности, а в перспективе, и долговечности такой формы записи информации. При звуковом воспроизведении читатель сможет выбирать, голосом какого актера или актеров будет читаться данная книга. Разумеется, для этого не потребуется начитывать данный текст самим актерам. Достаточно иметь запись характерных особенностей голоса и интонаций конкретного голоса, а процессор сам при генерации звука будет использовать голосовые особенности того или иного человека. Немного фантазии и можно будет представить, как ЭВМ будет воспроизводить текст в виде фильма, который она сгенерировала по выданному ей тексту (ведь сгенерирован же на ЭВМ корабль "Титаник" и море, по которому он плывет). Аналогичные услуги смогут оказываться и через сеть Интернет. Наибольшие трудности вызовет реализация качественного воспроизведения. Программы способные преобразовывать символьный текст в голос уже существуют. Проблема распознавания индивидуального голоса давно решена в охранных системах. Осталось научиться использовать результаты такого анализа при воспроизведении. Активно разрабатываются многие новые стандарты и протоколы для обеспечения передачи звука по ip-каналам, проведения видеоконференций и управления в реальном масштабе времени. К таким протоколам относятся RTP (real time protocol, RFC-1889, -1890), RTCP (real-time control protocol), который является дополнением RTP, и RSVP (resource reservation protocol, см. разделы проектов IETF nic.nordu.net, ftp.isi.edu, munnari.oz.au и ds.internic.net или ftp.ietf.org/internet-drafts/draft-ietf-rsvp-spec-16.txt), служащий для обеспечения своевременной доставки данных при работе в реальном времени. Протокол RTP способен работать помимо UDP/IP в сетях CLNP, ATM и IPX. Он обеспечивает детектирование потерь, идентификацию содержимого, синхронизацию и безопасность (доступ по шифрованному паролю, см. RFC-1423). Проблема синхронизации при передаче звука особенно важна, так как даже для локальных сетей время доставки пакетов может варьироваться в весьма широких пределах из-за используемого алгоритма доступа (например, CSMA/CD), а это приводит к искажениям при воспроизведении. Протоколы RTP и RTCP позволяют одновременное голосовое общение неограниченного числа людей в рамках сети Интернет. Протокол же RSVP (или его аналог) в случае внедрения гарантирует качество связи (разумеется, при достаточной широкополосности канала) за счет повышения приоритета пакетов реального времени. Следует иметь в виду, что голосовое общение, хотя и весьма привлекательно, не является единственной и даже главной целью разработчиков. По мере совершенствования протоколов Интернет сделает возможным управление в реальном масштабе времени довольно сложными удаленными объектами. В таблице 2.4.2 представлены характеристики аудио-кодеков, которые можно использовать в IP-телефонии. Таблица 2.4.2. Характеристики аудио-кодеков
При внедрении ip-телефонии желательно, чтобы сетевая инфраструктура обеспечивала:
Одна из возможных реализаций IP-телефонии показана на рис. 2.4.3.1. (MVD - Multiflex Voice/WAN модуль, включаемый в маршрутизатор, например, Cisco-3662).
На рисунке MVW-модуль (Multiflex Voice/WAN), включаемый в маршрутизатор, например, CISCO-3662, служит для связи с общедоступной телефонной сетью. Если сеть "А" размещена в Рио-де-Жанейро, а "В" в Москве, то любой клиент нижней сети сможет разговаривать с клиентом в Рио "бесплатно", а с клиентами телефонных сетей "А" и "B" по локальным тарифам. В левой части рисунка показаны телефонные аппараты, которые подключаются непосредственно к сегменту локальной сети. Такие приборы уже поступили в продажу. Связь может осуществляться как с традиционной старой аналоговой телефонной сетью, так и с ISDN. Телефонные аппараты могут подключаться непосредственно к интерфейсу маршрутизатора, к сетевой рабочей станции или к специальному сетевому адаптеру. |
||||||||||||||||||||||
|
Previous:
2.4.2 Кодировщики голоса (Vocoder)
UP:
2.4 Методы преобразования и передачи звуковых сигналов
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.4 Методы преобразования и передачи звуковых сигналов
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
На физическом уровне в ISDN используется кодово-импульсная модуляция с частотой стробирования 8кГц (что превосходит ограничение Найквиста = 2*3.3кГц, где 3.3кГц - полоса пропускания канала для традиционной телефонной сети). Эмпирически установлено, что для удовлетворительного воспроизведения речи, достаточно 4096 уровней квантования сигнала (12 разрядов АЦП). Такое разрешение диктуется большим динамическим диапазоном сигналов. По этой причине возникает возможность преобразования 12-битных кодов в 8-битные, что формирует информационный поток в 64 Кбит/c. Для этого используется логарифмическое преобразование. Природа позаботилась о человеке, снабдив его логарифмической чувствительностью слуха, в противном случае у нас в мозгу перегорали бы предохранители при близком выстреле или грозовом разряде. Логарифмическое преобразование наталкивается на определенные трудности при низких значениях входного сигнала, ведь логарифм для значений меньше 1 имеет отрицательную величину. Функция же преобразования должна пройти через нуль. В США две логарифмические кривые смещаются в направлении оси ординат (вертикальная ось), в результате получается функция вида:
Для дальнейшего упрощения процесса преобразования реальные кривые апроксимируются последовательностью отрезков прямых, наклоны которых каждый раз меняется вдвое. На практике функция табулируется (рекомендация G.711) и отличия m- и A-функций пренебрежимо малы. Но следует учитывать, что при реализации практической связи между Европой и Америкой, например телефонной, необходим m/A-конвертор. Для кодирования используется симметричный код, у которого первый бит характеризует полярность сигнала.
Дальнейшим усовершенствованием схемы pcm является адаптивный дифференциальный метод кодово-импульсной модуляции (Рис. 2.4.2). Здесь преобразуется в код не уровень сигнала в момент времени ti , а разница уровней в моменты ti и ti-1 . Так как обычно сигнал меняется плавно, что типично для человеческой речи, можно заметно сократить необходимое число разрядов АЦП. Принципиальное отличие между PCM и ADPCM (1984 год) заключается в использовании адаптивного АЦП и дифференциального кодирования, соответственно. Адаптивный АЦП отличается от стандартного PCM-преобразователя тем, что в любой момент времени уровни квантования расположены однородно (а не логарифмически), причем шаг квантования меняется в зависимости от уровня сигнала. Применение адаптивного метода базируется на том, что в человеческой речи последовательные уровни сигнала не являются независимыми. Поэтому, преобразуя и передавая лишь разницу между предсказанием и реальным значением, можно заметно снизить загрузку линии, а также требования к широкополосности канала. Следует иметь в виду, что метод не лишен серьезных недостатков: уровень шумов, связанный с квантованием сигнала, выше; при резких изменениях уровня сигнала, превышающих диапазон АЦП, возможны серьезные искажения.
Рис. 2.4.2. Адаптивный преобразователь голоса в код Расширение диапазона преобразования достигается умножением шага квантования на величину несколько больше (или меньше) единицы. При дифференциальном преобразовании на вход кодировщика подается не сам сигнал, а разница между текущим значением сигнала и предыдущим (рис. 2.4.3).
Рис. 2.4.3. ADPCM-преобразователь голоса в код для 32кбит/с Блок прогнозирования является адаптивным фильтром, который использует предшествующий код для оценки последующего стробирования. На вход кодировщика поступает сигнал, пропорциональный разнице между входным сигналом и предсказанием. Чем точнее предсказание, тем меньше бит нужно, чтобы с нужной точностью закодировать эту разницу. Характер человеческой речи позволяет заметно снизить требования к каналу при использовании адаптивного дифференциального преобразователя. Для компактных музыкальных дисков (cd) характерна полоса 50Гц - 20 кГц, обычная же речь соответствует полосе 50 Гц - 7 кГц. Только звуки типа Ф или С имеют заметные составляющие в высокочастотной части звукового спектра. Для высококачественной передачи речи используется субдиапазонный ADPCM-преобразователь (Adaptive Differential Pulse Code Modulation). В нем звук сначала стробируется с частотой 16 кГц, производится преобразование в цифровой код с разрешением не менее 14 бит, а затем подается на квадратурный зеркальный фильтр (qmf), который разделяет сигнал на два субдиапазона (50Гц-4кГц и 4кГц-7кГц). Диапазоны этих фильтров перекрываются в области 4кГц. Нижнему диапазону ставится в соответствие 6 бит (48кбит/с), а верхнему 2 бита (16 Кбит/с). Выходы этих фильтров мультиплексируются, формируя 64 кбит/с -поток. На CD используется 16-битное кодирование с частотой стробирования 44,1 кГц, что создает информационный поток 705 Кбит/c. Для стерео сигнала этот поток может удвоиться. Практически это не так - сигналы в стереоканалах сильно коррелированны, и можно кодировать и передавать лишь их разницу, на практике высокочастотные сигналы каналов суммируются, для различия каналов передается код их относительной интенсивности. Исследования показывают, что для акустического восприятия тонкие спектральные детали важны лишь в окрестности 2 кГц. Для передачи звуковой информации с учетом этих факторов был разработан стандарт MUSICAM (Masking pattern Universal Sub-band Integrated Coding and Multiplexing), который согласуется с ISO MPEG (Moving Picture Expert Group; стандарт ISO 11172). musicam развивает идеологию деления звукового диапазона на субдиапазоны, здесь 20кГц делится на 32 равных интервалов. Логарифмическая чувствительность человеческого уха и эффект маскирования позволяет уменьшить число разрядов кодирования. Эффект маскирования связан с тем, что в присутствии больших звуковых амплитуд человеческое ухо нечувствительно к малым амплитудам близких частот. Причем чем ближе частота к частоте маскирующего сигнала, тем сильнее этот эффект (см. рис. 2.4.4). Сплошной линией на рисунке показана нормальная зависимость порога чувствительности уха, а пунктиром - зависимость порога чувствительности в присутствии 500-герцного тона с амплитудой в 110 дБ.
Рис. 2.4.4.Изменение порога чувствительности человеческого уха под влиянием эффекта маскирования. При разбиении на субдиапазоны можно оценить эффект маскирования и передавать только ту часть информации, которая этому эффекту не подвержена. При этом уровень ошибок квантования следует держать лишь ниже порога маскирования, что также снижает информационный поток. Для стробирования высококачественных звуковых сигналов используются частоты 32, 44,1 или 48 кГц. Стандартом предусмотрено три уровня кодирования звука, отличающиеся по сложности и качеству. На первом уровне производится разбивка на 32 диапазона, определение диапазонных коэффициентов и формирование кадров, несущих по 384 результатов стробирования. Уровень 2 формирует кадры с 1152 результатами стробирования и дополнительными данными. Уровень 3 допускает динамическое разбиение на субдиапазоны и уплотнение данных с использованием кодов Хафмана. Любой декодер способен работать на своем и более низком уровне. Для улучшения качества передачи низких частот в дополнение к суб-диапазонным фильтрам, используется быстрое Фурье-преобразование (FFT). Результирующая частота бит при передаче звуковых данных оказывается не постоянной. Практическое измерение показывает, что частота редко превышает 110кбит/с, применение 128кбит/с делает качество воспроизведения неотличимым от CD. Ограничение скорости на уровне 64 Кбит/с вносит лишь незначительные искажения. Ниже в таблицах представлены данные по скоростям передачи аудиоданных по традиционным цифровым и отповолоконным каналам (см. также раздел 3.5.6). Таблица 2.4.1 Скорости передачи данных по цифровым каналам
Таблица 2.4.2. Скорости передачи данных по оптическим каналам
Еще одним методом, нацеленным на повышение эффективности преобразования входного аналогового сигнала в код, является дельта-модуляция. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
2.3 Цифровые каналы T1 и Е1
UP:
2 Преобразование, кодировка и передача информации
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
2.5.2 Стандарт MPEG-7
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||
|
Перевод
http://mpeg.telecomitalialab.com/standards/mpeg-7/
MPEG-7 является стандартом ISO/IEC,
разработанным MPEG (Moving Picture Experts Group), комитетом, который
разработал стандарты MPEG-1, MPEG-2 и MPEG-4. Стандарты MpeG-1 и MPEG-2 сделали
возможным интерактивное видео на CD-ROM и цифровое телевидение. Стандарт MPEG-4
предоставляет стандартизованные технологические элементы, позволяющие
интеграцию парадигм производства, рассылки и доступа к содержимому в области
цифрового телевидения, интерактивной графики и интерактивного мультимедиа.
MPEG-7 формально называется
"Мультимедиа-интерфейс для описания содержимого" (Multimedia Content
Description Interface), он имеет целью стандартизовать описание мультимедийного
материала, поддерживающего некоторый уровень интерпретации смысла информации,
которая может быть передана для обработки ЭВМ. Стандарт MPEG-7 не ориентирован
на какое-то конкретное приложение, он стандартизует некоторые элементы, которые
рассчитаны на поддержку как можно более широкого круга приложений.
Дополнительную информацию о MPEG-7 можно найти на базовой странице MPEG:
а WEB-страница MPEG-7 (Industry Focus Group)
размещена по адресу http://www.mpeg-7.com.
Эти WEB-страницы содержат ссылки на информацию об MPEG, включая описание
MPEG-7, многие общедоступные документы, списки "Frequently Asked
Questions" и ссылки на WEB-страницы MPEG-7.
1. Введение
Огромное количество аудио-визуальной
информации стало доступно в цифровой форме, в виде цифровых архивов, во
всемирной паутине, в виде широковещательных потоков, а также в форме частных
или профессиональных баз данных. Значение информации часто зависит оттого,
насколько ее легко найти, извлечь, отфильтровать и управлять.
Тенденция очевидна. В ближайшие несколько
лет, пользователи столкнутся с таким большим числом мультимедийных материалов,
предоставляемых разными провайдерами, что эффективный доступ к этому почти
бесконечному материалу представляется трудно вообразимым. Несмотря на тот факт,
что пользователи имеют увеличивающиеся ресурсы, управление ими становится все
более сложной задачей, из-за их объема. Это касается как профессионалов, так и
пользователей. Вопрос идентификации и управления материалами не ограничивается
приложениями доступа к базам данных, таким как цифровые библиотеки, но
распространяются в сферу выбора широковещательных каналов, мультимедийного
редактирования и служб мультимедийных каталогов. Протокол MPEG-7 призван решить
многие из этих проблем.
MPEG-7 является стандартом ISO/IEC, разработанным
MPEG (Moving Picture Experts Group), комитетом, который разработал также
стандарты MPEG-1 (1992), MPEG-2 (1995), и MPEG-4 (версия 1 в 1998 и версия 2 в
1999). Стандарты MPEG-1 и MPEG-2 позволили производить широко распространенные
коммерческие продукты, такие как интерактивные CD, DVD, цифровое
широковещательное аудио (DAB), цифровое телевидение, и многие другие
коммерческие услуги. MPEG-4 является первым реальным мультимедийным стандартом
для представления данных, позволяющим интерактивно работать с комбинациями
натурального и синтетического материала, закодированного в виде объектов (он
моделирует аудио-визуальные данные, как комбинацию таких объектов). MPEG-4
предоставляет стандартизованные технологические элементы, допускающие
интеграцию производства, распределения и доступа к мультимедийному материалу.
Это относится к интерактивному и мобильному мультимедиа, интерактивной графике
и улучшенному цифровому телевидению.
Стандарт
MPEG-7,
формально
назван
"Multimedia
Content Description Interface".
MPEG-7
предоставит широкий набор стандартизованных средств описания мультимедиа
материала. В области действия MPEG-7 находятся как пользователи-люди, так и
автоматические системы, выполняющие обработку аудио-визуального материала.
MPEG-7 предлагает полный набор
аудиовизуальных средств описания, которые образуют базис для приложений, делая
возможным высококачественный доступ к мультимедийному материалу, что
предполагает хорошие решения для записи, идентификации материала, обеспечения
прав собственности, и быстрой, эргономичной, точной целевой фильтрации, поиска.
Дополнительную информацию о MPEG-7 можно
найти на WEB-сайте MPEG-7 http://drogo.cselt.it/mpeg/
и сайте MPEG-7 Industry Focus Group http://www.mpeg-7.com.
Эти web-страницы содержат ссылки на ценную информацию о MPEG, включая материалы
по MPEG-7, многие общедоступные документы, несколько списков 'Frequently Asked
Questions' и ссылки на другие WEB-страницы MPEG-7.
1.1. Контекст MPEG-7
Доступно все больше и больше
аудиовизуального материала из самых разных источников. Информация может быть
представлена в различных медийных формах, таких как статические изображения,
графика, 3D модели, звук, голос, видео. Аудиовизуальная информация играет
важную роль в обществе, будучи записана на магнитную или фото пленку, или
поступая в реальном масштабе времени от аудио или визуальных датчиков в
аналоговой или цифровой форме. В то время как аудиовизуальная информация
первоначально предназначалась для людей, в настоящее время все чаще такие
данные генерируются и передаются и воспринимаются компьютерными системами. Это
может быть, например, сопряжено с распознаванием голоса или изображения и
медийным преобразованием (голос в текст, картинку в голос, голос в картинку, и
т.д.). Другими сценариями являются извлечение информации (быстрый и эффективный
поиск для различных типов мультимедийных документов, представляющих интерес для
пользователя) и фильтрация потоков описаний аудиовизуального материала (чтобы
получить только те элементы мультимедиа данных, которые удовлетворяют
предпочтениям пользователя). Например, программа во время телепередачи
запускает соответствующим образом программируемый VCR, чтобы записать эту
программу, или сенсор изображения выдает предупреждение, когда происходит
определенное событие. Автоматическое транскодирование может быть выполнено для
строки символов, преобразовав ее в аудиоданные, или можно провести поиск в
потоке аудио или видео данных. Во всех этих примерах, аудио-визуальная
информация была приемлемым образом закодирована, что позволяет программе ЭВМ
предпринять соответствующие действия.
Аудиовизуальные источники будут играть в
перспективе все большую роль в нашей жизни, и будет расти необходимость
обрабатывать такие данные. Это делает необходимым обработку видов
аудиовизуальной информации, имеющей волновую форму, компрессированный формат
(такой как MPEG-1 и MPEG-2) или даже объектно-ориентированный (такой как
MPEG-4) формат. Необходимы формы презентации, которые позволяют некоторую
степень интерпретации смысла информации. Эти формы могут быть переданы в, или
доступны для прибора или программы ЭВМ. В примерах приведенных выше датчики
изображения могут генерировать визуальные данные не в форме PCM (значения
пикселей), а в форме объектов с ассоциированными физическими величинами и
временной информацией. Эти объекты могут быть запомнены и обработаны с целью
проверки, выполняются ли определенные условия. Видео записывающий прибор может
получить описания аудиовизуальной информации, ассоциированной с программой,
которая при выполнении заданных условий выдаст команду на запись, например,
только новости за исключением спорта или запись фильма с автоматическим
вырезанием вставок рекламы (согласитеь, об этом сегодня можно только мечтать).
MPEG-7 будет стандартом для описания
мультимедийных данных, которые поддерживают определенные операционные
требования. MPEG не стандартизует приложения. MPEG может, однако использовать
приложения для понимания требований и развития технологий. Должно быть ясно,
что требования, сформулированные в данном документе, получены из анализа
широкого диапазона потенциальных приложений, которые могут использовать
описания MPEG-7. MPEG-7 не ориентирован на какое-то конкретное приложение;
скорее, элементы, которые стандартизует MPEG-7, будут поддерживать максимально
широкий диапазон приложений. 1.2. Цель MPEG-7
В октябре 1996, группа MPEG начала
разработку проблем, рассмотренных выше. Новым элементом семейства MPEG стал
интерфейс описаний мультмедийного материала, называемый "Multimedia Content
Description Interface" (или сокращенно MPEG-7), целью которого явилась
стандартизация базовых технологий, позволяющих описание аудио-визуальных данных
в рамках мультимедийной среды.
Аудиовизуальный материал MPEG-7 может включать
в себя: статические изображения, графику, 3D модели, звук, голос, видео и
композитную информацию о том, как эти элементы комбинируются при мультимедийной
презентации. В особых случаях этих общих видов данных сюда может включаться
выражения лица и частные характеристики личности.
Средства описаний MPEG-7 однако не зависят
от способа кодирования и записи материала. Можно сформировать описание MPEG-7
аналогового фильма или картинки, которая напечатана на бумаге, точно также, как
и цифрового материала. MPEG-7, как и другие объекты семейства MPEG, предоставляют стандартное представление аудио-визуальных данных, удовлетворяющих определенным требованиям. Одной из функций стандарта MPEG-7 является обеспечение ссылок на определенные части мультимедийного материала. Например, дескриптор формы, используемый в MPEG-4, может оказаться полезным в контексте MPEG-7, точно также Это может относиться к полям вектора перемещения, используемым в MPEG-1 и MPEG-2. В своих описаниях MPEG-7 допускает различную гранулярность, предлагая возможность существования различных уровней дискриминации. Хотя описание MPEG-7 не зависит от кодового представления материала, он может использовать преимущества, предоставляемые кодированным материалом MPEG-4. Если материал кодирован с использованием MPEG-4, который предоставляет средства кодирования аудио-визуального материала, в виде объектов, имеющих определенные связи во времени (синхронизация) и в пространстве (на сцене для видео или в комнате для аудио), будет возможно связать описания с элементами (объектами) в пределах сцены, такими как аудио и видео объекты. Так как описательные характеристики должны иметь смысл в контексте приложения, они будут различными для разных приложений. Это подразумевает, что один и тот же материал может быть описан различным образом в зависимости от конкретного приложения. Возьмем в качестве примера визуальный материал: нижним уровнем абстракции будет описание, например, формы, размера, текстуры, цвета, движения (траектории) и позиции ("где на сцене может размещаться объект"). А для аудио: ключ, тональность, темп, вариации темпа, положение в звуковом пространстве. Высшим уровнем представления будет семантическая информация: "Это сцена с лающей коричневой собакой слева и голубым мячом, падающим справа, с фоновым звуком проезжающих авто". Могут существовать промежуточные уровни абстракции. Уровень абстракции относится к способу выделения определенных характеристик: многие характеристики нижнего уровня могут быть выделены полностью автоматически, в то время как характеристики высокого уровня требуют большего взаимодействия с человеком. Кроме описания материала, требуется также включить другие виды информации о мультимедийных данных:
Во многих случаях будет желательно использовать
для описания текстовые данные. Необходимо позаботиться о том, чтобы полезность
описаний была независима по возможности от языка. Хорошим примером
текстуального описания является указания авторов, названия фильма и пр.
Следовательно, средства MPEG-7 позволят
формировать описания (т.e., наборы схем описания и соответствующих дескрипторов
по желанию пользователя) материала, который может содержать:
Все эти описания являются, конечно,
эффективно закодированными для поиска, отбора и т.д.
Чтобы удовлетворить этому многообразию
дополнительных описаний материала, MPEG-7 осуществляет описание материала с
нескольких точек зрения. Наборы средств описаний, разработанные с учетом этих
точек зрения, представляются в виде отдельных объектов. Однако они
взаимосвязаны и могут комбинироваться множеством способов. В зависимости от
приложения, некоторые будут присутствовать, а другие отсутствовать, а могут
присутствовать лишь частично. Описание, сформированное с помощью средств MPEG-7, будет ассоциировано с самим материалом, чтобы позволить быстрый и эффективный поиск и фильтрацию материала, представляющего интерес для пользователя.
Данные MPEG-7 могут физически размещаться
вместе с ассоциированным AВ-материалом, в том же информационном потоке или в
той же системе памяти, но описания могут также размещаться на другом конце света.
Когда материал и его описания размещены не совместно, необходим механизм для
соединения AВ-материала и его описаний MPEG-7; эти связи должны работать в
обоих направлениях.
Тип материала и запрос могут не совпадать;
например, визуальный материал может быть запрошен, используя визуальное
содержимое, музыка, голос, и т.д. Согласование данных запроса и описания MPEG-7
выполняется поисковыми системами и агентами фильтрации.
MPEG-7 относится ко многим различным
приложениям в самых разных средах. Этот стандарт должен обеспечивать гибкую и
масштабируемую схему описания аудио-визуальных данных. Следовательно, MPEG-7 не
определяет монолитную систему описания материала, а предлагает набор методов и
средств для различных подходов описания аудио-визуального материала. MPEG-7
сконструирован так, чтобы учесть все подходы, учитывающие требования основных
стандартов, таких как, SMPTE Metadata Dictionary, Dublin Cилиe, EBU P/Meta, и
TV Anytime. Эти стандарты ориентированы на специфические приложения и области
применения, в то время как MPEG-7 пытается быть как можно более универсальным.
MPEG-7 использует также схему XML в качестве языка выбора текстуального
представления описания материала. Главными элементами стандарта MPEG-7
являются:
1.3. Область действия
стандарта
MPEG-7 относится к приложениям, которые
могут осуществлять запись (или реализовать поточную передачу, например,
производить широковещательную пересылку в Интернет), и могут работать как в
реальном времени так и off-line. 'Среда реального времени' в данном контексте
означает, что описание генерируется в процессе приема материала.
На рис. 1 показана блок-схема системы
обработки данных MPEG-7. Чтобы полностью использовать возможности описаний
MPEG-7, автоматическое извлечение характеристик (или 'дескрипторов') может
оказаться особенно заметным. Ясно также, что автоматическое извлечение не
всегда возможно. Как было указано выше, чем выше уровень абстракции, тем
труднее автоматическое извлечение характеристик, и тем полезнее интерактивные
средства.
Рис.
1. Область MPEG-7.
Чтобы улучшить понимание терминологии
введенной выше (т.e. дескриптор, схема описания и DDL),
рассмотрите рис.2 и рис. 3.
Рис.
2. Взаимодействие различных элементов MPEG-7
На рис. 2 продемонстрирована
масштабируемость рассмотренной концепции. Более того, там показано, что DDL
предоставляет механизм построения схемы описания, которая в свою очередь
образует основу для формирования описания (см. также рис. 3).
Рис.
3. Абстрактное представление возможных приложений на основе MPEG-7
Овалами обозначены средства, которые
выполняют операции, такие как кодирование или декодирование, в то время как
прямоугольниками отмечены статические элементы, такие как описания. Пунктирные
прямоугольники на рисунке окружают нормативные элементы стандарта MPEG-7.
Главной задачей MPEG-7 будет предоставление
новых решений для описания аудио-визуального материала. Таким образом, чисто
текстовые документы не являются объектами MPEG-7. Однако аудио-визуальный
материал может содержать и сопряженный с ним текст. MPEG-7 будет,
следовательно, рассматривать и поддерживать существующие решения, разработанные
другими организациями стандартизации для текстовых документов.
Помимо самих дескрипторов на рабочие
характеристики системы довольно сильно влияют DB-структуры. Чтобы быстро
решить, представляет ли данный материал какой-то интерес, нужно структурировать
индексную информацию, например, иерархическим или ассоциативным способом.
1.4. Область применения
MPEG-7
Элементы, которые стандартизует MPEG-7,
будут поддерживать широкий диапазон приложений (например, мультимедийные
цифровые библиотеки, выбор широковещательного медийного материала,
мультимедийное редактирование, домашние устройства для развлечений и т.д.).
MPEG-7 сделает возможным мультимедийный поиск в WEB столь же простым, как и
текстовый. Это станет применимо для огромных архивов, которые станут доступны
для широкой публики, это придаст новый стимул для электронной торговли, так как
покупатели смогут искать нужный товар по видеообразцам. Информация,
используемая для извлечения материала, может также применяться агентами
для отбора и фильтрации широковещательного материала или целевой рекламы. Кроме
того, описания MPEG-7 позволят быстрые и эффективные с точки зрения затрат
полуавтоматические презентации и редактирование.
Все области применения, базирующиеся на
мультимедиа, выиграют от использования MPEG-7. Ниже предлагается список
возможных приложений MPEG-7, которые любой из читателей без труда сможет
дополнить:
В принципе, любой тип аудио-визуального
материала может быть получен с помощью любой разновидности материала в запросе.
Это означает, например, что видео материал может быть запрошен с помощью видео,
музыки, голоса и т.д. Ниже приведены примеры запросов:
1.5. План и метод работы
Метод разработки совместим с тем, что
регламентировано в предыдущих стандартах MPEG. Работа над MPEG обычно
выполнялась в три этапа: определение, соревнование и сотрудничество. На первой
фазе определяется область действия и требования, предъявляемые к стандарту
MPEG-7. На следующем этапе участники работают над различными технологиями
самостоятельно. Результатом этого этапа является выработка документа CfP (Call
for Proposals). В разработке стандарта участвовало около 60 коллективов, было
получено 400 предложений.
Выбранные элементы различных предложений на
завершающей фазе инкорпорированы в общую модель (eXperimentation Model или XM)
стандарта. Целью являлось построение наилучшей модели, которая по существу
представляла собой проект стандарта. На завершающей фазе, XM последовательно
актуализовалась до тех пор, пока MPEG-7 в октябре 2000 года не достиг уровня CD
(Committee Draft). Дальнейшее усовершенствование XM осуществлялось посредством
базовых экспериментов (CE - Core Experiments). CE призваны протестировать
существующие средства с учетом новых возможностей и предложений. Наконец все
части XM (или рабочего проекта), которые соответствуют нормативным элементам
MPEG-7, были стандартизованы.
1.6. Части MPEG-7
Стандарт MPEG-7 состоит из следующих частей:
1.7. Структура документа
Данный обзорный документ делится на 4 части,
не считая введения и приложений. Каждая часть делится на несколько секций,
характеризующих различные стороны MPEG-7 [2].
2. Главные функции
MPEG-7
Системы MPEG-7 будут включать в себя
средства, которые необходимы для подготовки описаний MPEG-7 для эффективной
транспортировки и запоминания, а также позволяют синхронизовать мультимедийный
материал и описания и средства, сопряженные с управлением и защитой интеллектуальной
собственности. Стандарт определяет архитектуру терминала и нормативных
интерфейсов.
2.2. Язык описания
определений MPEG-7
Согласно определению в MPEG-7 язык описания
определений DDL (Description Definition Language) представляет собой:
"... язык, который позволяет формировать
новые схемы описания и, возможно, дескрипторы. Он также позволяет
расширение и модификацию существующих схем описания".
В качестве основы DDL был выбран язык XML.
Как следствие, DDL может быть поделен на следующие логические нормативные
компоненты:
-Структурная схема языковых компонентов XML;
2.3. Аудио MPEG-7
Окончательный проект аудио MPEG-7
представляет шесть технологий: система аудио описаний (которая включает в себя
дерево шкал и низкоуровневые дескрипторы), средства описания звуковых эффектов,
средства описания тембра инструмента, описание голосового материала, сегмент
молчания и дескрипторы мелодии, облегчающие обработку запросов.
2.4. Визуальный MPEG-7
Средства визуального описания MPEG-7,
включенные в CD/XM состоят из базовых структур и дескрипторов, которые
характеризуют следующие визуальные характеристики:
Каждая категория состоит из элементарных и
сложных дескрипторов.
2.5. Основные объекты и
схемы описания мультимедиа MPEG-7
Базисом схем описания мультимедиа MDS
(Multimedia Description Schemes) является стандартизация набора средств
описания (дескрипторы и схемы описания), имеющие дело с общими и
мультимедийными объектами.
Общими объектами являются характеристики,
которые используются в аудио, видео и текстовых описаниях и, следовательно,
характеризуют все медийные типы материала. Такими характеристиками могут быть,
например, вектор, время и т.д.
Помимо этого набора общих средств описания
стандартизованы более сложные средства описания. Они используются, когда нужно
описать более одного вида медийного материала (например, аудио и видео). Эти
средства описания могут быть сгруппированы в 5 различных классов согласно их
функциональному предназначению:
2.6. Эталонные программы
MPEG-7: модель экспериментов (eXperimentation Model)
Программное обеспечение модели XM
(eXperimentation Model) представляет собой систему моделирования для дескрипторов
MPEG-7 (D), схем описания (DS), схем кодирования (CS), языка описания
определений (DDL). Кроме нормативных компонентов, системе моделирования
необходимы некоторые дополнительные элементы, существенные при исполнении
некоторых процедурных программ. Структуры данных и процедурные программы
образуют приложения. Приложения XM образуют две разновидности: приложения
клиента и сервера.
3. Детальное техническое
описание стандарта MPEG-7
Системы MPEG-7 в настоящее время определяет
архитектуру терминала и нормативных интерфейсов.
3.1.1. Архитектура
терминала
Представление информации, специфицированное
в стандарте MPEG-7 предоставляет средства описаний кодированного
мультимедийного материала. Объект, который использует такое кодовое
представление мультимедийного материала, называется "терминалом". Этот
терминал может соответствовать отдельно стоящему приложению или быть целой
прикладной системой. Архитектура такого терминала изображена на рис. 4, а его
работа описана ниже.
Рис.
4. Архитектура MPEG-7
В нижней части рис. 4 размещена система
передачи/записи. Это относится к нижнему уровню инфраструктуры доставки
(сетевой уровень и ниже). Эти уровни передают мультиплексированные потоки
данных уровню доставки. Транспортная среда MPEG-7 базируется на многих системах
доставки данных. Это включает, например, транспортные потоки MPEG-2, IP или
MPEG-4 (MP4) файлы или потоки. Уровень доставки реализует механизмы,
позволяющие выполнять синхронизацию, формирование кадров и мультиплексирование
материала MPEG-7. Материал MPEG-7 может быть доставлен независимо или вместе с
данными, которые он описывает. Архитектура MPEG-7 позволяет передавать данные
(например, запросы) назад из терминала к отправителю или серверу.
Уровень доставки предоставляет уровню сжатия
MPEG-7 элементарные потоки. Элементарные потоки MPEG-7 состоят из
последовательности индивидуально доступных порций данных, называемых блоками
доступа (Access Units). Блок доступа является наименьшим информационным объектом,
к которому может относиться временная информация. Элементарные потоки MPEG-7
содержат данные различной природы:
Уровень доставки приложения может также по
запросу доставлять мультимедийный материал. Для этих целей могут использоваться
существующие средства доставки.
Данные MPEG-7 могут быть представлены либо в
текстовом, либо в двоичном формате, или в виде комбинации этих форматов, в
зависимости от типа приложения. MPEG-7 определяет однозначную связь между
двоичным и текстовым форматами. Возможно установление двухсторонней однозначной
связи между текстовым и двоичным представлениями. Следует заметить, что это не
всегда доступно: некоторые приложения могут не захотеть передавать всю
информация, содержащуюся в текстовом представлении, а могут предпочесть
использовать более эффективную с точки зрения полосы двоичную кодировку с
потерями.
Синтаксис текстуального формата определен в
части 2 (DDL - Description Definition Language) стандарта. Синтаксис двоичного
формата (BiM - двоичный формат для данных MPEG-7) определен в части 1 (системы)
стандарта. Схемы определены в частях 3, 4 и 5 (визуальная, аудио и схемы
описания мультимедиа) стандарта.
На уровне компрессии, производится разборка
потока блоков доступа (текстуальных или двоичных), а описания материала
реконструируются. MPEG-7 не перепоручает реконструкцию текстуального
представления в качестве промежуточного шага декодирующему процессу. Двоичный
поток MPEG-7 может быть разобран с помощью BiM, передан в текстовом формате и
затем в этом виде транспортирован для последующей реконструкционной обработки,
или двоичный поток может быть разобран BiM и затем передан в подходящем формате
для последующей обработки.
Блоки доступа MPEG-7 далее структурируются
как команды, в которые инкапсулированы схемы описания. Команды придают
материалу MPEG-7 динамический вид. Они позволяют пересылать описания одним
куском или в виде небольших фрагментов. Команды делают возможными базовые
операции с материалом MPEG-7, такие как актуализация дескриптора, удаление
части описания или добавление новой структуры DDL. На реконструкционном этапе
уровня компрессии выполняется актуализация описания и соответствующих схем
посредством указанных команд.
3.1.2. Нормативные
интерфейсы
MPEG-7 имеет два нормативных интерфейса, как
это показано на рис. 5.
Рис.
5. Нормативные интерфейсы MPEG-7
3.1.2.2. Верификация стандарта
В данном разделе описывается, как
проверяется то, что двоичное и текстуальное представление являются адекватными
одному и тому же материалу. Этот процесс описан на рис. 6.
Рис.
6 - Процесс верификации
Кроме элементов описанных в разделе 3.1.2.1,
процесс валидации включает определение канонического представления описания
материала. В каноническом пространстве, описания материала могут быть сравнены.
Процесс валидации работает следующим образом:
Описание канонической презентации
XML-документа определено в Canonical XML[3].
3.2. Язык описания
определений MPEG-7 (DDL)
Главными средствами, используемыми в
описаниях MPEG-7 являются DDL (Description Definition Language), схемы описаний
(DS) и дескрипторы (D). Дескрипторы связывают характеристики с набором их
значений. Схемы описания являются моделями мультимедийных объектов и всего
многообразия элементов, которые они представляют, например, модели данных
описания. Они специфицируют типы дескрипторов, которые могут быть использованы
в данном описании, и взаимоотношения между этими дескрипторами или между
данными схемами описания.
DDL образует центральную часть стандарта
MPEG-7. Он обеспечивает надежную описательную основу, с помощью которой
пользователь может создать свои собственные схемы описания и дескрипторы.
DDL определяет семантические правила выражения и комбинации схем описания и
дескрипторов.
DDL не является языком моделирования, таким
как UML (Unified Modeling Language), а языком схем для представления
результатов моделирования аудио-визуальных данных, например, DS и D.
DDL должен удовлетворять требованиям MPEG-7
DDL. Он должен быть способен выражать пространственные, временные, структурные
и концептуальные взаимоотношения между элементами DS и между DS. Он должен
предоставить универсальную модель для связей и ссылок между одним или более
описаниями и данными, которые им описываются. Кроме того, язык не должен
зависеть от платформы и приложения и быть читаемым как машиной, так и человеком.
MPEG-7 должен базироваться на синтаксисе XML. Необходима также система разборки
DDL (парсинга), которая должна быть способна проверять схемы описания (материал
и структуру) и дескрипторы типа данных, как примитивные (целые, текст, дата,
время) так и составные (гистограммы, нумерованные типы).
3.2.1. Разработка
контекста
Так как схемный язык XML не был специально
разработан для аудио-визуального материала, необходимы определенные расширения,
для того чтобы удовлетворить всем требованиям MPEG-7 DDL.
3.2.2. Обзор схемы XML
Целью схемы является определение класса
XML-документов путем использования конкретных конструкций, чтобы наложить
определенные ограничения на их структуру: элементы и их содержимое, атрибуты и
их значения, количество элементов и типы данных. Схемы можно рассматривать, как
некоторые дополнительные ограничения на DTD.
Главной рекомендацией MPEG-7 AHG было
использование схемы, базирующейся на XML. В начале разработки имелось много
решений, но ни одно из них не оказалось достаточно стабильным. В исходный
момент группа DDL решила разработать свой собственный язык, следуя принципам,
используемым группой W3C при подготовке схемы XML. В апреле 2000, рабочая
группа W3C XML опубликовала последнюю версию спецификации схемы XML 1.0.
Улучшенная стабильность схемного языка XML, его потенциально широкое поле
применения, доступность средств и программ разборки, а также его способность
удовлетворить большинству требований MPEG-7, привели к тому, что схема XML
явилась основой DDL. Однако так как схема XML не была разработана специально
для аудио-визуального материала, необходимы некоторые специфические расширения.
DDL делится на следующие логические нормативные компоненты:
3.2.3. Схема XML:
Структуры
Схема XML: Структуры являются частью
2-частной спецификации XML-схемы. Она предоставляет средства для описания
структуры и ограничений, налагаемых на материалы документов XML 1.0. Схема XML
состоит из набора компонентов структурной схемы, которые могут быть разделены
на три группы. Первичными компонентами являются:
Вторичными компонентами являются:
Третья группа образована компонентами
"helper", которые входят в другие компоненты и не могут существовать отдельно:
Определения типа задают внутренние
компоненты схемы, которые могут использоваться в других компонентах, таких как
элементы, атрибуты деклараций или другие определения типа. Схема XML
предоставляет два вида компонентов определения типа:
Новые типы могут быть также определены на
основе существующих типов (встроенных или вторичных) путем расширения базового
типа. Детали использования этих компонентов можно
найти в проекте DDL или в схеме XML: Спецификация структур.
3.2.4. Схема XML: Типы
данных
XML Schema:Datatypes является второй частью
2-частной схемной спецификации XML. Она предлагает возможности определения
типов данных, которые могут быть использованы для ограничения свойств типов
данных элементов и атрибутов в рамках схем XML. Она предлагает более высокую
степень проверки типа, чем доступна для XML 1.0 DTD:
Подробные детали встроенных типов данных и
механизмы получения вторичных типов можно найти в окончательном проекте DDL или
в спецификации XML Schema:Datatypes.
3.2.5. Расширения схемы
XML MPEG-7
Следующие характеристики будет нужно
добавить к спецификации языка XML для того, чтобы удовлетворить специфическим
требованиям MPEG-7:
Программы разборки, специфические для MPEG-7
будут разработаны путем добавления валидации этих дополнительных конструкций к
стандартным схемным разборщикам XML.
3.3. Аудио MPEG-7
Аудио MPEG-7 FCD включает в себя пять
технологий: структура аудио описания (которая включает в себя масштабируемые
последовательности, дескрипторы нижнего уровня и униформные сегменты тишины),
средства описания тембра музыкального инструмента, средства распознавания
звука, средства описания голосового материала и средства описания мелодии.
3.3.1. Описание системы
аудио MPEG-7
Аудио структура содержит средства нижнего
уровня, созданные для обеспечения основы для формирования аудио приложений
высокого уровня. Предоставляя общую платформу структуры описаний, MPEG-7 Аудио
устанавливает базис для совместимости всех приложений, которые могут быть
созданы в рамках данной системы.
Существует два способа описания аудио
характеристик нижнего уровня. Один предполагает стробирование уровня сигнала на
регулярной основе, другой может использовать сегменты (смотри описание MDS) для
пометки сходных и отличных областей для заданного звукового отрывка. Обе эти
возможности реализованы в двух типах дескрипторов нижнего уровня (один для
скалярных величин, таких как мощность или частота, и один для векторов, таких
как спектры), которые создают совместимый интерфейс. Любой дескриптор,
воспринимающий эти типы может быть проиллюстрирован примерами, описывающими
сегмент одной результирующей величиной или последовательностью результатов
стробирования, как этого требует приложение.
Величины, полученные в результате
стробирования, сами могут подвергаться последующей обработке с привлечением
другого унифицированного интерфейса: они могут образовать масштабируемые ряды
(Scalable Series). Дерево шкал может также хранить различные сводные значения,
такие как минимальное, максимальное значение дескриптора и его дисперсию.
Аудио дескрипторы нижнего уровня имеют
особую важность при описании звука. Существует семнадцать временных и
пространственных дескрипторов, которые могут использоваться в самых разных
приложениях. Они могут быть грубо поделены на следующие группы:
Каждый из них может использоваться для
описания сегмента с результирующим значением, которое применяется для всего
сегмента или для последовательности результатов стробирования. Временная группа
по тембру (Timbral Temporal) является исключением, так как ее значения
приложимы только к сегменту, как целому.
В то время как аудио дескрипторы нижнего
уровня вообще могут служить для многих возможных приложений, дескриптор
однородности спектра поддерживает аппроксимацию сложных звуковых сигналов.
Приложения включают в себя голосовую идентификацию.
Кроме того, очень простым, но полезным
средством является дескриптор тишины. Он использует простую семантику
"тишины" (то есть отсутствие значимого звука) для аудио сегмента.
Такой дескриптор может служить для целей дальнейшей сегментации аудио потока.
3.3.2. Средства описания
аудио верхнего уровня (D и DS)
Четыре набора средств описания аудио,
которые приблизительно представляют области приложения, интегрированы в FCD:
распознавание звука, тембр музыкального инструмента, разговорный материал и
мелодическая линия.
3.3.2.1. Средства описания тембра
музыкальных инструментов
Дескрипторы тембра служат для описания
характеристик восприятия звуков. Тембр в настоящее время определен в литературе
как характеристика восприятия, которая заставляет два звука, имеющих одну
высоту и громкость, восприниматься по-разному. Целью средства описания тембра
является представление этих характеристик восприятия сокращенным набором
дескрипторов. Дескрипторы относятся к таким понятиям как "атака", "яркость" или
"богатство" звука.
В рамках четырех возможных классов звуков
музыкальных инструментов, два класса хорошо детализированы, и являются
центральным объектом экспериментального исследования. В FCD представляются
гармонические, когерентные непрерывные звуки и прерывистые, ударные звуки.
Дескриптор тембра для непрерывных гармонических звуков объединяет спектральные
дескрипторы тембра с временным дескриптором log attack. Дескриптор
ударных инструментов комбинирует временные дескрипторы тембра с дескриптором спектрального
центроида. Сравнение описаний, использующих один из наборов дескрипторов
выполняется с привлечением метрики масштабируемого расстояния.
3.3.2.2. Средства распознавания звука
Схемы дескрипторов и описаний распознавания
звука, представляют собой наборы средств для индексирования и категорирования
звуков, с немедленным использованием для звуковых эффектов. Добавлена также
поддержка автоматической идентификации звука и индексация. Это сделано для
систематики звуковых классов и средств для спецификации онтологии устройств
распознавания звука. Такие устройства могут использоваться для автоматической
индексации сегментов звуковых треков.
Средства распознавания используют в качестве
основы спектральные базисные дескрипторы низкого уровня. Эти базисные функции
далее сегментируются и преобразуются в последовательность состояний, которые
заключают в себя статистическую модель, такую как смешанная модель Маркова или
Гаусса. Эта модель может зависеть от своего собственного представления, иметь
метку, ассоциированную с семантикой исходного звука, и/или с другими моделями
для того, чтобы категоризовать новые входные звуковые сигналы для системы
распознавания.
3.3.2.3. Средства описания содержимого
сказанного
Средства описания Spoken Content
позволяет детальное описание произнесенных слов в пределах аудио-потока.
Учитывая тот факт, что сегодняшнее автоматическое распознавание речи
ASR-технологий (Automatic Speech Recognition) имеет свои ограничения, и что
всегда можно столкнуться с высказыванием, которого нет в словаре, средства
описания Spoken Content жертвует некоторой компактностью ради надежности
поиска. Чтобы этого добиться, средства отображают выходной поток и то, что в
норме может быть видно в качестве текущего результата автоматического
распознавания речи ASR. Средства могут использоваться для двух широких классов
сценария поиска: индексирование и выделение аудио потока, а также
индексирование мультимедийных объектов аннотированных голосом.
Средства описания Spoken Content поделены на
два широких функциональных блока: сетка, которая представляет декодирование,
выполненное системой ASR, и заголовок, который содержит информацию об узнанных
собеседниках и о самой системе распознавания. Сетка состоит из комбинаций слов
голосовых записей для каждого собеседника в аудио потоке. Комбинируя эти сетки,
можно облегчить проблему со словами, отсутствующими в словаре, и поиск может
быть успешным, даже когда распознавание исходного слова невозможно.
3.3.2.4. Средства описания мелодии
DS мелодического очертания (Melody
Contour) является компактным представлением информации о мелодии, которая
позволяет эффективно и надежно контролировать мелодическую идентичность,
например, в запросах с помощью наигрывания. DS мелодического очертания
использует 5-ступенчатый контур (представляющий интервал между смежными
нотами), в котором интервалы дискретизированы. DS мелодического очертания
(Melody Contour DS) предоставляет также базовую информацию ритмики путем
запоминания частот, ближайших к каждой из нот, это может существенно увеличить точность
проверки соответствия запросу.
Для приложений, требующих большей
описательной точности или реконструкции заданной мелодии, DS мелодии
поддерживает расширенный набор дескрипторов и высокую точность кодирования
интервалов. Вместо привязки к одному из пяти уровней в точных измерителях
используется существенно больше уровней между нотами (100 и более). Точная
информация о ритмике получается путем кодирования логарифмического отношения
разностей между началами нот способом аналогичным с используемым для
кодирования уровней сигнала.
3.4. Визуальный MPEG-7
Средства визуального описания MPEG-7,
включенные в CD/XM состоят из базовых структур и дескрипторов, которые
охватывают следующие основные визуальные характеристики:
Каждая категория состоит из элементарных и
составных дескрипторов.
3.4.1. Базовые структуры
Существует пять визуально связанных базовых
структур: сеточная выкладка, временные ряды (Time Series), многопрекционность
(MultiView), пространственные 2D-координаты и временная интерполяция
(TemporalInterpolation).
3.4.1.1. Сеточная выкладка
Сетка делит изображение на равные
прямоугольные области, так что каждая область может быть описана отдельно.
Каждая область сетки описывается посредством других дескрипторов, таких как
цвет или текстура. Более того, дескриптор позволяет ассоциировать
субдескрипторы со всей прямоугольной областью, или с произвольным набором
прямоугольных областей.
3.4.1.2. Многовидовые 2D-3D
Дескриптор 2D/3D специфицирует структуру,
которая комбинирует 2D дескрипторы, представляющие визуальные параметры
3D-объекта, видимые с различных точек. Дескриптор образует полное
3D-представление объекта на основе его проекций. Может использоваться любой визуальный
2D-дескриптор, такой как, например, форма контура, форма области, цвет или
текстура. Дескриптор 2D/3D поддерживает интеграцию 2D-дескрипторов,
используемых в плоскости изображения для описания характеристик 3D-объектов
(реальный мир). Дескриптор позволяет осуществлять сравнение 3D-объектов путем
сравнения их проекций.
3.4.1.3. Временные ряды
Этот дескриптор определяет в видео сегменте
дескрипторы временных рядов и предоставляет возможность сравнения изображения с
видео-кадром и видео-кадров друг с другом. Доступно два типа временных рядов
(TimeSeries): RegularTimeSeries и IrregularTimeSeries. В первом, дескрипторы
размещаются регулярным образом (с постоянным шагом) в пределах заданного
временного интервала. Это допускает простое представление для приложений,
которые предполагают ограниченную сложность. Во втором, дескрипторы размещаются
нерегулярно (с переменными интервалами) в пределах заданного временного
интервала. Это обеспечивает эффективное представление для приложений, которые
требуют малой полосы пропускания или малой емкости памяти. Они полезны в
частности для построения дескрипторов, которые содержат временные ряды
дескрипторов.
3.4.1.4. Пространственные координаты 2D
Это описание определяет 2D пространственную
координатную систему, которую следует использовать в других D/DS, где это
важно. Оно поддерживает два вида координатных систем: "локальную" и
"интегрированную" (рис. 7). В "локальной" координатной системе, все изображения
привязаны к одной точке. В "интегрированной" координатной системе, каждое
изображение (кадр) может быть привязано к разным областям. Интегрированная
координатная система может использоваться для представления координат на
мозаичном видео снимке.
a) "Локальные" координаты b)
"интегрированные" координаты
Рис.
7. "Локальная" и "интегрированная" координатная система
3.4.1.5. Временная интерполяция
TemporalInterpolation D описывает временную
интерполяцию, использующую связанные многогранники. Это может использоваться
для аппроксимации многомерных значений переменных, которые меняются со
временем, такие как положение объекта в видео. Размер описания временной
интерполяции обычно много меньше, чем описание всех величин. На рис. 8 25
реальных величин представлены пятью линейными интерполяционными функциями и
двумя квадратичными интерполяционными функциями. Начало временной интерполяции
всегда привязывается ко времени 0.
Рис.
8. Реальные данные и функции интерполяции
3.4.2. Описатели цвета
Существует восемь дескрипторов цвета:
цветового пространства, доминантных цветов, цветовой дискретизации, GoF/GoP
цвета, цветовой структуры, цветового размещения и масштабируемой гистограммы
цветов.
3.4.2.1. Цветовое пространство
Понятие цветового пространства используется
в других описаниях, базирующихся на цвете. В текущем описании, поддерживаются
следующие цветовые пространства:
3.4.2.2. Оцифровка цвета
Этот дескриптор определяет дискретизацию
цветового пространства и поддерживает линейные и нелинейные преобразователи, а
также lookup-таблицы. Число уровней квантования конфигурируемо так, чтобы
обеспечить большую гибкость для широкого диапазона приложений. В случае
нелинейного АЦП, ширина канала преобразования может также конфигурироваться.
Для разумных приложений в контексте MPEG-7, этот дескриптор должен
комбинироваться с другими, например, чтобы характеризовать значения в цветовой
гистограмме.
3.4.2.3. Доминантный цвет(а)
Этот дескриптор цвета является наиболее
удобным для представления локальных характеристик (области объекта или
изображения), где для предоставления цветовой информации достаточно малого
числа цветов. Могут использоваться и полные изображения, например, картинки
флагов или цветных торговых марок. Квантование цвета используется для получения
малого числа характерных цветов в каждой области/изображении. Соответственно
вычисляется процент каждого дискретизируемого цвета в области. Определяется
также пространственная когерентность всего дескриптора.
3.4.2.4. Масштабируемый цвет
Дескриптор масштабируемого цвета (Scalable
Color) является гистограммой цветов в цветном пространстве HSV, которая
кодируется с помощью преобразования Хара. Ее двоичное представление является
масштабируемым с точки зрения числа каналов и числа бит, характеризующих
значение точности в широком диапазоне потоков данных. Дескриптор
масштабируемого цвета полезен для сравнения изображений и поиска, базирующегося
на цветовых характеристиках. Точность отображения возрастает с увеличением
числа бит, используемых для описания.
3.4.2.5. Описатель структуры цвета
Дескриптор цветовая структура (Color
Structure) является описателем цветовой характеристики, которая объединяет
цветовое содержимое (аналогично цветовой гистограмме) и информацию о структуре
материала. Его главная задача сравнение изображений главным образом для
статических картинок. Метод выборки вводит данные о цветовой структуре в
дескриптор, учитывая локально цвета окрестных пикселей, и не анализирует каждый
пиксель отдельно. Дескриптор цветовая структура обеспечивает
дополнительную функциональность и улучшенный поиск, базирующийся на подобии
естественных изображений.
3.4.2.6. Выкладка цвета
Этот дескриптор специфицирует пространственное
распределение цветов для быстрого поиска и просмотра. Его целью является не
только сравнение изображений и видео клипов, но также поиск, базирующийся на
раскладке цветов, такой как сравнение наброска с изображением, которое не
поддерживается другими цветовыми дескрипторами. Этот дескриптор может
использоваться для всего изображения или для любой его части. Данный дескриптор
может также быть применен для областей произвольной формы.
3.4.2.7. Цвет GoF/GoP
Дескриптор цвета группа_кадров/группа_картинок
расширяет возможности дескриптора масштабируемого цвета, который определен для
статических изображений, чтобы выполнять цветовое описание видео сегментов или
собрания статических изображений. Дополнительные два бита позволяют определить,
была ли вычислена цветовая гистограмма, прежде чем было осуществлено
преобразование Хара: для усреднения, медианы или пересечения. Усредненная
гистограмма, которая соответствует усредненному значению счетчика для каждой
ячейки всех кадров или изображений, эквивалентна вычислению совокупной цветовой
гистограммы всех кадров или изображений с последующей нормализацией. Медианная
гистограмма соответствует вычислению медианного значения счетчика для каждой
ячейки совокупности кадров или изображений. Более надежно округлять ошибки и
присутствие выбросов в распределении яркости изображения по сравнению с
усредненной гистограммой. Гистограмма пересечения соответствует вычислению
минимального значения счетчика для каждой ячейки совокупности кадров или
изображений, чтобы получить цветовые характеристики "наименьшего общего" группы
изображений. Заметим, что это отличается от гистограммы пересечения, которая
является скалярной мерой. Аналогичные меры сходства/различия, которые
используются для сравнения масштабируемых цветовых описаний, могут быть
применены для сопоставления цветовых дескрипторов GoF/GoP.
3.4.3. Описатели
текстуры
Существует три текстурных дескриптора: Edge
Histogram, Homogeneous Texture и Texture Browsing.
3.4.3.1. Описатели однородной текстуры
Однородная текстура представляет собой
важный визуальный примитив для поиска и просмотра большой коллекции выглядящих
сходно образов. Изображение может рассматриваться как мозаика однородных
текстур, так что эти текстурные характеристики, соответствующие областям могут
использоваться для индексации визуальных данных. Например, пользователь,
просматривающий абстрактную базу данных изображений, может захотеть
идентифицировать различные блоки в этой коллекции изображений. Блоки с
автомашинами, запаркованными регулярным образом являются хорошим примером
однородного текстурного образца, рассматриваемого с большого расстояния, как
это происходит при аэросъемке. Аналогично, сельскохозяйственные области и
участки растительности являются другим примером однородных текстур, встречающихся
при аэро и спутниковых наблюдениях. Примеры запросов, которые могут
поддерживаться в этом контексте, могут включать в себя "Поиск всех
спутниковых изображений Санта Барбары, которые имеют меньше чем 20% облачного
покрытия" или "Найти растительный участок, который выглядит как эта
область". Чтобы поддерживать такой поиск изображений, необходимо
эффективное представление текстуры. Дескриптор однородной текстуры
предоставляет количественное представление, используя 62 числа (по 8 бит
каждое), которое удобно для поиска сходства. Получение данных осуществляется
следующим образом; изображение сначала обрабатывается посредством набора
фильтров Габора, настроенных на определенные ориентации и масштаб
(смоделированные с помощью функций Габора). Дескриптор однородной текстуры
предоставляет точное количественное описание текстуры, которое может
использоваться для поиска. Вычисление этого дескриптора базируется на
фильтрации.
3.4.3.2. Просмотр текстуры
Дескриптор просмотра текстуры
(Texture Browsing) полезен для представления однородной текстуры в приложениях,
служащих для просмотра, и требует только 12 бит (максимум). Он предоставляет
перцептуальную характеристику текстуры, аналогично человеческому описанию в
терминах регулярности, шероховатости, ориентированности. Вычисление этого
дескриптора осуществляется также как и дескриптора однородной текстуры.
Сначала, изображение фильтруется с помощью набора специально настроенных
фильтров (смоделированных посредством функций Габора); в отфильтрованном
результате идентифицируются два доминантных ориентаций текстуры. Три бита
используются для представления каждой из доминантных ориентаций. За этим
следует анализ проекций отфильтрованного изображения вдоль доминантных
направлений, чтобы определить регулярность (характеризуемую двумя битами) и
загрубленность (2 бита x 2). Этот дескриптор совместно с дескриптором
однородной текстуры предоставляет масштабируемое решение для представления
областей изображения с однородной текстурой.
3.4.3.3. Краевая гистограмма
Дескриптор краевой гистограммы
представляет пространственное распределение пяти типов краев, в частности
четырех ориентированных краев и одного неориентированного. Так как края играют
важную роль для восприятия изображения, данный дескриптор помогает найти
изображения со сходным семантическим значением. Таким образом, он изначально
ориентирован на сравнение изображений (по образцам или наброскам), в
особенности на естественные изображения с нерегулярными краями. В этом
контексте, свойства системы поиска изображения могут быть существенно улучшены,
если дескриптор краевой гистограммы комбинируется с другими дескрипторами,
такими как дескриптор цветовой гистограммы. Кроме того, наилучшие
характеристики системы поиска изображения, учитывая только этот дескриптор,
достигаются путем использования полу-глобальных и глобальных гистограмм,
получаемых непосредственно из дескриптора краевых гистограмм.
3.4.4. Описатели формы
Существует четыре типа дескрипторов формы:
объектная форма, базирующаяся на областях, форма, базирующаяся на контурах,
3D-форма и 2D-3D множественные проекции.
3.4.4.1. Форма, базирующаяся на областях
(Region-Based)
Форма объекта может состоять из одной
области или набора областей, а также некоторых отверстий в объектах, как это
показано на рис 9. Так как дескриптор формы, базирующейся на областях,
использует все пиксели, определяющие форму в пределах кадра, он может описывать
любую форму, то есть не только простые формы с односвязными областями, как на
рис. 9 (a) и (b), но также сложные формы, которые содержат отверстия или
несколько не соединенных областей, как показано на рис. 9 (c), (d) и (e),
соответственно. Дескриптор формы, базирующейся на областях, может не
только эффективно описать столь несхожие формы, но и минимизировать искажения
на границах объекта.
На рис. 9 (g), (h) и (i) показаны очень
схожие изображения чашки. Различия имеются только в форме ручки. Форма (g)
имеет трещину на нижней части ручки, в то время как в (i) ручка не имеет
отверстия. Дескриптор формы, базирующейся на областях, рассматривает (g) и (h)
подобными, но отличными от (i), так как там ручка не имеет отверстия.
Аналогично, на рис. 9(j-l) показана часть видео последовательности, где два
диска постепенно разделяются. С точки зрения дескриптора формы, базирующейся на
областях, эти картинки схожи.
Рис.
9. Примеры различной формы
Заметим, что черный пиксель в пределах
объекта соответствует 1 на изображении, в то время как пиксели белого фона
соответствуют 0.
Дескриптор характеризуется малым размером и
быстрым временем поиска. Размер данных для представления является фиксированным
и равным 17.5 байт.
3.4.4.2. Форма, основанная на контуре
Дескриптор формы, базирующейся на контуре,
получает параметры формы объекта или его контур, извлеченный из описания
областей. Он использует так называемое Curvature Scale-Space представление,
которое воспринимает значимые параметры формы.
Дескриптор формы, базирующейся на контуре
объекта, использует Curvature Scale Space представление контура. Это
представление имеет несколько важных особенностей, в частности:
Некоторые из выше перечисленных свойств
проиллюстрированы на рис. 10, каждый кадр содержит весьма сходные с точки
зрения CSS изображения, основанные на результате действительного поиска в базе
данных MPEG-7.
Рис.
10.
На рис. 10 (a) продемонстрированы свойства
обобщения формы (внешнее сходство различных форм), (b) устойчивость по отношению
к плавному движению (бегущий человек), (c) устойчивость к частичному перекрытию
(хвосты или ноги лошадей)
3.4.4.3. 3D-форма
Рассматривая непрерывное развитие
мультимедийных технологий, виртуальных миров, 3D-материал становится обычным
для современных информационных систем. В большинстве случаев, 3D-информация
представляется в виде сетки многоугольников. Группа MPEG-4, в рамках подгруппы
SNHC, разрабатывала технологии для эффективного кодирования модели 3D-сеток. В
стандарте MPEG-7 необходимы средства для интеллектуального доступа к
3D-информации. Главные приложения MPEG-7 имеют целью поиск, получение и
просмотр баз 3D-данных.
Предлагаемый дескриптор 3D-формы имеет целью
предоставление внутреннего описания формы сеточных 3D-моделей. Он использует
некоторые локальные атрибуты 3D-поверхности.
3.4.5.
Дескрипторы перемещения
Существует четыре дескриптора перемещения:
перемещение камеры, траектория перемещение объекта, параметрическое движение
объекта и двигательная активность.
3.4.5.1. Движение камеры
Этот дескриптор характеризует параметры
перемещения 3-D камеры. Он базируется на информационных параметрах
3-D-перемещения камеры, которые могут быть автоматически получены.
Дескриптор движения камеры поддерживает
следующие стандартные операции с камерой (см. рис. 11): фиксированное
положение, панорамное движение (горизонтальное вращение), слежение за
движущимся объектом (горизонтальное поперечное перемещение), вертикальное
вращение, вертикальное поперечное перемещение, изменение фокусного расстояния,
наезд (трансфокация вдоль оптической оси) и вращение вокруг оптической оси.
Рис.
11. Перемещения камеры
Отрывок, для которого все кадры
характеризуются определенным типом перемещения камеры, относящееся к одному
виду или нескольким, определяет базовые модули для дескриптора перемещения
камеры. Каждый составляющий блок описывает начальный момент, длительность,
скорость перемещения изображения и увеличение фокусного расстояния (FOE) (или
сокращение фокусного расстояния - FOC). Дескриптор представляет объединение
этих составляющих блоков, он имеет опцию описания смеси типов перемещения
камеры. Смешанный режим воспринимает глобальную информацию о параметрах
перемещения камеры, игнорируя детальные временные данные, путем совместного
описания нескольких типов движения, даже если эти типы перемещения
осуществляются одновременно. С другой стороны, несмешанный режим воспринимает
понятие чистых перемещений и их совмещения на протяжении определенного
временного интервала. Ситуации, когда одновременно реализуется несколько типов
перемещений, описывается, как суперпозиция описаний чистых независимых типов
перемещения. В этом режиме описания, временное окно конкретного элементарного
сегмента может перекрываться с временным окном другого элементарного сегмента.
3.4.5.2. Траектория движения
Траектория движения объекта является простой
характеристикой высокого уровня, определяемая как позиция, во времени и
пространстве, одной репрезентативной точки этого объекта.
Этот дескриптор полезен для поиска материала
в объектно-ориентированных визуальных базах данных. Он также эффективен в
большинстве специальных приложений. В данном контексте с предварительным
знанием ряда параметров, траектория позволяет реализовать некоторые
дополнительные возможности. При наблюдении, могут выдаваться сигналы тревоги,
если траектория воспринимается, как опасная (например, проходит через запретную
зону, движение необычно быстро, и т.д.). В спорте могут распознаваться
специфические действия (например, обмен ударами у сетки). Кроме того, такое
описание позволяет также улучшить обработку данных: для полуавтоматического
редактирования медиа данных, траектория может быть растянута, смещена, и т.д.,
чтобы адаптировать перемещения объекта для любого контекста.
Дескриптор является списком ключевых точек
(x,y,z,t) вместе с набором опционных интерполирующих функций, которые описывают
путь объекта между ключевыми точками, в терминах ускорения. Скорость неявно
известна с помощью спецификации ключевых точек. Ключевые точки специфицируются
путем задания моментов времени или их 2-D или 3-D декартовых координат, в
зависимости от приложения. Интерполирующие функции определены для каждого
компонента x(t), y(t) и z(t) независимо. Некоторые свойства этого представления
перечислены ниже:
3.4.5.3. Параметрическое движение
Модели параметрического движения были
использованы в рамках различных схем анализа и обработки изображения, включая
сегментацию перемещения, оценки глобального перемещения, и отслеживание
объектов. Модели параметрического перемещения использовались уже в MPEG-4, для
оценки перемещения и компенсации. В контексте MPEG-7, перемещение является
крайне важной характеристикой, связанный с пространственно-временной структурой
видео, относящейся к нескольким специфическим MPEG-7 приложениям, таким как
запоминание и поиск в видео базах данных, и для целей анализа гиперсвязей.
Движение является также критической характеристикой для некоторых специфических
приложений, которые уже рассматривались в рамках MPEG-7.
Базовый принцип состоит из описаний движения
объектов в видео последовательности, например, в параметрической 2D-модели. В
частности, аффинные модели включают в себя трансляции, вращения,
масштабирование и их комбинации, планарные модели перспективы делают возможным
учет глобальных деформаций, сопряженных с перспективными проекциями, а
квадратичные модели позволяют описать более сложные движения.
Параметрическая модель ассоциирована с
произвольными фоновыми объектами или объектами переднего плана, определенными
как области (группа пикселей) в изображении в пределах заданного интервала
времени. Таким способом, движение объекта записывается компактным образом в
виде набора из нескольких параметров. Такой подход ведет к очень эффективному
описанию нескольких типов перемещения, включая простые преобразования, вращения
и изменения масштаба, или более сложные перемещения, такие как комбинации
перечисленных выше элементарных перемещений.
Определение подобия характеристик моделей
движения является обязательным для эффективного поиска объектов. Оно также
необходимо для поддержки запросов нижнего уровня, полезно и в запросах верхнего
уровня, таких как "поиск объектов приближающихся к камере ", или для
"объектов, описывающих вращательное движение", или "поиск
объектов, перемещающихся влево", и т.д.
3.4.5.4. Двигательная активность
Просмотр человеком видео или анимационной
последовательности воспринимается как медленная последовательность, быстро протекающий
процесс, последовательность действий и т.д. Дескриптор активности
воспринимает интуитивное понятие 'интенсивность действия' или 'темп действий' в
видео сегменте. Примеры высокой 'активности' включают такие сцены, как 'ведение
счета голов в футбольном матче', 'автомобильные гонки' и т.д. С другой стороны
сцены, типа 'чтение новостей', 'интервью', 'снимок' и т.д. воспринимаются как
кадры низкой активности. Видео материал охватывает диапазон от низкой до
высокой активности, следовательно нам нужен дескриптор, который позволяет нам
точно выражать активность данной видео последовательности/снимка и всесторонне
перекрывать упомянутый выше диапазон. Дескриптор активности полезен для
приложений, таких как видео наблюдение, быстрый просмотр, динамическое видео
резюмирование, информационные запросы и т.д. Например, мы можем замедлить темп
презентации кадров, если дескриптор активности указывает на высокую активность,
так чтобы облегчить просмотр этой активности. Другим примером приложения
является нахождения всех кадров высокой активности в новой видео программе,
которая может рассматриваться как просмотр, так и абстракцию.
3.4.6. Локализация
Этот дескриптор допускает локализацию
областей внутри изображения или кадров путем спецификации их с помощью краткого
и масштабируемого отображения боксов или многогранников.
3.4.6.2. Пространственно-временной
локатор
Локатор описывает пространственно-временные
области в видео последовательности, такой как области движущихся объектов, и
обеспечивает функцию локализации. Главным его приложением является гипермедиа,
где выделенная точка находится внутри объекта. Другим ведущим приложением
является поиск объектов путем проверки, прошел ли объект определенные точки.
Это может использоваться для наблюдения. Дескриптор SpatioTemporalLocator
может описывать как связанные, так и несвязанные области.
Рис.
12. Пространственно-временная область
3.4.7. Прочие
Дескриптор FaceRecognition может
использоваться для получения изображения лиц, которые соответствуют запросу.
Дескриптор представляет проекцию вектора лица на набор базовых векторов,
которые охватывают пространство возможных векторов лица. Набор параметров
FaceRecognition получается из нормализованного изображения лица. Это
нормализованное изображения лица содержит 56 строк с 46 значениями уровня в
каждой строке. Центры двух глаз на каждом изображении лица размещаются на 24-ом
ряду и 16-ой и 31-ой колонке для правого и левого глаз соответственно. Это
нормализованное изображение затем используется для получения одномерного
вектора лица, который состоит из значений яркости пикселей нормализованного
изображения лица, которое получается в результате растрового сканирования,
начинающегося в верхнем левом углу и завершающегося в нижнем правом углу
изображения. Набор параметров FaceRecogniton вычисляется путем проектирования
одномерного вектора лица на пространство, определяемое набором базисных
векторов.
3.5. Схемы описания
мультимедиа MPEG-7
Дескрипторы MPEG-7 сконструированы для
описания следующих типов информации: низкоуровневые аудио-визуальные
характеристики, такие как цвет, текстура, движение, уровень звука и т.д.;
высокоуровневые семантические объекты, события и абстрактные принципы; процессы
управления материалом; информация о системе памяти и т.д. Ожидается, что
большинство дескрипторов, соответствующих низкоуровневым характеристикам будут
извлекаться автоматически, в то время как человеческое вмешательство будет
необходимо для формирования высокоуровневых дескрипторов.
MPEG-7 DS преобразуются в дескрипторы путем
комбинирования индивидуальных дескрипторов а также других DS в рамках более
сложных структур и определения соотношения составляющих дескрипторов и DS. В
MPEG-7 DS категорируются в отношении к аудио или видео областям, или по
отношению к описанию мультимедиа. Например, характерные DS соответствуют
неизменным метаданным, связанным с формированием, производством, использованием
и управлением мультимедиа, а также описанием материала. Обычно мультимедийные
DS относятся ко всем типам мультимедиа, в частности к аудио, видео и текстовым
данным, в то время как специфичные для области дескрипторы, такие как цвет,
текстура, форма, мелодия и т.д., относятся исключительно к аудио или видео областям.
Как в случае дескрипторов, реализация DS может в некоторых вариантах
базироваться на автоматических средствах, но часто требует вмешательства
человека.
3.5.1. Средства
организации MDS
На рис. 13 представлена схема организации
мультимедийных DS MPEG-7 в следующих областях: базовые элементы, описание
материала, управление материалом, организация материала, навигация и доступ,
взаимодействие с пользователем.
Рис.
13. Обзор мультимедийных DS MPEG-7
3.5.1.1. Базовые элементы
Спецификация мультимедийных DS MPEG-7
определяет определенное число схемных средств, которые облегчают формирование и
выкладку описаний MPEG-7. Схемные средства состоят из корневого элемента,
элементов верхнего уровня и средств выкладки (Package Tools). Корневые
элементы, которые являются начальными элементами описания MPEG-7, позволяют
сформировать полные XML-документы и фрагменты описания MPEG-7. Элементы
верхнего уровня, которые позволяют корневым элементам в описании MPEG-7
организовать DS для объектно-ориентированных задач описания, таких как описание
изображения, видео, аудио или аудио-визуальный материал, собрания (коллекции),
пользователи или семантики мира. Созданы пакетные средства для группирования
или ассоциации связанных компонентов DS описаний в каталоги или пакеты. Пакеты
полезны для организационных и передающих структур и типов описательной
информации MPEG-7 для систем поиска и для помощи при просмотре пользователям,
незнакомым с особенностями описаний MPEG-7.
Спецификация мультимедийных DS MPEG-7
определяет также некоторое число базовых элементов, которые используются
повторно в качестве фундаментальной конструкции при определении MPEG-7 DS.
Многие базовые элементы предоставляют специфические типы данных и
математические структуры, такие как вектора и матрицы, которые важны для
описания аудио-визуального материала. Они включаются также в качестве элементов
для связи медиа файлов и локализации сегментов, областей и т.д. Многие базовые
элементы предназначены для специальных нужд описания аудио-визуального
материала, таких как описание времени, мест, людей, индивидуальностей, групп,
организаций, и других текстовых аннотаций. Из-за их важности для описания
аудио-визуального материала, давайте очертим подходы MPEG-7 к описанию
временной информации и текстовых аннотаций:
3.5.1.2. Управление содержимым
MPEG-7 предоставляет также DS для управления
материалом. Эти элементы описывают различные аспекты создания медиа материала,
медиа кодирование, запись, форматы файлов и использование материала.
Функциональность каждого из этих классов DS представлена ниже [5]:
3.5.1.3. Описание содержимого
MPEG-7 предоставляет также DS для описания
материала. Эти элементы описывают структуру (области, видео кадры и аудио
сегменты) и семантику (объекты, события, абстрактные понятия). Функциональность
каждого из классов DS представлена ниже:
3.5.1.4. Навигация и доступ
MPEG-7 предоставляет также DS для облегчения
просмотра и извлечения аудио-визуального материала путем определения резюме,
разделов, составных частей и вариантов аудио-визуального материала.
3.5.1.5. Организация содержимого
MPEG-7 предоставляет также DS для
организации и моделирования собрания аудио-визуального материала, а также его
описания. DS собрания организует коллекцию аудио-визуального материала,
сегментов, событий, и/или объектов. Это позволяет описать каждое собрание как
целое на основе общих характеристик. В частности, для описания значений
атрибутов собрания могут быть специфицированы различные модели и статистики.
3.5.1.6. Интеракция с пользователем
Наконец, последний набор DS MPEG-7 имеет
отношение к взаимодействию с пользователем. DS взаимодействия с
пользователем описывает предпочтения пользователя и историю использования
мультимедийного материала. Это позволяет, например, найти соответствие между
предпочтениями пользователя и описаниями аудио-визуального материала, для того
чтобы облегчить индивидуальный доступ к аудио-визуальному материалу,
презентации и пр.
3.5.2. Управление
содержимым
Средства управления описанием материала
позволяют охарактеризовать жизненный цикл материала.
Материал, охарактеризованный описаниями
MPEG-7, может быть доступным в различных форматах и режимах, с разными схемами
кодирования. Например, концерт может быть записан в двух разных режимах:
звуковом и аудио-визуальном. Каждый из этих режимов может использовать
различное кодирование. Это создает несколько медиа профайлов. Наконец, могут
быть получены несколько копий одного и того же материала. Эти принципы режимов
и профайлов проиллюстрированы на рис 14.
Рис.
14. Модель материала, профайла и копии
Единственной частью описания, которая
зависит от среды записи или формата кодирования является MediaInformation,
описанная в этом разделе. Остальная часть описания MPEG-7 не зависит от
профайлов или копий и, как следствие, может использоваться, чтобы описать все
возможные копии материала.
3.5.2.1. Средства описания среды
Описание среды включает в себя один элемент
верхнего уровня, DS MediaInformation. Оно состоит из опционного
MediaIdentification D и одного или нескольких MediaProfile D
Идентификация среды (Media Identification) D
содержит средства описания, которые являются специфическими по отношению к идентификации
аудио-визуального материала вне зависимости от имеющихся различных копий.
Медиа-профайл D содержит различные средства
описания, которые позволяют охарактеризовать один профайл аудио-визуального
материала. Концепция профайла относится к различным вариациям, которые могут
отклоняться от оригинала в зависимости от выбранного кодирования, формата
записи и т.д. Профайл, соответствующий оригиналу или мастерной копии
аудио-визуального материала, считается мастерным профайлом. Для каждого
профайла может быть одна или более медиа-копии мастерного медиа-профайла.
MediaProfile D состоит из:
3.5.2.2. Создание и производство средств
описания
Средства описания получения материала
предоставляют авторские тексты, описания процесса формирования и/или
производства аудио-визуального материала. Эта информация не может быть получена
из самого материала. Эти данные связаны с материалом, но не описывают его
буквально.
Описание формирования и производства материала
содержит в качестве элемента верхнего уровня, DS CreationInformation,
который состоит из одного Creation D, нуля или одного Classification D, и нуля
или нескольких RelatedMaterial D.
Creation D содержит средства описания,
имеющие отношение к формированию материала, включая место, дату, действия,
материалы, персонал (технический и творческий) и организации, участвовавшие в
процессе.
Classification D содержит средства описания,
которые позволяют классифицировать аудио-визуальный материал. Classification D
используется для описания классификации аудио-визуального материала. Это
позволяет осуществлять поиск и отбор на основе предпочтений пользователя,
ориентируясь на классификации пользователя (например, по языку, стилю, жанру и
т.д.) и на классификации услуг (например, на цель, патентную защиту,
сегментацию рынка, медиа ревью и т.д.).
Related Material D содержит средства
описания, имеющие отношение к дополнительной информации о аудио-визуальном
материале, имеющемся в других материалах.
3.5.2.3. Средства описания использования
содержимого
Средства описания информации об
использовании материала предоставляют данные о процессе использования
аудио-визуального материала.
Описание данных об использовании
обеспечивается посредством DS UsageInformation, который может включать
один Rights D, нуль или один Financial D и нуль или несколько Availability D и
UsageRecord D.
Важно заметить, что описание DS
UsageInformation предполагает добавление новых описаний, каждый раз, когда
материал используется (например, DS UsageRecord, доход в Financial D),
или когда имеются другие способы доступа к материалу (например, Availability
D).
3.5.3.
Описание содержимого
Основным элементом этой части описания
является DS сегмента. Она относится к описанию физического и логического
аспектов аудио-визуального материала. DS сегмента может использоваться
для формирования сегментных деревьев. MPEG-7 специфицирует также DS графа,
который позволяет представлять сложные взаимоотношения между сегментами. Она
используется для описания пространственно-временных соотношений, между
сегментами, которые не описаны структурами дерева.
Сегмент представляет собой секцию аудио-визуального
материала. DS сегмента является абстрактным классом (в смысле
объектно-ориентированного программирования). Она имеет девять основных
подклассов: DS мультимедийного сегмента, DS аудио-визуальной области, DS
аудио-визуального сегмента, DS аудио сегмента, DS статической области, DS
статической 3D-области, DS подвижной области, DS видео сегмента и
DS электронной раскраски. Следовательно, она может иметь как
пространственные, так и временные свойства. Временной сегмент может быть
набором фрагментов аудио-визуальной последоватеьности, представленным DS
аудио сегмента, набором кадров видео последовательности, представленным DS
видео сегмента или комбинацией аудио и видео информации, охарактеризованной
DS аудио-визуального сегмента. Пространственный сегмент может быть
областью изображения или кадром в визуальной последовательности, представленным
DS статической области для 2D-областей и DS статической области 3D для
3D-областей. Пространственно временной сегмент может соответствовать подвижной
области в видеопоследовательности, представленной DS подвижной области
или более сложной комбинацией визуального и аудио материала, представленного,
например, DS аудио-визуальной области. InkSegment DS описывает
временной интервал или сегмент электронной раскраски, который соответствует
набору чернильных капель, выбрасываемых из сопла. Наконец, наиболее общим
сегментом является DS мультимедийного сегмента, который описывает
составные сегменты, образующие мультимедийную презентацию. DS сегмента
является абстрактным и не может быть отображен сам по себе: он используется для
определения общих свойств его подклассов. Любой сегмент может быть описан с
помощью информации формирования, использования медийных данных и текстовой
аннотации. Более того, сегмент может быть поделен на субсегменты с помощью DS декомпозиции
сегмента.
Сегмент не является обязательно связанным,
он может быть составлен из нескольких несвязанных компонентов. Связность здесь
относится как к пространственным, так и временным доменам. Временной сегмент (видео
сегмент, аудио сегмент или аудио-визуальный сегмент) считается
связанными, если он является непрерывной последовательностью видео кадров или
аудио фрагментов. Пространственный сегмент (статическая область или статическая
3D-область) считается связанными, если он является группой связанных
пикселей. Пространственно-временной сегмент (подвижная область или
аудио-визуальная область) считается связанным в пространстве и времени,
если временной сегмент, где он размещен является связанным, и, если каждый
кадр, в него входящий, является пространственно связанным (заметим, что это не
является классической связностью в 3D-пространстве).
На рис. 16 проиллюстрированы несколько
примеров временных или пространственных сегментов и их связности. Рис. 16a и
16b иллюстрируют временные и пространственные сегменты, содержащие один связный
компонент. Рис. 16c и 16d иллюстрирует временной и пространственный сегменты,
состоящие из трех связанных компонент. Заметим, что в последнем случае,
дескрипторы и DS, привязанные к сегменту, являются глобальными по отношению к
объединению связанных компонент, образующих сегмент. На этом уровне, невозможно
индивидуально описать связанные компоненты сегмента. Если связанные компоненты
должны быть описаны индивидуально, тогда сегмент разделяется покомпонентно.
DS Сегмента является рекурсивным, то
есть, он может быть поделен на субсегменты, и, таким образом, образовать древовидную
структуру. Результирующее сегментное дерево используется для определения
медиа-источника, временной и/или пространственной структуры аудио-визуального
материала. Например, видео программа может быть временно преобразована в ряд
сцен различного уровня, снимков, и микро-сегментов; оглавление может, таким
образом, генерироваться на основе этой структуры. Подобные стратегии могут
использоваться для пространственных и пространственно-временных сегментов.
Рис.
15. Примеры разложения сегмента на компоненты: a) и b) Декомпозиции сегмента
без зазоров и перекрытий; c) и d) Декомпозиции сегмента с зазорами и
перекрытиями
Сегмент может также разделен на составные
части по медиа-источникам, таким как различным звуковым дорожкам или разным
позициям видеокамер. Иерархическая декомпозиция полезна при формировании
эффективных стратегий поиска (от глобального до локального). Она также
позволяет описанию быть масштабируемым: сегмент может быть описан
непосредственно с помощью его набора дескрипторов и DS, а может быть также
описан набором дескрипторов и DS, которые относятся к его субсегментам.
Заметим, что сегмент может быть разделен на субсегменты различного типа,
например, видео сегмент может быть разложен движущиеся области, которые в свою
очередь разлагаются на статические области.
Так как это выполняется в
пространственно-временном пространстве, декомпозиция должна описываться набором
атрибутов, определяющих тип разложения: временное, пространственное или
пространственно-временное. Более того, пространственная и временная подсекции
могут располагаться с зазором или с перекрытием. Несколько примеров
декомпозиций для временных сегментов описано на рис. 15. Рис. 15a и 15b
описывают два примера декомпозиции без зазоров или перекрытий. В обоих случаях
объединение дочерних объектов соответствует в точности временному продолжению
родительского, даже если родитель сам не является связанным (смотри пример на
рис. 15b). Рис. 15c демонстрирует пример декомпозиции с зазорами, но без
перекрытий. Наконец, рис. 15d иллюстрирует более сложный случай, где родитель
состоит из двух связанных компонентов и его декомпозиция создает три дочерних
объекта: первый сам состоит из двух связанных компонентов, остальные два
состоят из одного связанного компонента. Декомпозиция допускает зазоры и
перекрытия. Заметим, что в любом случае декомпозиция означает, что объединение
пространственно-временного пространства, определенного дочерними сегментами,
включается в пространство, определенное его сегментом-предшественником
(дочерние объекты содержатся в предшественниках).
Рис.
16. Примеры сегментов: a) и b) сегменты состоят из одного связного компонента;
c) и d) сегменты состоят из трех связанных компонентов
Таблица
1. Примеры характеристик для описания сегмента
Как упомянуто выше, любой сегмент может быть
описан с помощью данных формирования, информации об использовании, медиа-данных
и текстовой аннотации. Однако специфические характеристики, зависящие от типа
сегмента, также допускаются. Примеры специфических характеристик представлены в
таблице 1. Большинство дескрипторов (D), соответствующих этим характеристикам
может быть получено автоматически из исходного материала. Для этой цели в
литературе описано большое число различных средств.
Пример описания изображения представлен на
рис. 17. Исходные изображения описаны как стационарные области, SR1,
которые описаны с помощью данных формирования (заголовок, создатель),
информации использования (авторские права), медийной информации (формат файла),
а также текстовой аннотации (обобщающей свойства изображения), гистограмм цвета
и дескриптора текстуры. Исходная область может быть в дальнейшем разложена на
составные области. Для каждого шага декомпозиции, мы указываем, допустимы или
нет зазоры и перекрытия. Дерево сегмента состоит из 8 стационарных областей
(заметим, что SR8 является одиночным сегментом, составленным из двух связанных
сегментов). Для каждой области, на рис. 17 показан тип характеристики, которая
реализована. Заметим, что в иерархическом дереве не нужно дублировать
информацию формирования, использования и пр., так как предполагается, что
дочерние сегменты наследуют эти характеристики.
Рис.
17. Примеры описания изображения с стационарными областями
Описание структуры материала может выходить
за рамки иерархического дерева. Хотя, иерархические структуры, такие как
деревья, удобны при организации доступа, поиска и масштабируемого описания, они
подразумевают ограничения, которые делают их неприемлемыми для некоторых
приложений. В таких случаях DS графа сегмента не используется. Структура
графа определяется набором узлов, представляющих сегменты, и набора ребер,
определяющих отношения между узлами. Чтобы проиллюстрировать использование
графов, рассмотрим пример, представленный на рис. 18.
Рис.
18. Пример видео-сегмента и областей для графа, представленного на рис. 19.
Этот пример демонстрирует момент футбольного
матча. Определены два видео-сегмента, одна стационарная область и три
движущиеся области. Граф, описывающий структуру материала, показан на рис. 19.
Видео-сегмент: Обводка & удар включает в себя мяч, вратаря
и игрока. Мяч остается рядом с игроком, движущимся
к вратарю. Игрок появляется справа от вратаря
Видео-сегмент гол включает в себя те же подвижные области плюс
стационарную область ворота. В этой части последовательности, игрок
находится слева от вратаря, а мяч движется к воротам. Этот
очень простой пример иллюстрирует гибкость данного вида представления. Заметим,
что это описание в основном представляется структурным, так как отношения,
специфицированные ребрами графа, являются чисто физическими, а узлы,
представляющие сегменты, которые являются объектами, определяемыми данными
создания, информацией использования и медиа-данными, а также дескрипторами
низкого уровня, такими как цвет, форма, движение. В семантически явном виде доступна
только информация из текстовой аннотации (где могут быть специфицированы
ключевые слова мяч, игрок или вратарь).
Рис.
19. Пример графа сегмента
3.5.3.2. Описание концептуальных аспектов
содержимого
Для некоторых приложений, подход, описанный
выше, не приемлем, так как он выделяет структурные аспекты материала. Для
приложений, где структура практически не используется, но где пользователь в
основном интересуется семантикой материала, альтернативным подходом является семантический
DS. В этом подходе, акцент делается не на сегментах, а на событиях, объектах,
концепциях, месте, времени и абстракции.
Документальная сфера относится к контексту
для семантического описания, то есть, это "реальность", в которой
описание имеет смысл. Это понятие перекрывает область специфических случаев
аудио-визуального материала, а также более абстрактных описаний, представляющих
область возможных медиа-вариантов.
Как показано на рис. 20, DS SemanticBase
описывает документальные сферы и семантические объекты. Кроме того, несколько
специальных DS получается из DS SemanticBase, которые описывают
специфические типы семантических объектов, таких как описательные сферы,
объекты, объекты агента, события, место и время, например: Семантический
DS описывает документальные сферы (narrative worlds - реальные миры), которые
отображаются или сопряжены с аудио-визуальным материалом. Он может
использоваться для описания шаблонов аудио-визуального материала. На практике,
семантический DS служит для инкапсуляции описания документальной области. DS объекта
описывает воспринимаемый или абстрактный объект. Воспринимаемый объект является
сущностью, которая является реальностью, то есть, имеет временное и
пространственное протяжение в описываемом мире (например, "Пианино
Вани"). Абстрактный объект является результатом абстрагирования
воспринимаемого объекта (например, "любое пианино"). Это
абстрагирование генерирует шаблон объекта. DS AgentObject расширяет
возможности DS объекта. Она описывает человека, организацию, группу
людей, или персонализированные объекты (например, "говорящую чашку в
анимационном кино"). DS события описывает воспринимаемое или
абстрактное событие. Воспринимаемое событие является динамическим отношением,
включающим один или более объектов, которые возникают во времени или
пространстве описываемого мира (например, "Ваня играет на пианино").
Абстрактное событие является результатом абстрагирования воспринимаемых событий
(например, "кто-то играет на пианино"). Эта абстракция позволяет
сформировать шаблон события. DS концепции описывает семантическую
сущность, которая не может быть описана, как обобщение или абстрагирование
специфицированного объекта, события, временного интервала или состояния. Она
представляет собой свойство или собрание свойств (например, "гармония" или
"готовность"). Эта DS может относиться к среде непосредственно или к другой
описываемой семантической сущности. DS SemanticState описывает один или
более параметрических атрибута семантической сущности в данное время или в
данной точке описываемого мира или в данной позиции среды (например, вес
пианино равен 100 кг). Наконец, DS SemanticPlace и SemanticTime
характеризуют соответственно место и время в описываемом мире.
Как и в случае DS сегмента, концепция
описания может быть представлена в виде дерева или графа. Структура графа
определена набором узлов, представляющих семантические понятия, и набора ребер,
специфицирующих отношения между узлами. Ребра описываются DS семантических
отношений.
Рис.
20. Средства для описания концептуальных аспектов
Кроме семантического описания индивидуальных
привязок в аудио-визуальном материале, семантические DS допускают также
описание абстракций. Абстракция относится к процессу получения описания из
специфической привязки к аудио-визуальному материалу и обобщению его с помощью
нескольких привязок к этому материалу или к набору специальных описаний.
Рассматриваются два типа абстракции, называемых медиа-абстракция и стандартная
абстракция.
Медиа-абстракция
представляет собой описание, которое отделено от
конкретных образцов аудио-визуального материала, и может описывать все варианты
и образцы аудио-визуального материала, которые достаточно схожи между собой
(подобие зависит от приложения и от деталей описания). Типичным примером может
служить новость, которая широковещательно передается по разным каналам.
Стандартная абстракция
является обобщением медиа-абстракции для описания
общего класса семантических сущностей или описаний. Вообще, стандартная
абстракция получается путем замещения конкретных объектов, событий или других
семантических сущностей классами. Например, если "Ваня играет на
пианино" заменяется на "человек играет на пианино", описание
становится стандартной абстракцией. Стандартные абстракции могут быть
рекурсивными, то есть определять абстракцию абстракций. Обычно стандартная
абстракция предназначена для повторного использования или ориентирована на
применение в качестве ссылки.
Простой пример описания концептуальных
аспектов показан на рис. 21. Описываемый мир включает в себя в данном случае
Ваню Иванова играющего на фортепиано со своим учителем. Событие характеризуется
семантическим описанием времени: "19:00 24-го апреля 2002", и
семантикой места: "Консерватория". Описание включает одно событие: игра
и четыре объекта: фортепьяно, Ваня Иванов, его учитель и абстрактное понятие
музыканта. Последние три объекта принадлежат к классу агент.
Рис. 21. Пример концептуальных аспектов описания.
3.5.4. Навигация и доступ
MPEG-7 предоставляет DS, которые облегчают
навигацию и доступ к аудио-визуальному материалу путем спецификации резюме,
обзоров, разделов и вариаций медиа-данных. DS резюме предоставляет аннотации
аудио-визуального материала для того, чтобы обеспечить эффективный просмотр и
навигацию в аудио-визуальных данных. Пространственно-частотная проекция дает
возможность рассматривать аудио-визуальные данные в пространственно-частотной
плоскости. DS вариации специфицируют отношения между различными вариантами
аудио-визуального материала, которые позволяют адаптивный выбор различных копий
материала при различных условиях доставки и для разных терминалов.
3.5.4.1. Резюме
Аудио-визуальные резюме предоставляют
компактные аннотации аудио-визуального материала для облегчения обнаружения,
просмотра, навигации, визуализации и озвучивания этого материала. DS резюме
позволяет осуществлять навигацию в рамках аудио-визуального материала
иерархическим или последовательным образом. Иерархическая декомпозиция резюме
организует материал послойно, так что он на различных уровнях выдает различную
детализацию (от грубой до подробной). Последовательные резюме предоставляет
последовательности изображений или видео кадров, возможно синхронизованные с
аудио и текстом, которые формируют слайд-демонстрации или аудио-визуальные
наброски.
Рис. 22. Пример
иерархического резюме видео записи футбольного матча, имеющего многоуровневую
иерархию. Иерархическое резюме предполагает достоверность (то есть, f0,
f1, .) ключевых кадров с точки зрения видео сегмента следующего
более низкого уровня.
На рис. 22
показан пример иерархического резюме видео записи футбольного матча. Описание
иерархического резюме предоставляет три уровня детализации. Видео запись матча
суммирована на одном корневом кадре. На следующем уровне иерархии предлагается
три кадра, которые суммируют различные сегменты видеозаписи. Наконец, внизу
рисунка показаны кадры нижнего уровня иерархии, отображающие детали, различных
сцен сегментов предыдущего уровня.
3.5.4.2. Разделы и декомпозиции
Отображения
разделов и декомпозиций описывает различные части аудио-визуального сигнала в
пространстве, времени и по частоте. Отображения разделов описывает различные
виды аудио-визуального материала, такие как отображения с низким разрешением,
пространственных или временных сегментов, или частотных субдиапазонов. Вообще,
DS отображения пространства и частоты специфицируют соответствующие
разделы в пространственной и частотной плоскостях.
Отображение
декомпозиций описывает различные представления аудио-визуального сигнала
посредством механизмов графов. Декомпозиции специфицируют узловые элементы
информационных структур, базирующихся на графе и соответствующие элементы
отношений, которые соответствуют анализу и синтезу внутренних зависимостей
отображений.
На рис. 23
приведен пример пространственно-частотного графа декомпозиции изображения.
Структура пространственного и частотного графа включает элементы узлов, которые
соответствуют различным пространственным и частотным проекциям изображения,
состоящего из пространственных проекций (пространственные сегменты), частотных
(частотные субдиапазоны), и пространственно-частотных (частотные субдиапазоны
пространственных сегментов). Структура пространственного и частотного графа
включает также элементы переходов, которые содержат анализ и синтез
зависимостей между проекциями. Например, на рис. 23, "S" переходы указывают на
пространственную декомпозицию, в то время как "F" переходы отмечают частотную
или субдиапазонную декомпозицию.
Рис. 23. Пространственно-частотный
граф разлагает изображение или аудио-сигналы в пространстве
место-время-частота. Декомпозиция изображений, использующая
пространственно-частотный граф, делает возможным эффективный доступ и поиск
материала при самом разном разрешении
3.5.4.3.
Вариации содержимого
Вариации
предоставляют информацию о различных изменениях аудио-визуального материала,
такого как резюме, архивированные или версии с малым разрешением, а также
версии на различных языках - звук, видео, изображение, текст и т.д.. Одной из
главных функций DS вариаций является разрешение серверу, прокси или
терминалу выбрать наиболее удобную вариацию аудио-визуального материала,
которая может заместить оригинал, если необходимо, адаптировать различные
возможности терминального оборудования, сетевых условий или предпочтений
пользователя. DS вариаций используется для спецификации различных
вариаций аудио-визуальных данных. Вариации могут возникать самыми разными
способами, или отражать изменения исходных данных. Значение достоверности
вариации определяет ее качество по сравнению с оригиналом. Атрибут типа
вариации указывает на характер изменений: резюме, аннотация, язык перевода,
уменьшение насыщенности цвета, снижение разрешения, сокращение частоты кадров,
архивирование и т.д..
3.5.5. Организация содержимого
MPEG-7
предоставляет DS для организации и моделирования коллекций аудио-визуального
материала, сегментов, событий, и/или объектов, и описания их общих свойств.
Коллекции могут быть далее описаны, используя различные модели и статистики для
того, чтобы характеризовать атрибуты элементов коллекции.
3.5.5.1.
Собрания (Collections)
DS структуры
коллекции описывает коллекции аудио-визуального материала или отрывков
такого материала, например, временные сегменты видео. DS структуры коллекции
группирует аудио-визуальный материал, сегменты, события, или объекты кластеры
коллекций и специфицирует свойства, которые являются общими для всех элементов.
DS CollectionStructure описывает также статистику и модели значений
атрибутов этих элементов, такие как усредненная гистограмма цвета для коллекции
изображений. DS CollectionStructure также описывает отношения между
кластерами коллекций.
На рис. 24
показана концептуальная организация коллекций в DS CollectionStructure.
В этом примере, каждая коллекция состоит из набора изображений с общими
свойствами, например, каждая отображает сходные события в футбольном матче.
Внутри каждой коллекции, могут быть специфицированы отношения между
изображениями, такие как степень сходства изображений в кластере. В рамках
коллекции, DS CollectionStructure специфицирует дополнительные связи,
такие как степень сходства коллекций.
Рис. 24. DS структуры коллекции описывает
коллекции аудио-визуального материала, включая отношения (то есть, R AB,
RBC, RAC) внутри и между кластерами коллекций
3.5.5.2. Модели
DS моделей
предоставляют средства для моделирования атрибутов и характеристик
аудио-визуального материала. DS модели вероятности предоставляет собой
фундаментальную DS для спецификации различных статистических функций и
вероятностных структур. DS модели вероятности могут использоваться для
представления образцов аудио-визуальных данных и классов дескрипторов,
использующих статистические аппроксимации.
DS аналитической
модели описывает коллекции образцов аудио-визуальных данных или кластеров
дескрипторов, которые предоставляют модели для конкретных семантических
классов. DS аналитической модели специфицирует семантические маркеры,
которые индицируют моделируемые классы. DS аналитической модели опционно
специфицирует степень доверия, с которой семантический маркер приписан модели.
DS классификатора описывает различные типы классификаторов, которые
определяют механизм присвоения семантических маркеров аудио-визуальным данным.
3.5.6. Взаимодействие с пользователями
DS UserInteraction
описывает предпочтения пользователей имеющих отношение к использованию
AВ-материала, а также историю его использования. Описания АВ-материала в MPEG-7
может быть приведено в соответствие с описаниями предпочтений для того, чтобы
выбрать и персонализовать АВ-материал для более эффективного доступа,
презентации и использования. DS UserPreference описывает предпочтения
для различных типов материала и моделей просмотра, включая зависимость от
контекста в терминах времени и места. DS UserPreference описывает также
вес относительной важности различных предпочтений, характеристики
конфиденциальности предпочтений и будут ли предпочтения изменяться в процессе
взаимодействия, агента с пользователем. DS UsageHistory описывает
историю действий, предпринятых пользователем мультимедийной системы. Описания
истории использования могут пересылаться между клиентами, их агентами,
провайдерами материала и оборудованием, и могут быть в свою очередь
использованы для определения предпочтений пользователей с учетом характера
АВ-материала.
3.6. Эталонные программы: экспериментальная модель
Программы XM
являются основой для эталонных кодов стандарта MPEG-7. Они используют
нормативные компоненты MPEG-7:
Кроме нормативных
компонентов, симуляционной платформе необходимы также некоторые ненормативные
компоненты, существенные для выполнения некоторых процедурных программ,
выполняемых для нормативных информационных структур. Информационные структуры и
процедурные программы образуют приложения. Для большинства D или DS существует
как минимум одно приложение в программном пакете, позволяющее проверить
функциональность каждого нормативного компонента. Приложения показывают также,
как извлечь метаданные из медиа-материала, или как мета данные могут
использоваться в простых приложениях. Следовательно, XM реализует только
базовые типы элементарных приложений, а не приложения реального мира. Более
того, программы XM имеют только интерфейс командной строки, который не позволяет
какого-либо взаимодействия в процессе исполнения.
Модули
программного обеспечения XM разработаны так, что все они используют
специфицированные интерфейсы. Это позволяет облегчить навигацию среди множества
различных модулей для разных D и DS. С другой стороны, использование
фиксированного интерфейса позволяет повторно использовать и объединять
отдельные модули в большие приложения.
3.6.2. Извлечение и приложения клиента
В рамках
программного обеспечения XM, приложения соотносятся с одним конкретным дескриптором
или схемой описания. Так как стандартизовано много дескрипторов и схем описания
(DS), существует также много приложений интегрированных в программный пакет.
Приложения, которые формируют дескриптор (D) или схему описания (DS), которые
они тестируют, называются приложениями выборки. С другой стороны,
приложения, которые используют тестируемые D или DS (DUT), называются приложениями
клиента. Извлекающие приложения нужны, если D или DS являются дескриптором
низкого уровня, это означает, что описание может быть извлечено из
мультимедийного материала автоматически. Для D или DS высокого уровня выборка
не может быть реализована аналогично. Однако в большинстве случаев выборка
может быть основана на предварительной информации. Это означает, что процесс
выборки читает эти дополнительные данные помимо медийного материала, чтобы
получить описания. Таким образом, набор мультимедийного материала расширяется
путем добавления входных данных высокого уровня.
3.6.3. Модульность XM-программ
По умолчанию
модули для всех D и DS скомпилированы так, чтобы создать один большой
исполнимый модуль, который может затем вызвать приложение для индивидуального D
или DS. Однако результирующий исполняемый модуль становится необыкновенно
большим, из-за массы индивидуальных D и DS определяемых стандартом. Компиляция
с целью получения исполняемого модуля может выдать файл размером более 100
Мбайт (в случае, если включен режим отладки). Следовательно, программное
обеспечение MPEG-7 XM сконструировано так, чтобы поддерживать частичную
компиляцию с использованием только одного D или DS. С другой стороны, во многих
случаях желательно комбинировать субнаборы D или DS. Более того, комбинирование
D и DS также необходимо, когда DS строится иерархически из других D и DS. При
этом сценарии, не только важно обеспечить частичную компиляцию, но существенно
сконструировать программу так, чтобы код можно было использовать повторно.
Таким образом, все приложения построены из модулей. Среди этих модулей:
Чтобы увеличить
возможность повторного использования, все эти классы используют специальные
интерфейсы, независящие от D или DS, к которым они принадлежат. Таким образом,
нужно, чтобы программу можно было использовать повторно, например, применить
средство выборки D или DS для других D или DS без глубокого знания, как это
делается в данном средстве. Это возможно, если только известно, как
использовать интерфейс этого средства выборки. Модули, перечисленные выше,
скомбинированы или соединены друг с другом так, чтобы образовать цепочку
обработки. Это сделано в классах приложений, которые могут относиться к классам
выборки или приложения клиента.
3.6.4. Модули приложения
Медиа-декодер
(класс MediaIO) поддерживает широкий диапазон возможных входных медийных
форматов. Среди них:
Для этих целей
класс MediaIO использует набор внешних библиотек, которые не принадлежат во
всех случаях дереву исходных кодов программ XM. Сюда входят следующие
библиотеки:
Особым случаем
является видео последовательности, так как декодированное и некомпрессированное
представление является слишком емким для того, чтобы производиться в памяти.
Следовательно, класс MediaIO записывает декомпрессированные изображения во
временные файлы, которые могут быть затем загружены с помощью программ для
статических изображений. Тот же механизм применяется для информации векторов
перемещения, но здесь декодирование видео последовательности останавливается
после получения векторов перемещения.
Так как класс
MediaIO является интерфейсом для этих библиотек, использование внешних
библиотек не нужно и не разрешено для любого другого класса программ XM,
например, разрешающих аудио-экспертам использовать программы XM без специфичной
для видео библиотеки ImageMagick.
3.6.4.2. Мультимедийные данные
Класс MultiMedia
хранит загруженные медиа данные в памяти. Видео последовательности, не
загружаются в память (в память могут заноситься лишь отдельные кадры).
Для статических
изображений XM использует сокращенную структуру данных MoMuSys Vop из модели
верификации MPEG-4 (VM). Ключевые точки записываются в двухмерный связанный
список, одно измерение для временных точек (один кадр) содержащих второе измерение,
которое включает в себя все ключевые точки для этого кадра. Структура
аудио-данных в данный момент не согласована, но будет доступна в ближайшем
будущем.
3.6.4.3. Средства выборки
Средство выборки
выполняет выборку из базы данных характеристики одного элемента мультимедиа.
Процесс выборки не является нормативным средством в стандарте MPEG-7. Чтобы
получить характеристику, средство выборки воспринимает ссылку на медиа-данные,
являющиеся входными для данной операции, и в то же время ссылкой для описания,
которое записывает результаты процесса выборки.
Так как в случае
обработки видео последовательности, невозможно предоставить все входные данные
одновременно, выборка производится по-кадрово. Это означает, что имеется три
функции, которые используются для реализации процедуры выборки:
Тот же интерфейс
используется в случае обработки аудио-данные. Здесь, входные данные являются
более или менее непрерывными. Входной поток делится на кадры, которые затем
могут обрабатываться один за другим.
Помимо
интерфейсов, классы выборки имеют процедурный код. В случае средства выборки
изображения или видео, программы XM используют AddressLib, которая является
общей библиотекой видео обработки для выполнения задач анализа изображения на
нижнем уровне.
Средства выборки
используются исключительно для получения данных из медиа среды прикладного
типа. Как будет показано позднее, имеется возможность извлечь проверяемые D или
DS из других данных описания. В этом случае, процесс выборки может быть
реализован только через один функциональный вызов, то есть, без итеративных
циклов с входными данными для каждой временной точки или периода.
3.6.4.4. Класс
дескрипторов
Классы
дескрипторов несут в себе описательные данные. В программах XM классы для
каждого D или DS представляют непосредственно нормативную часть стандарта.
Имеются также функции для элементов реализации описаний.
В программах XM
имеется два различных способа конструирования классов D или DS. В случае
визуальных D, этот класс использует простой подход класса C++. Во всех других
случаях этот класс реализуется с помощью общего модуля, который в XM называется
GenericDS. Этот класс является интерфейсом между программами C++ XM и
реализацией парсера DDL. Здесь используется XML парсер, предоставляющий DOM-API
(Data Object Model - Application Programming Interface - прикладной программный
интерфейс объектной модели данных). Следовательно, GenericDS является
интерфейсом между XM и парсером DOM-API. Управление памятью для описательных
данных выполняется посредством библиотеки парсера DOM. Оба подхода могут
комбинироваться с помощью функций ImportDDL и ExportDLL
реализованных классов дескриптора C++.
3.6.4.5. Схема кодирования
Схема кодирования
включает в себя нормативный кодировщик и декодер для D или DS. В большинстве
случаев схема кодирования определена только заданием схемы DDL. Здесь,
кодирование представляет собой вывод описания в файл, а декодирование является
разборкой (parsing) и загрузкой файла описания в память. Описание запоминается,
с использованием класса GenericDS, который является оболочкой для DOM-API.
Следовательно, мы можем использовать библиотеку парсера DOM-API для кодирования
и декодирования. Эти функции встроены XM с помощью класса GenericDSCS (CS =
схема кодирования). Помимо ASCII-представления XML-файла MPEG-7 стандартизует
также двоичное представление описаний (BiM).
Другим подходом
является использование визуальной группы MPEG-7. Здесь, каждый D имеет также
индивидуальное двоичное представление. Это позволяет специфицировать число бит,
которое следует использовать для кодирования индивидуальных элементов описания.
Примером может служить число бит, используемых для кодирования каждой ячейки
гистограммы.
3.6.4.6. Средство поиска
В качестве
средств извлечения и поиска используется ненормативное средство стандарта. Оно
берет одно описание из базы данных и одно описание запроса, причем запрос может
не соответствовать нормативам MPEG-7 D или DS. Средство поиска анализирует
описание и обрабатывает нужные входные данные так, как это требуется для
специфицированного приложения.
Средства поиска
используются во всех клиентских приложениях, которые являются приложениями
поиска и доставки (search & retrieval) и приложениями
медиа-транскодирования (media transcoding). В случае приложений поиска и
доставки, средство поиска сравнивает два входных описания и вычисляет величину
их отличия. Для приложения медиа-транскодирования обрабатываются медиа-данные,
то есть, медийная информация модифицируется на основе описания и запроса. Так
как медиа данные обрабатываются, средство поиска вызывается из приложения
транскодирования.
3.6.5. Типы приложений в XM-программах
Выборка из медиа
приложения относится к типам приложений выборки. Обычно, все D или DS низкого
уровня должны иметь класс приложения этого типа. Как показано на рис. 25 это
приложение извлекает тестируемые D/DS (DUT) из входных медиа данных. Сначала
медиа файл загружается медиа-декодером в мультимедиа-класс, то есть, память. На
следующем шагу с помощью средства выборки описание может быть извлечено из
мультимедиа-класса. Затем описание проходит через кодировщик и закодированные
данные записываются в файл. Этот процесс повторяется для всех мультимедийных
файлов медийной базы данных.
Рис. 25. Выборка для приложения медийного типа.
Описание извлекается из входных медийных данных
3.6.5.2.
Приложение поиска и извлечения
Приложение поиска
и получения данных, показанное на рис. 26, относится к типу клиентского
приложения. Сначала все описания базы данных, которые могут быть извлечены из
медиа приложения, декодируются и загружаются в память. Из медиа данных с
помощью средства выборки может быть извлечено и описание запроса. С другой
стороны запрос может быть загружен непосредственно из файла. После получения
всех входных данных, запрос обрабатывается для всех элементов базы данных, а
результирующие расстояния (значения отличия) используются для сортировки данных
согласно уровню соответствия запросу. Наконец, сортированный список
записывается в качестве медиа базы данных в файл.
Рис. 26. Поиск и выборка прикладного типа.
Сортированная информация из медиа базы данных получается из описаний и запроса
3.6.5.3. Приложение транскодирования среды
Приложение медиа
транскодирования также относится к клиентскому типу. Как показано на рис. 27,
медиа файлы и их описания загружены. Основываясь на описаниях, медиа данные
модифицируются (транскодируются), а новая медиа база данных записывается в
файл. Более того, может быть специфицирован запрос, который обрабатывается для
описаний до транскодирования.
Рис. 27. Тип приложения медиа транскодирования. Из
исходной DB создается транскодированная база данных, соответствующая описаниям
и опционно запросу.
3.6.5.4. Приложение описания фильтрации
Приложение
фильтрации описаний может относиться к типу выборки или клиента,
в зависимости оттого сгенерирован или использован исследуемый дескриптор (DUT).
В обоих случаях описания входной базы данных фильтруются на основе
регламентаций запроса. Результирующие отфильтрованные описания записываются
затем в выходные файлы.
Рис. 28. Приложение фильтрации описаний
3.6.6. Модель ключевого приложения MPEG-7
Эти приложения
называются также ключевыми приложениями, так как они имеют базовый или
элементарный тип. Вообще, ключевые приложения необязательно являются
приложениями реального мира, так как они используют только репрезентативные и
общие задания прикладных сценариев.
Другим важным
ограничением программного обеспечения XM является факт, что программы XM
являются лишь средствами командной строки, то есть, что приложение, его входы и
выходы могут быть специфицированы только, когда работает XM. Ключевые
приложения во время работы не поддерживают взаимодействие с пользователем.
3.6.6.2.
Модель интерфейса
После идентификации
природы ключевых приложений следующим шагом является разработка абстрактной
модели такого приложения. Результирующий субнабор входов и выходов показан на
рис. 29. Возможными входами являются медиа базы данных, базы данных описаний и
запросов. Возможными выходами могут быть медиа базы данных и базы данных
описаний. В абстрактной модели семантика выхода медиа базы данных не разделена,
то есть, список медиа файлов наилучшего соответствия и транскодированной медиа
базы данных не рассматриваются как индивидуальные типы выхода.
Рис. 29. Интерфейсная модель ключевых приложений XM.
Эта модель показывает супернабор возможных входов и выходов ключевого
приложения XM.
Помимо уже
используемых выходов, предполагается, что будет также тип выхода,
соответствующий входному запросу. На рис. 29 этот выход имеет название прочий
выход. Возможными приложениями для этого могут быть уточняющие запросы,
например, для просматривающих приложений. Однако использование этого выхода все
еще не ясно и нуждается в дальнейших исследованиях.
Далее мы используем
интерфейсную модель ключевых приложений для двух целей, создание новых ключевых
приложений и описание отношений ключевых приложений с приложениями реального
мира.
3.6.7. Ключевые приложения против приложений реального мира
Как было заявлено
выше, ключевыми приложениями в программном обеспечении XM являются приложения
элементарного типа. Комбинирование ключевых приложений создает составные
приложения. Так как ключевые приложения могут иметь произвольные комбинации
входов, модель ключевых приложений является общей для этого диапазона
приложений. Следовательно, также возможно, что приложения реального мира могут
быть объединены в обрабатывающие сети, состоящие из блоков элементарных
ключевых приложений и пользовательских интерфейсов, предоставляющих пользователю
механизм взаимодействия и презентации результатов.
Рис. 30. Пример приложения реального мира,
извлекающего два разных описания (XM-Appl1, XM-Appl2). Основываясь на первом
описании выбран адекватный набор материала (XM-Appl3), который затем
транскодирован с использованием второго описания (XM-Appl4). (MDB = медийная
база данных, DDB = база данных описаний). На рис. 30
приведен пример приложения реального мира. Сначала, из медиа базы извлекаются
два объекта. Затем, основываясь на первом объекте, из базы данных выбираются
адекватные медиа файлы. Эти медиа файлы транскодируются с привлечением второго
извлеченного объекта.
Ссылки
Имеется большое число документов на базовой странице MPEG
http://drogo.cselt.it/mpeg/, включая:
Информацию,
имеющую отношение к промышленной сфере, можно найти на Web-сервере MPEG-7 http://www.mpeg-7.com
(Industry Focus Group).
Приложение А. Словарь и сокращения
|
||||||||||||||||||||||||||||||||||||
|
Previous:
2.5.1 Стандарт MPEG-4
UP:
2.4 Методы преобразования и передачи звуковых сигналов
|
|
|
|||||||||||||||||||||||||||||||||||
|
2.5 Методы преобразования и передачи изображения
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||
|
Передача изображения представляет собой наиболее тяжелую проблему, так как человеческий глаз с информационной точки зрения несравненно совершеннее уха. В 1902 году Артур Корн (Германия) запатентовал систему фотоэлектрического сканирования изображения, а в 1910 году заработала первая международная факсимильная связь Берлин-Париж-Лондон. До 60-х годов этого века рынок факсимильной аппаратуры был ограничен. В 1968 году CCITT разработала рекомендации по факсимильному оборудованию, которое было способно передавать страницу за 6 минут при разрешении 3.85 линий на мм. Позднее в 1976 году аналоговая факсимильная техника была улучшена. Это позволило сократить время передачи страницы до 3 минут. В 1980 году разработан стандарт для цифровых факс-машин (группа 3), здесь уже предусматривается сжатие информации, что позволяет сократить время передачи страницы до 1 мин при скорости передачи 4800 бит/с. Следует иметь в виду, что сжатие информации в сочетании с ошибками пересылки может приводить к неузнаваемости изображения локальному или полному. По этой причине число линий сканирования, которые используются при обработке изображения, с целью сжатия может варьироваться (1-4) и определяется в результате диалога между отправителем и получателем, а передача каждой скан-линии завершается довольно длинным кодом, предназначенным для надежного распознавания завершения строки сканирования, а также коррекции ошибок. Факсимильное оборудование группы 3 может и не обеспечивать сжатия передаваемых (принимаемых) данных. В 1984 году разработаны требования к факс-аппаратам группы 4. Система базируется на двухмерной системе кодирования изображения (MMR - Modified Modified Reed). Факсимильное оборудование поделено на 4 группы. Первая группа практически совпадает с традиционным фототелеграфным оборудованием (6 минут на страницу при разрешении 3.85 линий на миллиметр). Динамической вариации кодовой таблицы не предусмотрено. При этом для кодирования очередной линии сканирования используются результаты, полученные для предшествующей линии. Следует учитывать, что зона сканирования факс-машины больше размера изображения и всегда имеются пустые строки и поля, что предоставляет дополнительные возможности для сжатия передаваемой информации. Существует три режима кодирования: вертикальный, горизонтальный и проходной. Последний режим реализуется, когда позиция в эталонной строке a2 находится слева от b1 (см. рис. 2.5.1; вериткальному и горизонтальному режиму соответствует нижняя часть рисунка). При "вертикальном" режиме кодирования (a2 справа от b1 и |b1a1|<= 3) позиция b1 кодируется относительно позиции a1. Относительное положение b1a1 может принимать одно из семи значений V(0), VR(1), VR(2), VR(3), VL(1), vL(2) и VL(3) (см. табл. 2.5.1). Индексы r и l указывают на то, что b1 находится справа или слева по отношению к a1, а число в скобках обозначает расстояние b1a1. Если используется "горизонтальный" режим кодирования (a2 справа от b1 и |b1a1|>3), длины b0b1 и b1b2 отображаются с помощью кодовой комбинации H+M(b0b1)+M(b1b2). H представляет собой код 001, взятый из двумерной кодовой таблицы. M(b0b1) и M(b1b2) являются кодовыми словами, которые характеризуют длину и цвет субстрок b0b1 и b1b2 соответственно.
Рис. 2.5.1. Режимы кодирования: проходной; вертикальный; горизонтальный Факс-оборудование группы 4 может поддерживать так называемый расширенный режим, когда часть рабочего поля кодируется без использования алгоритмов уплотнения информации (как правило, это участки, где попытка сжать либо ничего не дает, либо даже приводит к увеличению объема передаваемых данных). Оборудование этой группа использует на канальном уровне процедуры HDLC LAPB. Рекомендуемой полосой пропускания канала, к которому подключается такое оборудование, является 64 Кбит/с. Таблица 2.5.1. Кодирование элементов изображения
Перед началом передачи терминалы должны обменяться своими идентификаторами (TID - terminal identification). В последнее время появились факс-аппараты, которые печатают изображение на обычную бумагу с разрешением 300-400 точек на дюйм. Такая схема удобна, но имеет некоторые недостатки. Такие аппараты дороги, печать может начаться не ранее, чем будет передана вся страница; передающий аппарат может иметь более низкое разрешение, нужно уметь адаптироваться к любому разрешению, что приводит к тому, что скорость печати изображения при низком разрешении остается столь же низкой, как и при высокой. В 1970 году в Бритиш Телеком были разработаны основные принципы еще одного вида передачи графической информации - телетекста, первые опыты по его внедрению относятся к 1979 году. Стандарт на мозаичное представление символов был принят CEPT в 1983 году. Каждому символу ставится в соответствие код длиной в 7-8 бит. На экране такой символ отображается с помощью специального знакового генератора, использующего таблицу. Полному экрану видео текста, содержащему 24 строки по 40 символов, соответствует 960 байт, для передачи которых по коммутируемой телефонной сети требуется 6,4 секунды. D-канал ISDN может пропустить эту информацию за 1 сек, а B-канал быстрее за 0,1 сек. Телетекст позволяет более эффективно использовать каналы связи и не налагает чрезмерных требований на устройства отображения. Известно, что для корректной передачи цвета требуется 16 миллионов оттенков (8 бит на каждую из трех цветовых компонент). Таким образом, для описания картинки на экране, содержащей 575 линий по 720 пикселей, требуется 1,240 Мбайта. Для передачи такой информации по B-каналу ISDN, если не используется сжатие, потребуется около 2,5 минут. Эта цифра помогает понять актуальность проблемы сжатия графической информации. При передаче чисто текстовой информации электронная почта имеет по этой причине абсолютное преимущество перед факсом. В перспективе можно ожидать внедрения сжатия информации при передаче почтовых сообщений с последующей дешифровкой данных принимающей стороной. Первым шагом на этом пути является внедрение системы MIME. Такое усовершенствование электронной почты сделает ее еще более грозным конкурентом факс-машин. Ведь передача графических образов уже не является монополией факсимильных систем, а возможность шифрования почтовых сообщений (например, в PGP) делает электронную почту более противостоящей перехвату. Таким образом, чтобы выдержать конкуренцию со стороны электронной почты разработчикам факс-систем нужно упорно работать. Стандарты для представления и передачи изображения разрабатывает Joint Photographic Expert Group (JPEG). Для сжатия графической информации в настоящее время используется дискретное косинусное двухмерное преобразование (DCT - Discrete Cosine Transform), которое дает субъективно наилучший результат и описывается уравнением:
где v - горизонтальная координата графического блока, u - вертикальная, x - вертикальная координата внутри блока, а y - горизонтальная координата внутри блока, C(u), C(v) = 1/
Интуитивно метод DCT базируется на выявлении того, насколько вышестоящий блок отличается от нижестоящего. Для реального представления (сжатия) коэффициентов преобразования здесь также используются коды Хафмана.
Рис. 2.5.2. Графическое представление двухмерного преобразования по формуле [2.5.1] DCT обеспечивает сжатие на уровне 0.5-1.0 бит/пиксель при хорошем качестве изображения. Сжатие требует времени, а максимально приемлемым временем задержки при пересылке изображения является 5 секунд. На рис. 2.5.3 приведена качественная оценка четкости и соответствия оригиналу изображения в зависимости от величины сжатия (DCT). Если использовать скорость обмена 64 кбит/с, то степени сжатия 0,01 бита на пиксель будет соответствовать время передачи изображения 0,04 секунды, а сжатию 10 - время передачи 40сек.
Рис. 2.5.3. Качество DCT-изображения для различных значений сжатия информации (картинка имеет разрешение 512*512 пикселей; заполненные квадратики соответствуют цветному изображению, а незаполненные - черно-белому) Отображение графического образа может выполняться последовательно (примерно так, как мы читаем текст: слева-направо и сверху-вниз) или с использованием прогрессивного кодирования (сначала передается вся картинка с низким разрешением, затем последовательно четкость изображения доводится до максимальной). Последний метод весьма удобен для систем WWW, где просмотрев изображение низкого разрешения, можно отменить передачу данных улучшающих четкость и тем самым сэкономить время. Хорошо распознаваемое изображение получается при сжатии порядка 0,1 бита на пиксель. Проблема сжатия и передачи движущегося изображения еще сложнее. Алгоритм кодирования такого изображения описан в рекомендациях CCITT H.261 и предполагает, что скорость передачи при этом лежит в интервале 40кбит/с - 2Мбит/с. Следует иметь в виду, что видео телефония и видеоконференции требуют синхронной передачи звука и изображения (стандарт H.221, например 46,4 Кбит/с для видео и 16 Кбит/с для звука). Нормальный формат телевидения имеет 625 и 525 строк развертки и частоту кадров 25-30 в секунду. Цветное телевидение использует сигналы R (red), G (green) и B (blue), причем яркость луча (y) определяется соотношением: Y = 0.30R + 0.59G + 0.11B (при отображении белого цвета). Информация о цветах определяется формулами: СB = B - Y и CR = R - Y. Зная величины y, CB и СR, можно восстановить значения R, G и B. При сжатии цветного изображения учитывается тот факт, что человеческий глаз извлекает большую часть информации из контуров предметов, а не из цветных деталей. Например в рекомендации CCIR 601 предлагается использовать полосу 13.5 Мгц для кодирования Y и только по 6.75 Мгц для СB и CR. Такая схема требует 216 Мбит/с, что в 3375 раза превышает возможности стандартного 64кбит/с B-канала ISDN. Приемлемыми решениями могут быть:
Проблема сжатия информации была, есть и всегда будет актуальной. При известных современных методах, чем больше эффективность сжатия - больше задержка (наилучший результат можно получить, используя сжатие всего фильма, чем кадра или тем более строки). В каждом конкретном случае выбирается то или иное компромиссное решение. При работе в реальном масштабе времени, где в процессе обмена участвует человек, задержки более секунды вызывают раздражение, и приходится ограничиваться сравнительно скромными коэффициентами сжатия. При пересылке движущегося изображения производится сравнение текущего кадра с предшествующим. Если кадры идентичны, никакого информационного обмена не происходит. Если кадры отличаются лишь смещением какого-то объекта, выявляются границы этого объекта, направление и величина вектора его перемещения. Так как использование индивидуальных векторов перемещения для каждого пикселя слишком расточительно, используется общий вектор для блока пикселей 16*16 по яркости и для соответствующего блока 8*8 по цвету. Точность задания вектора перемещения обычно лежит в пределах 1/2 пикселя (стандарт MPEG-2). Только эта информация и передается по каналу связи. Выявление движущихся объектов осуществляется путем вычитания изображения двух последовательных кадров. Если бы передавалась всегда только разница кадров, происходило бы накопление ошибок. Кроме того, как кодер, так и декодер содержат прямой и обратный DCT-преобразователь. Если комбинация прямого и обратного DCT-преобразования не приводит к получению исходного объекта, то такого рода эффекты могут заметно усилиться. Для исключения этого время от времени производится передача непосредственно видеосигнала. Практически преобразователь изображения представляет чудо современной технологии, которое даст работу еще не одному поколению математиков и инженеров. Нисколько не проще система передачи и мультиплексирования потока видео данных, который содержит помимо обычной информации описания формы движущихся объектов, векторы перемещения, коэффициенты дискретизации и многое другое. Схема передачи графической информации имеет 4-х уровневую, иерархическую структуру. Передача каждого кадра изображения начинается с 20-битного кода PSC (Picture Start Code, эта сигнатура позволяет выделить начало кадра изображения в общем потоке), далее следует 5-битовый код TR (Temporal Reference, временная метка, которая позволяет поместить соответствующую часть изображения в правильную точку экрана). Изображение пересылается частями, имеется 4 уровня: кадр, группа блоков GoB (Group of Blocks), макроблоки (MB) и просто блоки. Ядро всей структуры составляет процедура передачи кадра (внутренний слой, существуют еще слои GoB, MB и блока, см. рис. 2.5.4, 2.5.5, 2.5.6)
Рис. 2.5.4. Схема передачи кадра изображения Поле Ptype содержит 6 бит, которые характеризуют формат изображения (используется ли формат CIF или QCIF). Однобитное поле PEI указывает на то, следует ли далее 8-битное поле PSpare (предназначено на будущее). Если PEI=0, начинается цикл передачи GoB. Группа блоков составляет одну двенадцатую картинки CIF или одну треть QCIF. GoB описывает Y (яркость), 176 пикселей для каждой из 48 строк и соответствующие 88*24 элементов для CB и CR. GBSC - (Group of Blocks Start Code) представляет собой 16-разрядное слово, за которым следует 4 бита номера GoB (GN - GoB number). GN указывает, какой части изображения соответствует данный GoB. Поле gquant имеет 5 бит и указывает на номер преобразователя (одного из 31 дискретизаторов), который используется данным GoB. Смысл GEI идентичен PEI. GEI и GSpare позволяют сформировать структуру данных, идентичную той, что используется на уровне кадра. Формат пересылки mb сложнее (см. [17]). Каждый GoB делится на 33 макроблока (MB), каждый из которых соответствует 16 строкам по 16 пикселей Y (четыре блока 8*8) и CB и CR. Каждый макроблок начинается с его адреса MBA (MacroBlock Address), имеющего переменную длину и определяющего положение макроблока в GoB.
Рис. 2.5.5. Блок-схема кодирования и передачи изображения Макроблоки не передаются, если данная часть изображения не изменилась. За MBA следует код переменной длины Mtype, характеризующий формат макроблока (применен ли метод подвижного вектора MVD и т.д.) и последующую информацию. CBP (Coded Block Pattern) представляет собой кодовое слово переменной длины, которое несет в себе информацию о том, какой из шести блоков преобразования (8*8) содержит коэффициенты (слой блоков). CBP нужно не для всех типов макроблоков. Каждый блок завершается флагом EOB (End of Block).
Рис. 2.5.6. Размещение блоков в макроблоках Сама природа алгоритма кодирования и передачи графических данных такова, что число бит передаваемых в единицу времени зависит от характера изображения. Чем динамичнее изменяется картинка, тем больше поток данных. Для выравнивания потока данных широко используется буферизация. Буферизация в свою очередь порождает дополнительные задержки, которые в случае видео-конференций или видео-телефонии не должны превышать нескольких сотен миллисекунд. Так как при передаче изображения широко используются коды переменной длины, она крайне уязвима для любых искажений. В случае ошибки будет испорчена вся информация вплоть до следующего стартового кода GoB. Из-за рекурсивности алгоритма формирования картинки, искажения будут оставаться на экране довольно долго. Использование векторов перемещения может привести к дрейфу искажений по экрану и расширению их области. Для того чтобы уменьшить последствия искажений, в передаваемый информационный поток включаются коды коррекции ошибок BCH (511,493; Forward Error Correction Code), которые позволяют исправить любые две ошибки или кластер, содержащий до 6 ошибок в блоке из 511 бит (см. рис. 2.5.7). Алгоритм работает в широком диапазоне скоростей передачи информации. Для реализации коррекции ошибок в поток двоичных данных включается 8 пакетов, каждый из которых включает в себя 1 кадровый бит, 1 бит индикатор заполнения, 492 бита кодированных данных и 18 бит четности. Поле Fi (индикатор заполнения) может равняться нулю, тогда последующие 492 бита не являются графической информацией и могут игнорироваться. Алгоритм предназначен для работы в динамическом диапазоне частот 40:1.
Рис. 2.5.7 Схема передачи данных с коррекцией ошибок Во время переговоров или в ходе видеоконференции может возникнуть необходимость отобразить текст, выделить на экране какой-то объект, послать факс и т.д. Для решения таких задач можно использовать D-канал, но это не оптимально, так как он имеет свои специфические функции. Поэтому более привлекательным представляется создание специального протокола, работающего в рамках B-канала (H.221). Для этих целей используется младший бит каждого из октетов, что позволяет создать канал с пропускной способностью 8 Кбит/с. этот сервисный канал использует кадры по 80 бит. Первые 8 бит служат для целей синхронизации (FAS - Frame Alignment Signal) и выполняют следующие функции:
При работе с каналами на 384, 1536 и 1920 Кбит/с сервисный канал использует тайм-слот 1. Следующие 8 бит имеют название BAS (Bit Allocation Signal) и выполняют следующие функции:
Очевидно, что BAS-коды (H.242) должны быть надежно защищены от ошибок. Для этой цели они пересылаются с использованием кодов, допускающих коррекцию ошибок. При работе оба приемника непрерывно ищут разделительный код кадров. Когда он обнаружен, бит А для выходного канала делается равным нулю. Только после получения А=0 терминал может быть уверен в том, что удаленный терминал правильно воспринял код BAS. Работа с кодами BAS описана в документе H.242. При установлении режима обмена терминалы обмениваются командами BAS. Команда действительна для последующих двух кадров, следовательно, при частоте кадров 100 Гц, изменения режима могут производиться каждые 20 мс. Многоточечный вызов может рассматриваться как несколько связей между терминалами и бриджом MCU (Multipoint Control Unit) по схеме точка-точка. Простой MTU передает на каждый из терминалов смешанный аудио-сигнал от остальных терминалов. Каждый терминал осуществляет широковещательную передачу для остальных терминалов, участвующих в обмене. При видео обмене на терминал выводится только одна картинка. Дополнительную информацию по данной тематике можно найти в рекомендациях H.231, H242 и H.243. Для передачи нормального телевизионного изображения необходимо 364 Кбит/с (4х64 Кбит/c). Интеграция телевидения с сетями передачи данных, появление видеотелефона и широкое внедрение видеоконференций становится велением времени. Требования к каждому из этих видов услуг варьируется значительно в зависимости от приложения. Например, ставшие обычными телевизионные мосты требуют высокого качества передачи изображения и звука. А в некоторых дорогостоящих отраслях науки, где международное сотрудничество стало неизбежным, важным является передача статических изображений (чертежи, схемы, описания алгоритмов, и т.д.) с высоким (иногда более высоким, чем в телевидении) разрешением. Здесь важно передать звук с приемлемым качеством (но заметно хуже, чем на ТВ) и обеспечить синхронное перемещение маркера мыши по экрану в ходе обсуждения переданного документа. Экономия только на авиа билетах (не говоря о командировочных и времени экспертов) способна перекрыть издержки по оплате канала для видеоконференции. В этом режиме приемлемым может считаться один кадр в 1-4 секунды. Рисунок известного французского художника Клода Серрэ из книги "Черный юмор и люди в белом" (см. начало раздела) может служить иллюстрацией того, к чему может привести использование протокола tcp при передаче изображения в реальном масштабе времени. Предположим, что в процессе передачи изображения носа пакеты были повреждены, тогда спустя некоторое время, определяемое размером окна (TCP), будет проведена повторная их передача. Тем временем переданные ранее пакеты будут использованы для построения изображения, а часть картинки, содержавшаяся в пакетах, посланных вместо поврежденных, будет отображена совсем не там, где это следует. Реально из-за повреждения пакетов возможны в этой версии и более тяжелые искажения изображения. Именно это является причиной использования UDP для передачи видео и аудио информации при видео и аудио конференциях (еще лучшего результата можно достичь, использую протокол RTP). Протокол UDP не требует подтверждения и повторной передачи при ошибке доставки. Поврежденные пакеты вызовут искажения изображения (или звука) лишь локально. Ситуация меняется в случае посылки изображения или звукового послания по электронной почте. Здесь в случае повторной передачи пакетов в конечном итоге будет сформирован файл, уже не содержащий ошибок. Такое решение приемлемо всякий раз, когда большая задержка появления изображения или звука не играет никакой роли. Стандарт MPEG Стандарт MPEG-2 является усовершенствованием MPEG-1 и базируется на схеме шифрования с потерями и передачи без потерь. Кодирование в MPEG-2 идентично используемому в MPEG-1 (I- P- и B-кадры; В-кадры не используются). I-кадр (Intracoded) представляет собой изображение, закодированное согласно стандарту JPEG при полном разрешении по яркости и половинном разрешении по цвету. Такие кадры должны появляться периодически. Эти кадры обеспечивают совместимость с MPEG-1, и исключают влияние накопления ошибок в процессе передачи. P-кадры (Predictive) содержат отличие блоков в последнем кадре изображения (базируются на идее макроблоков). B-кадры (Bidirectional) характеризуют отличие двух последовательных изображений. Здесь применено двойное косинусное преобразование с числом коэффициентов 10*10 (против 8*8 в MPEG-1). MPEG-2 предназначен для широковещательного телевидения (включая прямое спутниковое - DBS) и для записи на CD-ROM и поддерживает четыре разных стандартов разрешения: 352*240 (низкое), 720*480 (базовое), 1440*1152 (высокое-1440) и 1920*1080 (высокое). Низкое разрешение служит для обеспечения совместимости с MPEG-1. Базовое разрешение ориентировано на работу со стандартом NTSC. Последние два стандарта относятся к телевидению высокого разрешения (HDTV). Помимо этого MPEG-2 поддерживает 5 профайлов для различных прикладных областей. Основной профайл ориентирован на общие приложения с базовым разрешением. Простой профайл сходен с основным профайлом, но не работает с B-кадрами, чтобы облегчить процедуры кодирования/декодирования. Остальные профайлы служат для обеспечения масштабируемости и работы с HDTV, они отличаются цветовым разрешением и форматами информационных потоков. Скорость передачи данных для каждой комбинации разрешения и профайла различна и лежит в диапазоне от 3 до 100 Мбит/c. Для обычного ТВ характерна скорость 3-4 Мбит/c. В таблице 2.5.2 представлены размеры кадров в битах для MPEG-1 и MPEG-2. Таблица 2.5.2. Размеры кадров MPEG-1 и MPEG-2
Мультиплексирование аудио- и видеоданных в MPEG-2 показано на рис. 2.5.8. На выходе пакетизатора мы имеем элементарные потоки пакетов (PES- Packetized Elementary Stream), содержащих около 30 полей, включая длину, идентификаторы потоков, временные метки, контрольные суммы и т.д. В MPEG-2 формируется два комплексных потока, программный поток (PS) длинных пакетов переменной длины сходный с MPEG-1, содержащий видео и аудио данные и имеющий общую временную шкалу, и транспортный поток (TS) пакетов постоянной длины (188 байт) без общей временной шкалы. В последнем случае минимизируется влияние потерь пакетов в процессе транспортировки. Предусмотрено выделение в потоке составляющих разной степени важности (например, DCT-коэффициентов и обычных графических данных).
Рис. 2.5.8. Мультиплексирование аудио и видео данных в MPEG-1 и MPEG-2 (внизу) Преобразование аналогового сигнала в цифровую последовательность осуществляется в MPEG-2 с помощью кодеков, создавая первичный поток в 140 Мбит/с, который затем преобразуется для передачи через стандартные каналы 1,5 и 15 Мбит/с (например, для прямого широковещательного, спутникового телевидения). В соответствии со стандартом сжатия данных H.320 можно обеспечить передачу видео + аудио по каналу 56 кбит/с с низким разрешением и частотой 1 кадр/сек. Смотри раздел "Видеоконференции по каналам ISDN и Интернет". Интерактивное телевидение В последнее время благодаря широкому внедрению цифрового телевидения и новых стандартов передачи изображения (MPEG-2) открылись возможности для "телевидения по требованию" (интерактивного телевидения) - системы, где клиент может самостоятельно и индивидуально формировать ТВ-программу. Первые опыты такого рода относятся к 1995 году. Такие системы базируются на существующих сетях кабельного телевидения. Но развитие оптоволоконных технологий позволяют ожидать полной интеграции кабельного цифрового телевидения и информационных сетей Интернет. Следует, впрочем, заметить, что оптоволокно в каждом жилище является пока непозволительной роскошью. Общая схема такой системы показана на рис. 2.5.9.
Рис. 2.5.9. Схема реализации интерактивного телевидения Базовый мультимедийный сервер может обслуживать отдельный район города. В пределах квартала размещается промежуточный центр, где размещается локальный буферный сервер, где записываются фрагменты программ, заказанные локальными клиентами. Только новостийные и некоторые спортивные программы передаются в реальном масштабе времени, все фильмы берутся из локальной фильмотеки или предварительно записываются в накопитель из центрального мультимедиа-сервера. Транспортной средой здесь может стать ATM, SDH или Fibre Channel. Оптическое волокно доходит до квартального сервера или даже до дома клиента. Индивидуальная раздача сигнала на терминалы (телевизоры) может осуществляться через существующие телевизионные кабели. В этом случае по имеющимся каналам может передаваться не только программа телевидения и осуществляться телефонные переговоры, но выполняться полное информационное обслуживание. Сюда может включаться, помимо заказа ТВ-программ, подписка на газеты, заказ билетов на транспорт или в театр, получение прогноза погоды и данных о состоянии дорог, доступ к базам данных, включая библиотеки и фонотеки и многое другое. Особый интерес представляет возможность практически полного вытеснения традиционных газет. Клиент сможет получать только интересующие его статьи из любых газет (и только их и оплачивать). Если какая-то статья его заинтересует и он захочет почитать ее позднее в машине или на даче, он сможет ее распечатать на принтере, подключенном к его телевизору-терминалу. Цены на цветные принтеры в настоящее время спустились ниже 100 долларов, таким образом нужная копия уже сейчас дешевле стоимости газеты. Экономия на бумаге и средствах доставки очевидны, да и необходимость в типографиях отпадет, ведь даже книги можно будет получить непосредственно дома (хотя привлекательность данной услуги и не вполне очевидна - хорошо сброшированная и переплетенная книга будет привлекательным объектом еще долго (прогноз относительно будущих книг сотри в разделе "Заключение"). Массовое внедрение таких технологий будет стимулировать падение цен на соответствующие процессоры и принтеры. Интерактивная схема подключения телевизора-терминала сделает возможным многие новые виды развлечений, а также выполнение многих покупок, не выходя из дома. Традиционной почте подписала отсроченный приговор почта электронная, но появление интерактивных широкополосных средств завершит многовековую историю почты (да и телеграфа). Ей будет оставлена доставка товаров, билетов и документов. Побочным продуктом прогресса в данной области станет общедоступный видеотелефон. В жилье клиента будет входить оптоволоконный кабель, завершающийся интерфейсной коробкой с разъемами для подключения телефона, телевизора и ЭВМ. Даже современные ограниченные скорости передачи позволяют решить стоящие проблемы. Во-первых люди не смотрят телевизор круглые сутки, это позволяет ночью или в рабочее время, когда клиент на службе, произвести передачу нужных фрагментов ТВ-программы на локальный сервер. Во-вторых популярность фильмов и программ не однородна, что также снижает требование на широкополосность. Известно, что наиболее популярный фильм запрашивается примерно в К раз чаще, чем фильм, занимающий к-ое место в списке популярности (эмпирический закон Ципфа (Zipf), выведенный из статистики контор по прокату видеокассет). Это означает, что из предлагаемого списка будут выбраны не все фильмы, а наиболее популярные фрагменты программ можно передавать по схеме MBONE, минимизируя загрузку каналов (смотри также описание протокола PIM). Способствовать решению данной проблемы будет и появление CD с емкостью 4 Гбайта. Но проблем здесь остается немало, так трудно себе представить, что все клиенты захотят смотреть один и тот же фильм в одно время. Решение подобной задачи потребует очень большого объема буферной памяти и ощутимо поднимет требования к широкополосности канала. "Синхронизовать" клиентов можно будет дифференциацией оплаты для разных временных интервалов, и группированием клиентов, заказавших близкие времена начала демонстрации фильмов, путем предварительного оповещения. Но несмотря на все эти ухищрения, локальные серверы должны будут иметь сложную иерархическую систему буферной памяти, базирующейся на разных принципах работы (CD, магнитная лента, дисковая память и даже RAM). Практическая реализация фантастической схемы, предложенной в предыдущем абзаце, уже осуществляется в США и Канаде. Здесь есть немало проблем, например, нужен дешевый широкополосный кабельный модем (смотри раздел "Модемы", там же приведена схема подключения телевизора-терминала через кабельный модем). Предстоит написать огромное число различных сервисных программ, но все базовые технологии уже существуют. |
|||||||||||||||||||||||||||||||||||
|
Previous:
2.4.3 Передача голоса по каналам Интернет
UP:
2.4 Методы преобразования и передачи звуковых сигналов
|
|||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.5.1 Стандарт MPEG-4
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MPEG-4 является стандартом ISO/IEC разработанным MPEG (Moving Picture Experts Group), комитетом, который разработал такие известные стандарты как MPEG-1 и MPEG-2. Эти стандарты сделали возможным интерактивное видео на CD-ROM и цифровое телевидение. MPEG-4 является результатом работы сотен исследователей и разработчиков всего мира. Разработка MPEG-4 (в ISO/IEC нотации имеет название ISO/IEC 14496) завершена в октябре 1998. Международным стандартом он стал в начале 1999. Полностью совместимый расширенный вариант MPEG-4 версия 2 был разработан к концу 1999 и стал международным стандартом в начале 2000. Работы над этим документом продолжаются (см. http://sound.media.mit.edu/mpeg4/SA-FDIS.pdf). MPEG-4 предназначен для решения трех проблем:
Стандарт можно купить в ISO, связь через e-mail:sales@iso.ch. Программное обеспечение MPEG-4 может быть получено через сеть по адресу: www.iso.ch/ittf. Эти программы бесплатны, но это не означает, что они не защищены патентами. Смотри также http://mpeg.telecomitalialab.com/standards/mpeg-4/mpeg-4.htm. 1. Особенности стандарта MPEG-4 Стандарт MPEG-4 предоставляет технологии для нужд разработчиков, сервис-провайдеров и конечных пользователей.
Стандарт MPEG-4 определяет следующее:
1.1. Кодированное представление медийных объектов Аудиовизуальные сцены MPEG-4 формируются из нескольких медийных объектов, организованных иерархически. На периферии иерархии находятся примитивные медийные объекты, такие как:
MPEG-4 стандартизует число таких примитивных медиа-объектов, способных представлять как естественные, так и синтетические типы содержимого, которые могут быть 2- или 3-мерными. Кроме медиа-объектов, упомянутых выше и показанных на рис. 1, MPEG-4 определяет кодовое представление объектов, такое как: ∙ текст и графика; Медиа-объекты в его кодированной форме состоит из описательных элементов, которые позволяют обрабатывать его в аудио-визуальной сцене, а также, если необходимо, ассоциированный с ним поток данных. Важно заметить, что кодированная форма, каждого медиа-объекта может быть представлена независимо от его окружения или фона. Кодовое представление медиа-объектов максимально эффективно с точки зрения получения необходимой функциональности. Примерами такой функциональности являются разумная обработка ошибок, легкое извлечение и редактирование объектов и представление объектов в масштабируемой форме. 1.2. Состав медийных объектов На рис. 1 объясняется способ описание аудио-визуальных сцен в MPEG-4, состоящих из отдельных объектов. Рисунок содержит составные медиа-объекты, которые объединяют примитивные медиа-объекты. Примитивные медиа-объекты соответствуют периферии описательного дерева, в то время как составные медиа-объекты представляют собой суб-деревья. В качестве примера: визуальные объекты, соответствующие говорящему человеку, и его голос объединены друг с другом, образуя новый составной медиа-объект. Такое группирование позволяет разработчикам создавать комплексные сцены, а пользователям манипулировать отдельными или группами таких объектов. MPEG-4 предлагает стандартизованный путь описания сцен, позволяющий:
Описание сцены строится во многих отношениях также как и в языке моделирования виртуальной реальности VRML (Virtual Reality Modeling language).
Рис. 1. Пример сцены MPEG-4 1.3. Описание и синхронизация потоков данных для медийных объектов Медиа-объектам может быть нужен поток данных, который преобразуется в один или несколько элементарных потоков. Дескриптор объекта идентифицирует все потоки ассоциированные с медиа-объектом. Это позволяет иерархически обрабатывать кодированные данные, а также ассоциированную медиа-информацию о содержимом (называемом "информация содержимого объекта"). Каждый поток характеризуется набором дескрипторов для конфигурирования информации, например, чтобы определить необходимые ресурсы записывающего устройства и точность кодированной временной информации. Более тог, дескрипторы могут содержать подсказки относительно QoS, которое необходимо для передачи (например, максимальное число бит/с, BER, приоритет и т.д.) Синхронизация элементарных потоков осуществляется за счет временных меток блоков данных в пределах элементарных потоков. Уровень синхронизации управляет идентификацией таких блоков данных (модулей доступа) и работой с временными метками. Независимо от типа среды, этот слой позволяет идентифицировать тип модуля доступа (например, видео или аудио кадры, команды описания сцены) в элементарных потоках, восстанавливать временную базу медиа-объекта или описания сцены, и осуществлять их синхронизацию. Синтаксис этого слоя является конфигурируемым самыми разными способами, обеспечивая работу с широким спектром систем. 1.4. Доставка потоков данных Синхронизованная доставка потока данных отправителя получателю, использующая различные QoS, доступные в сети, специфицирована в терминах слоя синхронизации и доставки, которые содержат двухслойный мультиплексор (см. рис. 2). Первый слой мультиплексирования управляется согласно спецификации DMIF (Delivery Multimedia Integration Framework). Это мультиплексирование может быть реализовано определенным в MPEG мультиплексором FlexMux, который позволяет группировать элементарные потоки ES (Elementary Streams) с низкой избыточностью. Мультиплексирование на этом уровне может использоваться, например, для группирования ES с подобными требованиями по QoS, чтобы уменьшить число сетевых соединений или значения задержек. Слой "TransMux" (Transport Multiplexing) на рис. 2 моделирует уровень, который предлагает транспортные услуги, удовлетворяющие требованиям QoS. MPEG-4 специфицирует только интерфейс этого слоя, в то время как остальные требования к пакетам данных будут определяться транспортным протоколом. Любой существующий стек транспортных протоколов, например, (RTP)/UDP/IP, (AAL5)/ATM, или MPEG-2 Transport Stream поверх подходящего канального уровня может стать частным случаем TransMux. Выбор оставлен за конечным пользователем или серис-провайдером, и позволяет использовать MPEG-4 с широким спектром операционного окружения. Рис. 2. Модель системного слоя MPEG-4 Использование мультиплексора FlexMux является опционным и, как показано на рис. 2, этот слой может быть пустым, если нижележащий TransMux предоставляет все необходимые функции. Слой синхронизации, однако, присутствует всегда. С учетом этого возможно:
1.5. Взаимодействие с медийными объектами Пользователь видит сцену, которая сформирована согласно дизайну разработчика. В зависимости от степени свободы, предоставленной разработчиком, пользователь имеет возможность взаимодействовать со сценой. Пользователю могут быть разрешены следующие операции:
1.6. Менеджмент и идентификация интеллектуальной собственности Важно иметь возможность идентифицировать интеллектуальную собственность в MPEG-4 медиа-объектах. Полный перечень требований для идентификации интеллектуальной собственности можно найти на базовой странице MPEG в разделе 'Management and Protection of Intellectual Property'. MPEG-4 включает в себя идентификацию интеллектуальной собственности путем запоминания уникальных идентификаторов, которые выданы международными системами нумерации (например ISAN, ISRC, и т.д. [ISAN: International Audio-Visual Number, ISRC: International Standard Recording Code]). Эти числа могут использоваться для идентификации текущего владельца прав медиа-объекта. Так как не все содержимое идентифицируется этим числом, MPEG-4 версия 1 предлагает возможность идентификации интеллектуальной собственности с помощью пары ключевых значений (например:"композитор"/"John Smith"). Кроме того, MPEG-4 предлагает стандартизованный интерфейс, который тесно интегрирован с системным слоем для людей, которые хотят использовать системы, контролирующие доступ к интеллектуальной собственности. С этим интерфейсом системы контроля прав собственности могут легко интегрироваться со стандартизованной частью декодера. 2. Основные функции в MPEG-4 версия 1 2.1. DMIF DMIF поддерживает следующие функции:
2.2. Системы Как объяснено выше, MPEG-4 определяет набор алгоритмов улучшенного сжатия для аудио и видео данных. Потоки данных (Elementary Streams, ES), которые являются результатом процесса кодирования, могут быть переданы или запомнены независимо. Они должны быть объединены так, чтобы на принимающей стороне возникла реальная мультимедийная презентация. Системные части MPEG-4 обращаются к описаниям взаимодействий между аудио и видео компонентами, которые образуют сцену. Эти взаимодействия описаны на двух уровнях.
Некоторые другие особенности работы системы MPEG-4:
2.3. Аудио-система MPEG-4 аудио предлагает широкий перечень приложений, которые покрывают область от понятной речи до высококачественного многоканального аудио, и от естественных до синтетических звуков. В частности, он поддерживает высокоэффективную презентацию аудио объектов, состоящих из:
Примерами дополнительной функциональности является возможность управления скоростью обмена и масштабируемость в отношении потоков данных, полосы пропускания, вероятности ошибок, сложности, и т.д. как это определено ниже.
2.4. Видео-система Стандарт MPEG-4 Видео допускает гибридное кодирование естественных (пиксельных) изображений и видео вместе с синтезированными сценами (генерированными на ЭВМ). Это, например, допускает виртуальное присутствие участников видеоконференций. Видео стандарт содержит в себе средства и алгоритмы, поддерживающие кодирование естественных (пиксельных) статических изображений и видео последовательностей, а также средства поддержки сжатия искусственных 2-D и 3-D графических геометрических параметров. 2.4.1. Поддерживаемые форматы Следующие форматы и скорости передачи будут поддерживаться MPEG-4 версия 1: ∙ Скорости передачи: обычно между 5 кбит/с и 10 Mбит/с 2.4.2. Эффективность сжатия
2.4.3. Функции, зависящие от содержимого (Content-Based)
2.4.4. Масштабируемость текстур изображений и видео 2.4.5. Кодирование формы и Alpha-представление Alpha-плоскость определяет прозрачность объекта, которая не обязательно является однородной. Многоуровневые alpha-карты часто используются для затенения различных слоев последовательности изображений. Другими приложениями, которые используют при работе с изображениями ассоциированные двоичные alpha-маски, являются презентации баз данных изображений, интерактивные игры, наблюдения, и анимация. Предлагаются методики, которые позволяют эффективно кодировать двоичные и альфа-плоскости с серой шкалой изображения. Двоичная альфа-маска определяет, принадлежит ли пиксель данному объекту. Маска с серой шкалой предоставляет возможность точно определить прозрачность каждого пикселя. 2.4.6. Надежность в средах, подверженных ошибкам Устойчивость к ошибкам будет поддерживаться, чтобы обеспечить доступ к изображениям и видео через широкий спектр систем памяти и передающих сред. Это включает в себя операции алгоритмов сжатия данных в среде, подверженной сбоям при низких скоростях передачи (т.e., меньше чем 64 Кбит/с). 2.4.7. Анимация лица Часть стандарта, связанная с 'анимацией лица', позволяет посылать параметры, которые помогают специфицировать и анимировать синтезированные лица. Эти модели не являются сами частью стандарта MPEG-4, стандартизированы только параметры. ∙ Определение и кодирование анимационных параметров лица (модельно независимое): 2.4.8. Кодирование 2-D сеток с нечетко выраженной структурой ∙ Предсказание, базирующееся на сетке, и трансфигурация анимационных текстур 3. Главные функции в MPEG-4 версия 2 Версия 2 была зафиксирована в декабре 1999. Существующие средства и профайлы из версии 1 в версии 2 не заменены; новые возможности будут добавлены в MPEG-4 в форме новых профайлов. Системный слой версии 2 обладает обратной совместимостью с версией 1. 3.1. Системы Версия 2 систем MPEG-4 расширяет версию 1, с тем, чтобы перекрыть такие области, как BIFS-функциональность и поддержка Java (MPEG-J). Версия 2 также специфицирует формат файлов для записи содержимого MPEG-4. 3.2. Видео-системы 3.2.1. Натуральное видео Видео MPEG-4 версия 2 добавляет новые возможности в следующих областях: 3.2.2. Анимация тела В версии 2 к анимации лица, существовавшей в версии 1, добавлена анимация тела. 3.2.3. Кодирование 3-D полигональных сеток Версия 2 MPEG-4 предоставляет набор средств для кодирования многогранных 3-D сеток. Многогранные сетки широко используются для представления 3-D объектов. 3.3. Звук MPEG-4 Аудио версия 2 является расширением MPEG-4 Аудио версия 1. В новой версии добавлены новые средства и функции, все прежние возможности и функции сохранены. Версия 2 MPEG-4 Аудио предоставляет следующие возможности: 3.4. DMIF Основные средства, вводимые DMIF версия 2 предоставляют поддержку (ограниченную) мобильных сетей и мониторирования QoS. 3.4.1. Поддержка мобильных сетей Спецификация H.245 была расширена (H.245v6), чтобы добавить поддержку систем MPEG-4; спецификация DMIF предоставляет возможность работу с сигналами H.245. Мобильные терминалы могут теперь использоваться системами MPEG-4, такими как BIFS и OD-потоки. 3.4.2. Мониторирование QoS DMIF V.2 вводит концепцию мониторирования качества обслуживания (QoS). Реализуемого в сети. Интерфейс DMIF-приложения был соответственно расширен. Модель допускает до трех различных режимов мониторирования QoS: непрерывное мониторирование, контроль специфических очередей, и наблюдение за нарушениями QoS 3.4.3. Пользовательские команды с ACK Модель DMIF позволяет приложениям партнеров обмениваться любыми сообщениями пользователей (поток управляющих сообщений). В DMIF V2 добавлена поддержка сообщений-откликов. 3.4.4. Управление информацией уровня Sync MPEG-4 V.2 улучшает модель DMIF, чтобы позволить приложениям обмениваться прикладными данными со слоем DMIF. Это добавление было введено, чтобы сделать возможным в пределах модели обмен блоками протокольных данных уровня Sync. Это комбинация чисто медийных данных (PDU) и логической информации уровня Sync. Модель подтверждает, что в пределах существующего транспортного стека существуют средства, которые перекрываются с Sync-слоем систем MPEG-4. Это случай RTP и MPEG-2 элементарных потоков пакетов PES (Packetized Elementary Steams), а также MP4-атомов в файловом формате. Во всех таких случаях очевидной реализацией DMIF является преобразование информации уровня Sync, извлеченной из этих структур, а также из SL-PDU, в однородное логическое представление заголовка пакета уровня Sync. Как следствие, введены соответствующие параметры для DAI, с учетом обеспечения их семантической независимости от транспортного стека и приложения. 3.4.5. DAI-синтаксис на языке СИ DMIF V.2 вводит информативное дополнение, который предоставляет синтаксис C/C++ для прикладного интерфейса DMIF, как это рекомендуется API-синтаксисом. 4. Расширения MPEG-4 за пределы версии 2 MPEG в настоящее время работает с номером расширения версии 2, в визуальной и системной областях. Никаких работ по расширению MPEG-4 DMIF или Аудио за пределы версии 2 не проводились. 4.1. Визуальная область системы В визуальной области подготавливается добавление следующих методик: 4.2. Системы 4.2.1. Advanced BIFS Продвинутый BIFS предоставляет дополнительные узлы, которые могут быть использованы в графе сцены для мониторирования доступности и управляемости среды, такие как посылка команд серверу, продвинутый контроль воспроизведения, и так называемый EXTERNPROTO, узел, который обеспечивает дальнейшую совместимость с VRML, и который позволяет написание макросов, определяющих поведение объектов. Предусмотрено улучшенное сжатие данных BIFS, и в частности оптимальное сжатие для сеток и для массивов данных. 4.2.2. Текстуальный формат Расширяемый текстовой формат MPEG-4 XMT (Extensible Textual format) является базовым для представления MPEG-4 описаний сцен, использующих текстовой синтаксис. XMT позволяет авторам текста обмениваться его содержимым друг с другом. Консорциумом Web3D разработаны средства обеспечения совместимости с расширяемым X3D (Extensible 3D), и интеграционным языком синхронизованного мультимедиа SMIL (Synchronized Multimedia Integration Language) от консорциума W3C. Формат XMT может быть изменен участниками SMIL, VRML, и MPEG-4. Формат может быть разобран и воспроизведен непосредственно участником W3C SMIL, преобразован в Web3D X3D и заново воспроизведен участником VRML, или компилирован в презентацию MPEG-4, такую как mp4, которая может быть затем воспроизведена участником MPEG-4. Ниже описано взаимодействие с XMT. Это описание содержит в себе MPEG-4, большую часть SMIL, масштабируемую векторную графику (Scalable Vector Graphics), X3D, а также текстуальное представление описания MPEG-7 (смотри http://www.cselt.it/mpeg, где имеется документация на стандартe MPEG-7). XMT содержит два уровня текстуального синтаксиса и семантики: формат XMT-A и формат XMT-Ù. XMT-A является версией MPEG-4, базирующейся на XML, содержащей субнабор X3D. В XMT-A содержится также расширение MPEG-4 для X3D, что бы работать с некоторыми специальными средствами MPEG-4. XMT-A предоставляет прямое соответствие между текстовым и двоичным форматами. XMT-Ù является абстракцией средств MPEG-4 высокого уровня, базирующейся на W3C SMIL. XMT предоставляет по умолчанию соответствие Ù и A. 4.2.3. Улучшенная модель синхронизации Продвинутая модель синхронизации (обычно называемая 'FlexTime') поддерживает синхронизацию объектов различного происхождения с возможно разной временной шкалой. Модель FlexTime специфицирует временную привязку, используя гибкую модель с временными ограничениями. В этой модели, медиа-объекты могут быть связаны друг с другом в временном графе с использованием таких ограничений как "CoStart", "CoEnd", или "Meet". И, кроме того, для того чтобы обеспечить определенную гибкость и адаптацию к этим ограничениям, каждый объект может иметь адаптируемую длительность с определенными предпочтениями для растяжения и сжатия, которые могут быть применены. Модель FlexTime базируется на так называемой метафоре "пружины". Пружина имеет три ограничения: минимальная длина, менее которой она не сжимается, максимальная длина, при которой она может оборваться, и оптимальная длина, при которой она остается ни сжатой, ни растянутой. Следуя модели пружины, временные воспроизводимые медиа-объекты могут рассматриваться как пружины, с набором длительностей воспроизведения, соответствующих этим трем ограничениям пружины. Оптимальная длительность воспроизведения (оптимальная длина пружины) может рассматриваться как предпочтительный выбор автора для длительности воспроизведения медиа-объекта. Участник, где возможно, поддерживает длительность воспроизведения настолько близко к оптимальному значению, насколько позволяет презентация, но может выбрать любую длительность между минимальной и максимальной, как это специфицировал автор. Заметим, что поскольку растяжение или сжатие длительности в непрерывных средах, например, для видео, подразумевает соответствующее замедление или ускорение воспроизведения, для дискретных сред, таких как статическое изображение, сжатие или растяжение сопряжено в основном с модификацией периода рэндеринга. 5. Профайлы в MPEG-4 MPEG-4 предоставляет большой и богатый набор средств для кодирования аудио-визуальных объектов. Для того чтобы позволить эффективную реализацию стандарта, специфицированы субнаборы систем MPEG-4, средств видео и аудио, которые могут использоваться для специфических приложений. Эти субнаборы, называемые 'профайлами', ограничивают набор средств, которые может применить декодер. Для каждого из этих профайлов, устанавливается один или более уровней, ограничивающих вычислительную сложность. Подход сходен с MPEG-2, где большинство общеизвестных комбинаций профайл/уровень имеют вид 'главный_профайл @главный_уровень'. Комбинация профайл@уровень позволяет: ∙ конфигуратору кодека реализовать только необходимый ему субнабор стандарта, Существуют профайлы для различных типов медиа содержимого (аудио, видео, и графика) и для описания сцен. MPEG не предписывает или рекомендует комбинации этих профайлов, но заботится о том, чтобы обеспечить хорошее согласование между различными областями. 5.1. Визуальные профайлы Визуальная часть стандарта предоставляет профайлы для кодирования естественного, синтетического и гибридного типов изображений. Существует пять профайлов для естественного видео-материала: 1. Простой визуальный профайл обеспечивает эффективное, устойчивое к ошибкам кодирование прямоугольных видео объектов, подходящих для приложений мобильных сетей, таких как PCS и IMT2000. 2. Простой масштабируемый визуальный профайл добавляет поддержку кодирования временных и пространственных, масштабируемых объектов в простом визуальном профайле. Он полезен для приложений, которые обеспечивают услуги на более чем одном уровне качества, связанных с ограничениями скорости передачи данных или ресурсами декодера, такими как использование Интернет и программное декодирование. 3. Центральный визуальный профайл добавляет поддержку кодировки время-масштабируемых объектов произвольной формы в простой визуальный профайл. Он полезен для приложений, осуществляющих относительно простую интерактивность (приложения Интернет мультимедиа). 4. Главный визуальный профайл добавляет поддержку кодирования черезстрочных, полупрозрачных, и виртуальных объектов в центральном визуальном профайле. Он полезен для интерактивного широковещательного обмена (с качеством для развлечений) и для DVD-приложений. 5. N-битный визуальный профайл добавляет поддержку кодирования видео объектов, имеющих пиксельную глубину в диапазоне от 4 до 12 бит в главный визуальный профайл. Он удобен для использования в приложениях для наблюдения. Профайлами для синтетических и синтетико-натуральных гибридных визуальных материалов являются: 6. Простой визуальный профайл для анимации лица (Simple Facial Animation) предоставляет простые средства анимации модели лица, удобные для таких приложений как аудио/видео презентации лиц с ухудшенным слухом. 7. Визуальный масштабируемый профайл для текстур (Scalable Texture Visual) предоставляет пространственное масштабируемое кодирование статических объектов изображений (текстур), полезное для приложений, где нужны уровни масштабируемости, такие как установление соответствия между текстурой и объектами игр, а также работа с цифровыми фотокамерами высокого разрешения. 8. Визуальный профайл базовых анимированных 2-D текстур (Basic Animated 2-D Texture) предоставляет пространственную масштабируемоcть, SNR- масштабируемоcть, и анимацию, базирующуюся на сетках для статических объектов изображений (текстур), а также простую анимацию объектов лица. 9. Гибридный визуальный профайл комбинирует возможность декодировать масштабируемые объекты натурального видео произвольной формы (как в главном визуальном профайле) с возможностью декодировать несколько синтетических и гибридных объектов, включая анимационные статические объекты изображения. Он удобен для различных сложных мультимедиа приложений. Версия 2 добавляет следующие профайлы для натурального видео: 10. Профайл ARTS (Advanced Real-Time Simple) предоставляет продвинутый метод кодирования прямоугольных видео объектов устойчивый к ошибкам, использующий обратный канал и улучшенную стабильность временного разрешения при минимальной задержке буферизации. Он удобен для кодирования в случае приложений реального времени, таких как видеотелефон, телеконференции и удаленное наблюдение. 11. Центральный масштабируемый профайл добавляет поддержку кодирования объектов произвольной формы с пространственным и временным масштабированием в центральный профайл. Главная особенность этого профайла является SNR, и пространственная и временная масштабируемость для областей и объектов, представляющих интерес. Он полезен для таких приложений как Интернет, мобильные сети и широковещание. 12. Профайл ACE (Advanced Coding Efficiency) улучшает эффективность кодирования для прямоугольных объектов и объектов произвольной формы. Он удобен для таких приложений как мобильный широковещательный прием, и другие приложения, где необходимо высокая эффективность кодирования. Профайлы версии 2 для искусственного и синтетического/натурального гибридного визуального материала: 13. Продвинутый масштабируемый профайл текстур поддерживает декодирование текстур произвольной формы и статических изображений, включая масштабируемое кодирование формы, мозаичное заполнение и противостояние ошибкам. Он полезен для приложений, требующих быстрого произвольного доступа, а также нескольких уровней масштабируемости и кодирования статических объектов произвольной формы. Примерами таких приложений могут служить просмотр статических изображений в Интернет, а также считывание через Интернет изображений, полученных из цифровых фотоаппаратов с высоким разрешением. 14. Продвинутый центральный профайл комбинирует возможность декодирования видео объектов произвольной формы (как в центральном визуальном профайле) с возможностью декодирования масштабируемых статических объектов произвольной формы (как в продвинутом масштабируемом профайле текстур.) Он удобен для различных мультимедийных приложений, таких как интерактивная передача потоков мультиимедиа через Интернет. 15. Профайл простой анимации лица и тела является супернабором профайла простой анимации лица с добавлением анимации тела. В последующих версиях будут добавлены следующие профайлы: 16. Продвинутый простой профайл выглядит как простой, здесь он содержит только прямоугольные объекты, но он имеет несколько дополнительных средств, которые делают его более эффективным: B-кадры, компенсация перемещения ¼ пикселя и компенсация общего перемещения. 17. Масштабируемый профайл тонкой гранулярности допускает большое число масштабных уровней - до 8 - так что качество доставки можно легко адаптировать к условиям передачи и декодирования. Он может использоваться с простым или продвинутым простым в качестве базового уровня. 18. Простой студийный профайл является профайлом с очень высоким качеством для применения в приложениях студийного редактирования. Он работает только с I-кадрами, но он действительно поддерживает произвольные формы и большое число alpha-каналов. Возможная скорость передачи достигает 2 Гбит/c. 19. Центральный студийный профайл добавляет P-кадры к простому студийному варианту ( Simple Studio), делая его более эффективным, но требующим более сложной реализации. 5.2. Аудио профайлы Определены четыре аудио-профайла в MPEG-4 V.1: Еще четыре профайла добавлено в MPEG-4 V.2: 5.3. Профайлы графики Профайлы графики определяют, какие графические и текстовые элементы могут использоваться в данной сцене. Эти профайлы определены в системной части стандарта: 5.4. Графические профайлы сцены Графические профайлы сцены (или профайлы описания сцены), определенные в системной части стандарта, допускают аудио-визуальные сцены только аудио, 2-мерным, 3-мерным или смешанным 2-D/3-D содержимым. 5.5. Профайлы MPEG-J Существуют два профайла MPEG-J: персональный и главный: 1. Персональный - небольшой пакет для персональных приборов. Персональный профайл обращается к ряду приборов, включая мобильные и портативные аппараты. Примерами таких приборов могут быть видео микрофоны, PDA, персональные игровые устройства. Этот профайл включает в себя следующие пакеты MPEG-J API: a) Сеть 1. Главный - включает все MPEG-J API. Главный профайл обращается к ряду приборов, включая средства развлечения. Примерами таких приборов могут служить набор динамиков, компьютерные системы мультимедиа и т.д. Он является супер набором персонального профайла. Помимо пакетов персонального профайла, этот профайл содержит следующие пакеты MPEG-J API: a) Декодер 5.6. Профайл дескриптора объекта Профайл описания объекта включает в себя следующие средства: В настоящее время определен только один профайл, который включает все эти средства. В контексте слоев для этого профайла могут быть определены некоторые ограничения, например, допуск только одной временной шкалы. 6. Верификационное тестирование: проверка работы MPEG MPEG выполняет верификационные тесты для проверки того, предоставляет ли стандарт то, что должно быть. Результаты испытаний можно найти на базовой странице MPEG: http://www.cselt.it/mpeg/quality_tests.htm 6.1. Видео 6.1.1.1. Низкие и средние скорости передачи бит (версия 1) При испытаниях для низкой и средней скорости передачи, рассматривались последовательности кадров, которые следуют стандарту MPEG-1. (MPEG-2 будет идентичным для прогрессивных последовательностей за исключением того, что MPEG-1 немного более эффективен, так как имеет несколько меньшую избыточность заголовков). Тест использует типовую тестовую последовательность для разрешений CIF и QCIF, закодированный с идентичными условиями по скорости передачи для MPEG-1 и MPEG-4. Тест был выполнен для низких скоростей от 40 кбит/с до 768 кбит/с. Тесты эффективности кодирования показывают полное превосходство MPEG-4 перед MPEG-1 как на низкой, так и на средней скорости передачи. 6.1.1.2. Кодирование, базирующееся на содержимом (версия 1) Верификационные тесты для кодирования, базирующегося на содержимом, сравнивают визуальное качество кодирования object-based и frame-based. Главным соображением было гарантировать, чтобы object-based кодирование можно было поддерживать без ухудшения визуального качества. Содержимое теста было выбрано так, чтобы перекрыть широкий спектр условий моделирования, включая видео сегменты с различными типами движения и сложностью кодирования. Кроме того, условия теста были выбраны так, чтобы перекрыть низкие скорости передачи в диапазоне от 256 кбит/с до 384 кбит/с, и высокие скорости передачи в диапазоне от 512кбит/с до 1.15 Мбит/с. Результаты тестов ясно продемонстрировали, что объектно-ориентированная функциональность, предоставляемая MPEG-4, не имеет избыточности или потерь визуального качества, по сравнению с кодированием frame-based. Не существует статистически значимого различия между вариантами object-based и frame-based. 6.1.1.3. Профайл продвинутой эффективности кодирования ACE (Advanced Coding Efficiency) (версия 2) Формальные верификационные тесты профайла ACE (Advanced Coding Efficiency) были выполнены с целью проверки, улучшают ли эффективность кодирования три новые средства версии 2, включенные в визуальный ACE профайл MPEG-4 версии 2 (компенсация общего перемещения, компенсация перемещения на четверть пикселя и адаптированное к форме преобразование DCT), по сравнению с версией 1. Тесты исследуют поведение ACE профайла и главного визуального профайла MPEG-4 версия 1 в режимах object-based и frame-based при низкой скорости передачи, frame-based при высокой скорости передачи. Полученные результаты показывают преимущество ACE профайла перед главным профайлом. Ниже приведены некоторые детали сопоставления работы этих профайлов: При интерпретации этих результатов, нужно заметить, что главный профайл MPEG-4 более эффективен, чем MPEG-1 и MPEG-2. 6.1.2. Тесты устойчивости к ошибкам Устойчивость видео к ошибкам в простом профайле MPEG-4 была оценена в ходе тестов, которые симулируют видео MPEG-4, выполненных при скоростях между 32 кбит/с и 384 кбит/с. Испытания произведены при BER < 10-3, и средней длине блока ошибок около 10мс. Тестовая методология базировалась на непрерывной оценке качества в течение 3 минут. Результаты показывают, что в среднем качество видео, полученное для мобильного канала, является высоким, что воздействие ошибок в видео MPEG-4 остается локальным, и что качество быстро восстанавливается по завершении блока ошибок. 6.1.2.2. Простой продвинутый профайл реального времени ARTS (Advanced Real-Time Simple) (версия 2) Устойчивость видео к ошибкам в MPEG-4 профайле ARTS была оценена в ходе тестов, аналогичных описанным выше, при скоростях между 32 кбит/с и 128 кбит/с. В этом случае, остаточный уровень ошибок достигал 10-3, а средняя длительность блока ошибок была около 10 мс или 1 мс. Результаты испытаний показывают превосходство профайла ARTS над простым профайлом для всех параметров исследования. Профайл ARTS предпочтительнее простого по времени восстановления после прохождения блока ошибок. 6.1.3. Тестирование стабильности временного разрешения В данном тесте исследовались характеристики видео кодека, использующего технику преобразования с динамическим разрешением, которая адаптирует разрешение видео материала к обстоятельствам в реальном времени. Материал активной сцены кодировался при скоростях 64 кбит/с, 96 кбит/с и 128 кбит/с. Результаты показывают, что при 64 кбит/с, он превосходит простой профайл, работающий при 96 кбит/с, а при 96 кбит/с, визуальное качество эквивалентно полученному для простого профайла при 128 кбит/с. 6.1.4. Проверки масштабируемости Тест масштабируемости для простого масштабируемого профайла был создан для проверки того, что качество, обеспечиваемое средством временной масштабируемости в простом, масштабируемом профайле, сравненное с качеством, предоставляемым одноуровневым кодированием в простом профайле, и с качеством, обеспечиваемым в простом профайле. В этом тесте используются 5 последовательностей с 4 комбинациями скоростей передачи: a) 24 кбит/с для базового слоя и 40 кбит/с для улучшенного слоя. Формальные верификационные тесты показали, что при всех условиях, кодирование с временной масштабируемостью в простом масштабируемом профайле демонстрирует то же или несколько худшее качество, чем достижимое при использовании однослойного кодирования в простом профайле. Далее, очевидно, что кодирование с временной масштабируемостью в простом масштабируемом профайле обеспечивает лучшее качество, чем симулкастное (одновременная передача по радио и телевидению или передача несколькими потоками с разной скоростью) кодирование в простом профайле для тех же условий. 6.1.4.2. Центральный профайл (core profile версия 1) Верификационный тест был создан для оценки характеристик средств временной масштабируемости MPEG-4 видео в центральном профайле (Core Profile). Тестирование было выполнено с использованием метода "Single Stimulus". Тест создавался с использованием 45 субъектов из двух различных лабораторий. Результаты испытаний показывают, что качество последовательностей, закодированных с привлечением средств временного масштабирования сопоставимы по качеству с вариантом без масштабирования. Очевидно также, что средство временного масштабирования в центральном профайле обеспечивает лучшее качество при равных условиях, чем симулкастное кодирование в центральном профайле. 6.2. Звук Аудио-технология MPEG-4 состоит из большого числа средств кодирования. Верификационные тесты выполнялись в основном для небольшого набора средств кодирования, которые имеет сходные области использования, чтобы их можно было сравнивать. Так как сжатие является критическим параметром в MPEG, сравнение производилось при сходных скоростях обмена.
Первоначальной целью тестов является получение субъективного уровня качества средства кодирования, работающего при заданной скорости обмена. Большинство аудио тестов представляют результаты в виде субъективной шкалы оценки качества. Это непрерывная шкала с максимальным значением 5 баллов, как это показано в табличке выше. Работа различных средств кодирования MPEG-4 представлена в таблице ниже. Для лучшей оценки свойств технологии MPEG-4 в тесты были включены несколько кодировщиков от MPEG-2 и ITU-T и их оценка также включены в таблицу. Результаты из различных тестов не следует сравнивать.
При кодировании 5-канального материала при 64 кбит/с/канал (320 кбит/с) Продвинутое кодирование аудио AAC (Advanced Audio Coding) главного профайла было оценено как имеющее "неотличимое качество" (относительно оригинала) согласно определению EBU. При кодировании 2- канального материала при 128 кбит/с как AAC главного профайла так и AAC профайла низкой сложности были оценены как имеющие "неотличимое качество" (относительно оригинала) согласно определению EBU. Два масштабируемых кодировщика, CELP-база с улучшение AAC, и TwinVQ база с улучшением AAC, работают лучше чем AAC "multicast", работающий при скорости передачи уровня улучшения, но не так хороши как кодировщик AAC, работающий при полной скорости передачи. Широкополосное кодирующее средство CELP демонстрирует прекрасные характеристики только для голоса. Побитовое арифметическое кодирование (BSAC) предоставляет весьма малые шаги масштабирования. На верху диапазона масштабирования это кодирование не имеет штрафных балов по отношению к AAC, однако в нижней части диапазона оно уступает односкоростной AAC. Узкополосный CELP, TwinVQ и индивидуальные гармонические линии и шум (HILN) все могут обеспечить очень высокое сжатие сигнала. Средства противодействия ошибкам (ER) обеспечивают эквивалентно хорошую устойчивость к ошибкам в широком диапазоне условий канальных ошибок, и делают это с достаточно малой избыточностью по скорости передачи. 7. Промышленный форум MPEG-4 Промышленный форум MPEG-4 является бесприбыльной организацией, имеющей следующую цель: дальнейшее принятие стандарта MPEG-4, путем установления MPEG-4 в качестве принятого и широко используемого стандарта среди разработчиков приложений, сервис провайдеров, создателей материалов и конечных пользователей. Далее следует не исчерпывающая выдержка из устава M4IF о планах работы: M4IF имеет свою WEB-страницу: http://www.m4if.org Деятельность M4IF начинается там, где кончается активность MPEG. Сюда входят позиции, с которыми MPEG не может иметь дело, например, из-за правил ISO, таких как патентная чистота. 8. Детальное техническое описание MPEG-4 DMIF и систем Рис. 3 показывает как потоки, приходящие из сети (или запоминающего устройства), как потоки TransMux, демультиплексируются в потоки FlexMux и передаются соответствующим демультиплексорам FlexMux, которые извлекают элементарные потоки. Элементарные потоки (ES) анализируются и передаются соответствующим декодерам. Декодирование преобразует данные в AV объект и выполняет необходимые операции для реконструкции исходного объекта AV, готового для рэндеринга на соответствующем аппарате. Аудио и визуальные объекты представлены в их кодированной форме, которая описана в разделах 10 и 9 соответственно. Реконструированный объект AV делается доступным для слоя композиции при рэндеринга сцены. Декодированные AVO, вместе с данными описания сцены, используются для композиции сцены, как это описано автором. Пользователь может расширить возможности, допущенные автором, взаимодействовать со сценой, которая отображается.
Рис. 3. Главные компоненты терминала MPEG-4 (принимающая сторона) 8.1. DMIF DMIF (Delivery Multimedia Integration Framework) является протоколом сессии для управления мультимедийными потоками поверх общих средств доставки данных. В принципе это имеет много общего с FTP. Единственное (существенное) отличие заключается в том, что FTP предоставляет данные, DMIF предоставляет указатели, где получить данные (streamed). Когда работает FTP, первым действием, которое производит протокол, является установление сессии с удаленным партнером. Далее, выбираются файлы, и FTP посылает запрос об их передаче, партнер FTP пересылает файл через отдельное, сформированное для этой цели соединение. Аналогично, когда работает DMIF, первым действием, которое он выполняет, является установление сессии с удаленным партнером. Позднее, выбираются потоки и DMIF посылает запрос, передать их, партер DMIF в отклике пришлет указатель на соединение, где будут проходить потоки, и затем также устанавливает соединение. По сравнению с FTP, DMIF является системой и протоколом. Функциональность, предоставляемая DMIF, определяется интерфейсом, называемым DAI (DMIF-Application Interface), и реализуется через протокольные сообщения. Эти протокольные сообщения для разных сетей могут отличаться. При конструировании DMIF рассматривается и качество обслуживания (QoS), а DAI позволяет пользователю DMIF специфицировать требования для нужного потока. Проверка выполнения требований оставляется на усмотрение конкретной реализации DMIF. Спецификация DMIF предоставляет советы, как решать такие задачи на новом типе сети, таком, например, как Интернет. Интерфейс DAI используется для доступа к широковещательному материалу и локальным файлам, это означает, что определен один, универсальный интерфейс для доступа к мультимедийному материалу для большого числа технологий доставки. Как следствие, уместно заявить, что интегрирующая система DMIF покрывает три главные технологии, интерактивную сетевую технику, широковещательную технологию и работу с дисками; это показано на рис. 4 ниже.
Рис. 4. DMIF осуществляет интеграцию доставки для трех основных технологий Архитектура DMIF такова, что приложения, которые для коммуникаций базируются на DMIF, не должны быть чувствительны к нижележащему методу коммуникаций. Реализация DMIF заботится о деталях технологии доставки, предоставляя простой интерфейс к приложению. На рис. 5 представлена указанная выше концепция. Приложение получает доступ к данным через интерфейс приложения DMIF, вне зависимости от того, откуда получены данные: от широковещательного источника, локальной памяти или от удаленного сервера. Во всех сценариях локальное приложение только взаимодействует через универсальный интерфейс (DAI). Различные варианты DMIF будут затем транслировать запросы локального приложения в специфические сообщения, которые должны быть доставлены удаленному приложению, учитывая особенности используемых технологий доставки. Аналогично, данные, поступающие на терминал (из удаленного сервера, широковещательных сетей или локальных файлов) доставляются локальному приложению через DAI. Специализированные версии DMIF подключаются приложением апосредовано, чтобы управлять различными специфическими технологиями доставки данных, это, однако прозрачно для приложения, которое взаимодействует только с одним "DMIF фильтром". Этот фильтр отвечает за управление конкретным примитивом DAI в нужный момент. Концептуально, "настоящее" удаленное приложение доступное через сеть, например, через IP или ATM, ничем не отличается от эмулируемого удаленного приложения, получающего материал от широковещательного источника или с диска. В последнем случае, однако, сообщения, которыми обмениваются партнеры, должны быть определены, чтобы обеспечить совместимость (это сигнальные сообщения DMIF). В последнем случае, с другой стороны, интерфейсы между двумя партнерами DMIF и эмулируемым удаленным приложением являются внутренними по отношению реализации и не должны рассматриваться в этой спецификации. Заметим, что для сценариев получения данных широковещательно и из локальной памяти, рисунок показывает цепочку "Локальный DMIF", "Удаленный DMIF (эмулированный)" и "Удаленное приложение (эмулированное)". Эта цепочка представляет концептуальную модель и не должна отражаться в практической реализации (на рисунке она представлена закрашенной областью).
Рис. 5. Архитектура коммуникаций DMIF При рассмотрении сценариев с широковещанием и локальной памятью предполагается, что эмулируемое удаленное приложение знает, как данные доставлены/запомнены. Это подразумевает знание типа приложения, с которым осуществляется взаимодействие. В случае MPEG-4, это в действительности предполагает знание идентификатора элементарного потока, дескриптора первого объекта, названия услуги. Таким образом, в то время как уровень DMIF концептуально не знает ничего о приложении, которое поддерживает, в частном случае работы DMIF с широковещанием и локальной памятью это утверждение не вполне корректно из-за присутствия эмулированного удаленного приложения (которое, с точки зрения локального приложения является частью слоя DMIF). При рассмотрении сценария удаленного взаимодействия, слой DMIF ничего не знает о приложении. Введен дополнительный интерфейс DNI (DMIF-Network Interface), который служит для подчеркивания того, какого рода информацией должны обмениваться партнеры DMIF. Дополнительные модули SM (Signaling mapping) служат для установления соответствия между примитивами DNI и сигнальными сообщениями, используемыми в конкретной сети. Заметим, что примитивы DNI специфицированы для информационных целей, и интерфейс DNI в настоящей реализации может отсутствовать. DMIF допускает одновременное присутствие одного или более интерфейсов DMIF, каждый из которых предназначен для определенной технологии доставки данных. Одно приложение может активировать несколько технологий доставки. 8.1.1. Вычислительная модель DMIF Когда приложение запрашивает активацию услуги, оно использует сервисный примитив DAI, и формирует соответствующую сессию. Реализация DMIF устанавливает контакт с соответствующим партнером (который концептуально может быть либо удаленным, либо эмулируемым локальным партнером) и формирует вместе с ним сетевую сессию. В случае широковещательного и локального сценариев, способ формирования и управления сессией находится вне зоны ответственности данного документа. В случае интерактивного сценария с удаленным сервером, DMIF использует свой сигнальный механизм для формирования и управления сессией, например, сигнальный механизм ATM. Приложения партнеров используют эту сессию для установления соединения, которое служит для передачи прикладных данных, например, элементарных потоков MPEG-4. Когда приложению нужен канал, оно использует примитивы канала DAI, DMIF транслирует эти запросы в запросы соединения, которые являются специфическими для конкретных запросов сетевых реализаций. В случае сценариев широковещания и локальной памяти, метод установления соединения и последующего управления находится за пределами регламентаций MPEG-4. В случае сетевого сценария напротив, DMIF использует свой сигнальный механизм для формирования и управления соединением. Это соединение используется приложением для целей доставки данных. На рис. 6 предоставлена схема активации верхнего уровня и начало обмена данными. Этот процесс включает в себя четыре этапа:
Рис. 6. Вычислительная модель DMIF Слой DMIF автоматически определяет, предполагается ли предоставление данной услуги удаленным сервером в конкретной сети, например, в IP, или ATM, широковещательной сетью, или устройством локальной памяти: выбор основывается на адресной информации партнера, предоставляемой приложением в качестве части URL, переданной DAI. 8.2. Демультиплексирование, синхронизация и описание потоков данных Отдельные элементарные потоки должны быть выделены на уровне доставки из входных данных некоторого сетевого соединения или из локального устройства памяти. Каждое сетевое соединение или файл в модели системы MPEG-4 рассматривается как канал TransMux. Демультиплексирование выполняется частично или полностью слоями вне области ответственности MPEG-4. Единственным демультиплексирующим средством, определенным MPEG-4, является FlexMux, которое может опционно использоваться для снижения задержки, получения низкой избыточности мультиплексирования и для экономии сетевых ресурсов. Для целей интегрирования MPEG-4 в системную среду, интерфейс приложения DMIF является точкой, где можно получить доступ к элементарным потокам, как к потокам sync. DMIF является интерфейсом для реализации функций, недоступных в MPEG. Управляющая часть интерфейса рассмотрена в разделе DMIF. MPEG-4 определяет модель системного декодера. Это позволяет точно описать операции терминала, не делая ненужных предположений о деталях практической реализации. Это важно для того, чтобы дать свободу разработчикам терминалов MPEG-4 и декодирующих приборов. Это оборудование включает в себя широкий диапазон аппаратов от телевизионных приемников, которые не имеют возможности взаимодействовать с отправителем, до ЭВМ, которые полноценный двунаправленный коммуникационный канал. Некоторые приборы будут получать потоки MPEG-4 через изохронные сети, в то время как другие будут использовать для обмена информацией MPEG-4 асинхронные средства (например, Интернет). Модель системного декодера предоставляет общие принципы, на которых могут базироваться все реализации терминалов MPEG-4. Спецификация модели буфера и синхронизации является существенной для кодирующих приборов, которые могут не знать заранее, тип терминала и метод получения кодированного потока данных. Спецификация MPEG-4 делает возможным для кодирующего прибора проинформировать декодер о ресурсных требованиях, может оказаться невозможным для приемника реагировать на сообщение передатчика. 8.2.1. Демультиплексирование Демультиплексирование происходит на уровне доставки, который включает в себя слои TransMux и DMIF. Извлечение входящих информационных потоков из сетевого соединения или из памяти включает в себя два этапа. Во-первых, каналы должны быть найдены и открыты. Это требует наличия некоторого объекта, который осуществляет транспортный контроль и устанавливает соответствие между транспортными каналами и специальными элементарными потоками. Таблица карты таких потоков связывает каждый поток с ChannelAssociationTag (канальной меткой), которая служит указателем для канала, через который идет поток. Определение ChannelAssociationTags для реального транспортного канала, а также управление сессией и каналами осуществляется DMIF-частью стандарта MPEG-4. Во-вторых, входящие потоки должны быть соответствующим образом демультиплексированы, чтобы восстановить SL-потоки пакетов от нижележащих каналов (входящих в принимающий терминал). В интерактивных приложениях, соответствующий узел мультиплексирования переправляет данные в вышерасположенные каналы (исходящие из принимающего терминала). Базовый термин 'TransMux Layer' используется, чтобы абстрагироваться от нижележащей функциональности - существующей или будущей, которая пригодна для транспортировки потоков данных MPEG-4. Заметим, что этот уровень не определен в контексте MPEG-4. Примерами могут служить транспортный поток MPEG-2, H.223, ATM AAL 2, IP/UDP. Предполагается, что слой TransMux предоставляет защиту и средства мультиплексирования, этот уровень обеспечивает определенный класс QoS. Средства безопасности включают в себя защиту от ошибок и детектирование ошибок, удобное для данной сети или устройств памяти. В любом конкретном сценарии приложения используется один или более специфических TransMux. Каждый демультиплексор TransMux предоставляет доступ к каналам TransMux. Требования на информационный интерфейс доступа к каналу TransMux те же, что и для всех интерфейсов TransMux. Они включают необходимость надежного детектирования ошибок, доставки, если возможно, ошибочных данных с приемлемой индикацией ошибок и кадрирование поля данных, которое может включать потоки либо SL либо FlexMux. Эти требования реализованы в интерфейсе TransMux (системная часть стандарта MPEG-4). Адаптация потоков SL должна быть специфицирована для каждого стека протоколов. Средство FlexMux специфицировано MPEG для того, чтобы опционно предоставить гибкий метод, имеющий малую избыточность и задержку для переукладки данных в тех случаях, когда ниже лежащие протоколы не поддерживают это. Средство FlexMux само по себе недостаточно устойчиво по отношению к ошибкам и может либо использоваться в каналах TransMux с высоким QoS, либо для объединения элементарных потоков, которые достаточно устойчивы к ошибкам. FlexMux требует надежного детектирования ошибок. Эти требования реализованы в информационных примитивах прикладного интерфейса DMIF, который определяет доступ к данным в индивидуальных транспортных каналах. Демультиплексор FlexMux выделяет SL-потоки из потоков FlexMux. 8.2.2. Синхронизация и описание элементарных потоков
Рис. 7. Архитектура буферов модели системного декодера Слой sync имеет минимальный набор средств для проверки согласованности, чтобы передать временную информацию. Каждый пакет состоит из блока доступа или фрагмента блока доступа. Эти снабженные временными метками блоки образуют единственную семантическую структуру элементарных потоков, которые видны на этом уровне. Временные метки используются для передачи номинального времени декодирования. Уровень sync требует надежного детектирования ошибок и кадрирования каждого индивидуального пакета нижележащего слоя. Как осуществляется доступ к данным для слоя сжатия, определяется интерфейсом элементарных потоков, описание которого можно найти в системной части стандарта MPEG-4. Слой sync извлекает элементарные потоки из потоков SL. Чтобы с элементарные потоки могли взаимодействовать с медиа-объектами в пределах сцены, используются дескрипторы объектов. Дескрипторы объектов передают информацию о номере и свойствах элементарных потоков, которые ассоциированы с конкретными медиа-объектами. Сами дескрипторы объектов передаются в одном или более элементарных потоков, так как допускается добавление и удаление потоков (и объектов) в процессе сессии MPEG-4. Для того чтобы обеспечить синхронизацию, такие модификации помечаются временными метками. Потоки дескрипторов объектов могут рассматриваться как описание потоковых ресурсов презентации. Аналогично, описание сцены также передается как элементарный поток, позволяя модифицировать пространственно-временную картину презентации со временем. 8.2.3. Управление буфером Чтобы предсказать, как декодер будет себя вести, когда он декодирует различные элементарные потоки данных, которые образуют сессию MPEG-4, модель системного декодера (Systems Decoder Mode) позволяет кодировщику специфицировать и мониторировать минимальные буферные ресурсы, необходимые для декодирования сессии. Требуемые буферные ресурсы передаются декодеру в объектных дескрипторах во время установления сессии MPEG-4, так что декодер может решить, может ли он участвовать в этой сессии. При управлении конечным буферным пространством модель позволяет отправителю, например, передавать данные, не привязанные к реальному времени, досрочно, если имеется достаточно места в буфере со стороны приемника. Запомненные данные будут доступны в любое время, позволяя использовать для информации реального времени при необходимости большие ресурсы канала. 8.2.4. Идентификация времени Для операции реального времени, модель синхронизации is assumed in which the end-to-end delay from the signal output from an encoder to the signal input to a decoder is constant. Более того, передаваемые потоки данных должны содержать времязадающую информацию в явном или неявном виде. Существует два типа временной информации. Первый тип используется для передачи частоты часов кодировщика, или временной шкалы, декодеру. Второй, состоящий из временных меток, присоединенных к закодированным AV данным, содержит желательное время декодирование для блоков доступа или композиции, а также время истечения применимости композиционных блоков. Эта информация передается в заголовках SL-пакетов сформированных в слое sync. С этой временной информацией, интервалы в пределах картинки и частота стробирования аудио может подстраиваться в декодере, чтобы соответствовать интервалам частоте стробирования на стороне кодировщика. Различные медиа-объекты могут кодироваться кодировщиками с различными временными шкалами, и даже с небольшим отличием времязадающих частот. Всегда возможно установить соответствие между этими временными шкалами. В этом случае, однако, никакая реализация приемного терминала не может избежать случайного повторения или потери AV-данных, из-за временного наезда (относительное растяжение или сжатие временных шкал). Хотя допускается работа систем без какой-либо временной информации, определение модели буферизации в этом случае невозможно. 8.3. Улучшенная модель синхронизации (FlexTime) Модель FlexTime (Advanced Synchronization Model) расширяет традиционную модель хронирования MPEG-4, чтобы разрешить синхронизацию большого числа потоков и объектов, таких как видео, аудио, текст, графика, или даже программы, которые могут иметь разное происхождение. Традиционная модель синхронизации MPEG-4 первоначально была сконструирована для широковещательных приложений, где синхронизация между блоками доступа осуществляется через "жесткие" временные метки и эталонные часы. В то время как этот механизм предоставляет точную синхронизацию внутри потока, он терпит неудачу при синхронизации потоков, приходящих из разных источников (и возможно с разными эталонными часами) как это имеет место в случае большинства приложений Интернет и в более сложных широковещательных приложениях. Модель FlexTime позволяет разработчику материала специфицировать простые временные соотношения для выбранных объектов MPEG-4, таких как "CoStart," "CoEnd," и "Meet." Автор материала может также специфицировать ограничения гибкости для объектов MPEG-4, как если бы объекты были растяжимыми пружинами. Это позволяет синхронизовать большое число объектов согласно специфицированным временным соотношениям. Наибольшую эффективность внедрение этой техники может дать в случае приложений Интернет, где нужно синхронизовать большое число источников на стороне клиента. 8.3.1. Гибкая длительность В среде с ненадежной доставкой может так случиться, что доставка определенного элементарного потока или частей потока, может заметно задержаться относительно требуемого времени воспроизведения. Для того чтобы понизить чувствительность к задержке времени доставки, модель FlexTime основывается на так называемой метафоре "пружины", смотри раздел 4.2.3. Следуя модели пружины, элементарные потоки, или фрагменты потоков, рассматриваются как пружины, каждый с тремя 3 ограничениями. Оптимальная длина (длительность воспроизведения потока) может рассматриваться как подсказка получателю, когда возможны варианты. Заметим, что при растяжении или сжатии длительности непрерывной среды, такой как видео, подразумевает соответствующее замедление или ускорение воспроизведения, когда элементарный поток состоит из статических картинок. В этом случае растяжение или сжатие предполагает удержание изображения на экране в течение большего или меньшего времени. 8.3.2. Относительное время начала и конца Два или более элементарных потоков или потоков сегментов могут быть синхронизованы друг относительно друга, путем определения того, что они начинаются ("CoStart") или кончаются ("CoEnd") в одно и то же время или завершение одного совпадает с началом другого ("Meet"). Важно заметить, что существует два класса объектов MPEG-4. Синхронизация и рэндеринг объекта MPEG-4, который использует элементарный поток, такого как видео, не определяется одним потоком, но также соответствующими узлами BIFS и их синхронизацией. В то время как синхронизация и рэндеринг объекта MPEG-4, который не использует поток, такой как текст или прямоугольник, определяется только соответствующими узлами BIFS и их синхронизацией. Модель FlexTime позволяет автору материала выражать синхронизацию объектов MPEG-4 с потоками или сегментами потоков, путем установления временных соотношений между ними. Временные соотношения (или относительные временные метки) могут рассматриваться как "функциональные" временные метки, которые используются при воспроизведении. Таким образом, действующее лицо FlexTime может: 8.3.3. Поддержка FlexTime в MPEG-4 Модель FlexTime поддерживается в MPEG-4 двумя узлами: TemporalTransform и TemporalGroup, и дескриптором: SegmentDescriptor. Узел TemporalTransform специфицирует временные свойства объекта MPEG-4, который нуждается в синхронизации. Узел TemporalGroup специфицирует временные соотношения между объектами, которые представлены узлами TemporalTransform, а SegmentDescriptor идентифицирует доли потока, которые могут быть синхронизованы. 8.3.3.1. Узел TemporalTransform TemporalTransform поддерживает синхронизацию узлов в пределах сцены с медиа потоком, или его сегментом, и поддерживает гибкое преобразование ко времени сцены. Этот группирующий узел может гибко поддерживать замедление, ускорение, замораживание или смещение временной шкалы сцены для рэндеринга узлов содержащихся в ней. Его дочернее поле может содержать список узлов типа SF3Dnode, а узел может влиять на замедление, ускорение, замораживание или смещение временной шкалы композитора, когда он осуществляет рэндеринг дочерних узлов, которые преобразованы этим узлом. Кроме того, этот узел имеет поле url, которое может ссылаться на элементарный поток или его сегмент и в этом случае, узел воздействует на временную шкалу потока, указанного в ссылке. 8.3.3.2. Узел TemporalGroup Узел TemporalGroup специфицирует временное соотношение между заданным числом TemporalTransforms, чтобы выровнять временные шкалы узлов, в графе сцены. Временная настройка среды с целью удовлетворения ограничений и обеспечения гибкости осуществляется на уровне sync. TemporalGroup может рассматривать временные свойства его дочек и когда все они готовы, а временные ограничения выполнены, может быть дано разрешение на их воспроизведение. 8.3.3. Дескриптор сегмента (SegmentDescriptor) Массив SegmentDescriptors добавляется в качестве составного элемента в ES_Descriptor. SegmentDescriptor идентифицирует и помечает сегмент потока, так что отдельные сегменты потока могут быть адресуемы с помощью их полей url в узле TemporalTansform. 8.3.4. Модель исполнения Временное декодирование и настройка часов медиа потоков в соответствии с временными метками является функцией слоя sync. Модель FlexTime требует небольшого изменения модели буферизации MPEG-4 и декодирования. Декодирование может быть задержано у клиента, по отношению к стандартному времени. Модель буферов для flextime может быть специфицировано следующим образом: "В любое время от момента, соответствующего его DTS, вплоть до границы времени, заданной Flextime, AU немедленно декодируется и удаляется из буфера." Так как точное время удаления из буфера декодирования AU может варьироваться, нельзя быть уверенным, что оно будет удалено раньше наихудшего времени (максимальная задержка для медиа-потока). Используя наихудшее время, а не время, заданное DTS, буфер декодирования может управляться и не так, как предписывается MPEG-4. 8.4. Описание синтаксиса MPEG-4 определяет язык синтаксического описания чтобы характеризовать точный двоичный синтаксис для двоичных потоков, несущих медиа-объекты и для потоков с информацией описания сцены. Это уход от прошлого подхода MPEG, использовавшего язык псевдо C. Новый язык является расширением C++, и используется для интегрированного описания синтаксического представления объектов и классов медиа-объектов и сцен. Это предоставляет удобный и универсальный способ описания синтаксиса. Программные средства могут использоваться для обработки синтаксического описания и генерации необходимого кода для программ, которые выполняют верификацию. 8.5. Двоичный формат описания сцены BIFS (Binary Format for Scene description) Кроме обеспечения поддержки кодирования индивидуальных объектов, MPEG-4 предоставляет также возможность создать набор таких объектов в рамках сцены. Необходимая информация композиции образует описание сцены, которая кодируется и передается вместе с медиа-объектами. Начиная с VRML (Virtual reality Modeling Language), MPEG разработал двоичный язык описания сцены, названный BIFS. BIFS расшифровывается как BInary Format for Scenes. Для того чтобы облегчить авторскую разработку, а также создание средств манипулирования и взаимодействия, описания сцены кодируются независимо от потоков, имеющих отношение в примитивным медиа-объектам. Специальные меры предпринимаются для идентификации параметров, относящихся к описанию сцены. Это делается путем дифференциации параметров, которые используются для улучшения эффективности кодирования объектов (например, векторы перемещения в алгоритмах видео-кодирования), а также те, которые используются в качестве модификаторов объекта (например, положение объекта на сцене). Так как MPEG-4 должен допускать модификацию последнего набора параметров без необходимости декодировать самих примитивных медиа-объектов, эти параметры помещаются в описание сцены, а не в примитивные медиа-объекты. Следующий список предлагает некоторые примеры информации, представленные в описании сцены. Как объекты группируются. Сцена MPEG-4 следует иерархической структуре, которая может быть представлена как ориентированный граф без циклов. Каждый узел графа является медиа-объектом, как показано на рис. 8. Три структуры не обязательно являются статическими; атрибуты узла (например, позиционирующие параметры) могут быть изменены, в то время как узлы могут добавляться, замещаться, или удаляться.
Рис. 8. Возможная логическая структура сцены Как объекты позиционируются в пространстве и времени. В модели MPEG-4, аудиовизуальные объекты имеют протяженность в пространстве и во времени. Каждый медиа-объект имеет локальную координатную систему. Локальная координатная система объекта является той, в которой объект имеет фиксированное пространственно-временное положение и шкалу. Локальная координатная система служит в качестве указателя для манипулирования медиа-объектом в пространстве и во времени. Медиа-объекты позиционируются на сцене путем спецификации координатного преобразования из локальной координатной системы объекта в глобальную систему. Выбор значения атрибута. Индивидуальные медиа-объекты и узлы описания сцены демонстрируют набор параметров композиционному слою через который может частично контролироваться их поведение. Среди примеров можно назвать понижение звука (pitch), цвет для синтетических объектов, активация или дезактивация информации улучшения для масштабируемого кодирования и т.д. Другие преобразования медиа-объектов. Как упомянуто выше, структура описания сцены и семантика узла подвержены сильному влиянию VRML, включая его модель событий. Это предоставляет MPEG-4 очень богатый набор операторов конструирования сцены, включая графические примитивы, которые могут использоваться для построения сложных сцен. 8.5.1. Продвинутый формат BIFS BIFS версия 2 (продвинутый BIFS) включает в себя следующие новые возможности: 8.6. Взаимодействие с пользователем MPEG-4 позволяет пользователю взаимодействие с отображаемым материалом. Это взаимодействие может быть разделено на две главные категории: взаимодействие на стороне клиента и взаимодействие на стороне сервера. Взаимодействие на стороне клиента включает в себя манипуляцию материалом, который обрабатывается локально на терминале конечного пользователя. В частности, модификация атрибута узла описания сцены, например, изменения положение объекта, делание его видимым или невидимым, изменение размера шрифта узла синтетического текста и т.д., может быть выполнено путем трансляции событий пользователя. Событием пользователя может быть нажатие клавиши мыши или команда, введенная с клавиатуры. Другие формы взаимодействия на стороне клиента требуют поддержки со стороны синтаксиса описания сцены и должны быть специфицированы в стандарте. Использование структуры событий VRML предоставляет богатую модель, на основании которой разработчики могут создать вполне интерактивный материал. Взаимодействие на стороне сервера включает в себя манипуляцию материалом на стороне отправителя в результате действий пользователя. Это, разумеется, требует наличия обратного канала. 8.7. IPR идентификация и защита MPEG-4 предоставляет механизмы для защиты прав интеллектуальной собственности (IPR). Это достигается путем предоставления кодированных медиа-объектов с опционным набором данных идентификационной интеллектуальной собственности IPI (Intellectual Property Identification), несущим информацию о содержимом, типе содержимого и о владельцах прав на данный материал. Набор данных, если он имеется, является частью дескриптора элементарного потока, который описывает поточную информацию, ассоциированную с медиа-объектом. Номер набора данных, который ассоциируется с каждым медиа-объектом достаточно гибок; другие медиа-объекты могут использовать тот же набор. Предоставление наборов данных позволяет внедрить механизм отслеживания, мониторинга, выставления счетов и защиты от копирования. Каждое широкодиапазонное приложение MPEG-4 имеет набор требований относящихся к защите информации, с которой оно работает. Эти приложения могут иметь разные требования по безопасности. Для некоторых приложений, пользователи обмениваются информацией, которая не имеет собственной ценности, но которая, тем не менее, должна быть защищена, чтобы защитить права собственности. Для других приложений, где управляемая информация для ее создателя или дистрибьютора имеет большую ценность, требуется управление более высокого уровня и более надежные механизмы защиты. Подразумевается, что дизайн структуры IPMP должен учитывать сложность стандарта MPEG-4 и разнообразие его применений. Эта структура IPMP оставляет детали системы IPMP на усмотрение разработчиков. Необходимые уровень и тип управления и защиты зависят от ценности материала, комплексности, и сложности, связанных с этим материалом бизнес моделей. Данный подход позволяет конструировать и использовать системы IPMP специфичные для доменов (IPMP-S). В то время как MPEG-4 не стандартизует сами системы IPMP, он стандартизует интерфейс IPMP MPEG-4. Этот интерфейс состоит из IPMP-дескрипторов (IPMP-Ds) и элементарных потоков IPMP (IPMP-ES). IPMP-Ds и IPMP-ESs предоставляют коммуникационный механизм взаимодействия систем IPMP и терминала MPEG-4. Определенные приложения могут требовать нескольких систем IPMP. Когда объекты MPEG-4 требуют управления и защиты, они имеют IPMP-D, ассоциированные с ними. Эти IPMP-Ds указывают на то, какие системы IPMP следует использовать и предоставляют информацию о том, как защищать получаемый материал. (Смотри рис. 9). Кроме предоставления владельцам интеллектуальной собственности возможности управления и защиты их прав, MPEG-4 предлагает механизм идентификации этих прав с помощью набора данных IPI (Intellectual Property Identification Data Set). Эта информация может использоваться системами IPMP в качестве входного потока процесса управления и защиты.
Рис. 9. Интерфейсы IPMP в системе MPEG-4 8.8. Информация содержимого объекта MPEG-4 позволяет подсоединять к объектам информацию об их материале. Пользователи стандарта могут использовать этот поток данных 'OCI' (Object Content Information) для передачи текстовой информации совместно с материалом MPEG-4. 8.9. Формат файлов MPEG-4 Формат файла MP4 сконструирован так, чтобы информация MPEG-4 имела легко адаптируемый формат, который облегчает обмены, управление, редактирование и представление медиа-материала. Презентация может быть локальной по отношению к системе осуществляющей этот процесс, или осуществляемой через сеть или другой поточный механизм доставки (TransMux). Формат файлов сконструирован так, чтобы не зависеть от конкретного типа протокола доставки, и в тоже время эффективно поддерживать саму доставку. Конструкция основана формате QuickTime╝ компании Apple Computer Inc. Формат файла MP4 сформирован из объектно-ориентированных структур, называемых атомами. Каждый атом идентифицируется тэгом и длиной. Большинство атомов описывают иерархию метаданных, несущих в себе такую информацию как индексные точки, длительности и указатели на медиа данные. Это собрание атомов содержится в атоме, называемом 'кино атом'. Сами медиа-данные располагаются где-то; они могут быть в файле MP4, содержащемся в одном или более 'mdat', в медийных информационных атомах или размещаться вне файла MP4 с доступом через URL. Мета данные в файле в сочетании с гибкой записью медийных данных в память позволяют формату MP4 поддерживать редактирование, локальное воспроизведение и обмен, и тем самым удовлетворять требованиям интермедиа MPEG4. 8.10. MPEG-J MPEG-J является программной системой a programmatic system (в противоположность параметрической системе MPEG-4 версия 1), которая специфицирует API для кросс-операций медиа-проигрывателей MPEG-4 с программами на Java. Комбинируя среду MPEG-4 и безопасный исполнительный код, разработчики материала могут реализовать комплексный контроль и механизмы обработки их медиа в рамках аудио-визуальной сессии. Блок-схема плеера MPEG-J в среде системного плеера MPEG-4 показана на рис. 10. Нижняя половинка этого рисунка отображает системный параметрический плеер MPEG-4, называемый также средство презентации (ДП). Субсистема MPEG-J, контролирующая ДП, называется средством приложения (Application Engine), показана в верхней половине рис. 10. Приложение Java доставляется в качестве отдельного элементарного потока, поступающего на терминал MPEG-4. Оно будет передано MPEG-J, откуда программа MPEG-J будет иметь доступ к различным компонентам и данным плеера MPEG-4. MPEG-J не поддерживает загружаемых декодеров. По выше указанной причине, группой был определен набор API с различными областями применения. Задачей API является обеспечение доступа к графу сцены: рассмотрение графа, изменение узлов и их полей, и добавление и удаление узлов графа. Менеджер ресурсов API используется для управления исполнением: он обеспечивает централизованное средство управления ресурсами. API терминальных возможностей (Terminal Capability) используется, когда исполнение программы зависит от конфигурации терминала и его возможностей, как статических (которые не меняются во время исполнения) так и динамических. API медийных декодеров (Media Decoders) позволяет контролировать декодеры, которые имеются в терминале. Сетевое API предлагает способ взаимодействия с сетью, являясь прикладным интерфейсом MPEG-4 DMIF.
Рис. 10. Положение интерфейсов в архитектуре MPEG-J 9. Детальное техническое описание визуальной секции MPEG-4 Визуальные объекты могут иметь искусственное или натуральное происхождение. 9.1. Приложения видео-стандарта MPEG-4 MPEG-4 видео предлагает технологию, которая перекрывает широкий диапазон существующих и будущих приложений. Низкие скорости передачи и кодирование устойчивое к ошибкам позволяет осуществлять надежную связь через радио-каналы с ограниченной полосой, что полезно, например, для мобильной видеотелефонии и космической связи. При высоких скоростях обмена, имеются средства, позволяющие передачу и запоминание высококачественного видео на студийном уровне. Главной областью приложений является интерактивное WEB-видео. Уже продемонстрированы программы, которые осуществляют живое видео MPEG-4. Средства двоичного кодирования и работы с видео-объектами с серой шкалой цветов должны быть интегрированы с текстом и графикой. MPEG-4 видео было уже использовано для кодирования видеозапись, выполняемую с ручной видео-камеры. Эта форма приложения становится все популярнее из-за простоты переноса на WEB-страницу, и может также применяться и в случае работы со статичными изображениями и текстурами. Рынок игр является еще одной областью работы приложений MPEG-4 видео, статических текстур, интерактивности. 9.2. Натуральные текстуры, изображения и видео Средства для естественного видео в визуальном стандарте MPEG-4 предоставляют стандартные технологии, позволяющие эффективно запоминать, передавать и манипулировать текстурами, изображениями и видео данными для мультимедийной среды. Эти средства позволяют декодировать и представлять атомные блоки изображений и видео, называемые "видео объектами" (VO). Примером VO может быть говорящий человек (без фона), который может быть также создан из других AVO (аудио-визуальный объект) в процессе формирования сцены. Обычные прямоугольные изображения образуют специальный случай таких объектов. Для того чтобы достичь этой широкой цели функции различных приложений объединяются. Следовательно, визуальная часть стандарта MPEG-4 предоставляет решения в форме средств и алгоритмов для: 9.3. Синтетические объекты Синтетические объекты образуют субнабор большого класса компьютерной графики, для начала будут рассмотрены следующие синтетические визуальные объекты: ∙ Параметрические описания a) синтетического лица и тела (анимация тела в версии 2) ∙ Кодирование текстуры для приложений, зависимых от вида 9.4. Масштабируемое кодирование видео-объектов Существует несколько масштабируемых схем кодирования в визуальном MPEG-4: пространственная масштабируемость, временная масштабируемость и объектно-ориентированная пространственная масштабируемость. Пространственная масштабируемость поддерживает изменяющееся качество текстуры (SNR и пространственное разрешение). Объектно-ориентированная пространственная масштабируемость расширяет 'обычные' типы масштабируемости в направлении объектов произвольной формы, так что ее можно использовать в сочетании с другими объектно-ориентированными возможностями. Таким образом, может быть достигнута очень гибкая масштабируемость. Это делает возможным при воспроизведении динамически улучшать SNR, пространственное разрешение, точность воспроизведения формы, и т.д., только для объектов, представляющих интерес, или для определенной области. 9.5. Устойчивость в среде, предрасположенной к ошибкам Разработанная в MPEG новая методика, названная NEWPRED ('new prediction' - новое предсказание), предоставляет быстрое восстановление после ошибок в приложениях реального времени. Она использует канал от декодера к кодировщику. Кодировщик переключает эталонные кадры, приспосабливаясь к условиям возникновения ошибок в сети. Методика NEWPRED обеспечивает высокую эффективность кодирования. Она была проверена в условиях высоких потоков ошибок: ∙ Короткие всплески ошибок в беспроводных сетях (BER= 10-3, длительность всплеска 1мс) ∙ Потери пакетов в Интернет (вероятность потери = 5%) 9.6. Улучшенная стабильность временного разрешения с низкой задержкой буферизации Еще одной новой методикой является DRC (Dynamic Resolution Conversion), которая стабилизирует задержку буферизации при передаче путем минимизации разброса числа кодовых бит VOP на выходе. Предотвращается отбрасывание больших пакетов, а кодировщик может контролировать временное разрешение даже в высоко активных сценах. 9.7. Кодирование текстур и статические изображения Следующие три новых средства кодирования текстур и статических изображений предлагается в версии V.2: Упомянутые выше средства используются в двух новых 'продвинутых масштабируемых текстурах' и продвинутом центральном профайле (advanced core profile). 9.8. Кодирование нескольких видов и большого числа вспомогательных компонентов В MPEG-4 видео версии 1 поддерживается до одного альфа-канала на видео канальный слой и определены три типа формы. Все три типа формы, т.е. двоичная форма, постоянная форма и форма с серой шкалой, допускают прозрачность видео объекта. При таком определении MPEG-4 не может эффективно поддерживать такие вещи как многовидовые видео объекты (Multiview Video Objects). В версии 2 введено применение множественных альфа-каналов для передачи вспомогательных компонент. Базовой идеей является то, что форма с серой шкалой не является единственной для описания прозрачности видео объекта, но может быть определена в более общем виде. Форма с серой шкалой может, например, представлять: Все альфа-каналы могут кодироваться с помощью средств кодирования формы, т.е. средства двоичного кодирования формы и средства кодирования формы с серой шкалой, которые используют DCT с компенсаций перемещения, и обычно имеют ту же форму и разрешение, что и текстура видео объекта. В качестве примера использования множественных вспомогательных компонентов в случае формы несоразмерности для многовидовых видео объектов описаны ниже. Общим принципом является ограничение числа пикселей, которые следует кодировать при анализе соответствия между конкретными видами объекта, доступными на стороне кодировщика. Все области объекта, которые видны со стороны более чем одной камеры, кодируются только один раз с максимально возможным разрешением. Соотношения несоразмерности могут быть оценены из исходных видов, чтобы реконструировать все области, которые были исключены из кодирования путем использования проекции со скомпенсированной несоразмерностью. Один или два вспомогательных компонентов могут быть выделены, чтобы кодировать карты несоразмерности, указывающие на соответствие между пикселями различных видов. Мы назначаем области, которые используются для кодирования данных от каждой конкретной камеры как "области интереса" (AOI). Эти AOI могут теперь быть просто определены как видео объекты MPEG-4, и закодированы с их ассоциированными значениями несоразмерности. Из-за возможного отражения объектов в различных видах, а также из-за отклонений цветов или различия экспозиций для разных камер, границы между областями, которые нужно реконструировать на основе разных исходных видов могут оказаться видимыми. Чтобы решить эту проблему, необходимо предварительно обработать пиксели вблизи границ AOI, так чтобы осуществить плавный переход путем интерполяции пикселей из различных смежных видов в пределах переходной области. Чтобы реконструировать различные точки зрения из текстуры, проекция поверхности с компенсации несоразмерности формируется из текстурных данных в пределах конкретных AOI, с привлечением карты несоразмерностей, полученной из вспомогательной компоненты, декодированной из видео потока MPEG-4. Каждая AOI обрабатывается независимо, а затем проекции изображений ото всех AOI собираются для получения окончательного вида видео объекта с заданной точки зрения. Эта процедура может быть выполнена для системы с двумя камерами с параллельной установкой, но может быть распространена на случай с несколькими камерами со сходящимися оптическими осями. 9.8.1. Анимация лица 'Лицевой анимационный объект' может использоваться для представления анимированного лица. Форма, текстура и выражения лица управляются параметрами определения лица FDP (Facial Definition Parameters) и/или параметрами анимации лица FAP (Facial Animation Parameters). Объект лица содержит базовый вид лица с нейтральным выражением. Это лицо может уже отображено. Оно может также получить немедленно анимационные параметры из потока данных, который осуществит анимацию лица: выражения, речь и т.д. Между тем, могут быть посланы параметры определения, которые изменять облик лица от некоторого базового к заданному лицу со своей собственной формой и (опционно) текстурой. Если это желательно, через набор FDP можно загрузить полную модель лица. Анимация лица в MPEG-4 версии 1 предназначена для высоко эффективного кодирования параметров анимации, которые могут управлять неограниченным числом моделей лица. Сами модели не являются нормативными, хотя существуют средства описания характеристик модели. Кадровое и временное-DCT кодирование большой коллекции FAP может использоваться для точной артикуляции. Двоичный формат систем для сцены BIFS (Systems Binary Format for Scenes), предоставляет возможности поддержки анимации лица, когда нужны обычные модели и интерпретации FAP: Эти специфицированные типы узлов в BIFS эффективно предоставляют для моделей формирования лица встроенную калибровку модели, работающей в терминале или загружаемой стандартной модели, включающей форму, текстуру и цвет. 9.8.2. Анимация тела Тело является объектом способным генерировать модели виртуального тела и анимации в форме наборов 3-D многоугольных сеток, пригодных для отображения (rendering). Для тела определены два набора параметров: набор параметров определения тела BDP (Body Definition Parameter), и набор параметров анимации тела BAP (Body Animation Parameter). Набор BDP определяет параметры преобразования тела по умолчанию в требующееся тело с нужной поверхностью, размерами, и (опционно) текстурой. Параметры анимации тела (BAP), если интерпретированы корректно, дадут разумно высокий уровень результата выражаемого в терминах позы и анимации для самых разных моделей тела, без необходимости инициализировать или калибровать модель. Конструкция объекта тело содержит обобщенное виртуальное человеческое тело в позе по умолчанию. Это тело может быть уже отображено. Объект способен немедленно принимать BAP из потока данных, который осуществляет анимацию тела. Если получены BDP, они используются для преобразования обобщенного тела в конкретное, заданное содержимым параметров. Любой компонент может быть равен нулю. Нулевой компонент при отображении тела заменяется соответствующим значением по умолчанию. Поза по умолчанию соответствует стоящей фигуре. Эта поза определена следующим образом: стопы ориентированы в фронтальном направлении, обе руки размещаться вдоль тела с ладонями повернутыми внутрь. Эта поза предполагает также, что все BAP имеют значения по умолчанию. Не делается никаких предположений и не предполагается никаких ограничений на движения или сочленения. Другими словами модель человеческого тела должна поддерживать различные приложения, от реалистических симуляций человеческих движений до сетевых игр, использующих простые человекоподобные модели. Стандарт анимации тела был разработан MPEG в сотрудничестве с Рабочей группой анимации гуманоидов (Humanoid Animation Working Group) в рамках консорциума VRML. 9.8.3. Анимируемые 2-D сетки Сетка 2-D mesh является разложением плоской 2-D области на многоугольные кусочки. Вершины полигональных частей этой мозаики называются узловыми точками сетки. MPEG-4 рассматривает только треугольные сетки, где элементы мозаики имеют треугольную форму. Динамические 2-D сетки ссылаются на сетки 2-D и информацию перемещения всех узловых точек сетки в пределах временного сегмента интереса. Треугольные сетки использовались в течение долгого времени для эффективного моделирования формы 3-D объектов и воспроизведения в машинной графики. Моделирование 2-D сеток может рассматриваться как проекцию треугольных 3-D сеток на плоскость изображения. Узловые точки динамической сетки отслеживают особенности изображения во времени с помощью соответствующих векторов перемещения. Исходная сетка может быть регулярной, или адаптироваться к характеру изображения, которая называется сеткой, адаптируемой к изображению. Моделирование 2-D сетки, адаптируемая к изображению, соответствует неоднородному стробированию поля перемещения в некотором числе узловых точек вдоль контура и внутри видео объекта. Методы выбора и отслеживания этих узловых точек не является предметом стандартизации. В 2-D сетке, базирующейся на текстуре, треугольные элементы, в текущем кадре деформируются при перемещении узловых точек. Текстура в каждом мозаичном элементе эталонного кадра деформируется с помощью таблиц параметрического соответствия, определенных как функция векторов перемещения узловых точек. Для треугольных сетей обычно используется аффинное преобразование. Его линейная форма предполагает текстурный мэпинг с низкой вычислительной сложностью. Афинный мэпинг может моделировать преобразование, вращение, изменение масштаба, отражение и вырезание и сохранение прямых линий. Степени свободы, предоставляемые тремя векторами перемещения вершин треугольника, соответствуют шести параметрам афинного преобразования (affine mapping). Это предполагает, что исходное 2-D поле перемещения может быть компактно представлено движением узловых точек, из которого реконструируется афинное поле перемещение. В то же время, структура сетки ограничивает перемещения смежных, мозаичных элементов изображения. Следовательно, сетки хорошо годятся для представления умеренно деформируемых, но пространственно непрерывных полей перемещения. Моделирование 2-D сетки привлекательно, та как 2-D сетки могут сформированы из одного вида объекта, сохраняя функциональность, обеспечиваемую моделированием с привлечением 3-D сеток. Подводя итог можно сказать, что представления с объектно-ориентированными 2-D сетками могут моделировать форму (многогранная апроксимация контура объекта) и перемещение VOP в неоднородной структуре, которая является расширяемой до моделирования 3-D объектов, когда имеются данные для конструирования таких моделей. В частности, представление видео-объектов с помощью 2-D-сетки допускает следующие функции: A. Манипуляция видео-объектами B. Сжатие видео-объекта C. Видео индексирование, базирующееся на содержимом 9.8.4. 3D-сетки Возможности кодирования 3-D сеток включают в себя: 9.8.5. Масштабируемость, зависящая от изображения Масштабируемость, зависящая от вида, делает возможными текстурные карты, которые используются реалистичных виртуальных средах. Она состоит в учете точки наблюдения в виртуальном 3-D мире для того чтобы передать только видимую информацию. Только часть информации затем пересылается, в зависимости от геометрии объекта и смещения точки зрения. Эта часть вычисляется как на стороне кодировщика, так и на стороне декодера. Такой подход позволяет значительно уменьшить количество передаваемой информации между удаленной базой данных и пользователем. Эта масштабируемость может работать с кодировщиками, базирующимися на DCT. 9.9. Структура средств для представления натурального видео Алгоритмы кодирования изображение MPEG-4 и видео предоставляют эффективное представление визуальных объектов произвольной формы, а также поддержку функций, базирующихся на содержимом. Они поддерживают большинство функций, уже предлагаемых в MPEG-1 и MPEG-2, включая эффективное сжатие стандартных последовательностей прямоугольных изображений при варьируемых уровнях входных форматов, частотах кадров, глубине пикселей, скоростях передачи и разных уровнях пространственной, временной и качественной масштабируемости. Базовая качественная классификация по скоростям передачи и функциональности визуального стандарта MPEG-4 для естественных изображений и видео представлена на рис. 11.
Рис. 11. Классификация средств и алгоритмов кодирования звука и изображения MPEG-4 "Ядро VLBV" (VLBV - Very Low Bit-rate Video) предлагает алгоритмы и средства для приложений, работающих при скоростях передачи между 5 и 64 кбит/с, поддерживающие последовательности изображений с низким пространственным разрешение (обычно ниже разрешения CIF) и с низкими частотами кадров (обычно ниже 15 Гц). К приложениям, поддерживающим функциональность ядра VLBV относятся: Та же самая функциональность поддерживается при высоких скоростях обмена с высокими параметрами по временному и пространственному разрешению вплоть до ITU-R Rec. 601 и больше - используя идентичные или подобные алгоритмы и средства как в ядре VLBV. Предполагается, что скорости передачи лежат в диапазоне от 64 кбит/с до 10 Мбит/с, а приложения включают широковещательное мультимедиа или интерактивное получение сигналов с качеством, сравнимым с цифровым телевидением. Функциональности, базирующиеся на содержимом, поддерживают отдельное кодирование и декодирование содержимого (т.е. физических объектов в сцене, VO). Эта особенность MPEG-4 предоставляет наиболее элементарный механизм интерактивности. Для гибридного кодирования естественных и искусственных визуальных данных (например, для виртуального присутствия или виртуального окружения) функциональность кодирования, зависящая от содержимого, допускает смешение нескольких VO от различных источников с синтетическими объектами, такими как виртуальный фон. Расширенные алгоритмы и средства MPEG-4 для функциональности, зависящей от содержимого, могут рассматриваться как супер набор ядра VLBV и средств для работы при высоких потоках данных. 9.10. Поддержка обычной функциональности и зависящей от содержимого MPEG-4 видео поддерживает обычные прямоугольные изображения и видео, а также изображения и видео произвольной формы. Кодирование обычных изображений и видео сходно с обычным кодированием в MPEG-1/2. Оно включает в себя предсказание/компенсацию перемещений за которым следует кодирование текстуры. Для функциональности, зависящей от содержимого, где входная последовательность изображений может иметь произвольную форму и положение, данный подход расширен с помощью кодирования формы и прозрачности. Форма может быть представлена двоичной маской или 8-битовой компонентой, которая позволяет описать прозрачность, если один VO объединен с другими объектами. 9.11. Видео изображение MPEG-4 и схема кодирования Рис. 12 описывает базовый подход алгоритмов MPEG-4 видео к кодированию входной последовательности изображений прямоугольной и произвольной формы.
Рис. 12. Базовая блок-схема видео-кодировщика MPEG-4 Базовая структура кодирования включает в себя кодирование формы (для VO произвольной формы), компенсацию перемещения и кодирование текстуры с привлечением DCT (используя стандарт 8>x8 DCT или DCT адаптирующийся к форме). Важным преимуществом кодирования, базирующегося на содержимом, является то, что эффективность сжатия может для некоторых видео последовательностей быть существенно улучшена путем применения соответствующих объектно-ориентированных средств предсказания перемещения для каждого из объектов на сцене. Для улучшения эффективности кодирования и гибкости презентации объектов может использоваться несколько методик предсказания перемещения: ∙ Стандартная оценка и компенсация перемещения, базирующаяся на блоках 8x8 или 16x16
пикселей. 9.11.1. Эффективность кодирования в V.2 Стандарт MPEG-4 V.2 улучшает оценку перемещения и компенсации для объектов и текстур прямоугольной и произвольной формы. Введены две методики для оценки и компенсации перемещения: ∙ Глобальная компенсация перемещения GMC (Global Motion Compensation). Кодирование глобального перемещения для объекта, использующего малое число параметров. GMC основано на глобальной оценке перемещения, деформации изображения, кодировании траектории перемещения и кодировании текстуры для ошибок предсказания. ∙ Четверть-пиксельная компенсация перемещения улучшает точность схемы компенсации, за счет лишь небольшого синтаксической и вычислительной избыточности. Точное описание перемещения приводит к малым ошибкам предсказания и, следовательно, лучшему визуальному качеству. В области текстурного кодирования DCT (SA-DCT - адаптивный к форме) улучшает эффективность кодирования объектов произвольной формы. Алгоритм SA-DCT основан на предварительно определенных ортонормальных наборах одномерных базисных функций DCT. Субъективные оценочные тесты показывают, что комбинация этих методик может дать экономию в необходимой полосе канала до 50% по сравнению с версией 1, в зависимости от типа содержимого и потока данных. 9.12. Кодирование текстур в статических изображениях Эффективное кодирование визуальных текстур и статических изображений (подлежащих, например, выкладке на анимационные сетки) поддерживается режимом визуальных текстур MPEG-4. Этот режим основан на алгоритме элементарных волн (wavelet) с нулевым деревом, который предоставляет очень высокую эффективность кодирования в широком диапазоне скоростей передачи. Вместе с высокой эффективностью сжатия, он также предлагает пространственную и качественную масштабируемость (вплоть до 11 уровней пространственной масштабируемости и непрерывной масштабируемости качества), а также кодирование объектов произвольной формы. Кодированный поток данных предназначен также для загрузки в терминал иерархии разрешения изображения. Эта технология обеспечивает масштабируемость разрешения в широком диапазоне условий наблюдения более типичном для интерактивных приложений при отображении 2-D и 3-D виртуальных миров. 9.13. Масштабируемое кодирование видео-объектов MPEG-4 поддерживает кодирование изображений и видео объектов с пространственной и временной масштабируемостью, для обычных прямоугольных и произвольных форм. Под масштабируемостью подразумевается возможность декодировать лишь часть потока данных и реконструировать изображение или их последовательность с: ∙ уменьшенной сложностью декодера и следовательно ухудшенным качеством Эта функциональность желательна для прогрессивного кодирования изображений и видео, передаваемых через неоднородные сети, а также для приложений, где получатель неспособен обеспечить полное разрешение или полное качество изображения или видео. Это может, например, случиться, когда мощность обработки или разрешение отображения ограничены. Для декодирования статических изображений, стандарт MPEG-4 предоставит 11 уровней гранулярности, а также масштабируемость качества до уровня одного бита. Для видео последовательностей в начале будет поддерживаться 3 уровня гранулярности, но ведутся работы по достижению 9 уровней. 9.14. Устойчивость в среде, предрасположенной к ошибкам MPEG-4 обеспечивает устойчивость к ошибкам, чтобы позволить доступ к изображениям и видео данным через широкий круг устройств памяти и передающих сред. В частности, благодаря быстрому росту мобильных телекоммуникаций, необычайно важно получить доступ к аудио и видео информации через радио сети. Это подразумевает необходимость успешной работы алгоритмов сжатия аудио и видео данных в среде предрасположенной к ошибкам при низких скоростях передачи (т.е., ниже 64 кбит/с). Средства противостояния ошибкам, разработанные для MPEG-4 могут быть разделены на три основные группы: ресинхронизация, восстановление данных и подавления влияния ошибок. Следует заметить, что эти категории не являются уникальными для MPEG-4, они широко используются разработчиками средств противодействия ошибкам для видео. 9.14.1. Ресинхронизация Средства ресинхронизации пытаются восстановить синхронизацию между декодером и потоком данных нарушенную в результате ошибки. Данные между точкой потери синхронизации и моментом ее восстановления выбрасываются. Метод ресинхронизации принятый MPEG-4, подобен используемому в структурах групп блоков GOB (Group of Blocks) стандартов ITU-T H.261 и H.263. В этих стандартах GOB определена, как один или более рядов макроблоков (MB). В начале нового GOB потока помещается информация, называемая заголовком GOB. Этот информационный заголовок содержит стартовый код GOB, который отличается от начального кода кадра, и позволяет декодеру локализовать данный GOB. Далее, заголовок GOB содержит информацию, которая позволяет рестартовать процесс декодирования (т.е., ресинхронизовать декодер и поток данных, а также сбросить всю информацию предсказаний). Подход GOB базируется пространственной ресинхронизации. То есть, раз в процессе кодирования достигнута позиция конкретного макроблока, в поток добавляется маркер ресинхронизации. Потенциальная проблема с этим подходом заключается в том, что из-за вариации скорости процесса кодирования положение этих маркеров в потоке четко не определено. Следовательно, определенные части сцены, такие как быстро движущиеся области, будут более уязвимы для ошибок, которые достаточно трудно исключить. Подход видео пакетов, принятый MPEG-4, базируется на периодически посылаемых в потоке данных маркерах ресинхронизации. Другими словами, длина видео пакетов не связана с числом макроблоков, а определяется числом бит, содержащихся в пакете. Если число бит в текущем видео пакете превышает заданный порог, тогда в начале следующего макроблока формируется новый видео пакет. Маркер ресинхронизации используется чтобы выделить новый видео пакет. Этот маркер отличим от всех возможных VLC-кодовых слов, а также от стартового кода VOP. Информация заголовка размещается в начале видео пакета. Информация заголовка необходима для повторного запуска процесса декодирования и включает в себя: номер макроблока первого макроблока, содержащегося в этом пакете и параметр квантования, необходимый для декодирования данный макроблок. Номер макроблока осуществляет необходимую пространственную ресинхронизацию, в то время как параметр квантования позволяет заново синхронизовать процесс дифференциального декодирования. В заголовке видео пакета содержится также код расширения заголовка (HEC). HEC представляет собой один бит, который, если равен 1, указывает на наличие дополнительной информации ресинхронизации. Сюда входит модульная временная шкала, временное приращение VOP, тип предсказания VOP и VOP F-код. Эта дополнительная информация предоставляется в случае, если заголовок VOP поврежден. Следует заметить, что, когда в рамках MPEG-4 используется средство восстановления при ошибках, некоторые средства эффективного сжатия модифицируются. Например, вся кодированная информация предсказаний заключаться в одном видео пакете так чтобы предотвратить перенос ошибок. В связи с концепцией ресинхронизацией видео пакетов, в MPEG-4 добавлен еще один метод, называемый синхронизацией с фиксированным интервалом. Этот метод требует, чтобы стартовые коды VOP и маркеры ресинхронизации (т.е., начало видео пакета) появлялись только в легальных фиксированных позициях потока данных. Это помогает избежать проблем, связанных эмуляциями стартовых кодов. То есть, когда в потоке данных встречаются ошибки, имеется возможность того, что они эмулируют стартовый код VOP. В этом случае, при использовании декодера с синхронизацией с фиксированным интервалом, стартовый код VOP ищется только в начале каждого фиксированного интервала. 9.14.2. Восстановление данных После того как синхронизация восстановлена, средства восстановления данных пытаются спасти данные, которые в общем случае могут быть потеряны. Эти средства являются не просто программами коррекции ошибок, а техникой кодирования данных, которая устойчива к ошибкам. Например, одно конкретное средство, которое было одобрено видео группой (Video Group), является обратимыми кодами переменной длины RVLC (Reversible Variable Length Codes). В этом подходе, кодовые слова переменной длины сконструированы симметрично, так что они могут читаться как в прямом, так и в обратном направлении. Пример, иллюстрирующий использование RVLC представлен на рис. 13. Вообще, в ситуации, когда блок ошибок повредил часть данных, все данные между двумя точками синхронизации теряются. Однако, как показано на рис. 13, RVLC позволяет восстановить часть этих данных. Следует заметить, что параметры, QP и HEC, показанные на рисунке, представляют поля, зарезервированные в заголовке видео пакета для параметра квантования и кода расширения заголовка, соответственно.
Рис. 13. Пример реверсивного кода переменной длины 9.14.3. Сокрытие ошибок Сокрытие ошибок (имеется в виду процедура, когда последствия ошибок не видны) является исключительно важным компонентом любого устойчивого к ошибкам видео кодека. Средства аналогичные данному рассмотрены выше, эффективность стратегии сокрытия ошибок в высшей степени зависит от работы схемы ресинхронизации. По существу, если метод ресинхронизации может эффективно локализовать ошибку, тогда проблема сокрытия ошибок становится легко решаемой. Для приложений с низкой скоростью передачи и малой задержкой текущая схема ресинхронизации позволяет получить достаточно приемлемые результаты при простой стратегии сокрытия, такой как копирование блоков из предыдущего кадра. Для дальнейшего улучшения техники сокрытия ошибок Видео Группа разработала дополнительный режим противодействия ошибкам, который дополнительно улучшает возможности декодера по локализации ошибок. Этот подход использует разделение данных, сопряженных с движением и текстурой. Такая техника требует, чтобы был введен второй маркер ресинхронизации между данными движения и текстуры. Если информация текстуры потеряна, тогда для минимизации влияния ошибок используется информация перемещения. То есть, из-за ошибок текстурные данные отбрасываются, в то время данные о движении служат для компенсации перемещения как ранее декодированной VOP. 10. Подробное техническое описание MPEG-4 аудио MPEG-4 кодирование аудио объектов предлагает средства как для представления естественных звуков (таких как речь и музыка) так и синтетических - базирующихся на структурированных описаниях. Представление для синтетического звука может быть получено из текстовых данных или так называемых инструментальных описаний и параметров кодирования для обеспечения специальных эффектов, таких как реверберация и объемное звучание. Представления обеспечивают сжатие и другую функциональность, такую как масштабируемость и обработку эффектов. Средства аудио кодирования MPEG-4, охватывающие диапазон от 6кбит/с до 24кбит/с, подвергаются верификационным тестированиям для широковещательных приложений цифрового AM-аудио совместно с консорциумом NADIB (Narrow Band Digital Broadcasting). Было обнаружено, что высокое качество может быть получено для одного и того же частотного диапазона с привлечением цифровых методик и что конфигурации масштабируемого кодировщика могут обеспечить лучшие эксплуатационные характеристики. 10.1. Натуральный звук MPEG-4 стандартизирует кодирование естественного звука при скоростях передачи от 2 кбит/с до 64 кбит/с. Когда допускается переменная скорость кодирования, допускается работа и при низких скоростях вплоть до 1.2 кбит/с. Использование стандарта MPEG-2 AAC в рамках набора средств MPEG-4 гарантирует сжатие аудио данных при любых скоростях вплоть до самых высоких. Для того чтобы достичь высокого качества аудио во всем диапазоне скоростей передачи и в то же время обеспечить дополнительную функциональность, техники кодирования голоса и общего аудио интегрированы в одну систему: ∙ Кодирование голоса при скоростях между 2 и 24 кбит/с поддерживается системой кодирования HVXC (Harmonic Vector eXcitation Coding) для рекомендуемых скоростей 2 - 4 кбит/с, и CELP (Code Excited Linear Predictive) для рабочих скоростей 4 - 24 кбит/с. Кроме того, HVXC может работать при скоростях вплоть до 1.2 кбит/с в режиме с переменной скоростью. При кодировании CELP используются две частоты стробирования, 8 и 16 кГц, чтобы поддержать узкополосную и широкополосную передачу голоса, соответственно. Подвергнуты верификации следующие рабочие режимы: HVXC при 2 и 4 кбит/с, узкополосный CELP при 6, 8.3, и 12 кбит/с, и широкополосный CELP при 18 кбит/с. ∙ Для обычного аудио кодирования при скоростях порядка и выше 6 кбит/с, применены методики преобразующего кодирования, в частности TwinVQ и AAC. Аудио сигналы в этой области обычно стробируются с частотой 8 кГц. Чтобы оптимально перекрыть весь диапазон скоростей передачи и разрешить м асштабируемость скоростей, разработана специальная система, отображенная на рис. 14.
Рис. 14. Общая блок-схема MPEG-4 аудио Масштабируемость полосы пропускания является частным случаем масштабируемости скоростей передачи, по этой причине часть потока, соответствующая части спектра полосы пропускания, может быть отброшена при передаче или декодировании. Масштабируемость сложности кодировщика позволяет кодирующим устройствам различной сложности формировать корректные информационные потоки. Масштабируемость сложности декодера позволяет данному потоку данных быть декодированному приборами с различной сложностью (и ценой). Качество звука, вообще говоря, связано со сложностью используемого кодировщика и декодера Масштабируемость работает в рамках некоторых средств MPEG-4, но может также быть применена к комбинации методик, например, к CELP, как к базовому уровню, и AAC. Уровень систем MPEG-4 позволяет использовать кодеки, следующие, например, стандартам MPEG-2 AAC. Каждый кодировщик MPEG-4 предназначен для работы в автономном режиме (stand-alone) со своим собственным синтаксисом потока данных. Дополнительная функциональность реализуется за счет возможностей кодировщика и посредством дополнительных средств вне его. 10.2. Улучшения MPEG-4 аудио V.2 Средства устойчивости к ошибкам предоставляют улучшенные рабочие характеристики для транспортных каналов, предрасположенных к ошибкам. Улучшенную устойчивость к ошибкам для AAC предлагается набором средств сокрытия ошибок. Эти средства уменьшают воспринимаемое искажение декодированного аудио сигнала, которое вызвано повреждением бит информационного потока. Предлагаются следующие средства для улучшения устойчивости к ошибкам для нескольких частей AAC-кадра: Возможности улучшения устойчивости к ошибкам для всех средств кодирования обеспечивается с помощью синтаксиса поля данных. Это позволяет применение продвинутых методик кодирования, которые могут быть адаптированы к специальным нуждам различных средств кодирования. Данный синтаксис полей данных обязателен для всех объектов версии 2. Средство защиты от ошибок (EP tool) работает со всеми аудио объектами MPEG-4 версии 2, предоставляя гибкую возможность конфигурирования для широкого диапазона канальных условий. Главными особенностями средства EP являются следующие: Алгоритмы кодирования MPEG-4 аудио версии 2 предоставляет классификацию всех полей потока согласно их чувствительности к ошибкам. На основе этого, поток данных делится на несколько классов, которые могут быть защищены раздельно с помощью инструмента EP, так что более чувствительные к ошибкам части окажутся защищены более тщательно. 10.2.2. Аудио-кодирование с малыми задержками В то время как универсальный аудио кодировщик MPEG-4 очень эффективен при кодировании аудио сигналов при низких скоростях передачи, он имеет алгоритмическую задержку кодирования/декодирования, достигающую нескольких сот миллисекунд и является, таким образом, неподходящим для приложений, требующих малых задержек кодирования, таких как двунаправленные коммуникации реального времени. Для обычного аудио кодировщика, работающего при частоте стробирования 24 кГц и скорости передачи 24 кбит/с, алгоритмическая задержка кодирования составляет 110 мс плюс до 210 мс дополнительно в случае использования буфера. Чтобы кодировать обычные аудио сигналы enable с алгоритмической задержкой, не превышающей 20 мс, MPEG-4 версии 2 специфицирует кодировщик, который использует модификацию алгоритма MPEG-2/4 AAC (Advanced Audio Coding). По сравнению со схемами кодирования речи, этот кодировщик позволяет сжимать обычные типы аудио сигналов, включая музыку, при достаточно низких задержках. Он работает вплоть до частот стробирования 48 кГц и использует длину кадров 512 или 480 значений стробирования, по сравнению с 1024 или 960 значений, используемых в стандарте MPEG-2/4 AAC. Размер окна, используемого при анализе и синтезе блока фильтров, уменьшен в два раза. Чтобы уменьшить артифакты предэхо в случае переходных сигналов используется переключение размера окна. Для непереходных частей сигнала используется окно синусоидальной формы, в то время как в случае переходных сигналов используется так называемое окно с низким перекрытием. Использование буфера битов минимизируется, чтобы сократить задержку. В крайнем случае, такой буфер вообще не используется. 10.2.3. Масштабируемость гранулярности Масштабируемость скорости передачи, известная как встроенное кодирование, является крайне желательной функцией. Обычный аудио кодировщик версии 1 поддерживает масштабируемость с большими шагами, где базовый уровень потока данных может комбинироваться с одним или более улучшенных уровней потока данных, чтобы можно было работать с высокими скоростями и, таким образом, получить лучшее качество звука. В типовой конфигурации может использоваться базовый уровень 24 кбит/с и два по 16 кбит/с, позволяя декодирование с полной скоростью 24 кбит/с (моно), 40 кбит/с (стерео), и 56 кбит/с (стерео). Из-за побочной информации передаваемой на каждом уровне, малые уровни-добавки поддерживаются в версии 1 не очень эффективно. Чтобы получить эффективную масштабируемость с малыми шагами для стандартного аудио кодировщика, в версии 2 имеется средство побитового арифметического кодирования BSAC (Bit-Sliced Arithmetic Coding). Это средство используется в комбинации с AAC-кодированием и замещает бесшумное кодирование спектральных данных и масштабных коэффициентов. BSAC предоставляет масштабируемость шагами в 1 кбит/с на аудио канал, т.е. шагами по 2 кбит/с для стерео сигнала. Используется один базовый поток (уровень) данных и много небольших потоков улучшения. Базовый уровень содержит общую информацию вида, специфическую информацию первого уровня и аудио данные первого уровня. Потоки улучшения содержат только специфические данные вида и аудио данные соответствующего слоя. Чтобы получить масштабируемость с небольшими шагами, используется побитовая схема a квантования спектральных данных. Сначала преобразуемые спектральные величины группируются в частотные диапазоны. Каждая из этих групп содержит оцифрованные спектральные величины в их двоичном представлении. Затем биты группы обрабатываются порциями согласно их значимости. Таким образом сначала обрабатываются все наиболее значимые биты (MSB) оцифрованных величин в группе и т.д. Эти группы бит затем кодируются с привлечением арифметической схемы кодирования, чтобы получить энтропийные коды с минимальной избыточностью. Представлены различные модели арифметического кодирования, чтобы перекрыть различные статистические особенности группировок бит. Верификационные тесты показали, что аспект масштабируемости этого средства ведет себя достаточно хорошо в широком диапазоне скоростей передачи. При высоких скоростях оно столь же хорошо, как главный профайл AAC, работающий на той же скорости, в то время как при нижних скоростях функция масштабируемости требует скромной избыточности по отношению к основному профайлу AAC, работающий на той же скорости. 10.2.4. Параметрическое кодирование звука Средства параметрического аудио-кодирования сочетают в себе низкую скорость кодирования обычных аудио сигналов с возможностью модификации скорости воспроизведения или шага при декодировании без бока обработки эффектов. В сочетании со средствами кодирования речи и звука версии 1, ожидается улучшенная эффективность кодирования для использования объектов, базирующихся на кодировании, которое допускает выбор и/или переключение между разными техниками кодирования. Параметрическое аудио-кодирование использует для кодирования общих аудио сигналов технику HILN (Harmonic and Individual Lines plus Noise) при скоростях 4 кбит/с, а выше применяется параметрическое представление аудио сигналов. Основной идеей этой методики является разложение входного сигнала на аудио объекты, которые описываются соответствующими моделями источника и представляются модельными параметрами. В кодировщике HILN используются модели объектов для синусоид, гармонических тонов и шума. Как известно из кодирования речи, где используются специализированные модели источника, основанные на процессе генерации звуков в человеческом голосовом тракте, продвинутые модели источника могут иметь преимущество в частности для схем кодирования с очень низкими скоростями передачи. Из-за очень низкой скорости передачи могут быть переданы только параметры для ограниченного числа объектов. Следовательно, модель восприятия устроена так, чтобы отбирать те объекты, которые наиболее важны для качества приема сигнала. В HILN, параметры частоты и амплитуды оцифровываются согласно с "заметной разницей", известной из психо-акустики. Спектральный конверт шума и гармонический тон описан с использованием моделирования LPC. Корреляция между параметрами одного кадра и между последовательными кадрами анализируется методом предсказания параметров. Оцифрованные параметры подвергаются энтропийному кодированию, после чего эти данные вводятся в общий информационный поток. Очень интересное свойство этой схемы параметрического кодирования происходит из того факта, что сигнал описан через параметры частоты и амплитуды. Эта презентация сигнала позволяет изменять скорость и высоту звука простой вариацией параметров декодера. Параметрический аудио кодировщик HILN может быть объединен с параметрическим кодировщиком речи MPEG-4 (HVXC), что позволит получить интегрированный параметрический кодировщик, покрывающий широкий диапазон сигналов и скоростей передачи. Этот интегрированный кодировщик поддерживает регулировку скорости и тона. Используя в кодировщике средство классификации речи/музыки, можно автоматически выбрать HVXC для сигналов речи и HILN для музыкальных сигналов. Такое автоматическое переключение HVXC/HILN было успешно продемонстрировано, а средство классификации описано в информативном приложении стандарта версии 2. 10.2.5. Сжатие тишины CELP Средство "сжатия тишины" уменьшает среднюю скорость передачи благодаря более низкому сжатию пауз (тишины). В кодировщике, детектор активности голоса используется для разделения областей с нормальной голосовой активностью и зон молчания или фонового шума. Во время нормальной голосовой активности используется кодирование CELP как в версии 1. В противном случае передается дескриптор SID (Silence Insertion Descriptor) при малой скорости передачи. Этот дескриптор SID активирует в декодере CNG (Comfort Noise Generator). Амплитуда и форма спектра этого шума специфицируются энергией и параметрами LPC как в обычном кадре CELP. Эти параметры являются опционной частью SID и таким образом могут модифицироваться. 10.2.6. Устойчивое к ошибкам HVXC Объект HVXC, устойчивый к ошибкам (ER) поддерживается средствами параметрического кодирования голоса (ER HVXC), которые предоставляют режимы с фиксированными скоростями обмена (2.0-4.0 кбит/с) и режим с переменной скоростью передачи (<2.0 кбит/с, <4.0 кбит/с) в раках масштабируемой и не масштабируемой схем. В версии 1 HVXC, режим с переменной скоростью передачи поддерживается максимум 2.0 кбит/с, а режим с переменной скоростью передачи в версии ER HVXC 2 дополнительно поддерживается максимум 4.0 кбит/с. ER HVXC обеспечивает качество передачи голоса международных линий (100-3800 Hz) при частоте стробирования 8кГц. Когда разрешен режим с переменной скоростью передачи, возможна работа при низкой средней скорости передачи. Речь, кодированная в режиме с переменной скоростью передачи при среднем потоке 1.5 кбит/с, и типовом среднем значении 3.0 кбит/с имеет существенно то же качество, что для 2.0 кбит/с при фиксированной скорости и 4.0 кбит/с, соответственно. Функциональность изменения тона и скорости при декодировании поддерживается для всех режимов. Кодировщик речи ER HVXC ориентирован на приложения от мобильной и спутниковой связи, до IP-телефонии, и голосовых баз данных. 10.2.7. Пространственные характеристики среды Средства пространственной характеристики среды позволяют создавать аудио сцены с более естественными источниками звука и моделированием звукового окружения, чем это возможно в версии 1. Поддерживается как физический подход, так и подход восприятия. Физический подход основан на описании акустических свойств среды (например, геометрии комнаты, свойств конструкционных материалов, положения источников звука) и может быть использован в приложениях подобно 3-D виртуальной реальности. Подход с позиций восприятия позволяет на высоком уровне описать аудио восприятие сцены, основанное на параметрах, подобных тем, что используются блоком эффекта реверберации. Таким образом, аудио и визуальная сцена могут быть сформированы независимо, как это обычно требуется в случае кинофильмов. Хотя пространственной характеристики среды относятся к аудио, они являются частью описания BIFS (BInary Format for Scene) в системах MPEG-4 и называются продвинутым AudioBIFS. 10.2.8. Обратный канал Обратный канал (back channel) позволяет передать запрос клиента и/или клиентского терминала серверу. Посредством обратного канала может быть реализована интерактивность. В системе MPEG-4 о необходимости обратного канала (back channel) клиентский терминал оповещается с помощью соответствующего дескриптора элементарного потока, характеризующего параметры этого канала. Терминал клиента открывает этот обратный канал, так же как и обычные каналы. Объекты (например, медиа кодировщики или декодеры), которые соединены через обратный канал известны через параметры, полученные через дескриптор элементарного потока и за счет ассоциации дескриптора элементарного потока с дескриптором объекта. В MPEG-4 аудио, обратный канал обеспечивает обратную связь для настройки скорости передачи, масштабируемости и системы защиты от ошибок. 10.2.9. Транспортный поток звука Транспортный поток MPEG-4 аудио определяет механизм передачи аудио потоков MPEG-4 без использования систем MPEG-4 и предназначен исключительно для аудио приложений. Транспортный механизм использует двухуровневый подход, а именно уровни мультиплексирования и синхронизации. Уровень мультиплексирования (Low-overhead MPEG-4 Audio Transport Multiplex: LATM) управляет мультиплексированием нескольких информационных полей MPEG-4 аудио и аудио конфигурационной информации. Уровень синхронизации специфицирует синтаксис транспортного потока MPEG-4 аудио, который называется LOAS (Low Overhead Audio Stream - аудио поток с низкой избыточностью). Интерфейсный формат для транспортного уровня зависит от ниже лежащего коммуникационного уровня. 10.3. Синтетический звук MPEG-4 определяет декодеры для генерирования звука на основе нескольких видов структурированного ввода. Текстовый ввод Text преобразуется в декодере TTS (Text-To-Speech), в то время как прочие звуки, включая музыку, могут синтезироваться стандартным путем. Синтетическая музыка может транспортироваться при крайне низких потоках данных. Декодеры TTS (Text To Speech) работают при скоростях передачи от 200 бит/с до 1.2 Кбит/с, что позволяет использовать при синтезе речи в качестве входных данных текст или текст с просодическими параметрами (тональная конструкция, длительность фонемы, и т.д.). Такие декодеры поддерживают генерацию параметров, которые могут быть использованы для синхронизации с анимацией лица, при осуществлении перевода с другого языка и для работы с международными символами фонем. Дополнительная разметка используется для передачи в тексте управляющей информации, которая переадресуется другим компонентам для обеспечения синхронизации с текстом. Заметим, что MPEG-4 обеспечивает стандартный интерфейс для работы кодировщика TTS (TTSI = Text To Speech Interface), но не для стандартного TTS-синтезатора. 10.3.1. Синтез с множественным управлением (Score Driven Synthesis). Средства структурированного аудио декодируют входные данные и формируют выходной звуковой сигнал. Это декодирование управляется специальным языком синтеза, называемым SAOL (Structured Audio Orchestra Language), который является частью стандарта MPEG-4. Этот язык используется для определения "оркестра", созданного из "инструментов" (загруженных в терминал потоком данных), которые формирует и обрабатывает управляющую информацию. Инструмент представляет собой маленькую сеть примитивов обработки сигналов, которые могут эмулировать некоторые специфические звуки, такие, которые могут производить настоящие акустические инструменты. Сеть обработки сигналов может быть реализована аппаратно или программно и включать как генерацию, так и обработку звуков, а также манипуляцию записанными ранее звуками. MPEG-4 не стандартизует "единственный метод" синтеза, а скорее описывает путь описания методов синтеза. Любой сегодняшний или будущий метод синтеза звука может быть описан в SAOL, включая таблицу длин волн, FM, физическое моделирование и гранулярный синтез, а также непараметрические гибриды этих методов. Управление синтезом выполняется путем включения "примитивов" (score) или "скриптов" в поток данных. Примитив представляет собой набор последовательных команд, которые включают различные инструменты в определенное время и добавляют их сигнал в общий музыкальный поток или формируют заданные звуковые эффекты. Описание примитива, записанное на языке SASL (Structured Audio Score Language), может использоваться для генерации новых звуков, а также включать дополнительную управляющую информацию для модификации существующих звуков. Это позволяет композитору осуществлять тонкое управление синтезированными звуками. Для процессов синтеза, которые не требуют такого тонкого контроля, для управления оркестром может также использоваться протокол MIDI. Тщательный контроль в сочетании с описанием специализированных инструментов, позволяет генерировать звуки, начиная с простых аудио эффектов, таких как звуки шагов или закрытия двери, кончая естественными звуками, такими как шум дождя или музыка, исполняемая на определенном инструменте или синтетическая музыка с полным набором разнообразных эффектов. Для терминалов с меньшей функциональностью, и для приложений, которые не требуют такого сложного синтеза, стандартизован также "формат волновой таблицы" ("wavetable bank format"). Используя этот формат, можно загрузить звуковые образцы для использования при синтезе, а также выполнить простую обработку, такую как фильтрация, реверберация, и ввод эффекта хора. В этом случае вычислительная сложность необходимого процесса декодирования может быть точно определена из наблюдения потока данных, что невозможно при использовании SAOL. 11. Приложение. Словарь и сокращения
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
2.5 Методы преобразования и передачи изображения
UP:
2.4 Методы преобразования и передачи звуковых сигналов
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
2.6.2 Локально адаптивный алгоритм сжатия
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Этот алгоритм используется для кодирования (L,I), где L строка длиной N, а I - индекс. Это кодирование содержит в себе несколько этапов. 1. Сначала кодируется каждый символ L с использованием локально адаптивного алгоритма для каждого из символов индивидуально. Определяется вектор целых чисел R[0],.,R[N-1], который представляет собой коды для символов L[0],.,L[N-1]. Инициализируется список символов Y, который содержит в себе каждый символ из алфавита Х только один раз. Для каждого i = 0,.,N-1 устанавливается R[i] равным числу символов, предшествующих символу L[i] из списка Y. Взяв Y = ['a','b','c','r'] в качестве исходного и L = 'caraab', вычисляем вектор R: (2 1 3 1 0 3). 2. Применяем алгоритм Хафмана или другой аналогичный алгоритм сжатия к элементам R, рассматривая каждый элемент в качестве объекта для сжатия. В результате получается код OUT и индекс I. Рассмотрим процедуру декодирования полученного сжатого текста (OUT,I). Здесь на основе (OUT,I) необходимо вычислить (L,I). Предполагается, что список Y известен.
Наиболее важным фактором, определяющим скорость сжатия, является время, необходимое для сортировки вращений во входном блоке. Наиболее быстрый способ решения проблемы заключается в сортировке связанных строк по суффиксам. Для того чтобы сжать строку S, сначала сформируем строку S', которая является объединением S c EOF, новым символом, который не встречается в S. После этого используется стандартный алгоритм к строке S'. Так как EOF отличается от прочих символов в S, суффиксы S' сортируются в том же порядке, как и вращения S'. Это может быть сделано путем построения дерева суффиксов, которое может быть затем обойдено в лексикографическом порядке для сортировки суффиксов. Для этой цели может быть использован алгоритм формирования дерева суффиксов Мак-Крейгта. Его быстродействие составляет 40% от наиболее быстрой методики в случае работы с текстами. Алгоритм работы с деревом суффиксов требует более четырех слов на каждый исходный символ. Манбер и Майерс предложили простой алгоритм сортировки суффиксов строки. Этот алгоритм требует только двух слов на каждый входной символ. Алгоритм работает сначала с первыми i символами суффикса а за тем, используя положения суффиксов в сортируемом массиве, производит сортировку для первых 2i символов. К сожалению этот алгоритм работает заметно медленнее. В работе [1] предложен несколько лучший алгоритм сортировки суффиксов. В этом алгоритме сортируются суффиксы строки S, которая содержит N символов S[0,.,N-1].
Данный алгоритм может быть улучшен различными способами. Одним из самоочевидных методов является выбор символа ch на этапе 5, начиная с наименьшего общего символа в S и предшествующий наиболее общему. Ссылки
Смотри также раздел 2.6.3 "Сжатие данных с использованием преобразования Барроуза-Вилера", |
|
Previous:
2.6.1 Алгоритм Зива-Лемпеля
UP:
2.6 Методы сжатия информации
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Майкл Барроуз и Давид Вилер (Burrows-Wheeler) в 1994 году предложили свой алгоритм преобразования (BWT). Этот алгоритм работает с блоками данных и обеспечивает эффективное сжатие без потери информации. В результате преобразования блок данных имеет ту же длину, но другой порядок расположения символов. Алгоритм тем эффективнее, чем больший блок данных преобразуется (например, 256-512 Кбайт). Пояснение работы алгоритма будет выполнено на ограниченном объеме исходных данных (строка S длиной N, например, SEMENOV). Строка S рассматривается как последовательность, состоящая из N строк. Сначала осуществляется циклический сдвиг строки S и формируется N-1 новая строка. На практике строки не размножаются, а создается массив указателей на циклический буфер, где лежит исходная строка S.
Далее выполняется лексикографическое упорядочение (сортировка) этих строк (указателей). Для упорядочения можно использовать С-функции типа strcmp() или memcmp() (учитывая особенности структуры буфера, это должны быть их функциональные аналоги).
Первая колонка помечена буквой F, а последняя - L. Колонка F (EEMNOSV) содержит все символы исходной строки S, записанные в упорядоченной последовательности. Строка L представляет собой последовательность префиксных символов для строки S. Результатом работы алгоритма BWT является строка L и первичный индекс, который представляет собой номер элемента строки L, где хранится первый символ исходной строки S. В приведенном примере индекс равен 1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
2.6.2 Локально адаптивный алгоритм сжатия
UP:
2.6 Методы сжатия информации
|
|
|
|
2.6.4 Метод Шеннона-Фано
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Данный метод выделяется своей простотой. Берутся исходные сообщения m(i) и их вероятности появления P(m(i)). Этот список делится на две группы с примерно равной интегральной вероятностью. Каждому сообщению из группы 1 присваивается 0 в качестве первой цифры кода. Сообщениям из второй группы ставятся в соответствие коды, начинающиеся с 1. Каждая из этих групп делится на две аналогичным образом и добавляется еще одна цифра кода. Процесс продолжается до тех пор, пока не будут получены группы, содержащие лишь одно сообщение. Каждому сообщению в результате будет присвоен код x c длиной -lg(P(x)). Это справедливо, если возможно деление на подгруппы с совершенно равной суммарной вероятностью. Если же это невозможно, некоторые коды будут иметь длину -lg(P(x))+1. Алгоритм Шеннона-Фано не гарантирует оптимального кодирования. Смотри http://www.ics.uci.edu/~dan/pubs/DC-Sec3.html. |
|
Previous:
2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера
UP:
2.6 Методы сжатия информации
|
|
|
|
2.6.5 Статический алгоритм Хафмана
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Статический алгоритм Хафмана можно считать классическим (см. также Р. Галлагер. Теория информации и надежная связь. "Советское радио", Москва, 1974.) Определение статический в данном случае отностится к используемым словарям. Смотри также www.ics.ics.uci.edu/~dan/pubs/DataCompression.html (Debra A. Lelewer и Daniel S. Hirschberg). Пусть сообщения m(1),.,m(n) имеют вероятности P(m(1)),. P(m(n)) и пусть для определенности они упорядочены так, что P(m(1)) Ё P(m(2)) Ё . Ё P(m(N)). Пусть x1,., xn - совокупность двоичных кодов и пусть l1, l2,., lN - длины этих кодов. Задачей алгоритма является установление соответствия между m(i) и xj . Можно показать, что для любого ансамбля сообщений с полным числом более 2 существует двоичный код, в котором два наименее вероятных кода xN и xN-1 имеют одну и ту же длину и отличаются лишь последним символом: xN имеет последний бит 1, а xN-1 - 0. Редуцированный ансамбль будет иметь свои два наименее вероятные сообщения сгруппированными вместе. После этого можно получить новый редуцированный ансамбль и так далее. Процедура может быть продолжена до тех пор, пока в очередном ансамбле не останется только два сообщения. Процедура реализации алгоритма сводится к следующему (см. рис. 2.6.5.1). Сначала группируются два наименее вероятные сообщения, предпоследнему сообщению ставится в соответствие код с младшим битом, равным нулю, а последнему - код с единичным младшим битом (на рисунке m(4) и m(5)). Вероятности этих двух сообщений складываются, после чего ищутся два наименее вероятные сообщения во вновь полученном ансамбле (m(3) и m`(4); p(m`(4)) = p(m(4)) + P(m(5))).
Рис. 2.6.5.1 Пример реализации алгоритма Хафмана На следующем шаге наименее вероятными сообщениями окажутся m(1) и m(2). Кодовые слова на полученном дереве считываются справа налево. Алгоритм выдает оптимальный код (минимальная избыточность). При использовании кодирования по схеме Хафмана надо вместе с закодированным текстом передать соответствующий алфавит. При передаче больших фрагментов избыточность, сопряженная с этим не может быть значительной. Возможно применение стандартных алфавитов (кодовых таблиц) для пересылки английского, русского, французского и т.д. текстов, программных текстов на С++, Паскале и т.д. Кодирование при этом не будет оптимальным, но исключается статистическая обработка пересылаемых фрагментов и отпадает необходимость пересылки кодовых таблиц. |
|
Previous:
2.6.4 Метод Шеннона-Фано
UP:
2.6 Методы сжатия информации
|
|
|
||||||||||||||||||||||||||||
|
2.6 Методы сжатия информации
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||
Полагаю, что все читатели знакомы с архиваторами файлов, вероятно, многие из вас неоднократно ими пользовались. Целью архивации файлов является экономия места на жестком или гибком магнитном диске. Кому не приходилось время от времени задумываться над тем, войдет ли данный файл на дискету? Существует большое число программ-архиваторов, имеются и специальные системные программные средства типа Stacker или Doublespace и т.д., решающие эту проблему. Первые теоретические разработки в области сжатия информации относятся к концу 40-х годов. В конце семидесятых появились работы Шеннона, Фано и Хафмана. К этому времени относится и создание алгоритма FGK (Faller, Gallager, Knuth), где используется идея "сродства", а получатель и отправитель динамически меняют дерево кодов (смотри, например, http://www.ics.uci.edu/~dan/plus/DC-Sec4.html). Пропускная способность каналов связи более дорогостоящий ресурс, чем дисковое пространство, по этой причине сжатие данных до или во время их передачи еще более актуально. Здесь целью сжатия информации является экономия пропускной способности и в конечном итоге ее увеличение. Все известные алгоритмы сжатия сводятся к шифрованию входной информации, а принимающая сторона выполняет дешифровку принятых данных. Существуют методы, которые предполагают некоторые потери исходных данных, другие алгоритмы позволяют преобразовать информацию без потерь. Сжатие с потерями используется при передаче звуковой или графической информации, при этом учитывается несовершенство органов слуха и зрения, которые не замечают некоторого ухудшения качества, связанного с этими потерями. Более детально эти методы рассмотрены в разделе "Преобразование, кодировка и передача информации". Сжатие информации без потерь осуществляется статистическим кодированием или на основе предварительно созданного словаря. Статистические алгоритмы (напр., схема кодирования Хафмана) присваивают каждому входному символу определенный код. При этом наиболее часто используемому символу присваивается наиболее короткий код, а наиболее редкому - более длинный. Таблицы кодирования создаются заранее и имеют ограниченный размер. Этот алгоритм обеспечивает наибольшее быстродействие и наименьшие задержки. Для получения высоких коэффициентов сжатия статистический метод требует больших объемов памяти. Альтернативой статистическому алгоритму является схема сжатия, основанная на динамически изменяемом словаре (напр., алгоритмы Лембеля-Зива). Данный метод предполагает замену потока символов кодами, записанными в памяти в виде словаря (таблица перекодировки). Соотношение между символами и кодами меняется вместе с изменением данных. Таблицы кодирования периодически меняются, что делает метод более гибким. Размер небольших словарей лежит в пределах 2-32 килобайт, но более высоких коэффициентов сжатия можно достичь при заметно больших словарях до 400 килобайт. Реализация алгоритма возможна в двух режимах: непрерывном и пакетном. Первый использует для создания и поддержки словаря непрерывный поток символов. При этом возможен многопротокольный режим (например, TCP/IP и DECnet). Словари сжатия и декомпрессии должны изменяться синхронно, а канал должен быть достаточно надежен (напр., X.25 или PPP), что гарантирует отсутствие искажения словаря при повреждении или потере пакета. При искажении одного из словарей оба ликвидируются и должны быть созданы вновь. Пакетный режим сжатия также использует поток символов для создания и поддержания словаря, но поток здесь ограничен одним пакетом и по этой причине синхронизация словарей ограничена границами кадра. Для пакетного режима достаточно иметь словарь объемом, порядка 4 Кбайт. Непрерывный режим обеспечивает лучшие коэффициенты сжатия, но задержка получения информации (сумма времен сжатия и декомпрессии) при этом больше, чем в пакетном режиме. При передаче пакетов иногда применяется сжатие заголовков, например, алгоритм Ван Якобсона (RFC-1144). Этот алгоритм используется при скоростях передачи менее 64 Kбит/с. При этом достижимо повышение пропускной способности на 50% для скорости передачи 4800 бит/с. Сжатие заголовков зависит от типа протокола. При передаче больших пакетов на сверх высоких скоростях по региональным сетям используются специальные канальные алгоритмы, независящие от рабочих протоколов. Канальные методы сжатия информации не могут использоваться для сетей, базирующихся на пакетной технологии, SMDS (Switched Multi-megabit Data Service), ATM, X.25 и Frame Relay. Канальные методы сжатия дают хорошие результаты при соединении по схеме точка-точка, а при использовании маршрутизаторов возникают проблемы - ведь нужно выполнять процедуры сжатия/декомпрессии в каждом маршрутизаторе, что заметно увеличивает суммарное время доставки информации. Возникает и проблема совместимости маршрутизаторов, которая может быть устранена процедурой идентификации при у становлении виртуального канала. Иногда для сжатия информации используют аппаратные средства. Такие устройства должны располагаться как со стороны передатчика, так и со стороны приемника. Как правило, они дают хорошие коэффициенты сжатия и приемлемые задержки, но они применимы лишь при соединениях точка-точка. Такие устройства могут быть внешними или встроенными, появились и специальные интегральные схемы, решающие задачи сжатия/декомпрессии. На практике задача может решаться как аппаратно, так и программно, возможны и комбинированные решения. Если при работе с пакетами заголовки оставлять неизмененными, а сжимать только информационные поля, ограничение на использование стандартных маршрутизаторов может быть снято. Пакеты будут доставляться конечному адресату, и только там будет выполняться процедура декомпрессии. Такая схема сжатия данных приемлема для сетей X.25, SMDS, Frame Relay и ATM. Маршрутизаторы корпорации CISCO поддерживают практически все режимы сжатия/декомпрессии информации, перечисленные выше. Сжатие информации является актуальной задачей, как при ее хранении, так и при пересылке. Сначала рассмотрим вариант алгоритма Зива-Лемпеля. |
||||||||||||||||||||||||||||
|
Previous:
2.5.2 Стандарт MPEG-7
UP:
2.4 Методы преобразования и передачи звуковых сигналов
|
|
|
|||||||||||||||||||||||||||||||||||
|
2.6.1 Алгоритм Зива-Лемпеля
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||
|
Большинство алгоритмов сжатия базируется на последовательной схеме сжатия Лемпеля-Зива (Lempel-Ziv, 1977). Этот алгоритм используется, в частности, стандартной процедурой UNIX Compress. Методики со статистическим моделированием могут обеспечить лучшее сжатие, но они заметно медленнее. Но существует алгоритм, который совмещает в себе лучшие из черт названных выше. Этот алгоритм не предусматривает последовательной обработки входных данных, а обрабатывает текст по-блочно. Здесь используется обратимое преобразование блока данных к виду, который позволяет эффективно сжать данные с помощью простых алгоритмов. Преобразование имеет целью сгруппировать символы так, чтобы вероятность появления последовательностей идентичных символов значительно возросла. Такой текст может быть легко сжат посредством локально-адаптивных алгоритмов в сочетании с кодировкой Хафмана и арифметической кодировкой. Последовательность S, содержащая N символов ({S(0),. S(N-1)}), подвергается N циклическим сдвигам (вращениям), лексикографической сортировке, а последний символ при каждом вращении извлекается. Из этих символов формируется строка L, где i-ый символ является последним символом i-го вращения. Кроме строки L создается индекс I исходной строки S в упорядоченном списке вращений. Существует эффективный алгоритм восстановления исходной последовательности символов S на основе строки L и индекса I. Процедура сортировки объединяет результаты вращений с идентичными начальными символами. Предполагается, что символы в S соответствуют алфавиту, содержащему K символов. Для пояснения работы алгоритма возьмем последовательность S= "abraca" (N=6), алфавит X = {'a','b','c','r'}. 1. Формируем матрицу из N*N элементов, чьи строки представляют собой результаты циклического сдвига (вращений) исходной последовательности S, отсортированных лексикографически. По крайней мере одна из строк M содержит исходную последовательность S. Пусть I является индексом строки S. В приведенном примере индекс I=1, а матрица M имеет вид:
2. Пусть строка L представляет собой последнюю колонку матрицы M с символами L[0],.,L[N-1] (соответствуют M[0,N-1],.,M[N-1,N-1]). Формируем строку последних символов вращений. Окончательный результат характеризуется (L,I). В данном примере L='caraab', I =1. Процедура декомпрессии использует L и I. Целью этой процедуры является получение исходной последовательности из N символов (S). 1. Сначала вычисляем первую колонку матрицы M (F). Это делается путем сортировки символов строки L. Каждая колонка исходной матрицы M представляет собой перестановки исходной последовательности S. Таким образом, первая колонка F и L являются перестановками S. Так как строки в M упорядочены, размещение символов в F также упорядочено. F='aaabcr'. 2. Рассматриваем ряды матрицы M, которые начинаются с заданного символа ch. Строки матрицы М упорядочены лексикографически, поэтому строки, начинающиеся с ch упорядочены аналогичным образом. Определим матрицу M', которая получается из строк матрицы M путем циклического сдвига на один символ вправо. Для каждого i=0,., N-1 и каждого j=0,.,N-1, M'[i,j] = m[i,(j-1) mod N] В рассмотренном примере M и M' имеют вид:
Подобно M каждая строка M' является вращением S, и для каждой строки M существует соответствующая строка M'. M' получена из M так, что строки M' упорядочены лексикографически, начиная со второго символа. Таким образом, если мы рассмотрим только те строки M', которые начинаются с заданного символа ch, они должны следовать упорядоченным образом с учетом второго символа. Следовательно, для любого заданного символа ch, строки M, которые начинаются с ch, появляются в том же порядке что и в M', начинающиеся с ch. В нашем примере это видно на примере строк, начинающихся с 'a'. Строки 'aabrac', 'abraca' и 'acaabr' имеют номера 0, 1 и 2 в M и 1, 3, 4 в M'. Используя F и L, первые колонки M и M' мы вычислим вектор Т, который указывает на соответствие между строками двух матриц, с учетом того, что для каждого j = 0,.,N-1 строки j M' соответствуют строкам T[j] M. Если L[j] является к-ым появлением ch в L, тогда T[j]=1, где F[i] является к-ым появлением ch в F. Заметьте, что Т представляет соответствие один в один между элементами F и элементами L, а F[T[j]] = L[j]. В нашем примере T равно: (4 0 5 1 2 3). 3. Теперь для каждого i = 0,., N-1 символы L[i] и F[i] являются соответственно последними и первыми символами строки i матрицы M. Так как каждая строка является вращением S, символ L[i] является циклическим предшественником символа F[i] в S. Из Т мы имеем F[T[j]] = L[j]. Подставляя i =T[j], мы получаем символ L[T(j)], который циклически предшествует символу L[j] в S. Индекс I указывает на строку М, где записана строка S. Таким образом, последний символ S равен L[I]. Мы используем вектор T для получения предшественников каждого символа: для каждого i = 0,.,N-1 S[N-1-i] = L[Ti[I]], где T0[x] =x, а Ti+1[x] = T[Ti[x]. Эта процедура позволяет восстановить первоначальную последовательность символов S ('abraca'). Последовательность Ti[I] для i =0,.,N-1 не обязательно является перестановкой чисел 0,.,N-1. Если исходная последовательность S является формой Zp для некоторой подстановки Z и для некоторого p>1, тогда последовательность Ti[I] для i = 0,.,N-1 будет также формой Z'p для некоторой субпоследовательности Z'. Таким образом, если S = 'cancan', Z = 'can' и p=2, последовательность Ti[I] для i = 0,.,N-1 будет [2,4,0,2,4,0]. Описанный выше алгоритм упорядочивает вращения исходной последовательности символов S и формирует строку L, состоящую из последних символов вращений. Для того, чтобы понять, почему такое упорядочение приводит к более эффективному сжатию, рассмотрим воздействие на отдельную букву в обычном слове английского текста. Возьмем в качестве примера букву "t" в слове 'the' и предположим, что исходная последовательность содержит много таких слов. Когда список вращений упорядочен, все вращения, начинающиеся с 'he', будут взаимно упорядочены. Один отрезок строки L будет содержать непропорционально большое число 't', перемешанных с другими символами, которые могут предшествовать 'he', такими как пробел, 's', 'T' и 'S'. Аналогичные аргументы могут быть использованы для всех символов всех слов, таким образом, любая область строки L будет содержать большое число некоторых символов. В результате вероятность того, что символ 'ch' встретится в данной точке L, весьма велика, если ch встречается вблизи этой точки L, и мала в противоположном случае. Это свойство способствует эффективной работе локально адаптивных алгоритмов сжатия, где кодируется относительное положение идентичных символов. В случае применения к строке L, такой кодировщик будет выдавать малые числа, которые могут способствовать эффективной работе последующего кодирования, например, посредством алгоритма Хафмана.
Ссылки
|
|||||||||||||||||||||||||||||||||||
|
Previous:
2.6 Методы сжатия информации
UP:
2.6 Методы сжатия информации
|
|
|
||||||
|
2.7 Обнаружение ошибок
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||
Каналы передачи данных ненадежны, да и само оборудование обработки информации работает со сбоями. По этой причине важную роль приобретают механизмы детектирования ошибок. Ведь если ошибка обнаружена, можно осуществить повторную передачу данных и решить проблему. Если исходный код по своей длине равен полученному коду, обнаружить ошибку передачи не предоставляется возможным. Простейшим способом обнаружения ошибок является контроль по четности. Обычно контролируется передача блока данных (М бит). Этому блоку ставится в соответствие кодовое слово длиной N бит, причем N>M. Избыточность кода характеризуется величиной 1-M/N. Вероятность обнаружения ошибки определяется отношением M/N (чем меньше это отношение, тем выше вероятность обнаружения ошибки, но и выше избыточность). При передаче информации она кодируется таким образом, чтобы с одной стороны характеризовать ее минимальным числом символов, а с другой - минимизировать вероятность ошибки при декодировании получателем. Для выбора типа кодирования важную роль играет так называемое расстояние Хэмминга. Пусть А и Б две двоичные кодовые последовательности равной длины. Расстояние Хэмминга между двумя этими кодовыми последовательностями равно числу символов, которыми они отличаются. Например, расстояние Хэмминга между кодами 00111 и 10101 равно 2. Можно показать, что для детектирования ошибок в n битах, схема кодирования требует применения кодовых слов с расстоянием Хэмминга не менее N+1. Можно также показать, что для исправления ошибок в N битах необходима схема кодирования с расстоянием Хэмминга между кодами не менее 2N+1. Таким образом, конструируя код, мы пытаемся обеспечить расстояние Хэмминга между возможными кодовыми последовательностями больше, чем оно может возникнуть из-за ошибок. Широко распространены коды с одиночным битом четности. В этих кодах к каждым М бит добавляется 1 бит, значение которого определяется четностью (или нечетностью) суммы этих М бит. Так, например, для двухбитовых кодов 00, 01, 10, 11 кодами с контролем четности будут 000, 011, 101 и 110. Если в процессе передачи один бит будет передан неверно, четность кода из М+1 бита изменится. Предположим, что частота ошибок (BER) равна р=10-4. В этом случае вероятность передачи 8 бит с ошибкой составит 1-(1-p)8=7,9х10-4. Добавление бита четности позволяет детектировать любую ошибку в одном из переданных битах. Здесь вероятность ошибки в одном из 9 бит равна 9p(1-p)8. Вероятность же реализации необнаруженной ошибки составит 1-(1-p)9 - 9p(1-p)8 = 3,6x10-7. Таким образом, добавление бита четности уменьшает вероятность необнаруженной ошибки почти в 1000 раз. Использование одного бита четности типично для асинхронного метода передачи. В синхронных каналах чаще используется вычисление и передача битов четности как для строк, так и для столбцов передаваемого массива данных. Такая схема позволяет не только регистрировать но и исправлять ошибки в одном из битов переданного блока. Контроль по четности достаточно эффективен для выявления одиночных и множественных ошибок в условиях, когда они являются независимыми. При возникновении ошибок в кластерах бит метод контроля четности неэффективен и тогда предпочтительнее метод вычисления циклических сумм (CRC). В этом методе передаваемый кадр делится на специально подобранный образующий полином. Дополнение остатка от деления и является контрольной суммой. В Ethernet Вычисление crc производится аппаратно (см. также ethernet). На рис. 2.7.1. показан пример реализации аппаратного расчета CRC для образующего полинома B(x)= 1 + x2 + x3 +x5 + x7. В этой схеме входной код приходит слева. Рис. 2.7.1. Схема реализации расчета CRC Эффективность CRC для обнаружения ошибок на многие порядки выше простого контроля четности. В настоящее время стандартизовано несколько типов образующих полиномов. Для оценочных целей можно считать, что вероятность невыявления ошибки в случае использования CRC, если ошибка на самом деле имеет место, равна (1/2)r, где r - степень образующего полинома.
|
||||||
|
Previous:
2.6.5 Статический алгоритм Хафмана
UP:
2.6 Методы сжатия информации
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.8 Коррекция ошибок
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Исправлять ошибки труднее, чем их детектировать или предотвращать. Процедура коррекции ошибок предполагает два совмещенные процесса: обнаружение ошибки и определение места (идентификация сообщения и позиции в сообщении). После решения этих двух задач, исправление тривиально - надо инвертировать значение ошибочного бита. В наземных каналах связи, где вероятность ошибки невелика, обычно используется метод детектирования ошибок и повторной пересылки фрагмента, содержащего дефект. Для спутниковых каналов с типичными для них большими задержками системы коррекции ошибок становятся привлекательными. Здесь используют коды Хэмминга или коды свертки. Код Хэмминга представляет собой блочный код, который позволяет выявить и исправить ошибочно переданный бит в пределах переданного блока. Обычно код Хэмминга характеризуется двумя целыми числами, например, (11,7) используемый при передаче 7-битных ASCII-кодов. Такая запись говорит, что при передаче 7-битного кода используется 4 контрольных бита (7+4=11). При этом предполагается, что имела место ошибка в одном бите и что ошибка в двух или более битах существенно менее вероятна. С учетом этого исправление ошибки осуществляется с определенной вероятностью. Например, пусть возможны следующие правильные коды (все они, кроме первого и последнего, отстоят друг от друга на расстояние 4): 00000000 При получении кода 00000111 не трудно предположить, что правильное значение полученного кода равно 00001111. Другие коды отстоят от полученного на большее расстояние Хэмминга. Рассмотрим пример передачи кода буквы s = 0x073 = 1110011 с использованием кода Хэмминга (11,7).
Символами * помечены четыре позиции, где должны размещаться контрольные биты. Эти позиции определяются целой степенью 2 (1, 2, 4, 8 и т.д.). Контрольная сумма формируется путем выполнения операции XOR (исключающее ИЛИ) над кодами позиций ненулевых битов. В данном случае это 11, 10, 9, 5 и 3. Вычислим контрольную сумму:
Таким образом, приемник получит код:
Просуммируем снова коды позиций ненулевых битов и получим нуль.
Ну а теперь рассмотрим два случая ошибок в одном из битов посылки, например, в бите 7 (1 вместо 0) и в бите 5 (0 вместо 1). Просуммируем коды позиций ненулевых бит еще раз.
В обоих случаях контрольная сумма равна позиции бита, переданного с ошибкой. Теперь для исправления ошибки достаточно инвертировать бит, номер которого указан в контрольной сумме. Понятно, что если ошибка произойдет при передаче более чем одного бита, код Хэмминга при данной избыточности окажется бесполезен. В общем случае код имеет N=M+C бит и предполагается, что не более чем один бит в коде может иметь ошибку. Тогда возможно N+1 состояние кода (правильное состояние и n ошибочных). Пусть М=4, а N=7, тогда слово-сообщение будет иметь вид: M4, M3, M2, C3, M1, C2, C1. Теперь попытаемся вычислить значения С1, С2, С3. Для этого используются уравнения, где все операции представляют собой сложение по модулю 2: С1 = М1 + М2 + М4 Для определения того, доставлено ли сообщение без ошибок, вычисляем следующие выражения (сложение по модулю 2): С11 = С1 + М4 + М2 + М1 Результат вычисления интерпретируется следующим образом.
Описанная схема легко переносится на любое число n и М. Число возможных кодовых комбинаций М помехоустойчивого кода делится на n классов, где N - число разрешенных кодов. Разделение на классы осуществляется так, чтобы в каждый класс вошел один разрешенный код и ближайшие к нему (по расстоянию Хэмминга) запрещенные коды. В процессе приема данных определяется, к какому классу принадлежит пришедший код. Если код принят с ошибкой, он заменяется ближайшим разрешенным кодом. При этом предполагается, что кратность ошибки не более qm. Можно доказать, что для исправления ошибок с кратностью не более qmm (как правило, оно выбирается равным D = 2qm +1). В теории кодирования существуют следующие оценки максимального числа N n-разрядных кодов с расстоянием D.
В случае кода Хэмминга первые k разрядов используются в качестве информационных, причем k= n - log(n+1), откуда следует (логарифм по основанию 2), что k может принимать значения 0, 1, 4, 11, 26, 57 и т.д., это и определяет соответствующие коды Хэмминга (3,1); (7,4); (15,11); (31,26); (63,57) и т.д. Циклические коды Обобщением кодов Хэмминга являются циклические коды BCH (Bose-Chadhuri-Hocquenghem). Это коды с широким выбором длины и возможностей исправления ошибок. Циклические коды характеризуются полиномом g(x) степени n-k, g(x) = 1 + g1x + g2x2 + . + xn-k. g(x) называется порождающим многочленом циклического кода. Если многочлен g(x) n-k и является делителем многочлена xn + 1, то код C(g(x)) является линейным циклическим (n,k)-кодом. Число циклических n-разрядных кодов равно числу делителей многочлена xn + 1. При кодировании слова все кодовые слова кратны g(x). g(x) определяется на основе сомножителей полинома xn +1 как: xn +1 = g(x)h(x) Например, если n=7 (x7+1), его сомножители (1 + x + x3)(1 + x + x2 + x4), а g(x) = 1+x + x3. Чтобы представить сообщение h(x) в виде циклического кода, в котором можно указать постоянные места проверочных и информационных символов, нужно разделить многочлен xn-kh(x) на g(x) и прибавить остаток от деления к многочлену xn-kh(x). См. Л.Ф. Куликовский и В.В. Мотов, "Теоретические основы информационных процессов". Москва "Высшая школа" 1987. Привлекательность циклических кодов заключается в простоте аппаратной реализации с использованием сдвиговых регистров. Пусть общее число бит в блоке равно N, из них полезную информацию несут в себе K бит, тогда в случае ошибки, имеется возможность исправить m бит. Таблица 2.8.1 содержит зависимость m от N и K для кодов ВСН. Таблица 2.8.1
Увеличивая разность N-M, можно не только нарастить число исправляемых бит m, но открыть возможность обнаружить множественные ошибки. В таблице 2.8.2 приведен процент обнаруживаемых множественных ошибок в зависимости от M и N-M. Таблица 2.8.2
Другой блочный метод предполагает "продольное и поперечное" контрольное суммирование предаваемого блока. Блок при этом представляется в виде N строк и M столбцов. Вычисляется биты четности для всех строк и всех столбцов, в результате получается два кода, соответственно длиной N и M бит. На принимающей стороне биты четности для строк и столбцов вычисляются повторно и сравниваются с присланными. При выявлении отличия в бите i кода битов четности строк и бите j - кода столбцов, позиция неверного бита оказывается определенной (i,j). Понятно, что если выявится два и более неверных битов в контрольных кодах строк и столбцов, задача коррекции становится неразрешимой. Уязвим этот метод и для двойных ошибок, когда сбой был, а контрольные коды остались корректными. Применение кодов свертки позволяют уменьшить вероятность ошибок при обмене, даже если число ошибок при передаче блока данных больше 1. Линейные блочные коды Блочный код определяется, как набор возможных кодов, который получается из последовательности бит, составляющих сообщение. Например, если мы имеем К бит, то имеется 2К возможных сообщений и такое же число кодов, которые могут быть получены из этих сообщений. Набор этих кодов представляет собой блочный код. Линейные коды получаются в результате перемножения сообщения М на порождающую матрицу G[IA]. Каждой порождающей матрице ставится в соответствие матрица проверки четности (n-k)*n. Эта матрица позволяет исправлять ошибки в полученных сообщениях путем вычисления синдрома. Матрица проверки четности находится из матрицы идентичности i и транспонированной матрицы А. G[IA] ==> H[ATI].
Если Синдром полученного сообщения равен S = [полученное сообщение] . [матрица проверки четности]. Если синдром содержит нули, ошибок нет, в противном случае сообщение доставлено с ошибкой. Если сообщение М соответствует М=2k, а k =3 высота матрицы, то можно записать восемь кодов:
Кодовые векторы для этих сообщений приведены во второй колонке. На основе этой информации генерируется таблица 2.8.3, которая называется стандартным массивом. Стандартный массив использует кодовые слова и добавляет к ним биты ошибок, чтобы получить неверные кодовые слова. Таблица 2.8.3. Стандартный массив для кодов (6,3)
Предположим, что верхняя строка таблицы содержит истинные значения переданных кодов. Из таблицы 2.8.3 видно, что, если ошибки случаются в позициях, соответствующих битам кодов из левой колонки, можно определить истинное значение полученного кода. Для этого достаточно полученный код сложить с кодом в левой колонке посредством операции XOR. Синдром равен произведению левой колонки (CL "coset leader") стандартного массива на транспонированную матрицу контроля четности HT.
Чтобы преобразовать полученный код в правильный, нужно умножить полученный код на транспонированную матрицу проверки четности, с тем чтобы получить синдром. Полученное значение левой колонки стандартного массива добавляется (XOR!) к полученному коду, чтобы получить его истинное значение. Например, если мы получили 001100, умножаем этот код на HT:
этот результат указывает на место ошибки, истинное значение кода получается в результате операции XOR:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
2.7 Обнаружение ошибок
UP:
2.6 Методы сжатия информации
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.9.1 Используемые стандарты
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Для видеоконференций стандартизованы следующие скорости обмена: 112 Кбит/с (64 видео, 48 аудио); G.711 CCITT рекомендация для импульсно-кодовой модуляции (PCM) голоса с использованием m-закона кодирования при 8 кГц (8000 стробирований в сек) G.721 CCITT рекомендация для адаптивной дифференциальной импульсно-кодовой модуляции (ADPCM) для кодирования звука с полосой 32 кГц. G.722 CCITT рекомендация для ADPCM при 64 Кбит/с (7 кГц) G.723 CCITT рекомендация для ADPCM при 24 Кбит/с G.728 (CLEP) CCITT рекомендация для ADPCM при 16 Кбит/с (3.1 кГц) H.221 CCITT рекомендация для структуры кадров аудио-видео каналов при скоростях 64 - 1920 Кбит/с. H.261 или P*64- CCITT рекомендация для кодирования/декодирования аудио-видео процедур при скоростях p x 64 Кбит/с, где p=1-30, что эквивалентно 64 Кбит/с - 2 Мбит/с. Рекомендации первоначально были разработаны для узкополосного ISDN. Достижимы коэффициенты сжатия от 4:1 до 160:1. Регламентированы форматы: CIF 352x288 15 кадров/сек. H.320 CCITT рекомендации для узкополосных видео-телефонных систем и терминального оборудования со скоростями не более 1920 Кбит/с. Общее описание CODEC. JPEG - ISO/CCITT рекомендации объединенной группы фотоэкспертов. В рекомендации определен алгоритм сжатия для стационарных цветных изображений, при котором отбрасываются визуально второстепенные детали изображения, убирается избыточность в пределах кадра, в результате обеспечивается сжатие1:30 при потере качества изображения и 1:15 без потери качества. JPEG для движущегося изображения - стандарт JPEG, адаптированный для отображения движущегося изображения, обеспечивает индивидуальный доступ к кадрам и коэффициент сжатия информации 20:1. MPEG-1 ISO/CCITT рекомендации группы экспертов по движущемуся изображению, определен алгоритм сжатия для движущегося изображения при работе с каналами 1.5 Мбит/с (1.2 Мбит/с видео + 200 Кбит/с для аудио) с коэффициентами сжатия от 50:1 до 200:1 при размере изображения 352x240x24 бит и частоте кадров 30/сек. MPEG-2 ISO/CCITT рекомендации группы экспертов по движущемуся изображению, поток данных для видео и аудио лежит в пределах между 4 и 15 Мбит/с, достигаются коэффициенты сжатия от 50:1 до 200:1, размер изображения 728x486, качество соответствует телевидению высокого разрешения стандарта NTSC (National Television Standards Committee US). Сводные данные по стандартам для видеоконференций представлены в таблице 2.9.1.1. Новым универсальным набором стандартов для реализации видео-телефонии и мультимедийных обменов является H.323. Таблица 2.9.1.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
2.9 Видеоконференции по каналам Интернет и ISDN
UP:
2.6 Методы сжатия информации
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.9 Видеоконференции по каналам Интернет и ISDN
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Расширение международных контактов и реализация проектов с "удаленными" отечественными партнерами делает актуальной проблему экономии командировочных расходов особенно в случае коротких поездок (1-7 дней). Одним из средств решения проблемы является использование видеоконференций. Видеоконференции по каналам Интернет могут быть привлекательны для дистанционного обучения и медицинской диагностики. В отличие от телевизионных программ обучение с использованием Интернет предполагает диалог между преподавателем и обучаемым, что делает процесс более эффективным (эта техника может успешно дополнить WWW-методику, широко используемую в университетах США и Европы). Медицинские приложения еще более многообещающи. Видеоконференции позволят проконсультироваться в клинике, отстоящей на тысячи километров, устроить консилиум с участием врачей из разных городов, оперативно передать томограмму или многоканальную кардиограмму пациента с целью ее интерпретации и т.д. В более отдаленной перспективе технология видеоконференций может быть применена для целей телевидения.
Рис. 2.9.1. Оборудование, необходимое для видеоконференций Для проведения видеоконференции необходимо иметь цифровой канал с пропускной способностью не менее 56-128кбит/с. Если канал не позволяет, можно ограничиться аудио телеконференцией (см. раздел IP-phone). Схеме оборудования, необходимого для видеоконференции показано на рис. 2.9.1. Помимо стандартного оборудования рабочей станции (как правило, под ОС UNIX) требуется интерфейс для подключения видеокамеры и микрофонов. Этот интерфейс обычно снабжается аппаратной схемой сжатия видео и аудио данных. Многие современные мультимедиа интерфейсы снабжены входами для видеокамеры. Из обязательного оборудования на рис. 2.9.1 не показаны наушники и звуковые колонки. Полезным дополнением может служить сканнер, который позволит с высоким разрешением передать изображения документов или чертежей, видеомагнитофон, а также видео проектор для отображений принятого изображения на экране или телевизор с большим экраном. Видеоконференции обеспечивают не только "живое" общение партнеров, но также оперативное обсуждение и редактирование чертежей и документов. При этом разрешающая способность может превышать в 10-100 раз ту, которая доступна для факсов. Реализовать видеоконференцию можно разными путями, из них два наиболее реальны:
При видеоконференциях используется технология codec (coder/decoder) для выделенных и телефонных коммутируемых линий (>56 Кбит/с, интерфейс V35), применим и режим коммутации пакетов (multicast backbone, >256 Кбит/с). Перечень стандартов, регламентирующих протоколы видеоконференций можно найти в следующем разделе (2.9.1). Но базовым протоколом для работы в локальных сетях, где не гарантируется нужный уровень qos), является h.323 (1996-98 гг.; вторая дата относится к принятию версии 2). Этот стандарт обеспечивает видеоконференции для соединений точка-точка и для многоточечных топологий в рамках стека протоколов tcp/ip, он регламентирует и принципы сжатия видео и аудио информации. Привлекательность стандарта заключается в том, что он применим к уже существующей инфраструктуре телекоммуникаций с широкими вариациями задержек отклика. Способствует этому возрастающая пропускная способность локальных (fast ethernet и gigabit ethernet) и региональных сетей (SDH, ATM, FDDI, Fibre Channel и т.д.). Способствуют этому как новейшие протоколы из семейства IP - RTP и RSVP, так и поддержка H.323 такими компаниями как Intel, Microsoft, Cisco и IBM. H.323 не привязан ни к одной операционной системе и не предполагает использования какого-либо специализированного оборудования. На рис. 2.9.2 показана структура системы H.323 и основных ее компонентов.
Рис. 2.9.2. Структура системы H.323 и основных ее компонентов H.323 определяет четыре главных составляющих коммуникационной системы:
Терминалы служат для предоставления пользователям определенных услуг и обеспечивают двухсторонний обмен данными в реальном масштабе времени. Все терминалы H.323 должны также поддерживать стандарт H.245, который служит для выбора параметров канала. Структура терминала показана на рис. 2.9.3.
Рис. 2.9.3. Структура терминала H.323 Интерфейс RAS (registration/admission/status) служит для взаимодействия с блоком доступа (gatekeeper) и поддерживает протоколы RTP/RTCP. Опционными частями H.323 являются видео кодеки, протоколы для проведения информационных конференций (T.120) и возможности поддержания многоточечной связи (mcu). Внешний шлюз также является опционным элементом конференций H.323. Шлюз может выполнять функции интерфейса для согласования с требованиями других форматов, например, H.225 - H.221 или других коммуникационных процедур, например, H.245 - H.242. Типичным шлюзом можно считать соединитель H.323 с коммутируемой телефонной сетью (GSTN). Блок схема такого шлюза показана на рис. 2.9.4. Данный шлюз устанавливает аналоговую связь с терминалами GSTN, с терминалами H.320 по каналам ISDN и с терминалами H.324 по сети GSTN. Терминалы взаимодействуют со шлюзом через протоколы H.245 и Q.931. Применяя соответствующую перекодировку, можно обеспечить работу шлюза H.323 с терминалами, поддерживающими протоколы V.70, H.322, H.310 и H.321. Многие функции шлюза не стандартизованы, к их числу, например, относится нумерация подключенных терминалов.
Рис. 2.9.4. Схема шлюза IP/GSTN Узел управления доступом (gatekeeper) является центральным блоком сети H.323. Через него проходят все запросы обслуживания, при этом он выполняет функцию виртуального переключателя. Узел управления доступом осуществляет преобразование имен терминалов и шлюзов в их IP и IPX-адреса в соответствии со спецификацией RAS. Например, если администратор сети установил верхний предел на число участников конференции, при достижении этого порога узел управления доступом может отказать в установлении соединения. Совокупность терминалов, шлюзов и блоков MTU, управляемая общим блоком доступа, называется зоной H.323. Узел управления доступом может опционно маршрутизовать запросы H.323. Разработчики иногда совмещают функции шлюза, MCU и узла управления доступом, возможно независимое совмещение функций MCU и узла управления доступом. К числу обязательных функций узла управления доступом относится.
Определены некоторые опционные функции узла управления доступом:
Для организации конференций с числом участников три и более используется блок многоточечного доступа (MCU). MCU включает в себя многоточечный контроллер (MC) и многоточечный процессор (MP). MC осуществляет согласование рабочих параметров терминалов для обеспечения совместимости при передаче видео и аудио информации в рамках протокола H.245. Многоточечный контроллер управляет также ресурсами каналов, при этом поддерживается как уникастный, так и мультикастный обмен. Все терминалы посылают аудио, видео и данные MCU в режиме соединения точка-точка. Управляющая канальная информация H.245 передается непосредственно в MC. MP может выполнять перекодировку в случае использования кодеков различного типа. Конференция может быть организована в централизованном (все обмены идут через MCU) и децентрализованном режиме, когда терминалы непосредственно взаимодействуют друг с другом. Терминалы используют протокол H.245, для того чтобы сообщить MC, сколько видео- и аудио- потоков они могут обработать одновременно. MP может осуществлять отбор видеосигналов и смешение аудио-каналов при децентрализованной многоточечной конференции. Допускается и смешенный режим, когда одновременно реализуется централизованная и децентрализованная схема обменов. Новейшая версия H.323 (v2) за счет аутентификации и шифрования/дешифрования обеспечивает безопасность и конфиденциальность (перехват в промежуточных узлах становится невозможным). Более подробно возможности версии 2 изложены в документе http://www.databeam.com/h323/ . Звуковой сигнал передается в оцифрованной и сжатой форме. Алгоритмы компрессии, поддерживаемые H.323, соответствуют требованиям стандартов ITU. Терминалы H.323 должны быть способны работать со стандартом компрессии голоса G.711 (56 или 64 Кбит/c). Голосовой кодек должен следовать рекомендациям G.723, а видео кодек должен соответствовать стандарту H.261 (поддержка H.263 является опционной, этот стандарт обеспечивает более высокое качество изображения). В таблице 2.9.1 приведены форматы для видео-конференций ITU. Таблица 2.9.1
Видеоконференции реализуемы на ЭВМ IBM/PC [1,2], Mackintosh, SUN, HP, DEC. Пакетная техника обеспечивает удовлетворительное качество изображения и звукового сопровождения при низкой загрузке канала и малой вероятности ошибок при передаче пакетов. Достижимое сжатие видеосигнала - 1000:1, звукового 8:1. Например, система SPARC classic M позволяет передавать по сети Ethernet до 30 кадров в секунду при разрешении 768x576 точек (PAL). Рассмотренное оборудование может использоваться не только для "дальней" связи, но для коллективного редактирования документов и чертежей в пределах одного предприятия, используя локальную сеть. Это может найти применение при реализации систем САПР больших предприятий. Для компрессии применяются методы CellB, JFPEG, MPEG1, Capture (YUV, RGB-8). Наиболее популярные программные продукты для телеконференций: vic, vat, nv, wb, sd, ivs. (см. http://www.anl.gov/linda/video.html .) Такие программные средства как VAT (Visual Audio Tool, ftp.ee.lbl.gov ), nevot (network voice terminal, gaia.cs.umass.edu:/pub/hgschulz/nevot), VIC (Video Conference), IVS (INTRA Videoconferencing System, avahi.inria.fr:/pub/videoconference), NV (Net Video, beta.xerox.com:/pub/net-research) или wb (whiteboard, ftp.ee.lbl.gov) базируются на утилитах X11, они позволяют пользователю осуществить связь ЭВМ-ЭВМ или сессии с большим числом участников по каналам Интернет. Поддерживаются следующие схемы кодирования и передачи данных: PCM (64 Кбит/с), DVI, GSM и LPC (8 Кбит/с). В wb имеется возможность импорта файлов Postscript (обычно используемых для прозрачек). При этом достигается разрешение 640*512, число цветов равно 256, число кадров 2-20, коэффициент сжатия информации ~20:1, а требуемая полоса пропускания канала >128 Кбит/с. Эти параметры не идеальны. Желательно вдвое большее разрешение, число цветов должно быть равно 16 миллионам, а частота кадров 25-50, но это требует существенно большей пропускной способности каналов (> 2 Мбит/с). Но прогресс в области быстродействия каналов связи столь стремителен.... Система mmcc (Multimedia Conference Control program, ftp.isi.edu:confctrl/mmcc.tar.Z) во многом аналогична описанным выше, она позволяет клиенту осуществить вызов нужного партнера. Весьма полезной утилитой является SD (Session Directory, ftp.ee.lbl.gov:sd.tar.Z ), которая может запускать приложения, необходимые для проведения видео конференций. Пакет CUSeeMe (gated.cornell.edu:/pub/video/Mac.CU-SeeMe0.60b1) предназначен для персонального общения через Интернет, он работает на IBM/PC и MAC, требует 4 Мбайт оперативной памяти. Один кадр передается за 6-7 сек при полосе 28,8 Кбит/с, разрешение 320*240 пикселей. Такое качество соответствует скорее видео телефону. На экране предусмотрена область прокрутки, где можно напечатать какой-либо текст. Этим список доступных программных продуктов не исчерпывается. Приведенные здесь краткие описания даны лишь в качестве примеров. Подчеркну, что качество работы сети более критично для передачи звука, чем изображения, ведь потеря нескольких кадров подчас совсем незаметна. Потеря же пакетов при передаче звука более заметна, особенно при диалоге. Когда же используется сжатие, любые повреждения пакетов приводят к потере целых блоков данных. Для экспериментов с передачей звука и изображения группой IETF (Internet Engineering Task Force) была сформирована структура мультикастинг-сети MBONE. MBONE (Multicast Backbone, до 300 Кбит/с) представляет собой виртуальную сеть, построенную из уникаст-туннелей, которые функционируют поверх Интернет. MBONE составляет около 3,5% от всего Интернет. Рабочие станции для доступа к MBONE должны поддерживать IP-мультикастинг (см. RFC-1112 "Host Extensions for IP Multicasting"). Следует иметь в виду, что не все маршрутизаторы поддерживают мультикастинг. При работе с MBONE отправитель не должен знать, кто является получателем, а требуемая пропускная способность канала не зависит от того, обслуживается один клиент или 100. Требуемая полоса канала для видеоконференций определяется необходимой разрешающей способностью и частотой кадров. Таблица требований к каналу для передачи изображения представлена ниже.
В таблице приведены требования на пропускную способность канала при использовании различных степеней сжатия передаваемых видеоданных для частоты кадров 30/с и 24 бит на пиксель для отображения цвета.
Требования при передаче звука определяются необходимым качеством, так для получения полосы 6 Кгц нужно 64 Кбит/с, а для уровня, сопоставимого с CD, - 1,4 Мбит/с. Применение сжатия информации позволяет снизить эти требования в 4-8 раз. Общепринятыми стандартами для сжатия изображения при видеоконференциях являются JPEG, MPEG, H.261. Обычно они реализуются программно, но есть и аппаратные реализации. Если сегодня базовым транспортным протоколом для мультимедиа является UDP, то в самое ближайшее время его потеснит RTR и дополнят RSVP и ST-II, что заметно повысит качество и надежность (см. также раздел IP-phone). Набор стеков протоколов, которые могут использоваться для реализации видео конференций в рамках стандартов ITU (транспортный протокол H.320):
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
2.8 Коррекция ошибок
UP:
2.6 Методы сжатия информации
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2 Преобразование, кодировка и передача информации
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Для передачи информации на большие расстояния в настоящее время используются исключительно электромагнитные волны (акустические волны пригодны лишь для ограниченных расстояний). При этом пересылка может осуществляться по медным проводам, оптоволоконному кабелю или непосредственно, по схеме передатчик-приемник. В последнем случае используются антенны. Для того чтобы антенна была эффективна, ее размеры должны быть сравнимы с длиной передаваемой волны. Чем шире динамический диапазон передаваемых частот, тем труднее сделать антенну, пригодную для решения этой задачи. Именно по этой причине для передачи используются частоты, начиная с многих сотен килогерц и выше (длина волн сотни метров и меньше). Передача сигнала непосредственно по лучу лазера ограничена расстояниями 100-3000м и становится неустойчивой при наличии осадков даже для инфракрасных длин волн. Между тем человек воспринимает акустические колебания в диапазоне 20-12000 Гц и для целей пересылки звука (например, телефония) требуется именно этот диапазон частот. Динамический диапазон частот в этом случае равен 600, а для высококачественного воспроизведения звука он в два раза шире. При решении этой проблемы используется преобразование частот и различные методы модуляции. Так тот же частотный диапазон, лежащий в пределах (100 - 100,012) Мгц, соответствует динамическому диапазону 0,012%, что позволяет сделать компактную антенну и упростить частотное выделение сигнала. Для преобразования частот используется перемножение сигналов. Пусть мы имеем два синусоидальных сигнала: A 1*sin(w1 t) и A 2*sin( w2 t). Из тригонометрии известно, что: A1*sin( w1 t)*A2*sin( w2 t)=1/2*A1*A2*[sin( w1+w2)t + sin( w1-w2)t]. [1.1] Это означает, что в результате перемножения вместо двух частот f 1=w1/2p и f 2= w2/2p мы имеем две новые частоты (w1+w2)/2p и (w1-w2)/2p с амплитудой 1/2*A 1*A2. Если входной сигнал имеет полосу 0 - fм, то после перемножения с сигналом, имеющим частоту fн (несущая частота), получим сигнал с полосой в интервале от (fн - fм) до (fн+ fм). Это преобразование проиллюстрировано на рис. 2.1. (по вертикальной оси отложена спектральная плотность сигнала f(jw )). На практике это преобразование выполняется с помощью смесителей или гетеродинов, частота fн называется сигналом гетеродина или несущей.
Рис. 2.1. Частотное преобразование Получение исходного сигнала из преобразованного достигается путем обратного преобразования, которое сводится к умножению полученного сигнала на sin(w нt), где w н = 2 p*fн. При таком обратном преобразовании мы получим сигнал с исходным частотным диапазоном. Помимо этого будет получен сигнал с полосой от (2fн - fм) до (2fн+ fм). Так как fн обычно много больше fм, серьезных проблем это не вызывает - достаточно воспользоваться соответствующим фильтром. Этому методу обратного преобразования присущи некоторые недостатки. Если сигнал fн имеет фазовый сдвиг q по отношению к тому, что имел сигнал, использованный при прямом преобразовании, то амплитуда выходного сигнала будет пропорциональна cosq. Понятно, что при вариации фазы амплитуда будет меняться, а при q=p/2 станет нулевой. По этой причине должны быть предприняты специальные меры для синхронизации этих сигналов (fн. передатчика и fн приемника). Соотношение [1.1] используется при реализации амплитудной, частотной или фазовой модуляции. Так в случае амплитудной модуляции при временной вариации A1 (=Авх) будет изменяться и амплитуда выходного сигнала (А2=Aн - амплитуда несущей частоты при этом остается постоянной; w1=w н при этом может также варьироваться). Форма сигнала на выходе такого преобразователя имеет вид: Авых = Ан[1+Авх(t)] sin w нt. Для получения формы исходного сигнала на принимающей стороне используется схема детектора (например, диодного), на выходе которого получается сигнал, пропорциональный модулю огибающей функции входного сигнала. Существуют и другие методы демодуляции амплитудно-модулированного сигнала. Главным недостатком метода амплитудной модуляции является возможность нелинейных искажений из-за перемодуляции (когда амплитуда модулирующего сигнала слишком велика). При частотной и фазовой модуляции амплитуда передаваемого сигнала остается почти постоянной, что исключает нелинейные искажения, связанные с широким динамическим амплитудным диапазоном. Выходной сигнал для этого вида модуляции имеет вид: Авых = Ан sin[w нt + q(t)], где q(t) зависит от формы преобразуемого входного сигнала. Часто используется комбинация амплитудной и фазовой модуляции, которая носит название квадратурной модуляции. Системы передачи данных с амплитудной или частотной модуляцией являются аналоговыми системами и по этой причине весьма чувствительны к шумам на входе приемника. Применение цифровых методов пересылки информации увеличивает вероятность корректной доставки. Если для аналоговой передачи требуется отношение сигнал/шум на уровне 40-60 дБ, то при цифровой передаче достаточно 10-12 дБ. Выбор типа модуляции зависит от стоящей задачи и от характеристик канала (полосы пропускания, ослабления сигнала и т.д.). Частотная модуляция менее чувствительна к амплитудным флуктуациям сигнала. Ослабление сигнала может варьироваться во времени из-за изменений в транспортной среде, это довольно типично для коммутируемых телефонных сетей. В сетях, использующих выделенные каналы, это также возможно благодаря применению динамических протоколов маршрутизации, когда длина пути может изменяться в пределах одного сеанса связи. В любом случае на передающей стороне необходим модулятор, а на принимающей демодулятор. Так как обмен обычно двунаправлен, эти устройства объединяются в одном приборе, который называется модемом (см. также раздел "4.3.7. Модемы"). В модемах применимы несколько видов модуляции:
В QAM-модуляции используется 8/16 комбинаций амплитуда-фаза (см. рис. 2.2). Понятно, что такой тип модуляции более уязвим для шумов.
Рис. 2.2. QAM-модуляция с 3 битами на бод (слева) и 4 битами на бод (справа) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
1 Введение (общие принципы построения сетей)
UP:
1 Введение (общие принципы построения сетей)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
3.2 Оптоволоконные каналы
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
А.Г.Белл в 1880 году запатентовал фотофон - прибор для передачи голоса посредством светового сигнала с селеновым фотодетектором. Первые коммерческие телефонные системы были созданы лишь в 1977 году и работали со скоростью 44,7 Мбит/с. Одномодовые волоконные кабели начали производиться в 1983 году. В 1990 году Линн Моллинер (Bellcore) продемонстрировал передачу данных со скоростью 2,5Гбит/c на расстояние 7500 км (без промежуточных усилителей сигнала) В 1990 году в США суммарная протяженность оптических волокон составляла около 9000000 км. В 2000 году обшая длина оптоволокон только в США превысила 30 миллионов километров. Оптоволоконные линии связи работают в частотном диапазоне 1013 - 1016Гц, что на 6 порядков больше, чем в случае радиочастотных каналов (это обеспечивает пропускную способность 50000 Гбит/c). Но земная атмосфера является плохой средой для распространения света. По этой причине только разработка кремниевых волокон с низким коэффициентом поглощения в инфракрасном диапазоне (< 0,2 дБ/км) сделало возможным широкое распространение оптических каналов связи. Укладывается ~1000км оптоволоконного кабеля в день. В настоящее время каналы обычно имеют пропускную способность ~1Гбит/c и это связано с ограниченным быстродействием оборудования, преобразующего оптический сигнал в электрический и обратно. В ближайшие годы следует ожидать увеличения быстродействия таких устройств в 100-1000 раз. Учитывая, что df = (cdl)/l 2, где с - скорость света, f - частота, а l - длина волны. Для наиболее популярного диапазона l = 1,3m и dl = 0,17m мы имеем df = ~30ТГц. В 2002 году компанией Zonu разработан фототрансивер (GBIC) на 1,25Гбит/c для передачи и приема данных по одному и тому же волокну при длине волны 1310 нм. Для одномодового волокна расстояние передачи может составлять до 10 км. При длине волны 1550 нм достижимо расстояние передачи в 40 км. Разрабатывается вариант для скоростей передачи 2,5Гбит/c Оптоволоконное соединение гарантирует минимум шумов и высокую безопасность (практически почти невозможно сделать отвод). Пластиковые волокна применимы при длинах соединений не более 100 метров и при ограниченном быстродействии (<50 МГц). Вероятность ошибки при передаче по оптическому волокну составляет <10-10, что во многих случаях делает ненужным контроль целостности сообщений. При построении сетей используются многожильные кабели (рис. 3.2.1; существуют и другие разновидности кабеля: например, двух- или четырехжильные, а также плоские). В верхней части рисунка [a] изображено отдельное оптоволокно, а в нижней [Б] сечение восьмижильного оптического кабеля. Свет (длина волны l ~ 1350 или 1500 нм) вводится в оптоволокно (диаметром d<100m) с помощью светоизлучающего диода или полупроводникового лазера. Центральное волокно покрывается слоем (клэдинг, 1А), коэффициент преломления которого меньше чем у центрального ядра (стрелками условно показан ход лучей света в волокне). Для обеспечения механической прочности извне волокно покрывается полимерным слоем (2А). Кабель может содержать много волокон, например 8 (1Б). В центре кабеля помещается стальной трос (3Б), который используется при прокладке кабеля. С внешней стороны кабель защищается (от крыс!) стальной оплеткой (2Б) и герметизируется эластичным полимерным покрытием.
Рис. 3.2.1. Сечение оптоволоконного кабеля Существует несколько типов оптических волокон, обладающих различными свойствами. Они отличаются друг от друга зависимостью коэффициента преломления от радиуса центрального волокна. На рис. 3.2.2 показаны три разновидности волокна (А, Б и В). Буквами А и Б помечен мультимодовый вид волокон. Тип Б имеет меньшую дисперсию времени распространения и по этой причине вносит меньшие искажения формы сигнала. Установлено, что, придавая световым импульсам определенную форму (обратный гиперболический косинус), дисперсионные эффекты можно полностью исключить. При этом появляется возможность передавать импульсы на расстояние в тысячи километров без искажения их формы. Такие импульсы называются солитонами. При современных же технологиях необходимо использовать повторители через каждые 30 км (против 5 км для медных проводов). По сравнению с медными проводами оптоволоконные кабели несравненно легче. Так одна тысяча скрученных пар при длине 1 км весит 8 тонн, а два волокна той же длины, обладающие большей пропускной способностью, имеют вес 100кг. Это обстоятельство открывает возможность укладки оптических кабелей вдоль высоковольтных линий связи, подвешивая или обвивая их вокруг проводников.
Буквой В помечен одномодовый вид волокна (понятие мода связано с характером распространения электромагнитных волн). Мода представляет собой одно из возможных решений уравнения Максвелла. В упрощенном виде можно считать, что мода - это одна из возможных траекторий, по которой может распространяться свет в волокне. Чем больше мод, тем больше дисперсионное искажение сформы сигнала. Одномодовое волокно позволяет получить полосу пропускания в диапазоне 50-100 ГГц-км. Типовое значение модовой дисперсии лежит в пределах от 15 до 30 нсек/км. Эта разновидность волокна воспринимает меньшую долю света на входе, за то обеспечивает минимальное искажение сигнала и минимальные потери амплитуды. Следует также иметь в виду, что оборудование для работы с одномодовым волокном значительно дороже. Центральная часть одномодового волокна имеет диаметр 3-10 m, а диаметр клэдинга составляет 30-125 m. Число мод, допускаемых волокном, в известной мере определяет его информационную емкость. Модовая дисперсия приводит к расплыванию импульсов и их наезжанию друг на друга. Дисперсия зависит от диаметра центральной части волокна и длины волны света. Число мод n равно для волокна типа А:
где d - диаметр центральной части (ядра), a - численная апертура волокна, а
l - длина волны. Волокно с диаметром центральной части
волокна 50 m поддерживает 1000 мод. Для волокна типа
Б (рис. 3.2.2) значение n в два раза меньше. Численная апертура А равна
Очевидно, что чем больше длина волны, тем меньше число мод и меньше искажения сигнала. Это, в частности, является причиной работы в длинноволновом инфракрасном диапазоне. Но даже для одной и той же моды различные длины волн распространяются по волокну с разной скоростью. Волокно со сглаженным профилем показателя преломления имеет дисперсию 1 нсек/км и меньше. Это, в частности, связано с тем, что свет в перефирийных областях волокна с большей длиной траектории движется быстрее (там ведь меньше коэффициент преломления). Одномодовый режим реализуется тогда, когда длина волны вета становится сравнимой с диаметром ядра волокна. Длина волны, при которой волокно становится одномодовым, называется пороговой. Волокно с диаметром 50 микрон может поддерживать до 1000 мод. В отличие от многомодового волокна, в одномодовом - излучение присутствует не только внутри ядра. По этой причине повышаются требования к оптическим свойствам клэдинга. Для многомодового волокна требования к прозрачности клэдинга весьма умеренны. Затуханием обычно называется ослабление сигнала по мере его движения по волокну. Оно измеряется в децибелах на километр и варьируется от 300 дБ/км для пластиковых волокон до 0,21 дБ/км - для одномодовых волокон. Полоса пропускания волокна определяется дисперсией. Приближенно полосу пропускания одномодового волокна можно оценить согласно формуле. BW = 0,187/(Disp*SW*L), где Disp - дисперсия на рабочей длине волны в сек на нм и на км; Если диаметр источника света не соответствует диаметру ядра волокна, то потери света, связанные с геометрическим рассогласованием могут быть охарактеризованы следующей формулой. Потеридиам = 10log10(Диаметрволокна/Диаметристочника)2 Потерь нет, когда волокно имеет диаметр больше диаметра источника света. Если числовая апертура источника больше апертуры волокна, то потери света составят: Потеридиам = 10log10(Aволокна/Aисточника)2 Помимо дисперсии быстродействие оптического канала ограничивается шумами. Шумы имеют две составляющие: дробовой и тепловой шум. Дробовой шум определяется соотношением: isn 2= 2eiB, где е - заряд электрона, i - средний ток, протекающий через приемник, и В - ширина полосы пропускания приемника. Типовое значение дробового шума составляет 25 нА при температуре 25 градусов Цельсия. Тепловой шум характеризуется соотношением: isn 2=(4kTB)/RL где k - постоянная Больцмана, Т - температура по шкале Кельвина, В - ширина полосы пропускания приемника, RL - сопротивление нагрузки. При полосе в 10 МГц и температуре 298 0К эта составляющая шума равна 18 нА. Одной из составляющих теплового шума является темновой ток, который возрастает на 10% при росте температуры на 1 градус. Чувствительность приемника задается квантовой эффективностью, которая характеризует отношение числа первичных электронно-дырочных пар к числу падающих на детектор фотонов. Этот параметр часто выражается в процентах (реже в амперах на люмен). Так, если на каждые 100 фотонов приходится 60 пар электрон-дырка, то квантовая эффективность равна 60%. Чувствительность фотодетектора R может быть вычислена на основе квантовой чувствительности. R= (nel)/hc, где е - заряд электрона, h - постоянная Планка, с - скорость света l - длина волны, а n - квантовая чувствительность. Источники излучения инжектируемого в волокно имеют конечную полосу частот. Так светоизлучающие диоды излучают свет с шириной полосы 35 нм, а лазеры 2-3 нм (лазеры имеют, кроме того, более узкую диаграмму направленности, чем диоды). Характеристики светодиодов и инжекционных лазерных диодов приведены в таблице 3.2.1. Таблица 3.2.1. Характеристики светодиодов и инжекционных лазерных диодов
Время нарастания фотодиода ограничивает быстродействие системы. Не малую роль играет и уровень шумов на входе приемника. При этом световой импульс должен нести достаточно энергии (заметно больше уровня шума), чтобы обеспечить низкий уровень ошибок. В таблице 3.2.2 приведены характеристики оптических приемников. Таблица 3.2.2. Характеристики оптических приемников
Поглощение света в волокне происходит по нескольким причинам. Поглощение в собственно стекле волокна падает с частотой, в то время как потери из-за рассеяния на дефектах стекла (релеевское рассеяние) с увеличением частоты растет. При сгибании волокна поглощение увеличивается. По этой причине следует избегать малых радиусов изгиба (кроме всего прочего это может привести и к обрыву). В результате потери света в волокне обычно лежит в диапазоне (2-5) дБ/км для длин волн 0,8 - 1,8 m. Зависимость поглощения света в волокне от длины волны показана на рис. 3.2.3. Используемые диапазоны отмечены на рисунке зеленым цветом. Все эти диапазоны имеют ширину 25000-30000 ГГц.
Рис. 3.2.3. Зависимость поглощения света в волокне от длины волны Из рисунка видно, что минимумы поглощения приходятся на 1300 и ~1500 нм, что и используется для целей телекоммуникаций. При длине волны 1300 нм дисперсия скоростей распространения различных длин волн минимальна. Диапазон ~850 нм характеризуется высоким поглащением, но он привлекателен тем, что как лазеры, так и электроника могут быть изготовлены из одного материала (арсенида галлия). Используемые оптические диапазоны выделены зеленым цветом. Зависимость дисперсии от длины волны показана на рис. 3.2.4.
Рис. 3.2.4. Зависимость дисперсии от длины волны Из рисунка видно, что в области ниже 1300 нм более длинные волны движутся быстрее коротких. Для длин волн >1300нм имеет место обратная ситуация - более длинные волны движутся медленнее коротких. Для одномодовых волокон определяющий вклад в искажения вносится дисперсией скоростей распространения, для многомодовых основной вклад вносит модовая дисперсия. Зависимость полосы пропускания волокна от его длины приведена на рис. 3.2.5.
Рис. 3.2.5. Зависимость полосы пропускания волокна от его длины Типовые характеристики оптических волокон приведены в таблице 3.2.3. (См. также Дональд Дж. Стерлинг, Волоконная оптика. Техническое руководство. Изд. "ЛОРИ, Москва, 1998 а также Дж. Гауэр, Оптические системы связи. Москва, "Радио и связь", 1989) Таблица 3.2.3. Типовые характеристики оптических волокон
Одним из критических мест волоконных систем являются сростки волокон и разъемы. Учитывая диаметр центральной части волокна, нетрудно предположить, к каким последствиям приведет смещение осей стыкуемых волокон даже на несколько микрон (особенно в одномодовом варианте, где диаметр центрального ядра менее 10 микрон) или деформация формы сечения волокон. Соединители для оптических волокон имеют обычно конструкцию, показанную на рис. 3.2.6, и изготовляются из керамики. Потеря света в соединителе составляет 10-20%. Для сравнения сварка волокон приводит к потерям не более 1-2%. Существует также техника механического сращивания волокон, которая характеризуется потерями около 10% (splice). Оптические аттенюаторы для оптимального согласования динамического диапазона оптического сигнала и интервала чувствительности входного устройства представляют собой тонкие металлические шайбы, которые увеличивают зазор между волокном кабеля и приемником.
Рис. 3.2.6. Схема оптического разъема С использованием оптических волокон можно создавать не только кольцевые структуры. Возможно построение фрагмента сети, по характеру связей эквивалентного кабельному сегменту или хабу. Схема такого фрагмента сети представлена на рис. 3.2.7 (пассивный хаб-концентратор). Базовым элементом этой субсети является прозрачный цилиндр, на один из торцов которого подключаются выходные волокна всех передатчиков интерфейсов устройств, составляющих субсеть. Сигнал с другого торца через волокна поступает на вход фото приемников интерфейсов. Таким образом, сигнал, переданный одним из интерфейсов, поступает на вход всех остальных интерфейсов, подключенных к этой субсети. При этом потери света составляют 2С + S + 10*log(N), где С - потери в разъеме, S - потери в пассивном разветвителе, а N - число оптических каналов (N может достигать 64). Современные микросхемы приемо-передатчиков (корпус DIP) имеют встроенные разъемы для оптического кабеля (62,5/125мкм или 10/125 мкм). Некоторые из них (например, ODL 200 AT&T) способны осуществлять переключение на обходной оптический путь (bypass) при отключении питания.
Рис. 3.2.7. Схема пассивного оптоволоконного хаба В последнее время заметного удешевления оптических каналов удалось достичь за счет мультиплексирования с делением по длине волны. За счет этой техники удалось в 16-160 раз увеличить широколосность канала из расчета на одно волокно. Схема мультиплесирования показана на рис. 3.2.8. На входе канала сигналы с помощью призмы объединяются в одно общее волокно. На выходе с помощью аналогичной призмы эти сигналы разделяются. Число волокон на входе и выходе может достигать 32 и более (вместо призм в последнее время используются миниатюрные зеркала, где применяется 2D-развертка (или 3D)по длине волны). Разработка технологии получения особо чистого материала волокон позволила раширить полосу пропускания одномодового волокна до 100 нм (для волокон с l =1550нм). Полоса одного канала может лежать в диапазоне от 2 до 0,2 нм. Эта технология в самое ближайшее время расширит скорость передачи данных по одному волокну с 1 до 10 Тбит/с.
Рис. 3.2.8. Мультиплексирование с делением по длине волны в оптическом волокне |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
3.1 Кабельные каналы связи
UP:
3 Каналы передачи данных
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||
|
3.3 Беспроводные (радио) каналы и сети
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||
|
Применение электромагнитных волн для телекоммуникаций имеет уже столетнюю историю. Спектр используемых волн делится на ряд диапазонов, приведенных в таблице 3.3.1. Таблица 3.3.1.
Далее следуют диапазоны видимого света, ультрафиолета, рентгеновских и гамма-лучей. Диапазоны часто, используемые различными каналами связи показаны на рис. 3.3.1. Рис. 3.3.1. Диапазоны частот различных телекоммуникационных каналов. Если не используется направленная антенна и на пути нет препятствий, радиоволны распространяются по всем направлениям равномерно и сигнал падает пропорционально квадрату расстояния между передатчиком и приемником (удвоение расстояния приводит к потерям 6дБ). Радио каналы для целей передачи информации используют частотные диапазоны 902-928 МГц (расстояния до 10 км, пропускная способность до 64кбит/с), 2,4 ГГц и 12 ГГц (до 50 км, до 8 Мбит/с). Они используются там, где не существует кабельных или оптоволоконных каналов или их создание по каким-то причинам невозможно или слишком дорого. Более низкие частоты (например, 300 МГц) мало привлекательны из-за ограничений пропускной способности, а большие частоты (>30 ГГц) работоспособны для расстояний не более или порядка 5км из-за поглощения радиоволн в атмосфере. При использовании диапазонов 4, 5 и 6 следует иметь в виду, что любые препятствия на пути волн приведут к их практически полному поглощению. Для этих диапазонов заметное влияние оказывает и поглощение в атмосфере. Зависимость поглощения от длины волны радиоволн показана на рис. 3.3.1а.
Рис. 3.3.1а. Зависимость поглощающей способности земной атмосферы от длины волны Из рисунка видно, что заметную роль в поглощении радиоволн играет вода. По этой причине сильный дождь, град или снег могут привести к прерыванию связи. Поглощение в атмосфере ограничивает использование частот более 30 ГГц. Атмосферные шумы, связанные в основном с грозовыми разрядами, доминируют при низких частотах вплоть до 2 МГц. Галактический шум, приходящий из-за пределов солнечной системы дает существенный вклад вплоть до 200 ГГц. Зависимость поглощения радиоволн в тумане и дожде от частоты показана на рис. 3.3.2.
Рис. 3.3.2. Зависимость поглощения радиоволн в тумане и дожде от частоты Мощность передатчика обычно лежит в диапазоне 50 мВт - 2 Вт. Модемы, как правило, используют шумоподобный метод передачи SST (spread spectrum transmission). Для устройств на частоты 2.4 ГГц и выше, как правило, используются направленные антенны и необходима прямая видимость между приемником и передатчиком. Такие каналы чаще работают по схеме точка-точка, но возможна реализация и многоточечного соединения. На аппаратном уровне здесь могут использоваться радиорелейное оборудование радиомодемы или радио-бриджи. Схема этих устройств имеет много общего. Отличаются они лишь сетевым интерфейсом (см. рис. 3.3.3). Антенна служит как для приема, так и для передачи. Трансивер (приемопередатчик) может соединяться с антенной через специальные усилители. Между трансивером и модемом может включаться преобразователь частот. Модемы подключаются к локальной сети через последовательные интерфейсы типа RS-232 или v.35 (RS-249), для многих из них такие интерфейсы являются встроенными. Отечественное радиорелейное оборудование имеет в качестве выходного интерфейс типа G.703 и по этой причине нуждается в адаптере. Радио-бриджи имеют встроенный Ethernet-интерфейс. Длина кабеля от модема до трансивера лежит в пределах 30-70м, а соединительный кабель между модемом и ЭВМ может иметь длину 100-150м. Трансивер располагается обычно рядом с антенной.
Рис. 3.3.3. Схема оборудования радиоканала передачи данных Схемы соединения радиомодемов и традиционных модемов совершенно идентичны (см. рис. 3.3.4).
Рис. 3.3.4. Схема подключения радио-модемов Кроме уже указанных примеров перспективным полем применения радиомодемов могут стать "подвижные ЭВМ". Сюда следует отнести и ЭВМ бизнесменов, клиентов сотовых телефонных сетей, и все случаи, когда ЭВМ по характеру своего применения подвижна, например, медицинская диагностика на выезде, оперативная диагностика сложного электронного оборудования, когда необходима связь с базовым отделением фирмы, геологические или геофизические исследования и т.д. Радиомодемы позволяют сформировать сеть быстрее (если не считать времени на аттестацию оборудования, получение разрешения на выбранную частоту и лицензии на использование данного направления канала). В этом случае могут стать доступными точки, лишенные телефонной связи (что весьма привлекательно для условий России). Подключение объектов к центральному узлу осуществляется по звездообразной схеме. Заметное влияние на конфигурацию сети оказывает ожидаемое распределение потоков информации. Если все объекты, подключенные к узлу, примерно эквивалентны, а ожидаемые информационные потоки не велики, можно в центральном узле обойтись простым маршрутизатором, имеющим достаточное число последовательных интерфейсов. Применение радио-бриджей особенно выигрышно для организаций, имеющих здания, отстоящие друг от друга на несколько километров. Возможно использование этих средств связи и для подключения к сервис-провайдеру, когда нужны информационные потоки до 2 Мбит/с (например, для проведения видео конференций). Если расстояния не велики (<5км), можно воспользоваться всенаправленной антенной (см. рис. 3.3.5).
Рис. 3.3.5. Схема подключения объектов через радио-бриджи с помощью всенаправленной антенны Все соединяемые объекты (А, Б, В, и Г) должны быть оснащены радио-бриджами. Такая схема подключения эквивалентна с одной стороны кабельному сегменту ethernet, так как в любой момент времени возможен обмен лишь между двумя объектами; с другой стороны радио-бриджи А, Б, В и Г логически образуют много портовый бридж (или переключатель), что исключает загрузку локальных сетей объектов "чужими" пакетами. Модификации таких схем связи позволяют строить телекоммуникационные системы по схеме сотовых телефонных сетей. При построении каналов на основе радиорелейных систем или радио-бриджей следует учитывать возможность их взаимного влияния (см. рис. 3.3.6). Проектируя такие каналы в городе и используя направленные параболические антенны, нужно учитывать возможные помехи от зданий и профиля местности. Направленная антенна с площадью А обеспечивает усиление сигнала:
Угол излучения q такой антенны с радиусом R равен 0,61 l/R. Отсюда видно, что чем больше радиус, тем больше усиления и уже угол излучения и чувствительности. Предельные расстояния для радио каналов приводятся поставщиками в предположении, что в пределах первой зоны Френеля каких-либо физических помех нет. При звездообразной схеме каналов (как на рис. 3.6.) нужно по возможности выполнить требования на минимальное расстояние между принимающими антеннами d (оно должно быть больше определенного значения, зависящего от апертуры антенны и расстояния между передатчиком и приемником).
Рис. 3.3.6. Это расстояние определяется расходимостью (a) радиолуча и используемой длиной волны. Если это требование не выполнимо, следует в смежных каналах использовать разные длины волн. Диаграмма излучения направленной антенны показана на рис. 3.3.7 (стрелкой отмечено основное направление излучения). Эту диаграмму следует учитывать при выборе места установки антенны, особенно при использовании большой мощности излучения. Иначе один из лепестков излучения может прийтись на места постоянного пребывания людей (например, жилье). Учитывая эти обстоятельства, проектирование такого рода каналов целесообразно поручить профессионалам.
Рис. 3.3.7. Диаграмма излучения параболической антенны Стоимость антенного комплекса обычно пропорциональна кубу диаметра антенны. Стандартная антенна intelsat имеет диаметр 30 м и угол излучения 0,01 0. Спутниковые каналы используют диапазоны перечисленные в таблице 3.3.2. Таблица 3.3.2. Частотные диапазоны, используемые для спутниковых телекоммуникаций
Из таблицы видно, что передача ведется на более высокой частоте, чем прием сигнала со спутника. Обычный спутник обладает 12-20 транспондерами (приемопередатчиками), каждый из которых имеет полосу 36-50МГц, что позволяет сформировать поток данных 50 Мбит/с. Такая пропускная способность достаточна для получения 1600 высококачественных телефонных каналов (32кбит/c). Современные спутники используют узкоапертурную технологию передачи vsat (very small aperure terminals). Такие терминалы используют антенны диаметром 1 метр и выходную мощность около 1 Вт. При этом канал к спутнику имеет пропускную способность 19,2 кбит/с, а со спутника более 512 кбит/c. Непосредственно такие терминалы не могут работать друг с другом, разумеется через телекоммуникационный спутник. Для решения этой проблемы используются промежуточные наземные антенны с большим усилением, что, правда увеличивает задержку. Схема связей в технологии VSAT.
Рис. 3.3.8. Схема спутниковой связи VSAT Терминальные антены vsat имеют диаметр 1-1,5 м и излучаемую мощность 1-4 Вт, обеспечивая широкополосность до 64 кбит/с. Такие небольшие антенны не позволяют таким терминалам общаться непосредственно. На рис. 3.3.8. станции А и Б не могут непосредственно друг с другом. Для передачи данных используется промежуточная станция с большой антенной и мощностью (на рис. антенна В). Для создания постоянных каналов телекоммуникаций служат геостационарные спутники, висящие над экватором на высоте около 36000 км. Теоретически три таких спутника могли бы обеспечить связью практически всю обитаемую поверхность земли (см. рис. 3.3.9.). Спутники, работающие на одной и той же частоте должны быть разнесены по углу на 2o. Это означет что число таких спутников не может быть больше 180. В противном случае они должны работать в разных частотных диапазонах. При работе в ku-диапазоне угловое расстояние между спутниками можно сократить до 1o. Влияние дождя можно минимизировать, используя далеко отстоящие наземные станции (размеры урагана конечны!).
Рис. 3.3.9. Реально геостационарная орбита переполнена спутниками различного назначения и национальной принадлежности. Обычно спутники помечаются географической долготой мест, над которым они висят. На практике геостационарный спутник не стоит на месте, а выполняет движение по траектории, имеющей вид цифры 8. Угловой размер этой восьмерки должен укладываться в рабочую апертуру антенны, в противном случае антенна должна иметь сервопривод, обеспечивающий автоматическое слежение за спутником. Из-за энергетических проблем телекоммуникационный спутник не может обеспечить высокого уровня сигнала. По этой причине наземная антенна должна иметь большой диаметр, а приемное оборудование низкий уровень шума. Это особенно важно для северных областей, для которых угловое положение спутника над горизонтом невысоко (это особенно существенно для широт более 700), а сигнал проходит довольно толстый слой атмосферы и заметно ослабляется. Спутниковые каналы могут быть рентабельны для областей, отстоящих друг от друга более чем на 400-500 км (при условии что других средств не существует). Правильный выбор спутника (его долготы) может заметно снизить стоимость канала. Число позиций для размещения геостационарных спутников ограничено. В последнее время для телекоммуникаций планируется применение так называемых низколетящих спутников (<1000 км; период обращения ~1 час). Эти спутники движутся по эллиптическим орбитам и каждый из них по отдельности не может гарантировать стационарный канал, но в совокупности эта система обеспечивает весь спектр услуг (каждый из спутников работает в режиме "запомнить и передать"). Из-за малой высоты полета наземные станции в этом случае могут иметь небольшие антенны и малую стоимость. Смотри также S.Bhatti. Типичный спутник имеет 12-20 транспондеров, каждый из которых имеет полосу 36-50 МГц. Один транспондер может обеспечить информационный поток в 50 Мбит/с или 800 64-килобитных каналов цифровой телефонии. Два транспондера могут использовать разную поляризацию сигнала и по этой причине работать на одной и той жк частоте. Каждый телекоммуникационный спутник снабжен несколькими антеннами. Низходящий луч может быть сфокусирован на достаточно ограниченную область на земле (с диаметром несколько сот км). Что также упрощает осуществление двунаправленного обмена. Существует несколько способов работы совокупности наземных терминалов со спутником. При этом может использоваться мультиплексирование по частоте (FDM), по времени (TDM), CDMA (Code Division Multiple Access), ALOHA или метод запросов. Схема запросов предполагает, что наземные станции образуют логическое кольцо, вдоль которого двигается маркер. Наземная станция может начать передачу на спутник, лишь получив этот маркер. Простая система ALOHA (разработана группой Нормана Абрамсона из Гавайского университета в 70-х годах) позволяет каждой станции начинать передачу тогда, когда она этого захочет. Такая схема с неизбежностью приводит к столкновениям. Связано это отчасти с тем, что передающая сторона узнает о столкновении лишь спустя ~270 мсек. После столкновения станция ожидает некоторое псевдослучайное время и совершает повторную попытку передачи еще раз. Такой алгоритм доступа обеспечивает эффективность использования канала на уровне около 18%, что совершенно недопустимо для таких дорогостоящих каналов, как спутниковые. По этой причине чаще используется доменная версия системы ALOHA, которая удваивает эффективность. Одна наземная станция (эталонная) периодически посылает специальный сигнал, который используется всеми участниками для синхронизации. Если длина временного домена равна DT, тогда домен с номером k начинается в момент времени kDT по отношению к упомянутому выше сигналу. Так как часы разных станций работают немного по разному, необходима периодическая ресинхронизация. Другой проблемой является разброс времени распространения сигнала для разных станций. Метод мультиплекcирования по частоте (FDM) является старейшим и наиболее часто используемым. Типичный транспондер с полосой 36 Мбит/с может использован для получения 500 64кбит/с ИКМ-каналов, каждый из которых работает со своей уникальной частотой, чтобы исключить интерференцию с другими. Соседние каналы должны отстоять на достаточном расстоянии друг от друга. Кроме того, должен контролироваться уровень передаваемого сигнала, так как при слишком большой выходной мощности могут возникнуть интерференционные помехо в соседнем канале. Если число станций невелико и постоянно, частотные каналы могут быть распределены стационарно. Но при переменном числе терминалов или при заметной флуктуации загрузки приходится переходить на динамическое распределение ресурсов. Одним из механизмов такого распределение имеет название SPADE, он использовался в первых версиях систем связи на базе INTELSAT. Каждый транспондер системы SPADE содержит 794 симплексных ИКМ-каналов по 64-кбит/c и один сигнальный канал с полосой 128 кбит/c. ИКМ-каналы используются попарно для обеспечения полнодуплексной связи. При этом восходящий и ниcходящий каналы имеют полосу по 50 Мбит/с. Сигнальный канал делится на 50 доменов по 1 мсек (128 бит). Каждый домен принадлежит одной из наземной станции, число которых не превышает 50. Когда станция готова к передаче, она произвольным образом выбирает неиспользуемый канал и записывает номер этого канала в очередной свой 128 битный домен. Если один и тот же канал попытаются занять две или более станции происходит столкновение и они вынуждены будут повторить попытку позднее. Метод мультиплекирования по времени сходен с FDM и довольно широко применяется на практике. Здесь также необходима синхронизация для доменов. Это делается как и в доменной системе ALOHA c помощью эталонной станции. Присвоение доменов наземным станциям может выполняться централизовано или децентрализовано. Рассмотрим систему ACTS (Advanced Communication Technology Satellite). Система имеет 4 независимых канала (TDM) по 110 Мбит/c (два восходящих и два ниcходящих). Каждый из каналов структурированы в виде 1-милисекундных кадров, каждый из которых имеет по 1728 временных доменов. Каждый из временных доменов имеет 64-битовое поле данных, что позволяет реализовать голосовой канал с полосой в 64 кбит/c. Управление временными доменами с целью минимизации времени на перемещения вектора излучения спутника предполагает знание географического положения наземных станций. Управление временными доменами осуществляется одной из наземных станций (MCS - Master Control Station). Работа системы ACTS представляет собой трехшаговый процесс. Каждый из шагов занимает 1 мсек. На первом шаге спутник получает кадр и запоминает его в 1728-ячеечном буфере. На втором - бортовая ЭВМ копирует каждую входную запись в выходной буфер (возможно для другой антенны). И, наконец, выходная запись передается наземной станции. В исходный момент каждой наземной станции ставится в соответствие один временной домен. Для получения дополнительного домена, например для организации еще одного телефонного канала, станция посылает запрос MCS. Для этих целей выделяется специальный управляющий канал емкостью 13 запросов в сек. Существуют и динамические методы распределения ресурсов в TDM (методы Кроузера [Crowther], Биндера [Binder] и Робертса [Roberts]). Метод CDMA (Code Division Multiple Access) не требует синхронизации и является полностью децентрализованным. Как и другие методы он не лишен недостатков. Во-первых, емкость канала CDMA в присутствии шума и отсутствии координации между станциями обычно ниже, чем в случае TDM. Во-вторых, система требует быстродействующего и более дорогого оборудования. |
||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
3.2 Оптоволоконные каналы
UP:
3 Каналы передачи данных
|
|
|
|
3.4 Протокол SLIP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Протокол SLIP (Serial Line IP, RFC-1055) - это простейший способ инкапсуляции IP-дейтограмм для последовательных каналов связи. Этот протокол стал популярным благодаря возможностям подключения домашних персональных машин к сети Интернет через порт RS-232, который соединен с модемом. IP-дейтограмма в случае SLIP должна завершаться специальным символом 0xC0, называемым конец. Во многих реализациях дейтограмма и начинается с этого символа. Если какой-то байт дейтограммы равен символу конец, то вместо него передается двухбайтовая последовательность 0xDB, 0xDC. Октет 0xDB выполняет в SLIP функцию ESC-символа. Если же байт дейтограммы равен 0xDB, то вместо него передается последовательность 0xDB, 0xDD. Использование протокола SLIP предполагает выполнение ряда условий:
Впервые протокол SLIP был применен в 1984 году в 4.2BSD. Скорость передачи информации при использовании протокола SLIP не превышает 19.2кб/с, что обычно достаточно для интерактивного обмена в рамках протоколов telnet или RLOGIN. Максимальный размер передаваемого блока (MTU) для SLIP лежит вблизи 256-512 байт, что обеспечивает разумный компромисс между значением задержки отклика (~256мс.) и эффективностью использования канала (~98% для CSLIP). При этом для передачи одного символа (нажатая клавиша) используется 20 байт заголовка в IP-дейтограмме и 20 байт TCP-заголовка. Если мы учтем издержки формирования SLIP-кадра, накладные расходы превосходят 40 байт. Частично этот недостаток устранен в новой версии CSLIP (Compressed SLIP, RFC-1144, предложенной Джекобсоном в 1990 году). В CSLIP заголовок сокращается до 3-5байт (против 40 в SLIP). Эта версия протокола способна поддерживать до 16 TCP-соединений на каждом из концов последовательного канала. Многие современные SLIP-драйверы поддерживают и CSLIP. 3.4.1. Протоколы RS Протоколы RS (RS-232, RS-449, RS-423-А, RS-422-А и RS-485) относятся к семейству рекомендованных протоколов (буква R в названии обозначает recommended). RS-232 обеспечивает дуплексную связь и скорость передачи 19,2 кбит/с при длине связи до 15м. На практике при расстояниях порядка 10 метров можно получить быстродействие канала более 100кбит/с. Здесь обеспечивается связь точка-точка. Логической 1 соответствует уровень сигнала -(5-15)В, а логическому нулю +(5-15)В. В отличии от других упомянутых выше стандартов, которые допускают скорости обмена до 10Мбит/с (при длине линии 15м), данный протокол из-за низкой скорости обмена работает без использования симметричных сигналов на скрученной паре канала связи. Более подробную информацию можно найти, например, в http://ixbt.stack.net/comm/rs_proto.html. Разводка разъема приведена в приложении. Стандарт RS-449 представляет собой в действительности семейство, состоящее из 3-х стандартов. Механическая, функциональная и процедурная часть содержится в самом RS-449, а регламентации электрического интерфейса описаны в RS-423-A (подобен RS-232-C) дле схемы с общей землей. Балансная симметричная схема интерфейса представлена в документе на RS-422-A, для для передачи каждого сигнала используется два провода, что позволяет достичь быстродействия 2Мбит/с при длине соединения до 60м. Разводка разъемов представлена в приложении . |
|
Previous:
3.3 Беспроводные (радио) каналы и сети
UP:
3 Каналы передачи данных
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
3.5 Протокол PPP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51, cмотри также www.spitbrook.destek.com:81/pptp.txt) предназначен для решения тех же задач, что и SLIP, но лишен многих его недостатков, он служит для передачи мультипротокольных дейтограмм от одного узла к другому. Сам по себе список RFC, приведенный выше, впечатляющ. Он говорит о том, что данный протокол относится к числу наиболее важных и широко используемых. Это и понятно, большинство региональных сетей строится с использованием соединений точка-точка. PPP поддерживает, как асинхронный режим с 8 битами данных без бита четности (согласуется со свойствами последовательного интерфейса, имеющегося практически на всех ЭВМ), так и побитовый синхронный режим. Протокол содержит в себе три составные части:
Протокол управления каналом (LCP - Link Control Protocol) является частью PPP. Идеология NCP реализована и в протоколе TCP. Каждый кадр PPP начинается и завершается флагом 0x7E. За стартовым флагом-октетом следует байт адреса, который всегда равен 0xFF. Формат кадра PPP представлен на рисунке 3.5.1. Кадр ppp может содержать только целое число байт. При инкапсуляции других пакетов в PPP используется бит-ориентированный протокол HDLC (High-level Data Link Control).
Рис. 3.5.1 Формат кадра в протоколе PPP Поле адрес всегда содержит байт 0xff (смотри также HDLC). Это указывает на то, что все станции должны принять этот кадр, и исключает необходимость выделения каких-то специальных адресов. Байт управления всегда равен 0x03, что указывает на ненумерованный тип кадра. По умолчанию кадры PPP передаются в режиме "без установления соединения". Если требуется надежная доставка, используется версия, описанная в RFC-1663. Двухоктетное поле протокол сходно по функции с полем тип в кадре Ethernet и определяет то, как следует интерпретировать информационное поле (см. табл. 3.5.1). Значение 0x0021 этого поля говорит о том, что последующее информационное поле содержит в себе IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) представляет собой циклическую контрольную сумму, предназначенную для выявления ошибок при транспортировке PPP-кадра. Применение флагов-ограничителей кадра (0x7E) создает те же проблемы, о которых говорилось при описании SLIP-протокола, - эти байты не могут присутствовать в информационном поле. В синхронном режиме эта проблема решается на аппаратном уровне. При работе в асинхронном режиме для этого используется специальный ESC-символ, равный 0x7D. Когда этот esc-символ встречается в информационном поле, шестой бит в следующем за ним байте инвертируется. Так байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D - в два байта 0x7D, 0x5D. Все символы с кодами меньше 0x20 также преобразуются в ESC-последовательности. Например, 0x07 будет преобразован в 0x7D, 0x27. Это необходимо делать, так как управляющие символы могут оказать непредсказуемые воздействия на режим работы драйверов или модемов, используемых в канале. Протокол ppp в отличие от SLIP допускает мультипротокольность и динамическое определение IP-адресов партнеров. Несмотря на определенные преимущества протокола PPP перед SLIP, последний распространен достаточно широко. Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации. Таблица 3.5.1. Стандартизованные DLL-номера протоколов для PPP (поле протокол)
Значения кодов поля протокола от 0xxx до 3xxx идентифицируют протоколы сетевого уровня, а значения в интервале 8xxx - bxxx говорят о том, что протокол соответствует NCP (Network Control Protocol). Коды из диапазона 4xxx - 7xxx используются для протоколов с низким уровнем трафика, а коды от cxxx до exxx соответствуют управляющим протоколам (например, LCP). Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной (смотри рис. 3.5.2.). После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала.
Рис. 3.5.2. Алгоритм установления соединения PPP При обнаружении несущей или по инициативе клиента система может попытаться установить соединение. В случае успеха система переходит в фазу аутентификации. Если же и фаза аутентификации завершается благополучно, система выполняет подключение к сети (IP, IPX, Appletalk и т.д.), настройка сетевого уровня производится в рамках протокола NCP. Во всех остальных случаях производится возврат в исходное состояние. Процедура закрытия соединения осуществляется протоколом LCP. В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021 (Link Control Protocol). LCP-протокол служит для установления соединения путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации (рис.3.5.2). Формат LCP-пакета показан на рис. 3.5.3.
Рис. 3.5.3. Формат заголовка LCP-пакета Вслед за заголовком следует поле данных. Поле код (1 октет) идентифицирует модификацию LCP-пакета. Если получен пакет с неизвестным полем код, посылается пакет-отклик "отклонение кода". Поле идентификатор (1 октет) служит для нахождения соответствия между запросами и откликами. Если получен пакет с неправильным идентификатором, он просто уничтожается. Двухоктетное поле длина определяет размер LCP-пакета, включая размер заголовка. Октеты принятого пакета за пределами, заданными полем длина игнорируются. В качестве примера можно рассмотреть процедуру подключения персональной ЭВМ к серверу через модем. После того как модем маршрутизатора ответит на вызов модема-клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет работать со стеком протоколов TCP/IP, и по этой причине нуждается в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он может подключить одновременно N ЭВМ. Присвоение IP-адреса осуществляется также в рамках NCP-протокола. После этого ЭВИ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения осуществляет протокол LCP. За полем длина могут следовать поля опций. Опции определяются все сразу на фазе конфигурирования канала. Описание опции содержит однооктетные субполя типа и длины, за которыми следует поле данных. Значения субполя типа представлены в таблице.
Существует три класса LCP-пакетов:
Аналогом LCP является протокол IPCP (IP Control Protocol). В поле код протокола в этом случае записывается 8021 (RFC-1332). Формат пакета IPCP показан на рис. 3.5.4.
Рис. 3.5.4. Формат пакета IPCP. Младшие биты слева. Поле тип содержит 2, в поле длина заносится число байт в пакете (≥4). В поле протокол сжатия IP заносится код алгоритма сжатия (0х02D - в случае алгоритма Ван Джекобсона). Поле данные может содержать нуль или более октетов. Конфигурационный запрос может потребовать присылки (присвоения) IP-адреса. Для решения этой задачи предусмотрена опция IPCP-пакета, где поле тип=3, длина=6, а последующие 4 байта выделены для IP-адреса, куда отправитель должен его записать. Если туда записаны нули, это говорит о том, что отправитель запрашивает свой IP-адрес. Протоколы PPP, LCP (Link Control Protocol), CCP (Compression Control Protocol; RFC-1962, -1967), и некоторые другие управляющие протоколы содержат 8-битовые поля код. Значения этих кодов приведены в таблице 3.5.2. Таблица 3.5.2 Значения поля код LCP-заголовка
Для случая запроса Discard-Request между полями длина и данные помещается 4-байтовое поле Magic-Number (магическое число). Протокол PPP многолик, он способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно при работе через ISDN, X.25, Frame Relay или при необходимости расширить пропускную способность за счет подключения нескольких параллельных каналов (MP - MultiLink Protocol). Так как я не сталкивался со случаями, когда пропускной способности было вполне достаточно, данную модификацию PPP-протокола следует считать крайне важной. При этом одной из проблем является распределение пакетов по каналам и последующее их упорядочение принимающей стороной. Особую осторожность в этом случае следует соблюдать при использовании заполнителей. В этом режиме по виртуальному каналу MultiLink запрещается посылать конфигурационные LCP-пакеты Configure-Request, -Reject, -Ack, -Nak, Terminate-Request или -Ack. Принимающая сторона в случае их обнаружения должна их игнорировать. Применение других LCP-пакетов допускается (например, Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request). Формат MP-пакета представлен на рис. 3.5.5.
Рис. 3.5.5. Формат MР-пакета Поля PID - идентификатор протокола. Субполе B (Beginning) - бит фрагмента =1 для первого фрагмента PPP и =0 для всех последующих фрагментов. Субполе E (Ending) - бит фрагмента =1 для последнего фрагмента PPP и =0 для всех прочих фрагментов. Поле номер по порядку имеет длину 24 бита. Существует модификация пакета с укороченным кодом (12 бит) номера по порядку. При этом к этому полю отходят 4 нулевые бита после BE00. Выбор длины этого поля осуществляется протоколом LCP. Значение полу увеличивается на 1 при посылке очередного фрагмента. Для вышерасположенных уровней совокупность совместно используемых каналов выглядит, как один виртуальный канал. При передаче пакетов по каналу Multilink инкапсуляция производится согласно следующим правилам, которые задаются вручную:
Для предварительно фрагментированных пакетов запрещено дополнение нулями или использование каких-либо иных заполнителей. Рассмотрим пример Multilink-соединения, приведенный на рис. 3.5.6. Канал 1 между двумя системами согласуется сетевыми уровнями NL1, NL2 и MP. Затем эти две системы согласуют с MP канал 2. Кадры, полученные каналом 1, демультиплексируются на канальном уровне согласно сетевому протокольному идентификатору PPP и могут быть посланы NL1, NL2 или MP. Канал 2 примет кадры со всеми сетевыми протокольными идентификаторами, с которыми принимает их канал 1. Кадры, полученные MP, позднее демультиплексируются на сетевом уровне согласно протокольному идентификатору PPP и посылаются NL1 или NL2. Любые кадры, полученные MP для других протоколов сетевого уровня, отбрасываются с помощью стандартного протокольного механизма (Reject).
Рис. 3.5.6. Пример Multilink-конфигурации Так как межсетевые связи часто используют последовательные каналы (выделенные линии, радиомодемы и пр.), протокол PPP распространен достаточно широко. Протокол PPP служит и для создания межсетевых туннелей (протокол PPTP - Point to Point Tunneling Protocol). Протокол PPTP использует MTU=1532, номер порта 5678 и номер версии 0x0100, пакеты данных здесь транспортируются с использованием протокола инкапсуляции GRE V2 (см. сноску в начале раздела). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
3.4 Протокол SLIP
UP:
3 Каналы передачи данных
|
|
|
||||||||||||||||||||||||||||||||||||||||||||
|
3.6 Протокол G.703
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||
|
(ITU-T Recommendation G.703.Physical/Electrical Characteristics of Hierarchical Digital Interfaces. 1972 last amended in 1991). Интерфейс G.703 (ITU-T Recommendation G.703.Physical/Electrical Characteristics of Hierarchical Digital Interfaces. 1972 last amended in 1991) был разработан в 1972 году и базируется на стандартах G.702, G.704 и I.430 и обслуживает сети с иерархией PDH и SDH. Первоначально он разрабатывался для систем с импульсно-кодовой модуляцией. G.703 может работать на скоростях передачи данных 64 Кбит/с, 1544, 6312, 32064 и 44736 Кбит/с (PDH, американская версия), 2048, 8448, 34368, 139264 Кбит/с (европейская версия). Предусматривается работа и при 155,52 Мбит/с. В качестве физического канала передачи может использоваться скрученная пара (Z=100-120 Ом) или коаксиальный кабель (75 Ом), амплитуда импульса 1-3В. При скорости 64 Кбит/с через интерфейс передается три типа сигналов: информационный (64 Кбит/с) и два синхронизирующих тактовых 64 Кбит/с и 8 Кбит/с. Стандарт предусматривает 3 вида взаимодействия терминального оборудования: однонаправленный (codirectional; рис. 3.6.1), разнонаправленный (рис. 3.6.2) и с центральным тактовым генератором (рис. 3.6.3). Рис. 3.6.1. Однонаправленная передача информации и тактовых сигналов
Рис. 3.6.2. Разнонаправленная передача информации и тактового сигнала для 64 Кбит/с Во втором варианте терминалы неравноправны - один из них управляющий, другой - управляемый. Тактовые сигналы идут в этом случае только от управляющего терминала.
Рис. 3.6.3. Интерфейс с центральным тактовым генератором для 64 кбит/с Частота синхронизирующих сигналов может быть меньше скорости передачи данных в 2, 4 и 8 раз. Тип кода зависит от скорости передачи и типа аппаратного интерфейса. Характеристики основных разновидностей интерфейса G.703 приведены в таблице 3.6.1. Таблица 3.6.1.
Кодировка относится лишь для случая проводных каналов. |
||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
3.5 Протокол PPP
UP:
3 Каналы передачи данных
|
|
|
||||||||||||||||||||||||||||||||
|
3 Каналы передачи данных
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||
За последние двадцать лет пропускная способность каналов выросла с 56 кбит/c до 1 Гбит/с. Разработаны технологии, способные работать в случае оптических кабелей со скоростью 50 Тбит/с. Вероятность ошибки при этом сократилась с 10-5 на бит до пренебрежимо низкого уровня. Современный же лимит в несколько Гбит/с связан главным образом с тем, что люди не научились делать быстродействующие преобразователи электрических сигналов в оптические. |
||||||||||||||||||||||||||||||||
|
Previous:
2.10 Статистическая теория каналов связи
UP:
2.6 Методы сжатия информации
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
3.1 Кабельные каналы связи
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Кабельные каналы для целей телекоммуникаций исторически использовались первыми. Да и сегодня по суммарной длине они превосходят даже спутниковые каналы. Основную долю этих каналов, насчитывающих многие сотни тысяч километров, составляют телефонные медные кабели. Эти кабели содержат десятки или даже сотни скрученных пар проводов. Полоса пропускания таких кабелей обычно составляет 3-3,5 кГц при длине 2-10 км. Эта полоса диктовалась ранее нуждами аналогового голосового обмена в рамках коммутируемой телефонной сети. c учетом возрастающих требованиям к широкополосности каналов скрученные пары проводов пытались заменить коаксиальными кабелями, которые имеют полосу от 100 до 500 МГц (до 1 Гбит/с), и даже полыми волноводами. Именно коаксиальные кабели стали в начале транспортной средой локальных сетей ЭВМ (10base-5 и 10base-2; см. рис. 3.1.1).
Рис. 3.1.1. 1 - центральный проводник; 2 - изолятор; 3 - проводник-экран; внешний изолятор Коаксиальная система проводников из-за своей симметричности вызывает минимальное внешнее электромагнитное излучение. Сигнал распространяется по центральной медной жиле, контур тока замыкается через внешний экранный провод. При заземлении экрана в нескольких точках по нему начинают протекать выравнивающие токи (ведь разные "земли" обычно имеют неравные потенциалы). Такие токи могут стать причиной внешних наводок (иной раз достаточных для выхода из строя интерфейсного оборудования), именно это обстоятельство является причиной требования заземления кабеля локальной сети только в одной точке. Наибольшее распространение получили кабели с волновым сопротивлением 50 ом. Это связано с тем, что эти кабели из-за относительно толстой центральной жилы характеризуются минимальным ослаблением сигнала (волновое сопротивление пропорционально логарифму отношения диаметров внешнего и внутреннего проводников). Но по мере развития технологии скрученные пары смогли вытеснить из этой области коаксиальные кабели. Это произошло, когда полоса пропускания скрученных пар достигла 200-350 МГц при длине 100м (неэкранированные и экранированные скрученные пары категории 5 и 6), а цены на единицу длины сравнялись. Скрученные пары проводников позволяют использовать биполярные приемники, что делает систему менее уязвимой (по сравнению с коаксиальными кабелями) к внешним наводкам. Но основополагающей причиной вытеснения коаксиальных кабелей явилась относительная дешевизна скрученных пар. Скрученные пары бывают одинарными, объединенными в многопарный кабель или оформленными в виде плоского ленточного кабеля. Применение проводов сети переменного тока для локальных сетей и передачи данных допустимо для весьма ограниченных расстояний. В таблице 3.1.1 приведены характеристики каналов, базирующихся на обычном и широкополосном коаксиальном кабелях. Таблица 3.1.1
На рис. 3.1.2 показана зависимость ослабления кабеля (внешний диаметр 0,95 см) от частоты передаваемого сигнала. При диагностировании сетей не всегда под руками может оказаться настоящий сетевой тестер типа WaveTek, и часто приходится довольствоваться обычным авометром. В этом случае может оказаться полезной таблица 3.1.2, где приведены удельные сопротивления используемых сетевых кабелей. Произведя измерение сопротивления сегмента, вы можете оценить его длину.
Таблица 3.1.2 Сопротивление кабеля по постоянному току
Эти данные взяты из Handbook of LAN Cable Testing. Wavetek Corporation, California .
Конкретные зависимости ослабления сигнала от частоты и длины кабеля в децибелах представлены в таблице ниже (LANline Special IV/2002 p/26).
Данные, приведенные в таблице 3.1.2, могут использоваться для оперативной предварительной оценки качества кабельного сегмента (соответствует стандарту EIA/TIA 568, 1991 год). Частотные характеристики неэкранированных пар категории 6 представлены в табл. 3.1.5`. Таблица 3.1.5. Параметры неэкранированных пар категории 6
ACR - Attenuation-to-Crosstalk Ratio. NEXT - Near End CrossTalk. Кабели, изготовленные из скрученных пар категории 5 (волновое сопротивление 100,15 Ом), с полосой 100 Мгц обеспечивают пропускную способность при передаче сигналов ATM 155 Мбит/с. При 4 скрученных парах это позволяет осуществлять передачу до 622 Мбит/с. Кабели категории 6 сертифицируются до частот 300 Мгц, а экранированные и до 600 Мгц (волновое сопротивление 100 Ом). В таблице 3.1.6 приведены данные по затуханию и перекрестным наводкам. Приведены характеристики такого кабеля с 4-мя скрученными экранированными парами (S-FTP). Таблица 3.1.6
ACR - Attenuation-to Crosstalk Ratio. Такой кабель пригоден для передачи информации со скоростью более 1 Гбит/с. ACR - Attenuation-to-Crosstalk Ratio (отношение ослабления к относительной величине перекресных наводок). Ниже на рис. 3.1.3 показана зависимость наводок на ближнем конце кабеля, содержащего скрученные пары, (NEXT - Near End CrossTalk) от частоты передаваемого сигнала.
Рис. 3.1.3. Зависимость наводок NEXT от частоты передаваемого сигнала. На рис. 3.1.4 представлена зависимость ослабления сигнала в неэкранированной скрученной паре (именно такие кабели наиболее часто используются для локальных сетей) от частоты передаваемого сигнала. Следует иметь в виду, что при частотах в области сотен мегагерц и выше существенный вклад начинает давать поглощение в диэлектрике. Таким образом, даже если проводники изготовить из чистого золота, существенного продвижения по полосе пропускания достичь не удастся.
Рис. 3.1.4. Зависимость ослабления сигнала от частоты для неэкранированной скрученной пары Для неэкранированной скрученной пары 5-ой категории зависимость отношения сигнал-шум от длины с учетом ослабления и наводок NEXT показана на рис. 3.1.5.
Рис. 3.1.5 Зависимость отношения сигнал/шум от частоты с учетом ослабления и наводок на ближнем конце кабеля Характеристики неэкранированных скрученных пар американского стандарта 24 AWG (приведены характеристики кабелей, используемых при построении локальных сетей) для кабелей различной категории собраны в таблице 3.1.7. Таблица 3.1.7.
Подводя итоги можно сказать, что при расстояниях до 100 метров с успехом могут использоваться скрученные пары и коаксиальные кабели, обеспечивая полосу пропускания до 150 Мбит/с, при больших расстояниях или более высоких частотах передачи оптоволоконный кабель предпочтительнее. Следует заметить, что работа с кабелями предполагает необходимость доступа к системе канализации (иногда это требует специальных лицензий; а там часто размещаются усилители-повторители). Кабельное хозяйство требует обслуживания. В этом отношении радиоканалы предпочтительнее, ведь случаев коррозии электромагнитных волн не зарегистрировано, да и крысы их не грызут. Справедливости ради отмечу, что здесь серьезную угрозу представляют корыстолюбивые бюрократы, ответственные за выдачу лицензий, а они пострашнее крыс. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
3 Каналы передачи данных
UP:
3 Каналы передачи данных
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4 Сети передачи данных. Методы доступа
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Топология Среди топологических схем наиболее популярными являются (см. рис. 4.1):
Рис. 4.1. Примеры сетевых топологий К первым трем типам топологии относятся 99% всех локальных сетей. Наиболее популярный тип сети - Ethernet, может строиться по схемам 1 и 2. Вариант 1 наиболее дешев, так как требует по одному интерфейсу на машину и не нуждается в каком-либо дополнительном оборудовании. Сети Token Ring и FDDI используют кольцевую топологию (3 на рис. 4.1), где каждый узел должен иметь два сетевых интерфейса. Эта топология удобна для оптоволоконных каналов, где сигнал может передаваться только в одном направлении (но при наличии двух колец, как в FDDI, возможна и двунаправленная передача). Нетрудно видеть, что кольцевая топология строится из последовательности соединений точка-точка. Используется и немалое количество других топологий, которые являются комбинациями уже названных. Примеры таких топологий представлены на рис. 4.2. Вариант А на рис. 4.2 представляет собой схему с полным набором связей (все узлы соединены со всеми), такая схема используется только в случае, когда необходимо обеспечить высокую надежность соединений. Эта версия требует для каждого из узлов наличия n-1 интерфейсов при полном числе узлов n. Вариант Б является примером нерегулярной топологии, а вариант В - иерархический случай связи (древовидная топология). Если топологии на рис. 4.1 чаще применимы для локальных сетей, то топологии на рис. 4.2 более типичны для региональных и глобальных сетей. Выбор топологии локальной или региональной сети существенно сказывается на ее стоимости и рабочих характеристиках. При этом важной характеристикой при однородной сети является среднее число шагов между узлами d.
Рис. 4.2. Различные сетевые топологические схемы Современные вычислительные системы используют и другие топологии: решетки (А), кубы (В), гипердеревья (Б), гиперкубы и т.д. (см. рис. 4.3). Но так как некоторые вычислительные системы (кластеры) базируются на сетевых технологиях, я привожу и такие примеры. В некоторых системах топология может настраиваться на решаемую задачу.
Рис. 4.3. Некоторые топологии вычислительных систем Метод доступа к сети Метод доступа определяет метод, который используется при мультиплексировании/демультиплексировании данных в процессе передачи их по сети. Большая часть современных сетей базируется на алгоритме доступа CSMA/CD (carrier sensitive multiple access with collision detection), где все узлы имеют равные возможности доступа к сетевой среде, а при одновременной попытке фиксируется столкновение и сеанс передачи повторяется позднее. Здесь нет возможности приоритетного доступа и по этой причине такие сети плохо приспособлены для задач управления в реальном масштабе времени. Некоторое видоизменение алгоритма CSMA/CD (как это сделано в сетях CAN или в IBM DSDB) позволяют преодолеть эти ограничения. Доступ по схеме CSMA/CD (из-за столкновений) предполагает ограничение на минимальную длину пакета. По существу, метод доступа CSMA/CD предполагает широковещательную передачу пакетов (не путать с широковещательной адресацией). Все рабочие станции логического сетевого сегмента воспринимают эти пакеты хотя бы частично, чтобы прочесть адресную часть. При широковещательной адресации пакеты не только считываются целиком в буфер, но и производится прерывание процессора для обработки факта прихода такого пакета. Логика поведения субъектов в сети с доступом CSMA/CD может варьироваться. Здесь существенную роль играет то, синхронизовано ли время доступа у этих субъектов. В случае Ethernet такой синхронизации нет. В общем случае при наличии синхронизации возможны следующие алгоритмы. А.
Алгоритм А на первый взгляд представляется привлекательным, но в нем заложена возможность столкновений с вероятностью 100%. Алгоритмы Б и В более устойчивы в отношении этой проблемы. Следующим по популярности после csma/cd является маркерный доступ (Token Ring, Arcnet и FDDI), который более гибок и обеспечивает приоритетную иерархию обслуживания. Массовому его внедрению препятствует сложность и дороговизна. Хотя региональные сети имеют самую разнообразную топологию, практически всегда они строятся на связях точка-точка. В таблице 4.1 представлены сводные данные по основным видам локальных сетей, используемых в настоящее время (список не является полным). Таблица 4.1. Параметры различных локальных сетей
Приведенная таблица не может претендовать на полноту. Так сюда не вошла сеть IBM DSDB, разработанная в начале 80-х годов. Полоса пропускания сети составляет 64 Мбит/с. Эта сеть рассчитана на обслуживания процессов реального времени. Сеть имеет топологию шины с приоритетным доступом (длина шины до 500м). Коммуникационная шина логически делится на три магистрали: сигнальная - для реализации приоритетного доступа; лексемная шина для резервирования в буфере места назначения; и, наконец, коммуникационная шина для передачи данных. Каждая из указанных магистралей использует идеологию независимых временных доменов, границы которых синхронизованы для всех трех магистралей. Схема доступа сходна с описанной для сетей CAN (см. раздел 4.1.4).
Данная схема доступа исключает столкновения, характерные для CSMA. Именно это преимущество делает сеть применимой для задач реального времени. Существует целое семейство методов доступа, исключающих столкновение: это мультиплексирование по времени (TDM) и по частоте (FDM). Здесь каждому клиенту выделяется определенный временной домен или частотный диапазон. Когда наступает его временной интервал и клиент имеет кадр (или бит), предназначенный для отправки, он делает это. При этом каждый клиент ждет в среднем n/2 временных интервалов (предполагается, что работает n клиентов). При FDM передача не требует ожидания. Но в обоих случаях временные интервалы или частотные диапазоны используются клиентом по мере необходимости и могут заметное время быть не заняты (простаивать). Такие протоколы доступа часто используются в мобильной связи. Интересной разновидностью Ethernet является широкополосная сеть типа Net/one. Она может базироваться на коаксиальном кабеле (суммарная длина до 1500м) или на оптическом волокне (полная длина до 2500м). Эта сеть по многим характеристикам аналогична обычному ethernet (CSMA/CD) за исключением того, что коммуникационное оборудование передает данные на одной частоте, а принимает - на другой. Для каждого канала выделяется полоса 5 Мбит/с (полоса пропускания 6МГц соответствует телевизионному стандарту). Предусматривается 5 передающих (59,75-89,75 МГц) и 5 принимающих (252-282 МГц) каналов для каждого из сетевых сегментов. Частота ошибок (BER) для сети данного типа меньше 10-8. Другой Ethernet-совместимой сетью является Fibercom Whispernet. Сеть имеет кольцевую структуру (до 8км), полосу пропускания 10Мбит/c, число узлов до 100 на сегменте при полном числе узлов в сети - 1024. Число кольцевых сегментов может достигать 101. Максимальное межузловое расстояние - 2км. Примером нетрадиционного типа сети может служить Localnet 20 (Sytek). Сеть базируется на одном коаксиальном кабеле и имеет полную полосу пропускания 400 МГц. Сеть делится на 120 каналов, каждый из которых работает со скоростью 128 Кбит/с. Каналы используют две 36МГц-полосы, одна для передачи, другая для приема. Каждый из коммуникационных каналов занимает 300КГц из 36МГц. Сеть использует алгоритм доступа CSMA/CD, что позволяет подключать к одному каналу большое число сетевых устройств. Предусматривается совместимость с интерфейсом RS-232. Частота ошибок в сети не более 10-8. Фирма Дженерал Электрик разработала сеть gm (map-шина), совместимую со стандартом IEEE 802.4. Целью разработки было обеспечение совместимости с производственным оборудованием различных компаний. Сеть рассчитана на работу со скоростями 1, 5 и 50 Мбит/с. Традиционные сети и телекоммуникационные каналы образуют основу сети - ее физический уровень. Реальная топология сети может динамически изменяться, хотя это и происходит обычно незаметно для участников. При реализации сети используются десятки протоколов. В любых коммуникационных протоколах важное значение имеют операции, ориентированные на установление связи (connection-oriented) и операции, не требующие связи (connectionless - "бессвязные", ISO 8473). Интернет использует оба типа операций. При первом типе пользователь и сеть сначала устанавливают логическую связь и только затем начинают обмен данными. Причем между отдельными пересылаемыми блоками данных (пакетами) поддерживается некоторое взаимодействие. "Бессвязные" операции не предполагают установления какой-либо связи между пользователем и сетью (например, протокол UDP) до начала обмена. Отдельные блоки передаваемых данных в этом случае абсолютно независимы и не требуют подтверждения получения. Пакеты могут быть потеряны, задублированы или доставлены не в порядке их отправки, причем ни отправитель, ни получатель не будут об этом оповещены. Именно к этому типу относится базовый протокол Интернет - IP. Для каждой сети характерен свой интервал размеров пакетов. Среди факторов, влияющих на выбор размеров можно выделить
Ниже приведены максимальные размеры пакетов (mtu) для ряда сетей
Операции, ориентированные на установление связи (например, протокол TCP), предполагают трехстороннее соглашение между двумя пользователями и провайдером услуг. В процессе обмена они хранят необходимую информацию друг о друге, с тем, чтобы не перегружать вспомогательными данными пересылаемые пакеты. В этом режиме обмена обычно требуется подтверждение получения пакета, а при обнаружении сбоя предусматривается механизм повторной передачи поврежденного пакета. "Бессвязная" сеть более надежна, так как она может отправлять отдельные пакеты по разным маршрутам, обходя поврежденные участки. Такая сеть не зависит от протоколов, используемых в субсетях. Большинство протоколов Интернет используют именно эту схему обмена. Концептуально TCP/IP-сети предлагают три типа сервиса в порядке нарастания уровня иерархии: Немногие из читателей участвуют в создании региональных и тем более глобальных сетей, за то структура и принципы построения локальных сетей им, безусловно, близки. На рис. 4.4 и 4.5 приведены два варианта "ресурсных" локальных сетей (сети для коллективного использования ресурсов - памяти, процессоров, принтеров, магнитофонов и т.д.). Такие сети строятся так, чтобы пропускная способность участков, где информационные потоки суммируются, имели адекватную полосу пропускания. Эффективность сети на рис. 4.4 сильно зависит от структуры и возможностей контроллеров внешних устройств, от объема их буферной памяти.
Рис. 4.4. Вариант схемы ресурсной локальной сети Сеть, показанная на рис. 4.5, несравненно более эффективна (практически исключены столкновения и легче гарантировать определенное время доступа к ресурсу). Здесь также немало зависит от свойств контроллеров внешних ресурсов (помечены красным цветом). Но такие сети обычно более дорого реализовать.
Рис. 4.5. Для сопоставления быстродействия различных видов сетей Сталлингс (Stallings, W.: Data and Computer Communications, New York: Mac-Millan Publishing Company, 1985) в 1985 году разработал критерий. Критерий предполагает вычисление битовой длины BL (максимальное число бит в сегменте), которая равна произведению максимальной длины сегмента (L) на полосу пропускания (W), деленное на скорость распространения сигнала в сегменте (S): BL = l*W/S Для Ethernet BL = [500(м)*10 106(бит/c)]/2 108 (м/c) = 25 бит. Коэффициент использования сети равен b = 1/(1+a), где
Принципы построения сетевых программных интерфейсов Существует большое разнообразие сетевых интерфейсов. Их структура зависит от характера физического уровня сетевой среды, от метода доступа, от используемого набора интегральных схем и т.д.. Здесь пойдет речь о принципах построения программного интерфейса (см. также раздел 7; ..\7\soft_7.html). Существует три возможности построения интерфейса: с базированием на памяти, с использованием прямого доступа и с применением запросов обслуживания. Первый вариант предполагает наличие трех компонентов: буфер сообщений, область данных для управления передачей и зона памяти для управления приемом данных. Первый из компонентов служит для формирования исходящих сообщений программного интерфейса. Должны быть приняты меры, чтобы исключить модификацию содержимого этого буфера до того, как данные будут считаны ЭВМ или интерфейсом. Проблема решается путем формирования соответствующих указателей. Управление буфером осуществляется ЭВМ или совместно ЭВМ и интерфейсом с использованием механизма семафоров. Остальные методы связаны с использованием традиционных методов управления памятью с помощью средств операционной системы. Критической проблемой является обеспечение достаточного места в буфере для приходящих сообщений. Ведь в отсутствии памяти приходящее или записанное ранее сообщение может быть потеряно. Недостаток места для исходящих сообщений не является критическим, так как приводит обычно к задержке передачи, а не к потере сообщения. Второй компонент интерфейса, базирующегося на использовании памяти, часто реализуется в виде так называемых буферов управления передачей (TCB). Эти буферы содержат такую информацию как положения сообщения в памяти, длина сообщения, адрес места назначения, идентификатор процесса-отправителя, приоритет сообщения, предельное значение числа попыток передачи, а также флаг, указывающий на необходимость присылки подтверждения от получателя. TCB (transmission control buffer) создается процессом-отправителем и передается интерфейсу, после завершения записи в буфер сообщений. Параметры TCB используются интерфейсом при организации процесса передачи сообщения. Третий компонент интерфейса, базирующегося на использовании памяти, называется буфером управления приемом (RCB - Reception Control Buffer). RCB содержит в себе информацию, сходную с той, что записывается в TCB, например, идентификатор отправителя, длина сообщения, индикатор ошибки, время приема и идентификатор процесса места назначения. RCB заполняется интерфейсом при получении сообщения и передается процессору ЭВМ. Основополагающим принципом построение всех трех компонент является совместное использование памяти и гибкая система указателей. Версия программы, рассмотренная в разделе 7 ближе именно к этой схеме взаимодействия. Во втором варианте широко используемой схемы доступа к сети ("прямой доступ") взаимодействие ЭВМ и интерфейса строится по схеме клиент-сервер. Конкретная реализация программы в этом случае в большей степени зависит от структуры регистров физического интерфейса. В третьем варианте сетевого программного интерфейса используются служебные запросы. Этот тип сетевого доступа удобен для коммуникационных протоколов высокого уровня, таких как команды ввода/вывода CSP-стиля (Communicating Sequential Processes) или процедуры обмена языка Ада. В этом методе накладываются определенные ограничения на реализацию нижележащих коммуникационных уровней. Программирование для сетей существенным образом является программированием для процессов реального времени. Здесь часто можно столкнуться с тем, что одна и та же программа ведет себя по-разному в разных ситуациях. Особое внимание нужно уделять написанию многопроцессных сетевых программ, где также как в случае (см. раздел 7.1; ..\7\sock_71.html) работы с соединителями могут возникать ситуации блокировок. Пример такой ситуации показан на рис. 4.6.
Рис. 4.6. Когда число процессов больше, заметить запрограммированную ситуацию блокировки заметно сложнее. По этой причине необходимо предусмотреть меры препятствующие блокировке, если ожидаемое сообщение не пришло. Необычайно важной проблемой при построении сетей является их устойчивость при возникновении перегрузок. В Интернет для этого используется специальная опция протокола ICMP, а во Frame Relay имеются меры для преодоления перегрузок непосредственно на нижних протокольных уровнях. Оптимальность управления сетью в условиях перегрузок определяет эффективность использования сети. Пока субсеть загружена незначительно, число принимаемых и обрабатываемых пакетов равно числу пришедших. Однако, когда в субсеть поступает слишком много пакетов может возникнуть перегрузка и рабочие характеристики деградируют. При очень больших загрузках пропускная способность канала или сети может стать нулевой (см. [39]) Такая ситуация называется коллапсом сети. Отчасти это может быть связано с недостатком памяти для входных буферов, по этой причине некоторое увеличение памяти может помочь. Но следует помнить, что всякое лекарство хорошо в меру. Еще в 1987 году Нагле (Nagle) обнаружил, что если маршрутизатор имеет даже беспредельную память, эффект перегрузки может оказаться еще более тяжелым. Это сопряжено со временем, которые пакеты ожидают обработки. Если время ожидания в очереди превышает длительность таймаута, появятся дубликаты пакетов, что, безусловно, понижает эффективность системы. Причиной перегрузки может быть медленный процессор или недостаточная пропускная способность какого-то участка сети. Простая замена процессора или интерфейса на более быстродействующий не всегда решает проблему - чаще переносит узкое место в другую часть системы. Перегрузка, как правило, включает механизмы, усиливающие ее негативное воздействие. Так переполнение буфера приводит к потере пакетов, которые позднее должны будут переданы повторно (возможно даже несколько раз). Процессор передающей стороны получает дополнительную паразитную загрузку. Все это указывает на то, что контроль перегрузки является крайне важным процессом. Следует делать различие между контролем потока и контролем перегрузки. Под контролем потока подразумевается балансировка потока отправителя и возможности приема и обработки получателя. Этот вид контроля предполагает наличие обратной связи между получателем и отправителем. В этом процессе участвуют, как правило, только два партнера. Перегрузка же более общее явление, относящееся к сети в целом или к какой-то ее части. Например, 10 ЭВМ хотят передать одновременно какие-то файлы другим 10 ЭВМ. Конфликта потоков здесь нет, каждая из ЭВМ способна переработать поступающие данные, но сеть не может пропустить поток, генерируемый 10 сетевыми интерфейсами одновременно. Часто эти явления не так просто разделить. Отправитель может получить сообщение ICMP (quench) (в случае TCP/IP) при перегрузке получателя или при перегрузке какого-то сегмента сети. Начинать надо с решения проблемы выявления перегрузок. Перегрузкой следует считать ситуацию, когда нагрузка в течение некоторого оговоренного времени превышает заданную величину. Параметрами, которые позволяют судить о наличии перегрузки могут служить: Когда перегрузка выявлена, нужно передать необходимую информацию из точки, где она обнаружена, туда, где можно что-то сделать для исправления ситуации. Можно послать уведомление о перегрузке отправителю, загружая дополнительно и без того перегруженный участок сети. Альтернативой этому может быть применение специального поля в пакете, куда маршрутизатор может записать соответствующий код при перегрузке, и послать его соседям. Можно также ввести специальный процессор или маршрутизатор, который рассылает периодически запросы о состоянии элементов сети. При получении оповещения о перегрузки информационный поток может быть послан в обход. При использовании обратной связи путем посылки сообщения-запроса понижения скорости передачи следует тщательно настраивать временные характеристики. В противном случае система либо попадает в незатухающий осциллятивный режим, либо корректирующее понижение потока будет осуществляться слишком поздно. Для корректного выбора режима обратной связи необходимо некоторое усреднение. Преодоление перегрузки может быть осуществлено понижением нагрузки или добавлением ресурсов приемнику. Положительный результат может быть достигнут изменением механизма подтверждения (например, уменьшением размера окна), вариацией значений таймаутов, вариацией политики повторной передачи пакетов. В некоторых случаях позитивный результат может быть получен изменением схемы буферизации. Иногда решить проблему может маршрутизатор, например, перераспределяющий трафик по нескольким направлениям. Одной из причин перегрузки часто являются импульсные загрузки сегмента сети или сетевого устройства. По этой причине любые меры (напр., pipelining), которые могут выравнять поток пакетов, безусловно улучшат ситуацию (например, traffic shaping в сетях ATM). В TCP же с его окнами импульсные загрузки предопределены. Алгоритм leaky bucket ("дырявое ведро") Для систем без обратной связи решение проблемы выравнивания скорости передачи данных может быть решено с помощью алгоритма leaky bucket. Суть этого алгоритма заключается в том, что на пути потока устанавливается буфер выходной поток которого постоянен и согласован с возможностью приемника. Если буфер переполняется, пакеты теряются. Потеря пакетов вещь мало приятная, но это блокирует процессы, которые могут привести к коллапсу сегмента или всей сети. Там, где потеря пакетов нежелательна, можно применить более гибкий алгоритм. Алгоритм Token Bucket ("маркерное ведро") Алгоритм token bucket предполагает наличие в буферном устройстве (или программе) некоторого количества маркеров. При поступлении на вход буфера пакетов маркеры используются для их транспортировки на выход. Дальнейшая передача данных на выход зависит от генерации новых маркеров. Поступающие извне пакеты тем временем накапливаются в буфере. Таким образом, полной гарантии отсутствия потерь мы не имеем и здесь. Но алгоритм token bucket позволяет передавать на выход "плотные" группы пакетов ограниченной численности (по числу маркеров), снижая в некоторых случаях вероятность потери. Если буферное устройство "смонтировано" внутри ЭВМ-отправителя, потерь можно избежать вовсе, блокируя передачу при заполнении буфера. Как в одном так и в другом алгоритме мерой передаваемой информации может быть не пакет, а n-байт (где n некоторое оговоренное заранее число). В системах, где управление трафиком осуществляется с использованием обратной связи, можно достичь большей эффективности. Одним из механизмов преодоления перегрузок является управление разрешением (admission control). Суть метода заключается в том, что при регистрации перегрузки не формируется более никаких виртуальных соединений до тех пор, пока ситуация не улучшится. Альтернативным вариантом может служить решение, где формирование нового соединения разрешается, но при этом осуществляется маршрутизация так, чтобы обойти узлы, в которых выявлена перегрузка (смотри рис. 4.7 ).
Рис. 4.7. Выбор маршрута нового виртуального канала при наличии перегрузки На рис. 4.7 (верх) показан пример сети с двумя узлами, характеризующимися перегрузкой (помечены красным цветом). Предположим, что необходимо проложить виртуальный канал из узла А в узел Б. Из графа маршрутов удаляются перегруженные узлы, после чего осуществляется прокладка пути. В нижней части рисунка синим цветом показан новый виртуальный канал. Еще более универсальным решение, пригодным для работы с установлением соединения и без, является посылка пакетов блокировки (choke packets). Маршрутизатор обычно контролирует загруженность всех своих внешних каналов l, которая может принимать значения от 0 до 1. Когда l достигает некоторого порогового значения, отправителю посылается пакет блокировки. При вычислении l следует использовать какую-либо методику усреднения, чтобы избежать слишком частых блокировок. Когда отправитель получает пакет блокировки, он должен уменьшить трафик, посылаемый получателю на заданное число процентов. Так как на пути к месту назначения может быть много пакетов, это вызовет серию пакетов блокировки. Отправитель должен игнорировать пакеты блокировки в течение некоторого времени после получения первого такого пакета. По истечении этого периода отправитель прослушивает канал на протяжении аналогичного времени, ожидая получения новых пакетов блокировки. Если такой пакет приходит, канал все еще перегружен и отправитель снова должен понизить темп посылки пакетов. Если на протяжение периода прослушивания не приходит новых пакетов блокировки, отправитель может увеличить поток снова. ЭВМ может понижать трафик, корректируя свои параметры, например, ширину окна или темп передачи на выходе устройства типа "дырявое ведро". Обычно первый блокирующий пакет уменьшает поток вдвое, следующий на 0,25 от первичного и т.д. Увеличение потока также производится аналогичными шагами. Существует большое число вариантов алгоритма управления потоком с использованием пакетов блокировки. Параметром, который контролируется и определяет условие отправки пакета блокировки, может служить длина очереди или заполненность буфера. Ситуация перегрузки не всегда управляется однозначно. Например, при поступлении на вход пакетов от трех источников возможна ситуация, когда приемник посылает блокирующие пакеты всем отправителям, а откликнется сокращением потока только один. В результате этот узел, который "играет по правилам" (как это часто бывает и в жизни) оказывается в проигрыше. В 1987 году Нагле был предложен алгоритм fair queueing (честная очередь). В этом алгоритме маршрутизатор организует независимые очереди для пакетов, поступающих от разных источников. Когда выходной канал маршрутизатора оказывается свободным, он просматривает очереди циклически и отравляет очередной пакет. В результате при n очередях по завершении такого цикла просмотров-посылок оказываются посланы по одному пакету из каждой очереди. Такой алгоритм используется в некоторых ATM-переключателях. Следует заметить, что этот алгоритм дает некоторые преимущества тем узлам, которые посылают более длинные пакеты. Демерс (Demers) и др. в 1990 году предложил некоторое усовершенствоввание алгоритма. В данном варианте организуется циклический просмотр очередей не по-пакетно, а по-байтно. Система последовательно сканирует очереди и определяет положение концов пакетов. Первыми отправляются более короткие пакеты. Для иллюстрации предлагается рассмотреть рис. 4.8. (см. также [39])
Рис. 4.8. Маршрутизатор с 4-мя входными каналами, в каждом из которых ждет очереди передачи по одному пакету. В правой части рисунка представлен порядок посылки этих пакетов. Пакеты на рисунке имеют от трех до девяти октетов. Порядок пересылки октетов показан в левой части рисунка. В отсутствии поступления новых пакетов, кадры, записанные в буфер будут переданы в порядке, представленном в правой части рисунка. Особенностью этого алгоритма является равенство приоритета всех входных каналов. При передаче данных на большие расстояния с большими значениями RTT эффективность использования метода блокирующих пакетов снижается. Пока блокирующий пакет дойдет через ряд промежуточных узлов до отправителя, на вход получателя поступит большое число пакетов, которые не только усугубят ситуацию перегрузки, но и могут вызвать потерю какой-то их доли, что, в свою очередь, может потребовать повторной пересылки следовавших за ними кадров. Для повышения эффективности часто применяется схема, при которой блокирующие пакеты воздействуют на все маршрутизаторы по пути своего следования. В этом случае снижения потока можно ожидать уже чарез время, равное RTT до узла, ближайшего к получателю пакетов. Такая схема требует того, чтобы все промежуточные узлы имели достаточно емкие буферы, в противном случае возможны потери. В протоколе TCP используется алгоритм управления трафиком, называемый "скользящее окно". Здесь размер окна, которое определяет число сегментов, посылаемых без получения подтверждения, варьируется в зависимости от наличия потерь пакетов. При большой вероятности потери система переходит в режим, когда очередной пакет не посылается до тех пор, пока не будет подтверждено получение предшествующего. При серьезных перегрузках, когда потери становятся значительными, нарушается механизм вычисления значений RTT и таймаутов, что может приводить к трудно предсказуемым последствиям. Следует обратить внимание, что в протоколе UDP какого-либо механизма управления трафиком не предусмотрено. По этой причине для некоторых мультимедийных задач, следует предусматривать другие, например, ICMP-способы подавления перегрузки. В приложениях типа NFS, где используется UDP, для подавления перегрузки используется упомянутый выше ICMP-механизм. К сожаления в ряде мультимедийных приложений потеря пакетов не контролируется (например IP-телефония). Там шлюз 100-10Мбит/с может восприниматься как канал с вероятностью потери пакета 90%. Если другие способы испробованы, а перегрузка не исчезла, маршрутизатор начинает отбрасывать приходящие пакеты, которые уже не может обработать. Самое простое - это предоставить случаю выбор отбрасываемых пакетов. Но это не лучшая тактика. В случае пересылки мультимедийных данных предпочтение следует делать для последних полученных пакетов, а "старые" пакеты выбрасывать. При передаче файлов наоборот "старый" пакет имеет приоритет, ведь если его отбросить, придется повторно передавать не только его, но и все последующие пакеты. Некоторые методы передачи изображения требуют передачи время от времени всего кадра с последующей пересылкой только фрагментов, где произошли изменения. В таких условиях потеря пакета, составляющего базовый кадр, менее желательна. Сходные обстоятельства могут возникать и в других приложениях. Можно помечать пакеты, присваивая им определенные уровни приоритетов, что позволит осознанно принимать решение об отбрасывании того или иного пакета в условиях перегрузки. В перспективе проблема может быть решена на чисто коммерческой основе - компонента трафика, помеченная как высоко приоритетная, будет оплачиваться по более высокому тарифу. В некоторых сетях определенное количество пакетов объединяется в группы, образующие сообщение. Если одна ячейка такого сообщения выбрашена, все сообщение будет повторно переслано (смотри, например, адаптационные уровни сетей ATM). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
3.6 Протокол G.703
UP:
3 Каналы передачи данных
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
4.1.1.1 Архитектура сетей Ethernet
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||
Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации. К этой разновидности относится и Ethernet (10 Мбит/с ╠0,01%). Фирма Ксерокс осуществила разработку протокола Ethernet в 1973 году, а в 1979 году объединение компаний Ксерокс, Интел и DEC (DIX) предоставило документ для стандартизации протокола в IEEE. Предложение с небольшими изменениями было принято комитетом 802.3 в 1983 году. Кадр Ethernet имеет формат, показанный на рис. 4.1.1.1.1.
Рис. 4.1.1.1.1 Формат кадра сетей ethernet (цифры в верхней части рисунка показывают размер поля в байтах) Поле преамбула содержит 7 байт 0хАА и служит для стабилизации и синхронизации среды (чередующиеся сигналы CD1 и CD0 при завершающем CD0), далее следует поле SFD (start frame delimiter = 0xab), которое предназначено для выявления начала кадра. Поле EFD (end frame delimiter) задает конец кадра. Поле контрольной суммы (CRC - cyclic redundancy check), также как и преамбула, SFD и EFD, формируются и контролируются на аппаратном уровне. В некоторых модификациях протокола поле efd не используется. Пользователю доступны поля, начиная с адреса получателя и кончая полем информация, включительно. После crc следует межпакетная пауза (IPG - interpacket gap - межпакетный интервал) длиной 9,6 мксек или более. Максимальный размер кадра равен 1518 байт (сюда не включены поля преамбулы, SFD и EFD). Интерфейс просматривает все пакеты, следующие по кабельному сегменту, к которому он подключен, ведь определить, корректен ли принятый пакет и кому он адресован, можно лишь приняв его целиком. Корректность пакета по CRC, по длине и кратности целому числу байт производится после проверки адреса места назначения. Вероятность ошибки передачи при наличии crc контроля составляет ~2-32. При вычислении CRC используется образующий полином: G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1. Алгоритм вычисления CRC сводится к вычислению остатка от деления кода M(x), характеризующего кадр, на образующий полином G(x) (Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specification. Published by IEEE (802.3-1985). Wiley-Interscience, John & sons, inc.). CRC представляет собой дополнение полученного остатка R(x). CRC пересылается, начиная со старших разрядов. Схема взаимодействия различных субуровней при реализации протокола IEEE 802.3 показана на рис 4.1.1.1.2. Выше llc размещаются верхние субуровни, включая прикладной. Через AUI данные передаются с использованием манчестерского кода.
Рис. 4.1.1.1.2. Схема взаимодействия субуровней 802.3 (CSMA/CD) Манчестерский код объединяет в бит-сигнале данные и синхронизацию. Каждый бит-символ делится на две части, причем вторая часть всегда является инверсной по отношению первой. В первой половине кодируемый сигнал представлен в логически дополнительном виде, а во второй - в обычном. Таким образом, сигнал логического 0 - CD0 характеризуется в первой половине уровнем HI, а во второй LO. Соответственно сигнал CD1 характеризуется в первой половине бит-символа уровнем LO, а во второй - HI. Примеры форм сигналов при манчестерском кодировании представлены на рис. 4.1.1.1.3.
Рис. 4.1.1.1.3 Примеры кодировки с использованием манчестерского кода Ниже в таблице 4.1.1.1.1 приведены ограничения, налагаемые на сеть Ethernet в целом и на отдельные ее фрагменты. Таблица 4.1.1.1.1. Возможности различных схем реализации ethernet
Из таблицы видно, что максимальная задержка в сети ethernet складывается из:
В сумме это соответствует ~220 бит-тактам. Минимальная длина пакета должна быть больше удвоенного значения этой задержки (выбрано 64 байта = 512 тактов). Если размер пакета меньше 64 байт, добавляются байты-заполнители, чтобы кадр в любом случае имел соответствующий размер. При приеме контролируется длина пакета и, если она превышает 1518 байт, пакет считается избыточным и обрабатываться не будет. Аналогичная судьба ждет кадры короче 64 байт. Любой пакет должен иметь длину, кратную 8 бит (целое число байт). Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Формат адреса получателя или отправителя (MAC) показан на рис. 4.1.1.1.4. Для передачи данных на физическом уровне используется манчестерский код.
Рис. 4.1.1.1.4. Формат mac-адреса В верхней части рисунка указана длина полей адреса, в нижней - нумерация разрядов. Субполе I/G представляет собой флаг индивидуального или группового адреса. I/G=0 - указывает на то, что адрес является индивидуальным адресом сетевого объекта. I/G=1 характеризует адрес как мультикастинговый, в этом случае дальнейшее разбиение адреса на субполя теряет смысл. Субполе UL является флагом универсального или местного управления (определяет механизм присвоения адреса сетевому интерфейсу). U/L=1 указывает на локальную адресацию (адрес задан не производителем и ответственность за уникальность лежит на администраторе LAN). U/L=I/G=0 характерно для стандартных уникальных адресов, присваиваемых интерфейсу его изготовителем. Субполе OUI (organizationally unique identifier) позволяет определить производителя сетевого интерфейса. Каждому производителю присваивается один или несколько OUI. Размер субполя позволяет идентифицировать около 4 миллионов различных производителей. За корректность присвоения уникального адреса интерфейса (OUA - organizationally unique address) несет ответственность производитель. Двух интерфейсов одного и того же производителя с идентичными номерами не должно существовать. Размер поля позволяет произвести примерно 16 миллионов интерфейсов. Комбинация oui и oua составляют UAA (universally administrated address = IEEE-адрес). Если в поле кадра протокол/тип записан код менее 1500, то это поле характеризует длину кадра. В противном случае - это код протокола, пакет которого инкапсулирован в кадр Ethernet. Доступ к каналу Ethernet базируется на алгоритме CSMA/CD (carrier sense multiple access with collision detection). В Ethernet любая станция, подключенная к сети, может попытаться начать передачу пакета (кадра), если кабельный сегмент, к которому она подключена, свободен. Свободен ли сегмент, интерфейс определяет по отсутствию "несущей" в течение 9,6 мксек. Так как первый бит пакета достигает остальных станций сети не одновременно, может случиться, что попытку передачи совершат две или более станций, тем более что задержки в повторителях и кабелях могут достигать достаточно больших величин. Такие совпадения попыток называются столкновениями. Столкновение (коллизия) распознается по наличию в канале сигнала, уровень которого соответствует работе двух или более трансиверов одновременно. При обнаружении столкновения станция прерывает передачу. Возобновление попытки может быть произведено после выдержки (кратной 51,2 мксек, но не превосходящей 52 мсек), значения которой является псевдослучайной величиной и вычисляется каждой станцией независимо (t= RAND(0,2min(n,10)), где n - содержимое счетчика попыток, а число 10 - backofflimit). После выдержки станция увеличивает на единицу счетчик попыток и начинает очередную передачу. Предельное число попыток по умолчанию равно 16, если число попыток исчерпано, связь прерывается и выдается соответствующее сообщение. Передаваемый длинный кадр способствует "синхронизации" начала передачи пакетов несколькими станциями. Ведь за время передачи с заметной вероятностью может возникнуть необходимость передачи у двух и более станций. В момент, когда они обнаружат завершение пакета, будут включены таймеры IPG. К счастью информация о завершении передачи пакета доходит до станций сегмента не одновременно. Но задержки, с которыми это связано, являются также причиной того, что факт начала передачи нового пакета одной из станций не становится известным немедленно. При вовлечении в столкновение нескольких станций они могут уведомить остальные станции об этом, послав сигнал "затора" (jam - не менее 32 бит). Содержимое этих 32 бит не регламентируется. Такая схема делает менее вероятным повторное столкновение. Источником большого числа столкновений (помимо информационной перегрузки) может служить запредельная суммарная длина логического кабельного сегмента, слишком большое число повторителей, обрыв кабеля, отсутствие терминатора (50-омного согласователя кабеля) или неисправность одного из интерфейсов. Но сами по себе столкновения не являются чем-то негативным - это механизм, регулирующий доступ к сетевой среде. Под логическим кабельным сегментом (иногда называемым областью столкновений) подразумевается один или несколько кабельных сегментов, объединенных повторителями. Анализ столкновений является одним из средств эффективной диагностики сети. Локальные столкновения (столкновения на сегменте, к которому непосредственно подключена рабочая станция) порождают укороченные пакеты-фрагменты (ведь их передача прерывается) с длиной менее 64 октетов. Большинство трансиверов и репитеров имеют на своих передних панелях индикаторы столкновений. Блок-схема реализации протокола CSMA/CD показана на рис. 4.1.1.1.4. Особое внимание я бы хотел обратить на влияние сигнала jam. В процессе пересылки столкнувшихся пакетов и за время передачи сигнала jam другие узлы могли захотеть что-то передать. Если таких узлов больше одного, то это приведет к синхронизации начала передачи этими узлами и к увеличению вероятности столкновения. Практически такую "синхронизацию" может осуществить любой достаточно длинный пакет. Такая синхронизация является причиной "коллапса" сети при большой загрузке.
Рис. 4.1.1.1.5 Блок-схема реализации алгоритма доступа к сетевой среде CSMA/CD Метод CSMA/CD создает неопределенность времени доступа к сети, что делает ее неудобной для решения некоторых задач управления в реальном масштабе времени, где требуется малое время реакции системы на внешнее воздействие.
Рис. 4.1.1.1.6 Схема некоторых возможных вариантов подключения рабочих станций к Ethernet Исторически первой появилась схема подключения к толстому 50-омному коаксиальному кабелю (сегмент 1 на рис. 4.1.1.1.6; Z=50 ╠2 Ом) через трансивер и многожильный кабель типа AUI (attachment unit interface, максимальная длина 50 м). Трансивер подключается к кабелю методом "наколки", то есть во внешней оплетке и изоляции сверлится с помощью специального инструмента отверстие и через него осуществляется контакт трансивера с центральной жилой кабеля и экраном. Кабель по возможности не должен содержать сросток, в противном случае его предельная длина должна быть сокращена. Кабельный сегмент должен быть согласован с обоих сторон с помощью терминаторов (50 Ом ╠1%). Позднее стала популярной схема соединений через тонкий коаксиальный кабель и t-образные коаксиальные разъемы (волновое сопротивление 50 Ом). В настоящее время наибольшее применение находит схема со специальными многовходовыми повторителями-концентраторами (Hub) и подключением оконечного оборудования через скрученные пары. Для подключения используется 8-контактный разъем RJ-45 (см. приложение 10.17 Разводка разъемов). Этому способствует удешевление категорированных скрученных пар, соответствующих повторителей, а также большая надежность и лучшая ремонтоспособность таких сетей. Следует иметь в виду, что предельные длины для коаксиальных кабелей, приведенные в таблице 4.1.1.1.1 относятся к зарубежным типам, в частности в случае тонкого кабеля - это rg-58. Отечественные разновидности кабеля, например РК-50-2-11, допускают (при максимальной загрузке) длины примерно в 1,3-1,5 раз меньше. Это связано с меньшим сечением центральной жилы и большей вариацией волнового сопротивления. Если же число ЭВМ подключенных к кабельному сегменту много меньше предельного, допускается использование и запредельных длин кабельных сегментов, но это не рекомендуется. Пропускная способность сети с методом доступа csma/cd снижается по мере роста загрузки из-за увеличения вероятности столкновений. По этой причине даже использование 100-мегагерцного ethernet не может гарантировать большей пропускной способности (по сравнению с обычным, см. рис. 4.1.1.1.8) при условии высоких загрузок и, как следствие, высоких вероятностей столкновений. ethernet-интерфейс перед началом передачи контролирует состояние кабельного сегмента (наличие несущей), выжидает некоторое время, если сегмент занят, после чего производит попытку передачи с контролем возможности столкновения. Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Схема интерфейса на уровне mau в упрощенном виде имеет вид, показанный на рис. 4.1.1.1.7.
Рис. 4.1.1.1.7. Схема интерфейса на уровне mau Схема signal quality регистрирует коллизии и другие искажения сигнала и выдает в этом случае флаг SQE (signal quality error). sqe представляет собой сигнал CS0, посылаемый от MAU к DTE (точнее PMA к PLS, см. рис. 4.1.1.1.2). Сигнал SQE посылается mau также в случае завершения процесса передачи (output_idle). Узел isolate служит для блокировки передачи данных в сетевую среду, при этом DTE передает mau сигнал CS0. Суммарная емкостная нагрузка, вносимая mau, не должна превышать 4 пф. Входное сопротивление должно быть более 100 ком, а ток утечки должен лежать в пределах +2 мкА -25мкА. Выходной драйвер mau при передаче выдает в кабель -90 ╠4мa (эквивалентно -2,05В на нагрузке 25 Ом). Предельное ослабление сигнала на длине 500 м не должно превышать 8,5 дБ (на частоте 10МГц). При передаче сигнал распространяется в обоих направлениях по кабелю от точки подключения интерфейса. При использовании тонкого кабеля интерфейс должен иметь максимально большое входное сопротивление и минимально возможную входную емкость, чтобы вносить минимальные искажения для сигналов, распространяющихся по сегменту. В случае работы со скрученными парами на "кабельный сегмент" подключается только один интерфейс. Максимальное время прохождения сигнала между узлами сети, принадлежащих одному сегменту, называется окном коллизий и является важной рабочей характеристикой. Помимо столкновений в сети может быть зарегистрировано появление ложной несущей (FCE - false carrier event) - битовая последовательность не имеет байта SFD, соответствующего конкретному типу физической среды. Появление ложной несущей обычно связано с состоянием кабеля или шумами. Если фиксируется появление двух ложных несущих подряд, повторитель должен отключить порт (перевести в состояние link unstable) и послать сигнал jam во все остальные порты. Сигнал jam должен продолжаться до конца потока данных, вызвавшего появление ложной несущей. Если канал восстановлен, повторитель переводит порт в нормальное состояние. Отключение порта возможно также при возникновении множественных коллизий (ECE - excessive collision error) - более 60 коллизий подряд. После блокировки порта он будет восстановлен, если в течении 500 тактов коллизии не обнаружены или при повторном включении повторителя. Если рассмотреть зависимость пропускной способности сети L от ее суммарной загрузки Lin, мы для Ethernet получим кривую, показанную на рис. 4.1.1.1.8.
Рис. 4.1.1.1.8. Зависимость пропускной способности l in сети со схемой доступа CSMA/CD от суммарной загрузки l Вначале эта зависимость линейна и на участке А пропускная способность удовлетворительна. Но при больших входных загрузках из-за коллизий сначала наступает насыщение, а затем и резкий спад (Ethernet collapse). Это свойство сетей с CSMA/CD дает определенные преимущества сетям с маркерным доступом: Token Ring, FDDI и др.. При диагностировании сетей не всегда под руками может оказаться настоящий сетевой тестер типа Wavetek, и часто приходится довольствоваться обычным авометром. В этом случае может оказаться полезной таблица 4.1.1.1.2, где приведены удельные сопротивления используемых сетевых кабелей. Произведя измерение сопротивления сегмента, вы можете оценить его длину. Таблица 4.1.1.1.2 Сопротивление кабеля по постоянному току
Данные, приведенные в таблице, могут использоваться для оперативной предварительной оценки качества кабельного сегмента (соответствует стандарту EIA/TIA 568, 1991 год). Помимо уже описанных модификаций сетей ethernet в последнее время получили распространение сети для частот 100 Мбит/с, которые базируются на каналах, построенных из скрученных пар или оптоволоконных кабелей. Оптические связи используются и в обычном 10-мегагерцном ethernet (10base-FL, стандарт разработан в 1980 году, см. рис. 4.1.1.1.9). Оптоволоконная версия ethernet привлекательна при объединении сегментов сети, размещенных в различных зданиях, при этом увеличивается надежность сети, так как ослабляется влияние электромагнитных наводок, исключается влияние различия потенциалов земли этих участков сети. Облегчается переход от 10- к 100-мегагерцному Ethernet, также можно использовать уже имеющиеся оптоволоконные каналы, ведь они будут работать и на 100 Мбит/с (возможна реализация сетей со смешанной структурой, где используется как 100- так и 10-мегагерцное оборудование). На программном уровне 10- и 100-МГц ethernet не различимы. Требования к параметрам опто-волоконных кабелей не зависят от используемого протокола (FDDI, Token Ring, Fast Ethernet и т.д.) и определяются документом EN 50173 (European norm). Это утверждение не относится к топологии кабельных связей, которые в общем случае зависят от используемого протокола. При работе с оптоволоконными системами необходимы специальные тестеры, способные измерять потери света и отражения методом OTDR (рефлектометрия с использованием метода временных доменов). При пассивной звездообразной схеме длины оптоволоконных сегментов могут достигать 500 метров, а число подключенных ЭВМ - 33. Для передачи сигналов используются многомодовые волокна (MMF) с диаметром ядра 62,5 микрон и клэдинга 125 микрон. Длина волны излучения равна 850 (или 1350) нанометров при ослаблении сигнала в кабельном сегменте не более 12,5 дБ. Обычный кабель имеет ослабление 4-5 дБ/км. Оптические разъемы должны соответствовать требования стандарта ISO/IEC BFOC/2,5 и вносить ослабление не более 0,5 - 2,0 дБ. Количество используемых mau в логическом сегменте не должно превышать двух.
Рис. 4.1.1.1.9. Схема 10-мегагерцного оптоволоконного Ethernet. На данном рисунке видно, что соединения повторителя с FOMAU является дуплексным, аналогичные возможности предоставляют многие современные переключатели. Полно дуплексное подключение оборудование во многих случаях может обеспечить практическое удвоение скорости обмена и, что возможно более важно, исключить столкновения пакетов. Схема полно дуплексного соединения показана на рис. 4.1.1.1.10.
Рис. 4.1.1.1.10. Схеме реализации полно дуплексного канала Ethernet. (Буква К с цифрой отмечает номера ножек контактов разъема) При практической реализации локальной сети обычно возникает проблема защиты и заземления. Если этой проблеме не уделить внимание в самом начале она даст о себе знать позднее и обойдется ее решение дороже. Можно выделить три аспекта. Безопасность персонала, работающего с ЭВМ и сетевым оборудованием, устойчивость к внешним наводкам и помехам, а также безопасность самого сетевого оборудования (противостояние грозовым разрядам или резким скачкам в сети переменного тока (обычно ~220 В)). Безопасность персонала обеспечивается тем, что все объекты, за которые может взяться человек, должны иметь равные потенциалы и в любом случае разница потенциалов не должна превышать 50 вольт. При работе с коаксиальным кабелем существуют рекомендации его заземления в одной точке. Возникает вопрос, что делать с заземлением экранов в случае использования экранированных скрученных пар? Этой проблеме посвящена, например, статья в журнале LANline Special Juli/August 2002 страницы 27-32. Следует сразу заметить, что нужно избегать совмещения применения экранированных и неэкранированных скрученных пар в пределах одной системы. Представляется также естественной и разумной зонная концепция, рассматриваемая в упомянутой статье. На рис. 1. показана схема защиты. Эта схема содержит защитные выключатели на случай грозы или бросков напряжения (линия L). Буквой N обозначена нулевая (нейтральная) шина, а буквами PE - защитная шина.
Рис. 4.1.1.1.11. Схема защиты для случая использования экранированных скрученных пар
Рис. 4.1.1.1.12. Зоны заземлений Земли-экраны соседних зон соединяются только в одной точке. Между зонами могут включаться пограничные устройства фильтрации, предназначенные для снижения уровня шумов и помех. В пределах зоны все устройства должны быть эквипотенциальны. Это достигается за счет подключения к общему экрану. |
||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.1.1 Ethernet (IEEE 802.3)
UP:
4.1.1 Ethernet (IEEE 802.3)
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.1.1.2 Fast Ethernet
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
100-мегагерцную сеть ethernet дешевле создать на базе скрученных пар. Существует несколько версий 100-мегагерцного ethernet ( 100base-T4, 100base-TX, 100base-FX, стандарт 100VG-anylan - IEEE 802.12). TX и RX передатчики и приемники входных/выходных оптоволоконных трансиверов, соответственно. FOMAU - (fiber optic media attachment unit) оптоволоконный трансивер (см. рис. 4.1.1.1.9). Сегменты T4 (100base-T4) используют четыре скрученные пары телефонного качества (экранированные и неэкранированные скрученные пары проводов категории 3, 4 или 5) длиной до 100м. Провода должны быть скручены по всей длине, скрутка может быть прервана не далее как в 12мм от разъема (это требование справедливо и для сегментов типа TX). Сегменты TX (100base-TX, стандарт ANSI TP-PMD) состоят из двух скрученных пар проводов информационного качества (волновое сопротивление 100-150 Ом, экранированные и неэкранированные скрученные пары проводов категории 5, длина до 100м). FX-сегменты (100base-FX) представляют собой оптоволоконные кабели, отвечающие требованиям стандарта ANSI. Мультимодовое волокно 62,5/125 m (см. выше) работает в инфракрасном диапазоне 1350нм. Максимальная длина сегмента составляет 412 метров, ограничение определяется соображениями допустимых задержек. Предельное ослабление сигнала в волокне не должно превышать 11 дБ, стандартный кабель имеет 1-5 дБ/км. Оптические разъемы должны отвечать тем же требованиям, что и разъемы, используемые в FDDI-сетях (MIC- Media Interface Connector). Для того, чтобы выявить, к какой модификации относится тот или иной сегмент, разработан специальный протокол распознавания, позволяющий строить сети, которые содержат оборудование и кабельные сегменты, отвечающие разным требованиям. Универсальная схема подключения ЭВМ или любого другого оборудования (например, сетевого принтера) к 100-мегагерцному ethernet показана на рис. 4.1.1.2.1. Физическая среда служит для передачи сигналов Ethernet от одной ЭВМ к другой. Выше были перечислены три вида физических сред, используемых 100-мегагерцным Ethernet (T4, TX и FX). Здесь используется 8-контактный разъем (RJ-45) для скрученных пар или специальный оптоволоконный соединитель. Блок PHY выполняет ту же функцию, что и трансивер в 10-мегагерцном Ethernet. Он может представлять собой набор интегральных схем в сетевом порту или иметь вид небольшой коробочки на MII-кабеле. Интерфейс MII является опционным, он может поддерживать работу с 10- и 100-мегагерцным ethernet. Задачей MII является преобразование сигналов, поступающих от PHY, в форму, приемлемую для стандартного набора ИС Ethernet. Соединительный кабель не должен быть длиннее 0,5м. PHY и MII могут быть объединены на одной интерфейсной плате, вставляемой в ЭВМ.
Рис. 4.1.1.2.1 Блок-схема подключения оборудования к 100-мегагерцному Ethernet В сетях 100-мегагерцного Ethernet используются повторители двух классов (I и II). Задержки сигналов в повторителях класса I больше (~140нс), зато они преобразуют входные сигналы в соответствии с регламентациями применяемыми при работе с цифровыми кодами. Такие повторители могут соединять каналы, отвечающие разным требованиям, например, 100base-TX и 100base-T4 или 100base-FX. Преобразование сигнала может занимать время, соответствующее передаче нескольких бит, поэтому в пределах одного логического сегмента может быть применен только один повторитель класса I, если кабельные сегменты имеют предельную длину. Повторители часто имеют встроенные возможности управления с использованием протокола SNMP. Повторители класса II имеют небольшие задержки (~90нс или даже меньше), но никакого преобразования сигналов здесь не производится, и по этой причине они могут объединять только однотипные сегменты. Логический сегмент может содержать не более двух повторителя класса II, если кабели имеют предельную длину. Повторители класса II не могут объединять сегменты разных типов, например, 100base-TX и 100base-T4. Согласно требованиям комитета IEEE время задержки сигнала jam в повторителе Fast Ethernet (TX и FX) не должно превышать 460 нсек, а для 100base-T4 - 670 нсек. Для повторителей класса I эта задержка не должна быть больше 1400 нсек. Значения предельных длин сегментов для различных конфигураций сети приведены в таблице 4.1.1.2.1. Таблица 4.1.1.2.1. Максимальные размеры логического кабельного сегмента
Типовые задержки для различных устройств Fast Ethernet представлены в табл. 4.1.1.2.2. Таблица 4.1.1.2.2
Вариант построения 100-мегагерцной сети ethernet показан на рис. 4.1.1.2.2.
Рис. 4.1.1.2.2. Возможная схема 100-мегагерцной сети ethernet. Из рисунка видно, что максимальная длина логического сегмента не может превышать А+Б+В = 205 метров (см. табл. 4.1.1.2.3.). Предельно допустимые длины кабелей А и В приведены в табл. 4.1.1.2.3. Таблица 4.1.1.2.3. Максимально допустимые длины кабелей для сети, показанной на
рис. 4.1.1.2.2
При работе со скрученными парами (стандарт TX) используется 8-контактный разъем RJ-45 со следующим назначением контактов:
Если используются экранированные пары и 9-контактный разъем "d"-типа, то назначение контактов следующее:
Для стандарта 100base-T4 назначение контактов приведено в таблице 4.1.1.2.4. Таблица 4.1.1.2.4. Разъем MDI (media dependant interface) кабеля 100base-t4
Как видно из таблицы, одна пара предназначена для передачи (TX), одна для приема (RX) и две для двунаправленной передачи (BI). Знак полярности сигналов обозначен соответственно + и -. Уровень логической единицы +3,5 В (CS1), нуля - 0 В (CS0), а -1 соответствует -3,5 В (CS-1). Стандарт 100base-T4 предполагает применение схемы кодирования 8B6T. Алгоритм 8B6T преобразует октет данных в 6-битовый тернарный символ, который называется кодовой группой 6Т. Эти кодовые группы передаются параллельно по трем скрученным парам сетевого кабеля, что позволяет осуществлять обмен лишь со скоростью 33,33Мбит/с. Скорость же передачи тернарных символов по каждой из пар проводов равна 6/8 от 33,33 Мбит/с, что эквивалентно 25 МГц. Шесть тернарных символов позволяют отобразить 36=729 различных кодов. Это позволяет отобрать для отображения 256 восьмибитовых кодов те тернарные символы, которые обеспечивают не менее 2 перепадов уровня сигнала. Схема подключения и передачи сигналов в сетях 100base-T4 показана на рис 4.1.1.2.3. Пары 2 и 3 также как и в ТХ предназначены для приема и передачи данных. Пары 1 и 4 используются в двух направлениях, преобразуя канал между узлом и повторителем в полудуплексную. В процессе передачи узел использует пары 1, 2 и 4, а повторитель - пары 1, 3 и 4. Следует заметить, что схема Т4, в отличие от ТХ, может работать только в полудуплексном режиме.
Рис. 4.1.1.2.3. Схема подключения и передачи сигналов в сетях 100base-T4 (буквы К с цифрами обозначают номера контактов разъема) В сетях Fast Ethernet максимальное значение окна коллизий равно 5,12 мксек и называется временем канала (slot time). Это время в точности соответствует минимальной длине пакета в 64 байта. Для более короткого пакета коллизия может быть не зафиксирована. Окно коллизий представляет собой время от начала передачи первого бита кадра до потери возможности регистрации коллизии с любым узлом сегмента, это время равно удвоенной задержке распространения сигнала между узлами (RTT). Конфигурация сети Fast Ethernet, для которой значение окна коллизий превышает время канала, не верна. Время канала задает величину минимального размера кадра и максимальный диаметр сети. Для пояснения этих взаимозависимостей рассмотрим сеть, показанную на рис. 4.1.1.2.4.
Рис. 4.1.1.2.4 Задержка повторителя складывается из задержек физического уровня обоих портов и собственно задержки повторителя. Задержка на физическом уровне сетевого интерфейса считается равной 250 нсек. Рассмотрим задержки сигнала для всех пар узлов (a, b и c) изображенной на рисунке сети:
Когда А передает кадр, узлы В и С отслеживают наличие несущей. Это продолжается до тех пор, пока А не завершит эту процедуру. Как только узлы В и С фиксируют окончание передачи кадра узлом А, они запускают свои таймеры IPG. Запускает свой таймер ipg и узел А, причем его таймер стартует первым. На рис. 4.1.1.2.5 показана временная диаграмма развития событий в сетевом сегменте. Таймер В стартует следующим через 1321 нсек после А. Таймер узла С стартует спустя 1805 нсек после А.
Рис. 4.1.1.2.5 Временная диаграмма, поясняющая возникновение коллизий (все времена в наносекундах) Узел В начинает передачу сразу после срабатывания его IPG-таймера, а через 484 наносекунды передачу начнет и узел С, так как канал с его точки зрения свободен. Но коллизии еще не происходит, так как их кадры еще не "столкнулись". Для того чтобы первый бит от узла В достиг узла С, требуется 1706 наносекунд. Узел С зарегистрирует столкновение первым, это произойдет в момент 3987нсек. После этого С будет продолжать передачу еще в течение 320 нсек (сигнал jam). Сигнал jam гарантирует регистрацию коллизии повторителем. Только спустя 484 нсек коллизию обнаружит узел В, начнет передачу своего сигнала jam после чего прекратит передачу. При этом предполагается, что jam не является контрольной суммой передаваемого пакета. Стандарт IEEE предусматривает возможность полнодуплексной связи при использовании скрученных пар или оптоволокна. Реализуется это путем выделения для каждого из направлений передачи независимого канала. Такая схема осуществляет связь типа точка-точка и при определенных условиях позволяет удвоить пропускную способность сети. Здесь нет нужды в стандартном механизме доступа к сетевой среде, невозможны здесь и столкновения. Дуплексную схему могут поддерживать все три модификации 100-мегагерцного Ethernet (100base-TX, 100base-T4 и 100base-FX). Для оптоволоконной версии дуплексной связи предельная длина сегмента может достигать 2 км (для полудуплексного варианта предельная длина сегмента может достигать 412 м). Следует иметь в виду, что для локальных сетей целесообразнее применение мультимодового оптоволокна (дешевле и больше коэффициент захвата света, но больше удельное поглощение). В настоящее время разрабатываются новые еще более скоростные варианты Ethernet IEEE 802.3z (гигабитный Ethernet утвержден в качестве стандарта в 1998 году; 1000base-FX; ftp:/stdsbbs.ieee.org/pub, смотри также www.gigabit-ethernet.org/technology/faq.html). Эти сети ориентированы на применения 4-х скрученных пар категории 5 (до 100м) и оптоволоконных кабелей. Применяется кодировка 8В/10b. Сетевые интерфейсы используют шину PCI. 10-Гигабитный Ethernet Хотя Ethernet на 1 Гбит/с и не использовал все свои возможности, реализован уже 10Гбитный Ethernet (IEEE 802.3ae, 10GBase-LW или 10GBase-ER). Этот стандарт утвержден в июне 2002 года и соответствует для в случае использования для построения региональных каналов спецификациям OC-192c/SDH VC-4-46c (WAN). Опробован канал длиной 200 км с 10 сегментами. Существует серийное сетевое оборудование обеспечивающее надежную передачу на скорости 10Гбит/с при длине одномодового кабеля 10 км ( l=1310 nm). Эти данные взяты из журнала "LANline" (www.lanline.de) N7, Juli 2002. При работе с оптическими волокнами могут применяться лазеры с вертикальными резонаторами и поверхностным излучением VCSEL (Vertical Cavity Surface Emitting Laser). В случае мультимодовых вариантов используются волокна с градиентом коэффициента преломления. В протоколе 10Гбит/c Ethernet предусмотрен интерфейс chip-to-chip (802.3ae-XAUI - буквы ае означают здесь Ethernet Alliance - www.10gea.org). Такие каналы могут использоваться и в LAN для соединения переключателей сетевых кластеров. Соединение организуется по схеме точка-точка. Эта технология удобна для использования в фермах ЭВМ. Стандартизованы порты: 10Gbase-LR (до 10 км по одномодовому волокну - для высокопроизводительных магистральных и корпоративных каналов), 10Gbase-ER (до 40 км по одномодовому волокну), 10Gbase-SR (до 28 м по мультимодовому волокну - для соединений переключателей друг с другом), а также 10Gbase-LХ4 (до 300 м по мультимодовому волокну стандарта FDDI - для сетей в пределах одного здания). Обсуждается возможность построения 100Гбит/c Ethernet. В 10Gbase для локальных сетей применяется кодирование 64В/66B (вместо 8В/10B, используемого в обычном гигабитном Ethernet), так как старая схема дает 25% увеличение паразитного трафика. Следует обратить внимание, что такое решение делает непригодными существующие оптоволоконные технологии SDH/SONET. К концу 2002 года технология 10Гбит-Ethernet вторглась в область региональных (MAN; смотри форум Metro-Ethernet и EFM Task Force) и даже межрегиональных (WAN) сетей, тесня SDH, Fibre Channel, OC-192, PCI Express и InfiniBand. В версии 10Gbase-X4 используется кодирование 8В/10B. Там формируется 4 потока по 3,125Гбит/с, которые передаются по одному волокну (1310нм) с привлечением техники мультиплексирования длин волн (WWDM). В случае 10Gbase-W на уровне МАС вводится большая минимальная длина IPG.
Рис. 4.1.1.2.6. Схема уровней для 10Gbase Ethernet
Таблица 4.1.1.2.5. Классификация категорий оптических волокон для сетевых приложений (данные взяты из журнала "LAN line Special" за июль-август 2002 года; www.lanline.de). Согласно принятым сокращениям буквы в конце обозначения канала (например, 10Gbase-LX) характеризуют оптическое волокно [E - Extended (для WAN или MAN, длина волны 1550нм), L - Long (для расстояний <10км при длине волны 1310нм, возможен вариант с многомодовым волокном длиной до 300м и привлечением техники WWDM) и S - Short (для расстояний менее 35 м при длине волны 850нм; для волокон с 160 МГц*км длина <28м, а для 200МГц*км < 35м)] и тип кодирования (R, W или X).
Всякая, даже гигантская сеть была когда-то маленькой. Обычно сеть начинается с одного сегмента типа 1, 3 или 4 (рис. 4.1.1.2.1). Когда ресурсы одного сегмента или концентратора (повторители для скрученных пар) исчерпаны, добавляется повторитель. Так продолжается до тех пор, пока ресурсы удлинения сегментов и каналы концентраторов закончатся и будет достигнуто предельное число повторителей в сети (4 для 10МГц-ного Ethernet). Если при построении сети длина кабельных сегментов и их качество не контролировалось, возможен и худший сценарий - резкое увеличение числа столкновений или вообще самопроизвольное отключение от сети некоторых ЭВМ. Когда это произошло, администратор сети должен понять, что время дешевого развития сети закончилось - надо думать о приобретении мостов, сетевых переключателей, маршрутизаторов, а возможно и диагностического оборудования. Применение этих устройств может решить и проблему загрузки некоторых сегментов, ведь в пределах одного логического сегмента потоки, создаваемые каждым сервером или обычной ЭВМ, суммируются. Не исключено, что именно в этот момент сетевой администратор заметит, что топология сети неудачна и ее нужно изменить. Чтобы этого не произошло, рекомендуется с самого начала тщательно документировать все элементы (кабельные сегменты, интерфейсы, повторители и пр.). Хорошо, если уже на первом этапе вы хорошо представляете конечную цель и те возможности, которыми располагаете. Бухгалтерская сеть и сеть, ориентированная на выход в Интернет, будут иметь разные структуры. Прокладывая кабели, рекомендуется учитывать, что положение ЭВМ время от времени меняется, и это не должно приводить к изменению длины сегмента или к появлению дополнительных "сросток". Следует также избегать применения в пределах сегмента кабелей разного типа и разных производителей. Если сеть уже создана, научитесь измерять информационные потоки в сегментах и внешние потоки (если ваша сеть соединена с другими сетями, например с Интернет), это позволит осмысленно намечать пути дальнейшей эволюции сети. Если возможности позволяют, избегайте использования дешевых сетевых интерфейсов, их параметры часто не отвечают требованиям стандарта. Сетевая архитектура требует немалых знаний и это дело лучше поручить профессионалам. Когда потоки данных в сети достигают уровня, при котором использование мостов и сетевых переключателей уже недостаточно, можно подумать о внедрении маршрутизаторов или оптоволоконных сегментов сети FDDI или быстрого (100 Мбит/с) Ethernet. Эти субсети будут играть роль магистралей, по которым идет основной поток данных, ответвляясь в нужных местах в субсети, построенные по традиционной технологии (см. раздел FDDI). Сеть FDDI для этих целей предпочтительнее, так как она не страдает от столкновений и у нее не падает пропускная способность при перегрузке. Если в вашей сети имеются серверы общего пользования, их рекомендуется подключить к быстродействующим сегментам и организовать несколько узлов доступа к FDDI-кольцу. Остальные потребители будут соединены с FDDI через эти узлы доступа (мосты/шлюзы). Аналогичную функцию могут выполнять и сегменты быстрого Ethernet (особенно хороши для этого схемы дуплексного обмена, см. выше). Особую проблему составляют переходы 100 Мбит/с ╝10 Мбит/с (рис. 4.1.1.2.7). Дело в том, что на MAC-уровне нет механизмов понижения скорости передачи для согласования возможностей отправителя и приемника. Такие возможности существуют только на IP-уровне (ICMP-congestion). Если функцию шлюза исполняет, например, переключатель, то исключить переполнение его буфера невозможно. Такое переполнение неизбежно приведет к потере пакетов, повторным передачам и, как следствие, к потере эффективной пропускной способности канала. Решить проблему может применение в качестве шлюза маршрутизатора (здесь работает ICMP-механизм "обратного давления").
Рис. 4.1.1.2.7 Схема переходов 10-100-10 Мбит/с Если любые 2 или более каналов справа попытаются начать работу с одним из каналов слева, или наоборот, потери пакетов неизбежны. Проблема исчезает, когда SW работают на IP-уровне. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.1.1.1 Архитектура сетей Ethernet
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
4.1.1.3 Интернет в Ethernet
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||
|
В Интернет не существует иерархии сетей. Локальная сеть на основе Ethernet, две ЭВМ, связанные через последовательный интерфейс, или общенациональная сеть страны - это все сети и по логике Интернет они все равны. Каждая сеть имеет свое имя и как минимум один IP-адрес. Имя привычнее для людей, адреса - для машин. Между именами и адресами существует строгое соответствие. Для того чтобы пояснить взаимодействие различных систем в сети, рассмотрим сильно упрощенную схему обработки команды telnet vxdesy.desy.de, которая предполагает осуществление удаленного доступа к vx-кластеру в ДЕЗИ, Гамбург (вызов через windows обрабатывается практически аналогично). Сначала ЭВМ выделяет команду telnet и запускает соответствующую программу. Эта программа рассматривает символьный адрес vxdesy.desy.de в качестве параметра команды telnet.
Рис. 4.1.1.3.1. Схема обработки сетевого запроса Сначала определим, что же нужно сделать для решения стоящей задачи? Чтобы обратиться к нужной ЭВМ, система должна знать ее IP-адрес, маску субсети и адрес маршрутизатора или ЭВМ, через которые можно обратиться с запросом на установление канала связи. Рассмотрим решение проблемы поэтапно. Сначала символьный адрес vxdesy.desy.de пересылается серверу имен (DNS-система может располагаться как в ЭВМ пользователя, так и в другой машине), где преобразуется в цифровой IP-адрес, пересылаемый в отклике на DNS-запрос (предварительно надо узнать его MAC-адрес). Но знания IP-адреса недостаточно, надо выяснить, где находится объект с этим адресом. На IP-адрес накладывается сетевая маска (задается при конфигурации рабочей станции), чтобы определить, не является ли данный адрес локальным. Если адрес локален, IP-адрес должен быть преобразован в Ethernet-адрес (MAC), ведь ваша ЭВМ может оперировать только с Ethernet-адресами. Для решения этой задачи посылается широковещательный (обращенный ко всем участникам локальной сети) ARP-запрос. Если адресат находится в пределах локальной субсети, то он откликнется, прислав Ethernet-адрес своей сетевой карты. Если это не так, что имеет место в приведенном примере, присылается Ethernet-адрес пограничного для данной сети маршрутизатора. Это происходит лишь в случае, если он поддерживает режим proxy-ARP. В противном случае рабочая станция должна воспользоваться IP-адресом маршрутизатора (gateway), заданным при ее конфигурации, и выявить его MAC-адрес с помощью ARP-запроса. Наконец с использованием полученного IP-адреса программа telnet формирует IP-пакет, который вкладывается в Ethernet-кадр и посылается в маршрутизатор узла (ведь именно его адрес она получила в ответ на ARP-запрос в данном примере). Последний анализирует имеющиеся у него маршрутные таблицы и выбирает, по какому из нескольких возможных путей послать указанный пакет. Если адресат внешний, IP-дейтограмма вкладывается в PPP- FDDI- или какой-то другой кадр (зависит от протокола внешнего канала) и отправляется по каналам Интернет. В реальной жизни все бывает сложней. Во-первых, присланный символьный адрес может быть неизвестен локальной dns-системе (серверу имен) и она вынуждена посылать запросы вышестоящим DNS-серверам, во-вторых, пограничный маршрутизатор вашей автономной системы может быть непосредственно не доступен (ваша ЭВМ находится, например, в удаленной субсети) и т.д. и т.п. Как система выпутывается из подобных осложнений, будет описано позднее. Следует иметь в виду, что, например, в системе unix все виды Интернет услуг обслуживает демон inetd. Конкретный запрос (Telnet, FTP, Finger и т.д.) поступает именно к нему, inetd резервирует номер порта и запускает соответствующий процесс, после чего переходит в режим ожидания новых запросов. Такая схема позволяет эффективно и экономно работать со стандартными номерами портов (см. раздел 7). Ну а теперь начнем с фундаментальных положений Интернет. В Интернет информация и команды передаются в виде пакетов, содержащих как исходящий адрес, так и адрес места назначения (IP-адрес имеет 32 двоичных разряда). Каждой ЭВМ в сети поставлен в соответствие уникальный адрес, появление двух объектов с идентичными IP-адресами может дезорганизовать сеть. IP-адресация поддерживает пять различных классов сетей (практически используется только три) и, соответственно, адресов (версия IPv4). Класс А предназначен в основном для небольшого числа очень больших сетей. Здесь для кода сети выделено только 7 бит, это означает, что таких сетей в мире не может быть больше 127 (27-1). Класс B выделяет 14 бит для кода сети, а класс С - 22 бита. В классе C для кода ЭВМ (host) предназначено 8 бит, поэтому число ЭВМ в сети ограничено. Самые левые биты адреса предназначены для кода класса. ip-адрес характеризует точку подключения машины к сети. Поэтому, если ЭВМ перенесена в другую сеть, ее адрес должен быть изменен. Старшие биты адреса определяют номер подсети, остальные биты задают номер узла (номер ЭВМ). В таблице 4.1.1.3.1 приведено соответствие классов адресов значениям первого октета адреса и указано количество возможных IP-адресов каждого класса. Таблица. 4.1.1.3.1 Характеристики классов адресов
Структура ip-адресов изображена на рисунке 4.1.1.3.2:
Рис. 4.1.1.3.2. Структура IP-адресов (NetID = идентификатор сети) Для удобства чтения IP-адреса обычно записываются в десятично-точечной нотации, например: 192.148.166.129 (адрес класса C). Классу A соответствует диапазон адресов 1.0.0.0 - 127.255.255.255. Ряд адресов является выделенными для специальных целей: 0.0.0.0 - обращение к ЭВМ, на которой производится работа;
Рис. 4.1.1.3.2.а. Специальные ip-адреса IP-адрес имеет Интернет- и местную секции, первая характеризует место (организацию, сеть или даже группу сетей), вторая - конкретную ЭВМ. Местная секция адреса может быть разделена на части, характеризующие локальную сеть и конкретную ЭВМ (рис. 4.1.1.3.3).
Рис. 4.1.1.3.3. Локальная часть IP-адреса Такая схема обеспечивает необходимую гибкость, дает возможность разделить локальную сеть на субсети. При работе с субсетью необходимо использовать 32-разрядную маску. Разряды маски должны равняться 1, если сеть рассматривает данный бит как часть адреса сети, и 0, если он характеризует адрес ЭВМ в этой сети. Например: 255.255.255.254 (десятично-точечное представление) 11111111 11111111 11111111 11111110 (двоичное представление) описывает маску субсети, в которой работает автор. Некоторую информацию о масках в работающей сети можно получить с помощью команды ifconfig (SUN): /usr/etc/ifconfig -a (курсивом здесь и далее выделяются команды, введенные с клавиатуры) le0: flags=863 inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32 lo0: flags=869 inet 127.0.0.1 netmask ffffff00, где le0 и lo0 - имена интерфейсов, флаг -a предполагает выдачу данных обо всех интерфейсах. Во всех схемах IP-адресации адрес со всеми единицами в секции адрес ЭВМ (host) означает широковещательное обращение ко всем ЭВМ сети. Следует помнить, что широковещательные запросы сильно перегружают сеть, и без особой необходимости их использовать не следует. В настоящее время обсуждаются четыре предложения усовершенствования IP-адресации (см. RFC-1454): IP-адрес безусловно удобный для использования ЭВМ, почему-то плохо запоминается людьми, поэтому они разработали символьную систему имен для узлов Интернет. Эта система (DNS- domain name system) имеет иерархический характер. Имя содержит несколько полей, разделенных символом "." (точка). В качестве примера можно привести имя домена itepnet - cl.itep.ru. Это имя содержит три поля. Поле ru указывает на принадлежность данного домена России, поле itep определяет принадлежность узла ITEP (Institute for Theoretical and Experimental Physics), cl - характеризует то, что данное конкретное имя относится к кластеру ЭВМ (имя субдомена). Никаких ограничений на число полей в имени, кроме налагаемых здравым смыслом, не существует. Собственно имя домена - это itep.ru. Самое правое поле в имени домена характеризует принадлежность к определенному типу организации или стране. Таблица стандартизованных имен приведена в приложении Национальные коды . Преобразование символьного имени в IP-адрес производится в DNS-сервере узла, который представляет собой базу данных с удаленным доступом. Если искомое имя узла в локальном DNS-сервере отсутствует, он может прислать в качестве ответа адрес другого DNS-сервера, куда следует обратиться, чтобы определить IP-адрес искомого узла. Анализ имени обычно производится справа налево. Более подробно DNS-система описана в документах RFC-822, -823, а также ниже в разделе DNS. О правилах получения IP-адресов и регистрации имен сетей можно прочесть в [8]. При формировании пакетов различного уровня используется принцип инкапсуляции (вложения). Так IP-пакеты вкладываются в Ethernet-пакеты (кадры). Всякий пакет имеет заголовок и тело, некоторые из них снабжены контрольной суммой. Схема такого вложения представлена на рисунках 4.1.1.3.4 и 4.1.1.3.5. Поле тип определяет используемый в дейтограмме протокол, PAD - пустые биты, дополняющие размер дейтограммы до 48 бит. В случае протокола IEEE 802.3 полю тип (>150010) соответствует поле длина (<150010), которое определяет длину кадра. Пакетный принцип позволяет передавать информацию от разных источников к различным адресатам по общему телекоммуникационному каналу. Схема вложения пакетов в рамках TCP/IP показана на рис. 4.1.1.3.4. Принцип вложения (также как и фрагментации) является фундаментальным для любых современных сетей. Этот принцип используется в сетях netware, Apple Talk, TCP/IP т.д.
Рис. 4.1.1.3.4. cхема вложения пакетов в TCP/IP (в данном примере в поле тип Ethernet кадра будет записан код 0800) Отдельные сети в Интернет соединяются друг с другом через узловые серверы (gateway, их иногда называют пограничными маршрутизаторами - boarder gateway), расстояние между которыми может измеряться метрами или тысячами километров. В межсетевых обменах также используется принцип вложения так пакеты Ethernet могут вкладываться в пакеты FDDI и т.д.. Прикладные программы также как и все протокольное программное обеспечение уровня Интернет и выше работают только с ip-адресами, в то время как уровень сетевого программного обеспечения работает с физическими сетевыми адресами (так Ethernet использует 48-битные адреса). Обычно при описании сетей используется терминология 7-уровневой модели ISO ("стек протоколов"). Так уж получилось, но Интернет лишь с определенными натяжками можно описать, придерживаясь этой схемы. Ethernet инкапсуляция (RFC 894) (размеры полей указаны в байтах)
Рис. 4.1.1.3.5. Вложение пакетов Интернет в Ethernet- и IEEE 802 пакеты LLC - управление логической связью (logical link control); DSAP = 0xaa (destination service access point) - поле адреса доступа к службе получателя; SSAP = 0xaa (source service access point) - поле адреса доступа к службе отправителя; SNAP - протокол доступа к субсетям (subnetwork access protocol). PAD - поле заполнитель. В общем случае форматы полей DSAP и SSAP имеют вид, показанный на рис. 4.1.1.3.6 I/G = 0 - индивидуальный адрес, I/G =1 - групповой адрес; D - бит адреса службы места назначения, S - бит адреса службы отправителя; C/R =0 - команда, C/R =1 - подтверждение.
Рис. 4.1.1.3.6. Структура адресов DSAP и SSAP Поле CNTL может иметь длину 1 или 2 байта, а его структура соответствовать I, S или U-форматам (см. разделы "Эталонная модель iso" и "x.25"). В однобайтовых полях DSAP и SSAP записывается код типа протокола сетевого уровня. Для протоколов IPX/SPX это и последующее поле содержат код 0xE0. Поле CNTL=03 обозначает нечисловой формат для уровня ethernet 802.2. Эти три байта часто представляют собой код производителя, как правило, совпадающий с первыми тремя байтами адреса отправителя. Иногда они просто делаются равными нулю. Поле тип (2 байта) характеризует используемую версию Ethernet. Из рисунка 4.1.1.3.5 видно, что первые два поля (адреса получателя и отправителя) и последнее поле (CRC) во всех форматах идентичны. При расчете CRC содержимое кадра рассматривается как двоичный полином. Производится деление этого кода на специальный образующий полином. Полученный остаток от деления дополняется по модулю один, результирующий код и считается контрольной суммой CRC. В поле адрес получателя может быть записан код 0xffffffffffff, что указывает на широковещательную адресацию кадра. Адрес отправителя такой код содержать не может. Третье поле может служить для выявления типа используемого протокола. Если в этом поле содержится число более 1500 (десятичное), это указывает на то, что данный кадр имеет формат Ethernet II, а само поле содержит не длину кадра а тип данных. Теперь, надеюсь, читателю понятно, почему кадр Ethernet 802.3 не может содержать более 1500 байт. Кадр Ethernet 802.2 помимо первых трех полей содержит дополнительные три однобайтовые поля, следующие вслед за ними (DSAP, SSAP и CNTL). Кадр Ethernet SNAP является модификацией кадра Ethernet 802.2. Для этого кадра коды полей dsap и ssap равны 0xAA (признак кадра Ethernet SNAP), код CNTL=03 (нечисловой формат), поле код организации (3 байта, характеризует организацию сети) равен нулю (для IPX/SPX), а двухбайтовое поле тип характеризует протокол высокого уровня. Для протоколов IPX/SPX в этом поле должен быть записан код 0x8138 (для ip - 0x0800, для arp - 0x0806, для rarp - 0x8035, а для Apple Talk - 0x809b). Таблица кодов протоколов приведена в приложении Базовые протоколы Интернет (см. также RFC-1700). Поля тип протокола и по смыслу и по содержанию идентичны для всех разновидностей кадра Ethernet (кроме ieee 802.3). Транспортный уровень должен воспринимать данные от нескольких пользовательских программ и пересылать их на более низкий уровень. Многоуровневые протоколы спроектированы так, чтобы слой N по месту назначения получал ту же самую информацию, что была послана слоем N отправителя. Прикладные программы также как и все протокольное программное обеспечение уровня Интернет и выше использует только IP-адреса (32 бита), в то время как уровень сетевого программного обеспечения работает с физическими сетевыми адресами (так Ethernet использует 48-битные адреса). Когда IP-дейтограмма попадает в ЭВМ, сетевое программное обеспечение передает ее программе IP-уровня. Если адрес места назначения совпадает с IP-адресом ЭВМ, дейтограмма принимается и передается на более высокий уровень для дальнейшей обработки. При несовпадении адресов дейтограмма уничтожается (переадресация дейтограмм для ЭВМ запрещена, это функция маршрутизатора). Хотя можно заставить ЭВМ выполнять задачи маршрутизации, с точки зрения Интернет-философии это плохая идея. Различные сети и каналы имеют разные скорости обмена и надежность передачи. Это определяет длину пакета, пересылка которого с высокой вероятностью будет осуществлена без ошибки. Так как Интернет объединяет самые разные узлы и сети, использующие разные длины посылок, при реализации связи между такими объектами размер пакета задается наименее надежным узлом и длина пакета выбирается минимальной из двух. Поэтому при передаче длинного пакета через такой участок сети он сегментируется и передается по частям. Размер фрагмента определяется величиной максимального передаваемого блока (MTU - maximum transfer unit, в Ethernet MTU=1500 октетам). Величины MTU для других сред приведены в таблице 4.1.1.3.2: Таблица 4.1.1.3.2 Значения mtu для различных сетевых стандартов
Рассмотрим по фрагментную передачу дейтограммы с длиной в 1300 октетов в предположении, что более 576 октетов за один раз передать нельзя.
Рис. 4.1.1.3.6. Пример фрагментации пакета Куда будет направлен Ethernet-кадр, указывает значение для типа в заголовке кадра (рис. 4.1.1.3.5). Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть переданы либо модулю TCP (Transmission Control Protocol), либо UDP, что определяется полем "протокол" в заголовке IP-пакета. Одним из основополагающих понятий в теории маршрутизации является автономная система (AS). Автономную систему составляет IP-сеть (или система из нескольких IP-сетей), проводящая единую политику внешней маршрутизации и имеющая одного или более операторов. Все AS имеют уникальные номера. Идеология AS позволяет решить проблему безудержного роста размера таблиц маршрутизации. Построение узла Интернет неотделимо от формирования локальной сети, поэтому прежде чем перейти к углубленному описанию протоколов TCP/IP, введем определения некоторых сетевых устройств, без которых построение локальной сети невозможно. |
||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.1.1.2 Fast Ethernet
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
На физическом уровне пакет представляет собой цуг импульсов, распространяющихся по коаксиальному кабелю, скрученной паре или оптическому волокну. За счет дисперсии, частичным отражениям от точек подключения и поглощению в среде импульсы в пакете "расплываются" и искажаются (ухудшается отношение сигнал/шум), это является одной из причин ограничения длин кабельных сегментов. Для преодоления этих ограничений вводятся сетевые повторители (repeater). Повторитель воспринимает входные импульсы, удаляет шумовые сигналы и передает вновь сформированные пакеты в следующий кабельный сегмент или сегменты. Никакого редактирования или анализа поступающих данных не производится. Задержка сигнала повторителем не должна превышать 7,5 тактов (750нсек для обычного Ethernet). Повторители могут иметь коаксиальные входы/выходы, AUI-разъемы для подключения трансиверов или других аналогичных устройств, или каналы для работы со скрученными парами.
Рис. 4.1.1.4.1 Схема сетевого повторителя Все входы/выходы повторителя с точки зрения пакетов эквивалентны. Если повторитель многовходовый, то пакет пришедший по любому из входов будет ретранслирован на все остальные входы/выходы повторителя. Чем больше кабельных сегментов объединено повторителями, тем больше загрузка всех сегментов. При объединении нескольких сегментов с помощью повторителя загрузка каждого из них становится равной сумме всех загрузок до объединения. Это справедливо как для коаксиальных кабельных сегментов, так и для повторителей, работающих со скрученными парами (хабы - концентраторы). Некоторые повторители контролируют наличие связи между портом и узлом (link status), регистрируют коллизии и затянувшиеся передачи (jabber - узел осуществляет передачу дольше, чем это предусмотрено протоколом), выполняют согласование типа соединения (autonegotiation). В этом случае они обычно снабжены SNMP-поддержкой. Для преодоления этого нежелательного явления используются сетевые мосты или переключатели. Мост соединяет два сегмента сети, при инициализации он изучает списки адресов устройств, подсоединенных к каждому из сегментов. В дальнейшем мост записывает в свою память эти списки и пропускает из сегмента в сегмент лишь транзитные пакеты. Существуют мосты, которые оперируют с физическими и с IP-адресами (cм. стандарт IEEE 802.1d).
Рис. 4.1.1.4.2. Схема сетевого моста Мост является активным устройством, которое способно адаптироваться к изменениям в окружающей сетевой среде. При этом пакеты, отправленные из сегмента А и адресованные устройству, которое подключено к этому же сегменту, никогда не попадут в сегмент Б и наоборот. Через мост проходят лишь пакета, отправленные из сети А в Б или из Б в А. Функцию моста с определенными скоростными ограничениями может выполнять и обычная ЭВМ, имеющая два сетевых интерфейса и соответствующее программное обеспечение. Мосты при разумном перераспределении серверов и рабочих станций по сетевым сегментам позволяют выровнять и даже эффективно снизить среднюю сетевую загрузку. Когда на один из входов моста приходит пакет, производится сравнение адреса получателя с содержимым внутренней базы данных. Если адрес в базе данных отсутствует, мост посылает широковещательный запрос в порт, противоположный тому, откуда получен данный пакет с целью выяснения местоположения адресата. Понятно, что появление в субсетях a и Б двух объектов с идентичными адресами ни к чему хорошему не приведет. При поступлении отклика вносится соответствующая запись в базу данных. Параллельно анализируется и адрес отправителя и, если этот адрес в базе данных отсутствует, производится его запись в банк адресов соответствующего порта. В базу данных записывается также время записи адреса в базу данных. Содержимое базы данных периодически обновляется. К любой подсети может вести несколько путей, но для нормальной работы мостов и переключателей все пути кроме одного должны быть заблокированы. Функциональная схема работы моста показана на рис. 4.1.1.4.3. Сети, между которыми включается мост, не обязательно должны работать согласно идентичным протоколам. Возможны мосты между Ethernet и Token Ring или между Ethernet и ATM.
Рис. 4.1.1.4.3 Блок-схема работы сетевого моста Мост, имеющий более двух портов, называется переключателем. Первый переключатель был разработан фирмой Калпане в 1991 году. Иногда переключатели называются маршрутизаторами, тем более что некоторые из них поддерживают внутренние протоколы маршрутизации (например, RIP). Переключатели имеют внутреннюю параллельную магистраль очень высокого быстродействия (от десятков мегабайт до гигабайт в сек.). Эта магистраль позволяет переключателю совместить преимущества повторителя (быстродействие) и моста (разделение информационных потоков) в одном устройстве. Схемы реализации переключателей варьируются значительно, каких-либо единых стандартов не существует. Алгоритм работы с адресами здесь тот же, что и в случае мостов. На рис. 4.1.1.4.4 приведена схема 8-входового переключателя. В переключателе все входы идентичны, но внешняя информация, записанная в их память, делает входы неэквивалентными. Определенные проблемы возникают, когда к одному из входов переключателя подключен сервер, с которым работают пользователи подключенные к остальным входам. Если все ЭВМ, подключенные к переключателю, одновременно попытаются обратиться к серверу, переключатель перегрузится и все каналы будут на некоторое время блокированы (будет послан сигнал перегрузки - jam). При данной схеме вероятность таких событий значительна, так как несколько каналов с пропускной способностью 10 Мбит/с работают на один общий канал с той же полосой пропускания. Для преодоления проблем этого рода следует распределять нагрузки между портами переключателя равномерно, а также подключать серверы через полнодуплексные каналы. Полнодуплексные каналы полезны и для соединения переключателей между собой. Современные переключатели имеют много различных возможностей - SNMP поддержка, автоматическая настройка быстродействия и определения типа соединения (дуплексная/полудуплексная). Имеется возможность внешней загрузки программы работа переключателя. Способы проверки производительности переключателей описаны в документах RFC-1242 и RFC-1944 (тесты Бреднера, см. www.wiley.com/compbooks/fastethernet и www.tolly.com).
Рис. 4.1.1.4.4. Схема 8-входового сетевого переключателя Существуют переключатели, работающие в режиме "на пролет" (cut through). Здесь первые биты пакета поступают на выход переключателя, когда последующие еще только приходят на вход. Задержка в этом случае минимальна, но переключатель пропускает через себя пакеты, поврежденные в результате столкновений. Альтернативой такому режиму является передача через буферную память (схема передачи SAF - Store And Forward). Поврежденные пакеты в этом режиме отбрасываются, но задержка заметно возрастает. Кроме того, буферная память должна иметься на всех входах (или общая многопортовая). При проектировании сетей следует иметь в виду, что переключатели превосходят маршрутизаторы по соотношению производительность/цена. При проектировании локальной сети следует учитывать то обстоятельство, что узлы с самым напряженным трафиком должны располагаться как можно ближе к повторителю (мосту или переключателю). В этом случае среднее число коллизий в единицу времени будет ниже. По этой причине сервер должен располагаться как можно ближе к повторителю или другому сетевому устройству (см. рис. 4.1.1.4.6). Схема внутренних связей переключателя может отличаться от приведенной на рис. 4.1.1.4.4 и иметь конфигурацию, показанную на рис. 4.1.1.4.5. Привлекательность такой схемы заключается в возможности реализации обмена по двум непересекающимся направлениям одновременно (См. LAN. Журнал сетевых решений, май 1998, том 4, N5, стр 21. Дмитрий Ганжа). От разделяемых к коммутируемым сетям). При этом эффективная пропускная способность многопортового переключателя может в несколько раз превосходить полосу пропускания сети, например, 10 Мбит/с.
Рис. 4.1.1.4.5. Вариант схемы внутренних связей переключателя.
Рис. 4.1.1.4.6 Схема подключения сервера к переключателю При использовании в сети большого числа мостов и/или переключателей может сформироваться топология связей, когда от одного сегмента к другому пакет может попасть более чем одним путем (см. рис. 4.1.1.4.7). Приведенная на рисунке схема неработоспособна и некоторые связи должны быть ликвидированы. В данном примере проблема может быть решена удалением мостов BR-2 и BR-3 или разрывом связей, помеченных символом "X". Проблему ликвидации связей, способных привести к зацикливанию, решает протокол STP (Spanning Tree Protocol; алгоритм предложен Пёлманом в 1992 году), который автоматически блокирует некоторые соединения, а в случае недоступности основного пути открывает эти заблокированные соединения, обеспечивая высокую надежность сети. STP является частью протокола мостов IEEE 802.1d.
При использовании протокола STP каждой связи присваивается при конфигурации определенный вес (чем меньше, тем выше приоритет). Мосты периодически рассылают специальные сообщения (BPDU - Bridge Protocol Data Unit), которые содержат коды их уникальных идентификаторов, присвоенные им при изготовлении. Мост или переключатель с наименьшим значением такого кода становится корневым ("корень дерева"). Затем выявляется наикратчайшее расстояние от корневого моста/переключателя до любого другого моста в сети. Граф, описывающий дерево наикратчайших связей, и является "расширяющимся деревом". Такое дерево включает все узлы сети, но необязательно все мосты/переключатели. Этот алгоритм функционирует постоянно, отслеживая все топологические изменения.
Современные мосты позволяют создавать виртуальные субсети (VLAN), увеличивающие сетевую безопасность. VLAN позволяет ограничить зону распространения широковещательных пакетов, улучшая эксплуатационные характеристики сети в целом.
Рис. 4.1.1.4.7. Пример реализации алгоритма "расширяющееся дерево" Некоторые современные мосты используют так называемую маршрутизацию отправителя (source routing). Такая маршрутизация предполагает, что отправитель знает, находится ли адресат в пределах локальной сети и может оптимально определить путь доставки. При посылке кадра другой сети отправитель устанавливает старший бит своего адреса равным единице. Одновременно в заголовке кадра прописывается весь маршрут. Каждой сети присваивается 12-битовый идентификатор, а каждому мосту ставится в соответствие 4-битовый код, уникальный в контексте данной сети. Это означает, что мосты в пределах одной сети должны иметь разные идентификаторы, но их коды могут совпадать, если они находятся в разных сетях. Мост рассматривает только кадры с единицей в старшем бите адреса места назначения. Для этих кадров просматриваются коды сети в списке, записанном в заголовке. Если в списке содержится код, совпадающий с тем, который характеризует сеть, где находится мост, кадр переадресуется в эту сеть. Реализация алгоритма может осуществляться программно или аппаратно. Если путь до места назначения неизвестен, отправитель генерирует специальный пакет, посылаемый широковещательно (discovery frame) и достигающий всех мостов и всех субсетей. Когда приходит отклик от адресата, мосты записывают его идентификатор, а первичный отправитель фиксируют маршрут до адресата. Данный алгоритм достаточно прост, но сопряжен с лавинным размножением "исследовательских" пакетов особенно в случае, когда смежные сети соединяются через несколько мостов/переключателей. Маршрутизатор отличается от переключателя тем, что поддерживает хотя бы один протокол маршрутизации. Существуют внутренние и внешние протоколы маршрутизации. Если маршрутизатор осуществляет связь данной автономной системы с другими автономными системами, его называют пограничным (border). Маршрутизатор же, который имеет только один внешний канал связи, в литературе часто называют gateway (входной порт сети). Любой маршрутизатор может поддерживать в любой момент только один внутренний и один внешний протокол маршрутизации, выбор этих протоколов осуществляет администратор сети из имеющегося списка. Маршрутизаторы представляют собой наиболее сложные сетевые устройства. Главным достоинством маршрутизаторов в локальной сети является ограничение влияния потоков широковещательных сообщений. В последнее время заметное распространение получил гибрид маршрутизатора и моста - brouter. Некоторые протоколы (например, NetBIOS) не допускают маршрутизации. Когда необходимо использовать такие протоколы совместно с TCP/IP, необходим brouter. Широко используются такие приборы в сетях Token Ring. Особый класс образуют мультиплексоры/демультиплексоры, которые используют собственные протоколы и служат для предоставления общего канала большему числу потребителей. Эти устройства широко используются при построении сетей типа Интранет (корпоративные сети, где субсети разных филиалов разнесены на большие расстояния). Такие сети строятся на базе специальных выделенных каналов, а мультиплексоры позволяют использовать эти каналы для предоставления комплексных услуг: телефонной связи, передачи факсов и цифровой информации, экономя значительные средства. Если перед вами стоит задача создания локальной сети с выходом в Интернет, вам нужно последовательно решить ряд проблем помимо финансовых. Должны быть сформулированы задачи, ради которых эта сеть создается, определена топология сети, число сегментов и характер их связей, число ЭВМ-участников, определен сервис-провайдер, или провайдеры, если вам нужно обеспечить более высокую надежность и живучесть сети. Вам надо оценить требуемую загрузку сегментов сети и внешних каналов связи, выбрать программную среду. После этого вы можете приступить к составлению списка необходимого оборудования и программного обеспечения. Если ваша сеть является оконечной и она имеет только один внешний канал связи, вам не нужен маршрутизатор и вы можете ограничиться ЭВМ-портом (gateway), которая должна иметь необходимый интерфейс. Внешним каналом может стать коммутируемая телефонная сеть, выделенная телефонная линия, оптоволоконный кабель или радиорелейный канал. Во всех перечисленных случаях вам будет необходим соответствующий модем. |
|
Previous:
4.1.1.3 Интернет в Ethernet
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.1.2 IEEE 802.5 (Token Ring)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Сети Token Ring были разработаны фирмой IBM в 1970-х годах и рассчитана на скорость обмена 4.16 Мбит/c при числе сегментов до 250. По своей популярности она уступает лишь Ethernet/IEEE 802.3. Спецификация IEEE 802.5 практически идентична ей и полностью совместима (см. [13], или, например, bbs.uniinc.msk.ru/product/bay/routers/interf/toking.html или www.oil.unh.edu/training/vganylan/teach/vgconcept/frame/802.-5). Сеть Token Ring имеет топологию звезды, все оконечные станции которой подключаются к общему устройству ( MSAU - MultiStation Access Unit). В IEEE 802.5 топология не оговаривается, не регламентирована здесь и сетевая среда. В Token Ring сеть базируется на скрученных парах. Обе эти разновидности сети используют схему передачи маркера (небольшой пакет - token). В отличие от сетей с csma/cd доступом (например, Ethernet) в IEEE 802.5 гарантируется стабильность пропускной способности (нет столкновений). Сети Token Ring имеют встроенные средства диагностики, они более приспособлены для решения задач реального времени, но в то же время более дороги. Маркер содержит лишь поля стартового разделителя(sdel), управления доступом (AC) и оконечного разделителя (EDEL, всего 3 байта). Если узел получил маркер, он может начать передачу информации, в противном случае он просто передает маркер следующему узлу. Каждая станция может захватить маркер на определенное время. Станция, намеревающаяся что-то передать, захватывает маркер, меняет в нем один бит, который преобразует маркер во флаг начала кадра, вносит в кадр информацию, подлежащую пересылке, и посылает его следующей станции. Передающая станция ответственна за изъятие из кольца переданных ею кадров (станция не ретранслирует собственные кадры). Введенный в сеть кадр будет двигаться по сети, пока не попадет в узел, которому он адресован и который скопирует необходимую информацию. При этом устанавливается флаг копирования (FCI), что свидетельствует об успешной доставке кадра адресату. Кадр продолжает движение, пока не попадет в узел отправитель, где он будет уничтожен. При этом проверяется, подключена ли к сети станция-адресат. Это делается путем контроля API (индикатора распознавания кадра адресатом). Сеть Token Ring идеальна для приложений, где задержка получения информации должна быть предсказуемой, и требуется высокая надежность. Сетевые станции подключаются к MSAU, которые объединяются друг с другом, образуя кольцо. Если станция отключилась, MSAU шунтирует ее, обеспечивая проход пакетов. Стандарт Token Ring использует довольно сложную систему приоритетов, которая позволяет некоторым станциям пользоваться сетью чаще остальных. Кадры Token Ring имеют два поля, которые управляют доступом приоритет и резервирование. Только станции с приоритетом равным или выше, чем приоритет маркера, могут им завладеть. Если маркер уже захвачен и преобразован в информационный кадр, только станции с приоритетом выше, чем у станцииё отправителя, могут зарезервировать маркер на следующий цикл. Станции, которые подняли приоритет маркера, должны его восстановить после завершения передачи. Сети Taken Ring имеют несколько механизмов для обнаружения и предотвращения влияния сетевых сбоев и ошибок. Например, пусть одна из станций выбрана в качестве активного монитора. Эта станция работает как центральный источник синхронизации для других станций сети и выполняет ряд других функций. Одной из таких функция является удаление из кольца бесконечно циркулирующих кадров (маркеров). Если отправитель ошибся, установив, например ошибочный адрес места назначения, это может привести к зацикливанию кадра. Ведь кадр может быть поврежден в пути и отправитель его уже не узнает. А это в свою очередь блокирует работу остальных станций. Активный монитор должен обнаруживать такие кадры, удалять их и генерировать новый маркер. Функции активного монитора часто выполняют MSAU. Попутно msau может контролировать, какая из станций является источником таких дефектных кадров, и вывести ее из кольца. Если станция обнаружила серьезную неполадку в сети (например, обрыв кабеля), она посылает сигнальный кадр (beacon). Такой кадр несет в себе идентификатор отправителя и имя соседа-предшественника (NAUN - nearest active upstream neighbour). Такой кадр инициализирует процедуру автореконфигурации, при которой узлы в районе аварии пытаются реконфигурировать сеть так, чтобы ликвидировать влияние поломки. Топологическая схема сети ieee 802.5 представлена на рис. 4.1.2.1.
Рис. 4.1.2.1 Топология сети Token Ring Периферийные ЭВМ подключаются к блокам msau по схеме звезда, а сами MSAU соединены друг с другом по кольцевой схеме. Возможна реализация схемы звезда и иным способом, показанным на рис. 4.1.2.2. Здесь объединяющую функцию выполняет блок концентратора.
Рис. 4.1.2.2. Реализация Token Ring по схеме звезда Концентратор может шунтировать каналы, ведущие к ЭВМ, с помощью специальных реле при ее отключении от питания. Аналогичную операцию может выполнить и блок msau. Управление сетью возлагаются на пять функциональных станций, определенных протоколом. Некоторые контрольные функции выполняются аппаратно, другие реализуются с помощью загружаемого программного обеспечения. Каждая из функциональных станций имеет свои логические (функциональные) адреса. Функциональные станции должны реагировать как на эти функциональные, так и на свои собственные аппаратные адреса. Ниже в таблице представлен список функциональных станций и их функциональных адресов (таблица 4.1.2.1). Таблица 4.1.2.1 Типы и адреса функциональных станций
В сети используются кадры управления доступом к среде (УДС, код типа кадра = 00) и информационные кадры (код типа кадра =01). Имеется 25 разновидностей УДС-кадров (см. приложение 10.6 Управление доступом). Сюда входят кадры инициализации, управления средой, сообщения об ошибках и кадры управления рабочими станциями. Общий формат заголовка кадра Token Ring представлен на рис. 4.1.2.3. Размер поля данных, следующего за адресом отправителя, может иметь произвольную длину, в том числе и нулевую. В это поле может быть вложен пакет другого протокола, например, LLC.
Рис. 4.1.2.3. Формат информационного кадра для IEEE 802.5 В начале поля данных может размещаться LLC-заголовок, который содержит в себе 3-8 байт. Собственно этот заголовок, да поле управления кадром и отличают информационный кадр от кадра управления доступом (см. рис. 4.1.2.4).
Рис. 4.1.2.4. Формат кадра управления доступом для IEEE 802.5 (цифрами обозначены размеры полей в байтах) Вслед за адресом отправителя следует информация управления доступом к среде. Кадры управления доступом служат исключительно для целей управления сетью и не передаются через бриджи и маршрутизаторы. Управляющая информация включает в себя основной вектор и несколько субвекторов. Основной вектор задает тип УДС-кадра (или команду) и типы (или классы) станций отправителя и получателя, всего 4 байта. Субвекторы содержат информацию об адресе соседа-предшественника, номер физического отвода кабеля и пр. (3 и более байт). На рис. 4.1.2.5. представлен формат основного вектора.
Рис. 4.1.2.5. Формат основного вектора Субполе длина определяет полную протяженность информационного поля УДС-кадра и равна сумме длин основного вектора и всех субвекторов. Субполе класс характеризует станции отправителя и получателя. Каждой из станций выделено по 4 двоичных разряда, которые описывают типы этих станций. Ниже в таблице 4.1.2.2 представлены эти коды и их значения. Таблица 4.1.2.2 Таблица кодов класса
Субполе команда содержит код, передаваемой УДС-кадром команды (см. таблицу 10.6 в приложении Управление доступом). Кадр управления доступом может содержать любое, в том числе нулевое число субвекторов. Некоторые субвектора являются обязательными. Таблица обязательных субвекторов приведена в приложении 10.7 Типы субвекторов. В результате декодирования субвекторов можно локализовать нестабильную ошибку. Ниже на рис. 4.1.2.6 приведен формат субвектора.
Рис. 4.1.2.6. Формат субвектора Поля длина определяет длину субвектора (ведь она переменная). Поля тип содержит код типа субвектора. Поле значение хранит данные, например, код 0x0b характеризует номер отвода и т.д.. Разряды начального и конечного разделителей кадра содержат как обычные нули и единицы, так и закодированные дифференциальным манчестерским кодом. На рис. 4.1.2.7 приведен формат начального разделителя SDEL.
Рис. 4.1.2.7. Формат начального разделителя SDEL "e" и "Н" - представляет собой единицу и нуль, закодированные манчестерским кодом. Оконечный разделитель (EDEL) имеет формат, показанный на рис. 4.1.2.8.
Рис. 4.1.2.8. Формат оконечного разделителя EDEL Бит - индикатор промежуточного кадра (IF) равен нулю, если кадр является последним или единственным кадром в последовательности. Единица в этом бите указывает на то, что этот кадр не является последним. Бит индикатор обнаруженной ошибки (ED) устанавливается равным единице первой станцией, которая выявила ошибку в контрольной последовательности кадра (CRC). Таким образом, crc контролируется всеми станциями, через которые проходит пакет. crc - гарантирует корректность пересылке части кадра, начиная от поля управление кадром кончая полем данные. Последним полем кадра является октет состояния (рис. 4.1.2.9). Первые и последние четыре бита этого поля должны повторять друг друга, что повышает достоверность записанной там информации.
Рис. 4.1.2.9. Формат поля состояния кадра Бит распознавания адреса (ARI) служит в качестве флага распознавания получателем своего адреса. Если распознавание произошло, получатель перед ретрансляцией кадра далее устанавливает этот бит в единичное состояние. Бит- индикатор копирования кадра (FCI) служит для индикации успешного копирования информации из полученного кадра. Если получатель распознал свой адрес, имеет достаточно место в буфере и благополучно скопировал туда информацию из полученного пакета, он устанавливает этот бит в единичное состояние. Биты ARI и FCI активно используются управляющими станциями кольца. Для отправителя они носят второстепенный характер, ибо решение о повторной пересылке при утере кадра принимается обычно на транспортном (более высоком) уровне. При недостатке буферного пространства в памяти станция не всегда может скопировать кадр, повторная же передача сокращает пропускную способность сети. Если же перегружающаяся станция является частью инфраструктуры сети (сервер), это может ухудшить свойства сети в целом. Улучшению ситуации может способствовать увеличение числа буферов на плате сетевого адаптера, увеличение быстродействия канала и расширения объема буферной памяти в самой ЭВМ. Флаг начала потока (SSD - start of stream delimiter) позволяет сетевому уровню, независящему от физической среды (PMI - physical media independent) детектировать начало потока кодов. Получение неверного SSD не прерывает прием данных, а передает сигнал ошибки субуровням MAC или RMAC.
Флаг окончания потока (ESD - end of stream delimiter) позволяет сетевому уровню PMI завершить прием пакета и переслать полученные данные субуровню mac. Детектирование неверного IPM (invalid packet marker) разделителя приводит к ошибке на уровне MAC или RMAC. Правильный флаг окончания потока (ESD):
Сигнатура преамбулы позволяет PMI определить место, с которого следует начинать прием данных. Код преамбулы имеет вид: 010101 010101 010101 010101 010101 010101 010101 010101
Рис. 4.1.2.10. Формат поля управления доступом Поле управления доступом служит для определения приоритета кадра, это единственное поле, которое присутствует в маркере (помимо SDEL и EDEL). Субполе приоритета (PPP) указывает на приоритет маркера в 802.5. Предусмотрено восемь уровней приоритета, начиная с 000 (низший) до 111 (высший). В 802.12 здесь записывается всегда 000. Субполе бит маркера позволяет отличить обычный кадр от маркера. Для маркера поле несет в себе 0, а для кадра 1 (802.5). Так как в 100VG-anylan передаются только маркерные кадры, этот бит всегда равен 1. Бит мониторинга препятствует бесконечной циркуляции кадра по кольцу. В исходный момент все кадры и маркеры имеют этот бит равный 0. Приемник игнорирует этот бит. Биты rrr разрешают приоритетным пакетам запрашивать маркер того же уровня приоритета. Стандарт 802.12 не использует непосредственно октет управления доступом, а для обеспечения совместимости с 802.5 по умолчания записывает туда 0001000.
Рис. 4.1.2.11. Формат поля управления кадра Значения кодов субполя тип кадра представлено в таблице 4.1.2.3, они определяют формат данных информационного поля кадра. Для обычной передачи поле равно 01000yyy. Таблица 4.1.2.3 Коды типа кадра
Поле физического управления (pcf) имеет смысл только для УДС-кадров и служит для оповещения станций о типе кадра управления средой. Это поле служит также для указания приоритета передачи кадра из буфера адаптера в ЭВМ. В таблице 4.1.2.4. Таблица 4.1.2.4 Коды поля pcf
Для llc-кадров поле резервированные биты и далее имеет формат rrryyy, где биты rrr зарезервированы для будущего использования (000), а yyy - код приоритета пакетов пользователя. (MAC-кадры не используются в IEEE 802.12). Формат поля адреса получателя отображен на рис. 4.1.2.12.
Рис. 4.1.2.12. Формат адреса места назначения I/G =0 индивидуальный адрес (I); I/G=1 групповой адрес (g). Индивидуальный адрес - адрес конечного узла, уникальный для данной локальной сети (в случае локального администрирования) или отличный от любого другого адреса в глобальной сети в случае универсального администрирования. Существует две разновидности индивидуального адреса: уникастный и нулевой. Уникастный адрес - индивидуальный адрес, идентифицирующий один из узлов сети. Нулевой адрес равен нулю и означает, что кадр не адресован ни одному из узлов сети. Такой адрес не может быть присвоен ни одному из оконечных узлов сети. Описываемые далее разновидности адресов используются только в полях адреса места назначения. Групповой адрес ассоциируется с (нулем или более) некоторым числом оконечных узлов данной сети, обычно это группа логически связанных узлов. Широковещательные и мультикастинг-адреса относятся к групповым адресам. Широковещательный адрес подразумевает обращение ко всем узлам данной сети, такой адрес содержит 1 во всех своих разрядах. Мультикастинг-адрес подразумевает обращение к некоторой, выделенной группе адресов данной локальной сети. Существуют также функциональные адреса (FA), которые идентифицируют некоторые известные функциональные объекты с помощью групповых адресов. Формат функционального адреса представлен на рис. 4.1.2.13.
Рис. 4.1.2.13. Структура функционального адреса Ниже приведена таблица 4.1.2.5 некоторых зарезервированных функциональных адресов. Таблица 4.1.2.5. Зарезервированные функциональные адреса
Функциональные адреса являются отличительной особенностью сетей Token Ring. В этих сетях маршрутная информация распределена между устройствами сети. Рабочие станции создают и поддерживают собственные маршрутные таблицы. Формат поле адреса отправителя показан на рис. 4.1.2.14.
Рис. 4.1.2.14. Формат адреса отправителя Субполе RII является индикатором маршрутной информации, функция субполя U/L идентична с вариантом формата адреса получателя. Если RII=1, в поле данных содержится маршрутная информация. Формат поля маршрутной информации отображен на рис. 4.1.2.15.
Рис. 4.1.2.15. Формат поля маршрутной информации (RI) Разновидности сетей, не использующие маршрутную информацию, берут код из субполя LTH (длина), чтобы обойти поле RI. Субполе RT (код типа маршрутизации) имеет 3 бита и говорит о том, должен ли данный кадр быть переадресован. Ниже приведена таблица (4.1.2.6) возможных значений кода rt. Таблица 4.1.2.6. Значения кола rt
Субполе LTH (длина) имеет 5 бит и хранит в себе длину поля RI в октетах. LTH должно быть четным и лежать в пределах 2-30, включительно. Обычно маршрутная информация занимает от 2 до 16 байт (cпецификация IBM требует, чтобы кадр проходил не более 7 мостов). Если субполе бит направления (d) равно нулю, обход кольца маркером осуществляется в порядке записи дескрипторов маршрута, при d=1 - в обратном порядке (RDN, RDn-1, ... RD1). Субполе максимальная длина кадра (LF) имеет 3 бита и указывает наибольший размер информационного поля MAC. Значение поля устанавливается мостами при определении маршрута и указывает максимальную длину кадра, передаваемого мостом. Допустимы следующие значения: Таблица 4.1.2.7. Возможные значения поля LF
Субполя дескрипторов маршрута состоят из 12 бит идентификатора сети (номер кольца, назначается сетевым администратором) за которым следует 4 бита номера моста. Эти дескрипторы определяют порядок обхода сети кадром. В сетях 100VG-anylan это поле не используется, так как порядок обхода задается аппаратно повторителями. При построении больших сетей token ring приходится использовать большое число колец. Отдельные кольца связываются друг с другом, как и в других сетях, с помощью мостов (рис. 4.1.2.16). Мосты бывают "прозрачными" (IEEE 802.1d) и с маршрутизацией от источника. Последние позволяют связать в единую сеть несколько колец, использующих общий сетевой IPX- или IP-адрес.
Рис. 4.1.2.16 Соединение колец с помощью прозрачного моста Использование мостов позволяет преодолеть и ограничение на число станций в сети (260 для спецификации ibm и 255 для IEEE). Мосты могут связывать между собой фрагменты сетей, использующих разные протоколы, например, 802.5, 802.4 и 802.3. Пакеты из кольца 1 адресованные объекту этого же кольца никогда не попадут в кольцо 2 и наоборот. Через мост пройдут лишь пакеты, адресованные объектам соседнего кольца. Фильтрация пакетов осуществляется по физическому адресу и номеру порта. На основе этих данных формируется собственная база данных, содержащая информацию об объектах колец, подключенных к мосту. Схема деления сети с помощью мостов может способствовать снижению эффективной загрузки сети. Мосты с маршрутизацией от источника могут объединять только сети token ring, а маршрутизация пакетов возлагается на все устройства, посылающие информацию в сеть (отсюда и название этого вида мостов). Это означает, что в каждом из сетевых устройств должно быть загружено программное обеспечение, позволяющее маршрутизировать пакеты от отправителя к получателю (в случае netware это route.com). Эти мосты не создают собственных баз данных о расположении сетевых объектов и посылают пакет в соседнее кольцо на основе маршрутного указания, поступившего от отправителя самого пакета. Таким образом, база данных о расположении сетевых объектов оказывается распределенной между станциями, хранящими собственные маршрутные таблицы. Программы маршрутизации используют сетевой драйвер адаптера. Мосты с маршрутизацией от источника просматривают все поступающие кадры и отбирают те, которые имеют индикатор информации о маршруте RII=1. Такие кадры копируются, и по информации о маршруте определяется, следует ли их посылать дальше. Мосты с маршрутизацией от источника могут быть настроены на широковещательную передачу по всем маршрутам, либо на широковещательную передачу по одному маршруту. Формат информации о маршруте показан на рис. 4.1.2.15. В сетях со сложной топологией маршруты формируются согласно иерархическому протоколу STP (spanning tree protocol). Этот протокол организует маршруты динамически с выбором оптимального маршрута, если адресат достижим несколькими путями. При этом минимизируется транзитный трафик. Для решения задачи мосты обмениваются маршрутной информацией. Формат этих пакетов показан на рис. 4.1.2.17.
Рис. 4.1.2.17. Формат кадра маршрутных данных, рассылаемых мостом Поле идентификатор протокола характеризует используемый мостом протокол (для STP это код равен 0x000). Поле версия протокола хранит текущую версию протокола. Поле тип протокольного блока данных моста может принимать следующие значения:
В настоящее время протоколом STP используются только два флага :
Поле идентификатор корня содержит идентификатор корневого моста. В поле метрика маршрута до корня хранится оценка маршрута до корневого моста. В поле идентификатор моста записывается 8-байтовый код-идентификатор моста, передающего протокольный блок данных. Содержимое двух старших байт задается администратором сети, остальные 6 байт хранят универсальный или локальный адрес порта моста. Идентификатор порта представляет собой двух-байтовый код, присвоенный порту моста. Поле возраст сообщения содержит время в секундах, прошедшее с момента формирования конфигурационного сообщения. При ретрансляции протокольного блока конфигурации каждый мост увеличивает код в этом поле на величину, заданную протоколом управления. Величину кода в поле максимальный возраст задает корневой мост так, чтобы все остальные мосты имели согласованные значения возраста информации о конфигурации. Поле период актуализации определяет длительность периода посылки протокольных блоков конфигурации в секундах. Поле задержки передачи указывает на заданную корневым мостом величину времени в секундах, в течение которого порт не должен начинать передачу кадров после окончания реконфигурации сети. Длина поля данных ограничивается временем, на которое станция может захватить маркер и не превышает 4502 октетов. Поле CRC служит для контроля целостности кадра при транспортировке. При расчете CRC используется образующий полином вида: x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 Алгоритм вычисления аналогичен тому, что используется в сетях Ethernet, контрольное суммирование охватывает поля адрес места назначения, адрес отправителя, управление кадром, маршрутная информация и данные. Стартовый разделитель должен иметь уникальную сигнатуру, которая не может встретиться ни в одном из последующих полей. Оконечный разделитель нужен для того, чтобы обозначить конец кадра (или маркера), ведь длина пакетов переменна. На физическом сетевом уровне используется дифференциальный манчестерский код с уровнями сигналов положительной и отрицательной полярности в диапазоне 3,0-4,5 В (сравните с +0,85 и -0,85 В для IEEE 802.3). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|||||||||||||||||||||||||||||||||||||||
|
4.1.3 IEEE 802.4 (Маркерная шина)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||
|
Стандарт IEEE 802.4 описывает свойства сетей, известных под названием маркерная шина. С точки зрения правил предоставления доступа этот стандарт схож с token ring (см. [13], а также RFC-1042 и -1230). В качестве физической среды используется 75-омный кабель. При необходимости построения сети типа дерева, а также для увеличения длины сети используются повторители. Сеть способна обеспечить пропускную способность до 10 Мбит/с при полосе пропускания кабеля 12 МГц. Для доступа к сетевой среде станция должна получить пакет-маркер. Получив маркер, сетевое устройство может начать передачу данных, а завершив эту процедуру, устройство должно переслать маркер следующей сетевой станции. Передача маркера происходит до тех пор, пока он не достигнет младшей станции, после чего он возвращается первой станции. Формат кадра, пересылаемого по маркерной шине, имеет вид, представленный на рис. 4.1.3.1.
Рис. 4.1.3.1. Формат кадров 802.4. SD - (Start Delimiter) - стартовый байт-разделитель =**0**000, где * - символ, кодируемый неманчестерским кодом; FC - (Frame Control) поле управления кадром = FFxxxxxx, где FF - субполе формата кадра, а xxxxxx - биты типа кадра, SA и DA адреса отправителя и получателя, соответственно. FSC - (Frame Control Sequence) контрольная сумма (4 байта). ED - (End Delimiter) оконечный разграничитель =**1**11E (правый бит является 8-ым). MMM=000 - запрос, не требующий подтверждения; MMM=001 - запрос, требующий подтверждения, MMM=010 - отклик на запрос. PPP - биты приоритета (111 - высший приоритет, а 000 - низший). Значения кодов поля FC приведены в таблицах 4.1.3.1 и 4.1.3.2 (цифрами обозначен порядок передачи разрядов). Таблица 4.1.3.1. Коды поля FC
Станции получают доступ к шине в результате соревновательной процедуры, называемой "окно откликов". Окно откликов представляет собой временной интервал, равный по длительности одному системному такту, который в свою очередь равен времени распространения сигнала по шине. Это время отсчитывается от момента окончания передачи кадра управления. В течение этого времени станция-инициатор ожидает отклика от других станций. Любая станция сети, будучи владельцем маркера, может запустить этот процесс с помощью посылки кадра поиск следующей станции. Запросы на подключение осуществляются путем отправки пакета установка следующей станции, в поле данных которого записывается адрес станции, запрашивающей доступ к шине. Адрес следующей соседней станции меньше адреса станции-отправителя (маркер движется в направлении убывания адресов). Обычно посылается кадр с одним окном откликов. При этом запросы могут посылать станции с адресами не меньше, чем адрес ближайшего соседа. Если процесс инициализирован станцией с наименьшим номером, то посылается пакет с двумя окнами откликов, одно для станции с номером меньше, чем у предшественника, другое с адресом больше чем у предшественника. После этого станция ждет ответа в течение одного такта. Если ответа нет, маркер передается следующей станции. Если же получен один ответ, инициализируется подключение станции с помощью пакета установка следующей станции. При получении более одного отклика возникает конфликт, для разрешения которого посылается пакет разрешение конфликта с четырьмя окнами. Станции заносят свои запросы в окна в соответствии с первыми двумя битами своего адреса. Если попытка разрешить конфликт при этом не удалась, пакет осылается повторно. В новой попытке участвуют только станции, участвовавшие в первом раунде, а для сравнения используются уже следующие два бита адреса. Процедура может завершиться подключением одной из станций или исчерпыванием числа попыток. Станция может отключиться от сети в любое время, но это вызовет инициализацию системы и временное нарушение работы сети. Поэтому для отключения от сети станция должна дождаться получения маркера, после чего она шлет пакет типа установка следующей станции, в поле данных которого находится адрес ее преемника. Если держатель маркера получит пакет, показывающий наличие в сети еще одного владельца маркера, он уничтожает свой маркер и переходит в режим ожидания. Получив маркер, станция должна начать передачу данных или передать его следующей станции. После передачи маркера станция в течение одного цикла прослушивает сеть, чтобы убедиться в активности своего преемника. Если преемник не посылает ничего в течении секунды, станция повторяет передачу маркера. Если и это не помогает, то посылается пакет кто следующий? с адресом преемника в поле данных и тремя окнами откликов. Если станция обнаруживает в поле данных адрес своего предшественника, она посылает кадр типа установка следующей станции по адресу отправителя. В отсутствии кадра установка следующей станции станция посылает такой пакет самой себе с двумя окнами для выявления активных сетевых устройств. При обнаружении потери маркера запускается процедура инициализации сети, при этом посылается пакет требование маркера. Станция, пославшая запрос, прослушивает шину и при обнаружении сетевой активности выбывает из соревнования (имеется станция с большим, чем у нее адресом). В сети определено 4 класса обслуживания (6, 4, 2, 0). Станция может передавать данные класса 6 в течение допустимого времени удержания маркера THT (для класса 6). При M станций в сети максимальное время ожидания будет равно THT*M. По завершении передачи данных класса 6 (или если они не передавались вовсе) можно передавать данные класса 4. Аналогично определено время обращения маркера для классов 4, 2 и 0. Таблица 4.1.3.2. Коды поля FC и типы кадров
Сети все шире внедряются в промышленность, науку, а в последнее время можно ожидать появления сетей и в наших жилищах (первые опыты по созданию информационных сетей на основе систем кабельного телевидения в США и Канаде уже успешно проведены). Для сбора измерительной информации уже более десятилетия используется магистрально-модульный стандарт GPIB (IEC-625, IEEE-488 или ГОСТ 26.003-80). Но этот стандарт ограничивает размер сети, имеет дорогостоящий интерфейс, недостаточно надежен и гибок. Применение для этой цели RS-232 не слишком перспективно, так как этот интерфейс предполагает соединение по схеме точка-точка. Возникла необходимость создания сетей с дешевой магистралью и интерфейсом с пропускной способностью 128-1024 Кбит/c. Примером такой сети можно считать CAN. Кто знает, возможно спустя несколько лет какая-то модификация этой сети будет использована для сетевого управления бытовой техникой в вашей квартире. Аппаратная реализация узлов комплексного управления бытовой техникой уже появились в продаже. |
|||||||||||||||||||||||||||||||||||||||
|
Previous:
4.1.2 IEEE 802.5 (Token Ring)
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
||||||||||||||||||||||
|
4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||
|
Стандарт CAN (Controller Area Network - http://www.kvaser.se/can/protocol/index.htm или http://www.omegas.co.uk/can/canworks.htm, а также www.can-cia.de) был разработан в Германии компанией Robert Bosch gmbh для автомобильной промышленности (1970 годы). Сеть CAN ориентирована на последовательные каналы связи, выполненные из скрученных пар проводов (или оптических волокон), стандарт определяет протоколы физического уровня и субуровеней MAC и LLC. Все узлы сети равноправны и подключаются к общему каналу. Уровни сигналов протоколом не нормированы. В CAN использована кодировка типа NRZ (Non Return to Xero). Для распознавания сигнатур начала (SOF) и конца (EOF) кадра используется бит-стафинг. В настоящее время в ЕС разрабатывается новый протокол для сети автомобиля, который бы позволял передачу высококачественного стерео аудио и видео сигналов, обеспечивал работу с мобильными телефонными сетями и Интернет. Предполагается, что пропускная способность протокола составит 45 Мбит/c Высокая надежность и дешевизна сделала сети CAN привлекательными для промышленности и науки. Сеть предназначена для сбора информации и управления в реальном масштабе времени, но может быть использована и для других целей. Канал can реализует принцип множественного доступа с детектированием столкновений (CSMA/CD - Carrier Sense Multiple Access with Collision Detection, аналогично Ethernet). Сеть может содержать только один сегмент. В соответствии со стандартом ISO 11898 сеть способна работать при обрыве одного из проводов, при закоротке одного из проводов на шину питания или на землю. Скорость работы канала программируется и может достигать 1 Мбит/с. Недиструктивная схема арбитража позволяет сделать доступ к общему каналу существенно более эффективным, чем в случае Ethernet. В настоящее время действуют две версии стандарта с полями арбитража длиной в 11 бит (2.0a) и 29 бит (расширенная версия, 2.0b). Код арбитража одновременно является идентификатором кадра и задается на фазе инициализации сети. При одновременной попытке передачи кадров двумя узлами арбитраж выполняется побитно с использованием схемы проволочного "И", при этом доминантным состоянием является логический "0". Выигравший соревнование узел продолжает передачу, а проигравший ждет момента, когда канал освободится. Код-адрес объекта (узла CAN) задается с помощью переключателей на плате CAN при формировании сети. Когда канал свободен, любой из подключенных узлов, может начать передачу. Кадры могут иметь переменную, но конечную длину. Формат информационного кадра сети CAN, содержащего семь полей, показан на рис. 4.1.4.1.
Рис. 4.1.4.1 Стандартный информационный кадр 1 2.0a CAN Кадр начинается с доминантного бита начала кадра (логический нуль, SOF - start of frame). Далее следует поле арбитража (идентификатор кадра), содержащее 11 бит (эти разряды носят имена id-28, ..., id-18) и завершающееся битом RTR (remote transmission request) удаленного запроса передачи. В информационном кадре RTR=0, для кадра запроса RTR=1. Семь наиболее значимых бит id-28 - id-22 не должны быть никогда все одновременно равными 1. Первым передается бит id28. Доминантные биты r0 и r1 (=0) зарезервированы для будущего использования (в некоторых спецификациях бит r1 называется IDE и относится для стандартных кадров к полю управления). Поле DLC (Data Length Code; биты поля имеют имена dcl3 - dcl0) несет в себе код длины поля данных в байтах. Поле данных, размещенное вслед за ним, может иметь переменную длину или вообще отсутствовать. CRC - циклическая контрольная сумма. В качестве образующего полинома при вычислении CRC используется x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1. Формально, следующий за контрольной суммой бит-разграничитель (=1) принадлежит полю CRC. Поле отклика (ack) содержит два бита, первый из которых первоначально имеет уровень 1, а узлы получатели меняют его значение на доминантное (логический 0). Бит используется для сообщения о корректности контрольной суммы. Второй бит поля всегда имеет уровень логической 1. Завершающее поле EOF (end of frame) содержит семь единичных бит. За этим полем следует поле-заполнитель (INT) из трех единичных бит, после него может следовать очередной кадр. Формат расширенного информационного кадра сети can показан на рис. 4.1.4.2.
Рис. 4.1.4.2. Расширенный информационный кадр 2.0b CAN Однобитовое субполе SRR (substitute remote request) включено в поле арбитража (идентификатора кадра) и всегда содержит код 1, что гарантирует преимущество стандартного информационного кадра (2.0a) случае его соревнования с расширенным кадром (2.0b) (при равных 11 битах идентификатора). Субполе IDE (identifier extension) служит для идентификации расширенного формата и для этого типа кадра всегда имеет уровень логической 1. Вслед за IDE следует 18-битовое поле (биты имеют имена id-17, ..., id-0; первым передается бит id-28) расширения идентификатора кадра. Контроллеры 2.0b полностью совместимы с кадрами 2.0a и могут посылать и принимать пакеты обоих типов. Идентификаторы в пределах одной сети должны быть уникальными. Следует иметь в виду, что 18-битное поле расширения идентификатора можно при определенных условиях использовать и для передачи информации. Идентификатор не является адресом места назначения, а определяет назначение передаваемых данных (адресация по содержанию). По этой причине пакет может быть принят отдельным узлом, группой узлов, всеми узлами сети или не воспринят вообще. Предельное число различных идентификаторов для версии 2.0a составляет 2032, а для 2.0b превышает 500 миллионов. Послав кадр-запрос другому узлу, отправитель может затребовать присылку определенной информации. Удаленный узел должен откликнуться информационным кадром с тем же идентификатором, что и запрос. Если несколько узлов начнут передачу одновременно, право передать кадр будет предоставлено узлу с более высоким приоритетом, который задается идентификатором кадра. Механизм арбитража гарантирует, что ни информация, ни время не будут потеряны. Если одновременно начнется передача запроса и информационного кадра с равными идентификаторами, предпочтение будет дано информационному пакету. В процессе арбитража каждый передатчик сравнивает уровень передаваемого сигнала с реальным уровнем на шине. Если эти уровни идентичны, он может продолжить передачу, в противном случае передача прерывается и шина остается в распоряжении более приоритетного кадра. Протокол can имеет развитую систему диагностики ошибок. В результате вероятность не выявленной ошибки составляет менее 4.7╢ 10-11. При выявлении ошибки кадр отбрасывается и его передача повторяется. Число узлов, подключенных к каналу, протоколом не лимитируется. Практически такое ограничение налагается задержкой или предельной нагрузкой канала. Любой модуль can может быть переведен в пассивный режим ("состояние сна"), при котором внутренняя активность прекращается, а драйверы отключаются от канала. Выход из этого режима возможен либо по внутренним причинам, либо вследствие сетевой активности. После "пробуждения" модуль ждет, пока стабилизируется его внутренний тактовый генератор, после чего производится синхронизация его работы с тактами канала (11 тактов). Благодаря синхронизации отдельные узлы не могут начать передачу асинхронно (со сдвигом на часть такта). Протокол предусматривает использование четырех типов кадров:
Информационные кадры и удаленные запросы могут использовать как стандартные, так и расширенные форматы кадров (2.0a и 2.0b). Кадр удаленного запроса может иметь стандартный и расширенный форматы. В обоих случаях он содержит 6 полей: SOF, поле арбитража, поле управления, CRC, поля ACK и EOF. Для этого типа кадров бит RTR=1, а поле данных отсутствует вне зависимости от того, какой код содержится в субполе длины. Кадр сообщения об ошибке имеет только два поля - суперпозиция флагов ошибки и разграничитель ошибки. Флаги ошибки бывают активными и пассивными. Активный флаг состоит из шести нулевых бит, а пассивный - из шести единиц. Суперпозиция флагов может содержать от 6 до 12 бит. Разграничитель ошибки состоит из восьми единичных бит. Кадр перегрузки включает в себя два поля - перпозиция флагов перегрузки и разграничитель перегрузки (8 бит =1). В поле флаг ерегрузки записывается 6 бит, равных нулю (как и в поле флаг активной ошибки). Кадры ошибки или перегрузки не требуют межкадровых разделителей. Существует ряд условий перегрузки, каждое из которых вызывает посылку такого кадра:
Время пребывания канала в пассивном состоянии не нормировано. Появление доминантного бита на шине, пребывающей в пассивном состоянии, воспринимается как начало очередного кадра. Предусматривается возможность установления масок в узле на отдельные двоичные разряды идентификатора, что позволяет игнорировать их значения. Маскирование делает возможным мультикастинг-адресацию. Поля SOF, идентификатор, управляющее поле, данные и CRC кодируются таким образом, что при появлении пяти идентичных бит подряд, в поток вставляется бит противоположного уровня. Так 0000000 преобразуется в 00000100, а 1111110 в 11111010. Это правило не распространяется на CRC-разделители, поля ACK и EOF, а также на кадры сообщения об ошибке или переполнении. Существует 5 разновидностей ошибок (таблица 3.3.4.1). Таблица 4.1.4.1 Разновидности ошибок.
Любой узел CAN должен регистрировать и по запросу сообщать число ошибок при передаче и приеме. Номинальное время, выделенное для передачи одного бита, включает в себя четыре временные области: sync_seg, prop_seg, phase_seg1, phase_seg2 (рис.3.4.4.3).
Рис. 4.1.4.3 Временные зоны периода передачи одного бита Первая временная область (SYNC_SEG) служит для синхронизации работы различных узлов сети. Область PROP_SEG предназначена для компенсации временных задержек в сети и равна сумме времени распространения сигнала по каналу и задержки во входных компараторах. PHASE_SEG1 и PHASE_SEG2 служат для компенсации фазовых ошибок и могут увеличиваться или уменьшаться после синхронизации. T0 - минимальный квант времени, используемый для формирования временной шкалы в пределах периода передачи одного бита (длительность внутреннего такта может быть значительно короче). Момент стробирования определяет момент времени, когда проверяется состояние канала. Этот момент должен быть синхронным для всех узлов сети. Длительность этих временных областей может задаваться программно. Чем длиннее канал, тем меньшую скорость передачи информации он может обеспечить (см. табл. 3.3.4.2). Таблица 4.1.4.2 Зависимость пропускной способности канала от его длины
В сетях CAN используются 9-, 6- и 5-контактные разъемы. Тип разъема, или какие либо его характеристики стандартом не регламентируются. Разъем определяется протоколом HLP (High Layer Protocol). |
||||||||||||||||||||||
|
Previous:
4.1.3 IEEE 802.4 (Маркерная шина)
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.5 Локальные сети ArcNet
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
ARCNET - (attached resource computing network - смотри также http://www.smc.com/network/arcnet) представляет собой стандарт на локальные сети, разработанный корпорацией datapoint в 1977 году. Эта сеть базируется на идее маркерной шины и может позволить реализовать топологию шины, кольца или звезды при скорости обмена 2,5Мбит/с. Сеть строится вокруг активных и пассивных повторителей (HUB). Активные повторители (обычно 8-канальные) могут соединяться друг с другом, с пассивными повторителями/разветвителями и оконечными ЭВМ (рабочими станциями). Длина таких соединений, выполняемых 93-омным коаксиальным кабелем (RG-62, разъемы BNC), может достигать 600м. Допускается применение скрученных пар (RS485) или оптического волокна. Пассивный 4-входовый повторитель позволяет подключать до трех рабочих станций кабелем длиной до 35 м, один из входов всегда занят соединением с активным повторителем. Пассивные повторители не могут соединяться друг с другом. Активные повторители могут образовывать иерархическую структуру. Максимальное число рабочих станций в сети равно 255. Предельная суммарная длина кабелей многосегментной сети составляет около 7 км. Схема соединений в сети arcnet показана на рис. 4.1.5.1 (пунктиром обозначены возможные связи с другими активными повторителями или маршрутизаторами). В настоящее время разработан стандарт arcnet plus, рассчитанный на скорость обмена до 20 Мбит/с, совместимый с прежней версией. Новый стандарт позволяет строить сети с числом станций в 8 раз больше, чем старый. Если в сети присутствуют узлы, рассчитанные на разную скорость обмена, выбор полосы пропускания осуществляется при установлении связи. Соединение с другими сетями (например, Ethernet, Token Ring или Интернет) возможно через специальные шлюзы, мосты или маршрутизаторы. Каждому узлу в сети присваивается уникальный адрес в диапазоне от 1 до 255. Стандарт arcnet поддерживает работу с пакетами двух длин: <253 или 506. Отличительной особенностью сети является низкая избыточность - заголовки пакетов имеют длину 3-4 байта. Все пакеты в arcnet начинаются с байта, содержащего единицы во всех разрядах. Всего в arcnet используется пять разновидностей пакетов:
Сеть Arcnet допускает фрагментацию (ANSI 878.2) сообщений и инкапсуляцию (ansi 878.3) пакетов, отвечающих требованиям других протоколов.
Рис. 4.1.5.1. Топологическая схема сети Arcnet Все кадры начинаются с аппаратного заголовка и завершаются пользовательскими данными, в начале которых всегда присутствует программный заголовок. Между аппаратным и программным заголовками вводится заполнитель, обеспечивающий постоянство длин пакетов. Этот заполнитель удаляется интерфейсом так, что программа его не видит. Короткие кадры могут содержать от 0 до 249 байт полезной информации. Длинные кадры могут нести от 253 до 504 байт. Для того, чтобы иметь возможность работать с кадрами, содержащими 250, 251 или 252 байт информации, введен специальный формат (exception). Форматы этих кадров ARCNET представлены на рис. 4.1.5.2. Эти пакеты представлены так, как их видит программное прикладное обеспечение, по этой причине это представление иногда называется "буферным". Пакеты в сети выглядят несколько иначе: идентификатор места назначения дублируется, заполнитель между полем смещения и идентификатором протокола вообще не пересылается. arcnet позволяет делить длинные внешние пакеты или сообщения на ряд фрагментов, максимальное число которых может достигать 120. Поле флаг фрагментации указывает на наличие фрагментации пакета. Не фрагментированные пакеты имеют этот флаг равный нулю. Для первого пакета фрагментированного сообщения этот флаг равен ((t-2)*2)+1, где t - полное число фрагментов.
Рис. 4.1.5.2 Форматы кадров ARCNET Пакеты, несущие в себе последующие части сообщения, имеют в этом поле код равный ((N-1)*2), где N - номер фрагмента. Так пятый фрагмент сообщения будет содержать в поле флага фрагментации код 8. Принимающая станция может идентифицировать последний фрагмент сообщения, так как он будет иметь флаг фрагментации больше, чем у первого фрагмента. Значения флага фрагментации более 0xEE запрещены. Значение флага фрагментации 0xFF используется для пометки кадров специального формата (exception). Все фрагменты одного и того же сообщения имеют идентичные поля номера по порядку. IP и ARP-дейтограммы инкапсулируются в соответствующие ARCNET пакеты. Если длина дейтограмм превосходит 504 октета, они делятся на фрагменты и пересылаются по частям. Взаимосвязь IP- и 8-битных ARCNET адресов осуществляется с помощью протокола ARP (см. RFC-826. Plammer D., "An Ethernet Address Resolution Protocol", MIT, Nov. 1982). Можно устроить так, чтобы младшие 8 бит IP-адреса совпадали с ARCNET адресом. В этом случае ARP-протокол не потребуется. Но этот путь не рекомендуется, так как он менее гибок. Все широковещательные и мультикастинг IP-адреса должны соответствовать ARCNET-адресу 0. Корпорация Datapoint использует следующие идентификаторы протоколов: 212 (десятичное) для IP, 213 - для ARP и 214 - для протокола RARP. Сети ARCNET отличаются дешевизной, простотой установки и эксплуатации. За последнее время в связи с резким удешевлением Ethernet-интерфейсов это преимущество несколько нивелировалось. Взаимодействие ARCNET и Интернет описано в документе STD-46. |
|
Previous:
4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||
|
4.1.6 Сети FDDI
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||
|
Одной из наиболее популярных сетей, использующих оптическое волокно, (не считая fast ethernet) является FDDI. FDDI (fiber distributed data interface, ISO 9314-1, rfc-1512, -1390, -1329, -1285 - смотри также http://iquest.com/~nmaller/fddi.htm) стандарт американского института стандартов (ansi), принятый без изменения ISO. Протокол рассчитан на физическую скорость передачи информации 100 Мбит/с и предназначен для сетей с суммарной длиной до 100км (40 км для мультимодовых волокон) при расстоянии между узлами 2 км или более. Частота ошибок в сети не превышает 10-9. В FDDI используется схема двойного кольцевого счетчика (рис. 4.1.6.1; буквами a,b,c,d и e обозначены станции-концентраторы). Кольцевая схема единственно возможное решение для оптического волокна (не считая схемы точка-точка). Для доступа к сети используется специальный маркер (развитие протокола IEEE 802.5 - Token Ring). Сети FDDI не имеют себе равных при построении опорных магистралей (backbone) локальных сетей, позволяя реализовать принципиально новые возможности - удаленную обработку изображений и интерактивную графику. Обычно устройства (DAS - dual attached station) подключаются к обоим кольцам одновременно. Пакеты по этим кольцам движутся в противоположных направлениях. В норме только одно кольцо активно (первичное), но при возникновении сбоя (отказ в одном из узлов) активизируется и второе кольцо, что заметно повышает надежность системы, позволяя обойти неисправный участок (схема соединений внутри станций-концентраторов на рис. 4.1.6.1 является сильно упрощенной). Предусмотрена возможность подключения станций и только к одному кольцу (SAS - single attached station), что заметно дешевле. К одному кольцу можно подключить до 500 das и 1000 sas. Сервер и клиент имеют разные типы интерфейсов.
Рис. 4.1.6.1. Схема связей в двойном кольце FDDI Топология связей в FDDI устроена таким образом, что отказ в любом из узлов из-за выхода из строя оборудования или отключения питания не приведет к разрыву кольца, поток кадров автоматически пойдет в обход поврежденного участка. FDDI позволяет работать с кадрами размером 4500 октетов, за вычетом места, занимаемого преамбулой, остается 4470 октетов для передачи данных. RFC-1188 резервирует 256 октетов для заголовков, оставляя для данных 4096 октетов. Маршрутизатор, поддерживающий протокол FDDI должен быть способен принимать такие длинные пакеты. Посылаться же должны дейтограммы не длиннее 576 октетов, если не ясно, сможет ли адресат принимать длинные кадры. Услуги информационного канала (data link service) реализуются через протокол IEEE 802.2 logical link control (LLC). В результате мы имеем следующий стек протоколов (рис. 4.1.6.2):
Рис. 4.1.6.2. Схема протокольных подуровней для FDDI Уровень MAC (media access control) определяет доступ к сетевой среде, включая формат кадров, адресацию, алгоритм вычисления crc и механизм исправления ошибок. Уровень PHY (physical layer protocol) задает процедуру кодирования/декодирования, синхронизацию, формирование кадров и пр. В качестве базовой используется кодировка 4b/5b (преобразование 4-битного кода в 5-битный), а в канале - NRZI. Уровень PMD (physical layer medium) определяет характеристики транспортной среды, включая оптические каналы, уровни питания, регламентирует частоту ошибок, задает требования к оптическим компонентам и разъемам. Блок схема интерфейса между уровнями MAC и PHY показана на рис. 4.1.6.3.
Рис. 4.1.6.3. Схема физического интерфейса FDDI ip-дейтограммы, ARP-запросы и отклики, пересылаемые по сети FDDI, должны инкапсулироваться в пакеты 802.2 LLC и SNAP (subnetwork access protocol; см. рис. 4.1.6.4 и 4.1.6.5), а на физическом уровне в FDDI MAC. Протокол snap должен использоваться с организационными кодами, указывающими, что SNAP-заголовок содержит код Ethertype. 24-битовый организационный код (organization code) в snap должен быть равен нулю, а остальные 16 бит должны соответствовать Ethertype (см. assigned numbers, RFC-1700; IP=2048, ARP=2054). Все кадры должны пересылаться в соответствии со стандартом 802.2 LLC тип 1 (формат ненумерованной информации, с полями DSAP (destination service access point) и SSAP (source service access point) заголовка 802.2, равными предписанным значениям SAP (service access point) для SNAP.
Рис. 4.1.6.4. Структура некоторых полей заголовков пакетов Полная длина LLC- и SNAP-заголовков составляет 8 октетов. Десятичное значение k1 равно 170 . Для преобразования 16- или 48-разрядного FDDI-адреса в 32-разрядный IP-адрес используется протокол ARP. Операционный код равен 1 для запроса и 2 для отклика. Спецификация FDDI MAC определяет максимальный размер кадра равным 4500 октетам, включая 16-октетную преамбулу. Преамбула состоит из кодов 11111, стартовый разделитель имеет вид 1100010001, а оконечный разделитель - 0110101101 (во всех случаях применена 5-битовая нотация). Контрольная сумма CRC вычисляется для полей, начиная с поля управление по данные включительно.
Рис. 4.1.6.5. Формат пакета протокола FDDI Вычитая 8 байт LLC/SNAP заголовка, получаем значения максимального размера пакета (MTU) 4470 (4478) октетов. Для совместимости размер пакетов для IP-дейтограмм и ARP-пакетов согласуется с требованиями конкретной сети. FDDI реализует маркерный доступ, формат пакета-маркера имеет вид, показанный на рис. 4.1.6.6. В зависимости от размера кольца в нем могут циркулировать несколько маркеров.
Рис. 4.1.6.6. Формат кадра-маркера 802.2 класс I LLC требует поддержки команд ненумерованная информация (UI), команд и откликов exchange identification (XID), а также test. Станции не обязаны уметь передавать команды XID и test, но должны быть способны посылать отклики. Командные кадры идентифицируются по нулевому младшему биту SSAP-адреса. Кадры-отклики имеют младший бит SSAP-адреса равный 1. UI-команды содержат в управляющем поле LLC код 3. Команды/отклики XID имеют код поля LLC, равный 175 (значение десятичное) при значении бита poll/final=0 или 191 при poll/final=1. Код управления LLC для команд/откликов test равен 227, если poll/final=0, и 243 при poll/final=1. Отклики и команды UI при poll=1 игнорируются. Команды UI, имеющие отличные от snap sap в DSAP- или SSAP-полях, не считаются пакетами IP или ARP. При получении команд XID или test должен быть послан соответствующий отклик. Отклик посылается, когда DSAP равен SNAP SAP (170), null SAP (0), или при global SAP (255). При других DSAP отклики не посылаются. При посылке отклика на команды XID или test, значение бита final отклика должно быть равно значению бита poll команды. Кадр отклика XID должен включать в себя информационное поле 802.2 XID 129.1.0, указывающее на класс услуг 1 (не требующих установления связи). Кадры отклика test должны соответствовать информационному полю кадра команды test. Для начала передачи станция должна получить в свое распоряжение маркер. Если станция находится в пассивном состоянии, она передает маркер следующей станции. Но из-за большой протяженности колец FDDI время задержки здесь заметно больше, чем в случае Token Ring. В кольце FDDI может находиться несколько кадров одновременно. Станция сама удаляет кадры из кольца, посланные ей самой. Все станции должны иметь таймер вращения маркера (TRT - token rotation time), который измеряет время с момента, когда станция последний раз принимала этот пакет. Имеется переменная TTRT (target token rotation time). Значение TRT сравнивается с TTRT и только приоритетные кадры могут быть переданы при TRT> TTRT. Обычная передача данных контролируется таймером THT (token hold timer). Когда станция получает маркер, она заносит TRT в таймер THT, который начинает обратный отсчет. Станция может посылать кадры до тех пор, пока THT остается больше TTRT. В действительности THT определяет максимальное число октетов (символов), которое может быть послано станцией в рамках одного кадра (THT задает предельное время, в течение которого станция может передавать данные). IEEE специфицирует числа как последовательности бит, где младший бит передается первым. В протоколах Интернет порядок бит другой, что может вызывать ошибки. Ниже приведена краткая таблица (4.1.6.1) соответствия для некоторых из чисел. Таблица 4.1.6.1
Оптоволокно особенно привлекательно для сетей, где ЭВМ размещены в далеко отстоящих друг от друга зданиях и при высоком уровне электромагнитных наводок. Оптоволокно является незаменимой средой для широкополосных каналов связей (вспомним теорему Шеннона). Привлекательна такая среда и с точки зрения надежности (бульдозеры, рвущие кабель, не в счет) и безопасности (отсутствие внешних излучений). Расстояние между станциями при использовании такого кабеля может достигать 8-9 км (а не 2 км, как в случае многомодового кабеля с полосой 500МГц/км). Зарубежные одномодовые кабели группы 1 допускают максимальное расстояние между узлами в 10 км, а группы 2 - 40 км при полосе пропускания 1 Гбит/с. Подключение к сети fddi производится обычно через фотооптические трансиверы (ФОТ), которые преобразуют оптический сигнал в электрический. Источником света является светоизлучающий диод с длиной волны 1350 или 1500 нм. Толщина передающего оптоволокна равна 50/125 или 62.5/125 микрон (числитель - диаметр несущего свет волокна; знаменатель - внешний диаметр клэдинга; числа относятся к мультимодовому волокну). При выборе того или иного кабеля следует иметь в виду, что ослабление более 11дБ не допустимо, при большем ослаблении число ошибок в процессе передачи становится слишком большим. Именно это ограничение ставит верхний предел на длину при использовании многомодового волокна (при длине 2 км ослабление достигает 10,5 дБ). Выбирая оптические разъемы, нужно помнить, что хороший разъем не должен вносить ослабление более 2 дБ. Там где это возможно, предпочтительнее сварка волокон, которая при качественном исполнении вносит ослабление сигнала не более 0,3 дБ. На случай выхода из строя оборудования или отключения питания удобно использовать обводящие оптические переключатели (но они вносят ослабление около 2.5-4 дБ). При их использовании предельное расстояние между узлами должно быть сокращено более чем вдвое. Если видно, что потери достигают критического уровня, следует выбирать кабель с волокном 62.5/125 микрон. При прокладке оптического кабеля нельзя допускать слишком малых радиусов перегибов (возможен обрыв волокна, увеличиваются потери света). Кабели, относящиеся к разным кольцам fddi, следует разнести, в этом случае один бульдозер не сможет оборвать сразу оба кабеля. FDDI-кадры используют заголовки, определяемые стандартом IEEE 802.2 (LLC - logical link control), который не имеет поля тип, присутствующий в Ethernet-заголовке. FDDI и ethernet имеют разный порядок передачи битов, поэтому мосты и маршрутизаторы между FDDI и Ethernet должны уметь выполнять соответствующие преобразования. В силу особенностей маршрутизаторов не все протоколы могут быть реализованы на стыке FDDI и Ethernet (например, DEC LAT работать не будет). Для решения проблемы созданы гибридные приборы (brouter), которые для одних протоколов работают как маршрутизаторы, являясь мостами для других. Эти приборы для одних пакетов прозрачны, другие же пересылаются с использованием инкапсуляции. Учитывая то, что FDDI может пересылать до 400000 пакетов в секунду, схемы распознавания адресов моста должна иметь соответствующее быстродействие. Нетрадиционным для других сетей является концентратор, используемый в FDDI. Он позволяет подключить несколько приборов SAS-типа к стандартному FDDI-кольцу, создавая структуры типа дерева. Но такие структуры несут в себе определенные ограничения на длины сетевых элементов, так при использовании повторителя удаление не должно превышать 1,5 км, а в случае моста 2,5 км (одномодовый вариант). Несмотря на эти ограничения и то, что базовой топологией сетей FDDI является кольцо, звездообразные варианты также имеют право на жизнь, допустимы и комбинации этих топологий. В пределах одного здания подключение целесообразно делать через концентратор, отдельные же здания объединяются по схеме кольцо. К кольцу FDDI могут также легко подключаться и субсети Token Ring (через мост или маршрутизатор). Концентраторы бывают двух типов: DAS и SAS. Такие приборы повышают надежность сети, так как не вынуждают сеть при отключении отдельного прибора переходить в аварийный режим обхода. Применение концентраторов снижает и стоимость подключения к FDDI. Концентраторы могут помочь при создании небольших групповых субсетей, предназначенных для решения специфических задач (например, CAD, CAM или обработка изображений). Новым устройством, используемым в FDDI-узлах, являются межузловые процессоры (internetwork nodal processor - INP), которые являются развитием идей front end processor (FEP). INP, благодаря модульности, может помочь пользователю адаптироваться к изменениям, постоянно происходящим в сетях, где он работает. INP может выполнять функции многопротокольного моста или маршрутизатора. Управление FDDI-оборудованием производится с помощью протокола SNMP и базы данных MIB. Предусмотрены некоторые дополнительные диагностические средства, которые выявляют не только аппаратные сбои, но и некоторые программные ошибки. Применение мостов для объединения FDDI-сетей позволяет обеспечить высокую степень сетевой безопасности и решить многие топологические проблемы, снять ограничения с предельного числа DAS-подключений (<500). Выбор между мостом и маршрутизатором определяется тем, что важнее, стоимость, гибкость системы илу высокая пропускная способность. На рис. 4.1.6.7 показан пример использования сети FDDI для доступа нескольких субсетей к общему серверу без взаимного влияния потоков данных. Сегменты 1 и 2 представляют собой субсети Ethernet (10 Мбит/с). Учитывая то, что FDDI имеет пропускную способность 100 Мбит/с, даже при подключении 10 субсетей взаимовлияние их будет практически отсутствовать. Два кольца FDDI, показанные на рис. 4.1.6.7, могут быть объединены друг с другом через мост или маршрутизатор. Сетям FDDI благодаря маркерному доступу не знакомы столкновения в том виде, в каком они существуют в Ethernet и это дает им определенное преимущество перед сетями равного быстродействия, например перед быстрым Ethernet (также 100 МГц). Существует версия FDDI приспособленная для передачи мультимедийной информации. Возможна реализация FDDI на скрученных парах проводов.
Рис. 4.1.6.7. Схема использования кольца FDDI для расширения пропускной способности локальной сети При обрывах оптоволокна возможно частичное (при двух обрывах) или полное (при одном обрыве) восстановление связности сети.
Рис. 4.1.6.8. Варианты связей в случае обрывов волокон |
|||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.1.5 Локальные сети ArcNet
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.7 Параллельный сетевой интерфейс HIPPI
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Все рассматриваемые до сих пор системы передачи информации использовали исключительно последовательный код. На разных этапах эволюции телекоммуникаций предпочтение отдавалось и параллельному и последовательному методам обмена данными. В данный момент параллельный интерфейс сохранился только для подключения принтеров. Главным преимуществом последовательных схем передачи информации является экономия на кабелях. Ниже описан еще один стандарт, где применен параллельный интерфейс (начало разработки относится к 1987 году). HIPPI (high performance parallel interface, смотри ftp.network.com; http://www.cern.ch/hsi/hippi/spec/introduc.htm; RFC-2067, IP over HIPPI, J.Renwick; RFC-1374, IP and ARP on HIPPI, J.Renwick, ANSI x3t9.3/90-043, 1990 и X3t9.3/91-005) представляет собой быстродействующий параллельный интерфейс, рассчитанный на пропускную способность 800 Мбит/с (но возможны версии со 100, 200 400 и 1600 Мбит/с). Разработка интерфейса выполнена в Лос-Аламосе. Позднее на базе этого интерфейса была подготовлена идеология сети. Длина кода, передаваемого за один такт в HIPPI, составляет 32 разряда (версия HIPPI, рассчитанная на скорость 1600 Мбит/с, имеет длину кода 64 бита). Все пересылки являются симплексными. Существует стандарт Superhippi (HIPPI-6400, 6,4 Гбайт/с), который описывает систему передачи данных в 8 раз более быстродействующую, чем HIPPI. Разработана версия последовательного HIPPI на скорость обмена 1,2 Гбод для коаксиального и оптоволоконного кабеля (до 10км; версия HIPPI-FC - fiber channel). Максимальное расстояние между станцией и переключателем составляет 25 м. Максимальное дистанция между станциями (станция-переключатель-станция) равно 50 м. Предельное число станций зависит от типа используемых переключателей. Переключатели могут взаимодействовать друг с другом (HIPPI-SC), обеспечивая информационный обмен между станциями. Пример топологии сети hippi представлен на рис. 4.1.7.1.
Рис. 4.1.7.1. Пример топологии сети hippi (П - переключатели, С - станции) HIPPI предполагает передачу данных по медному кабелю (или оптическому волокну) только в одном направлении по схеме связи точка-точка, но два канала HIPPI могут обеспечить и двунаправленный обмен данными. Передающий кабель может содержать 50/100 скрученных пар или соответствующее число оптических волокон. Длина пакета данных может варьироваться. Протокол HIPPI рассчитан на работу в реальном масштабе времени при суммарных длинах кабелей до десятков километров. Стандартный блок данных содержит 256 слов (1024 или 2048 байт). Для контроля корректности передачи предусмотрен контроль по четности для каждого байта на шине, кроме того, для каждого блока данных вычисляется "продольная" контрольная сумма (LLRC - length/longitudinal redundancy checkword). На рис. 4.1.7.2 показана схема передачи данных в рамках протокола HIPPI. На каждое соединение может быть передано любое число пакетов, пакет в свою очередь может содержать любое число блоков. Время между пакетами не регламентировано и может меняться, оно зависит от потока данных и протокола верхнего уровня.
Рис. 4.7.1.2. Структура передаваемой информации (каждое слово содержит 32 или 64 бита) Каждый пакет содержит в конце субполе контроля четности. Все сигналы кроме соединения (interconnect) используют приемники и передатчики эмиттерно-связанной логики (ECL). Формат I-поля показан на рис 4.1.7.3.
Рис. 4.1.7.3. Формат i-поля пакета HIPPI Поле L=1 - локально заданный формат; W=1 указывает на 64-битное соединение; D=1 отмечает смену положения адресов отправителя и получателя; PS - биты выбора пути (path selection); С - задержка вызова при занятой линии (camp-on; переключатель не разрывает соединения при занятом получателе, а ждет его освобождения). 12-битовые адреса отправителя и получателя часто делятся на 6-битовые секции, определяющие адрес переключателя и номер порта. HIPPI-IPI (intelligent peripheral interface) представляет собой быстродействующий интерфейс периферийных устройств, выполняющий команды SCSI. Расширение HIPPI-LE (link encapsulation) обеспечивает поддержку IEEE 802.2. При расстояниях до 25 метров используется кабель, содержащий 50 скрученных пар. Такты часов следуют с периодом 40 нсек. В сетях HIPPI предусмотрен транзит пакетов формата TCP/IP. Блок-схема канала HIPPI показана на рис. 4.1.7.4.
Рис. 4.1.7.4. Блок-схема канала HIPPI Существуют документы, регламентирующие работу системы передачи информации HIPPI для основных уровней интерфейса, начиная с физического. Предусмотрена работа HIPPI с протоколами TCP/IP. Смотри также "ARP and IP Broadcast over HIPPI-800". J.-M. Pittet. May 2000, RFC-2834, "IP and ARP over HIPPI-6400 (GSN)". J.-M. Pittet. May 2000, RFC-2835. |
|
Previous:
4.1.6 Сети FDDI
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.8 Сети IEEE 802.11
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Технология беспроводных сетей развивается довольно быстро. Эти сети удобны для подвижных средств в первую очередь. Наиболее перспективным представляется проект IEEE 802.11, который должен играть для радиосетей такую же интегрирующую роль как 802.3 для сетей Ethernet и 802.5 для Token Ring. В протоколе 802.11 используется тот же алгоритм доступа и подавления cтолкновений, что и в 802.3, но здесь вместо соединительного кабеля используются радиоволны (Рис. 4.1.8.1.)
Рис. 4.1.8.1. Схема беспроводной локальной сети Стандарт 802.11 предполагает работу на частоте 2.4-2.4835 ГГц при использовании 4FSK/2FSK FHSS модуляции, мощность передатчика 10мВт-1Вт. Максимальная пропускная способность сети составляет 2 Мбит/с. В 1992 году страны члены ЕС выделили диапазон частот 1,89-1,9 ГГц для целей построения сетей, базирующихся на применение радиосигналов (стандарт DECT - Digital European Cordless Telecommunications). Этот стандарт был разработан для целей передачи данных и голоса в системах сотовой связи. В США для этих же целей используются широкополосные системы с шумоподобным сигналом (SST - ШПС). Для подобных же целей выделены также частотные диапазоны 18 и 60ГГц (диапазон 2,4 ГГц сильно перегружен и "засорен" шумами). Существуют уже системы базирующиеся на Ethernet и Token Ring. При относительно малых расстояниях проблем обычно не возникает и работу беспроводной сети действительно можно аппроксимировать алгоритмом CSMA. Но в случае, когда расстояние между передатчиком и приемником сравнимо с радиусом надежной связи, отличие от традиционных сетей становится значительным. Ведь для радиосетей важна интерференция на входе приемника, а не на выходе передатчика (как в CSMA). Рассмотрим вариант сети, изображенный на рис. 4.1.8.2. Если передачу осуществляет узел А, узел С находится вне его радиуса действия и может решить, что можно начать передачу. Излучение передатчика С может вызвать помехи на входе узла В (проблема скрытой станции).
Рис. 4.1.8.2. Схема взаимодействия узлов в беспроводной сети (MACA) В случае, когда передачу ведет узел В, узел С может решить, что начало передачи сообщения узлу D не возможно, так как в зоне С детектируется излучение станции В (проблема засвеченной станции). Таким образом, в радиосетях, прежде чем начать передачу данных надо знать, имеется ли радио активность в зоне приемника-адресата. В коротковолновых сетях возможна одновременная передача для нескольких адресатов, если они находятся в разных зонах приема. Ранние протоколы беспроводных локальных сетей базировались на схеме MACA (Multiple Access with Collision Avoidance), разработанной Ф. Карном в 1990 году. Эта схема является основой стандарта IEEE 802.11. В этой схеме отправитель запрашивает получателя послать короткий кадр, будучи принят соседями, предотвратит их передачу на время последующей передачи сообщения адресату. На рис. 4.1.8.2 узел В посылает кадр RTS (Request To Send) узлу C. Этот кадр имеет всего 30 октетов и содержит поле длины последующего сообщения. Узел C откликается посылкой кадра CTS (Clear To Send), куда копируется код длины последующего обмена из кадра RTS. После этого узел В начинает передачу. Окружающие станции, например D или E, получив CTS, воздерживаются от начала передачи на время, достаточное для передачи сообщения оговоренной длины. Станция A находится в зоне действия станции B, но не станции C и по этой причине не получит кадр CTS. По этой причине станция A может начинать передачу, если хочет и не имеет других причин, препятствующих этому. Несмотря на все предосторожности коллизия может иметь место. Например, станции A и C могут одновременно послать кадры RTS станции B. Эти кадры будут неизбежно потеряны, после псевдослучайной выдержки эти станции могут совершить повторную попытку (как в ETHERNET). В 1994 году схема MACA была усовершенствована и получила название MACAW. Было отмечено, что без подтверждения на канальном уровне потерянные кадры не будут переданы повторно, пока транспортный уровень много позднее не обнаружит их отсутствия. В усовершенствованной схеме требуется подтверждение получения любого информационного кадра, добавлен также механизм оповещения о перегрузке. К сожалению беспроводные, особенно мобильные каналы крайне ненадежны. Потери пакетов в таких каналах весьма вероятны. Понижение скорости передачи, как правило, не приводит к понижению вероятности потери. Кроме того, проходы от отправителя к получателю здесь неоднородны и могут включать в себя сегменты с различными методами транспортировки данных (проводные и беспроводные). В таких структурах бывает полезно разбить канал на две последовательные связи (indirect TCP). Преимуществом такой схемы является то, что оба виртуальных канала являются однородными. Таймауты в одном из соединений заставят отправителя замедлить темп передачи, в то время как таймауты во втором - могут ускорить обмен. Да и все остальные параметры связей могут оптимизироваться независимо. Основной недостаток этого приема заключается в нарушении базового принципа организации TCP-соединений на основе сокетов, здесь получение подтверждения отправителем не означает благополучной доставки. В 1995 году была предложена схема, не нарушающая TCP-семантику. В этой схеме вводится специальный агент-наблюдатель, который отслеживает состояние кэшей отправителя и получателя и посылает подтверждения. Этот агент при отсутствии своевременного подтверждения запускает процедуру повторной посылки сегмента, не информируя об этом первичного отправителя. Механизмы подавления перегрузки запускаются в этом варианте только при перегрузке проводной секции канала. При потерях реализуется выборочная пересылка сегментов. При работе с UDP также возникают некоторые трудности. Хотя известно, что UDP не гарантирует доставки, большинство программ, предполагает, что вероятность потери невелика. Программы используют такие способы преодоления потерь, которые при высокой вероятности потери просто не срабатывают. Многие приложения предполагают наличие достаточного запаса пропускной способности, чего в случае мобильной связи обычно нет. В последнее время в продажу поступили радио-интерфейсы (IEEE 802.11b) для персональных ЭВМ, которые позволяют создавать небольшие офисные сети. Пригодны они и для подключения к каналам Интернет, но в этом случае следует позаботиться о специальной антенне. Такие интерфейсы работают на несущей частоте 2,4-5,0 ГГц и обеспечивают пропускную способность 11-22Мбит/с при расстояниях 700-5000м. Особую привлекательность такие интерфейсы представляют для мобильных ЭВМ. См. LANline Spezial VII/2002, Nov/Dez s16; LANline |
|
Previous:
4.1.7 Параллельный сетевой интерфейс HIPPI
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.8.1 Мобильные телекоммуникации
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
В 80-х - 90-х годах весьма активное развитие получила мобильная телефония. В последнее время услуги мобильной связи стали применяться и для передачи цифровых данных. Мобильные телекоммуникации использует диапазоны в интервале 50 МГц - 1 ГГц. Мобильные системы работают при малых выходных мощностях передатчика, что ограничивает размер зоны приема. Вне этой зоны другие передатчики могут функционировать независимо. Такие зоны называются сотами (ячейками). По аналогии с пчелиными сотами их часто изображают шестигранными, хотя реально они могут иметь самую причудливую форму в зависимости от профиля местности. Ячейки должны перекрываться, так как показано на рис. 4.1.8.1.1
Рис. 4.1.8.1.1. Схема расположения ячеек при сотовой связи Светлыми кружками отмечены реальные границы ячеек, их перекрытие должно обеспечить перекрытие всей зоны телекоммуникаций. В центре ячейки находится базовая станция ретранслятор. Такая станция содержит в себе ЭВМ и приемо-передатчик, соединенный с антенной. Такие системы могут обслуживать пейджерную или мобильную телефонную сеть. Пейджерные каналы однонаправлены а телефонные двунапрвлены (см. рис. 4.1.8.1.2). Пейджинговые системы требуют небольшой полосы пропускания. А одно сообщение редко содержит более 30 байт. Большинство современных пейджигновых систем работает в частотном диапазоне 930-932 МГц (старые занимали 150-174 МГц).
Рис. 4.1.8.1.2. Каналы пейджерной (слева) и мобильной телефонной сети (справа). В небольших системах все базовые станции соединены с MTSO(mobile telephone switching office). В больших сетях может потребоваться несколько MTSO, которые в свою очередь управляются mtso следующего уровня и т.д.. Узловая MTSO соединена со станцией коммутируемой телефонной сети. В любой момент времени каждый мобильный телефон логически находится в одной определенной ячейке и управляется одной базовой станцией. Когда телефон покидает ячейку, базовая станция обнаруживает падение уровня сигнала и запрашивает окружающие станции об уровне сигнала для данного аппарата. Управление аппаратом передается станции с наибольшим входным сигналом. Телефон информируется о смене управляющей станции, при этом предлагается переключиться на новый частотный канал (в смежных ячейках должны использоваться разные частотные каналы). Процесс переключения занимает около 300 мсек (handoff), что должно быть практически незаметно для пользователя. Присвоением частот управляет MTSO. Сигнал передатчика падает по мере удаления от центра ячейки, где он должен быть расположен. Там же должен находиться и приемник. В пределах ячейки предусмотрено несколько каналов для приема/передачи, разнесенные по частоте. Эти каналы управляются центральным коммутатором ячейки (MSC - mobile-service switching centre). В рамках американского стандарта первого поколения AMPS (advanced mobile phone service; 1982) формируется 40 МГц канал в интервале 800-900 МГц. Система использует 832 полнодуплексных каналов. Данный частотный диапазон делится пополам, 20 МГц выделяется для передачи и столько же для приема. Данные диапазоны делятся в свою очередь на 666 двусторонних каналов, каждый по 30 кГц. Эти каналы расщепляются на 21 субканал, сгруппированные по 3. Обычно, как показано на рис. 4.1.8.1.1, гексагональные ячейки группируются по 7 (центральная и 6 ее соседей). Имея 666 каналов, можно выделить три набора по 31 каналу для каждой ячейки. Такая схема удобна в случае возникновения необходимости увеличения числа каналов, для этого достаточно уменьшить размер ячейки - число ячеек увеличится и, как следствие, увеличится число каналов на единицу площади. В хорошо спланированной сети плотность ячеек пропорциональна плотности пользователей. AMPS для разделения каналов использует метод мультиплексирования по частоте. Каждый мобильный телефон в amps имеет 32-битовый серийный номер и телефонный номер, характеризуемый 10 цифрами. Телефонный номер представляется как код зоны (3 десятичные цифры) и номер подписчика (7 десятичных цифр). Когда телефон включается, он сканирует список из 21 управляющих каналов и находит тот, у которого наиболее мощный сигнал. Управляющая информация передается в цифровой форме, хотя сам голосовой сигнал является аналоговым. При нормальной работе мобильный телефон перерегистрируется в MTSO (mobile telephone switching office) каждые 15 мин. При осуществлении вызова пользователь набирает номер телефона и нажимает кнопку send. Аппарат посылает набранный номер и свой идентификационный код. Базовая станция принимает вызов и передает его MTSO. Если звонящий является клиентом mtso или ее партнером, ишется свободный канал и мобильный телефон переключается на него, ожидая когда адресат снимет трубку. В режиме приема аппарат постоянно прослушивает канал пейджинга, чтобы обнаружить обращенный к нему вызов. Осуществляется обмен командными сообщениями с MTSO, после чего раздается звонок вызова. Аналоговые сотовые телефоны не обеспечивают конфиденциальности. С помощью широкополосного сканера можно зафиксировать вызов и осуществить прослушивание. Другим недостатком является возможность кражи эфирного времени. Вседиапазонный приемник, подключенный к ЭВМ, может записать 32-битовый серийный номер и 34-битовый телефонный номер всех телефонов, работающих поблизости. Собрав такие данные вор может по очереди пользоваться любым из перехваченных номеров. AMPS базируется на аналоговой модуляции, существует еще полдюжины аналогичных не стыкуемых друг с другом систем. В последнее время аналоговая модуляция повсеместно вытесняется цифровой. В Европе принят единый стандарт для систем мобильной связи GSM (groupe special mobile, второе поколение мобильных средств связи). gsm использует диапазоны 900 и 1800 МГц. Это довольно сложный стандарт, его описание занимает около 5000 страниц. Идеологически система имеет много общего с ISDN (например, переадресацию вызовов). GSM имеет 200 полнодуплексных каналов на ячейку, с полосой частот 200 кГц, что позволяет ей обеспечить пропускную способность 270,833 бит/с на канал. Каждый из 124 частотных каналов делится в GSM между восемью пользователями (мультиплексирование по времени). Теоретически в каждой ячейке может существовать 992 канала, на практике многие из них недоступны из-за интерференции с соседними ячейками. Система мультиплексирования по времени имеет специфическую структуру. Отдельные временные домены объединяются в мультифреймы. Упрощенная схема структуры показана на рис. 4.1.8.1.3.
Рис. 4.1.8.1.3. Структура кадров в GSM Каждый временной домен (TDM) содержит 148-битовый кадр данных, начинающийся и завершающийся последовательностью из трех нулей. Кадр имеет два 57-битовых поля данных, каждое из которых имеет специальный бит, который указывает на то, что лежит в кадре - голос или данные. Между информационными полями размещается поле синхронизации (Sync). Хотя информационный кадр имеет длительность 547 мксек, передатчику позволено передавать его лишь раз в 4615 мксек, так остальное время зарезервировано для передачи другими станциями. Если исключить накладные накладные расходы каждому соединению выделена полоса (без учета сжатия данных) 9600 кбит/с. Восемь информационных кадров образуют TDM-кадр, а 26 TDM-кадров объединяются в 128-микросекундный мультифрейм. Как видно из рисунка 4.1.8.1.2 позиция 12 в мультифрейме занята для целей управления, а 25-я зарезервирована для будущих применений. Существует также стандарт на 51-позиционный мультифрейм, содержащий больше управляющих вставок. Управляющий канал используется для регистрации, актуализации положения и формирования соединения. Каждая стационарная станция поддерживает базу данных, где хранится информация обо всех обслуживаемых в данный момент клиентах. Общий управляющий канал делится на три субканала. Первый служит для обслуживания вызовов (paging channel), второй (random access channel) реализует произвольный доступ в рамках системы ALOHA (устанавливаются параметры вызова). Третий субканал служит для предоставления доступа (access grant channel). Алгоритмы обслуживания мобильной связи достаточно нетривиальны. Из рисунка 4.1.8.1.1 видно, что области перекрываются (иначе бы существовали "мертвые" зоны без связи). Существуют даже субобласти, накрываемые тремя MSC. По это причине процедура должна четко определить, с каким из MSC клиент должен быть связан, и при каких условиях его следует переключить на соседний MSC, не прерывая связи. Система должна также компенсировать падение сигнала, иногда достаточно резкое, чтобы обеспечить комфортную связь и безошибочную передачу информации. По этой причине частота ошибок (BER) в таких сетях составляет 10-3 (против 10-6 для обычных стационарных цифровых каналов связи). Следует иметь в виду, что в условиях города сигнал падает пропорционально не квадрату, а четвертой степени расстояния. На распространение радиоволн в городе влияют ориентация улиц (до 20 дБ), туннели (до 30 дБ) и листва деревьев в сельской местности (до 18 дБ). GSM - система базирующаяся в основном на коммутации каналов. Применение модема на переносной ЭВМ позволяет подключиться к сети Интернет. Но здесь не все беспроблемно. Базовые станции временами теряют связь друг с другом (переключение с канала на канал), что может приводить к 300 миллисекундным потери данных. Как уже говорилось выше, здесь высока вероятность ошибок. Так, нажав клавишу "a", можно получить на экране букву "я". Да и расценка за минуту работы в Интернет здесь весьма высока. В связи с этим был разработан стандарт на цифровую систему коммутации пакетов CDPD (Cellular Digital Packet Data). Система работает поверх AMPS. Система обеспечивает информационную пропускную способность на уровне 9,6 кбит/с. CDPD довольно точно следует модели OSI. В CDPD определены три типа интерфейсов. Е-интерфейс (внешний по отношению CDPD-провайдеру) соединяют CDPD-область с определенной сетью. I-интерфейс (внутренний по отношению CDPD-провайдеру) соединяет CDPD-области друг с другом. A-интерфейс (эфирный) используется для связи базовой станции с мобильной ЭВМ. В функции этого интерфейса входит сжатие и шифрование данных, а также исправление ошибок. 274-битные блоки сжатой и зашифрованной информации вкладываются в 378-битовые блоки, предназначенные для коррекции ошибок согласно алгоритму Рида-Соломона. К каждому такому блоку добавляется семь 6-битовых флагов. Результирующие блоки имеют 420 бит и передаются в виде семи 60-битовых микроблоков. Эти микроблоки передаются к базовой станции со скоростью 19,2 кбит/с. Канал с аналогичным быстродействием создается для пересылки информации в противоположном направлении. При обмене применяется мультиплексирование с делением по времени. При этом временные домены имеют длительность 3,125 мсек (60 бит). Когда мобильная ЭВМ хочет что-то передать, прослушивается канал базовой станции и проверяется флаг, сообщающий, свободен ли входной канал базовой станции. Если канал занят, ЭВМ вместо ожидания до очередного временного домена, пропуская псевдослучайное число временных доменов, после чего повторяет попытку. Если повторная попытка неудачна, время ожидания увеличивается примерно вдвое. Когда, наконец, ЭВМ обнаруживает, что канал свободен, она начинает пересылку своих микроблоков. Предусмотрена процедура, препятствующая попытке всех ЭВМ, готовых к передаче, захватить канал, как только он оказался свободным. Этот алгоритм называется DSMA (Digital Sense Multiple Access). Но, несмотря на применение DSMA, столкновение все же возможно, так как две или более ЭВМ могут воспользоваться одним и тем же временным доменом для начала передачи. Для выявления столкновений предусмотрен специальный флаг, который позволяет судить, корректно ли доставлен предыдущий микроблок. К сожалению это происходит не мгновенно а лишь спустя несколько микроблоков. При обнаружении ошибки передача прерывается. Следует иметь в виду, что информационный обмен имеет более низкий приоритет по отношению передачи голосовых данных. Предусмотрена возможность создания выделенных CDPD-каналов. GSM использует довольно сложную комбинацию методик ALOHA, TDM и FDM. CDPD для передачи одиночных кадров не вполне согласуется с алгоритмом CSMA. Впрочем существует еще один метод формирования радио каналов - CDMA (Code Division Multiple Access). Метод CDMA принципиально отличается от описанных выше, которые использовали для дультиплексирования доступа FDM, TDM или ALOHA. CDMA позволяет каждой станции осуществлять передачу во всем частотном диапазоне постоянно. Множественные передачи реализуются с привлечением теории кодирования. Здесь предполагается, что сигналы, совпадающие по времени складываются линейно. В CDMA каждый бит-тайм делится на m коротких интервалов, называемых чипами. Обычно используется 64 или 128 чипов на бит. Каждой станции присваивается уникальный m-битный код (chip sequence). Чтобы передать 1 бит станция посылает свой чип-код. Для простоты далее будем предполагать, что m=8. Для того чтобы послать нулевой бит, посылается дополнение чип-кода по модулю один. Никакие другие кодовые последовательности не разрешены. Например, пусть станции 1 поставлен в соответствие чип-код 01010101, тогда при посылке логической 1 она отправляет код 01010101, а при отправке логического нуля - 10101010. Если имеется канал с полосой 1 МГц и 100 станций с FDM, то каждая из них получит по 10 КГц (10 кбит/c при 1 бите на Гц). При CDMA каждая станция использует весь частотный диапазон, так что будет получена скорость передачи 1 мегачип в секунду. При менее 100 чипов на бит CDMA обеспечивает большую пропускную способность, чем FDM. Для упрощения введем двуполярную нотацию, где нулю соответствует -1, а единице +1. Тогда чип-код станции 1 получит вид -1 +1 -1 +1 -1 +1 -1 +1. Каждая из станций получает уникальный чип-код. Чип-коды можно представить в виде m-компонентных векторов. Чип-коды выбираются так, что все они попарно ортогональны (не любой уникальный чип-код пригоден, так, если станция 1 имеет чип-код 01010101, то станция 2 не может иметь чип-код 10101001, но чип-код 10100101 вполне допустим). Математически это можно выразить следующим образом:
где Hi и Gi компоненты векторов чип-кодов H и
G. Это равенство указывает, что число разных компонентов равно числу равных. Если G и H
ортогональны, то и
Когда сигналы от разных станций совпадают во времени и складываются, принимающая сторона легко может вычислить наличие соответствующей компоненты. Если компоненты суммарного сигнала Si, то компоненты Gi вычисляются с помощью произведения Si*H. Действительно, если:
Здесь первые два слагаемых равны нулю в силу ортогональности выбранных чип-кодов. Последнее же слагаемое равно 1 согласно [1]. Во всех этих рассуждениях предполагалось, что все станции работают синхронно и начинают передачу чип-кодов одновременно. Для пояснения метода рассмотрим конкретный пример в выше предложенной нотации. присвоим станциям F, G, H, I ортогональные чип-коды: F=01010101 → -1 +1 -1 +1 -1 +1 -1 +1 Теперь рассмотрим четыре варианта наложений: Только F → S1=[-1 +1 -1 +1 -1 +1 -1 +1] Для выявления наличия компоненты G выполним операции "умножения" согласно описанным выше правилам. S1*G =[-1 -1 -1 -1 +1 +1 +1 +1]/8=0 (G отсутствует) Хотя теоретически здесь все прекрасно, наложение слишком большого числа чип-кодов может создать проблемы и, в конечном итоге, привести к ошибкам. Идеальная мобильная система связи представляется в виде телефонной трубки, которой человек пользуется дома, в автомобиле, в отпуске или командировке. При этом телефонный номер не меняется, где бы вы не находились. Такая система разрабатывается в настоящее время и называется PCS (Personal Communication Services) в США. В остальном мире эта система имеет имя PCN (Personal Communications Network). PCS использует технику сотовой телефонной сети. Но здесь размер ячейки лежит в пределах 50-100 м (против 20 км для AMPS). Это позволяет работать с малой выходной мощностью порядка 0,25 Вт и понизить вес аппарата. При этом для покрытия той же области требуется в 40000 раз больше ячеек и, следовательно, такая система будет значительно дороже даже с учетом более низкой цены одной ячейки. Некоторые телефонные компании осознали, что старомодные телеграфные столбы являются идеальным местом для размещения базовых станций новой системы (провода уже имеются!). Для системы PCS зарегервирован диапазон частот 1,7-2,3 ГГц. |
|
Previous:
4.1.8 Сети IEEE 802.11
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
||||||
|
4.1.9 Сети DQDB (двойная шина с распределенной очередью)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||
|
Сети с двойной шиной и распределенной очередью (DQDB - distributed queue dual bus) используют алгоритм доступа, называемый распределенное переключение пакетов (QPSX - queued-packet distributed-switch). Здесь используется две несвязанные однонаправленные шины, сформированные из цепочки соединений точка-точка. Описание работы сети содержится в документе IEEE 802.6. Пропускная способность сети составляет 150 Мбит/с (планируется 600 Мбит/с). Максимально возможная длина сети составляет 160 км. Максимальное число узлов равно 512. В качестве транспортной среды можно использовать одно- и мультимодовое оптическое волокно (длина волны 1300 нм). Схема кодирования 8В/9В при представлении сигнала NRZI. средняя частота ошибок (BER) составляет 10-9. По сетям DQDB пересылаются также как и по ATM-каналам ячейки фиксированного размера (L=53 байта). Формат поля данных совместим с некоторыми типами AAL. Формат пакета показан на рис 4.1.9.1
Рис. 4.1.9.1. Формат ячейки DQDB (цифры в верхней части рисунка характеризуют длины полей) Поле ST (segment type) характеризует тип сегмента. Поле MID (message identifier) представляет собой идентификатор сообщения. LEN -характеризует длину поля данных, а CRC - это контрольная сумма ячейки. Когда станция намерена передать ячейку, она должна знать, справа или слева от нее находится место назначения. Если место назначения справа, отправитель использует шину А, в противном случае передача производится по шине В. Для ввода данных на шину применяется схема проволочного ИЛИ. По этой причине обесточенная станция не вызовет отказа всего сегмента сети. Станция образуют очередь для передачи в порядке поступления заявок (fifo). Структура заголовка ячейки показана на рис. 4.1.9.2 она весьма схожа с той, что имеет ячейка atm.
Рис. 4.1.9.2. Формат заголовка DQDB-пакета Поле ACF (access control field) служит для управления доступом. Поле VCI (virtual cannel identifier) - виртуальный идентификатор канала. Далее следуют поля:
Ячейка DQDB отличается от ячейки ATM тем, что не содержит поля VPI (идентификатор виртуального пути), а поле VCI имеет на 4 бита больше. Упрощенная схема подключения узлов к сети показана на рис. 4.1.9.3. Шины А и Б служат для передачи ячеек в противоположных направлениях. Если станция намерена передать ячейку по шине Б, она должна выполнить резервирование заранее на шине А, осуществив запись 1 в бит request соответствующей ячейки.
Рис. 4.1.9.3. Топология сети DQDB Каждый из узлов подключен к обеим шинам. По каждой из шин всегда циркулирует фиксированное число контейнеров. Содержимое контейнеров может передаваться с одной шины на другую. В сети DQDB используются следующие типы сегментов:
Поле MID остается идентичным для всех DQDB ячеек сегментированного МАС-кадра. Поле ACF содержит биты busy и request, которые используются в рамках механизма qpsx. Бит busy=1 указывает на то, что ячейка занята. Бит request=1 устанавливается узлом, который ждет возможности начать передачу. В каждом узле имеется счетчик запросов RC(request counter), который фиксирует число узлов, ожидающих передачи и стоящих в очереди впереди данного узла. Содержимое счетчика увеличивается всякий раз, когда по шине А проходит контейнер с битом busy=1. Счетчик декрементируется при появлении на шине Б контейнера со свободным битом request. Когда станция сама намеривается передать кадр, содержимое RC переносится в реверсивный счетчик DC, а в регистр RC заносится нуль. Код в DC уменьшается на единицу при получении контейнера с битом busy=1. DC определяет положение запроса в очереди (нуль соответствует началу очереди). Если получен контейнер с request=0 и DC=0, узел может передать ячейку по данной шине. Каждый узел может осуществлять передачу и прием по любой из шин А и Б. В сети DQDB предусмотрено 4 уровня приоритетов и каждый узел поддерживает до 5 очередей с RC и DC счетчиками для каждой из очередей. Для индикации приоритета в поле ACF предусмотрено 4 двоичных разряда (R1, R2, R3 и R4). Высшему приоритету соответствует R4. Схема сегментирования MAC-кадра при передаче с помощью DQDB ячеек показана на рис. 4.1.9.4.
Рис. 4.1.9.4. Сегментация МАС-кадра Сети DQDB могут иметь размер до 160 км при скорости передачи данных 44,736 Мбит/с (Т3). |
||||||
|
Previous:
4.1.8.1 Мобильные телекоммуникации
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.10 Сети с многокаскадными соединениями
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Среди традиционных сетей особое положение занимают сети, базирующиеся на большом числе идентичных ключевых элементов. Это сети с многокаскадными связями (MIN - Multistage Interconnection Network). Идеология таких сетей используется при построении коммутаторов ATM. Из таких сетей наиболее известной является Delta Banyan (Batcher-switch). Эта сеть содержит регулярную структуру N*N переключателей с двух направлений на два. Сеть содержит log2N число каскадов, каждый из которых имеет N/2 переключателей. Для управления маршрутизацией сообщений в этой сети необходимо log2N бит информации. Схема 4-каскадной сети Delta-2 приведена на рис. 4.1.10.1.
Рис. 4.1.10.1. Блок-схема 4-х каскадной сети Delta-2 |
|
Previous:
4.1.9 Сети DQDB (двойная шина с распределенной очередью)
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.11 Сети 100Base-VG
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Сети 100BASE-VG (Voice Grade) используют звездообразную схему сетевых объектов с помощью соединения типа точка-точка. Эта разновидность сети может работать через кабельную инфраструктуру стандартной сети 10BASE-T. Станции подключаются к сети через концентратор (Hub). Когда станция желает что-либо передать, она посылает сигнал определенной частоты. Начало обмена стартует только после получения разрешения (сигнал специальной частоты, посылаемый концентратором. Широковещательные и мультикатинг-запросы обслуживаются в соответствии со схемой "запомнить и передать". В одно и то же время допускается прием или передача только одного пакета. Для предоставления доступа используется карусельный принцип, что делает эту сеть весьма удобной для небольших рабочих групп и для решения задач управления в реальном масштабе времени. Имеется возможность и приоритетного обслуживания. В сети используется схема кодирования 5B/6B. |
|
Previous:
4.1.10 Сети с многокаскадными соединениями
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
||||||||||||||||||||||
|
4.1.12 Канальный протокол Fibre Channel
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||
|
Известно, что производительность микропроцессоров рабочих станций удваивается каждые 18 месяцев. Каждому миллиону операций в секунду процессора должна соответствовать пропускная способность ввода/вывода, равная мегабиту в секунду (закон Amdahl). По этой причине требования к широкополосности телекоммуникационных каналов уже сегодня лежит в диапазоне от 100 до 1000 Мбит/с. Наиболее популярные скоростные сети Fast Ethernet, FDDI и ATM соответствуют этим требованиям на пределе. Уже одно это заставляет обратить внимание на такие протоколы как гигабитный Ethernet и (стандарт ANSI). Fibre Channel сочетает в себе преимущества канальных и сетевых технологий. Работы по разработке стандарта FC начаты группой ANSI в 1988 году. К настоящему времени разработано более 20 регламентирующих документов. В настоящее время Fibre Channel конкурирует как с Ethernet, так и с SCSI. Смотри www.prz.tu-berlin.de/docs/html/EANTC/INFOSYS/fibrechannel/detail, http://www.fibrechannel.com/technology/physical.htm и http://www.ancor.com. http://www.iol.unh.edu/training/fc/fc_tutorial.html. Последний уже сейчас превосходит по быстродействию существующие сети в 10-100 раз. Он легко стыкуется с протоколами локальных и региональных сетей. Fibre Channel имеет уникальную систему физического интерфейса и форматы кадров, которые позволяют этому стандарту обеспечить простую стыковку с канальными протоколами IPI (Intelligent Peripheral Interface), SCSI, HIPPI, ATM, IP и 802.2. Это позволяет, например, организовать скоростной канал между ЭВМ и дисковой накопительной системой RAID. Быстродействие сетей Fibre Channel составляет n╢ 100Мбайт/с при длинах канала 10 км и более. Предусмотрена работа и на меньших скоростях (например, 12,5 Мбайт/c). Предельная скорость передачи составляет 4,25 Гбод. В качестве транспортной среды может использоваться одномодовое или мультимодовое оптическое волокно. Допускается применение медного коаксиального кабеля и скрученных пар (при скоростях до 200 Мбайт/с). Fibre Channel имеет шесть независимых классов услуг (каждый класс представляет определенную стратегию обмена информацией), которые облегчают решать широкий диапазон прикладных задач:
fibre channel использует пакеты переменной длины (до 2148 байт), содержащие до 2112 байт данных. Такая длина пакета заметно снижает издержки, связанные с пересылкой заголовков (эффективность 98%). С этой точки зрения в наихудшем положении оказывается ATM(83% эффективность 48 байт данных при 53 байтном пакете). Только FDDI превосходит Fibre Channel по этому параметру (99%). В отличие от других локальных сетей, использующих 6-октетные адреса, fibre channel работает с 3-байтовыми адресами, распределяемыми динамически в процессе выполнения операции login. Адрес 0xffffff зарезервирован для широковещательной адресации. Адреса же в диапазоне 0xfffff0-0xfffffe выделены для обращения к "структуре" (fabric), мультикастинг-серверу и серверу псевдонимов (alias-server). n_port передает кадры от своего source_id (s_id) к destination_id (d_id). До выполнения операции fabric login s_id порта не определено. В случае арбитражного кольца применяются 3-октетные адреса al_pa, задаваемые при инициализации кольца. Для однозначной идентификации узлов используются 64-битовые имена-идентификаторы. Fibre Channel превосходит другие сети и по некоторым экономическим параметрам (см. табл. 4.1.12.1). Таблица 4.1.12.1 (www.ancor.com/ctspr97.html )
Цены вещь непостоянная, но здесь следует учитывать относительный их характер, да и в случае начала массового производства цены на fibre channel пожалуй будут падать быстрее, чем для других сетей (они этот этап уже прошли). Формат пакетов в сетях Fibre Channel показан на рис. 4.1.12.1. Здесь используются 24-битовые адреса, что позволяет адресовать до 16 миллионов объектов. Сеть может строить соединения по схеме точка-точка, допускается и кольцевая архитектура с возможностью арбитража (FC-al) и другие схемы (например, "ткань соединений" (fabric), допускающее большое число независимых обменов одновременно). Схема кольцевого соединения показана на рис. 4.1.12.2. К кольцу может быть подключено до 128 узлов. Протокол Fibre Channel предусматривает 5 уровней, которые определяют физическую среду, скорости передачи, схему кодирования, форматы пакетов, управление потоком и различные виды услуг. На физическом уровне (FC-ph 1993 год) предусмотрены три подуровня. FC использует оптические волокна диаметром 62,5, 50мкм и одномодовые. Для обеспечения безопасности предусмотрен опционный контроль подключенности оптического разъема (OFC). Для этого передатчик время от времени посылает короткие световые импульсы приемнику. Если приемник получает такой импульс, процесс обмена продолжается.
FC-0 определяет физические характеристики интерфейса и среды, включая
кабели, разъемы, драйверы (ECL, LED, лазеры), передатчики и приемники. Вместе с FC-1 этот уровень
образует физический слой. FC-0 и FC-1 образуют физический уровень, соответствующей стандартной модели ISO.
Рис. 4.1.12.1. Формат пакета Fibre Channel Стандарт FC допускает соединение типа точка-точка, арбитражное кольцо и структура (верх, середина и низ рисунка 4.1.12.2). Кольцевая архитектура обеспечивает самое дешевое подключение. Система арбитража допускает обмен только между двумя узлами одновременно. Следует учесть, что кольцевая структура не предполагает применения маркерной схемы доступа. Когда подключенное к сети устройство готово передать данные, он передает сигнал-примитив ARBX, где X - физический адрес устройства в кольце арбитража (al_pa). Если устройство получит свой собственный сигнал-примитив ARBX, оно получает контроль над кольцом и может начать передачу. Инициатор обмена посылает сигнал-примитив open (OPN) и устанавливает связь с адресатом. Время удержания контроля над кольцом не лимитируется. Если контроль над кольцом одновременно пытаются захватить два устройства, сравниваются значения X сигналов ARB. Устройство с меньшим al_pa получает преимущество, прибор с большим al_pa блокируется. Прежде чем использовать кольцо его нужно инициализировать (процедура LIP), так чтобы каждый порт получил свой физический адрес (al_pa - один октет, что и определяет макcимальное число портов в кольце арбитража). Процедура инициализации начинается сразу после включения питания посылкой сигнала-примитива LIP через порт l_port. Затем осуществляется выбор устройства, которое будет управлять процессом выбора al_pa.
Рис. 4.1.12.2. Типы топологии FC Перед передачей октеты преобразуются в 10-битовые кодовые последовательности, называемые символами передачи (кодировка IBM 8B/10B). Логической единице соответствует больший уровень световой энергии. В Fibre Channel предусмотрено два режима обмена буфер-буфер и точка-точка (end-to-end). Передача данных осуществляется только когда принимающая сторона готова к этому. Прежде чем что-либо посылать стороны должны выполнить операцию login. В ходе выполнения login определяется верхний предел объема пересылаемых данных (credit). Значение параметра credit задает число кадров, которые могут быть приняты. После передачи очередного кадра значение credit уменьшается на единицу. Когда значение этой переменной достигает нуля, дальнейшая передача блокируется до тех пор, пока получатель не обработает один или более кадров и будет готов продолжить прием. Здесь имеет место довольно тесная аналогия с окнами в протоколе TCP. Режим обмена буфер-буфер предполагает установление связи между портами N_Port и F_Port или между двумя N_Port. При установлении соединения каждая из сторон сообщает партнеру, сколько кадров она готова принять (значение переменной BB_Credit). Режим точка-точка (end-to-end) реализуется между портами типа N_Port. Предельное число кадров, которые сторона может принять, задается переменной EE_Credit. Эта переменная устанавливается равной нулю при инициализации, увеличивается на единицу при передаче кадра и уменьшается при получении кадра ACK Link Control. Кадр ACK может указывать на то, что порт получил и обработал один кадр, N кадров или всю последовательность кадров. Смотри также "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard". K. Teow. May 2000, RFC-2837. |
||||||||||||||||||||||
|
Previous:
4.1.11 Сети 100Base-VG
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|
4.1.13 Коммутируемая мультимегабитная информационная служба SMDS
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Коммутируемая мультимегабитная информационная служба SMDS (Switched Multimegabit Data Service; RFC-1209, -1694) создана для объединения большого числа локальных сетей. Система была разработана в 80-е годы и реализована в начале 90-х годов. Система SMDS функционирует как высокоскоростная опорная сеть, транспортирующая пакеты от одной локальной сети к другой. SMDS рассчитана на большие краткосрочные всплески трафика. При N локальных сетях, соединенных выделенными каналами, полносвязная схема их соединения требует N(N-1)/2 каналов (см. рис. .1А). Для системы SMDS требуется только N каналов до ближайшего SMDS-маршрутизатора (рис. .1В).
Быстродействие системы SMDS составляет 45 Мбит/с. Система SMDS использует передачу данных без установления соединения. Формат пакета SMDS показан на рис. .2.
Адреса места назначения и отправителя состоят из 4-битного кода, за которым следует телефонный номер, содержащий до 15 десятичных чисел. Каждая цифра кодируется посредством четырех бит. Телефонный номер содержит код страны, код зоны и номер клиента-подписчика, что делает сеть SMDS международной. Длина поля данные является переменной. Когда пакет попадает в сеть SMDS, первый маршрутизатор проверяет, соответствует ли адрес отправителя номеру входной линии. При несоответствии пакет отбрасывается. Существенной особенностью SMDS является возможность мультикастинга. Пользователь может составить список номеров и присвоить ему специфический адрес. Отправка пакета по этому адресу вызовет его переадресацию всем клиентам, чьи адреса присутствуют в списке. Это воспроизведение на сетевом уровне возможности почтового списка рассылки. Другой особенностью адресации в SMDS является возможность использования списков доступа (screening) для входящих и исходящих пакетов. Кроме того, такая функция позволяет эффективно строить корпоративные сети типа Интранет. Поле данных может содержать в себе кадр Ethernet или пакет Token Ring, что также повышает эффективность и надежность работы сети, упрощая задачу интерфейсного оборудования. Работа в условиях всплесков загрузки осуществляется следующим образом. Маршрутизатор в каждом из интерфейсов содержит счетчик, который инкрементируется с постоянной частотой (например, раз в 10 мксек). Когда на вход маршрутизатора приходит пакет, осуществляется сравнение длины пакета в байтах с содержимым этого счетчика. Если содержимое счетчика больше, пакет немедленно пересылается, а содержимое счетчика уменьшается на длину пакета. Если длина пакета больше содержимого счетчика, такой пакет отбрасывается. В результате при данной частоте приращения счетчика в среднем допускается передача 100000 байт/сек. Но импульсная загрузка может существенно превышать это значение. |
|
Previous:
4.1.12 Канальный протокол Fibre Channel
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
||||||||||||||||||||||||
|
4.1.1 Ethernet (IEEE 802.3)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||
Сеть Ethernet разработана в 1976 году Меткальфом и Боггсом (фирма Ксерокс). Ethernet совместно со своей скоростной версией Fast Ethernet занимает в настоящее время абсолютно лидирующую позицию (а на подходе еще и гигабитный Ethernet). Единственным недостатком данной сети является отсутствие гарантии времени доступа к среде (и механизмов, обеспечивающих приоритетное обслуживание), что делает сеть малоперспективной для решения технологических проблем реального времени. Определенные проблемы иногда создает ограничение на максимальное поле данных, равное ~1500 байт. |
||||||||||||||||||||||||
|
Previous:
4.1 Локальные сети (обзор)
UP:
4.1 Локальные сети (обзор)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.1 Локальные сети (обзор)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
В этом разделе речь идет о физической среде локальных сетей. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4 Сети передачи данных. Методы доступа
UP:
4 Сети передачи данных. Методы доступа
|
|
|
||||||||||||||||||||||||||||
|
4.2.1 Протоколы Novell (IPX/SPX)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||
Межсетевой протокол IPX - (Internetwork Packet eXchange; Novell (См. также А.В.Фролов, Г.В.Фролов, "Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS. Москва, "Диалог-МИФИ", 1993), [13]) соответствует сетевому уровню модели ISO, до какой-то степени это аналог IP-протокола в Интернет. IPX-протокол может работать совместно с SPX при обеспечении обменов, ориентированных на соединение, где гарантируется доставка информации. IPX произошел от протокола XNS (Xerox Network Services) и имеет ряд уникальных черт. Так IPX может использовать различные схемы инкапсуляции в зависимости от физической сетевой среды. В операционной среде MS-DOS за реализацию протокола IPX отвечает программа IPX.COM или IPXODI.COM. Оболочка же системы NetWare (NETX.COM) и DOS Requester (VLM.COM) используют протокол IPX для пересылки запросов файл-серверу. Первоначально пакеты Novell инкапсулировались в кадры IEEE 802.3. В настоящее время схема инкапсуляции поддерживает 802.2 и протокол SNAP (Sub-Network Access Protocol). |
||||||||||||||||||||||||||||
|
Previous:
4.2 Наложенные сети
UP:
4.2 Наложенные сети
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.2.1.1 IPX-протокол
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол IPX предназначен для передачи дейтограмм в системах, неориентированных на соединение (также как и IP или NETBIOS, разработанный IBM и эмулируемый в Novell), он обеспечивает связь между NetWare серверами и конечными станциями. Максимальный размер IPX-дейтограммы составляет 576 байт, из них 30 байта занимает заголовок. Предполагается, что сеть, через которую транспортируются эти дейтограммы, способна пересылать пакеты соответствующей длины. IPX-пакеты могут рассылаться широковещательно, для этого поле типа должно принять значение 0x14, адрес сети назначения должен соответствовать локальной сети, адрес узла назначения при этом принимает значение 0xFFFFFF. Оригинальный транспортный протокол Novell, на мой взгляд, не способствует успеху этой сети. Не успев своевременно переориентироваться на транспортные и маршрутные протоколы стека TCP/IP этот крайне популярный совсем недавно вид сетей в настоящее время имеет шансы исчезнуть. IPX-пакеты, передаваемые по сети Ethernet, могут иметь несколько разных форматов. Старейший из них носит в Novell название "802.3" (информацию об интеграции сетей Novell и Интернет можно найти в документах: RFC-1234, -1420, -1553, -1634, -1792) и используется по умолчанию в версиях вплоть до 3.11. В последующих версиях форматом по умолчанию является "802.2". Применим также и формат, называемый Ethernet II, который наиболее близок идеологии TCP/IP. Сеть в Netware - это логический канал, который используется совместно рядом узлов так, что они могут взаимодействовать друг с другом непосредственно. Так процессы, реализуемые на одном сервере, считаются подключенными к внутренней IPX-сети. Все пользователи сети типа Ethernet II образуют логическую сеть IPX. Все пользователи одной сети типа 802.3 рассматриваются как узлы различных сетей IPX. Сопоставление форматов пакетов для различных сетевых стандартов представлено на рис. 4.2.1.1.
Рис. 4.2.1.1. Форматы сетевых пакетов Из рисунка видно, что различия непринципиальны и не препятствуют сосуществованию всех перечисленных форматов в пределах одной локальной сети. IPX-заголовок начинается сразу после поля Тип или Длина в зависимости от используемого протокола. Серверы Netware можно сконфигурировать так, чтобы они воспринимали пакеты разных типов, и поэтому могли иметь непосредственные связи с разными сетями. IPX-сервер может выполнять и функции маршрутизатора. Формат заголовка пакета IPX показан на рис. 4.2.1.2. За заголовком следуют данные, их объем определяется кодом поля Длина пакета (минус 30) и лежит в диапазоне от 0 до 546 байт.
Рис. 4.2.1.2. Формат заголовка IPX-пакета Поле Контрольная сумма (2 байта) устанавливается ipx-драйвером равным 0xffff, это означает, что контрольного суммирования не производилось. Приложениям разрешено использовать поле контрольной суммы при работе с кадрами Ethernet II, ieee 802.2 и Ethernet SNAP и запрещено для работы с кадрами ieee 802.3. Данное ограничение можно легко понять, обратившись к рис. 4.2.1.1. Контрольная сумма служит лишь для контроля правильности IPX-заголовка и не имеет никакого отношения к полю данных IPX-дейтограммы. Для того чтобы работать с контрольными суммами на NetWare-сервере, следует выдать команду set enable IPX checksum=n, где n указывает на то, что контрольная сумма использована. Возможные значения n и их смысл приведены ниже в таблице 4.2.1.1. Таблица 4.2.1.1
Поле Длина пакета (2 байта) содержит число байт в пакете, включая заголовок, и может лежать в пределах от 30 (только заголовок) до 576. В действительности максимальная длина IPX-пакета равна 1518 байт, но при прохождении пакетов через маршрутизаторы, когда не используется протокол LIP(large internet packet, протокол межсетевой пересылки больших пакетов) максимальная длина может быть равной лишь 576 байт (что и принято по умолчанию). Следует также иметь в виду, что согласно регламентациям Novell длина пакета может принимать только четные значения. Программист не должен беспокоиться о содержании этого поля, это за него сделает сам протокол IPX. Поле управление пересылкой (1 байт) устанавливается IPX-драйвером равным нулю перед посылкой пакета. Каждый маршрутизатор увеличивает значение этого поля на 1. Если пакет прошел через 15 маршрутизаторов, очередной - удалит пакет из сети (в некотором смысле это аналог поля время жизни - TTL в протоколах TCP/IP). Поле управление пересылкой можно использовать для оптимизации маршрутов в локальной сети. Если станция общается только с серверами соседней субсети, ее следует переключить туда и снизить тем самым нагрузку маршрутизатора. Контроль за содержимым этого поля выполняется протоколом IPX. Поле тип пакета (1 байт) устанавливается прикладной программой. При использовании протокола ipx это поле должно содержать нуль (или 4), в случае использования протокола SPX - 5, а для протокола NCP(Netware core protocol) -17. Поля адрес узла назначения и адрес узла отправителя содержат 12-байтовые структуры ipxaddr_1. Эта структура включает в себя 4 байта адреса сети (присваивается администратором сети при установке сети Novell), 6 байт адреса узла (физический адрес, задается изготовителем сетевого интерфейса) и 2 байта дескриптора соединителя (socket, необходим для адресации программы, принимающей пакеты, заполняется приложением). Пакеты, адресованные серверу в NetWare 3.x или 4.x содержат в поле адреса узла получателя код 0x00 00 00 00 00 01 (аналогичный код будет записан в поле адрес отправителя, если им является сервер). Адрес же узла получателя на уровне Ethernet или Token Ring будет равен физическому сетевому адресу интерфейса или локального маршрутизатора, если сервер размещен в другой субсети. Соединители (socket) служат для управления обработкой пакетов. Широковещательный пакет будет получен ЭВМ, если она имеет открытый соединитель для процесса, которому он адресован. По этой причине должны приниматься специальные меры, чтобы предотвратить возможность посылки двумя программами пакетов различного типа на один и тот же соединитель. Ряд номеров соединителей зарезервировано IPX-протоколом для определенных целей: 2 - соединитель протокольных откликов; 3 - обработчик ошибок. Некоторые номера заняты под нужды Netware:
Дескрипторы соединителей для рабочих станций задаются динамически и их коды лежат в диапазоне 0x4000 - 0x8000. В отличии от протоколов TCP/IP IPX не имеют фиксированных адресов для сетей или интерфейсов, которые следует конфигурировать. Вместо этого рабочие станции получают свои сетевые номера от маршрутизатора, к которому они подсоединены, и используют Ethernet-адрес в качестве номера узла. Приложение должно устанавливать поля тип пакета и адрес узла назначения, а IPX-драйвер заполняет остальные поля. Возможные значения кода поля тип пакета представлены в таблице 4.2.1.2. Таблица 4.2.1.2 Коды типа IPX-пакета.
Программа, использующая IPX-протокол для передачи информации должна записывать в поле тип пакета код 4. Маршрутная информация передается между серверами и маршрутизаторами. Динамический маршрутный протокол RIP (routing information protocol, базируется на стандарте Xerox IP; cм. также RFC-1058) обеспечивает конечные станции информацией, которая необходима для динамического управления оптимизацией маршрутов. Рассылка маршрутной информации производится с помощью широковещательных пакетов. Как видим, сети Novell являются источником значительных потоков широковещательных пакетов. Аналогичным образом объекты сети оповещаются о других изменениях в сетевой среде, например, рассылка информации о доступных услугах (SAP - service advertisement protocol). Протокол SAP позволяет узлам, которые предлагают определенные услуги (например, файл-серверы или принт-серверы), сообщать о своих адресах и видах доступных услуг. Администратор может регулировать поток таких пакетов, задавая постоянные времени для таймеров обновления информации. Маршрутизаторы рассылают маршрутную информацию в пяти случаях:
Маршрутизация пакетов в сети достаточно проста. Каждому сетевому сегменту маршрутизатор присваивает номер в пределах от 1 до fffffffe. Каждой группе устройств присваивается "сетевой номер", который представляет эту группу во всех маршрутизаторах сети. Пакеты, посылаемые от одного члена группы другому, посылаются непосредственно. Пакеты от одного члена группы к объекту из другой группы будут пересланы через маршрутизаторы. Для выбора маршрута в пределах локальной сети используется маршрутный протокол RIP. Формат пакета NetWare RIP показан на рис. 4.2.1.3.
Рис. 4.2.1.3. Формат RIP-пакета в NetWare Поле тип пакета содержит код 0x0001, если это запрос, и 0x0002, если отклик. В поле адреса сети записывается адрес сети места назначения, если пакет является запросом. Если в поле записан код 0xff ff ff ff, это означает, что запрос относится ко всем известным сетям. Поле число шагов до цели имеет смысл лишь в случае пакетов-откликов. В этом случае сюда заносится число маршрутизаторов, которые должен пройти пакет по дороге к сети назначения. Поле время в тиках имеет смысл для пакетов-откликов и указывает на время, необходимое для достижения сети адресата. Один тик равен 1/18 секунды. Сходный протокол маршрутизации используется в сетях appletalk (RTMP). Для межсетевой маршрутизации в Novell разработан протокол NLSP (NetWare link services protocol). NLSP базируется на той же идеологии, что и протокол IS-IS (intermediate system-to-intermediate system), созданный для сетей OSI и IP. В NLSP значение метрики маршрута задается вручную. nlsp-маршрутизаторы хранят полную карту сети, по которой принимаются решения о наилучших возможных маршрутах. На рис. 4.2.1.4 представлена схема соответствия протоколов Novell и 7-уровневой модели osi.
Рис. 4.2.1.4. Схема соответствия протоколов Novell и модели osi Протокол SAP (service advertising protocol) служит для получения информации обо всех серверах, имеющихся в сети, и поддерживает следующие виды запросов и функции:
Каждому серверу NetWare присваивает номер, а некоторые сервера могут иметь и имя. Номер сервера и его имя хранятся в базе данных объектов bindary каждого сервера. Пакет запроса SAP-сервиса содержит 2 байта типа пакета и два байта типа сервера. Поле тип пакета определяет, является ли данный пакет общим запросом сервиса (код=0x0003), или запросом ближайших услуг (код=0x0001). Таблица кодов поля тип сервера приведена ниже (4.2.1.3). Таблица 4.2.1.3 Коды тип сервера (cм. также ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap-numbers)
SAP-пакеты-отклики (периодически рассылаемые пакеты) имеют следующий формат (рис. 4.2.1.5).
Рис. 4.2.1.5. Формат пакета SAP Поле тип пакета принимает значение 0x0002 для SAP-откликов общего обслуживания (General Service Response) и 0x0004 для отклика ближайшего сервера. Запросы о ближайшем сервере используются для поиска в сети сервера конкретной разновидности (пакет запроса содержит лишь первые два поля). Реально отклик будет получен от всех серверов данного типа, а не только от ближайшего. Насколько данный сервер близок, определяется по числу маршрутизаторов до него. Эти запросы/отклики служат для составления списка доступных серверов. Поле тип сервера содержит код доступного вида услуг, а в поле наименование сервиса записывается имя услуги уникальное для данного сервера (длина поля на рис. 4.2.1.5 равна N). Поле адрес сети представляет собой 4-байтовое число, которое идентифицирует адрес сервера. Поле адрес узла характеризует адрес сервера в сети. Службы NetWare указывают адрес 0x00.00.00.00.00.01. Поле дескриптор соединителя характеризует код соединителя, который будет использовать сервер. Последнее поле - число шагов до сервера (число транзитных сетей) характеризует число маршрутизаторов между сервером и клиентом. При отключении сервера от сети он должен широковещательно разослать SAP-уведомление "Останов сервера". Уведомление содержит код сервера и его полный адрес. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.2.1 Протоколы Novell (IPX/SPX)
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
4.2.1.2 SPX-протокол
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||
|
SPX (Sequence Packet eXchange) и его усовершенствованная модификация SPX II представляют собой транспортные протоколы 7-уровневой модели ISO. Это протокол гарантирует доставку пакета и использует технику скользящего окна (отдаленный аналог протокола TCP). В случае потери или ошибки пакет пересылается повторно, число повторений задается программно. В протоколе SPX не предусмотрена широковещательная или мультикастинг-адресация. В SPX индицируется ситуация, когда партнер неожиданно прерывает соединение, например из-за обрыва связи. Пакеты SPX вкладываются в пакеты IPX. При этом в поле тип пакета IPX записывается код 5. Заголовок пакета SPX всегда содержит 42 байта, включая 30 байт заголовка IPX-пакета, куда он вложен (см. рис. 4.2.1.2.1).
Рис. 4.2.1.2.1. Формат заголовка SPX-пакета Поле управления соединением определяет, является ли данный пакет системным или прикладным. Это поле содержит однобитовые флаги, используемые spx и spx ii для управления потоком данных в виртуальном канале.
Поле тип потока данных характеризует тип данных, помещенных в пакет. Значения этого поля перечислены ниже:
Поля идентификатора отправителя и получателя содержат коды, определяющие участников информационного обмена, присваиваются SPX-драйвером в момент установления связи. В запросах на соединение это поле содержит код 0xffff. Данное поле служит для обеспечения демультиплексирования пакетов, поступающих на один и тот же соединитель (socket). Поле последовательный номер определяет число пакетов пересланных в одном направлении. Каждый из партнеров обмена имеет свой счетчик, который сбрасывается в ноль после достижения 0xffff, после чего счет может продолжаться. Для приложения это поле, также как и последующие два, неприкосновенно. spx-пакеты подтверждения содержат в этом поле порядковый номер последнего посланного пакета. Поле номер подтверждения характеризует последовательный номер следующего пакета, который spx ожидает получить. Любой пакет с порядковым номером меньше, чем задано в поле номера подтверждения, доставлен благополучно и не требует ретрансмиссии. Поле число буферов служит для указания числа доступных на станции буферов (буфера нумеруются, начиная с 0, один буфер способен принять один пакет) и используется для организации управления потоком данных между приложениями. Код этого поля информирует партнера о наибольшем порядковом номере пакета, который может быть послан. Протокол spx посылает пакеты до тех пор, пока локальный последовательный номер не станет равным числу-указателю на удаленной ЭВМ. SPX-протокол не посылает следующий пакет до тех пор, пока не получит подтверждение получения предшествующего. Хотя в протоколе SPX предусмотрен алгоритм скользящих окон (как и в TCP), практически он в настоящее время не используется, что вполне оправдано для локальных сетей. Следует заметить, что для достаточно больших LAN, где пакет проходит через несколько переключателей или маршрутизаторов, пренебрежение техникой окон становится непозволительной роскошью. На случай непредвиденных обрывов связи в spx имеется алгоритм "сторожевая собака". Этот алгоритм реализуется специальной программой, которая активируется лишь в случае, когда в течение определенного времени в канале отсутствует трафик в любом из направлений (машина все сделала, а оператор заснул). В этом случае программа посылает специальные пакеты и, если определенное число попыток "достучаться" до партнера не увенчается успехом, сессия прерывается. Если партнер не присылает отклик за оговоренное время (RTT), производится повторная посылка пакета, при этом RTT увеличивается на 50%. Значение RTT не должно превысить величины max_retry_delay, которая по умолчанию равна 5 секундам. Если связь не восстановилась, отправитель пытается найти другой маршрут до адресата. Если маршрут найден, счетчик попыток сбрасывается в ноль и процедура отправки запускается вновь. Допустимое число попыток может лежать в диапазоне 1-255 (по умолчанию - 10). При отсутствии успеха сессия прерывается. Значение RTT определяется по времени отклика ближайшего маршрутизатора, которое удваивается, а к полученной величине добавляется некоторая константа. Для каждой из сессий RTT определяется независимо. Многие временные константы задаются администратором сети. Протокол spx позволяет осуществить от 100 до 2000 соединений одновременно (по умолчанию это число равно 1000). Конфигурационные параметры SPX-протокола (и сети) хранятся в файлах shell.cfg и net.cfg. В 1992 году была разработана новая версия SPX - SPX II. Главное усовершенствование протокола связано с применением пакетов большего размера. Раньше длинные spx-пакеты фрагментировались и пересылались по частям, учитывая, что очередной пакет может быть послан лишь после получения подтверждения, нетрудно понять крайнюю неэффективность такой схемы. Стандарт spx позволяет обмен пакетами с размером, ограниченным только используемой сетевой средой. Так в Ethernet пакет SPX II может иметь длину 1518 байт. Кроме того, SPX II допускает использование технологии окон, то есть можно послать несколько кадров, не дожидаясь получения подтверждения на каждый из уже посланных. Размер окна устанавливается в соответствии с кодом, содержащимся в поле число-указатель (число буферов/пакетов). При необходимости администратор может задать размер окна раз и навсегда. Формат пакетов SPX II несколько отличается от SPX. В SPX II увеличено число допустимых кодов для поля управления соединением, введено дополнительное поле в заголовок подтверждения (два байта, имя поля "расширенное подтверждение"). Новое поле добавлено после поля число буферов. Алгоритм установление связи в SPX II отличатся от варианта spx тем, что необходимо согласовать размер пересылаемых пакетов.
Рис. 4.2.1.2.2. Формат заголовка SPX-II Управление сетями Novell осуществляется с помощью стандартного протокола SNMP (Simple Network Management Protocol) и управляющей базы данных MIB. |
||||||||||||||||||||||||||||
|
Previous:
4.2.1.1 IPX-протокол
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
|
|
||||||||||||||||||
|
4.2.1.3 Протокол ядра NetWare (NCP)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||
|
NCP представляет собой язык общения серверов и клиентов в среде NetWare. NCP-пакет вкладывается в SPX. Рабочие станции передают свои запросы на запись или чтение файлов, на создание очереди заданий, на поиск в дисковых каталогах и т.д. в виде NCP-сообщений. Прежде чем клиент пошлет NCP-запрос, он должен подключиться к серверу и выдать заявку на формирование NCP-канала связи. Сервер в ответ на этот запрос присылает отклик, в котором содержится подтверждение создания такого канала связи, если запрос удовлетворен. Каждому запросу должен соответствовать отклик. Формат NCP-запроса показан на рис. 4.2.1.3.1.
Рис. 4.2.1.3.1. Формат заголовка пакета NCP Поле тип запроса характеризует запрос, передаваемый от клиента к серверу, возможные значения кодов этого поля приведены ниже (таблица 4.2.1.4). Таблица 4.2.1.3.1 Значения кодов поля тип запроса
Поле номер по порядку используется для отслеживания последовательности связи между клиентом и сервером. Клиент записывает в это поле код, равный номеру по порядку плюс единица. В полях номера канала записан номер, присвоенный клиенту при его регистрации сервером. Поле номер задачи идентифицирует каждую из задач, сделавших запрос. Сервер следит за выполнением задачи и освобождает ресурсы при завершении выполнения. Номер задачи равный нулю говорит серверу, что все задания окончены. Старшая часть номера канала используется лишь при наличии более чем 1000 пользователей, в остальных вариантах это субполе содержит нуль. Сервер в своем отклике сообщает клиенту результаты выполнения его запроса. Отклик, также как и запрос, вкладывается в IPX/SPX-пакет. Формат пакета-отклика показан на рис. 4.2.1.3.2.
Рис. 4.2.1.3.2. Формат заголовка NCP-отклика Поле тип отклика может содержать следующие коды (таблица 4.2.1.3.2): Таблица 4.2.1.3.2 Коды откликов
Сервер отвечает на большую часть запросов, помещая код 3333 в поле типа отклика. Если запрос клиента помещен в очередь, а клиент по таймауту выдал еще один запрос, ему присылается отклик типа "Запрос обрабатывается". Станция клиента при этом сбросит таймер в исходное состояние, добавит 1 к счетчику попыток и продолжит ожидание. По умолчанию запрос можно повторить 20 раз. Поле код завершения указывает на характер завершения выполнения запроса клиента. Код нуль говорит об успешном завершении, любое другое число - об ошибке. Поле состояние канала содержит флаги, характеризующие статус канала, клиенты NetWare должны проверять код этого поля во всех пакетах, приходящих от сервера. Кроме заголовка (запросов и откликов) каждое NCP-сообщение должно содержать в себе код NCP-процедуры, характеризующий запрашиваемую услугу. Часто помимо кода процедуры необходимо указать и ее субкод. Перечень кодов процедур и их функций приведен в приложении. Помимо стандартных пакетов в среде Novell используются несколько вспомогательных видов пакетов. Это пакеты "сторожевая собака" (Watchdog), сериализации (serialization) и сообщения. Пакеты "сторожевая собака" после IPX-заголовка имеет поля номера канала и сигнатура. Поле номера канала отмечает канал станции, присвоенный ей при регистрации. Поле сигнатура содержит код 0x3F. Если отклика от рабочей станции нет, то сервер передает с интервалом 59 сек 10 аналогичных "собачих" пакетов. Если отклика добиться не удастся, связь со станцией будет разорвана. Период и число таких запросов администратор может изменять в широких пределах. Так как система NetWare продается для каждого сервера отдельно, чтобы контролировать случаи нелегальной загрузки, по сети рассылаются широковещательные пакеты сериализации. Цель такой рассылки - проверка наличия в сети нескольких копий одного и того же программного обеспечения. Пакеты сериализации содержат 36 байт, включая IPX-заголовок, и передаются раз в 66 сек. Эти пакеты помимо IPX-заголовка включают в себя только поле данных (6 байт), где содержится информация о серийном номере программного продукта. Пакеты сериализации всегда посылаются на вход соединителя (socket) с номером 0x0457. При обнаружении нелегальной копии всем пользователям рассылается уведомление "Copyright violation". Пользователи NetWare могут передавать сообщения рабочим станциям, группам и другим пользователям. Для каждой станции NetWare резервирует буфер для сообщений. Консоль отображает принятое сообщение немедленно, буфер же сохраняет сообщение и может уведомлять о нем пользователя. Для передачи сообщений используется команда SEND. |
||||||||||||||||||
|
Previous:
4.2.1.2 SPX-протокол
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
|
|
||||||||||||
|
4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||
|
Новый протокол LIP (Large Internet Packet Protocol, 1992 год) разработан Novell для того, чтобы максимально эффективно реализовать возможности, предоставляемые внешними каналами связи. Для повышения производительности операций чтения и записи разработан также протокол пакетного режима (Burst Mode Protocol). Этот протокол позволяет рабочим станциям передавать один запрос на чтение или запись и получать в ответ до 64 Кбайт данных, не посылая дополнительных запросов (используется технология BNETX и VLM). Длина пакета является результатом соглашения между отправителем и получателем, которое достигается в результате диалога. При этом прикладные программы не должны поддерживать пакетный режим (он реализован в оболочке системы). При использовании протокола пакетного режима BNETX клиент и сервер должны быть соответственно подготовлены. На сервере загружается модуль NLM (PBURST.NLM). Согласование размера пакета реализуется путем посылки оболочкой пакетного режима специального запроса на установление соединения с сервером. Это в свою очередь накладывает ограничение на минимальный размер каждого из используемых буферов. Если совершается попытка клиента установить связь в пакетном режиме с сервером, который этот режим не поддерживает, то будет послано сообщение "NO Such Property", а обмен будет производиться в обычном режиме (NCP-запрос-отклик). Отличие пакетных режимов в BNETX и VLM заключается в управлении скользящим окном. VLM (VLM.EXE), в отличии от BNETX, не устанавливает верхнего предела размера окна. По умолчанию размер окна (число посланных пакетов без подтверждения получения) при чтении равно 16, а при записи - 10. Формат кадров протокола пакетного режима предполагает наличие IPX-заголовка, за которым следует NCP-заголовок пакетного режима. Далее следуют данные. Формат кадра пакетного режима показан на рис. 4.2.1.10. Поле тип запроса NCP-запроса или отклика содержит код 0x7777. Возможные значения флагов перечислены ниже (таблица 4.2.1.6). Таблица 4.2.1.4.1 Значения поля флаги
Рис. 4.2.1.10 Формат кадра пакетного режима В скобках на рисунке указаны размеры полей в байтах. Поле тип потока в данное время может содержать только код 0x02 и означает, что передаются длинные блоки пакетов. Поле идентификатор отправителя является случайным числом и представляет собой уникальный идентификатор канала, работающего в пакетном режиме. Код этого поля формируется отправителем и не должен равняться нулю. Идентификатор канала получателя также случайное число, но задается адресатом и также не должно содержать нуль. Поле номер пакета по порядку служит для отслеживания текущей пакетной операции и увеличивается на единицу для каждого нового пакета. Поле время задержки передачи означает величину задержки между отправкой пакетов и измеряется в сотнях микросекунд. Поле номер блока пакетов идентифицирует принадлежность пакета к конкретному блоку (данные, посылаемые по запросу, образуют один блок). При установлении связи код этого поля делается равным нулю. В дальнейшем при выполнении каждого запроса его значение увеличивается на 1. Поле порядковый номер подтверждения содержит номер блока пакетов, ожидаемый следующим. Поле служит для контроля доставки блоков пакетов. Поле полная длина блока пакетов задает длину блока в байтах и равно сумме длин всех пакетов в блоке. Поле указатель блока пакетов определяет положение конкретного пакета, указатель равный нулю говорит о том, что это первый пакет. Поле длина блока задает длину блока пакетов в октетах. Поле элементы списка фрагментов задает число элементов, пропущенных в процессе реализации пакетной сессии. Если это число равно нулю, пропущенных фрагментов не было. Поле функция определяет разновидность операции (чтение или запись), реализуемой в данной сессии. Последующие поля служат для операций с файлами. |
||||||||||||
|
Previous:
4.2.1.3 Протокол ядра NetWare (NCP)
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.2.1.5 Служба каталогов NetWare (NDS)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
С точки зрения службы каталогов netware (NDS - netware directory services) сеть - это не совокупность ЭВМ, а интегрированная информационная среда. При регистрации в сети клиент получает доступ ко всем ее ресурсам. Для повышения надежности и сокращения времени доступа к сети база данных службы каталогов netware распределена по сети. Отдельные фрагменты базы данных могут располагаться на разных серверах, и могут быть задублированы на нескольких серверах, имеются специальные сетевые средства для синхронизации изменений в этих секциях. Все эти вещи порождают в сети дополнительный трафик, ведь необходимо сравнивать содержимое секций базы данных, их обновление, читать и изменять записи и т.д. Одной из важнейших функций службы каталогов является синхронизация работы ее частей. Синхронизация предполагает определение порядка операций по обслуживанию каталога. В службе каталогов все серверы делятся на:
Существует пять функций NCP, которые поддерживают взаимодействие со службой каталогов Netware. Имеются также функции службы каталогов. Коды функций вставляются в пакеты, посылаемые службой каталогов, и служат в качестве субфункций основных NCP-операций. Таблица (4.2.1.5.1) функций и субфункций службы каталогов представлена ниже. Таблица 4.2.1.5.1 Основные NCP-функции
Запрос nds в режиме ping позволяет запросить сервер о поддержке им операции с кодом 104. Если сервер может выполнить эту операцию, он посылает позитивный отклик, который содержит имя дерева каталога и его глубину. При посылке фрагментированного nds запроса присылается фрагментированный отклик. При обновлении секции каталога netware передает последовательность nds-фрагментов, содержащих изменения данной секции. Формат таких пакетов показан на рис. 4.2.1.5.1. В скобках указаны размеры полей в байтах. Поле максимальный размер фрагмента несет в себе максимальное число байт, которое может быть послано в качестве отклика. Код в этом поле соответствует максимуму, поддерживаемому сетевой средой минус 8 (сумма длин поля длины отклика и поля дескриптора фрагмента). Поле флага фрагмента всегда содержит нуль. Поле внутренняя функция хранит в себе код операции для службы каталогов netware. Таблица команд службы каталогов приведена в приложении (10.5) . В netware имеется развитая собственная система сетевой диагностики, которая позволяет выяснить реальную конфигурацию сети (возможно, что-то не включено или уже сломалось), ее загруженность или частоту ошибок (diagnostic responder). Узлы сети с загруженной программой diagnostic responder должны откликаться на диагностические пакеты, адресованные им или разосланные широковещательно. Наличие отклика говорит о доступности данного сетевого объекта, а его содержимое может нести в себе информацию о конфигурации (наличие IPX/SPX, драйвера локальной сети, программы маршрутизатора или файлового сервера).
Рис. 4.2.1.5.1. Формат пакетов "Фрагментированный NDS-запрос/отклик" Диагностические запросы содержат код 0x0456 в поле соединителя получателя IPX-заголовка. Формат такого запроса показан на рис. 4.2.1.5.2. Однобайтовое поле счетчика исключаемых узлов задает число станций, которые могут не присылать отклик. Нуль в этом поле предполагает, что все станции должны откликнуться. Допустимый диапазон значений кодов в этом поле 0 - 79. При широковещательной рассылке запроса можно сделать так, чтобы сервер и определенные клиенты на запрос не реагировали. Для этого их адреса помещаются в поля адресов исключаемых узлов. Число таких исключений может достигать 80.
Рис. 4.2.1.5.2. Формат диагностического запроса Структура пакета-отклика показана на рис. 4.2.1.5.3. В зависимости от числа компонентов конфигурации пакет-отклик может иметь различную длину. Поля базового и вспомогательного номера версии характеризуют вариант программы diagnostic responder (например, 1.1). Поле номер диагностического соединителя SPX указывает на соединитель, которому отсылаются все диагностические отклики. Поле счетчик компонентов содержит число описаний компонентов, содержащихся в пакете. Поле тип компонента описывает один из компонентов (или процессов) узла, посылающего отклик. Описание компонента может быть простым и расширенным. Простое описание содержит один байт идентификатора компонента. Расширенное описание компонента включает в себя информацию о маршрутизаторах, файл-серверах и невыделенных IPX/SPX. Первое поле в этом случае представляет собой идентификатор расширенного описания, который характеризует тип компонента: Таблица 4.2.1.5.1. Коды типа компонентов
Далее следует поле числа локальных сетей, характеризующее количество сетей, обменивающееся данными с данным компонентом. Для каждой из сетей указывается ее тип, а также адрес сети и узла. Поле типа сети содержит код типа (таблица 4.2.1.5.2). Таблица 4.2.1.5.2 Коды типа сети
Поле адреса сети имеет 4 байта, а поле адреса узла 6 байт, перенаправленные удаленные линии имеют адрес узла 0x00-00-00-00-00-00. Внутренние сети IPX версий 3.x и 4.x имеют адрес узла 0x00-00-00-00-00-01.
Рис. 4.2.1.5.3 Формат пакета диагностического отклика Сервера Novell за счет протоколов RIP и SAP могут заметно загрузить локальную сеть широковещательными сообщениями. По этой причине не следует бездумно множить число таких серверов. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
|
|
|
4.2.2 AppleTalk
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Сеть APPLETALK разработана компанией apple computer inc. (ЭВМ Macintosh, 1987 г) Эти сети могут работать в среде Ethernet, Token Ring, FDDI и localtalk (собственная сеть apple, использующая скрученные пары). В AppleTalk специфицирован собственный стек протоколов, которые управляют потоком данных в сети. Для целей маршрутизации AppleTalk использует модифицированную версию внутреннего протокола маршрутизации IGRP. Стек протоколов appletalk phase ii включает в себя (схема структуры стека протоколов показана на рис. 4.2.2.1; смотри http://bbs-win.uniinc.msk.ru/product/bay/routers/protocol, а также RFC-1378, -1419, -1504, -1742):
Из рисунка 4.2.2.1 видно, что стек протоколов appletalk полностью согласуется с семиуровневой схемой OSI. DDP представляет собой протокол передачи данных, не ориентированный на соединение. Дейтограмма DDP использует 13-байтовый заголовок, который включает в себя: поле числа маршрутизаторов (число шагов), через которые прошел пакет; поле длины дейтограммы; поле контрольной суммы; поля сети назначения и отправителя и т.д. (см. рис. 4.2.2.2. - смотри http://www.stanford.edu/group/networking/adminatalk/atalk_3.html). Вслед за заголовком следует информация, которая может содержать до 586 байт. Максимальный размер пакета (MTU) равен 599 байтам. Число узлов в сети может достигать 16 миллионов.
Рис. 4.2.2.1. Диаграмма стека протоколов appletalk Протокол adsp позволяет двум программам обмениваться потоками информации в полном дуплексном режиме с гарантией доставки. Протоколы TLAP, ELAP и LLAP служат для обеспечения сопряжения с соответствующими физическими протоколами (Token Ring, Ethernet и Arcnet), скрывая от программ других уровней специфические особенности используемого сетевого оборудования. Протокол ATP надежно передает запросы и отклики, детектирует ошибки и организует пакетный обмен. Этот протокол используется в свою очередь протоколами ZIP, ASP и PAP, что видно из рис. 4.2.2.1. Протокол AFP является протоколом поддержки приложений и позволяет пользователям ЭВМ Macintosh работать с общими файлами. Программное обеспечение Netware для Macintosh включает в себя файл AFP NLMtm, который обеспечивает поддержку Netware-серверов. Протокол AURP (appletalk update-based routing protocol) служит для целей маршрутизации, но в отличии от некоторых других протоколов передает маршрутную информацию только в случае изменения ситуации. Он поддерживает также IP-туннели.
Рис. 4.2.2.2. Формат пакетов в сети Apple Talk Phase II (в скобках указаны размеры полей в байтах) Адрес отправителя и получателя имеют по 24 бита, из них 16 бит составляет адрес сети. Идентификатор узла назначения (локальная часть адреса) выбирается произвольно самой рабочей станции при установлении связи. ЭВМ берет случайное 8-битовое число в качестве локального адреса и посылает его в сеть. Если какая-то ЭВМ использует этот адрес, она откликается, тогда код меняется и делается повторная попытка. Процесс продолжается пока не будет найден свободный адрес. Протокол RTMP является протоколом маршрутизации, где в качестве метрики используется вектор расстояния до адресата, этот протокол собирает маршрутную информацию и предоставляет ее протоколу DDP для обеспечения транспортировки пакетов по сети. Маршрутные таблицы RTMP хранятся в каждом из маршрутизаторов AppleTalk и базируются на номерах сетей адресатов. Таблица содержит в себе расстояние до адресата, измеренное в шагах (hop), идентификатор порта маршрутизатора, через который достижим адресат, и статус маршрута. Маршрутизаторы AppleTalk формируют и актуализируют маршрутные таблицы, посылая регулярно (раз в 10 сек) широковещательные RTMP-пакеты соседним узлам и сетям. Запись в маршрутной таблице, своевременно не подтвержденная, спустя определенное время стирается. Записи в маршрутной таблице попадают в разряд "подозреваемых" при отсутствии отклика от них в течение 20 сек, в разряд "умирающих" - спустя 40 сек, в категорию "умерших" - через 60 сек. Запись удаляется из таблицы, если отклик не удается получить в течение 80 сек. Адреса сетевого уровня ставятся в соответствие адресам MAC-уровня с помощью адресного протокола AARP. Узлы сети Apple Talk хранят эту информацию в специальных таблицах (AMT - Address Mapping Table). Таблица просматривается всякий раз, когда AppleTalk посылает пакет. Если поиск не увенчался успехом, узел-отправитель посылает широковещательный AARP-запрос. При получении отклика на этот запрос вносятся коррективы в AMT-таблицу. Особенностью сети AppleTalk является согласование при присвоении локальных адресов объектам сети. При инициализации узла ему присваивается временный адрес. Протокол AARP проверяет, не принадлежит ли данный адрес кому-то еще, для этого он посылает 10 AARP-запросов. Если данный временный адрес уже используется, инициализируемому узлу присваивается новый временный адрес и процедура проверки повторяется до тех пор, пока узлу не будет присвоен уникальный адрес. Протокол NBP преобразует локальные AppleTalk адреса в имена, присвоенные сетевому объекту пользователем и наоборот. Это избавляет пользователя от необходимости помнить полный сетевой адрес принт- или файл-сервера, почтового сервера и т.д.. Протокол ZIP допускает логическое группирование оконечных сетевых узлов в некоторые объединения, называемые зонами, что позволяет ЭВМ, принадлежащие к одному отделу, но расположенные в разных зданиях, находиться в одной зоне (субсети). Зона может представлять собой комбинацию локальных сетей, а в случае EtherTalk Phase II - часть локальной сети. Информация о зонах хранится в маршрутизаторах в виде специальных таблиц (ZIT - Zone Information Table). Таблица содержит по одной записи на сетевой сегмент. Запись включает в себя номер сетевого сегмента и список объектов, входящих в зону. Протокол ZIP отслеживает изменения в RTMP-таблицах и при появлении в них записей, относящихся к новым объектам или сетям, маршрутизатор посылает ZIP -запрос и на основе полученной информации корректирует ZIT-таблицу. Протокол AEP выполняет отладочные и диагностические функции, предоставляя возможность выполнения процедур ping (до какой-то степени это аналог протокола ICMP). При необходимости проверить состояние сети или какого-либо узла посылается AEP-дейтограмма, а зондируемый узел, который при ее получении должен послать отклик отправителю исходного запроса. Протокол позволяет проверить время распространения пакетов между узлами сети. Протокол может использоваться в начале любой сессии для проверки доступности того или иного сетевого объекта. Протокол AURP является внешним протоколом сетевой маршрутизации и служит для взаимодействия сетей AppleTalk c Интернет. Протокол поддерживает технологию IP-туннелей с использованием UDP/IP инкапсуляции. Рассылка сетевой информации осуществляется AURP только при возникновении каких-либо изменений в состоянии сети. Протокол AURP поддерживает гибкую систему переадресаций, исключая конфликты адресов при подключении новых сетей AppleTalk, и выявляет маршрутные петли. Существуют специальные фильтры, которые позволяют разделять пакеты по приоритетам, что бывает важно, например, при передаче мультимедиа информации. Сети AppleTalk хорошо согласуются с другими сетями, например, NetWare. Следует иметь в виду, что ЭВМ, работающие с протоколами Phase I и Phase II, могут работать друг с другом только через специальные мосты, так как форматы пакетов для этих протоколов не совместимы. Управление сетями Apple Talk осуществляется с помощью протокола SNMP и управляющей базы данных MIB. |
|
Previous:
4.2.1.5 Служба каталогов NetWare (NDS)
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
|
|
||||||||||||||||||||
|
4.2 Наложенные сети
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||
В отличие от локальных наложенные сети не требуют использования специальных аппаратных средств для подключения. Так, если ЭВМ подключена к Ethernet (к ArcNet или Token Ring), нужны только соответствующие программные средства, чтобы она стала узлом сети Novell. Почтовая сеть (протоколы SMTP или UUCP) и сеть новостей (Usenet, протокол NNTP) относятся к наложенным сетям. Интернет (семейство протоколов TCP/IP) является также примером наложенной сети. Проблематика Интернет выделена в самостоятельный раздел лишь в силу объема и разнообразия материалов. Одна и та же ЭВМ может быть узлом нескольких разных наложенных сетей. Смешанные сети могут создавать проблемы для администраторов сетей, но для пользователей они дают лишь дополнительные возможности. В таких сетях неизбежно возникает проблема присвоения имен и установки соответствия между виртуальными и физическими адресами (в Интернет эта проблема решается с помощью протокола ARP). |
||||||||||||||||||||
|
Previous:
4.1.13 Коммутируемая мультимегабитная информационная служба SMDS
UP:
4.1.1 Ethernet (IEEE 802.3)
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.2.3 NetBIOS
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, независящего от фирмы-производителя. NetBIOS использует в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network" (см. также RFC-1001-2, -1088 и STD-48). Пакет NETBIOS (см. также ftp://ietf.org/internet-drafts/draft-ietf-pppext-netbios-fcp-08.txt) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. netbios имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *. Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139. Любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами. При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** - ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram). Все оконечные узлы netbios делятся на три типа:
IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD). В настоящее время (1985 г) разработана улучшенная версия протокола NETBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP. Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F), который в свою очередь базируется на протоколе PPP. Формат кадра протокола NBFCP показан на рис. 4.2.3.1.
Рис. 4.2.3.1. Формат кадра NBFCP Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует. Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 4.2.3.1). Таблица возможных значений поля класс партнера приведена ниже. Поле имя партнера может иметь до 32 октетов. Таблица 4.2.3.1 Коды класса партнера
Протокол WINS Протокол WINS разработан компанией MicroSoft для операционной среды Windows и предназначен для расширения возможностей NetBIOS. WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 1.
Рис. 4.2.3.2. Формат запроса WINS В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, аналогичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 2.
Рис. 4.2.3.2. Формат отклика WINS Поле флаги имеет следующую структуру:
Для поля флаги имени характерна следующая структура
Для поля флагов имени группы характерно следующее назначение бит
Протокол WINS весьма удобен для сбора данных о МАС-адресах ЭВМ в многоранговой сети, где получить эти данные с помощью ARP-запросов невозможно. Какие-то данные можно извлечь из кэша маршрутизаторов или таблиц сетевых переключателей, если они доступны с помощью SNMP-запросов. Но WINS может дать больше данных, если рабочая станция использует операционную систему Windows. Так что, когда, скажем, программа Black ICE Defender пришлет вам MAC-адрес атакера, сидящего на другом континенте, не удивляйтесь, на помощь был призван протокол WINS. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.2.2 AppleTalk
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
|
|
|||||||||||||||||||||
|
4.3.4 Протокол Frame Relay
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||
|
Протокол Frame Relay (I.122 ITU-t; ANSI T1S1.2; RFC-1490, -1315, -1604; cм. также
www.frforum.com/frame-relay/5000/approved/frf.3/frf.3.1/frf3.f.0.html) является одним из новых телекоммуникационных протоколов (1993 г.), он обеспечивает большую скорость передачи данных (1,5Мбит/с),
меньшие задержки, но и меньшую надежность доставки информации. Frame Relay предназначен для межсетевого общения, ориентирован на соединение и использует два протокольных уровня модели OSI. Остальные уровни должны реализоваться программно. Такая схема заметно удешевляет интерфейс. Протокол вводит понятие committed information rates (CIR - оговоренные скорости передачи),
обеспечивая каждому приложению гарантированную полосу пропускания. Если приложение не использует полностью выделенную полосу, другие приложения могут поделить между собой свободный ресурс. Frame Relay гарантирует большее быстродействие, чем X.25. Стандарт предусматривает 2-х, 3-х и 4-х
байтовые форматы заголовков (ANSI T1.618 и ITU-T Q.922) и синхронную передачу данных. Применение инкапсуляции гарантирует транспортировку пакетов других протоколов через сети Frame Relay. Пакет Frame Relay начинается и завершается разграничительным байтом 0x7e (что соответствует и стандарту Х.25). Максимальный размер кадра 1600 октетов. Формат пакета показан на рис. 4.3.4.1.
Рис. 4.3.4.1. Формат пакетов Frame Relay (цифры сверху - номера байт) NLPID - идентификатор протокола сетевого уровня (network layer protocol ID). FCS - двухбайтовая контрольная сумма кадра (frame control sum). Заполнитель является опционным и может отсутствовать. Различные форматы заголовков кадров Frame Relay показаны на рисунках 4.3.4.2, 4.3.4.3 и 4.3.4.4. В верхней части рисунка приведена нумерация бит.
Рис. 4.3.4.2. 2-байтовый заголовок пакета Frame Relay (адрес) C/R
бит command/response (Команда/Отклик). E/A
бит extended address (Расширенный адрес) определяет, следует ли рассматривать следующий байт в качестве части адреса (E/A=0 заголовок продолжается в следующем октете). DLCI
(data link control interface) адрес управляющего интерфейса информационного
канала (имеет только локальный смысл). В двухбайтовой версии DLCI занимает в сумме 10 бит. FECN
бит forward explicit congestion notification (указание на возможность
реагирования на перегрузку при посылке пакетов). Сигнализирует отправителю о переполнении буферов
на приеме. BECN
бит backward explicit congestion notification
(тоже для случая приема пакетов). DE
бит discard eligibility (пометка пакета при перегрузке канала). Помеченный пакет может быть отброшен и потребуется его повторная пересылка. При возникновении перегрузки DCE-узел отправляет устройствам-адресатам пакет с FECN=1, а узлам, шлющим ему информацию, пакет с битом BECN=1. Большое число пакетов с такими битами говорит о перегрузке и отправитель должен снизить частоту посылки пакетов или вовсе ее прекратить.
Рис. 4.3.4.3. 3-байтовый заголовок пакета Frame Relay
D/C - бит data/control (данные/управление) определяет, является
ли последующее поле младшей частью DLCI или его следует интерпретировать как управляющую информацию DL-core.
Рис. 4.3.4.4. 4-байтовый заголовок пакета Frame Relay Первым передается младший бит байта. Для управления сетью используется протокол snmp и база данных MIB. Формат кадра Frame Relay показан на рис. 4.3.4.4. NLPID - (network layer protocol identifier) идентификатор протокола сетевого
уровня. Это поле может содержать коды многих протоколов, включая IP, CCITT Q.933, ISO 8208, IEEE SNAP, CLNP (ISO 8473) и т.д. Это поле говорит получателю, какой тип протокола инкапсулирован. Коды
nlpid стандартизованы документом ISO/IEC TR 9577. Некоторые допустимые коды этого поля приведены в таблице 4.3.4.1. Пользовательская информация располагается, начиная с поля управления, и содержит код 0x03 для случая пересылки без подтверждения (Q.922, UI). Для всех прочих видов обмена
(кадры I- S-типов) подтверждение доставки является обязательным. Поле заполнитель предназначено для выравнивания границы полей на 2-байтовый уровень. Длина этого поля может быть равной нулю или одному байту. Поле адрес описано выше (см. рис. 4.3.4.1, 4.3.4.2, 4.3.4.3). Если за кодом NLPID
следует 4 октета уровней 2 и 3, это указывает на то, что используется связь, ориентированная на соединение. Протокол Frame Relay предусматривает гибкую систему межсетевых соединения на основе мостов-шлюзов и маршрутизаторов. Все мосты и маршрутизаторы должны быть способны воспринимать и
правильно интерпретировать как NLPID- так и SNAP-инкапсуляцию. Для обеспечения правильной интерпретации идентификатора протокола PID, предусмотрен 3-октетный уникальный идентификатор OUI (organizationally unique identifier). В пакетах для мостов и маршрутизатором в поле OUI предшествует двух-октетному полю PID.
Рис. 4.3.4.5. Формат маршрутизуемого кадра Frame Relay Нетрудно видеть, что кадр Frame Relay имеет много общего с X.25 и ISDN. Здесь уже на протокольном уровне предусматривается мультикастинг.
Таблица 4.3.4.1. Коды поля NLPID (идентификатор протокола сетевого уровня)
Код протокола SNAP используется и для протоколов 802.3, 802.4, 802.5, FDDI и 802.6. При вложении IP в кадры Frame Relay в поле управления записывается код 0x03, а в поле NLPID - 0xcc, начиная с байта 5 располагается тело IP-дейтограммы, за которой следует поле FCS. Формат маршрутизируемой IP-дейтограммы показан на рис. 4.3.4.5А.
Рис. 4.3.4.5А. Формат маршрутизируемой IP-дейтограммы Аналогично осуществляется инкапсуляция пакетов протокола clnp, только здесь в поле NLPID записывается код 0x81. Для примера на рис. 4.3.4.6 и 4.3.4.7 показаны пакеты для мостов 802.3 и FDDI (см. "Multiprotocol Encapsulation over Frame Relay").
Рис. 4.3.4.6 Формат мостового кадра Ethernet 802.3
Рис. 4.3.4.7 Формат мостового кадра FDDI Весьма перспективным сетевым протоколом особенно для передачи мультимедийных данных является ATM. Его модификация может стать транспортным протоколом для цифрового кабельного телевидения. |
|||||||||||||||||||||
|
Previous:
4.3.3 Интегрированные сети ISDN
UP:
4.3 Региональные сети
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.3.5 Протоколы сетей ATM
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
В настоящее время начинают широко внедряться каналы с пропускной способностью 150,52 и 622,08 Мбит/с. Эти каналы используются как для соединения локальных сетей, так и непосредственно для построения скоростных LAN. 150 Мбит/с может обеспечить любые современные телекоммуникационные услуги кроме телевидения высокого разрешения. Предусмотрен стандарт и на скорость передачи 2,48832 Гбит/c. Так как время доставки для многих видов сетевых услуг реального времени является крайне важной характеристикой, АТМ находит широкое применение в телефонии, кабельном телевидении и других областях. Следует учитывать, что оцифрованный видеосигнал качества VHS требует 100Мбит/с при отсутствии сжатия и 1,5-6 Мбит/c при использовании сжатия. Файл изображения 1000х1000 пикселей при 24 битах, характеризующих цвет, занимает 3 Мбайта. ATM справится с передачей такого кадра с учетом накладных расходов (заголовок) за ~0,2 сек. Понятно, что при использовании сжатия можно получить заметно большее быстродействие. Это не значит, что доступны лишь указанные скорости, интерфейсы позволяют мультиплексировать большое число каналов с самыми разными скоростями обмена. Но мультиплексирование на таких частотах представляет собой значительную проблему. Определенные трудности представляет то обстоятельство, что в ATM трудно реализовать обмен без установления соединения (аналог utp в Интернет) Протокол ATM (asynchronous transfer mode; см. также А.Н. Назаров, М.В. Симонов. "АТМ. Технология высокоскоростных сетей". ЭКО-Трендз, М. 1998) является широкополосной версией ISDN, работает на скорости 150,52 Мбит/с с пакетом постоянной длины и минимальным заголовком. Слово асинхронный в названии означает, что тактовые генераторы передатчика и приемника не синхронизованы, а сами ячейки передаются и мультиплексируются по запросам. При мультиплексировании используется статистическая технология. Асинхронная передача не предполагает упорядочивания ячеек по каналам при пересылке. ATM поддерживает аппаратную и пакетную коммутацию. Каждый пакет ATM имеет 53 байта (в англоязычной документации пакеты ATM носят название cell (ячейка), этот термин введен, чтобы отличить пакеты ATM от пакетов низкоскоростных каналов), из них 48 байт несут полезную информацию (что для случая передачи звука, соответствует 6 мс). Для выделения пакета из потока используются такие же, как в ISDN разделительные байты (0x7E). Заголовок пакета содержит лишь 5 байт и предназначен главным образом для того, чтобы определить принадлежит ли данный пакет определенному виртуальному каналу. Отсутствие контроля ошибок и повторной передачи на физическом уровне приводит к эффекту размножения ошибок. Если происходит ошибка в поле идентификатора виртуального пути или виртуального канала, то коммутатор может отправить ячейку другому получателю. Таким образом, один получатель не получит ячейку, а другой получит то, что ему не предназначалось. Виртуальный канал в ATM формируется также как и в ISDN. Формально эта процедура не является частью ATM-протокола. Сначала здесь формируется сигнальная схема, для этого посылается запрос с VPI=0 и VCI=5. Если процедура завершилась успешно, можно начинать формирование виртуального канала. При создании канала могут использоваться 6 разновидностей сообщений.
Схема обмена сообщениями при установлении (и разрыве) виртуального соединения показана на рис. 4.3.5.1. Предполагается, что между ЭВМ-инициализатором и ЭВМ-адресатом находится два ATM-переключателя. Каждый из узлов по пути к месту назначения при получении запроса setup откликается, посылая сообщение call proceeding. Адрес места назначения указывается в сообщении setup. В ATM используется три вида адресов. Первый - имеет 20 байт и имеет структуру OSI-адреса. Первый байт указывает на вид адреса (один из трех). Байты 2 и 3 указывают на принадлежность стране, а байт 4 задает формат последующей части кода адреса, которая содержит 3 байта кода администрации (authority), 2 байта домена, 2 байта области и 6 байтов собственно адреса. Во втором формате байты 2 и 3 выделены для международных организаций, а не стран. Остальная часть адреса имеет тот же формат, что и в варианте 1. Третий формат является старой формой (CCITT E.164) 15-цифровых десятичных телефонных номеров ISDN. В ATM не специфицировано никакого алгоритма маршрутизации. Для выбора маршрута (от коммутатора к коммутатору) используется поле VCP. VCI используется лишь на последнем шаге, когда ячейка посылается от переключателя к ЭВМ. Такой подход упрощает маршрутизацию отдельных ячеек, так как при этом анализируется 12- а не 28-битовые коды. В каждом коммутаторе (переключателе) формируются специальные таблицы, которые решают проблему переадресации ячеек. Следует обратить внимание на то, что виртуальный канал (circuit) и виртуальный проход (path) в данном контексте не тождественны. Виртуальный проход (маршрут) может содержать несколько виртуальных каналов. Виртуальные каналы всегда являются полностью дуплексными.
Рис. 4.3.5.1. Обмен сообщениями при установлении и разрыве виртуального соединения Сети ATM допускают создание мультикастных каналов. Такой канал имеет одного отправителя и много получателей. Первый канал формируется обычным путем, последующие участники сессии подключаются позднее путем посылки сообщения add party. За видимую простоту ячеек приходится платить тем, что управляющая информация передается в общем информационном потоке. Высокая скорость передачи данных требует применения аппаратно реализованных маршрутных таблиц на каждом переключателе пакетов. На рис. 4.3.5.2 представлен формат заголовка пакета ATM. Заголовок обеспечивает два механизма маршрутизации пакетов:
Эти два субполя вместе образуют поле маршрута, которое занимает 24 бита.
Рис. 4.3.5.2 Формат заголовка ATM-пакета (сетевой интерфейс пользователя - UNI) Для интерфейса сеть-сеть (NNI) используется ячейка с несколько иным форматом заголовка. Там весь первый октет выделен для VPI, а поле GFC отсутствует.
Ряд значений VCI и VPI имеют фиксированные значения, приведенные в таблице 4.3.5.1
Некоторые значения поля pt зафиксированы, их значения представлены в таблице 4.3.5.2. Таблица 4.3.5.2. Заданные значения поля PT (payload type identifier)
OAM - эксплуатация и техническое обслуживание. ATM обеспечивает любые услуги в сети:
В ATM предусмотрено несколько категорий услуг (таблица 4.3.5.3). Таблица 4.3.5.3. Типы категорий ATM-услуг
CBR не предусматривает контроля ошибок, управления трафиком или какой-либо другой обработки. Класс CBR пригоден для работы с мультимедиа реального времени. Класс VBR содержит в себе два подкласса - обычный и для реального времени (см. таблицу выше). ATM в процессе доставки не вносит никакого разброса ячеек по времени. Случаи потери ячеек игнорируются. Класс ABR предназначен для работы в условиях мгновенных вариаций трафика. Система гарантирует некоторую пропускную способность, но в течение короткого времени может выдержать и большую нагрузку. Этот класс предусматривает наличие обратной связи между приемником и отправителем, которая позволяет понизить загрузку канала, если это необходимо. Класс UBR хорошо пригоден для посылки IP-пакетов (нет гарантии доставки и в случае перегрузки неизбежны потери). atm использует исключительно модель с установлением соединения (здесь нет аналогий с UDP-протоколом). Это создает определенные трудности для управления трафиком с целью обеспечения требуемого качества обслуживания (QoS). Для решения этой задачи используется алгоритм GCRA (generic rate algorithm). Работа этого алгоритма проиллюстрирована на рис. 4.3.5.3.
Рис. 4.3.5.3. Иллюстрация работы алгоритма GCRA gcra имеет два параметра. Один из них характеризует максимально допустимую скорость передачи (PCR - peak cell rate; T=1/PCR - минимальное расстояние между ячейками), другой - допустимую вариацию значения скорости передачи (CDVT=L). Если клиент не собирается посылать более 100000 ячеек в секунду, то Т=10 мксек. На рис. 4.3.5.3 представлены разные варианты следования ячеек. Если ячейка приходит раньше чем T-t, она считается неподтверждаемой и может быть отброшена. Ячейка может быть сохранена, но при этом должен быть установлен бит CLP=1. Применение бита CLP может быть разной для разных категорий услуг (смотри таблицу 4.3.5.3.). Данный механизм управления трафиком сходен с алгоритмом "дырявое ведро", описанным в разделе "Сети передачи данных". Можно вычислить число подтверждаемых ячеек N, которые могут быть переданы при пиковом потоке ячеек PCR=1/t. Пусть время ячейки в пути равно d. Тогда N = 1 + (l/(T-d)). Если полученное число оказалось нецелым, оно должно быть округлено до ближайшего меньшего целого. Трудно устранимой проблемой для atm является предотвращение перегрузки на промежуточных коммутаторах-переключателях. Коммутаторы могут иметь 100 внешних каналов, а загрузка может достигать 350000 ячеек/сек. Здесь можно рассматривать две задачи: подавление долговременных перегрузок, когда поток ячеек превосходит имеющиеся возможности их обработки, и кратковременные пиковые загрузки. Эти проблемы решаются различными способами: административный контроль, резервирование ресурсов и управление перегрузкой, привязанное к уровню трафика. В низкоскоростных сетях с относительно медленно меняющейся или постоянной загрузке администратор вмешивается лишь при возникновении критической ситуации и предпринимает меры для понижения скорости передачи. Очень часто такой подход не слишком эффективен, так как за время доставки управляющих команд приходят многие тысячи ячеек. Кроме того, многие источники ячеек в ATM работают с фиксированной скоростью передачи (например, видеоконференция). Требование понизить скорость передачи здесь достаточно бессмысленно. По этой причине в АТМ разумнее предотвращать перегрузку. Но для трафика типа CBR, VBR и UBR не существует никакого динамического управления перегрузкой и административное управление является единственной возможностью. Когда ЭВМ желает установить новый виртуальный канал, она должна охарактеризовать ожидаемый трафик. Сеть анализирует возможность обработки дополнительного трафика с учетом различных маршрутов. Если реализовать дополнительный трафик нельзя, запрос аннулируется. В отсутствии административного контроля несколько широкополосных пользователей могут блокировать работу массы узкополосных клиентов сети, например, читающих свою почту. Резервирование ресурсов по своей сути близко административному контролю и выполняется на фазе формирования виртуального канала. Резервирование производится вдоль всего маршрута (во всех коммутаторах) в ходе реализации процедуры setup. Параметрами резервирования может быть значение пикового значения полосы пропускания и/или средняя загрузка. Для типов сервиса CBR и VBR отправитель даже в случае перегрузки не может понизить уровень трафика. В случае UBR потери не играют никакой роли. Но сервис ABR допускает регулирование трафика. Более того, такое управление здесь весьма эффективно. Существует несколько механизмов реализации такого управления. Так предлагалось, чтобы отправитель, желающий послать блок данных, сначала посылал специальную ячейку, резервирующую требуемую полосу пропускания. После получения подтверждения блок данных начинает пересылаться. Преимуществом данного способа следует считать то, что перегрузки вообще не возникает. Но данное решение не используется из-за больших задержек (решение ATM-форума). Другой способ сопряжен с посылкой коммутаторами специальных ячеек отправителю в случае возникновения условий перегрузки. При получении такой ячейки отправитель должен понизить скорость передачи вдвое. Предложены различные алгоритмы последующего восстановления скорости передачи. Но и эта схема отвергнута форумом atm из-за того, что сигнальные ячейки могут быть потеряны при перегрузке. Действительно данный алгоритм не всегда можно признать разумным. Например, в случае, когда коммутатор имеет 10 каналов с трафиком по 50 Мбит/с и один канал с потоком в 100 кбит/c, глупо требовать понижения трафика в этом канале из-за перегрузки. Третье предложение использует тот факт, что граница пакета помечается битом в последней ячейке. Коммутатор просматривает входящий поток и ищет конец пакета, после чего выбрасывает все ячейки, относящиеся к следующему пакету. Этот пакет будет переслан позднее, а отбраcывание M ячеек случайным образом может вынудить повторение передачи m пакетов, что значительно хуже. Данный вариант подавления перегрузки был также не принят, так как выброшенный пакет совсем не обязательно послан источником, вызвавшим перегрузку. Но этот способ может быть использован отдельными производителями коммутаторов. Обсуждались решения, сходные с тем, что используется в протоколе TCP "скользящее окно". Это решение требует слишком большого числа буферов в коммутаторах (как минимум по одному для каждого виртуального канала). После длинных дискуссий был принят за основу совершенно другой метод. После каждых М информационных ячеек каждый отправитель посылает специальную RM-ячейку (resource management). Эта ячейка движется по тому же маршруту, что и информационные, но RM-ячейка обрабатывается всеми коммутаторами вдоль пути. Когда она достигает места назначения, ее содержимое просматривается и корректируется, после чего ячейка посылается назад отправителю. При этом появляются два дополнительных механизма управления перегрузкой. Во-первых, RM-ячейки могут посылаться не только первичным отправителем, но и перегруженными коммутаторами в направлении перегрузившего их отправителя. Во-вторых, перегруженные коммутаторы могут устанавливать средний PTI-бит в информационных ячейках, движущихся от первоисточника к адресату. Но даже выбранный метод подавления перегрузки не идеален, так как также уязвим из-за потерь управляющих ячеек. Управление перегрузкой для услуг типа abr базируется на том, что каждый отправитель имеет текущую скорость передачи (ACR - actual cell rate), которая лежит между MCR (minimum cell rate) и PCR (peak cell rate). Когда происходит перегрузка, ACR уменьшается, но не ниже MCR. При исчезновении перегрузки acr увеличивается, но не выше PCR. Каждая RM-ячейка содержит значение загрузки, которую намеривается реализовать отправитель. Это значение называется ER (explicit rate). По пути к месту назначения эта величина может быть уменьшена попутными коммутаторами. Ни один из коммутаторов не может увеличивать ER. Модификация ER может производиться как по пути туда, так и обратно. При получении RM-ячейки отправитель может скорректировать значение ACR, если это необходимо. С точки зрения построения интерфейса и точек доступа (T, S и R) сеть ATM сходна с ISDN (см. рис. 4.3.3.1 ). Для физического уровня предусмотрены две скорости обмена 155,52 и 622,08 Мбит/с. Эти скорости соответствуют уровням иерархии SDH STM-1 и 4*STM-1. При номинальной скорости 155.52 Мбит/с пользователю доступна реально скорость обмена 135 Мбит/c, это связано с издержками на заголовки и управление. Для ATM используются коаксиальные кабели, скрученные пары (<100м для обоих вариантов) и оптоволоконные кабели (~2км). Для канала связи рассматриваются два кода CMI (coded mark inversion) и скрэмблеры типа установка-сброс (set-reset). В CMI двоичный 0 передается как отрицательный импульс половинной длины, за которым следует положительный импульс той же длительности. Двоичная 1 представляется в виде отрицательного или положительного импульса полной длины, так чтобы уровень менялся для последовательно следующих 1 (система AMI, см. раздел 2.1). Это обеспечивает балансировку передающей линии по постоянному напряжению, но удваивает частоту переключения практически вдвое. Скрамблерный метод не меняет частоту переключения, но его эффективность зависит от передаваемой информации. CMI предпочтительней для 155 Мбит/с. В настоящее время используется две схемы передачи данных применительно к ATM: базирующийся на потоке пакетов (cell stream) и на SDH структурах. В первом случае мы имеем непрерывный поток 53-октетных пакетов, во втором эти пакеты уложены в STM-1 кадры. Управляющие сообщения располагаются в заголовках секции и пути кадра SDH. AAL (ATM adaptation layer) служит для адаптации различных видов сервиса к требованиям ATM-уровня. Каждый вид услуг требует своего AAL-протокола. Главной целью AAL является обеспечение удобства при создании и исполнении программ прикладного уровня. Для всех AAL определены два субуровня:
aal-протоколы управляются значениями следующих переменных:
В настоящее время определены четыре класса услуг, которые могут требовать или нет синхронизации между отправителем и получателем, осуществлять обмен при постоянной или переменной частоте передачи бит, с установлением связи или без. Особенности этих видов услуг для адаптивного уровня систематизированы в таблице 4.3.5.4. Каждая из услуг имеет свой AAL протокол. Таблица 4.3.5.4. Особенности видов услуг для адаптивного уровня
Уровень адаптации 1-го уровня (AAL) выполняет для верхнего уровня следующие услуги (передача аудио- и видео- по каналам DS-1 и DS-3; постоянная скорость передачи):
Для решения этих задач AAL первого уровня должен устранять разброс задержек, выявлять ячейки, доставленные не по адресу, и потерянные ячейки, сегментацию пакетов и последующее их восстановление, выполнять мониторирование ошибок в управляющей информации протокола AAL-PCI (protocol control information). Характер обмена здесь строго ориентирован на соединение. AAL-1 использует субуровни конвергенции и SAR. Субуровень конвергенции обеспечивает постоянство скорости передачи ячеек. AAL-1 конвергенции не имеет какого-то специфического протокольного заголовка. Этот субуровень разбивает входные сообщения на 46- или 47-байтные блоки и передает их субуровню SAR для пересылки. Структура протокольной части информационного поля ячейки SAR-pdu представлена на рис. 4.3.5.4 CSI позволяет приемнику распознать уровень конвергенции. Подуровень SAR получает значение SN (порядковый номер) для каждого 47-октетного блока данных от подуровня конвергенции. Поле SNR (sequence number protection - контрольная сумма) служит для обнаружения и исправления ошибок в заголовке, в качестве производящего полинома используется G(x)= x3 + x + 1. Один из битов SNP- представляет собой бит четности. Если CSI=1, то после поля SNP следует однобайтовое поле указатель, которое используется для определения положения начала следующего сообщения (значения 0-92; старший бит поля указатель зарезервирован на будущее). Поле данных в этом варианте имеет 64 байт. Для сжатой аудио и видео информации скорость передачи может варьироваться в широких пределах. Ведь многие схемы предусматривают периодическую отправку полного видеокадра при последующей передаче транспортируются лишь отличия последовательных кадров. Уровень адаптации 2-го типа предоставляет вышестоящему уровню возможность синхронизовать передатчик и приемник, осуществлять обмен с изменяющейся скоростью, оповещение об ошибках и потерях ячеек. Структура ячейки AAL 2-го типа показана на рис. 4.3.5.5 (субуровень SAR). Из-за переменной скорости передачи заполнение ячеек может быть неполным.
Рис. 4.3.5.4. Структура PDU подуровня SAR ATM 1-го типа (AAL1)
Рис. 4.3.5.5. Структура PDU подуровня SAR ATM 2-го типа (AAL2)
Поля SN и IT имеют общую длину 1 байт, поля же LI и CRC вместе занимают 2 байта. Поле данных (PDU) в такой ячейке имеет длину 45 байт. Более детальной информации о длинах полей стандарт не оговаривает. Уровень адаптации 3/4 типов предназначен для передачи данных как в режиме с установлением соединения, так и без него. Раньше службам С и D были выделены разные типы уровня адаптации, позднее они были объединены. Определены два типа обмена: сообщение и поток. В первом случае блок данных передается в одном интерфейсном блоке (IDU). Сервисные блоки данных могут иметь переменную длину. В режиме поток сервисный блок данных передается через интерфейс уровня адаптации в одном или нескольких IDU. В этом режиме может быть реализована услуга "внутренний контейнер". Здесь допускается и прерывание передачи, частично переданный блок теряется. AAL3/4 допускает организацию нескольких сессий одновременно (например, несколько удаленных login). Структура протокольного блока данных подуровня SAR 3/4 типа представлена на рис. 4.3.5.6. Длина поля данных (PDU) составляет 44 байта. Заметим, что AAL3/4 имеет два уровня издержек - 8 байт добавляется для каждого сообщения и 4 избыточных байта приходятся на каждую ячейку, это достаточно много особенно для коротких сообщений.
Рис. 4.3.5.6. Структура pdu подуровня SAR ATM 3/4-го типов
При вычислении crc используется образующий полином G(x) = x11 + x9 + x5 + x4 + x +1. Подуровень конвергенции aal содержит общую часть подуровня CPCS (common path convergence sublayer) и служебную часть подуровня SSCS (service specific convergence sublayer). CPCS обеспечивает негарантированную доставку кадров любой длины в диапазоне 1-65535 байт. Данные пользователя передаются непосредственно на субуровень AAL. Формат протокольного блока данных подуровня конвергенции AAL 3/4-типа показан на рис. 4.3.5.7.
Рис. 4.3.5.7. Формат блока данных подуровня конвергенции AAL 3/4-типа
Тип 3/4 имеет существенную избыточность (4 байта из 48 на каждый SAR-PDU). По этой причине был введен 5-ый тип. Этот уровень обеспечивает канал, ориентированный на соединение, с переменной скоростью обмена (VBR) в широковещательном режиме при минимальном контроле ошибок (или вовсе без него). IP-дейтограммы передаются через сети ATM через адаптационный уровень 5 (RFC-1577). Уровень AAL5 иногда называют SEAL (simple and efficient adaptation layer - простой и эффективный адаптационный уровень). AAL5 занимает в наборе протоколов семейства ATM нишу протокола udp стека TCP/IP. Формат ячейки SAR-PDU 5-го типа показан на рис. 4.3.5.8.
Рис. 4.3.5.8. Формат ячейки SAR-PDU 5-го типа (AAL5)
Рис. 4.3.5.8a. Формат сообщения AAL5 субуровня конвергенции
Однобайтовое поле, расположенное между полями UU и длина зарезервировано для использования в будущем. Так как здесь для переноса информации используется заголовок, работа AAL не является независимой от нижележащего уровня, что является нарушением эталонной модели. Инкапсулироваться в поля данных AAL5 могут блоки длиной до 216-1 октетов (65535). Выполнение операций здесь зависит от того, работает ли система в режиме сообщения или потока. На подуровне конвергенции для передачи протокольного блока данных используется 4-х байтовая CRC с образующим полиномом G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1, что обеспечивает высокую надежность корректности доставки. Положение адаптационного уровня в рамках эталонной модели показано на рис. 4.3.5.9. Следует впрочем заметить, что не вполне ясно, какой уровень занимает сам протокол ATM (транспортный или сетевой?).
Рис. 4.3.5.9. Положение уровней ATM в универсальной модели Верхние уровни управления для ATM базируются на рекомендациях ccitt I450/1 (Q.930/1). В случае использования ATM для Интернет значение MTU по умолчанию равно 9180 (RFC-1626), так как фрагментация IP-дейтограмм крайне нежелательна (AAL). Работа протоколов TCP/IP поверх ATM описана в документах RFC-1483, -1577, -1626, -1680, -1695, -1754, -1755, -1821, -1926, -1932 (полужирным шрифтом выделены коды документов, являющиеся стандартами Интернет). Ниже на рис. 4.3.5.10 показано, как пакеты atm размещаются в кадрах STM-1 (виртуальный контейнер VC-4).
Рис. 4.3.5.10. Размещение atm пакетов в STM-1 кадре В STM-1 для передачи ячеек выделяется полоса пропускания
Форматы адресов согласно спецификации интерфейса "пользователь-сеть" представлены на рис. 4.3.5.11.
Рис. 4.3.5.11. Формат DCC ATM с числовым кодом страны.
Формат ICD с указателем международного кода отличается от формата DCC тем, что в нем поле DCC заменено полем международного кода ICD (international code designator). Формат адреса Е.164 NSAP, где идентификатор исходной области является номером Е.164, представлен на рис. 4.3.5.12. Структура номера (15 десятичных цифр в кодировке BCD) места назначения отображена на рис. 4.3.5.13. Важную роль в управлении сетями АТМ играет информация OAM(operations and maintenance). Здесь осуществляется тесное взаимодействие с потоками управления sdh (F1-F5). F1 - поток данных oam уровня регенерационной секции SDH.
Рис. 4.3.5.12. Формат адреса Е.164 NSAP
Рис. 4.3.5.13. Структура номеров Код страны (СС -country code) занимает от одной до трех цифр (из 15). Маршрутизация в atm отличается от аналогичных процессов в сетях с коммутацией пакетов. Сети АТМ в основном ориентированы на соединение. Ячейки транспортируются по уже выбранному маршруту через коммутаторы АТМ в соответствии со значениями идентификаторов виртуального пути и виртуального канала. Вычисление маршрута осуществляется на специальном сервере. Потоки информации F4 или F5 принимаются и обрабатываются устройствами, которые формируют виртуальные пути или каналы. Формат информационного поля ячейки oam показан на рис. 4.3.5.14. Поток информации oam F4 уровня виртуального пути для идентификации потока точка-точка использует идентификатор виртуального канала VCI=4, а для сегментных потоков VCI=3.
Рис. 4.3.5.14. Формат ячейки OAM F4 Поток ячеек OAM F5 уровня виртуального канала каких-либо специальных идентификаторов виртуальных путей не использует. В заголовках ячеек потока oam F5 типа точка-точка в поле типа данных (PT) записывается код 100, а для сегментных потоков виртуальных каналов PT=101. Значения кодов полей тип OAM и выполняемой функции приведены в таблице 4.3.5.5. Для решения проблем выявления и локализации отказов в сети АТМ используются ячейки AIS (alarm indication signal - аварийный сигнал), RDI/FERF (remote defect indication/far end reporting failure - указатель отказа на удаленном конце), контроля непрерывности (continuity check) и проверки с применением обратной связи (loopback). Для ячеек AIS и RDI поля тип отказа имеет 8 байт (по умолчанию во все октеты записывается 0х6А), а для указателя места отказа выделено 9 байт. Полезная часть поля данных в этих ячейках равна 45 байтам, из них 28 зарезервировано на будущее. Таблица 4.3.5.5.
Контроль рабочих характеристик сети АТМ производится без нарушения соединений и без снижения качества обслуживания. Для запуска и остановки процесса измерения служат ячейки типа activation/deactivation. В ячейке oam для этих целей в поле данных выделено 45 байт. Формат субполей поля данных представлен на рис. 4.3.5.15.
Рис. 4.3.5.15. Формат субполей поля данных oam activation/deactivation Субполе неиспользуемые октеты заполняется байтами 0х6А, а субполя блок РМ - кодами 0000. Значения кодов поля идентификатор сообщения приведены в таблице 4.3.5.6. Таблица 4.3.5.6.
В субполе направление действия заносится код 10 при направлении от А к В и 01 при противоположном направлении. В поле размер записывается код 1000 при длине 1024 ячеек, 0100 - при 512, 0010 - при 256 и 0001 - при 128. Размеры блоков для направлений А ->b и В ->a могут быть и неравными. Мониторинг рабочих параметров может выполняться для А ->b, В ->a или для обоих направлений одновременно. Формат ячеек oam типа измерение рабочих характеристик представлен на рис. 4.3.5.16.
Рис. 4.3.5.16. Формат ячеек oam типа измерение рабочих характеристик В субполя BIP-16 (bit interleaved parity) и счет потерянных ячеек в отсутствии прямого мониторинга по умолчанию заносится код 0х6А, аналогичный код записывается в субполя число ячеек пользователя и результаты анализа в отсутствие обратного мониторинга. В неиспользуемое поле записываются 1 во все биты, если не использована временная метка. Поле порядковый номер мониторинга (MSN - monitoring sequence number) содержит номер ячейки oam типа PM по модулю 256. Поле общее число ячеек пользователя (TUC - total user cell) записывается число пользовательских ячеек, отправленных после последней ячейки OAM типа PM. Один физический отказ может сгенерировать большое число ячеек OAM. Для блокировки такой возможности введено ограничение на период генерации таких ячеек (> нескольких секунд). Операции проверки тракта, выполняемые с помощью ячеек OAM типа loopback, позволяют выявить место возникновения неисправностей. Формат поля специальных функций ячейки OAM типа loopback отображен на рис. 4.3.5.17 (см. также рис. 4.3.5.14).
Рис. 4.3.5.17. Формат ячейки oam типа loopback Поле неиспользуемое содержит во всех октетах по умолчанию код 0х6А. Поле индикатор шлейфа содержит 1 при посылке отправителем (остальные семь бит равны нулю), единица заменяется нулем в момент приема. При получении ячейки с индикатором шлейфа, равным нулю, она уничтожается. Поле корреляционная метка используется отправителем для идентификации отклика. Поле идентификатор места шлейфа определяет место, откуда ячейка должна быть послана назад. Если поле содержит все единицы, таким местом является адресат. Поле идентификатор источника служит для распознавания ячейки и ее уничтожения при возвращении. Предоставление услуг без установления соединения соответствует уровню выше чем АТМ и требует соединения каждого клиента с соответствующим сервером, решающим данную задачу. Большинство локальных и региональных сетей АТМ реализуют именно такой режим. Для передачи данных без установления соединения используется протокол доступа CLNAP (connectionless network access protocol), интерфейс CLAI (connectionless access interface) и сетевой протокол CLNIP (connectionless network interface protocol). Размер поля данных для CLNAP не является постоянным и составляет 9188 октетов, что подразумевает фрагментацию. Эти протоколы работают выше подуровня конвергенции. Соответствующая длина для CLNIP SDU равна 9236 октетам. Формат блока данных CLNIP показан на рис. 4.3.5.18.
Рис. 4.3.5.18. Формат структуры данных протокола CLNIP
Проблему фрагментации и инкапсуляции этих длинных пакетов в АТМ ячейки берет на себя коммутатор доступа. Схема вложения и фрагментации для пакетов clnap отображена на рис. 4.3.5.19. Из рисунка видно, что на подуровне SAR происходит деление пакета на части и укладка полученных сегментов в поля данных ячеек (48 байт).
Рис. 4.3.5.19. Схема вложения и фрагментации для пакетов CLNAP
Для использования одного и того же виртуального канала многими протоколами служит LLC-инкапсуляция (logical link control). LLC-заголовок укладывается в поле данных перед PDU и содержит в себе информацию, необходимую для того, чтобы корректно обработать AAL5 CPCS-PDU. Обычно такой заголовок имеет формат IEEE 802.2, за которым может следовать SNAP-заголовок IEEE 802.1a. LLC-заголовок, содержащий код 0xFE-fe-03, говорит о том, что далее следует маршрутизируемый pdu длиной 216-4 октетов. Одно-октетный код NLPID идентифицирует сетевой протокол. Значения кодов NLPID представлены в таблице 4.3.5.7. Таблица 4.3.5.7. Значения кодов NLPID
Формат PDU для маршрутизируемых данных при использовании протоколов, не принадлежащих ISO, представлен на рис. 4.3.5.20 (случай IP-дейтограммы).
Рис. 4.3.5.20. Формат IP PDU при транспортировке с использованием AAL5 ATM Пропускная способность сети АТМ (150 Мбит/с) позволяет передавать немного более 360000 ячеек в секунду, что означает для ATM-переключателя время коммутации менее 2,7 мксек. Реальный переключатель может иметь от 16 до 1024 входных линий, что может означать коммутацию 16-1024 ячеек каждые 2,7 мксек. При быстродействии 622 Мбит/с новая порция ячеек поступает каждые 700 нсек. Постоянство длины ячеек упрощает конструкцию ключа. Все АТМ-ключи имеют целью обеспечить коммутацию с минимальной вероятностью потери и исключить возможность изменения порядка следования ячеек. Приемлемой считается вероятность потери ячейки не более 10-12. Это эквивалентно для большого коммутатора потери 1-2 ячеек в час. Уменьшению вероятности потери способствует создание буферов конвейерного типа. Если на вход переключателя приходят две ячейки одновременно, одна из них обслуживается, а вторая ставится в очередь (запоминается в буфере). Выбор ячеек может производиться псевдослучайно или циклически. При этом не должно возникать предпочтений для каких-то каналов. Если в один цикл на вход (каналы 1, 2, 3 и 4) коммутатора пришли четыре ячейки, предназначенные для выходных линий J+2, J, J+2 и J+1, соответственно, то на линии J+2 возникает конфликт. Предположим, что будет обслужена ячейка, поступившая по первой входной линии, а ячейка на входной линии 3 будет поставлена в очередь. В начале следующего цикла на выход попадут три ячейки. Предположим также, что в этот цикл на ходы коммутатора (1 и 3) придут ячейки адресованные для линий J+3 и J, соответственно. Ячейка, адресованная J, будет поставлена в очередь вслед за ячейкой, адресованной J+2. Все эти ячейки будут переданы только на 4-ом цикле. Таким образом, попадание в очередь на входе ячейки блокирует передачу последующих ячеек даже если выходные каналы для их передачи свободны. Чтобы исключить блокировку такого рода можно организовать очередь не на входе, а на выходе коммутатора. При этом для коммутатора с 1024 входами теоретически может понадобиться 1024 буфера на каждом выходе. Реально число таких буферов значительно меньше. Такая схема АТМ-коммутатора (8*8) показана на рис. 4.3.5.21.
Рис. 4.3.5.21. Схема переключателя с организацией очередей на выходе Концентратор выбирает N ячеек для помещения в очередь (предполагается, что максимальная длина очереди может быть равна N). Выходной буфер уже заполнен, ячека может быть потеряна. При построении АТМ-коммутаторов часто используется схема сети с многокаскадными соединениями. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.3.4 Протокол Frame Relay
UP:
4.3 Региональные сети
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.3.1 Эталонная сетевая модель ISO
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Международная организация по стандартизации (ISO) определила 7-уровневую эталонную сетевую модель для открытых систем (OSI), (Интернет использует 4-х уровневое подмножество). Ниже на рис. 4.3.1.1 показана схема этих уровней, справа записаны коды документов международного Телекоммуникационного союза (ITU), регламентирующих протоколы соответствующих уровней.
Рис. 4.3.1.1. Семиуровневая эталонная модель ISO Разбиение совокупности (стека) сетевых протоколов по уровням связана с попыткой унификации аппаратного и программного обеспечения. Предполагается, что каждому из уровней соответствует определенная ункциональная программа с жестко заданными входным и выходным интерфейсами. Форматы данных на заданном уровне модели для отправителя и получателя должны быть идентичны. Физический уровень локальных сетей определен документами, например, Ethernet II, IEEE 802.3 и т.д. Модели ISO наиболее полно соответствуют сети X.25. Физический уровень X.25 определяет стандарт на связь между ЭВМ и сетевыми коммутаторами (X.21), а также на процедуры обмена пакетами между ЭВМ. X.21 характеризует некоторые аспекты построения общественных сетей передачи данных. Следует учитывать, что стандарт X.25 появился раньше рекомендаций ITU-T и опыт его применения был учтен при составлении новейших рекомендаций. На физическом уровне могут использоваться также протоколы X.21bis, RS232 или V.35. Канальный уровень определяет то, как информация передается от ЭВМ к пакетному коммутатору (HDLC - high data link communication, бит-ориентированная процедура управления), на этом уровне исправляются ошибки, возникающие на физическом уровне. Сетевой уровень определяет взаимодействие различных частей субсети, форматы пакетов, процедуры повторной передачи пакетов, стандартизует схему адресации и маршрутизации. Транспортный уровень определяет надежность передачи данных по схеме точка-точка, избавляет уровень сессий от забот по обеспечению надежной и эффективной передачи данных. Уровень сессий описывает то, как протокольное программное обеспечение должно организовать обеспечение выполнения любых прикладных программ. Организует двухстороннее взаимодействие сетевых объектов и необходимую синхронизацию процедур. Презентационный уровень обеспечивает прикладной уровень стандартными услугами (сжатие информации, поддержка ASN.1 (abstract syntax notation 1) управляющих протоколов и т.д.). Прикладной уровень - это все, что может понадобиться пользователям сетей, например X.400. Международным стандартом в процедуре HDLC определены два вида кадров:
Рис. 4.3.1.2 Два вида кадров процедур HDLC Флаг f = 01111110 задает границы кадра, SCS - контрольная сумма. Поля информация может иметь переменную длину, кратную восьми бит. Для HDLC определены три класса кадров: информационные (I), управляющие (S -supervisory) и ненумерованные (U - unnumbered). (Эти форматы соответствуют канальному уровню протокола x.25). Формат поля управление I-кадра показан на рис. 4.3.1.3.
Рис. 4.3.1.3. Формат поля управления I-кадра (нумерация по модулю 128) \N(S) и N(S) представляют собой поля номера кадров. N(R) - номер текущего кадра, а N(R) - номер следующего кадра, который отправитель текущего кадра ожидает получить. При несоответствии ожидаемого номера и полученного возникает ошибка. Если используется нумерация кадров по модулю 8, то максимальное число кадров, не получивших подтверждение не может превышать 7, а размер полей N(S) и N(R) равен трем бит. Это справедливо и для s-кадров. i, s и u-кадры могут иметь обычный (один байт) и расширенный (2 байта) форматы. Младший бит (1) расположен слева. Поле P/F - флаг опрос/окончание опроса. Информационный (I) кадр содержит поле информация (см. рис. 4.3.1.2). Формат S- кадра показан на рис. 4.3.1.4.
Рис. 4.3.1.4. Формат поля управления s-кадра (расширенный вариант) Для однобайтовой версии s-кадра за полем s следует непосредственно поле P/F. Поле S определяет тип управляющего кадра (см. таблицу 4.3.1.1): Таблица 4.3.1.1. Коды поля S
S-кадры служат для передачи сигналов подтверждения, запросов повторной передачи или прекращения посылки кадров из-за блокировки приема в местной станции. При получении кадра с неверным порядковым номером (напр., предшествующий кадр потерян), приемник посылает S-кадр REJ, что означает необходимость повторной посылки предшествующего кадра и всех последующих. Кадр SREJ(n) указывает на то, что все кадры до n-1, включительно, доставлены без ошибок, а при доставке кадра n допущена ошибка и он должен быть послан повторно. В отличии от rej запрашивается пересылка только одного кадра. Связь с терминалом является временной, если бит P/F равен 1. Если адрес места назначения равен 11111111, то обращение является широковещательным. Формат U-кадра представлен на рис. 4.3.1.5.
Рис. 4.3.1.5. Формат поля управления U-кадра U-кадр используется для формирования канала, изменения режима работы и управления системой передачи данных. Существует версия, когда поле "0" размещается не в 8-ой позиции, а в 5-ой. В нижней части рисунка показана расширенная версия формата. Младшие разряды располагаются слева. Поле m может принимать значения, приведенные в таблице 3.5.1.2. Установление соединения начинается с передачи в канал команды SABM (или SABME). Если удаленной станцией эта команда принята правильно и имеется возможность установления соединения, то присылается отклик UA. При этом переменные состояния на удаленной станции V(S) и V(R) (аналоги полей N(S) и N(R) в пакетах) устанавливаются в нулевое состояние. Таблица 4.3.1.2. Коды поля M (U-кадр).
После благополучного получения пакета ua локальной станцией соединение считается установленным и может начинаться обмен данными. Информацию несут кадры типа I, а также FRMR и UI-кадры типа U. В кадре ответа FRMR должно присутствовать информационное поле, содержащее обоснование присылки такого ответа. Структура этого поля для обычного и расширенного (внизу) форматов показана на рис. 4.3.1.6.
Рис. 4.3.1.6. Структура информационного поля для FRMR-кадров Биты A, B, C и D определяют причину, по который кадр не был доставлен. Если бит равен 1, то это указывает на соответствующую причины недоставки. Бит A указывает на неверное значение N(R). Бит B =1 говорит о слишком большой длине информационного поля. Бит C - указывает на то, что поле управления неопределенно из-за наличия в кадре недопустимой для данной команды или отклика информационного поля, а D=1 означает, что поле управления принятого кадра не определено или же неприемлемо. V(R) и V(S) текущие значения переменных приема и передачи, соответственно. C/R (Command/Response) =1 означает, что ошибочное сообщение является откликом (=0 - командой). Большинство U-кадров интерпретируются как команды или отклики в зависимости от контекста и того, кто их послал. В некоторых случаях для разделения откликов и команд используется поле адреса. Одним из наиболее известных протоколов сетевого уровня, использующих HDLC, является X.25. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.3 Региональные сети
UP:
4.3 Региональные сети
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.3.2 Протоколы сетей X.25
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
В 1976 году был принят стандарт X.25, который стал основой всемирной системы PSPDN (Packet-Switched Public Data Networks), базирующейся на 7-уровневой модели ISO OSI. Стандарт X.25 был усовершенствован в 1984. X.25 - протокол (ISO 8208:1989; RFC-887, -1381, -1382, -1461, -1598, -1613), который определяет синхронный интерфейс между терминальным оборудованием (DTE - Data Terminal Equipment) и оборудованием передачи данных (DCE - Data Communication Equipment) для терминалов, работающих в пакетном режиме. По существу это протокол связи оборудования с сетью. Главный недостаток протокола X.25 - большие задержки отклика (типовое значение 0.6 сек). Терминалом может служить ЭВМ или любая другая система, удовлетворяющая требованиям X.25. Соединение DTE - DTE осуществляется через DCE. В протоколе X.25 DCE и DTE используют статистическое мультиплексирование с делением по времени. Одновременно могут реализовываться несколько обменных процессов. Схема взаимодействия DTE и DCE выглядит как: DTE - <логический канал> - DCE <виртуальное соединение> - DCE - <логический канал> - DTE Асинхронный старт-стопный терминал подключается к сети коммутации пакетов через пакетный адаптер данных ПАД (PAD - packet assemble/disassemble) и отвечает рекомендациям X.3, X.28 и X.29. Один ПАД обеспечивает интерфейс для 8, 16 или 24 асинхронных терминалов. Пакет данных состоит обычно из 128 байтов, которые передаются по адресу, содержащемуся в пакете. Но длина пакета может лежать в пределах 64-4096 байтов. Размер пакета также как и величина окна (число пакетов, принимаемых без подтверждения) определяются на фазе установления канала. Прежде чем пакет будет передан, необходимо установить связь между исходными ЭВМ/ПАД и адресуемыми ЭВМ/ПАД. Существуют два вида соединений: коммутируемый виртуальный канал (SVC) и постоянный виртуальный канал (PVC). Предусмотрены две процедуры доступа к каналу:
Виртуальный канал описывается в общем формате пакета, как "логический канал". Логический канал имеет идентификатор, состоящий из 12 бит. Этот идентификатор обычно состоит из номера группы (4 бита) и номера логического канала (8 бит). В группе может быть до 256 логических каналов (за исключением группы 0, которая может иметь только 255 логических каналов). Возможное число групп - 16, поэтому теоретически возможное число виртуальных каналов для каждого соединения x.25 равно 4095 (16x256-1). Постоянный виртуальный канал (PVC - permanent virtual circuit) является аналогом выделенного канала. Коммутируемый виртуальный канал (SVC - switched virtual circuit - напоминает традиционный телефонный вызов) реализует обмен данными. Имеются три типа коммутируемых виртуальных каналов, работающие в дуплексном режиме, но отличающиеся направлением устанавливаемых соединений: входящий SVC, двунаправленный SVC и выходящий SVC. Адресат каждого пакета распознается с помощью идентификатора логического канала (LCI) или номера логического канала (LCN). SVC используются только на время соединения и становятся доступными для повторного использования после разъединения. Все типы пакетов, за исключением пакетов запроса повторного пуска, содержат идентификатор логического канала. Пакет запрос соединения в SVC является единственным типом пакетов, которые содержат адреса в соответствии с рекомендацией X.121. Для установки выходящего соединения через svc ЭВМ выбирает логический канал с наибольшим номером в группе и посылает пакет запрос соединения, содержащий выбранный номер группы канала, адрес получателя (в соответствии с рекомендацией X.121) и в отдельных случаях свой собственный адрес. При установлении входящего соединения центр коммутации пакетов (ЦКП) выбирает свободный логический канал с наименьшим номером в группе каналов порта адресуемой ЭВМ и помещает этот логический номер группы и канала в пакет входящий запрос соединения. После того как соединение через svc установлено, ЭВМ направляют свои пакеты, используя номера своих логических групп/каналов, а ЦПК в сети осуществляет транспортировку пакетов и преобразование номеров логических групп/каналов. Как только установленное по svc логическое соединение разъединяется, номера логических групп/каналов на обоих концах соединения освобождаются и становятся доступными для повторного использования. Соответствие между ЦКП/портом, выделенным для терминального оборудования, адресами (согласно рекомендациям x.121) и номерами логических каналов известно в сети только ЦКП. Выбор ЭВМ свободного канала с наибольшим номером при каждом выходящем соединении и выбор в ЦКП свободного канала с наименьшим номером для каждого входящего позволяют избежать конфликтов. С этой же целью используются две логические группы: одна только для входящих соединений, а другая только для выходящих. Перед подключением к сети пользователь должен определить, сколько pvc и svc требуется на каждую точку физического интерфейса x.25. Асинхронные терминалы подключаются к сети коммутации пакетов через встроенные или удаленные пакетные адаптеры данных (ПАД). Встроенный ПАД обычно располагается вместе с ЦКП в его стойке. В этом случае каждый асинхронный терминал, расположенный в удаленном месте, подключается к своему встроенному ПАД через отдельный канал связи (протокол Х.28). В альтернативном случае удаленный ПАД (небольшое отдельное устройство) может быть расположен в удаленном месте и подключается к своему ЦКП через канал связи (X.25). С помощью удаленного ПАД к ЦКП подключается 8-16 асинхронных терминалов. Встроенный ПАД может быть совместно использован несколькими терминалами, расположенными в различных местах, в то время как удаленный ПАД обслуживает терминалы, расположенные обычно в одном месте. Существует еще один аспект размещения ПАД, связанный с помехами в каналах связи и использованием протоколов. Удаленный ПАД подключается к ЦКП на канальном уровне в соответствии с рекомендацией X.25. В качестве протокола канала данных в рекомендации X.25 реализуется подмножество HDLC, обеспечивающее автоматическую повторную передачу данных в случае их искажения при возникновении помех в линии. Асинхронный терминал использует для диалога с групповым ПАД процедуры, описанные в рекомендации X.28, в которых не предусмотрена возможность повторной передачи в случае ошибки. Поэтому канал между синхронным терминалом и групповым ПАД не защищен от возникновения ошибок данных в результате линейных помех. Процедуры ПАД определены в рекомендациях МККТТ (см. приложение 10.1).
Основные функции ПАД соответствуют рекомендациям X.3:
В постоянном запоминающем устройстве ПАД хранятся параметры. Эти параметры могут быть установлены либо асинхронным терминалом, подключенным к ПАД, либо любой ЭВМ в сети, которая удовлетворяет условиям рекомендации X.29. В рекомендации X.29 МККТТ эти параметры названы управляющей информацией. Поэтому необходимо квалифицировать данные, проходящие между ЭВМ и ПАД, либо как управляющую информацию (сообщения ПАД), либо как собственно данные от асинхронного терминала. Сеть X.25 предоставляет пользователю старт-стопного терминала средства, позволяющие выбрать параметры ПАД с заранее определенными значениями. Пользователь посылает в ПАД команду выбора профайла, которая включает идентификатор профайла. Этим определяется один из нескольких стандартных профайлов, хранящихся в ПАД. Идентификатор профайла и параметр 11 ПАД (скорость терминала) включаются в "поле данных пользователя" пакетов типа запрос соединения, посылаемых ПАД. ЭВМ (ПАД) использует это поле, извлекая из него информацию о терминале, пославшем запрос. Пакетный терминал является интеллектуальным устройством (например, ЭВМ, или внешним ПАД'ом), которое обеспечивает синхронный обмен с сетью на скорости 2400, 4800, 9600 бит/c или 48 Кбит/с, используя трехуровневый протокол X.25. Возможная схема подключения терминальных устройств к сети X.25 показана на рис. 4.3.2.1. Из рисунка 4.3.2.1 видно, что подключение ЭВМ и другого терминального оборудования возможно как к встроенному, так и удаленному ПАД (протокол X.28), а также непосредственно к ЦКП (протокол X.25, X.29). Связи с удаленными объектами осуществляются через соответствующие модемы (на рисунке не показаны). Для международного соединения необходимо указать код страны из трех цифр, а также набрать одну цифру 9 перед сетевым адресом пользователя. Таким образом, всего требуется не более 15 цифровых символов. Для установления коммутируемого соединения оператор вначале вручную набирает номер ПАД и ждет подтверждения соединения с телефонным узлом общего пользования. Как только соединение установлено, оператор набирает 12-символьный код "сетевого идентификатора пользователя". ПАД обеспечивает операцию эхо-контроля, которая позволяет оператору терминала визуально проверять данные, посылаемые в ПАД. Наиболее серьезным недостатком встроенного ПАД является отсутствие какого-либо линейного протокола, предусматривающего устранение ошибок в данных, посылаемых от ПАД к терминалу. В удаленном ПАД предусмотрена процедура восстановления ошибочных данных, однако он подключается к сети как "пакетный терминал".
Рис. 4.3.2.1. Возможная топология сети X.25 Сетевой адрес пользователя состоит из 12 десятичных цифр. 1-4 - идентификатор сети передачи данных (3 - страна, 4 - сеть); 5-12 - национальный номер (5-7 местная область, 8-12 - местный номер). Международная система адресации для систем передачи данных общего пользователя описана в рекомендациях X.121 международного комитета по телефонии и телеграфии. Каждое подключение к сети коммутации пакетов имеет свой национальный номер. Протокол X.25 не определяет технику маршрутизации пакетов по сети. Для целей управления в сетях X.25 используется протокол snmp и база данных MIB (как и в сетях Интернет). Три базовых уровня протокола X.25 и схема потоков информации отображены на рис. 4.3.2.2. Для подключения по виртуальному каналу ЭВМ/ПАД посылается пакет (call request), содержащий сетевой адрес пользователя. После подтверждения соединения и передачи/приема данных виртуальное соединение может быть разорвано путем передачи пакета (clear request), инициатором в этом случае выступает удаленная ЭВМ. При невозможности установить связь clear request посылается сетью. Такой пакет содержит два информационных октета. Первый содержит код причины, второй является диагностическим кодом. Ниже в таблице 4.3.2.1 приведены коды причин ошибки. Таблица 4.3.2.1. Коды причины ошибки
Один физический канал связи X.25 может поддерживать несколько коммутируемых виртуальных каналов. Постоянный виртуальный канал подобен выделенной линии - обмен возможен в любой момент. X.25 определяет первые три уровня соединения открытых систем (см. рис. 4.3.2.2).
X.21 - универсальный интерфейс между оконечным оборудованием (DTE) и аппаратурой передачи данных (DCE) для синхронного режима работы в сетях общего пользования. X.21bis - тоже, но для модемов, удовлетворяющих рекомендациям серии V. Для канального уровня используется подмножество протокола HDLC (являющегося развитием стандарта SDLC IBM), обеспечивающее возможность автоматической повторной передачи в случае возникновения ошибок в линии.
Рис. 4.3.2.2. Три уровня X.25 Формат кадра для протокола HDLC показан на рис. 4.3.2.3 (байты передаются, начиная с младшего бита):
Рис. 4.3.2.3. Формат кадра X.25 Открывающий и закрывающий флаги для бит-ориентированного формата несут в себе код 0x7e. Когда не передается никакой информации, по каналу пересылается непрерывный поток флагов 01111110. Посылка более 6 единиц подряд воспринимается как флаг абортирования связи. Если необходимо передать информационную последовательность 01111110, после первых пяти единиц вводится дополнительный нуль, приемник восстанавливает истинную информацию, удаляя эти лишние нули. В случае байт-ориентированных кадров открывающий и завершающий флаги имеют по два байта [DLE (Символы кодов стандарта ISO 646-1973 (МТК-5, ГОСТ 13059-74). Здесь и далее используется русская терминология в соответствии со стандартом ГОСТ 26556-85, STX и DLE, ETX, соответственно, для информационного кадра и DLE, STX и DLE, ETX для управляющего]. Адрес в пакете X.25 занимает всего один байт, что определяет предельное число терминальных устройств, подключаемых к одному каналу. Кадр на уровне 2 имеет двухбайтовый заголовок, содержащий байт адреса и байт типа. Для нумерации кадров на уровне 2 используется 3 бита. При работе со скользящим окном откликов это позволяет иметь до 7 кадров в очереди. При использовании спутниковых каналов с большими задержками можно переходить в режим расширенной нумерации (7 бит), где длина очереди может достигать 128. Если удаленный партнер не способен работать в режиме расширенной нумерации, он отклонит запрос соединения. При работе в режиме расширенной нумерации возможно применение 3-байтовых заголовков вместо двухбайтовых. Значения поля идентификатора общего формата (GFI - general format identifier) приведено в таблице 4.3.2.2. Бит 8 этого поля (Q) используется в информационных пакетах как индикатор уровня передаваемых данных. Групповой номер логического канала и номер логического канала присваиваются по соглашению с администрацией сети во время постановки на обслуживание. Поля групповой номер логического канала и номер логического канала присутствуют во всех пакетах кроме пакетов регистрации и повторного пуска, где они принимают нулевое значение. Таблица 4.3.2.2. Значения кодов идентификатора общего формата (GFI)
x - бит может принимать значения 0 или 1. Допустимые значения кодов в поле тип пакета приведены в таблице 4.3.2.3. Таблица 4.3.2.3. Значения кодов тип пакета
x - отмечет разряды, которые могут принимать значения 0 или 1. Четырехбитовые поля длина адреса отправителя и длина адреса получателя характеризуют длины последующих полей переменной длины. Длина выражается в полуоктетах. Далее следуют соответствующие адреса. В каждом полуоктете записывается десятичная цифра адреса, при необходимости поле адреса дополняется нулями до целого числа октетов. Для пакетов установления связи кадры имеют формат, показанный на рис. 4.3.2.4.
Рис. 4.3.2.4. Формат кадра запроса на соединение и соединение установлено Поле опции содержит целое число октетов, но не более 109, следующее же поле может содержать до 128 байт. Опция типа fast select позволяет поместить до 64 байтов в информационном поле пользователя, во многих случаях этого оказывается достаточно и исключается необходимость переходить в режим пересылки данных. Если вызываемое DTE не присылает сообщения вызов принят или запрос завершения (установление связи отвергнуто) за отведенное для этого время, процедура завершается и процессу, инициализировавшему запрос, присылается соответствующий код ошибки. При успешной обработке запроса (прислано сообщение соединение установлено) система переходит в режим обмена данными. DTE может в любой момент инициировать процедуру разрыва связи, послав сообщение запрос завершения. DCE сообщает о завершении соединения путем присылки пакета индикация завершения, на который DTE должно прислать отклик подтверждение завершения. Формат пакетов запроса и подтверждения завершения отображен на рис. 4.3.2.4. и 4.3.2.5. Байты 1 и 2 на рисунке 4.3.2.5 не показаны, так как они идентичны тому, что представлено на рис. 4.3.2.4.
Рис. 4.3.2.5. Формат пакетов запроса завершения Коды причины завершения связи приведены в таблице 4.3.2.1. Однобайтовое поле диагностический код позволяет уточнить причину. В таблице 4.3.2.4 приведены коды причины повторного пуска. Формат пакетов подтверждения завершения представлен на рис. 4.3.2.6. Таблица 4.3.2.4. Коды причин повторного пуска
Рис. 4.3.2.6. Формат пакетов подтверждения завершения Для инициализации обмена информацией (первичного или повторного), а также для прерывания виртуальной связи и возвращения виртуальных каналов в исходное состояние используются запросы повторного пуска (и подтверждение повторного пуска). DTE может выдать запрос повторного пуска (к DCE) в любой момент времени, переводя логический канал в исходное состояние. DCE в ответ должно послать сообщение подтверждение повторного пуска. Инициатором повторного пуска может быть и dce, для этого оно посылает сообщение индикация повторного пуска. DTE в результате устанавливает логический канал в исходное состояние и посылает dce сообщение подтверждение повторного пуска. Форматы пакетов, несущих эти сообщения показаны на рис. 4.3.2.6 и 4.3.2.7. Эти пакеты не имеют полей группового номера логического канала и LCN (см. рис. 4.3.2.7 и .8). Процедура повторной установки во многом аналогична повторному пуску и используются всякий раз при выявлении сбоя, чтобы вернуть виртуальную связь или постоянный виртуальный канал в исходное состояние.
Рис. 4.3.2.7. Формат пакета запроса повторного пуска (слева) и повторной установки Таблица 4.3.2.5. Коды причин повторной установки
Партнер - получатель этого запроса должен прислать сообщение подтверждение повторной установки (рис. 4.3.2.8). При этом возможны потери информации (также как и в случае повторного пуска), так как некоторые пакеты, находящиеся в сети в момент реализации запроса повторной установки или повторного пуска будут потеряны. Инициатором посылки запроса повторной установки может быть dte и dce. Коды причин повторной установки представлены в таблице 4.3.2.5.
Рис. 4.3.2.8. Формат пакета подтверждения повторного пуска (слева) и повторной установки (справа) Пакеты данных передаются по постоянным виртуальным каналам или через виртуальные соединения после их создания. Пакеты данных распознаются по нулевому младшему биту (бит с номером 1) в третьем октете. Остальные биты этого октета используются для управления. Форматы пакетов данных показаны на рис. 4.3.2.9. Информационное поле начинается с четвертого байта (при расширенной нумерации с пятого) и может иметь длину 16-4096, хотя в рекомендациях стандарта x.25 оговорена величина 128 октетов. Если принимающая сторона не способна принять пакет данной длины, связь должна быть переустановлена, а стороне-инициатору соединения послано сообщение об ошибке. Каждому пакету данные присваивается порядковый номер N(S), значение которого при установлении соединения равно нулю.
Рис. 4.3.2.9. Форматы пакетов данные. Слева - по модулю 8, справа - по модулю 128 Q -бит определяет тип кадра-пакета, Q=1 - управляющий пакет для PAD, Q=0 - информационный пакет. Бит D используется для запроса специального отклика на пакет со стороны удаленного конца виртуального канала. Бит M указывает на то, что данный пакет является частью более крупного пакета, который должен быть воссоздан позднее. Индекс S (send) соответствует отправке, а индекс R - приему (receive). Если используется нумерация пакетов по модулю 8, N(S) занимает биты 2-4 включительно, при нумерации по модулю 128 для этого отводятся биты 2-8. Нумерация пакетов позволяет выявить потерю пакетов или изменение порядка их доставки. N(R) является номером пакета с принимающей стороны. Бит подтверждения доставки D (идентификатор формата) служит для указания необходимости сообщения о доставке данных получателем. Если D=1, то DTE обязано подтвердить доставку. Обязательность процедуры подтверждения определяется уже на фазе установления связи (сообщение запрос на установление связи принят). Если какой-либо узел по пути пересылки пакета не поддерживает процедуру подтверждения доставки, он пошлет сообщение запрос завершения (причина - несовместимость у адресата) и связь должна быть сформирована заново с учетом необходимости подтверждения во всех узлах-участниках. Размер поля данные в пакете может быть разным для разных узлов, участвующих в обмене. По этой причине число полученных пакетов может оказаться больше (или меньше) числа посланных. Для таких случаев предусмотрен флаг m (дополнительные данные). Возможность фрагментации и последующей сборки пакетов определяется управляющими битами M и D (см. таблицу 4.3.2.6). Таблица 4.3.2.6. Управление фрагментацией и сборкой пакетов с помощью битов M и D
Таким образом, при фрагментации исходного сообщения все пакеты кроме последнего должны иметь бит m=1. Нумерация пакетов по модулю 8 означает, что им последовательно присваиваются номера 0,1,2,3,4,5,6,7,0,1,2 и т.д. Аналогично при нумерации по модулю 128 - 0,1,2,...127,0,1,2,3 и т.д. Форма нумерации пакетов определяет также размер "окна", то есть число пакетов, которые могут быть переданы, не дожидаюсь подтверждения получения. По умолчанию размер окна равен 2, другие значения могут быть согласованы на фазе установления соединения. Принцип использования окон при передаче пакетов более подробно описан в разделе "3.6.2 Протокол TCP". Для управления процессом передачи данных используются сообщения "готов к приему" и "не готов к приему". Форматы этих пакетов показаны на рис. 4.3.2.10 и 4.3.2.11.
Рис 4.3.2.10. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 8.
Рис 4.3.2.11. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 128. Код N(R) на входе DCE должен лежать в пределах между N(R) последнего принятого пакета и N(S) следующего пакета, который должен быть послан из DCE к DTE. При невыполнении этого условия связь будет переустановлена и передача повторена. Пакеты готовность к приему используются для сообщения о готовности принять пакеты, с номерами, начиная с номера N(R), приведенного в пакете. Пакеты неготовность к приему служат для того, чтобы сообщить о временной неспособности принять данные. При поступлении этого сообщения отправитель должен прервать передачу до получения сообщения готовность к приему. DTE может передавать данные удаленному DTE, не следуя правилам управления потоком данных. Для реализации такой возможности предусмотрена операция прерывания. Эта операция не влияет на передачу данных и управление. Формат пакета прерывание и подтверждение прерывания показан на рис. 4.3.2.12.
Рис. 4.3.2.12. Формат пакетов прерывание и подтверждение прерывания Идентификатор формата равен 0x1 для нумерации по модулю 8 и 0x2 при нумерации по модулю 128. Передав сообщение прерывание, DTE должно ожидать получение пакета подтверждение прерывания. Максимальный размер поля данные пользователя в пакете прерывание не должен превышать 32 байт. Иногда в сетях для сообщения об ошибке используется пакет "диагностика". Этот пакет посылается DCE, адресуется DTE и несет информацию о неустранимых на уровне пакетов ошибках. Пакет диагностика посылается лишь один раз сразу после выявления ошибки. Подтверждения его получения не требуется. Формат пакета показан на рис. 4.3.2.13.
Рис. 4.3.2.13. Формат пакета диагностика Поле код диагностики несет в себе информацию об ошибке, вызвавшей посылку этого пакета. Если же пакет диагностика передается в качестве отклика на пакет с ошибками от DTE, то поле уточнение диагностики содержит первые три байта пакета DTE. Современные сети создаются ради доступа к определенным услугам. В протоколе X.25 предусмотрена процедура, которая позволяет получить текущие значения параметров услуг (опций) и модифицировать их. Эта процедура называется регистрацией и не является обязательной. Форматы пакетов запроса регистрации и подтверждения регистрации показаны на рис. 4.3.2.14 и 4.3.2.15. Максимальный размер поля регистрация составляет 109 байт. Инициатором регистрации всегда является dte, которое передает запрос регистрации. В качестве отклика dce посылает пакет подтверждение регистрации, в котором содержатся информация о параметрах доступных услуг. Для выявления доступных услуг может быть послан запрос регистрации, не содержащий списка запрашиваемых услуг.
Рис. 4.3.2.14. Формат пакетов запрос регистрации
Рис. 4.3.2.15. Формат пакетов подтверждение регистрации Получив список доступных услуг из сообщения подтверждение регистрации, может поменять параметры некоторых из них. Если значение какого-либо параметра услуги (опции) не разрешено, DCE должно сообщить разрешенное значение параметра и максимальное и или минимальное разрешенное значение (в зависимости от того больше или меньше допустимого оказалось значение запрошенного параметра). Неисправность сети может привести к тому, что та или иная согласованная ранее услуга станет недоступной. В этом случае DCE должно инициировать процедуру повторного пуска, чтобы уведомить DTE о случившихся изменениях. Кроме процедуры регистрации к необязательным процедурам относятся услуги для замкнутой группы, идентификация пользователей сети, группа поиска, ускоренный обмен, переадресация вызовов, выбор транзитной сети, сообщения о модифицированном адресе, согласование параметров управления потоком и некоторые другие. Повторная передача пакетов согласуется на определенное время и может использоваться во всех логических каналах DTE-DCE. DTE запрашивает повторную передачу одного или нескольких пакетов данные путем посылки сообщения отказ reject), которое определяет логический канал и порядковый номер пакета N(R). Получив пакет отказ DCE, DTE начинает повторную передачу пакетов. Формат пакетов отказ для случаев нумерации по модулю 8 и 128 показан на рис. 4.3.2.16.
Рис. 4.3.2.16. Форматы пакетов типа отказ для нумерации по модулю 8 (слева) и 128 Программное обеспечение принимающей и передающей сторон должно иметь переменные состояния V(R) и V(S), содержащие, соответственно, номера пакетов, которые предстоит получить и послать (см. описание процедуры HDLC). После посылки очередного пакета с N(S) значение V(S) увеличивается на 1. Принимающая сторона сравнивает V(R) с N(S) полученного пакета, при совпадении укладывает N(S) в поле N(R) пакета-отклика и инкрементирует V(R). Отправитель при получении пакета проверяет равенство переменной V(S) и кода поля N(R) в пакете-отклике. Если при получении пакета выясняется, что V(R) не равно N(S), V(R) не инкрементируется, а принимающая сторона отправляет отклик с N(R)=V(R). Отправитель, получив этот отклик и обнаружив, что V(S) не равно N(R), узнает о происшедшем сбое. Номер логического канала (LCN) служит для того, чтобы определить соответствие межу DTE и местным DCE. LCN вместе с полем группового номера логического канала занимают 12 бит, что позволяет иметь до 4095 логических каналов (LCN=0 зарезервировано для использования DCE). 4 бита первого байта управляющего пакета содержат в себе код типа сообщения (таблица 4.3.2.7): Таблица 4.3.2.7 Коды типов сообщений
В поле управляющего сообщения PAD может быть включено любое число параметров, которое допускает максимальный размер пакета. Каждый параметр имеет свой код-номер, за которым в пакете следует значение параметра (таблица 4.3.2.8): Таблица 4.3.2.8. Коды параметров PAD
При работе TCP/IP сети через каналы X.25 и наоборот следует учитывать некоторые отличия кодов предпочтения в полях TOS. Таблица 4.3.2.9 содержит соответствие этих кодов для этих сетей. Таблица 4.3.2.9. Соответствие кодов TOS для сетей TCP/IP и X.25
Для реализации работы сетей ISDN по существующим каналам сети X.25 разработан протокол X.31. X.31 организует канал пользователь-маршрутизатор X.25 (через посредство ISDN) и регламентирует работу ISDN с пакетами X.25. Для решения первой задачи используется сообщение SETUP. Вторая задача решается, когда канал до маршрутизатора сформирован. На этом этапе привлекается набор протоколов X.25, возможно применение протокола X.75 (ISO 8208), который является расширением X.25 для межсетевых связей. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.3.1 Эталонная сетевая модель ISO
UP:
4.3 Региональные сети
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.3.3 Интегрированные сети ISDN
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Название ISDN (integrated system digital network - интегрированные цифровые сети) было предложено группой XI CCITT в 1971 году (cм. П. Боккер, ISDN. Цифровая сеть с интеграцией служб. Понятия, методы, системы. "Радио и связь", М. 1991). Основное назначение ISDN - передача 64-кбит/с по 4-килогерцной проводной линии и обеспечение интегрированных телекоммуникационных услуг (телефон, факс, данные и пр.). Использование для этой цели телефонных проводов имеет два преимущества: они уже существуют и могут использоваться для подачи питания на терминальное оборудование. Выбор 64 Кбит/c стандарта определен простыми соображениями. При 4-килогерцной полосе, согласно теореме Найквиста-Котельникова, частота стробирований должна быть не ниже 8 кГц. Минимальное число двоичных разрядов для представления результатов стробирования голосового сигнала при условии логарифмического преобразования равна 8. Таким образом, в результате перемножения этих чисел и получается значение полосы B-канала ISDN. Базовая конфигурация каналов имеет вид 2*B + D = 2*64 +16 = 144 кбит/с. Помимо B-каналов и вспомогательного D-канала isdn может предложить и другие каналы с большей пропускной способностью, канал Н0 с полосой 384 Кбит/с, Н11 - 1536 и Н12 - 1920 Кбит/c (реальные скорости цифрового потока). Для первичных каналов (1544 и 2048 Кбит/с) полоса D-канала может составлять 64 Кбит/с. Ожидается, что к 2000 году в США будет 10000000 пользователей ISDN. Число же телефонных аппаратов в мире приближается к миллиарду. Существует около 10 разновидностей протоколов ISDN (national ISDN-1 (США); at&t custom; euro-ISDN (Net3) и т.д. ISDN предполагает, что по телекоммуникационным каналам передаются цифровые коды, следовательно аналоговые сигналы в случае телефона или факса должны быть преобразованы соответствующим образом, прежде чем их можно будет передать. При передаче цифровых сигналов используется кодово-импульсная модуляция (cм. раздел "Преобразование, кодирование и передача информации"), впервые примененная во время второй мировой войны. Широкое внедрение этого метода передачи относится к началу 60-х годов. Чтобы обеспечить пропускную способность 64 Кбит/с по имеющимся телефонным проводам, не нарушая теоремы Шеннона, надо ставить ретрансляторы на расстоянии 2 км друг от друга (ведь ослабление сигнала в стандартном кабеле составляет около 15дБ/км). Последние достижения в телекоммуникационных технологиях существенно ослабили это ограничение.). Унификация скоростей передачи данных в ISDN способствует уменьшению объема оборудования, так как исключает необходимость межсетевых интерфейсов, согласующих быстродействие отдельных частей сети. Одной из наиболее массовых приложений ISDN является цифровая телефония. Человеческий голос можно удовлетворительно закодировать, используя лишь 6 бит, но вариации уровня входного сигнала приводит к тому, что нужно не менее 8 бит (с учетом логарифмической характеристики аналого-цифрового преобразователя - АЦП). Значения кодов, полученных в результате последовательных преобразований звука человеческой речи, сильно коррелированны, а это открывает дополнительные возможности для сжатия информации. Сети ISDN дали толчок развитию сетевой технологии. На очереди интеграция Интернет с кабельным телевидением, а там, глядишь, появятся квартирные сети, объединяющие телевизор, ЭВМ, бытовую технику и телефон. Это неудивительно, когда цена хорошего телевизора почти сравнялась с ценой персональной ЭВМ, а многие бытовые устройства имеют встроенные процессоры. Здесь должно быть решено несколько проблем. С одной стороны телевизионные кабели имеют полосу пропускания достаточную для передачи как аналогового (заведомо более 10 каналов), так и цифрового телевидения. Проблема возникает при совмещении передачи телевизионного сигнала и цифрового (или PCM) канала Интернет (кабельные модемы пока достаточно дороги). Современные телевизионные системы обеспечивают порядка 50 каналов одновременно, что накладывает весьма жесткие требования на кабельную разводку между локальным распределительным узлом и оконечными пользователями. Распределительные узлы сегодня объединяются с помощью ATM-каналов (~150 Мбит/с, широкополосный ISDN), что уже сегодня недостаточно. По мере удешевления можно ожидать, что в ближайшем будущем в квартиры конечных пользователей будет осуществлен ввод оптоволоконных кабелей, что решит проблему радикально (не нужен не только телевизионный, но и телефонный кабель). Попутно это решит проблему и видеотелефона. На очереди разработка новых стандартов, которые позволят осуществить такую интеграцию. Так как первоначально ISDN создавалась для передачи голоса и изображения (факс), начнем именно с этих приложений. Для факсов сети ISDN особенно привлекательны, так как может обеспечить высокое разрешение (до 16 линий/мм и лучше) при разумном времени передачи. Для иллюстрации взаимодействия различных частей ISDN рассмотрим рис. 4.3.3.1.
4.3.3.1 Традиционная схема сети ISDN Network termination 1 (NT-1) представляет собой прибор, который преобразует 2-проводную ISDN-линию (от телефонной компании), называемую u-интерфейсом, в 8-проводный S/T-интерфейс. Как правило, к точке Т может быть подключено только одно оконечное устройство. NT2 же предназначено для подключения большого числа разнотипного оборудования (функции NT1 и NT2 могут быть совмещены в одном приборе). Допускается объединение интерфейсов NT2 и TA; возможна работа нескольких NT1 с одним NT2. Интерфейс NT2 может обеспечивать внутриофисный трафик, образуя шину, к которой может подключаться несколько терминалов. Терминальное оборудование (TE) в режиме точка-точка может быть подключено к системе кабелем длиной до 1 км, реальным ограничением служит ослабление в 6 дБ на частоте 96 кГц. В режиме точка-мультиточка (до 8 терминалов) подсоединение производится параллельно, но длина шины в этом случае не должна превышать 200 м (по временным ограничениям). Терминалы, чтобы не вносить искажений, должны иметь входное сопротивление не ниже 2500 Ом. Шина согласуется 100 омным сопротивлением, как со стороны NT1, так с противоположного удаленного конца (это справедливо для принимающих и передающих пар проводов). Оборудование, следующее рекомендациям ISDN, может подключаться в точках S и T. Схемы кабелей, объединяющих интерфейсы ISDN с оконечным оборудованием, показаны на рис. 4.3.3.2.
Рис. 4.3.3.2. Кабели и разъемы в каналах ISDN Точки s и t обеспечивают доступ к канальным услугам ISDN. В точке R (на рис. 4.3.3.2 TA - терминальный адаптер), в зависимости от типа терминального адаптера, доступны некоторые другие стандартные CCITT услуги (X.21 или X.25, V.35, RS-232 или V.24). Входы TE1 и TE2 предназначены для удаленных телекоммуникационных услуг. Все виды услуг могут быть разделены на три группы по форме доступа к 64кбит/с:
Эталонная конфигурация системы передачи и приема сигналов, а также подачи питания на терминальное оборудование показана на рис. 4.3.3.3. Передаваемая по проводам мощность составляет 1-0.5 Вт. Дополнительная пара проводов питания является в настоящее время опционной.
Рис. 4.3.3.3 Эталонная конфигурация системы передачи и приема сигналов, а также подачи питания на терминальное оборудование (*) Относится к полярности кадровых сигналов. (**) относится к полярности питающего напряжения. Используется напряжение питания V= 40 v, которое (если требуется для питания управляющей электроники) преобразуется в 5 В. Логика взаимодействия различных частей сети isdn показана на рис. 4.3.3.4.
Рис. 4.3.3.4 Взаимодействие основных протоколов ISDN Процессом передачи информации между узлами управляет сигнальная система общего канала (CCS - common channel signaling system). В ISDN используется 7-я сигнальная система CCITT (рис. 4.3.1.1). Ее уровни сходны, но не идентичны OSI. На нижних уровнях используется MTP (message transfer part - система передачи сообщений), задачей которой является надежная пересылка сигнальных пакетов по сети. Пользовательские (прикладные) сообщения иерархически расположены над MTP, которая имеет три уровня. Терминальное оборудование подключается к NT через трансформатор (см. рис. 4.3.3.5). На входе трансиверов используются схемы защиты от переходных процессов в линиях связи.
Рис. 4.3.3.5 Терминальный ISDN-интерфейс Нормальная амплитуда сигнала составляет 750 мВ. Формат кадра первого уровня показан на рис. 3.5.3.6, он содержит 48 бит и имеет длительность 250 мксек. Физическая скорость обмена составляет 192 Кбит/с (~5,2 мксек на бит). Блок-схема терминального ISDN-интерфейса показана на рис. 4.3.3.5. Питание интерфейса осуществляется через 4-проводный выходной кабель. На вход интерфейса подается импульсно-кодовый модулированный сигнал (ИКМ). Интерфейс обеспечивает доступ к B- и D-каналам. Номинальное смещение в начале кадра в случае обмена терминал-сеть, как показано на рис. 4.3.3.6, составляет 2 бита. В некоторых случаях оно может оказаться больше из-за задержек в кабеле. Кадр включает в себя несколько l-битов, которые служат для балансировки цуга по постоянному току. Для направления NT -> TE (связь сетевого оборудования с терминальным) первыми битами кадра являются F/L-пары (см. начало и конец диаграмм; временная ось направлена слева направо), нарушающие AMI-правила (чередование полярности сигнала при передаче логической единицы). Раз чередование нарушено, до завершения кадра должно присутствовать еще одно такое нарушение. Бит FA реализует это второе нарушение чередования полярности. A-бит используется в процедуре активации для того, чтобы сообщить терминалу о том, что система синхронизована. Активация может проводиться по инициативе терминала или сетевого оборудования, а деактивация может быть выполнена только сетью. Помимо B1, B2 (байты выделены стрелками) и D-каналов формируются также виртуальные E- и A-каналы. E-канал служит для передачи эхо от NT1 к TE в D-канале. Существует 10-битовое смещение (задержка) между D-битом, посылаемым терминалом, и E-битом эхо (отмечено стрелкой на рис. 4.3.3.6). M-бит используется для выделения мультифреймов (эта услуга недоступна в Европе). M-бит идентифицирует некоторые FA-биты, которые могут быть изъяты для того, чтобы сформировать канал управления (например, при проведении видеоконференций). S-бит является резервным. Назначения различных вспомогательных каналов собраны в таблице А. Таблица А
Следует обратить внимание на то, что базовый ISDN-канал содержит два В-канала по 64 кбит/c и один D-канал с 16 кбит/c. Первичный же isdn-канал содержит 24 или 30 стандартных В-каналов и один D-канал с полосой 64 кбит/c. На первом уровне протокола разрешаются конфликты доступа терминалов к D-каналу. Активация и деактивация осуществляется сигналом <info>. info=0 означает отсутствие сигнала в линии. info=1 передает запрос активации от терминала к NT. info=2 передается от NT к TE с целью запроса активации или указывает, что NT активировано вследствие появления info=1.
info=3 и info=4 представляют собой кадры, содержащие оперативную информацию, передаваемую из TE и NT, соответственно. nt активирует местную передающую систему, которая информирует коммутатор о начале работы пользователя. NT1 в ответ передает терминалу info=2, которое служит для синхронизации. TE откликаются, посылая пакетом info=3, который содержит оперативную информацию. Все терминалы активируются одновременно. Второй уровень решает проблему надежной передачи сообщений по схеме точка-точка. К каждому сообщению добавляется 16 контрольных чисел, включающих в себя идентификатор сообщения. Этот уровень описывает HDLC-процедуры (high level data link communication), которые обычно называются процедурами доступа для D-канала (LAP - link access procedure). LAP D базировался первоначально на рекомендациях X.25 слоя 2, но в настоящее время процедуры LAP D функционально обогатились (разрешено много LAP для одного и того же физического соединения, что позволяет 8-ми терминалам использовать один D-канал). Уровень 2 должен передать уровню 3 сообщения, лишенные ошибок. На уровне 2 решается проблема повторной передачи пакетов в случае их потери или доставки с ошибкой. LAP D базируется на LAP B рекомендаций X.25 для уровня 2. Кадры на уровне 2 представляют собой последовательности 8-битных элементов. Формат кадра второго уровня показан на рис. 4.3.3.7.
Рис. 4.3.3.7 Структура кадра для слоя 2 Стартовый и завершающие флаги передаются так, что к любым 5 единицам подряд добавляется нуль (чтобы избежать имитации сигнатуры в других, в том числе информационных полях). Принимающая сторона эти нули убирает. FSC- вычисляется по методике CRC, описанной в разделе 3.3.1. Каждый кадр начинается и завершается одной и той же последовательностью (сигнатура начала/конца кадра). Размер управляющего поля зависит от типа кадра (1 или 2 октета). Информационные элементы присутствуют только в кадрах, содержащих данные 3-го уровня. Формат двухбайтного поля адреса для уровня 2 показан на рис. 4.3.3.7. Адрес имеет лишь локальное значение и известен только участникам процедуры обмена. Формат байтов адреса показан на рис. 4.3.3.8.
Рис. 4.3.3.8. Адресное поле кадра слоя 2
SAPI=0 - запрос соединения по схеме коммутации каналов;
Рис. 4.3.3.9 Виртуальный интерфейс между слоями 2 и 3 Как видно из рисунка в системе могут использоваться и идентичные коды TEI, если они относятся к разным видам услуг (несовпадающими должны быть лишь комбинации SAPI-TEI). Для кодирования сигналов в ISDN используется метод 2B1Q (2 binary into 1 quaternary), что соответствует
Форматы полей управления для кадров различных модификаций представлены на рисунках 4.3.3.10, 4.3.3.11 и 4.3.3.12.
Рис. 4.3.3.10 Формат поля управления информационных кадров
N(S) - номер кадра, посылаемого отправителем (cм. также описание форматов для протокола X.25).
Рис. 4.3.5.11 Формат поля управления управляющих кадров
s - разряды кода управляющей функции;
Рис. 4.3.3.12 Формат поля управления ненумерованных кадров m - бит модификатора функции (см. таблицу 4.3.1.2). Мультиплексирование на уровне 2 осуществляется за счет использования отдельного адреса для каждого LAP (link access procedure) в системе. Адрес содержит два байта и определяет приемник командного кадра и адрес передатчика кадра-отклика. SAPI используется для идентификации типа услуг. Если наряду с цифровым телефоном используется обмен данными, то эти два терминала будут подключены к разным типам сервиса и, вообще говоря, к разным сетям. Для каждого вида услуг фиксируется определенный код SAPI. TEI (terminal endpoint identifier) обычно имеет определенное значение для каждого из терминалов пользователя. Комбинация SAPI и TEI однозначно описывает LAP (link access procedure) и определяет адрес второго уровня. Так как в системе не может быть двух идентичных TEI, коды TEI распределяются следующим образом:
TEIс кодом в диапазоне 0-63 не нуждаются в диалоге с сетью в процессе установления связи на уровне 2. Но пользователь должен следить сам, чтобы в системе не было двух TEI с идентичными кодами. Терминалы с TEI в диапазоне 64-126 должны договариваться с сетью о TEI при установлении связи на уровне 2. Широковещательный TEI=127 служит для обращения ко всем терминалам, имеющим тот же код SAPI. Прежде чем предложить услуги уровню 3 уровень 2 должен запустить LAP. Это производится путем обмена пакетами между драйвером терминала уровня 2 и соответствующим сетевым драйвером. Предварительно должен быть активирован интерфейс уровня 1. До установления LAP возможен обмен только ненумерованными кадрами. Этот процесс включает в себя передачу команды SET asynchronous balanced mode extended(SABME), адресат при этом должен откликнуться посылкой ненумерованного отклика (UA - unnumbered acknowledgment). После установления канала уровень 2 может передавать информацию для уровня 3. Ниже (рис. 4.3.3.13) приведена последовательность обмена кадрами на уровне 2:
Рис. 4.3.3.13 Последовательность обмена кадрами на уровне 2 Получение каждого информационного кадра (Iframe) должно быть в конце концов подтверждено (прислан пакет RR; см. таблицу 4.3.3.1). Число Iframe, которое может быть послано, не дожидаясь подтверждения получения (размер окна), может лежать в пределах 1-127. В случае телефонии это число равно 1. Если ресурс окна исчерпан, партнер вынужден задержать отправку очередного пакета до подтверждения получения посланного ранее кадра (RR). Для выявления потери кадров используется таймер. Таймер запускается всякий раз при посылке командного кадра и останавливается при получении подтверждения. Этого таймера достаточно, чтобы проконтролировать доставку, как команды, так и отклика. Если произошел таймаут, нельзя определить, какой из этих двух кадров потерян. Кадр, поврежденный на уровне 1, будет принят с неверной FCS (frame check sequence) и по истечении времени, заданного таймером, будет произведена посылка командного кадра с битом poll=1. Партнер при этом вынужден прислать значение системной переменной, характеризующей ситуацию. По этой переменной можно судить, был ли получен исходный кадр. Таким образом, можно идентифицировать факт потери информационного кадра (нужна ретрансмиссия) или отклика на него. После трех ретрансмиссий считается, что канал разорван, и предпринимается попытка его восстановить. FCS получается путем деления последовательности бит, начиная с адреса и кончая (но не включая) началом fcs, на образующий полином x16+x12+x5+1. Практически это делается с использованием сдвигового регистра, который в исходном состоянии устанавливается в единичное состояние. В конечном результате в регистре оказывается код остатка от деления. Дополнение по модулю 1 этого остатка и есть FCS.
Рис. 4.3.3.14 Схема вычисления контрольной суммы (FCS/CRC) Другой возможной ошибкой является получение I-кадра с неверным номером N(S). Это возможно, когда LAP работает при ширине окна более 1. Если потерян кадр с номером N(s)=k, принимающая сторона не должна посылать подтверждение приема кадра k+1. Отклик при этом имеет тип REJ (см. таблица 4.3.3.1) с N(R)=k+1. Это укажет передающей стороне, что все кадры до k получены, но необходимо возобновить передачу, начиная с кадра k. При выявлении ошибки в N(R) связь прерывается, реинициализируются переменные состояния передающей и принимающей сторон, после чего канал восстанавливается, и обмен возобновляется с самого начала. Таблица 4.3.3.1. (См. также раздел о протоколе X.25)
Ниже на рис. 4.3.3.15 показана схема алгоритма восстановления после потери кадра RR.
Рис. 4.3.3.15 Восстановление системы после потери кадра RR Сигнал RNR(получатель не готов) используется для запрета пересылки пакетов партнеру на уровне 2 и может использоваться при реализации приоритетных услуг. Другим пакетом, который специфицирован на уровне 2, является кадр frame reject (FRMR). Этот кадр может быть получен объектом второго уровня, но не может быть послан. При получении этого кадра система сбрасывается в исходное состояние. После завершения процедуры обмена разрыв канала производится путем посылки кадров DISC (disconnect) и отклика UA (unnumbered acknowledgment), с этого момента обмен кадрами I-типа не возможен. Кадр DM(disconnect mode) может выполнять те же функции, что и UA. Он используется в качестве отклика на SABME, если слой 2 не может установить связь, или отклика на disc, если связь уже разорвана. Для управления и контроля за выделяемыми идентификаторами TEI предназначен специальный драйвер, который имеет возможность выделять и удалять используемые TEI. Все сообщения, связанные с TEI, передаются с помощью пакетов SAPI (service access point identifier). Так как работа с TEI должна выполняться вне зависимости от состояния уровня 2, все TEI-сообщения являются ненумерованными (UI) и не требуют отклика. Надежность достигается путем многократной пересылки пакетов. Пока терминалу не присвоен TEI (terminal endpoint identifier), используется широковещательный метод обмена. Все терминалы пользователя должны воспринимать любые управляющие кадры. Кадры управления в процессе присвоения TEI терминалу рассылаются широковещательно. Схема присвоения TEI и установления связи показана ниже на рис. 4.3.3.16:
Рис. 4.3.3.16 Алгоритм выделения TEI и формирования связи Третий уровень X.25 служит для доставки управляющих сообщений даже в случае отказа сети, именно здесь выполняется реконфигурация маршрута, если это необходимо. Сигнальный пакет 3-го уровня имеет формат (рис. 4.3.3.17):
Рис. 4.3.3.17 Формат сигнального пакета уровня 3 Эти пакеты следуют от терминала к коммутатору и наоборот. Первый октет (поле протокольный дискриминатор) дает D-каналу в будущем возможность поддержки нескольких протоколов. Приведенный код соответствует стандартному управляющему запросу пользователя. Третий октет (поле код запроса - call reference value) используется для идентификации запроса вне зависимости от типа коммуникационного канала, где этот запрос может быть реализован. Четвертый байт характеризует назначение пакета (например, Setup - запрос установления канала). Возможные типы сообщений перечислены в таблице 4.3.3.2. Длина сообщения зависит от его типа. Стандарт не регламентирует содержания полей, следующих за полем тип сообщения, и они могут использоваться по усмотрению пользователя для расширения функциональных возможностей системы. Таблица 4.3.3.2 Коды типов сообщений
* Цифрами в верхней части таблицы пронумерованы биты кодов В приведенной ниже таблице 4.3.3.3 представлены информационные элементы, которые могут содержаться в сообщениях Setup (это самый сложный тип сообщений). Таблица 4.3.3.3. Поля setup-сообщений
Сигнальная система ISDN позволяет пользователю уже на фазе формирования канала с помощью запроса setup сформулировать требования к каналу, задав значение BC (bearer capability, см. таблицу 4.3.3.3), а также HLC (high layer compatibility) и LLC (low layer compatibility), характеризуя необходимый вид услуг. При этом проверяется совместимость запрашиваемых скоростей и имеющихся в распоряжении возможностей. HLC определяет тип сервиса или оборудования (телефон, факс группы 3 или 4, видеотекст), а LLC - быстродействие терминала пользователя, механизм адаптации к скорости передачи данных, контроль четности, синхронный/асинхронный интерфейс и т.д.). BC может принимать значения (например, "BC=speech"):
Услуги типа speech или 3.1 khz audio возможны и через общественную коммутируемую телефонную сеть (PSTN), остальные из перечисленных требуют 64-килобитного цифрового канала. Схема формирования запроса, получения доступа к определенному виду услуг показана ниже на рисунке 4.3.3.18. Помимо названных услуг существуют и другие, например, видео-телефония, видеоконференции и пр., список этот постоянно расширяется. При реализации 7кГц-телефонии должны быть выполнены следующие требования:
Видео телефония использует один или два B-канала. В Европе приняты следующие нормы (normes europeennes de telecommunication-net):
Рис. 4.3.3.18 Последовательность сообщений при реализации стандартного вызова Вызываемый партнер получает setup-сообщение через широковещательное обращение. Все терминалы, соединенные с NT1 могут анализировать Setup-сообщение с тем, чтобы определить, соответствуют ли они вызывающей стороне. Соответствие определяется по возможностям канала и по совместимости информационных элементов нижнего уровня. Если терминал соответствует требованиям запроса, он посылает сети сообщение alerting (Оповещение). В то же время, если необходимо, терминал должен сформировать локальный сигнал вызова (напр. звонок). После получения всей необходимой информации сеть выдает сообщение call proceeding, которое указывает на то, что начата установка связи с объектом вызова. Когда терминал обнаружил, что на запрос получен отклик, он переадресует connect-сообщение сети. Сеть регистрирует запрос и выдает команду терминалу соединиться с соответствующим B-каналом, послав пакет connect acknowledge, содержащий код B-канала. В любой момент времени к В-каналу может иметь доступ только один терминал. Все остальные терминалы, которые откликнулись на запрос, получат от сети сообщение release, которое переводит их в пассивное состояние. Пользователь может отменить запрос в любое время, послав три сообщения: disconnet, release и release complete (см. рис. 4.3.3.19 и таблица 4.3.3.2).
Рис. 4.3.3.19 Обмен сообщениями при разрыве связи Возможна временная пассивация терминала посредством сообщения suspend с последующим возобновлением прерванного режима с помощью сообщения resume. Каждое из этих сообщений требует подтверждения получения (suspend acknowledge и resume acknowledge, соответственно). При вызове может оказаться несколько терминалов, отвечающих запрашиваемым требованиям (например, телефонных аппаратов). Вызывающая сторона может выбрать один из них (зная, например, их положение). Существует два механизма обращения к заданному терминалу. Первый использует вспомогательную службу direct dialling-in (DDI), которая в случае реализации обычного доступа к ISDN называется multiple subscriber number (MSN). В DDI и MSN номер сети используется для целей маршрутизации в пределах локальной сети пользователя. Каждому терминалу в сети должен быть присвоен уникальный MSN-номер. Именно этот номер используется для идентификации при Setup-процедуре. Второй механизм адресации к заданному терминалу базируется на субадресации (subaddressing - SUB). В этом варианте дополнительная адресная информация передается от источника запроса к адресату. Этот адрес не является частью ISDN-номера, который используется для целей маршрутизации. Этот адрес может быть применен для обращения к некоторому процессу внутри терминала (не следует забывать, терминалом может быть ЭВМ) или к приложениям, которые не следуют стандартам OSI. Каждый терминал, подсоединенный к пассивной шине, нуждается в присвоении ему субадреса. Принципиальное различие между DDI/MSN и SUB методами адресации заключается в том, что для DDI/MSN адрес является частью ISDN номера, в то время как для SUB это не так. В этом случае каждому терминалу, подключенному к пассивной шине, должен быть присвоен такой субадрес. Процедура Setup должна содержать информацию о субадресе. Для выбора типа услуг и проверки терминальных возможностей используется обмен сообщениями alerting-connect. Для максимального удовлетворения запросов потребителей isdn должна поддерживать самые разные дополнительные виды услуг. Чтобы решить эти задачи на уровне 3 для интерфейса пользователь-сеть разработаны два протокола - функциональная и стимулирующая сигнальные процедуры. В случае стимулирующей сигнальной процедуры терминал не должен иметь какой-либо информации о вспомогательных видах услуг. Работа терминала контролируется сетью с помощью сигнальных сообщений уровня 3. Сеть и терминал работают по схеме клиент-сервер и от терминала не требуется особых аналитических способностей. Базовый формат управляющих сообщений соответствует типу information. Существуют две разновидности этого протокола: один использует управляющие последовательности символов, заключенные между * и #, для второго - сеть должна хранить специальный профайл для каждого терминала. Такой профайл может переопределять функцию некоторых клавиш терминала. Нажатие такой клавиши осуществляет вызов определенного вида услуг. В случае функциональной сигнальной процедуры терминал должен знать все о вспомогательном виде услуг и хранить всю необходимую информацию о них. Функциональный протокол использует информационные элементы facility (возможность, см. таблицу 4.3.5.4). Для пересылки этих информационных элементов используются сообщения типа register (см. описание протокола X.25). Функциональный протокол базируется на протоколе ROSE (remote operations service element). Этот протокол служит для поддержки приложений, где необходим интерактивный контроль сетевых объектов. Протокол ROSE обеспечивает запуск процесса, поддерживает процедуры подтверждения и последующее управление процессом. В таблице 4.3.5.4 приведен перечень дополнительных услуг, предоставляемых ISDN и поддерживаемых функциональным протоколом. Таблица 4.3.5.4. Дополнительные услуги сети ISDN
Реально это лишь ядро списка, разные сети могут предоставлять и многие другие услуги. При установлении телефонного канала используется сообщение TUP (telephony user part). В ISDN определены также сообщения ISUP (integrated services user part), которые должны стать основой всех будущих разработок. Примерами ISUP могут служить следующие сообщения:
В ISDN используются базовая (B-канал, 64 Кбит/с) и первичная (1,544/2,048 Мбит/с) скорости передачи информации. Сигнальный D-канал формируется на основе 24-го временного домена (timeslot) в случае 1,544 Мбит/с и 16-го для 2,048 Мбит/с. Характеристики первичных каналов ISDN приведены в таблице 4.3.3.5. Таблица 4.3.3.5. Характеристики первичных каналов ISDN
Различие между базовой и первичной скоростями обмена заключается в следующем. Для первичной скорости не предусматривается интерфейс многоточечного обмена в локальной сети пользователя; связь устанавливается между сетью и одним из PABX (public automatic branch exchange) или другим терминалом. В случае первичной скорости отсутствуют какие-либо средства для деактивации связи с целью экономии энергии. Для пользователя желательно иметь доступ, как к базовым, так и первичным каналам Для базовой скорости передачи работает сигнальная цифровая система доступа DASS (digital access signaling system). Формат кадра при этом имеет вид (DASS2/DPNSS - digital private network signaling system):
Рис. 4.3.3.20 DASS2/DPNSS-кадр уровня 2 Этот формат не отличается от общепринятого для уровня 2 ISDN, за исключением числа байт управления (см. рис. 4.3.3.20 и 4.3.3.7), что допускается регламентирующими документами. Использование местной ISDN-АТС открывает дополнительные возможности. Помимо высококачественной локальной связи появляются коллективные (групповые) номера, что снимает ограничение на число пользователей, подключенных к узлу через обычные аналоговые модемы. Все пользовательские модемы дозваниваются по одному и тому же номеру, а коммутатор выполняет функцию пакетного мультиплексора. Емкость таких АТС легко наращивается, отдельные АТС могут объединяться друг с другом. Схема взаимодействия такой АТС (PTNX) с терминальным пользовательским оборудованием, другими ptnx и основной сетью ISDN показана на рис. 4.3.3.21. Местная АТС может предоставлять те же услуги, что и традиционная сеть ISDN, плюс запрограммированные локально виды сервиса (диалог между пользователями локальной сети, услуга типа "не беспокоить" и т.д.).
Рис. 4.3.3.21 Связи местной ISDN-АТС Взаимодействие между ISDN и PSPDN регулируется стандартом ccitt x.31 (и i.462). x.31 позволяет использовать ISDN с существующими сетями x.25. Схема взаимодействия периферийного оборудования, ISDN и PSPDN показана на рисунке 4.3.3.22 (ISDN-коммутатор может и отсутствовать).
Рис. 4.3.3.22 Схема взаимодействия сетей ISDN и X.25 TA - терминальный адаптер; TE - терминальное оборудование; NT - сетевое терминальное оборудование Доступ к программам обработки пакетов возможен через B- или D-каналы. В зависимости от вида приложения доступ через D-канал иметь определенные преимущества. D-канал в отличии от B-канала принципиально не может быть заблокирован. Возможна работа одновременно с 8-ю терминалами, подключенными к пассивной ISDN-шине. Кроме того, работа с D-каналом оставляет B-канал свободным для задач, которые не решаемы через D из-за его малого быстродействия (16 Кбит/с). А согласно рекомендациям LAPD быстродействие D-канала не может быть увеличено (по этой же причине максимальная длина пакетов X.25 в данной схеме не может превышать 260 октетов (против 1024 для обычных каналов X.25). К недостаткам использования D-канала можно отнести возможное увеличение задержек из-за низкого быстродействия. Протокол X.25 был разработан довольно давно для "традиционных" приложений и его недостаточная гибкость (большие задержки откликов, таймауты и пр.) приводит к тому, что он совершенно не пригоден для некоторых новых приложений. Это вынудило разработку для ISDN новых режимов работы с пакетами. И первое что было сделано - это четкое разделение управляющих и информационных потоков. ISDN может рассматриваться как две логически независимые субсети - сигнальную субсеть и коммутируемую информационную сеть (в x.25 информация и управление осуществляется по одним и тем же каналам). В соответствии с этим разделением терминология CCITT различает плоскость управления (C-plane) и пользовательскую информационную плоскость (U-plane, см. рис. 4.3.3.23). В ISDN существует два режима: frame relaying (передача кадров, наиболее простой из режимов) и frame switching (коммутация кадров). Отличительной особенностью режима frame relaying является отсутствие подтверждений получения пакета при обмене данными между ISDN-терминалами (аналог UDP в TCP/IP сетях). Для обоих режимов используется одни и те же сигнальные процедуры (Q.933), но они отличаются протоколами U-плоскости при пересылке информации. Здесь используются протоколы передачи данных, базирующиеся на усовершенствованном стандартном сигнальном протоколе LAPD слоя 2, известном как LAPF - link access procedures for frame mode bearer services (Q.922). Пользователь может установить несколько виртуальных соединений и/или постоянных виртуальных связей одновременно с несколькими адресатами.
Рис. 4.3.3.23 Услуги ISDN в режиме переключения (цифрами помечены уровни протоколов, в скобках приведены ссылки на документы ITU) На сигнальном уровне C-плоскости используются стандартные LAPD-процедуры слоя 2 (Q.921 или I.441), а для слоя 3 спецификация кадрового режима (Q.933). Но на U-плоскости сеть поддерживает только небольшую часть связного протокола:
В простейшем случае сеть посредством сигнальных процедур на фазе Setup формирует вход в маршрутную таблицу. На уровне 2 для каждого виртуального запроса выделяется адрес, который остается действительным только на время данного вызова. При пересылке данных сеть просто индексирует маршрутную таблицу, используя адреса слоя 2 поступающих кадров, и ставит их в очередь на передачу по соответствующему маршруту. На фазе передачи информации терминалы используют протоколы более высокого уровня по схеме точка-точка без привлечения сети. Схема протокола коммутации кадров показана ниже на рис. 4.3.3.24, здесь передача кадров происходит с подтверждением получения (до какой-то степени аналог протокола tcp). Сеть детектирует потери и случаи дублирования пакетов. Здесь на сигнальном уровне все процедуры следуют требованиям связного протокола ISDN в полном объеме в том числе и при передаче данных. Это подразумевает необходимость подтверждения получения каждого информационного кадра, пересылаемого от терминала к терминалу. Cеть контролирует доставку кадров и выявляет ошибки. Как и в предыдущем случае мультиплексирование и демультиплексирование выполняется с использованием адресов слоя 2. Адрес кадра может содержать 2-4 октетов, а информация занимать от 1 до 262 октетов. Последняя величина может быть и увеличена в результате переговоров между отправителем и получателем при формировании виртуального канала. Рекомендуется не использовать кадров с размером поля данных более 1600 октетов во избежании фрагментации и последующей сборки сообщений.
Рис. 4.3.3.24 Режим переключения кадров ITU-T делит все канальные услуги на две категории. 8 типов услуг уже определены для случая коммутации каналов и три определены для коммутации пакетов. Три из восьми считаются определяющими и каждый ISDN-переключатель должен их поддерживать (ITU-T рекомендация I.230). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.3.2 Протоколы сетей X.25
UP:
4.3 Региональные сети
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.3.6 Синхронные каналы SDH/SONET
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Мультиплексирование потоков информации при формировании мощных региональных и межрегиональных каналов имеет два решения. Одно базируется на синхронном мультиплексировании и носит название синхронная цифровая иерархия (SDH, cм. Н.Н.Слепов, Синхронные цифровые сети SDH. ЭКО-ТРЕНДЗ, Москва, 1998), другое использует простой асинхронный пакетный обмен и носит название асинхронный режим передачи (ATM, см. предыдущую главу). Стандарт SDH (synchronous digital hierarchy) разработан в Европе, (предназначен для замены иерархии асинхронных линий E-1/E-3) используется в настоящее время многими сетями и представляет собой модификацию американского стандарта на передачу данных по оптическим каналам связи SONET (synchronous optical network). Несмотря на свое название SONET не ограничивается исключительно оптическими каналами. Спецификация определяет требования для оптического одно- и мультимодового волокна, а также для 75-омного коаксиального кабеля CATV 75. Пропускная способность SONET начинается с 51,84 Мбит/с STS-1 (synchronous transport signal-1). Более высокие скорости передачи информации в sonet кратны этому значению. Стандартизованы следующие скорости передачи, которые кратны скорости 64 Кбит/с.
Соответствие каналов SONET и SDH приведено ниже[W. Simpson RFC-1619 "PPP over SONET/SDH"] (и тот и другой могут использоваться для организации связей по схеме PPP):
sonet (стандарт ANSI, предназначенный для замены NADH - north american digital hierarchy) использует улучшенную PDH - (plesiochronous digital hierarchy - plesios - близкий (греч.)) схему мультиплексирования каналов. В плезиохронной (почти синхронной) иерархии используется мультиплексирование с чередованием бит, а не байт. Мультиплексор формирует из N входных потоков один выходной (сети, где разные часы сфазированы с разными стандартами, но все они привязаны к одной базовой частоте называются плезиохронными). Так как скорости разных каналов могут не совпадать и нет структур, которые могли бы определить позиции битов для каждого из каналов, используется побитовая синхронизация. Здесь мультиплексор сам выравнивает скорости входных потоков путем введения (или изъятия) соответствующего числа бит. Информация о введенных и изъятых битах передается по служебным каналам. Помимо синхронизации на уровне мультиплексора происходит и формирование кадров и мультикадров. Так для канала Т2 (6312кбит/с) длина кадра равна 789 бит при частоте кадров 8 кГц. Мультикадр содержит 12 кадров. Помимо европейской и американской иерархии каналов существует также японская. Каждая из этих иерархий имеет несколько уровней. Сравнение этих иерархий представлено в таблице 4.3.6.1. Таблица 4.3.6.1. Сравнение европейской и американской иерархии каналов
Но добавление выравнивающих бит в PDH делает затруднительным идентификацию и вывод потоков 64 Кбит/с или 2 Мбит/с, замешанных в потоке 140 Мбит/с, без полного демультиплексирования и удаления выравнивающих бит. Если для цифровой телефонии PDH достаточно эффективна, то для передачи данных она оказалась недостаточно гибкой. Именно это обстоятельство определило преимущество систем SONET/SDH. Эти виды иерархических систем позволяют оперировать потоками без необходимости сборки/разборки. Структура кадров позволяет выполнять не только маршрутизацию, но и осуществлять управление сетями любой топологии. Здесь использован чисто синхронный принцип передачи и побайтовое, а не побитовое чередование при мультиплексировании. Первичной скоростью SONET выбрана 50688 Мбит/с (ОС1). Число уровней иерархии значительно расширено (до 48). Кратность уровней иерархии равна номеру уровня. CCITT выработал следующие рекомендации на эту тему: G.707, G.708 и G.709. CCITT разработал рекомендации для высокоскоростных каналов H:
На нижних уровнях SDH и SONET в некоторых деталях различаются. Внедрение стандарта SONET ликвидировало многие недостатки каналов T-1 (ограничения на размер максимальной полезной нагрузки, простота стыковки скоростных каналов связи). SONET хорошо согласуется с ATM и FDDI, что создает фундаментальный базис для широкополосных сетей ISDN (B-ISDN). Следует учитывать, что SONET сохраняет совместимость с уже существующими каналами, убирая лишь некоторые присущие им недостатки. Одним из базовых каналов сегодня является T-1 (1544 Кбит/с для США). Он содержит в себе 24 субканалов DS-0 (digital signal at zero level, 64 Кбит/с, США). Мультиплексирование 24 каналов DS-0 по времени формирует канал DS-1 (24 канала*64 Кбит/с)+8 Кбит/с=1544 Кбит/с, последнее слагаемое связано с заголовками информационных блоков). Этой величине соответствует в Европе 2048 Кбит/с (канал E-1 = 30*ds0). Два канала T-1 образуют канал T-1c, четыре канала T-1 формируют канал T-2, а семь T-2 (28 T-1) образуют T-3. Для оптических систем связи в качестве базового принят канал OC-1, равный по пропускной способности T-3. А кадр STS-1 выбран в качестве основного в системе SONET. Кадр STS-1 имеет 9 строк и 90 столбцов (810 байт). Кадры передаются с частотой 8 кГц, что дает для канала STS-1 51840 Кбит/с = 8000Гц*810байт*8бит. Эта цифра характеризует физическую скорость обмена, включающую в себя передачу служебной информации (заголовков), эффективная информационная пропускная способность равна 50112 Кбит/с. Быстродействие каналов более высокого уровня SONET получается умножением пропускной способности STS-1 (51,84 Мбит/с) на целое число. Так пропускная способность OC-3 будет равна 155,52 Мбит/с, а OC-24 - 1244,16 Мбит/с и т.д. Целью создателей SONET было прямая стыковка оптических каналов различных сервис-провайдеров (вспомним, что непосредственное соединение каналов T-1 и E-1 не возможно). SDH допускает сцепление нескольких контейнеров (в том числе и разных размеров), если в один контейнер данные не помещаются. Допускается объединение нескольких контейнеров равного размера в один большой. Хотя относительный размер заголовка виртуального контейнера невелик (~3,33%), его объем достаточен для передачи достаточно больших объемов служебной информации (до 5,184 Мбит/c). В SONET предусмотрено четыре варианта соединений: точка-точка, линейная цепочка (add-drop), простое кольцо и сцепленное кольцо (interlocking ring). Линейные варианты используются для ответвлений от основного кольца сети.
Наиболее распространенная топология - самовосстанавливающееся кольцо (см. также
FDDI). Такое кольцо состоит из ряда узлов, которые связаны между собой двухсторонними линиями связи, образующими кольцо и обеспечивающими передачу сообщений по и против часовой стрелки. Способность сетей SONET к самовосстановлению определяется не только топологией, но и средствами управления и контроля состояния. При повреждении трафик перенаправляется в обход, локально это приводит к возрастанию информационного потока, по этой причине для самовосстановления сеть должна иметь резерв пропускной способности (как минимум двойной). Но, проектируя сеть, нужно избегать схем, при которых основной и резервный маршрут проходят через одну и ту же точку, так как они могут быть, если не повезет, повреждены одновременно. Резервные пути могут использоваться для низкоприоритетных обменов, которые могут быть заблокированы при самовосстановлении.
Существующие PDH-сети мультиплексируют каналы, используя каскадную схему, показанную на рис. 4.3.6.1.
Рис. 4.3.6.1. pdh-мультиплесирование SDH-иерархия распространяется до 2500 Мбит/с и может быть расширена вплоть до 13 Гбит/с (ограничение оптического кабеля). SDH предоставляет существенно улучшенную схему мультиплексирования каналов для быстродействующих интерфейсов с полосой 150 Мбит/с и выше:
При передаче по сети SDH информация вкладывается в специальные структуры, называемые виртуальными контейнерами (VC). Эти контейнеры состоят из двух частей:
Описано несколько типов виртуальных контейнеров для использования в различных каналах. Таблица 4.3.6.2. Виды виртуальных контейнеров
В схеме мультиплексирования применены следующие обозначения:
Контейнеры С-n используются для инкапсуляции сигналов каналов доступа или трибов, при этом уровни n соответствуют уровням PDH. Контейнер С-1 может нести в себе контейнер С-11, который содержит триб Т1=1,54 Мбит/с, и контейнер С-12, несущий триб Е1=2 Мбит/с. Контейнер С-2 разбивается на контейнер С-21, содержащий триб Т2=6 Мбит/с и контейнер С-22 с трибом Е2=8Мбит/с. Контейнер С-3 разбивается на контейнер С-31 (триб Е3=34 Мбит/с) и контейнер С-32 с трибом Т3=45Мбит/с. С-4 не имеет подуровней и несет в себе триб Е4=140 Мбит/с. Виртуальный контейнер VC-3 делится на два виртуальных контейнера VC-31 и VC-32, полезная нагрузка VC-3 образуется из одного контейнера С-3 или с помощью мультиплексирования нескольких групп TUG-2. Виртуальный контейнер VC-4 с полезной нагрузкой в виде контейнера С-4 или путем мультиплексирования нескольких групп TUG-2 и TUG-3. Административный блок AU-3 разбивается на подуровни AU-31 и AU-32, поле данных которых формируется из виртуального контейнера VC-31 или VC-32 соответственно. Административный блок AU-4 не имеет подуровней, его поле данных формируется из виртуального контейнера VC-4 или комбинаций других блоков: 4*VC-31 или 3*VC-32 или 21*TUG-21 или 16*TUG-22.
Рис. 4.3.6.2 Иерархия мультиплексирования SDH На рис. 4.3.6.2 отображена иерархия мультиплексирования потоков информации в SDH. На рисунке не показана возможность вложения контейнера VC-11 в TU-12. SDH-сигнал состоит из STM-1 кадров (synchronous transport module уровень 1; рис. 4.3.6.3). Этот сигнал обеспечивает интерфейс для обмена со скоростью 155.52 Мбит/c, что является базовым блоком, из которого строятся интерфейсы с более высоким быстродействием. Для более высоких скоростей может быть использовано n STM-1 кадров с перекрытием байтов (byte interleave, см. рис. 4.3.6.6). Согласно требованиям CCITT n может принимать значения 1, 4 и 16, предоставляя интерфейс для каналов с полосой 155.52, 622.08 и 2488 Мбит/с. Каждый STM-1 кадр содержит 2430 байтов, передаваемых каждые 125 мксек. Для удобства такой кадр можно отобразить в виде блока, содержащего 9 строк по 270 байт.
Рис. 4.3.6.3 Структура кадра STM-1 Первые 9 колонок кадра, исключая строку 4, используются в качестве заголовка. Регенераторная часть служит для передачи сигнала между линейным оборудованием и несет в себе флаги разграничения кадров, средства для обнаружения ошибок и управления телекоммуникационным каналом. Мультиплексорный заголовок используется мультиплексорами, обеспечивая детектирование ошибок и информационный канал с пропускной способностью 576 Кбит/с. AU (administrative units) - предлагает механизм эффективной транспортировки информации STM-1. Административный блок перераспределяет информацию внутри виртуального контейнера. Начало виртуального контейнера индицируется указателем au, в котором содержится номер байта, с которого начинается контейнер. Таким образом, начала STM-1 и VC не обязательно совпадают.
Рис. 4.3.6.5. VC-4, плавающий в AU-4 VC-4 (см. рис. 4.3.6.5) позволяет реализовать каналы с быстродействием 139.264 Кбит/с. Более высокая скорость обмена может быть достигнута путем соединения нескольких VC-4 вместе. Для более низких скоростей (около 50 Мбит/с) предлагается структура AU-3. Три VC-3 помещаются в один кадр STM-1, каждый со своим au-указателем. Когда три VC-3 мультиплексируются в один STM-1, их байты чередуются, то есть за байтом первого VC-3 следует байт второго vc-3, а затем третьего. Чередование байтов (byte interleaving) используется для минимизации задержек при буферизации. Каждый VC-3 имеет свой AU-указатель, что позволяет им произвольно размещаться в пределах кадра STM-1.
Рис. 4.3.6.6. Три VC-3 в STM-1 кадре Каждому VC-3 при занесении в STM-1 добавляется 2 колонки заполнителей, которые размещаются между 29 и 30, а также между 57 и 58-ой колонками контейнера VC-3. VC, соответствующие низким скоростям, сначала вкладываются в структуры, называемые TU (tributary units - вложенные блоки), и лишь затем в более крупные - VC-3 или VC-4. TU-указатели позволяют VC низкого уровня размещаться независимо друг от друга и от VC высокого уровня. VC-4 может нести в себе три VC-3 непосредственно, используя TU-3 структуры, аналогичные AU-3. Однако транспортировка VC-1 и VC-2 внутри vc-3 несколько сложнее. Необходим дополнительный шаг для облегчения процесса мультиплексирования VC-1 и VC-2 в структуры более высокого уровня (см. рис. 4.3.6.7).
Рис. 4.3.6.7. Транспортировка VC при низких скоростях с использованием TU-структур Так как VC-1 и VC-2 оформляются как TU, они вкладываются в TUG (Tributary Unit Group). TUG-2 имеет 9 рядов и 12 колонок, куда укладывается 4 VC-11, 3 VC-12 или один VC-2. Каждый TUG-2 может содержать VC только одного типа. Но TUG-2, содержащие различные VC, могут быть перемешаны произвольным образом. Фиксированный размер TUG-2 ликвидирует различия между размерами VC-1 и VC-2, упрощая мультиплексирование виртуальных контейнеров различных типов и их размещение в контейнерах более высокого уровня. Данная схема мультиплексирования требует более простого и дешевого оборудования для осуществления мультиплексирования, чем PDH. Если в SDH управление осуществляется на скоростях в несколько килобайт, в ATM оно реализуется на скорости канала, что влечет за собой определенные издержки. Для управления SDH/SONET используется протокол SNMP (см. RFC-1595, "Definitions of Managed Objects for the SONET/SDH Interface Type") и база данных MIB. Архитектура сети, базирующейся на SDH, может иметь кольцевую структуру или схему точка-точка. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.3.5 Протоколы сетей ATM
UP:
4.3 Региональные сети
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
4.3 Региональные сети
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||
Региональные сети (WAN - Wide Area Network) с точки зрения архитектуры и протоколов практически не отличаются от глобальных. В региональных сетях обычно не используются трансокеанские кабели, но это отличие не может рассматриваться как принципиальное. Региональные сети решают проблему формирования из LAN (локальных сетей) сетей регионов и целых стран и даже наднациональных сетей (например, E-BONE для Европы). Как правило, эти сети строятся с использованием протоколов SDH, ATM, ISDN, Frame Relay или X.25. Архитектурно такие сети формируются из каналов со схемой точка-точка и мощных коммутаторов-мультиплексоров. Из таких фрагментов формируются и опорные сети (BackBone), которые позволяют сократить число шагов от узла к узлу. В этих сетях в основном используются оптоволоконные транспортные системы, а там где это нерентабельно, спутниковые или радиорелейные каналы. С появлением корпоративных сетей типа Интранет понятия локальной и региональной сетей стало частично перекрываться. Для пользователя Интранет все узлы такой сети являются локальными, хотя и могут отстоять на сотни или даже тысячи километров друг от друга. По существу сети Интранет являются наложенными сетями по отношению к региональным сетям (WAN). Интернет также следует отнести к числу наложенных сетей по отношению к WAN. |
||||||||||||||||||||||||||||||||||||
|
Previous:
4.2.3 NetBIOS
UP:
4.2.1 Протоколы Novell (IPX/SPX)
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.3.7 Модемы
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Само название этого прибора происходит от имеющихся в нем модулятора и демодулятора. Современный модем можно отнести к числу устройств с наибольшим числом современных технологий на кубический сантиметр. Разнообразие модемов огромно. Они различаются по конструкции, по используемым протоколам, по характеру интерфейсов и т.д. Основное назначение модема оптимальное преобразование цифрового сигнала в аналоговый для передачи его по каналу связи и, соответственно, обратное преобразование на принимающей стороне. Под "оптимальным преобразованием" понимается такое, которое обеспечивает надежность связи, улучшает отношение сигнал шум и как следствие пропускную способность канала. Это преобразование необходимо для обеспечения улучшения отношения сигнал-шум. В качестве канала передачи данных может быть использована городская телефонная сеть, выделенная линия или радио-канал. Схема взаимодействия модемов показана на рис. 4.3.7.1.
Рис. 4.3.7.1. Схема соединения двух модемов (М1 и М2) через канал В качестве последовательного интерфейса может выступать RS-232, V.35, G.703 и т.д.. Все модемы содержат в себе управляющий микропроцессор, постоянную память (ROM), куда записано фирменное программное обеспечение и интерпретатор команд, энергонезависимую память (NVRAM - non-volatile RAM), которая хранит конфигурационные профайлы модема, телефонные номера и т.д., буфер ввода/вывода (128-256 байт), сигнальный процессор (DSP), включающий в себя модулятор и демодулятор, интерфейс для связи с ЭВМ (RS-232) и оперативную память. Первоначально модемы использовались для связи через традиционные коммутируемые телефонные линии. Так как такие линии содержат только два провода, а информационный обмен должен происходить в обоих направлениях одновременно, возникает проблема отделения передаваемого сигнала от приходящего из вне (подавление эхо; см. раздел 2.1). Для выделенных четырехпроводных линий эта проблема значительно упрощается, здесь прием и передача осуществляется по разным скрученным парам и эхо возникает лишь из-за перекрестных наводок (NEXT). Модемы подключаются к последовательным интерфейсам ЭВМ (COM-порт, RS-232), иногда для подключения модема используется специальная плата расширения, которая имеет дополнительные буферы и помогает достичь большего сжатия информации, существуют модемы, подключаемые и к параллельному порту ЭВМ. Модемы (микромодемы) могут работать не только через общедоступную телефонную сеть, они могут найти применение при соединении терминалов или ЭВМ в пределах организации, если расстояние между ними исчисляются сотнями метров (а иногда и километрами). В этом случае они помогают повысить надежность связи и исключить влияние разностей потенциалов между земляными шинами соединяемого оборудования. Микромодемы не требуют подключения к сети переменного тока, так как получают питание через разъем последовательного интерфейса (RS-232). Все протоколы модемов утверждаются международным телекоммуникационным союзом (ITU), ранее за это был ответственен Консультативный комитет CCITT. Асинхронные модемы поддерживают определенный набор команд, который был впервые применен фирмой hayes в модеме smartmodem 1200. Модемы, придерживающиеся этого стандарта, называются Hayes-совместимыми. Совместимость предполагает идентичность функций первых 28 управляющих регистров модема (всего модем может иметь более сотни регистров). Почти все внутренние команды начинаются с символов AT (attention) и имеют по три символа. По этой причине их иногда называют AT-командами. Hayes-совместимость гарантирует, что данный модем будет работать со стандартными терминальными программами. Реально набор команд для модемов разных производителей варьируется в широких пределах. Для синхронных модемов набор команд регламентируется стандартом V.25bis. Ниже (таблица 4.3.7.1) приводится перечень стандартных модемных протоколов и стандартов. Таблица 4.3.7.1. Основные протоколы модемов
Начиная с модемов V.32bis, стала использоваться динамическая регулировка скорости в ходе телекоммуникационной сессии в зависимости от состояния линии связи. Качество линии отслеживается по отношению сигнал/шум или по проценту блоков, переданных с ошибкой за определенный период времени. Важным свойством модемов является возможность коррекции ошибок и сжатия информации. Ошибки корректируются путем повторной пересылки ошибочных блоков (ARQ - automatic repeat request). Ошибки контролируются с использованием CRC (cyclic redundancy check). Этим целям отвечает стандарт V.42, принятый еще в 1988 году, он включает в себя протокол LAPM (link access procedure for modems) и один из протоколов mnp (microcom networking protocol). В V.42 применен алгоритм сжатия информации Lempel-Ziv. При установлении связи между модемами определяется, какой из протоколов коррекции и сжатия они оба поддерживают. Если это V.42, то они сначала пытаются работать с использованием протокола LAPM. При неудаче (один из модемов не поддерживает V.42) используется протокол MNP. Перечисленные ниже алгоритмы коррекции ошибок и сжатия информации работают только для асинхронных модемов. Для синхронных модемов известен алгоритм сжатия SDS (synchronous data compression) фирмы motorola (коэффициент упаковки ~3.5, что для модемов V.34 может довести скорость обмена до 100кбит/с). Ниже приведена таблица основных протоколов детектирования ошибок и сжатия информации, все протоколы mnp совместимы снизу вверх. При установлении связи между модемами используется наивысший протокол, поддерживаемый с обеих сторон канала. Таблица 4.3.7.2. Протоколы mnp
Рис. 4.3.7.2 Схема подключения модема Модем подключается к ЭВМ (см. рис. 4.3.7.2) через последовательный интерфейс RS-232c (существуют версии модемов, способных работать и с параллельным интерфейсом, который обладает почти в 3 раза большим быстродействием). Ниже в таблице представлена разводка для 9- и 25- контактных разъемов (таблица 4.3.7.3), используемых для последовательных интерфейсов (синхронные модемы используют только 25-контактный разъем). Таблица 4.3.7.3. Разводка стандартных разъемов модема
В персональных ЭВМ может быть 2 или 4 последовательных портов (интерфейсов), которые имеют логические имена COM1-COM4, им соответствуют следующие прерывания и адреса:
К телефонной сети модем подключается с помощью 6-х контактного разъема RJ11 (используется 4 контакта). Модем может находиться в режиме данных (режим по умолчанию) и в командном режиме. Последний используется для реконфигурации модема и подготовки его к работе. Реконфигурация и управление возможны из локальной ЭВМ через последовательный порт, с передней панели модема, или при установленной связи через удаленный модем, если такой режим поддерживается. Переключение в командный режим производится с помощью ESC-последовательности (по умолчанию это три символа "+" с предшествующей и последующей секундной паузой). При использовании большого числа модемов они для удобства обслуживания объединяются в группы (пулы). Модемный пул представляет в себя стандартный каркас, где размещается какое-то количество бескорпусных модемов. На передней панели находится, как правило, только индикация, выходы в телефонную сеть и разъемы последовательного интерфейса подключаются через заднюю панель. Такой пул содержит в себе обычно управляющий процессор. Так как в настоящее время не существует стандартов на организацию модемных пулов, они ориентированы на использование модемов только определенной фирмы. К пулу может подключаться дисплей, который отображает текущее состояние всех модемов. Процессор может контролировать состояние модемов, устанавливать их режим работы, а в некоторых случаях и выполнять функцию маршрутизатора, управляя встроенным многоканальным, последовательным интерфейсом. В последнем случае такой пул подключается непосредственно к локальной сети (например, Ethernet), а не к ЭВМ. Пул позволяет предотвращать "повисание" и отключение телефонных линий, что заметно повышает надежность системы. Некоторые модемы (например, фирмы Penril) имеют независимые узкополосные (~300 бит/с), дополнительные каналы для дистанционного управления. Такие каналы обладают повышенной устойчивостью, что позволяет сохранять целостность системы даже при временных отключеньях электропитания. Таблица 4.3.7.4. Протоколы передачи файлов
Практически все выше перечисленные протоколы устарели.
Передача файлов возможна с использованием терминальной программы, это особенно полезно для удаленных терминалов, не поддерживающих протоколы TCP/IP. Терминальные программы используют один из перечисленных выше протоколов, например, Zmodem. В качестве терминальной программы можно воспользоваться одной из: Term95 (Norton commander 5.0), Bitcom, Teleview, Telix, procomm plus (для DOS и Windows), Mtez, MTE, Zstem-240, Pctalk, Crosstalk (эта и следующие для Windows), Dataline, Hyperaccess. Чтобы обеспечить безопасность и исключить несанкционированный доступ к сети, можно воспользоваться методом "обратного телефонного вызова", некоторые модемы реализуют его аппаратно. Метод предполагает, что после установления связи и проверки авторизации связь прерывается, а входной модем сети производит набор номера клиента, который хранится в памяти, и устанавливает связь повторно. Такая схема исключает передачу входного пароля друзьям или знакомым, так как это становится бессмысленным - модем будет пытаться установить связь по номеру вашего домашнего телефона. Модемы обычно имеют дисплей, который позволяет контролировать работу этого прибора. Модемы разных производителей имеют различные типы дисплеев, ниже приведен список наиболее часто встречающихся индикаторов.
В современных ЭВМ имеется возможность совместить функции модема и факс-аппарата. Для решения этой задачи используются так называемые факс-модемы. Эти приборы работают в полудуплексном режиме. Ниже перечислены протоколы, используемые в этих аппаратах (кроме протоколов передачи данных факс-модемы поддерживают стандарты T.4 и T.30):
Для обеспечения работы факс-модема пригодны программы: Bitfax, Winfax, Quicklink или любая другая, поставляемая вместе с приобретенным вами модемом. Следует иметь в виду, что для пересылки через факс-модем традиционного документа, подготовленного на типографском бланке, написанного от руки и т.д., вам потребуется сканнер. В перспективе факс-технология будет вытеснена электронной почтой, которая эффективнее и, при необходимости, может обеспечить большую безопасность. В настоящее время технология модемов продолжает развиваться, появились и активно внедряются кабельные модемы, много усилий тратится на развитие ADSL (см. http://www.adsl.com/general_tutorial.html (asymmetric digital subscriber line), SDSL (single line digital subscriber line), hdsl (high data rate digital subscriber line), VDSL (very high data rate digital subscriber line) и некоторых других технологий, связанных с передачей мультимедиа данных. (См. XDSL. atg's communications & networking technology guide series. pairgain, copperoptics company; http://www.techguide.com/). Эти технологии предназначены для обеспечения широкополосного канала между провайдером и конечным пользователем (проблема последней мили). [Должен заметить, что миля мера иностранная и российским 1,853 км, если речь идет о телефонных кабелях, не соответствует. Провода у нас другого качества и наша миля как бы длиннее, если судить по искажениям сигнала и шумам]. Здесь используются три метода модуляции (2B1Q, CAP и DMT). ADSL позволяет приспособить обычные телефонные линии для мультимедийных приложений и для высокоскоростной передачи данных (до 6 Мбит/с). Два ADSL-модема, соединенные скрученной парой проводов образуют три информационных канала: скоростной однонаправленный (нисходящий) канал (1,5-6,1 Мбит/с), среднескоростной дуплексный канал (16-640 Кбит/с) и POTS-канал (plain old telephone service). POTS сохраняет работоспособность даже при отказе ADSL. Каждый из этих каналов может мультиплексироваться, образуя каналы меньшего быстродействия. ADSL-модемы могут работать и с ATM-сетями, но следует учитывать их принципиальную асимметричность - передача в одном направлении и в другом имеет разную скорость. Для передачи данных в сети Интернет это не удобно. Но для транспортировки телевизионного сигнала такая схема представляется вполне эффективной. Для провода длиной 5,5 км при диаметре сечения 0,5 мм (стандартные условия для isdn) пропускная способность составляет 1,5 - 2,0 Мбит/с (верхний край полосы пропускания около 1 МГц). При организации дуплексного канала весь частотный диапазон делится пополам и одна из частей используется для передачи данных в одном направлении, другая - в противоположном. Каждый из частотных диапазонов в свою очередь делится на части и для каждой из них используется техника эхо-подавления. Для POTS-канала выделяется 4 кГц в низкочастотной части диапазона. HDSL представляет собой способ передачи потоков T1 или E1 по скрученным парам проводов с использованием улучшенной техники модуляции (для передачи 1,544-2,048 Мбит/с достаточно полосы 80-240 кГц). SDSL представляет собой версию HDSL с одной скрученной парой. Ниже в таблице 4.3.7.5 приведены сравнительные данные для различных систем передачи информации. Таблица 4.3.7.5. Свойства различных систем (модемов) передачи информации.
Верхние значения в третей колонке для ADSL и VDSL соответствуют нисходящему (асимметричный канал) и дуплексному потокам. HDTV - телевидение высокого разрешения.
Рис. 4.3.7.3. Ограничения пропускной способности для разных типов канала DSL представляет собой канал ISDN-BRI (Basic Rate Interface; 2*64 + 16 Кбит/c), совместимый с POTS, ISDN и DDS. На рис. 4.3.7.3 показаны области применимости различных канальных технологий.
Метод модуляции 2B1Q характеризуется четырьмя уровнями амплитудной модуляции (4-PAM; +3, +1, -1 и -3). CAP-модуляция (Carrierless Amplitude and Phase) характеризуется четырьмя уровнями амплитуды и четырьмя фиксированными значениями фазы, что дает в плоскости амплитуда-фаза 16 независимых состояний. DTM-модуляция (Discrete Multi-tone) предполагает использование нескольких смежных, узких частотных диапазонов. На рис. 4.3.7.2 показана схема подключения оборудования ADSL для различных оконечных терминалов.
Рис. 4.3.7.4. Схема подключения оборудования ADSL (IF - ADSL/Ethernet интерфейс) В качестве внешней сети на рис. 4.3.7.4 может использоваться практически любая достаточно быстродействующая среда, например ATM. Выбор того или иного внешнего канала зависит от стоящей задачи. Так файл размером 30 Кбайт (среднего размера электронное сообщение) будет передан через модем V.34 за 8,3 сек, по каналу ISDN - за 1,9 сек, по каналу HDSL - за 0,16 сек, а по каналу VDSL - быстрее 0,04 сек. В большинстве случаев вполне приемлемым можно считать уже первые два варианта. Деловой электронный документ имеет размер порядка 250 Кбайт. Здесь для пересылки его указанными способами потребуется уже, соответственно: 69,4; 15,6; 1,3 и 0,3 секунды. Более чем минутное время доставки (в реальности это обычно больше) в некоторых случаях не будет признано удовлетворительным. Время пересылки рентгенограммы (~5 Мбайт) будет пропорционально больше (23 мин, 5,2 мин, 26 сек и 6,5 сек). Считается, что приемлемым временем отклика на команду следует считать 3 секунды, а до 80% трафика локальной сети составляет внешний поток данных. Если же стоит задача организации видеоконференции (384 Кбит/с), то решение проблемы возможно уже только с использованием каналов xDSL. Учитывая стремительный рост потребной пропускной способности каналов, не трудно предсказать перспективность внедрения технологии xDSL. Пример использования модема ADSL для подключения телевизора и модема к широкополосному каналу представлен на рис. 4.3.7.5. Управляющий канал на 16 кбит/с может использоваться для целей интерактивного телевидения (смотри раздел "Методы преобразования и передачи изображения").
Рис. 4.3.7.5. Схема подключения телевизора и телефона через модем ADSL |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.3.6 Синхронные каналы SDH/SONET
UP:
4.3 Региональные сети
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.1 IP-протокол
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
В Интернет используется много различных типов пакетов, но один из основных - IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP. IP-протокол предлагает ненадежную транспортную среду. Ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтограммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтограмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 4.4.1.1.
Рис. 4.4.1.1. Формат дейтограммы Интернет Поле версия характеризует версию IP-протокола (например, 4 или 6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса слишком тяжелых последствий это не вызовет. Понятно также, что значение поля версия во избежании непредсказуемых последствий должно контролироваться программой. HLEN - длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (HLEN=5, без опций и заполнителя). Поле полная длина определяет полную длину IP-дейтограммы (до 65535 октетов), включая заголовок и данные. Одно-октетное поле тип сервиса (TOS - type of service) характеризует то, как должна обрабатываться дейтограмма. Это поле делится на 6 субполей:
Субполе Приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).
0 Обычный уровень Формат поля TOS определен в документе RFC-1349. Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. Так D=1 требует минимальной задержки, T=1 - высокую пропускную способность, R=1 - высокую надежность, а C=1 - низкую стоимость. TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует запрашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP). В таблице 4.4.1.1 приведены рекомендуемые значения TOS. Табл. 4.4.1.1. Значения TOS для разных протоколов
Только один бит из четырех в TOS может принимать значение 1. Значения по умолчанию равны нулю. Большинство из рекомендаций самоочевидны. Так при telnet наибольшую важность имеет время отклика, а для SNMP (управление сетью) - надежность. До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возрасло. Появилось предложение замены поля TOS на поле DSCP (Differenciated Services Code Point), которое также имеет 8 бит (см. RFC-2474). Смотри рис. 4.4.1.1a. Биты CU пока не определены. Иногда это поле называется байтом DS (Differenttiated Services).
Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000.
На базе DSCP разработана технология "пошагового поведения" PHB (per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания. Маршрут транспортировки IP-дейтограммы нельзя знать заранее, это связано с поэтапным (по-шаговом) принятием решения о пути каждого пакета. Это свойство маршрутизации обусловлено тем, что IP является протоколом передачи данных без установления соединения. Поля идентификатор, флаги (3 бита) и указатель фрагмента (fragment offset) управляют процессом фрагментации и последующей "сборки" дейтограммы. Идентификатор представляет собой уникальный код дейтограммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтограмм. Бит 0 поля флаги является резервным, бит 1 служит для управления фрагментацией пакетов (0 - фрагментация разрешена; 1 - запрещена), бит 2 определяет, является ли данный фрагмент последним (0 - последний фрагмент; 1 - следует ожидать продолжения). Поле время жизни (TTL - time to live) задает время жизни дейтограммы в секундах, т.е. предельно допустимое время пребывания дейтограммы в системе. При каждой обработке дейтограммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтограмма из системы удаляется. Во многих реализациях TTL измеряется в числе шагов, в этом случае каждый маршрутизатор выполняет операцию TTL=TTL-1. TTL помогает предотвратить зацикливание пакетов. Поле протокол аналогично полю тип в Ethernet-кадре и определяет структуру поля данные (см. табл. 4.4.1.2). Поле контрольная сумма заголовка вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1. Сама контрольная сумма является дополнением по модулю один полученного результата сложения. Обратите внимание, здесь осуществляется контрольное суммирование заголовка, а не всей дейтограммы. Поле опции не обязательно присутствует в каждой дейтограмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных. Если место, занятое опциями, не кратно 4 октетам, используется заполнитель. Структура октета кода опции отражена на рис. 4.4.1.2. Таблица 4.4.1.2. Коды протоколов Интернет
Рис. 4.4.1.2. Формат описания опций Флаг копия равный 1 говорит о том, что опция должна быть скопирована во все фрагменты дейтограммы. При равенстве этого флага 0 опция копируется только в первый фрагмент. Ниже приведены значения разрядов 2-битового поля класс опции:
В таблице, которую вы найдете ниже, приведены значения классов и номеров опций.
* в колонке "длина" - означает - переменная. Наибольший интерес представляют собой опции временные метки и маршрутизация. Опция записать маршрут создает дейтограмму, где зарезервировано место, куда каждый маршрутизатор по дороге должен записать свой IP-адрес (например, утилита traceroute). Формат опции записать маршрут в дейтограмме представлен ниже на рис. 4.4.1.3:
Рис. 4.4.1.3 Формат опций записать маршрут Поле код содержит номер опции (7 в данном случае). Поле длина определяет размер записи для опций, включая первые 3 октета. Указатель отмечает первую свободную позицию в списке IP-адресов (куда можно произвести запись очередного адреса). Интересную возможность представляет опция маршрут отправителя, которая открывает возможность посылать дейтограммы по заданному отправителем маршруту. Это позволяет исследовать различные маршруты, в том числе те, которые недоступны через узловые маршрутизаторы. Существует две формы такой маршрутизации: Свободная маршрутизация и Жесткая маршрутизация. Форматы для этих опций показаны ниже:
Рис. 4.4.1.3а. Формат опций маршрутизации Жесткая маршрутизация означает, что адреса определяют точный маршрут дейтограммы. Проход от одного адреса к другому может включать только одну сеть. Свободная маршрутизация отличается от предшествующей возможностью прохода между двумя адресами списка более чем через одну сеть. Поле длина задает размер списка адресов, а указатель отмечает адрес очередного маршрутизатора на пути дейтограммы. IP-слой имеет маршрутные таблицы, которые просматриваются каждый раз, когда IP получает дейтограмму для отправки. Когда дейтограмма получается от сетевого интерфейса, IP первым делом проверяет, принадлежит ли IP-адрес места назначения к списку локальных адресов, или является широковещательным адресом. Если имеет место один из этих вариантов, дейтограмма передается программному модулю в соответствии с кодом в поле протокола. IP-процессор может быть сконфигурирован как маршрутизатор, в этом случае дейтограмма может быть переадресована в другой узел сети. Маршрутизация на IP-уровне носит пошаговый характер. IP не знает всего пути, он владеет лишь информацией - какому маршрутизатору послать дейтограмму с конкретным адресом места назначения. Просмотр маршрутной таблицы происходит в три этапа:
Для того чтобы посмотреть, как выглядит простая маршрутная таблица, воспользуемся командой netstat -rn (ЭВМ Sun. Флаг -r выводит на экран маршрутную таблицу, а -n отображает IP-адреса в цифровой форме. С целью экономии места таблица в несколько раз сокращена).
Колонка destination - место назначение, Default - отмечает маршрут по умолчанию; Gateway - IP-адреса портов подключения (маршрутизаторов); REFCNT (reference count) - число активных пользователей маршрута; USE - число пакетов, посланных по этому маршруту; interface - условные имена сетевых интерфейсов. Расшифровка поля FLAGS приведено ниже:
Опция временные метки работает также как и опция запись маршрута. Каждый маршрутизатор на пути дейтограммы делает запись в одном из полей дейтограммы (два слова по 32 разряда; смотри раздел 4.4.15). Формат этой опции отображен на рисунке 4.4.1.4.
Рис. 4.4.1.4 Формат опции "временные метки" Смысл полей длина и указатель идентичен тому, что сказано о предыдущих опциях. 4-битовое поле переполнение содержит число маршрутизаторов, которые не смогли записать временные метки из-за ограничений выделенного места в дейтограмме. Значения поля флаги задают порядок записи временных меток маршрутизаторами: Таблица 4.4.1.3.
Временные метки должны содержать время в миллисекундах, отсчитанное от начала суток. Взаимодействие других протоколов с IP можно представить из схемы на рис. 4.4.1.5. В основании лежат протоколы, обеспечивающие обмен информацией на физическом уровне, далее следуют протоколы IP, ICMP, ARP, RARP, IGMP и протоколы маршрутизаторов. Чем выше расположен протокол, тем более высокому уровню он соответствует. Протоколы, имена которых записаны в одной и той же строке, соответствуют одному и тому же уровню. Но все разложить аккуратно по слоям невозможно - некоторые протоколы занимают промежуточное положение, что и отражено на схеме, (области таких протоколов захватывают два уровня. Здесь протоколы IP, ICMP и IGMP помещены на один уровень, для чего имеется не мало причин. Но иногда последние два протокола помещают над IP, так как их пакеты вкладываются в IP-дейтограммы. Так что деление протоколов по уровням довольно условно. На самом верху пирамиды находятся прикладные программы, хотя пользователю доступны и более низкие уровни (например, ICMP), что также отражено на приведенном рисунке (4.4.1.5).
Рис. 4.4.1.5. Распределение протоколов Интернет по уровням Интернет - это инструмент общения, средство доступа к информации и как всякий инструмент требует практики. Из вашего собственного опыта вы знаете, что можно прочесть ворох инструкций о том, как забивать гвозди, но научиться этому можно лишь на практике. Поэтому рекомендую с самого начала, читая данные тексты, чаще садитесь за терминал. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4 Интернет
UP:
4.4 Интернет
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.1.1 Адресация IPv6
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: "TCP and UDP with Bigger Addresses (TUBA)"; "Common Architecture for the Internet (CatnIP)" и "Simple Internet Protocol Plus (SIPP) [смотри "Протоколы и ресурсы Интернет" Семенов Ю.А., Радио и связь, М 1995]. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно. Адресное пространство IPv6 будет распределяться IANA(Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (internet architecture board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет). IANA будет делегировать права выдачи IP-адресов региональным сервис-провайдерам, субрегиональным структурам и организациям. Отдельные лица и организации могут получить адреса непосредственно от регионального распределителя или сервис провайдера. Передача адресного пространства от IANA не является необратимым. Если по мнению IANA распорядитель адресного пространства допустил серьезные ошибки, IANA может аннулировать выполненное ранее выделение. IANA в этом случае должна сделать все возможное, чтобы не отзывать адреса, находящиеся в активном использовании, за исключением случаев, когда это диктуется техническими соображениями. Оплата за распределение адресов должна использоваться исключительно на деятельность, непосредственно связанную с выделением адресов, поддержанием соответствующих баз данных и т.д. Адресное пространство само по себе не должно стоить ничего. Следует избегать монополизации и любых злоупотреблений при распределении IP-v6 адресов. IANA разработает план первичного распределения IPv6 адресов, включая автоматическое выделение адресов индивидуальным пользователям. IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:
В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе "scope" (группа адресов). Определен новый тип адреса "anycast address" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее.
Некоторые поля заголовка IPv4 отбрасываются или делаются опционными, уменьшая издержки, связанные с обработкой заголовков пакетов с тем, чтобы уменьшить влияние расширения длины адресов в IPv6.
Изменение кодирования опций IP-заголовков позволяет облегчить переадресацию пакетов, ослабляет ограничения на длину опций, и делает более доступным введение дополнительных опций в будущем.
Введена возможность помечать пакеты, принадлежащие определенным транспортным потокам, для которых отправитель запросил определенную процедуру обработки, например, нестандартный тип TOS (вид услуг) или обработка данных в реальном масштабе времени.
В IPv6 введена спецификация идентификации сетевых объектов или субъектов, для обеспечения целостности данных и при желании защиты частной информации. Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885.
Замечание: допустимо (хотя и необычно), что устройство с несколькими интерфейсами может быть сконфигурировано для переадресации пакетов, приходящих через один или несколько интерфейсов. Пакеты, приходящие через остальные интерфейсы, могут при этом отбрасываться. Такие устройства должны выполнять требования протоколов маршрутизации. При получении пакетов, адресованных этому устройству, оно должно вести себя как обычная ЭВМ.
Рис. 4.4.1.1.1. Формат заголовка пакета IPv6
В документе RFC-2460, который появился спустя три года после RFC-1883, поле приоритет заменено на поле класс трафика . Это поле имеет 8 бит (против 4 в поле приоритет). При этом размер поля метка потока сократился до 20 бит. Это было продиктовано требованиями документа RFC-2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", ориентированного на решение задач управления QoS. 3. IP версия 6 архитектуры адресации Существует три типа адресов:
В IPv6 не существует широковещательных адресов, их функции переданы мультикастинг-адресам. В IPv6, все нули и все единицы являются допустимыми кодами для любых полей, если не оговорено исключение. ipv6 адреса всех типов ассоциируются с интерфейсами, а не узлами. Так как каждый интерфейс принадлежит только одному узлу, уникастный адрес интерфейса может идентифицировать узел. IPv6 уникастный адрес соотносится только с одним интерфейсом. Одному интерфейсу могут соответствовать много IPv6 адресов различного типа (уникастные, эникастные и мультикстные). Существует два исключения из этого правила:
IPv6 соответствует модели IPv4, где субсеть ассоциируется с каналом. Одному каналу могут соответствовать несколько субсетей. 4.1. Представление записи адресов (текстовое представление адресов) Существует три стандартные формы для представления ipv6 адресов в виде текстовых строк:
Примеры: fedc:ba98:7654:3210:FEDC:BA98:7654:3210 Заметьте, что ненужно писать начальные нули в каждом из конкретных полей, но в каждом поле должна быть, по крайней мере, одна цифра (за исключением случая, описанного в пункте 2.).
может быть представлено в виде:
0:0:0:0:0:0:13.1.68.3 или в сжатом виде: ::13.1.68.3 4.2. Представление типа адреса Специфический тип IPv6 адресов идентифицируется лидирующими битами адреса. Поле переменной длины, содержащее эти лидирующие биты, называется префиксом формата (Format Prefix - FP). Исходное назначение этих префиксов следующее (табл. 4.4.1.1.1): Таблица 4.4.1.1.1
Замечание: Не специфицированные адреса, адреса обратной связи и IPv6 адреса со встроенными IPv4 адресами, определены вне "0000 0000" префиксного пространства. Данное распределение адресов поддерживает прямое выделение адресов провайдера, адресов локального применения и мультикастинг-адресов. Зарезервировано место для адресов NSAP, IPX и географических адресов. Оставшаяся часть адресного пространства зарезервирована для будущего использования. Эти адреса могут использоваться для расширения имеющихся возможностей (например, дополнительных адресов провайдеров и т.д.) или новых приложений (например, отдельные локаторы и идентификаторы). Пятнадцать процентов адресного пространства уже распределено. Остальные 85% зарезервированы. Уникастные адреса отличаются от мультикастных значением старшего октета: значение FF (11111111) идентифицирует мультикастинг-адрес; любые другие значения говорят о том, что адрес уникастный. Эникастные (anycast) адреса берутся из уникастного пространства, и синтаксически неотличимы от них. IPv6 уникастный адреса, сходны с традиционными IPv4 адресами при бесклассовой междоменной маршрутизации (Class-less InterDomain Routing - CIDR). Существует несколько форм присвоения уникастных адресов в IPv6, включая глобальный уникастный адрес провайдера (global provider based unicast address), географический уникастный адрес, NSAP адрес, IPX иерархический адрес, Site-local-use адрес, Link-local-use адрес и IPv4-compatible host address. В будущем могут быть определены дополнительные типы адресов. Узлы IPv6 могут иметь существенную или малую информацию о внутренней структуре IPv6 адресов, в зависимости от выполняемой узлом роли, (например, ЭВМ или маршрутизатор). Как минимум, узел может считать, что уникастный адрес (включая его собственный адрес) не имеет никакой внутренней структуры. То есть представляет собой 128 битовый неструктурированный образ. ЭВМ может дополнительно знать о префиксе субсети для каналов, c которыми она соединена, где различные адреса могут иметь разные значения n:
Рис. 4.4.1.1.2 Более сложные ЭВМ могут использовать и другие иерархические границы в уникастном адресе. Хотя простейшие маршрутизаторы могут не знать о внутренней структуре IPv6 уникастных адресов, маршрутизаторы должны знать об одной или более иерархических границах для обеспечения работы протоколов маршрутизации. Известные границы для разных маршрутизаторов могут отличаться и зависят от того, какое положение занимает данный прибор в иерархии маршрутизации. 4.3.1. Примеры уникастных адресов Примером уникастного адресного формата, который является стандартным для локальных сетей и других случаев, где применимы MAC адреса, может служить:
Рис. 4.4.1.1.3 Где 48-битовый идентификатор интерфейса представляет собой IEEE-802 MAC адрес. Использование IEEE 802 mac адресов в качестве идентификаторов интерфейсов будет стандартным в среде, где узлы имеют IEEE 802 MAC адреса. В других средах, где IEEE 802 MAC адреса не доступны, могут использоваться другие типы адресов связного уровня, такие как E.164 адреса, в качестве идентификаторов интерфейсов. Включение уникального глобального идентификатора интерфейса, такого как IEEE MAC адрес, делает возможным очень простую форму авто-конфигурации адресов. Узел может узнать идентификатор субсети, получая информацию от маршрутизатора в виде сообщений оповещения, которые маршрутизатор посылает связанным с ним партнерам, и затем сформировать IPv6 адрес для себя, используя IEEE MAC адрес в качестве идентификатора интерфейса для данной субсети. Другой формат уникастного адреса относится к случаю, когда локальная сеть или организация нуждаются в дополнительных уровнях иерархии. В этом примере идентификатор субсети делится на идентификатор области и идентификатор субсети. Формат такого адреса имеет вид:
Рис. 4.4.1.1.4 Эта схема может быть развита с тем, чтобы позволить локальной сети или организации добавлять новые уровни внутренней иерархии. Может быть, желательно использовать идентификатор интерфейса меньше чем 48-разрядный IEEE 802 MAC адрес, с тем, чтобы оставить больше места для полей, характеризующих уровни иерархии. Это могут быть идентификаторы интерфейсов, сформированные администрацией локальной сети или организации. 4.4. Не специфицированный адрес Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адресом. Он не должен присваиваться какому-либо узлу. Этот адрес указывает на отсутствие адреса. Примером использования такого адреса может служить поле адреса отправителя любой IPv6 дейтограммы, посланной инициализируемой ЭВМ до того, как она узнала свой адрес. Не специфицированный адрес не должен использоваться в качестве указателя места назначения IPv6 дейтограмм или в IPv6 заголовках маршрутизации. Уникастный адрес 0:0:0:0:0:0:0:1 называется адресом обратной связи. Он может использоваться для посылки IPv6 дейтограмм самому себе. Его нельзя использовать в качестве идентификатора интерфейса. Адрес обратной связи не должен применяться в качестве адреса отправителя в IPv6 дейтограммах, которые посылаются за пределы узла. IPv6 дейтограмма с адресом обратной связи в качестве адреса места назначения не может быть послана за пределы узла. 4.6. IPv6 адреса с вложенными IPv4 адресами Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6 пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется "IPv4-compatible IPv6 address" и имеет формат, изображенный на рис. 4.4.1.1.5:
Рис. 4.4.1.1.5 Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется "IPv4-mapped IPv6 address" и имеет формат показанный на рис. 4.4.1.1.6:
Рис. 4.4.1.1.6 Соответствие NSAP адреса IPv6 адресам выглядит следующим образом (рис. 4.4.1.1.7):
Рис. 4.4.1.1.7 Соответствие IPX и IPv6 адресов показано ниже на рис. 4.4.1.1.8:
Рис. 4.4.1.1.8 4.9. Провайдерские глобальные уникаст-адреса Глобальный уникаст-адрес провайдера имеет назначение, описанное в [ALLOC]. Исходное назначение этих уникаст-адресов аналогично функции IPv4 адресов в схеме CIDR [см. CIDR]. Глобальный IPv6 уникаст-адрес провайдера имеет формат, отображенный ниже на рис. 4.4.1.1.9:
Рис. 4.4.1.1.9. Глобальный адрес провайдера Старшая часть адреса предназначена для определения того, кто определяет часть адреса провайдера, подписчика и т.д. Идентификатор регистрации определяет регистратора, который задает провайдерскую часть адреса. Термин "префикс регистрации" относится к старшей части адреса, включая поле идентификатор регистрации (ID). Идентификатор провайдера задает специфического провайдера, который определяет часть адреса подписчика. Термин "префикс провайдера" относится к старшей части адреса включая идентификатора провайдера. Идентификатор подписчика позволяет разделить подписчиков, подключенных к одному и тому же провайдеру. Термин "префикс подписчика" относится к старшей части адреса, включая идентификатор подписчика. Часть адреса интра-подписчик определяется подписчиком и организована согласно местной топологии Интернет подписчика. Возможно, что несколько подписчиков пожелают использовать область адреса интра-подписчик для одной и той же субсети и интерфейса. В этом случае идентификатор субсети определяет специфический физический канал, а идентификатор интерфейса - определенный интерфейс субсети. 4.10. Локальные уникаст-адреса IPv6 Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на рис. 4.4.1.1.10:
Рис. 4.4.1.1.10. Локальный адрес канала Локальные адреса канала предназначены для обращения через определенный канал, например, для целей авто-конфигурации адресов, поиска соседей или в случае отсутствия маршрутизатора. Маршрутизаторы не должны переадресовывать пакеты с локальными адресами отправителя. Локальный адрес сети имеет формат, показанный на рис. 4.4.1.1.11:
Рис. 4.4.1.1.11. Локальный адрес сети Локальные адреса сети могут использоваться для локальных сетей или организаций, которые (пока еще) не подключены к глобальному Интернет. Им не нужно запрашивать или "красть" префикс адреса из глобального адресного пространства Интернет. Вместо этого можно использовать локальный адрес сети IPv6. Когда организация соединяется с глобальным Интернет, она может сформировать глобальные адреса путем замещения локального префикса сети префиксом подписчика. Маршрутизаторы не должны переадресовывать пакеты с локальными адресами сети отправителя. Эникаст-адрес IPv6 является адресом, который приписан нескольким интерфейсам (обычно принадлежащим разным узлам), при этом пакет, посланный по эникастному адресу, будет доставлен ближайшему интерфейсу в соответствии с метрикой протокола маршрутизации. Эникастные адреса выделяются из уникастного адресного пространства, и используют один из известных уникастных форматов. Таким образом эникастные адреса синтаксически неотличимы от уникастных адресов. Когда уникастный адрес приписан более чем одному интерфейсу, он превращается в эникастный адрес и узлы, которым он приписан, должны быть сконфигурированы так, чтобы распознавать этот адрес. Для любого эникастного адреса существует адресный префикс P, который определяет топологическую область, где находятся все соответствующие ему интерфейсы. В пределах области, заданной P, каждый член эникастной (anycast) группы должен быть объявлен, как отдельный вход в маршрутной системе; вне области, заданной P, эникастный адрес может быть занесен в маршрутную запись для префикса p. Заметим, что в худшем случае префикс P эникастной группы (anycast set) может быть нулевым, т.e., члены группы могут не иметь никакой топологической локальности. В этом случае эникастный адрес должен объявляться как отдельная маршрутная единица (separate routing entry) по всему Интернет, что представляет собой серьезное ограничение, так как число таких "глобальных" эникастных адресов не может быть большим. Одним ожидаемым приложением эникастных адресов является идентификация набора маршрутизаторов, принадлежащих Интернет сервис провайдеру. Такие адреса в маршрутном заголовке IPv6 могут использоваться в качестве промежуточных, чтобы обеспечить доставку пакета через определенного провайдера или последовательность провайдеров. Другим возможным приложением может стать идентификация набора маршрутизаторов, связанных с определенной субсетью, или набора маршрутизаторов, обеспечивающих доступ в определенный домен. Существует ограниченный опыт широкого применения эникастных Интернет адресов, некоторые возможные осложнения и трудности рассмотрены в [anycst]. Имеются следующие ограничения при использовании эникастных IPv6 адресов:
4.11.1. Необходимые эникаст-адреса Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 4.4.1.1.12:
Рис. 4.4.1.1.12 Префикс субсети в эникастном адресе является префиксом, который идентифицирует определенный канал. Этот эникастный адрес является синтаксически идентичным уникастному адресу для интерфейса канала с идентификатором интерфейса равным нулю. Пакеты, посланные группе маршрутизаторов с эникастным адресом, будут доставлены всем маршрутизатам субсети. При этом все маршрутизаторы субсети должны поддерживать работу с эникастными адресами. Реальный обмен будет осуществлен лишь с тем маршрутизатором, который ответит первым. Эникастный адрес маршрутизатора субсети предполагается использовать в приложениях, где необходимо взаимодействовать с одним из совокупности маршрутизаторов удаленной субсети. Например, когда мобильный хост хочет взаимодействовать с одним мобильным агентом в его "домашней" субсети. Мультикастинг-адрес IPv6 является идентификатором для группы узлов. Узел может принадлежать к любому числу мультикастинг групп. Мультикастинг-адреса имеют следующий формат (рис. 4.4.1.1.13):
Рис. 4.4.1.1.13 11111111 в начале адреса идентифицирует адрес, как мультикатинг-адрес.
Рис. 4.4.1.1.14 Старшие 3 флага зарезервированы и должны быть обнулены. t = 0 указывает на то, что адрес является стандартным ("well-known") мультикастным, официально выделенным для глобального использования в Интернет. T = 1 указывает, что данный мультикастинг-адрес присвоен временно ("transient"). Поле scope представляет собой 4-битовый код мультикастинга, предназначенный для определения предельной области действия мультикастинг-группы. Допустимые значения: 0 зарезервировано Идентификатор группы идентифицирует мультикастинг-группы, постоянной или переходной (transient), в пределах заданных ограничений (scope). Значение постоянно присвоенного мультикастинг-адреса не зависит от значения поля scope. Например, если "NTP servers group" присвоен постоянный мультикастинг адрес с идентификатором группы 43 (hex), тогда: ff01:0:0:0:0:0:0:43 означает, что все ntp серверы
одного и того же узла рассматриваются как отправители. Непостоянно выделенные мультикаст-адреса имеют значение только в пределах данного ограничения (scope). Например, группа, определенная непостоянным локальным мультикаст-адресом FF15:0:0:0:0:0:0:43, не имеет никакого смысла для другой локальной сети или непостоянной группы, использующей тот же групповой идентификатор с другим scope, или для постоянной группы с тем же групповым ID. Мультикастинг адреса не должны использоваться в качестве адреса отправителя в IPv6 дейтограммах или встречаться в любых заголовках маршрутизации. 4.12.1. Предопределенные мультикаст-адреса Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными): ff00:0:0:0:0:0:0:0 Перечисленные выше мультикаст-адреса зарезервированы и не будут присваиваться каким-либо мультикаст-группам. Адреса для обращения ко всем узлам: FF01:0:0:0:0:0:0:1 Приведенные выше адреса идентифицируют группу, включающую в себя все IPv6 узлы в пределах группы 1 (локальные узлы) или 2 (локально связанные узлы). Адреса всех маршрутизаторов: FF01:0:0:0:0:0:0:2 Приведенные выше мультикаст-адреса идентифицируют группу всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы) или 2 (связанные локально узлы). DHCP server/relay-agent: FF02:0:0:0:0:0:0:C Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области (scope) 2 (локальный канал). Адрес активного узла (solicited-node): FF02:0:0:0:0:1:xxxx:xxxx Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicited-node) сформирован из младших 32 бит адреса (уникастного или эникастного) добавлением 96 битного префикса FF02:0:0:0:0:1. В результате получен мультикастинг адрес, охватывающий интервал: ff02:0:0:0:0:1:0000:0000 Например, код мультикаст-адреса активного узла (solicited node), соответствующий IPv6 адресу 4037::01:800:200E:8C6C, равен FF02::1:200E:8C6C. IPv6 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться. 4.13. Необходимые адреса узлов ЭВМ должна распознавать следующие адреса, как обращенные к нему:
Маршрутизатор должен распознавать следующие адреса (as identifying itself):
Приложение должно предопределить только следующие адресные префиксы:
Приложения должны считать все остальные адреса уникастными, если противоположное не оговорено при конфигурации (например, эникастные адреса). В IPv6, опционная информация уровня Интернет записывается в отдельных заголовках, которые могут быть помещены между IPv6 заголовком и заголовком верхнего уровня пакета. Существует небольшое число таких заголовков, каждый задается определенным значением кода поля следующий заголовок. В настоящее время определены заголовки: маршрутизации, фрагментации, аутентификации, инкапсуляции, опций hop-by-hop, места назначения и отсутствия следующего заголовка. Как показано в примерах ниже, IPv6 пакет может нести нуль, один, или более заголовков расширения, каждый задается предыдущим полем следующий заголовок (рис. 4.4.1.1.15):
Рис. 4.4.1.1.15. Структура вложения пакетов для IPv6 Заголовки расширения не рассматриваются и не обрабатываются узлами по пути доставки. Содержимое и семантика каждого заголовка расширения определяет, следует или нет обрабатывать следующий заголовок. Следовательно, заголовки расширения должны обрабатываться строго в порядке их выкладки в пакете. Получатель, например, не должен просматривать пакет, искать определенный тип заголовка расширения и обрабатывать его до обработки предыдущих заголовков. Единственное исключение из этого правила касается заголовка опций hop-by-hop, несущего в себе информацию, которая должна быть рассмотрена и обработана каждым узлом по пути доставки, включая отправителя и получателя. Заголовок опций hop-by-hop, если он присутствует, должен следовать непосредственно сразу после IPv6-заголовка. Его присутствие отмечается записью нуля в поле следующий заголовок заголовка IPv6. Если в результате обработки заголовка узлу необходимо перейти к следующему заголовку, а код поля следующий заголовок не распознается, необходимо игнорировать данный пакет и послать соответствующее сообщение ICMP (parameter problem message) отправителю пакета. Это сообщение должно содержать код ICMP = 2 ("unrecognized next header type encountered " - встретился нераспознаваемый тип следующего заголовка) и поле - указатель на не узнанное поле в пакете. Аналогичные действия следует предпринять, если узел встретил код следующего заголовка равный нулю в заголовке, отличном от IPv6-заголовка. Каждый заголовок расширения имеет длину кратную 8 октетам. Многооктетные поля в заголовке расширения выравниваются в соответствии с их естественными границами, т.е., поля с шириной в n октетов помещаются в n октетов, начиная с начала заголовка, для n = 1, 2, 4 или 8. IPv6 включает в себя следующие заголовки расширения: Опции hop-by-hop Последние два описаны в RFC-1826 и RFC-1827. 5.1. Порядок заголовков расширения Когда используется более одного заголовков расширения в одном пакете, рекомендуется помещать их в следующем порядке: IPv6 заголовок (1) для опций, которые должны обрабатываться по адресу, указанному в поле IPv6 destination address и во всех узлах, перечисленных в заголовке маршрутизации. (2) дополнительные рекомендации относительно порядка заголовков authentication и encapsulating security payload приведены в RFC-1827. (3) для опций, которые должны обрабатываться при достижении пакетом конечной точки маршрута. Каждый заголовок расширения должен встречаться не более одного раза, исключение представляет собой заголовок опций места назначения, который должен быть представлен дважды (один раз перед заголовком маршрутизации и второй раз перед заголовком верхнего уровня). Если заголовок верхнего уровня представляет собой еще один IPv6 заголовок (в случае туннелирования IPv6 или инкапсуляции в IPv6), за ним может следовать его собственный заголовок расширения. Узлы IPv6 должны принимать и пытаться обработать заголовки расширения в любом порядке, встречающиеся любое число раз в пределах одного пакета, за исключением заголовка опций типа hop-by-hop, который может появляться только непосредственно за IPv6 заголовком. Два из определенных в настоящее время заголовков расширения - заголовок опций hop-by-hop и заголовок опций места назначения - несут в себе переменное число TLV-кодированных (type-length-value) опций следующего формата (Рис. 4.4.1.1.16):
Рис. 4.4.1.1.16 Формат опций
Последовательность опций в заголовке должна обрабатываться строго в соответствии с их порядком записи. Идентификаторы типа опций кодируются так, что их старшие два бита характеризуют операцию, которая должна быть выполнена, если узел не узнает тип опции:
Третий старший бит типа опции определяет, может ли информация в поле опция измениться по пути до места назначения пакета. Когда в пакете присутствует заголовок аутентификации, для любой опции, информация которой может измениться по пути, должна рассматриваться как нулевые октеты при определении значения идентификации. Значения этого бита: 0 - Данные опции не меняют маршрута Отдельные опции могут требовать определенного выравнивания, с тем, чтобы обеспечить выкладку мультиоктетного значения данных поля опции. Требование выравнивания опции описывается с помощью выражения xn+y, означающего, что поле тип опции должно находиться через целое число, кратное x октетам плюс y октетов (отсчет от начала заголовка). Например:
Существует две опции заполнения, которые используются, когда необходимо выровнять последующие опции и вывести границу заголовка на значение кратное 8 октетам. Эти заполняющие опции должны распознаваться всеми приложениями IPv6: Опция Pad1 (выравнивание не требуется) Опция Pad1 используется для введения одного октета заполнителя в зону опций заголовка. Если требуется более одного октета, используется опция Padn. Опция padn (выравнивание не требуется)
Рис. 4.4.1.1.17 Опция Padn используется для введения двух и более октетов заполнителей в поле опций заголовка. Для n октетов заполнителя поле OPT data Len содержит значение n-2, а поле данных опции состоит из n-2 нулевых октетов 6.1. Опции заголовка Hop-by-Hop (шаг за шагом) Заголовок опций hop-by-hop (шаг за шагом) используется для опционной информации, которая просматривается каждым узлом по пути доставки. Заголовок опций hop-by-hop идентифицируется кодом поля следующий заголовок 0 в IPv6 заголовке и имеет формат (рис. 4.4.1.1.18):
Рис. 4.4.1.1.18. Формат заголовка опций hop-by-hop
В дополнение к Pad1 и Padn опциям определены следующие опции hop-by-hop:
Рис. 4.4.1.1.19. Опция Jumbo payload используется для посылки пакетов IPv6 с полем данных, превосходящим 65535 октетов. Длина Jumbo Payload характеризует длину пакета в октетах, исключая заголовок IPv6, но включая заголовок опций hop-by-hop; Это поле должно содержать код более чем 65535. Если получен пакет с опцией Jumbo payload, содержащей код длины меньше или равный 65535, посылается сообщение ICMP (parameter problem, код 0) с указателем на старший октет поля длины Jumbo payload. Поле длины Payload length IPv6 заголовка должно быть равно нулю для каждого пакета с опцией Jumbo payload. Если получен пакет с корректным значением опции Jumbo Payload и ненулевым кодом длины поля данных, посылается сообщение ICMP (parameter problem код 0) с указателем на поле тип опции. Опция Jumbo payload не может использоваться в пакетах, которые несут в себе заголовок фрагмента. Если заголовок фрагмента встретится в пакете, содержащем корректную опцию jumbo payload, посылается сообщение ICMP (parameter problem, код 0) с указателем на первый октет заголовка фрагмента. Приложения, которые не поддерживают опцию Jumbo Payload, не могут иметь интерфейсы для каналов с MTU больше 65575 (40 октетов IPv6 заголовка плюс 65535 октетов данных). Заголовок маршрутизации используется отправителем, чтобы заставить пакет посетить один или более промежуточных узлов на пути к месту назначения. Эта функция схожа с опцией принудительной маршрутизации в протоколе IPv4. Заголовок маршрутизации идентифицируется кодом 43 поля следующий заголовок предыдущего заголовка и имеет формат:
Если в процессе обработки входного пакета встретится заголовок маршрутизации с не узнанным полем тип маршрутизации, то поведение узла зависит от содержимого поля число оставшихся сегментов пути.
Рис. 4.4.1.1.20. Формат заголовка маршрутизации типа 0
Мультикастинг-адреса не должны встречаться в заголовке маршрутизации типа 0, или в поле места назначения IPv6 пакета, несущего в себе заголовок маршрутизации типа 0. Если бит 0 поля Strict/loose bit map имеет значение 1, поле адреса места назначения IPv6 заголовка в исходном пакете должно идентифицировать соседа. Если бит 0 имеет значение 0, отправитель может использовать любой легальный не мультикастинговый адрес в качестве адреса места назначения. Биты с номерами более n, где n - число адресов в заголовке маршрутизации, должны быть обнуляться отправителем и игнорироваться получателем. Заголовок маршрутизации не рассматривается и не анализируется до тех пор, пока пакет не достигнет места назначения, указанного в поле IPv6 заголовка. Узел, указанный в поле следующий заголовок заголовка, которому принадлежит модуль заголовка маршрутизации, реализует следующий алгоритм: Если оставшееся число сегментов = 0 else если HDR ext len является нечетным или больше 46, else Если число оставшихся сегментов пути больше n, else { уменьшить число оставшихся сегментов пути на 1; Вычислить i, индекс следующего адреса, который следует посетить, для этого вычесть число оставшихся сегментов пути из n Если адрес [i] или адрес места назначения IPv6 являются мультикастинговыми { выбросить пакет } else { поменять местами адрес места назначения IPv6 и адрес[i] если бит i поля strict/loose bit map имеет значение 1 и новый адрес места назначения не является адресом узла соседа { послать сообщение ICMP destination unreachable -- not a neighbor else если код IPv6 hop limit меньше или равен 1 else { уменьшить hop limit на 1 В качестве примера работы приведенного выше алгоритма, рассмотрим случай, когда узел отправителя s посылает пакет получателю D, используя заголовок маршрутизации, чтобы заставить пакет пройти через промежуточные узлы I1, I2 и I3. Значения кодов полей заголовка IPv6 и заголовка маршрутизации для каждого из сегментов пути принимают следующие значения: При движении пакетов от S к I1:
При движении пакетов от I1 к I2:
При движении пакетов от I2 к I3:
При движении пакетов от I3 к D:
Заголовок фрагмента используется отправителем IPv6 для посылки пакетов длиннее, чем MTU пути до места назначения. (Замечание: в отличие от IPv4, фрагментация в IPv6 выполняется только узлами-отправителями, а не маршрутизаторами вдоль пути доставки). Заголовок фрагментации идентифицируется кодом поля следующий заголовок, равным 44 и имеет следующий формат (рис. 4.4.1.1.21):
Рис. 4.4.1.1.21. Формат заголовка фрагментации
Для того чтобы послать пакет с длиной больше MTU пути, узел-отправитель может разделить пакет на фрагменты и послать каждый фрагмент в виде отдельного пакета, сборка исходного пакета будет проведена получателем. Для каждого пакета, который должен быть фрагментирован, узел-отправитель генерирует код идентификации. Этот код должен отличаться от аналогичных кодов идентификации, используемых для других фрагментируемых пакетов, которые пересылаются в данный момент. Под "данным моментом" подразумевается период времени жизни пакета, включая время распространения кадра от источника до получателя и время, необходимое для сборки исходного (оригинального) пакета получателем. Однако не предполагается, чтобы отправитель знал максимальное время жизни пакета. Скорее предполагается, что данное требование будет удовлетворено с помощью простого 32-разрядного счетчика, инкрементируемого всякий раз, когда очередной пакет должен быть фрагментирован. Схема реализации генератора кода идентификации оставляется на усмотрение приложения. Если присутствует заголовок маршрутизации, под адресом получателя подразумевается конечное место назначения. Под исходным большим, не фрагментированным пакетом подразумевается "оригинальный" пакет. Предполагается, что он состоит из двух частей, как показано на рисунке 4.4.1.1.22: Исходный пакет:
Рис. 4.4.1.1.22. Не фрагментированная часть состоит из IPv6 заголовка плюс любых заголовков расширения, которые должны быть обработаны узлами по пути до места назначения. Таким образом, нефрагментированная часть включает в себя все заголовки вплоть до заголовка маршрутизации, если таковой присутствует, или до заголовка опций hop-by-hop, если он присутствует. Фрагментируемая часть представляет собой остальную часть пакета, т.е. включает в себя заголовки расширений, которые должны быть обработаны в узле места назначения, заголовок верхнего уровня и данные. Фрагментируемая часть оригинального пакета делится на фрагменты с длиной кратной 8 октетам. Фрагменты пересылаются независимо с помощью пакетов-фрагментов. Как показано на рис. Рис. 4.4.1.1.23 Исходный пакет:
o o
Рис. 4.4.1.1.23. Каждый пакет-фрагмент состоит из: (1) Не фрагментируемой части оригинального пакета, с длиной поля данных оригинального IPv6 заголовка, измененной для того чтобы соответствовать длине фрагмента пакета (исключая длину самого IPv6-заголовка), а код поля следующий заголовок последнего заголовка не фрагментируемой части меняется на 44. (2) Заголовка фрагмента, включающего в себя: Код поля следующий заголовок, идентифицирующий первый заголовок фрагментируемой части оригинального пакета. Смещение фрагмента, выражаемое в 8-октетных блоках и отсчитываемое от начала фрагментируемой части оригинального пакета. Смещение первого фрагмента (самого левого) равно нулю. Код M-флага равен нулю, если фрагмент является последним (самым правым), в противном случае флаг равен 1. (3) Сам фрагмент. Длина фрагментов должна выбираться такой, чтобы пакеты-фрагменты соответствовали значению MTU для маршрута к месту назначения (назначений). В узле места назначения из пакетов-фрагментов восстанавливается оригинальный пакет в не фрагментированной форме. Восстановленный оригинальный пакет:
Рис. 4.4.1.1.24. В процессе восстановления должны выполняться следующие правила: Оригинальный пакет восстанавливается из фрагментов, которые имеют одни и те же адреса отправителя и получателя, а также код идентификации. Не фрагментируемая часть восстанавливаемого пакета состоит из всех заголовков вплоть до (но не включая) заголовок фрагмента первого пакета-фрагмента (пакет со смещением равным нулю). При этом производятся следующие изменения: Поле следующий заголовок последнего заголовка не фрагментируемой части берется из поля следующий заголовок заголовка первого фрагмента. Длина поля данных восстановленного пакета вычисляется с использованием длины не фрагментируемой части, а также длины и смещения последнего фрагмента. Например, формула расчета длины поля данных восстановленного пакета имеет вид: pl.orig = pl.first - fl.first - 8 + (8 * fo.last) + fl.last где pl.orig - поле длины данных восстановленного пакета. Фрагментируемая часть восстановленного пакета состоит из частей, следующих за заголовками в каждом из пакетов-фрагментов. Длина каждого фрагмента вычисляется путем вычитания из длины поля данных длины заголовков, размещенных между IPv6 заголовком и самим фрагментом. Их относительное положение в фрагментируемой части вычисляется на основе значения смещения фрагмента. Заголовок фрагмента отсутствует в восстановленном пакете. В процессе сборки могут возникнуть следующие ошибки: Если в пределах 60 секунд после прихода первого фрагмента получено недостаточно фрагментов для завершения сборки, процедура сборки должна быть прервана и все полученные фрагменты выкинуты. Если первый фрагмент (т.e., пакет с нулевым смещением) получен, посылается ICMP сообщение "Time exceeded -- Fragment reassemble time exceeded". Если длина фрагмента, полученная из поля длины данных пакета, не является кратным 8 октетам, а M флаг фрагмента равен 1, фрагмент должен быть выброшен и должно быть послано сообщение ICMP (parameter problem, код 0) с указателем на поле длины данных пакета-фрагмента. Если длина и смещение фрагмента таковы, что восстановленная длина поля данных фрагмента превосходит 65,535 октетов, фрагмент выбрасывается, посылается сообщение ICMP (parameter problem, код 0) с указателем на поле смещения фрагмента пакета-фрагмента. Следующие условия не должны реализоваться, но они также рассматриваются как ошибка, если это произойдет: Число и содержимое заголовков, предшествующих заголовку фрагмента, отличаются для разных фрагментов одного и того же исходного пакета. Какие бы заголовки ни предшествовали, заголовку фрагмента, они обрабатываются по прибытии на место назначения до постановки фрагментов в очередь на восстановление. Только эти заголовки из пакета с нулевым смещением сохраняются в восстановленном пакете. Значение поля следующий заголовок в заголовках фрагментов различных фрагментов исходного пакета могут отличаться. Для последующей сборки используется только значение из пакета-фрагмента с нулевым смещением. 9. Заголовок опций места назначения Заголовок опции места назначения используется для передачи опционной информации, которая должна анализироваться только узлом (узлами) назначения. Заголовок опции места назначения идентифицируется кодом поля следующий заголовок равным 60 предшествующего заголовка и имеет формат (рис. 4.4.1.1.25):
Рис. 4.4.1.1.25. Формат заголовка опции места назначения Следующий заголовок - 8-битовый селектор. Идентифицирует тип заголовка, который непосредственно следует за заголовком опций места назначения. Использует те же коды протокола, что и IPv4 [RFC-1700]. Hdr Ext Len - 8-битовое целое без знака. Длина заголовка опций места назначения в 8-октетных блоках, исключая первые 8 октетов. Опции - поле переменной длины, кратное 8 октетам. Содержит одну или более TLV-закодированных опций. Здесь определены только две опции места назначения Pad1 и padn. Обратите внимание, что существует два способа кодировки опционной информации места назначения для пакетов IPv6: в заголовке опций места назначения, или в виде отдельного заголовка расширения. Заголовок фрагмента и заголовок идентификации являются примерами последнего подхода. Какой из подходов будет применен, зависит от того, какая операция желательна в узле места назначения:
10. Отсутствие следующего заголовка Код 59 в поле следующий заголовок IPv6 заголовка или любой другой заголовок расширения указывает, что за этим заголовком ничего не следует. Если поле длина данных заголовка IPv6 указывает на присутствие октетов после конца заголовка, содержащего код 59 в поле следующий заголовок, эти октеты должны быть проигнорированы и переданы без изменений при переадресации пакета. Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6. Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации. Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для использования преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не использовать path MTU discovery. Для того чтобы послать пакет длиннее чем MTU канала, узел может использовать заголовок фрагментации IPv6. Однако использование такой фрагментации заблокировано в приложениях, где используется настройка по измеренному значению MTU пути. Узел должен быть способен принимать фрагментированные пакеты, которые после сборки имеют размер 1500 октетов, включая IPv6 заголовок. Узлу позволено принимать пакеты, которые после сборки имеют размер более 1500 октетов. Однако узел не должен посылать фрагменты, которые после сборки образуют пакеты длиннее 1500 октетов, если он не уверен, что получатель способен их воспринять и дефрагментировать. В ответ на IPv6 пакет, посланный IPv4 адресату (т.e., пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации, чтобы использовать полученные IPv4 фрагменты. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения. Замечание: Анализ MTU пути должно проводиться даже в случае, когда узел "думает", что адресат находится на том же канале что и сам узел. Замечание: В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины mtu канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать. 24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая например, как нестандартная QoS или "real-time " сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении. Поток это последовательность пакетов, посылаемых отправителем определенному адресату, при этом предполагается, что все пакеты данного потока должны быть подвергнуты определенной обработке. Характер этой специальной обработки может быть передан маршрутизатору посредством протокола управления или внутри самих пакетов, например, в опции hop-by-hop. Допускается несколько потоков между отправителем и получателем, а также обмен, не ассоциированный ни с одним из потоков. Поток однозначно описывается комбинацией адреса отправителя и ненулевой меткой потока. Пакеты, не принадлежащие ни одному из потоков, имеют метку равную нулю. Метка потока присваивается потоку узлом отправителя. Новые метки потоков должны выбираться псевдослучайным образом из диапазона чисел 1 - ffffff. Целью псевдослучайного выбора метки является возможность использования любого набора бит поля метки потока в качестве хэш ключа маршрутизаторами для контроля состояния соответствующего потоку. Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации но исключая поле следующий заголовок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете). Маршрутизаторы могут произвольно варьировать способ обработки потоков данных, даже когда имеется какая-либо информация о потоке со стороны протокола управления, опции hop-by-hop или другого источника. Например, при получении пакетов от какого-то источника с неизвестной ненулевой меткой, маршрутизатор может обрабатывать их IPv6-заголовок и любой необходимый заголовок расширения так, как если бы метка равнялась нулю. Такая обработка может включать выявление интерфейса следующего шага и другие действия, такие как актуализация опции hop-by-hop, перемещение указателя и адресов в заголовке маршрутизации и т.д.. Маршрутизатор может запомнить результаты такой обработки, занеся их в кэш (адрес отправителя и метка образуют ключ кэша). Последующие пакеты с тем же адресом отправителя и меткой потока могут обрабатываться с использованием информации из кэша без детального просмотра всех полей, которые, согласно уже описанному, должны быть идентичными. Режим обработки пакетов с использованием кэш должен быть аннулирован не позднее 6 секунд после своей установки вне зависимости от того, продолжают ли поступать пакеты данного потока. Если приходит другой пакет от того же отправителя с той же меткой после того как кэш режим отменен, он подвергается обычной обработке (как если бы имел нулевую метку), такая ситуация может быть причиной повторного формирования кэш режима. Время жизни режима обработки потока задается явно в процессе конфигурации, например, через протокол управления или опцию hop-by-hop, и может превышать 6 секунд. Отправитель не должен использовать старую метку для нового потока в пределах времени жизни любого потока. Так как режим обработки потока на 6 секунд может быть установлен для любого потока, минимальный интервал между последним пакетом одного потока и первым пакетом нового, использующего ту же метку, должно быть равно 6 секундам. Метки потока, которые используются для потоков, существующих более продолжительное время не должны использоваться соответственно дольше. Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память, так чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (time for rebooting, обычно более 6 секунд), это время можно использовать для задания времени жизни меток потоков. Не требуется, чтобы все или даже большинство пакетов принадлежали потокам с ненулевыми метками. Например, было бы неумно сконструировать маршрутизатор так, чтобы он работал только с пакетами, принадлежащими к тому или иному потоку, или создать схему сжатия заголовков, которая работает только с помеченными потоками. 4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов "реального времени", посылаемых с постоянной частотой. Для трафика, управляемого сигналами перегрузки, рекомендуются следующие значения приоритета для конкретных категорий приложений (см. таблицу 4.4.1.1.2). Таблица 4.4.1.1.2. Значения кодов приоритета
Предполагается, что чем больше код, тем выше приоритет данных, тем быстрее они должны быть доставлены. Так для передачи мультимедийной информации, где управление скоростью передачи не возможно, уровень приоритета должен лежать в пределах 8-15. Практически, уровни приоритета выше или равные 8 зарезервированы для передачи данных в реальном масштабе времени. Для трафика, не контролируемого на перегрузки, нижнее значение приоритета (8) должно использоваться для тех пакетов, которые отправитель разрешает выбросить в случае перегрузки (например, видео трафик высокого качества), а высшее значение (15) следует использовать для пакетов, которые отправитель не хотел бы потерять (напр., аудио трафик с низкой надежностью). Не существует связи между относительными приоритетами обменов с и без контроля перегрузки.
14. О протоколе верхнего уровня Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):
Рис. 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP Если пакет содержит заголовок маршрутизации, в качестве адреса места назначения в псевдо-заголовке используется оконечный адрес. В исходном узле этот адрес будет последним элементом заголовка маршрутизации; для узла получателя он будет находиться в поле адрес места назначения IPv6 заголовка.
IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP. 15. Максимальное время жизни пакета В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение. 16. Максимальный размер поля данных для протоколов высокого уровня При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4. 17. Приложение a. Рекомендации по формированию опций Это приложение дает некоторые советы, как выкладывать поля, при формировании новых опций, предназначенных для использования в заголовке опций hop-by-hop или в заголовке опций места назначения. Эти рекомендации базируются на следующих предположениях:
Эти предположения определяют следующий подход к выкладке полей опций: порядок опций от коротких к длинным без внутреннего заполнения. Требования выравнивания границ для всей опции определяется требованием выравнивания наиболее длинного поля (до 8 октетов). Этот подход иллюстрируется на следующих примерах: Пример 1 Если опция x требует двух полей данных, одно длиной 8 октетов, а другое длиной 4 октета, ее формат будет иметь вид (рис. 4.4.1.1.27):
Рис. 4.4.1.1.27. Требование выравнивания соответствует 8n+2, для того чтобы гарантировать начало 8-октетного поля со смещением, кратным 8, от начала последнего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из этих опций будет иметь формат (рис. 4.4.1.1.28):
Рис. 4.4.1.1.28 Пример 2 Если опция y требует трех полей данных, одно длиной 4 октета, одно - 2 октета и одно - длиной один октет, она будет уложена следующим образом (рис. 4.4.1.1.29):
Рис. 4.4.1.1.29 Требование выравнивания выглядит как 4n+3, и призвано гарантировать, что 4-октетное поле начнется со смещением кратным 4 по отношению к началу завершающего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из указанных опций будет иметь вид (рис. 4.4.1.1.30):
Рис. 4.4.1.1.30 Пример 3 Заголовок с опциями hop-by-hop или destination options, содержащий обе опции x и y из примеров 1 и 2, будет иметь один из приведенных ниже форматов, в зависимости от того, какая из опций встречается первой (рис. 4.4.1.1.31, 4.4.1.1.32):
Рис. 4.4.1.1.31
Рис. 4.4.1.1.32 Заголовок IP идентификации [RFC-1826] и безопасная IP инкапсуляция [RFC-1827] будут использоваться в IPv6, в соответствии с безопасной архитектурой протоколов Интернет [RFC-1825]. Существующая поддержка записи адресов Интернет в DNS (Domain Name System) [1,2] не может быть легко расширена для поддержки IPv6-адресов [3], так как приложение предполагает, что адресный запрос вернет только 32-битовый IPv4-адрес. Для того чтобы запоминать IPv6-адреса, определены следующие расширения:
Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. Переходное состояние осуществования IPv4 и IPv6-адресов обсуждается в [4]. 19.1. Определение новой ресурсной записи и домена Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи. Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное). 128-битовый IPv6-адрес записывается в информационной части ресурсной записи aaaa, придерживаясь порядка байт, используемого в сети (старший байт первый). Запрос aaaa для конкретного имени домена в классе Интернет возвращает в качестве отклика все ресурсные записи, соответствующие ресурсной секции aaaa. Запрос типа aaaa не выполняет никакой дополнительной обработки этой секции. Текстовое представление информационной секции ресурсной записи aaaa, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе. Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int. IPv6-адрес представляется в виде имени в домене ip6.int. Это имя выглядит как последовательность символов, разделенных точками, завершающаяся суффиксом .ip6.int. Последовательность символов записывается в обратном порядке, т.е. младший по порядку символ записывается первым и т.д... Каждый из символов представляет собой шестнадцатеричную цифру. Например, запрос, соответствующий адресу 4321:0:1:2:3:4:567:89ab будет выглядеть как b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int. 19.2. Модификации существующих типов запроса Все существующие типы запросов, которые выполняют дополнительную обработку секции a, т.е. типы запросов, относящиеся к серверу имен (ns), почтовому серверу (MX) и почтовому ящику (MB), для осуществления обработки как секции типа a, так и типа aaaa должны быть переопределены. Эти новые определения означают, что сервер имен, обрабатывая один из указанных запросов, должен добавить в соответствующую секцию запроса какие-то подходящие адреса IPv4 и какие-то адреса IPv6 доступные локально. Протокол IPv6 является новой версией IP. IPv6использует протокол управляющих сообщений (ICMP) так, как это определено для IPv4 [RFC-792], но с некоторым количеством изменений. Протокол подключения к группам (IGMP), специфицированный для IPv4 [RFC-1112] был также пересмотрен и включен в протокол ICMP для IPv6. Результирующий протокол называется ICMPv6, и имеет код следующего заголовка 58. ICMPv6 используется узлами IPv6 для сообщений об ошибках при обработке пакетов, и для выполнения других функций уровня Интернет, таких как диагностика (ICMPv6 "ping") и сообщение об участии в мультикастинг группах. Протокол ICMPv6 является интегрированной частью IPv6 и должен реализовываться каждым узлом, поддерживающим IPv6. Сообщения ICMPv6 образуют два класса: сообщения об ошибках и информационные сообщения. Сообщения об ошибках идентифицируются по нулю в старшем бите поля тип. Таким образом, сообщения об ошибках могут иметь код поля тип от 0 до 127; информационные сообщения имеют коды поля тип от 128 до 255. В данном документе определены форматы для следующих сообщений ICMPv6: Сообщения об ошибках ICMPv6: 1 destination unreachable (место назначения недоступно) Информационные сообщения ICMPv6: 128 echo request (Запрос эхо) Каждое сообщение ICMPv6 начинается с заголовка IPv6, за которым следует нуль или более заголовков расширения IPv6. Заголовок ICMPv6 идентифицируется кодом следующего заголовка 58 в предыдущем заголовке. (Заметим: этот код отличается от значения, принятого для ICMP IPv4.) Сообщения ICMPv6 имеют следующий общий формат (рис. 4.4.1.1.33):
Рис. 4.4.1.1.33. Общий формат сообщений ICMPv6 Поле тип указывает на тип сообщения. Его значение определяет формат последующих данных. Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6. Узел отправитель сообщения ICMPv6 должен определить IPv6-адреса отправителя и получателя до вычисления контрольной суммы. Если узел имеет более одного уникастного адреса, то он должен выбрать адрес отправителя следующим образом:
Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см. в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется. Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):
Если исходный пакет имеет необычно большое число заголовков расширения, возможно, что тип протокола верхнего уровня может отсутствовать в сообщении ICMPv6, из-за укорочения исходного пакета до уровня 576 октетов. В этом случае сообщение об ошибке отбрасывается после обработки уровня IPv6. (e.1) сообщения об ошибке ICMPv6, или (e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) - чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или (e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или (e.4) широковещательного пакета канального уровня, (исключения пункта e.2 применимы и здесь), или (e.5) пакета, чей адрес отправителя не однозначно определяет какой-то узел, например, не специфицированный адрес IPv6, мультикаст-адрес IPv6 или эникаст-адрес. (f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует. Это ограничит загрузку канала. Существует много способов ограничения частоты посылки сообщений, например: (f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд. (f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала. Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!). 20.3. Сообщения об ошибках ICMPv6
Рис. 4.4.1.1.34. Формат сообщения о недостижимости адресата Поля IPv6: Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку. Поля ICMPv6:
Тип = 1 Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем. Описание Сообщение адресат не достижим (destination unreachable) должно генерироваться маршрутизатором, или уровнем IPv6 узла-отправителя, в случае, когда пакет не может быть доставлен адресату не по причине перегрузки. (Сообщение ICMPv6 не должно посылаться при потере пакета из-за перегрузки). Если причиной потери пакета является недостаток места в маршрутной таблице узла, поле код должно принять значение 0 (Заметим, что такая ошибка может произойти только при наличии в таблице маршрута по умолчанию). Если причиной потери пакета является административный запрет, например, Firewall, поле код принимает значение 1. Если причиной потери пакета является то, что следующий узел в маршрутной таблице не является соседом данного узла, то поле код принимает значение 2. Если имеет место какая-то другая причина недоставки пакета, в поле код заносится значение 3. Узел места назначения может посылать сообщение "адресат не достижим" с кодом 4, когда транспортный протокол пакета (напр., UDP) не имеет получателя, а другого метода, уведомить об этом отправителя нет. Узел, получивший сообщение ICMPv6 "адресат не достижим" должен уведомить об этом протокол вышележащего уровня.
Рис. 4.4.1.1.35. Сообщение packet too big (пакет слишком велик) Поля IPv6: Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку. Поля ICMPv6:
Тип 2 Описание Сообщение packet too big (пакет слишком велик) должно посылаться маршрутизатором в ответ на получение пакета, который не может быть переадресован, из-за того, что он длиннее, чем MTU выходного канала. Информация в этом сообщении используется в качестве части процесса определения MTU прохода [RFC-1191]. Пришедшее сообщение packet too big должно быть передано протоколу верхнего уровня. Формат сообщения о превышении времени аналогичен формату сообщения о недостижимости адресата (рис. 4.4.1.1.33). Поля ICMPv6:
Тип 3 Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем. Описание Если маршрутизатор получает пакет с предельным значением числа шагов равным нулю (hop limit = 0), или маршрутизатор после декрементации получил нулевое значение поля hop limit, он должен выбросить такой пакет и послать отправителю пакета сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным 0. Это указывает на зацикливание маршрута или на слишком малое значение поля hop limit. Посылая сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным нулю, маршрутизатор должен рассматривать входной интерфейс, в соответствии с правилом выбора адреса отправителя (d). Пришедшее сообщение time exceeded должно быть передано протоколу верхнего уровня.
Рис. 4.4.1.1.36. Сообщение о конфликте параметров Поля ICMPv6:
Тип 4 Указатель отмечает позицию в пакете, если размер пакета ICMPv6 не позволяет поместить его в отклик полностью, а ошибочное поле в сообщение не поместилось. Описание Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то проблему с одним из полей заголовка или заголовков расширения, такую, что дальнейшая обработка невозможна, он должен выбросить пакет и послать сообщение ICMPv6 parameter problem (проблема с параметрами) отправителю пакета с указанием типа и позиции ошибки. Поле указатель идентифицирует октет заголовка исходного пакета, где обнаружена ошибка. Например, сообщение ICMPv6 с полем тип = 4, полем код = 1 и полем указатель = 40 указывает на то, что заголовок расширения IPv6, следующий за заголовком IPv6 исходного пакета содержит нераспознанный код следующего заголовка. 20.4. Информационные сообщения ICMPv6
Рис. 4.4.1.1.37. Сообщение запрос эхо Поля IPv6: Адрес места назначения - любой легальный IPv6-адрес Поля ICMPv6:
Тип 128 Номер по порядку Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю. Информация. Нуль или более октетов произвольных данных. Описание Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики. Формат сообщения эхо-отклик идентичен формату запроса эхо (рис. 20.5). Поля IPv6: Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо. Поля ICMPv6:
Тип 129 Номер по порядку. Номер по порядку из исходного запроса эхо. Информация. Данные из исходного запроса эхо. Описание Каждый узел должен иметь встроенную функцию отклика ICMPv6, которая получает запросы эхо и посылает соответствующие эхо-отклики. Узел должен также реализовать интерфейс прикладного уровня для посылки запросов эхо и получения эхо-откликов для диагностических целей. Адрес отправителя эхо-отклика, посылаемого в ответ на уникастный запрос эхо должен быть тем же самым, что и адрес места назначения в запросе эхо. Эхо-отклик должен быть послан в ответ на запрос эхо, посланный по мультикастному адресу. Адрес отправителя в отклике должен быть уникастным адресом, принадлежащим интерфейсу, через который был получен мультикастный запрос эхо. Информация, полученная в ICMPv6 сообщении запроса эхо, должна быть полостью возвращена без модификации в ICMPv6 эхо-отклике, если эхо-отклик не превысит MTU обратного прохода, в противном случае пакет укорачивается. Оповещение верхнего уровня Сообщения эхо-отклик должны передаваться пользовательскому интерфейсу ICMPv6, если соответствующий запрос эхо исходит не из IP-уровня. Сообщение о членстве в группе имеет следующий формат:
Рис. 4.4.1.1.38. Сообщения участия в группе Поля IPv6: В сообщении-запросе о членстве в группе запрашивается мультикаст-адрес группы. В отчете о членстве в группе или в сообщении о сокращении членства в группе сообщается мультикаст-адрес группы. Поле Hop Limit = 1 (предельное число шагов)
Тип 130 - Запрос членства в группе В сообщениях запросах - это максимальное время в миллисекундах, на которое может задержаться сообщение-отчет. В сообщениях-отчетах и сообщениях о сокращении в это поле отправитель записывает нуль, а получатель его игнорирует.
Не используется. Отправитель записывает нуль, получатель игнорирует. Адрес мультикаст-группы, сообщение о которой послано. В сообщениях-запросах поле мультикаст-адреса может равняться нулю, что означает запрос ко всем группам. Описание Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112]. Литература
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.1 IP-протокол
UP:
4.4 Интернет
|
|
|
|
4.4.1.2 IP-туннели
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Особенность IP-протокола (опция принудительной маршрутизации) позволяет переадресовывать IP-дейтограммы определенным узлам сети. На первый взгляд эта возможность может показаться совершенно бесполезной, ведь существуют механизмы динамической маршрутизации, которые несравненно эффективнее и надежней обеспечивают обмен данными. Но тем не менее существуют приложения, где принудительная маршрутизация на IP-уровне представляет возможности недоступные для традиционных решений. Это прежде всего сети, работающие с использованием протоколов IPX/SPX (Novell), где традиционная маршрутизация не предусмотрена. Для подключений удаленных серверов, находящихся вне локальной сети, здесь используется технология так называемых IP-туннелей. При реализации этой технологии IPX-пакеты инкапсулируются в IP-дейтограммы и доставляются в соответствие с протоколами TCP/IP. Процедура инкапсуляции осуществляется специальным драйвером (IPtunnel; использует протокол IPxodi), который работает так, как если бы он был драйвером аппаратного сетевого интерфейса. При этом необходимо модифицировать конфигурационный файл net.cfg (См., например, www2.ncsu.edu/cc-consult/usinglwp/tunnel.html ). ;Техника IP-туннелей может оказаться иногда полезной и при администрировании маршрутизации, так как метрика внешних протоколов маршрутизации может не учитывать пропускную способность каналов и некоторые другие факторы, например, QoS. В этом случае IP-дейтограммы вкладываются в IP-дейтограммы отправителем (начало туннеля) и извлекаются оттуда в конце туннеля. Конец туннеля не обязательно совпадает с местом назначения пакетов. Такая простая схема туннелирования может порождать некоторые проблемы (см. рис. 4.4.1.2.1).
Рис. 4.4.1.2.1 Схема туннелирования пакетов. Квадратными скобками отмечено вложение пакетов. В числителе приводится адрес места назначения, в знаменателе адрес отправителя. Адрес вне скобок - адрес места назначения. Из рисунка видно, что простой туннель может породить асимметричный маршрут, при котором путь туда и обратно не совпадают. Чтобы такого не произошло, применяется техника "маскарада" (masquerading). Для этого "маршрутизатор конца туннеля" должен извлечь вложенный пакет (как это он делает и на рис. 4.4.1.2.1) и вложить его в пакет с адресом места назначения IP3, указав при этом в качестве отправителя себя (IP3/IP2[IP3/IP1]). Тогда конечный адресат IP3 будет посылать отклики по адресу IP2, а не IP1. А уже маршрутизатор конца туннеля будет пересылать их первоисточнику запроса IP1. В последнее время техника туннелей нашла применение при построении так называемых прокси-серверов, популярность которых связана с возможностью заметно сократить внешний (часто зарубежный) трафик за счет запоминания в дисковом буфере файлов, наиболее часто запрашиваемых клиентами. Заметно упрощает решение данной задачи многие современные маршрутизаторы, которые могут отфильтровывать запросы по определенным портам и переадресовывать их прокси-серверу (см. рис. 4.4.1.2.2).
Рис. 4.4.1.2.2. Схема транспортировки запросов при использовании прокси-сервера Схема с "невидимым" прокси-сервером работает следующим образом. Сначала запрос поступает в маршрутизатор, там он анализируется и, если выясняется что это HTTP или FTP-запросы, переадресуется прокси-серверу. Если запрашиваемый файл находится в буфере сервера, заказ клиента удовлетворяется локально. В противном случае запрос снова посылается маршрутизатору. Запросы прокси-сервера маршрутизатор переправляет во внешнюю сеть. В случае использования персональной ЭВМ в качестве прокси-сервера можно ее снабдить двумя сетевыми интерфейсами для приема и посылки запросов, что сделает работу более эффективной. Если маршрутизатор не поддерживает описанный режим, то при конфигурации сетевого программного обеспечения клиента можно явно прописать адрес прокси-сервера и все соответствующие запросы пойдут непосредственно туда. Туннели широко используются и при передаче мультимедийных данных. |
|
Previous:
4.4.1.1 Адресация IPv6
UP:
4.4 Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
(W. Townsley, A. Valencia, A., Rubens, G. Pall, G. Zorn, B. Palter, Layer Two Tunneling Protocol "L2TP". RFC-2661, August 1999. Перевод Семенова Ю.А.) 1.0. Введение Протокол PPP [RFC1661] определяет механизм инкапсуляции для транспортировки мультипротокольных пакетов для соединений точка-точка сетевого уровня L2. Обычно, пользователь получает соединение L2 с сервером доступа NAS (Network Access Server) посредством одной из следующих технологий: посредством модема через коммутируемую телефонную сеть, ISDN, ADSL, и т.д. Далее через это соединение реализуется протокол PPP. В такой конфигурации терминальная точка L2 и сессии PPP находится в одном и том же физическом устройстве (NAS). Разрабатывается версия протокола для безопасного удаленногго доступа через L2TP (RFC-2888). Протокол L2TP расширяет модель PPP, позволяя размещение терминальных точек L2 и PPP в различных физических устройствах, подключенных к сети с коммутацией пакетов. В L2TP, пользователь имеет соединение L2 с концентратором доступа (например, модемным пулом, ADSL DSLAM, и т.д.), а концентратор в свою очередь туннелирует индивидуальные PPP-кадры в NAS. Это позволяет разделить обработку PPP-пакетов и реализацию шлюза L2. Очевидным преимуществом такого разделения является то, что вместо требования завершения соединения L2 в NAS, соединение может завершаться в локальном концентраторе, который затем продлевает логический канал PPP через общую инфраструктуру, такую как, например, Интернет. C точки зрения пользователя нет никакой разницы между завершением туннеля на уровне L2 в NAS или через L2TP. Многоканальный PPP [RFC1990] требует, чтобы все каналы, образующие многоканальную связь, были объединены в группу с помощью одного NAS. Благодаря возможности формирования сессий PPP с оконечными адресами, отличными от точки присоединения, L2TP может использоваться для схем, когда все каналы приходят на вход одного NAS. 1.1. Терминология
2. Топология На диаграмме (рис. 1.) показана схема работы протокола L2TP. Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC и LNS, размещенной в LAN.
Рис. 1. Схема работы протокола L2TP Удаленная система инициирует PPP-соединение с LAC через коммутируемую телефонную сеть PSTN. LAC затем прокладывает туннель для PPP-соединения через Интернет, Frame Relay или ATM к LNS, посредством чего осуществляется доступ к исходной LAN (Home LAN). Адреса удаленной системе предоставляются исходной LAN через согласование с PPP NCP. Аутентификация, авторизация и аккоунтинг могут быть предоставлены областью управления LAN, как если бы пользователь был непосредственно соединен с сервером сетевого доступа NAS. LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании до исходной LAN без использования отдельного LAC. В этом случае, ЭВМ, содержащая программу LAC клиента, уже имеет соединение с Интернет. Затем создается "виртуальное" PPP-соединение и локальная программа L2TP LAC формирует туннель до LNS. Как и в выше описанном случае, адресация, аутентификация, авторизация и аккоунтинг будут обеспечены областью управления исходной LAN. 3. Обзор протокола L2TP использует два вида пакетов, управляющие и информационные сообщения. Управляющие сообщения используются при установлении, поддержании и аннулировании туннелей и вызовов. Информационные сообщения используются для инкапсуляции PPP-кадров пересылаемых по туннелю. Управляющие сообщения используют надежный контрольный канал в пределах L2TP, чтобы гарантировать доставку (смотри раздел 5.1). Информационные сообщения если происходит их потеря, не пересылаются повторно.
Рис. 2.0. Структура протокола L2TP На рис. 2.0 показано взаимоотношение PPP-кадров и управляющих сообщений по управляющему и информационному каналам L2TP. PPP-кадры передаются через ненадежный канал данных, инкапсулированные сначала в L2TP, а затем в транспортные пакеты, такие как UDP, Frame Relay, ATM и т.д.. Управляющие сообщения посылаются через надежный управляющий канал L2TP, который передает пакеты в пределах того же пакетного транспорта. Порядковые номера необходимы во всех управляющих сообщениях и используются в управляющем канале для обеспечения надежной доставки. Информационные сообщения могут использовать порядковые номера, чтобы восстановить порядок пакетов и детектировать потерю кадров. Все коды посылаются в порядке, принятом для сетей (старшие октеты первые). 3.1. Формат заголовка L2TP Пакеты L2TP для контрольного и информационного каналов используют один и тот же формат заголовка. Заметим, что поля длина, Ns и Nr - опционные для информационных пакетов, являются обязательными для всех управляющих сообщений. Заголовок имеет следующий формат:
Рис. 3. Формат заголовка L2TP Бит тип (T) характеризует разновидность пакета. Он устанавливается равным 0 для информационных сообщений и 1 - для управляющих. Если бит длины (L) равен 1, поле длина присутствует. Для управляющих сообщений этот бит должен быть равен 1. Биты x зарезервированы для будущих применений. Все зарезервированные биты должны быть установлены равными 0 для исходящих сообщений и игнорироваться для входящих. Если бит последовательности (S) равен 1, поля Ns и Nr присутствуют. Бит S для управляющих сообщений должен быть равен 1. Если бит смещения (O) равен 1, поле величины смещения присутствует. Бит O для управляющих сообщений должен быть равен 0. Если бит приоритета Р равен 1, это информационное сообщение должно обслуживаться с предпочтением при обработке очередей и передаче. Запрос эхо LCP (Link Control Protocol) используется для канала, в качестве контроля keepalive, его следует посылать с битом приоритета равным 1. Без этого, временные периоды локальной перегрузки могут вызвать интерференцию с сообщениями keepalive и потерю связи. Эта особенность характерна только для информационных сообщений. Бит P должен быть равен 0 для всех управляющих сообщений. Поле Ver должно быть равно 2, указывая версию заголовка информационного сообщения L2TP. Значение 1 зарезервировано для детектирования пакетов L2F [RFC-2341], в условиях, когда они приходят вперемешку с L2TP-пакетами. Пакеты, полученные с неизвестным значением поля Ver должны отбрасываться. Поле длина указывает общую длину сообщения в октетах. ID-туннеля содержит идентификатор управляющего соединения. Идентификаторы туннеля L2TP имеют только локальное значение. То есть, разные концы одного туннеля должны иметь разные ID. ID-туннеля в каждом сообщении должно быть тем, которое ожидает получатель. ID-туннеля выбираются при формировании туннеля. ID-сессии определяет идентификатор для сессии данного туннеля. Сессии L2TP именуются с помощью идентификаторов, которые имеют только локальное значение. ID-сессии в каждом сообщении должно быть тем, которое ожидает получатель. ID-сессии выбираются при формировании сессии. Ns определяет порядковый номер информационного или управляющего сообщения, начиная с нуля и увеличиваясь на 1 (по модулю 216) для каждого посланного сообщения. Смотри разделы 5.8 и 5.4. Nr содержит порядковый номер, который ожидается для следующего сообщения. Таким образом, Nr делается равным Ns последнего по порядку полученного сообщения плюс один (по модулю 216). В информационных сообщениях, Nr зарезервировано и, если присутствует (как это определяется S- битом), должно игнорироваться при получении. Смотри раздел 5.8. Поле величина смещения (Offset Size), если имеется, специфицирует число октетов после заголовка L2TP, где должно начинаться поле данных. Содержимое заполнителя смещения не определено. Если поле смещения присутствует, заголовок L2TP завершается после завершающего октета заполнителя смещения. 3.2. Типы управляющих сообщений Тип сообщения AVP (смотри раздел 4.4.1) определяет специфический тип посылаемого управляющего сообщения. В данном документе определены следующие типы управляющих сообщений (смотри разделы 6.1 - 6.14): Управление контрольным соединением
Управление вызовами (Call Management)
Сообщения об ошибках
Управление сессией PPP
4. Пары значений-атрибутов управляющих сообщений 4.1. Формат AVP Каждая AVP кодируется следующим образом:
Рис. 4. Первые 6 бит представляют собой битовую маску, характеризующую атрибуты AVP. Два бита определены в этом документе, остальные - зарезервированы на будущее. Зарезервированные биты должны равняться нулю. AVP, полученная с зарезервированным набором бит равным 1, должна рассматриваться как не узнанная AVP. Обязательный бит M (Mandatory) контролирует реакцию системы на получение нераспознанной AVP. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном с определенной сессией, эта сессия должна быть немедленно завершена. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном со всем туннелем, этот туннель (и все его сессии) должен быть ликвидирован. Если бит M =0, нераспознанную AVP следует игнорировать. Управляющие сообщения должны обрабатываться при этом так, как если бы AVP не было. Бит сокрытия (H). Идентифицирует скрываемые данные в поле значения атрибута AVP. Эта возможность может использоваться, чтобы исключить передачу важных данных, например пароля пользователя, в незашифрованном тексте AVP. В разделе 4.3 описана процедура выполнения сокрытия AVP. Длина. Число октетов (включая поля полной длины и маски) в AVP. Длина может быть вычислена как 6 + длина поля значения атрибута в октетах. Поле имеет 10 бит, позволяя закодировать до 1023 октетов в одной AVP. Минимальный код длины AVP равен 6. Если длина равна 6, поле значения атрибута отсутствует. ID производителя (Vendor ID). IANA определила значения кодов производителей (SMI Network Management Private Enterprise Codes) [RFC1700]. Значение 0, соответствующее атрибутам, адаптированным для IETF, используется для всех AVP, определенных в данном документе. Любой производитель, желающий реализовать свое собственное расширение L2TP, может использовать свой код Vendor ID вместе с частными значениями атрибута, гарантирующие отсутствие столкновений с любыми расширениями других производителей, или будущими расширениями IETF. Заметим, что для ID-производителя выделено 16 бит, что ограничивает максимальное число производителей цифрой 65,535. Тип атрибута: 2-октетное значение с уникальной интерпретацией для совокупности AVP данного ID-производителя. Значение атрибута. Действительное значение атрибута для заданного Vendor ID и типа атрибута. Оно следует немедленно после поля типа атрибута, и занимает все пространство октетов, отведенное значением поля длина (т.e., длина минус 6 октетов заголовка). Это поле отсутствует, если длина равна 6. 4.2. Обязательные AVP Получение неизвестной AVP, которая имеет бит M=1, является катастрофическим для сессии или туннеля, с которым она ассоциирована. Таким образом, бит M должен быть определен только для AVP, которые критичны для нормальной работы сессии или туннеля. Далее, в случае, когда LAC или LNS получают неизвестную AVP с M-битом равным 1 и закрывают сессию или туннель, ответственность за это полностью несет партнер, пославший обязательную AVP. Прежде чем определить AVP с M=1, в особенности AVP специфичное для данного производителя, убедитесь в том, что вы именно этого хотите. Когда имеется адекватная альтернатива использованию M-бита, ей следует воспользоваться. Например, вместо того, чтобы посылать AVP с M=1 для определения существования специфического расширения, можно решить проблему путем посылки AVP в сообщении-запросе в расчете на получение соответствующего AVP в отклике. Использование M-бита с новыми AVP (не определенными в этом документе) должно предоставить возможность сконфигурировать программу так, чтобы AVP либо не посылалась, или посылалась с M-битом равным нулю. 4.3. Сокрытие значений атрибутов AVP Бит H в заголовке каждой AVP предлагает механизм указания принимающему партнеру, представлено ли содержимое AVP скрытым или открытым текстом. Эта возможность применяется, чтобы скрыть важную информацию управляющих сообщений, такую как пароль пользователя или его ID. Бит H должен быть равен 1, если имеется общий ключ для LAC и LNS. Этот ключ является тем же ключом, который использовался для аутентификации туннеля (смотри раздел 5.1.1). Если бит H =1 в любой AVP в данном управляющем сообщении, там должен также присутствовать случайный вектор AVP и должен предшествовать первому AVP, имеющему H = 1. Сокрытие значения AVP делается за несколько шагов. Сначала берутся поля длины и значения оригинала (открытый текст) AVP и кодируются согласно субформата скрытого AVP:
Рис 5. Субформат скрытого AVP Исходная длина значения атрибута. Это длина кода исходного значения атрибута, которое следует закрыть, в октетах. Необходимо определить исходную длину значения атрибута, так как ее значение теряется при добавлении заполнителя. Исходное значение атрибута. Значение атрибута, которое должно быть скрыто. Заполнитель. Произвольные дополнительные октеты, используемые для того, чтобы скрыть длину значения атрибута, когда необходимо скрыть само значение. Чтобы замаскировать размер скрытого поля данных, используемый субформат может быть дополнен некоторым количеством произвольных октетов. Заполнитель не меняет значения поля, но изменяет величину поля длина AVP, которое было сформировано. Например, если значение атрибута, которое необходимо скрыть, занимает 4 октета, исходная длина AVP будет равна 10 октетам (6 + длина поля значения атрибута). После операции сокрытия, длина AVP станет равной 6 + длина атрибута + размер поля длины исходного значения атрибута + длина заполнителя. Таким образом, если заполнитель имеет 12 октетов, длина AVP будет равна 6 + 4 + 2 + 12 = 24 октетам. Далее, производится хэширование (MD5) для полученного объединения: + 2 октета номера атрибута AVP Значение случайного вектора, используемого в этом хэше, передается в поле случайный вектор AVP. Этот случайный вектор AVP должен быть помещен в сообщение отправителем до любого скрытого AVP. Тот же самый случайный вектор может быть использован для более чем одного скрытого AVP сообщения. Если для сокрытия последующих AVP используется другой случайный вектор, тогда новый случайный вектор AVP должен быть помещен в командное сообщение до первого его использования. Значение хэша MD5 затем объединяется с помощью операции XOR с первыми 16 октетами сегмента субформата скрытого AVP и помещается в поле значения атрибута скрытого AVP. Если субформат скрытого AVP имеет менее 16 октетов, субформат преобразуется так, как если бы поле значения атрибута было дополнено до 16 октетов перед операцией XOR, но модифицируются только действительные октеты, присутствующие в субформате, а длина AVP не изменяется. Если субформат длиннее 16 октетов, вычисляется второй хэш MD5 для потока октетов, состоящего из общего секретного ключа, за которым следует результат первой операции XOR. Этот хэш объединяется с помощью операции XOR со вторым 16 октетным (или менее) сегментом субформата, а результат помещается в соответствующие октеты поля значения скрытого AVP. Если необходимо, эта операция повторяется, для общего секретного ключа, используемого совместно с каждым результатом операции XOR, чтобы получить очередной хэш, для которого будет выполняться XOR с кодом следующего сегмента. Метод сокрытия был адаптирован из RFC 2138 [RFC2138], который был взят из секции "Mixing in the Plaintext" книги "Network Security" Кауфмана, Пелмана и Спенсера [KPS]. Ниже дается детальное пояснение метода: Берется общий секретный ключ S, случайный вектор RV и значение атрибута AV. Поле значение делится на секции по 16 октетов p1, p2 и т.д.. Последняя секция дополняется до границы в 16 октетов специальным заполнителем. Вычисляются блоки шифротекста c(1), c(2), и т.д.. Мы также определяем промежуточные значения b1, b2, и т.д.
строка будет содержать c(1)+c(2)+...+c(i) где + означает объединение. По получение, случайный вектор берется из AVP, включенного в сообщение до AVP, подлежащего сокрытию. Описанный выше процесс реверсируется с целью получения исходного значения. 4.4. Обзор AVP Имя AVP является списком, указывающим типы сообщений, которые использует каждая AVP. После каждого названия AVP следует короткое описание назначения AVP, подробности формата значения атрибута, и любая дополнительная информация, необходимая для правильного использования AVP. 4.4.1. AVP, применимые для всех управляющих сообщений Тип сообщения (все сообщения) Тип сообщения AVP, тип атрибута 0, идентифицируют управляющее сообщение и определяет контекст, в котором будет определено точное значение последующих AVP. Поле значения атрибута для этой AVP имеет следующий формат:
Рис. 6 Тип сообщения характеризуется целым 2-октетным числом без знака. Тип сообщения AVP должен быть первым AVP в сообщении, который следует непосредственно сразу за заголовком управляющего cообщения (определено в разделе 3.1). Список типов управляющих сообщений и их идентификаторов смотри в разделе 3.2. Обязательный бит (M) в типе сообщения AVP имеет специальное назначение. Этот бит служит скорее не для указания того, следует ли игнорировать саму AVP, если бы она не распознана, а указанием того, что при не распознании следует игнорировать управляющее сообщение. Таким образом, если M-бит равен 1 в типе сообщения AVP, а тип сообщения неизвестен программе, туннель должен быть ликвидирован. Если бит M=0, тогда программа может игнорировать сообщения неизвестных типов. M-бит должен быть сделан равным 1 для всех типов сообщений определенных в данном документе. Эта AVP не может быть скрытой (H-бит должен быть равен нулю 0). Длина этого AVP равна 8. Случайный вектор (все сообщения) Случайный вектор AVP, тип атрибута 36, используются для разрешения сокрытия значения атрибута AVP. Случайная последовательность октетов может иметь произвольную длину, хотя для случайного вектора рекомендуется длина, по крайней мере, 16 октетов. Строка содержит случайный вектор для использования при вычислении хэша MD5 чтобы извлечь или скрыть значение атрибута скрытого AVP (смотри раздел 4.2). В сообщении может быть более одного случайного вектора AVP. Эта AVP должна предшествовать первому AVP с битом H =1. M-бит для этого AVP должно быть равно 1. Это AVP не должно быть скрыто (H-бит должен быть равен 0). Длина этого AVP равно 6 плюс длина случайной строки октетов. 4.4.2. Коды результата и ошибки Результирующий код (CDN, StopCCN) Результирующий код AVP, тип атрибута - 1, индицируют причину завершения работы управляющего канала или сессии. Поле значения атрибута AVP имеет следующий формат:
Рис. 7. Формат поля значения атрибута AVP Результирующий код представляет собой целое число без знака длиной в 2 октета. Опционный код ошибки представляет собой 2-октетное целое число без знака. Опционное сообщение об ошибке поясняет код ошибки. Присутствие кода ошибки и сообщения определяется полем длины AVP. Сообщение об ошибке содержит произвольную строку текста, пригодного для чтения, характеризующего ситуацию. Читабельный текст во всех сообщений об ошибке должен быть представлен в кодировке UTF-8, для языка по умолчанию [RFC2277]. Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина равна 8, если в сообщении нет кода ошибки и нет сообщения об ошибке, 10, если имеется код ошибки, но нет сообщения об ошибке, или 10 + длина сообщения об ошибке, если имеется код и сообщение об ошибке. Определенные значения кодов результата для сообщения StopCCN перечислены ниже:
Определены следующие значения кодов результата для сообщений CDN: 0 - Зарезервировано Коды ошибок, определенные ниже, относятся к типам ошибок, которые не являются специфическими для любого конкретного L2TP-запроса, и относятся скорее к ошибкам протокола или формата сообщения. Если L2TP-отклик указывает в своем коде результата, что произошла общая ошибка, для выяснения причины должен быть проанализирован общий код ошибки. В настоящее время определены общие коды ошибки и их значение:
Когда используется код общей ошибки = 6, дополнительная информация об ошибке должна быть помещена в поле сообщения об ошибке. 4.4.3. AVP управления контрольным соединением Версия протокола (SCCRP, SCCRQ) Версия протокола AVP, тип атрибута - 2, указывает на версию протокола L2TP отправителя. Поле значения атрибута для данной AVP имеет следующий формат:
Рис. 8. Поле значения атрибута для AVP управления контрольным соединением Поле Ver характеризуется целым числом без знака длиной в один октет и содержит код 1. Поле Rev характеризуется целым числом без знака длиной в один октет и содержит код 0. Так характеризуется версия протокола L2TP 1, и модификация версии 0. Заметим, что это не тот же код версии, что включается в заголовок каждого сообщения. Эта AVP не должна быть скрытой (бит H должен быть равен 0). Бит M для данной AVP должен быть равен 1. Длина этой AVP равна 8. Возможность работы с кадрами (SCCRP, SCCRQ) Возможность работы с кадрами AVP, тип атрибута - 3, предоставляет партнеру указание на типы кадров, которые будут приняты или запрошены отправителем. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 9. Поле значения атрибута для AVP возможности работы с кадрами Поле значения атрибута представляет собой 32-битовую маску, с двумя определенными битами. Если бит A=1, поддерживается асинхронный обмен кадрами. Если бит S=1, поддерживается синхронный обмен кадрами. Партнер не должен запрашивать входящий или исходящий вызов с кадровым типом AVP, специфицирующим значение, не указанное в AVP, которые были получены при установлении управляющего соединения. Такая попытка приведет к тому, что вызов будет отвергнут. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) равна 10. Возможности носителя (SCCRP, SCCRQ) AVP возможностей носителя, тип атрибута - 4, предоставляют партнеру указание на типы носителя, поддерживаемые аппаратным интерфейсом отправителя для исходящих вызовов. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 10. Поле значения атрибута для AVP возможности носителя Это 32-битная маска, с двумя определенными битами. Если бит A =1, поддерживается аналоговый доступ. Если бит D =1, поддерживается цифровой доступ. LNS не должен запрашивать исходящих вызовов, специфицирующих значение в AVP типа носителя для приборов, неуказанных в AVP типа носителя, полученных от LAC при установлении управляющего соединения. Такая попытка приведет к тому, что вызов будет отвергнут. Эти AVP должны присутствовать, если отправитель может осуществлять исходящие вызовы, когда это требуется. Заметим, что LNS, который не может работать как LAC, а также не поддерживает оборудование для обработки входящих и исходящих вызовов, должен установить биты A и D этого AVP равными 0, или не должен вообще посылать AVP. LNS, который может работать в качестве LAC, и направлять исходящие вызовы, должен устанавливать биты A или D так, как это нужно. Присутствие этого сообщения не гарантирует того, что данный исходящий вызов будет направлен отправителем, если это потребуется, хотя такая возможность и существует. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) равна 10. Арбитр конфликта (Tie Breaker (SCCRQ)) AVP арбитра конфликта, тип атрибута - 5, указывает, что отправитель желает иметь один туннель между заданной парой LAC-LNS. Значение Tie Breaker характеризуется 8-октетным кодом, который используется для выбора одного туннеля, когда LAC и LNS требуют формирования туннеля одновременно. Получатель SCCRQ должен проверить, был ли послано партнеру SCCRQ и, если это так, должен сравнить свое значение Tie Breaker с полученным. Более низкое значение "wins" и "loser" должно вызвать молчаливую ликвидацию туннеля. В случае, когда код арбитра присутствует на обеих сторонах и значения равны, обе стороны должны ликвидировать туннели. Если получен tie breaker, а невыполненный просроченный SCCRQ не имеет значения tie breaker, инициатор, который включает AVP Tie Breaker "выигрывает". Если ни одна из сторон не посылает Tie Breaker, тогда открываются два туннеля. Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этого AVP должен быть равен 0. Длина этой AVP равна 14. Фирменная версия (Firmware Revision) (SCCRP, SCCRQ) Фирменная версия AVP, тип атрибута 6, указывает на фирменную версию прибора, пославшего сообщение. Поле фирменная версия имеет 2 октета и представляется целым числом без знака, закодированным в формате, который определяется фирмой. Для приборов, которые не имеют кода фирменной версии (универсальные ЭВМ, где, например, работают программные модули L2TP), вместо этого может быть сообщена модификация программных модулей L2TP. Эта AVP может быть скрыта (H-бит может быть равен 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 8. Имя ЭВМ (SCCRP, SCCRQ) AVP имени ЭВМ, тип атрибута 7, указывает на имя ЭВМ, реализующей функцию LAC или LNS. Имя ЭВМ имеет переменную длину, но должно иметь, по крайней мере, один октет. Это имя должно быть максимально уникальным; для ЭВМ, участвующих в DNS [RFC1034], следует выбирать полное имя домена. Эта AVP не должна быть скрыта (H-бит должен быть 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 6 плюс длина имени ЭВМ. Имя производителя (SCCRP, SCCRQ) AVP имени производителя, тип атрибута 8, содержит специфическую для производителя строку, которая характеризует тип используемого LAC или LNS. Имя производителя представляет собой строку октетов произвольной длины. Для обеспечения читаемости текст этой AVP должен быть представлен с помощью символьного набора UTF-8 на языке, выбранном по умолчанию [RFC2277]. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для данной AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина имени производителя. ID, присвоенное туннелю (SCCRP, SCCRQ, StopCCN) AVP ID, присвоенного туннелю, тип атрибута 9, несет в себе ID, присвоенное туннелю отправителем. ID, присвоенное туннелю, содержит в себе 2-октетное целое неравное нулю число без знака. AVP ID, присвоенное туннелю, определяет код, используемый при мультиплексировании и демультиплексировании в случае работы с несколькими туннелями между LNS и LAC. Партнер L2TP должен помещать этот код в поле заголовка ID-туннеля всех управляющих и информационных сообщений, пересылаемых через туннель. Пока от партнера не получена AVP с присвоенным ID-туннеля, управляющие сообщения должны посылаться этому партнеру со значением ID-туннеля = 0. В управляющем сообщении StopCCN, AVP ID, присвоенного туннелю, должно быть тождественно AVP ID, присвоенного туннелю, посланному первым, позволяя партнеру идентифицировать соответствующий туннель, даже если сообщение StopCCN послано до получения AVP ID. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8. Размер приемного окна (Receive Window Size (SCCRQ, SCCRP)) Размер приемного окна AVP, тип атрибута 10, специфицирует размер приемного окна, которое предлагает удаленный партнер. Размер окна характеризуется 2-октетным целым числом без знака. Если размер окна отсутствует, партнер должен предполагать этот код равным 4. Удаленный партнер может послать специфицированный номер управляющего сообщения, прежде чем ожидать отклика. Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 8. Приглашение (Challenge (SCCRP, SCCRQ)) AVP приглашения, тип атрибута 11, указывает, что отправивший его партнер хочет аутентифицировать концы туннеля, используя CHAP-стиль аутентификационного механизма. Вызов содержит один или более октетов произвольной информации. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина приглашения (challenge). Отклик на приглашение (Challenge Response (SCCCN, SCCRP)) AVP отклика, тип атрибута 13, направляет ответ на полученное сообщение. Поле отклик содержит 16 октетов, соответствуя CHAP-стилю [RFC1994] отклика на вызов. Эта AVP должна присутствовать в SCCRP или SCCCN, если приглашение было получено в предыдущем SCCRQ или SCCRP. Для целей вычисления значения ID в CHAP-отклике используется код типа сообщения AVP для этого кадра (например, 2 для SCCRP, и 3 для SCCCN). Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 22. 4.4.4. AVP управления вызовом Q.931 код причины (CDN) AVP, тип атрибута 12, используется, чтобы предоставить дополнительную информацию в случае непреднамеренного разрыва соединения. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 11. Поле значения атрибута для AVP кода причины Q.931 В качестве кода причины присылается код Q.931, а в качестве сообщения причины - сообщение Q.931 (например, DISCONNECT), ассоциированное с кодом причины. Оба кода присылаются в их исходных кодировках ITU [DSS1]. Дополнительный ASCI-текст сообщения-рекомендации может быть включен (присутствие определяется с помощью кода длины AVP) для дальнейшего уточнения причины отсоединения. Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 9, плюс размер сообщения Advisory. ID, присвоенное сессии (CDN, ICRP, ICRQ, OCRP, OCRQ) AVP ID, присвоенного сессии, тип атрибута 14, содержит ID, присвоенное сессии отправителем сообщения. ID, присвоенное сессии, представляет собой 2-октетное целое, ненулевое число без знака. AVP ID, присвоенного сессии, определяет код, который используется для мультиплексирования и демультиплексирования данных, посылаемых через туннель между LNS и LAC. Партнер L2TP должен поместить этот код в поле заголовка ID-сессии всех управляющих и информационных сообщений, которые пересылаются по туннелю в рамках данной сессии. До того как от партнера придет AVP ID, присвоенного сессии, управляющие сообщения должны посылаться партнеру с ID-сессии, равным нулю. В управляющем сообщении CDN, используется первое AVP ID-сессии, полученное партнером, позволяя партнеру идентифицировать соответствующий туннель, даже если CDN послано до получения ID, присвоенное сессии. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8. Порядковый номер вызова (ICRQ, OCRQ) AVP порядкового номера вызова, тип атрибута 15, несет в себе идентификатор, присвоенный данному вызову LAC или LNS. Порядковый номер вызова представляет собой 32-битовый код. Порядковый номер вызова предназначен для удобного административного указателя для обоих концов туннеля, когда необходимо проанализировать причину отказа. Порядковые номера вызова должны быть монотонно возрастающими числами, которые должны быть уникальными для достаточно большого периода времени для всех соединенных LNS и LAC. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10. Максимальный BPS (OCRQ) AVP максимального BPS, тип атрибута 16, характеризует минимальную приемлемую скорость передачи канала для данного вызова. Максимальный BPS представляет собой 32-битовый код, характеризующий скорость передачи в битах в секунду. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10. Максимальный BPS (OCRQ) AVP максимального BPS, тип атрибута 17, характеризует максимальную приемлемую скорость канала для данного вызова. Максимальный BPS представляет собой 32-битный код, характеризующий скорость передачи в битах в секунду. Эта AVP может быть скрытым (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) этого AVP равна 10. Тип носителя (ICRQ, OCRQ) AVP типа носителя, тип атрибута 18, характеризует тип носителя для входящего или исходящего вызовов. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 12. Поле значения атрибута для AVP типа носителя Тип носителя представляет собой 32-битовую маску, которая характеризует возможности несущей среды для вызова (ICRQ) или требования к среде для данного вызова (OCRQ). Если бит A=1, то вызов относится к аналоговому каналу. Если бит D=1, то вызов относится к цифровому каналу. Могут быть установлены оба бита, что может означать, что тип канала не определен, или допустима работа, как с аналоговым, так и цифровым каналами. Биты в поле значение данной AVP должны устанавливаться LNS для OCRQ, если они были установлены в AVP возможностей носителя, полученной от LAC в период установления управляющего соединения. Можно не устанавливать ни A, ни D-биты в ICRQ. Такая установка может означать, что вызов не был получен по физическому каналу (например, если LAC и PPP находятся в той же подсистеме). Эта AVP может быть скрыта (H-бит может быть 0 или 1). M-бит этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10. Тип кадрового обмена (ICCN, OCCN, OCRQ) AVP типа кадрового обмена, тип атрибута 19, характеризует тип кадров для входящих и исходящих вызовов. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 13. Поле значения атрибута для AVP типа кадрового обмена Тип кадрового обмена представляет собой 32-битовую маску, которая указывает тип кадрового обмена PPP, запрошенный для OCRQ, или тип кадрового обмена PPP, согласованный для OCCN или ICCN. Тип кадрового обмена может быть использован как указание PPP на LNS, какую из канальных опций использовать для согласования с LCP [RFC1662]. Бит A указывает на асинхронный обмен кадрами. Бит S указывает на синхронный обмен кадрами. Для OCRQ могут быть установлены оба бита, что будет означать допустимость обоих типов кадрового обмена. Биты в поле значение этой AVP должны устанавливаться только LNS для OCRQ, если они были установлены в AVP возможностей кадрового обмена, полученной от LAC в процессе установления управляющего соединения. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10. Вызванный номер (Called Number (ICRQ, OCRQ)) AVP вызванного номера, тип атрибута 21, характеризует телефонный номер, куда посылается вызов для OCRQ. Вызванный номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера. Вызывающий номер (Calling Number (ICRQ)) AVP вызывающего номера, тип атрибута 22, содержит телефонный номер входящего вызова. Вызывающий номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера. Субадрес (ICRQ, OCRQ) AVP субадреса, тип атрибута 23, несет в себе дополнительную информацию по вызову. Субадрес является ASCII-строкой. Может быть, необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина субадреса. Скорость канала (Tx) (Connect Speed (ICCN, OCCN)) AVP скорости канала (Tx) BPS, тип атрибута 24, характеризует быстродействие устройства, выбранного для попытки установления соединения. Скорость канала (Tx) BPS содержит 4 октета и характеризует скорость обмена в битах в секунду. Когда присутствует опционная AVP скорости соединения Rx, значение этой AVP представляет быстродействие канала с точки зрения LAC (например, скорость передачи данных, передаваемых от LAC в удаленную систему). Когда опционная AVP скорости соединения Rx отсутствует, быстродействие канала между удаленной системой и LAC предполагается симметричным и представляется одной величиной этой AVP. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10. Скорость соединения Rx (Connect Speed (ICCN, OCCN)) AVP скорости соединения Rx, тип атрибута 38, представляет скорость канала с точки зрения LAC (например, информация, передаваемая от удаленной системы в LAC). Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 14. Поле значения атрибута для AVP скорости соединения Rx BPS имеет 4 октета, характеризующие скорость обмена в битах в секунду. Присутствие этой AVP означает, что быстродействие канала может быть асимметричным с учетом скорости передачи, заданной в AVP скорости соединения Rx. Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10. ID физического канала (ICRQ, OCRP) AVP ID физического канала, тип атрибута 25, представляет код физического канала, присвоенный ему производителем, и используемый при вызове. ID физического канала имеет 4 октета и служит только для целей регистрации. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10. ID частной группы (ICCN) AVP ID частной группы, тип атрибута 37, используется LAC для индикации того, что этот вызов ассоциируется с определенной группой клиентов. ID частной группы представляет собой строку октетов произвольной длины. LNS может воспринимать PPP-сессию, а также сетевой трафик в рамках сессии специальным образом, определенным партнером. Например, если LNS соединен с несколькими частными сетями, использующими незарегистрированные адреса, эта AVP может быть включена LAC, чтобы индицировать, что данный вызов должен быть ассоциирован с одной из частных сетей. ID частной группы представляет собой строку, соответствующую таблице в LNS, которая определяет конкретные характеристики выбранной группы. LAC может определить ID частной группы из отклика RADIUS, локальной конфигурации, или некоторых других источников. Эта AVP может быть скрытой (H-бит может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина ID частной группы. Необходима нумерация (Sequencing Required (ICCN, OCCN)) AVP Sequencing Required, тип атрибута 39, сообщает LNS, что порядковые номера должны всегда присутствовать в информационном канале. Эта AVP не имеет поля значения атрибута. Эта AVP не должна быть скрытой (H-бит должен быть 0). M-бит этой AVP должен быть равен 1. Длина этой AVP равна 6. 4.4.5. AVP прокси LCP и аутентификации LAC может откликнуться на вызов и согласовать LCP с удаленной системой, возможно для того чтобы установить идентичность системы. В этом случае, эти AVP могут быть включены для индикации свойств канала, которые запросила удаленная система в исходном состоянии, свойства, согласованные удаленной системой и LAC после согласования, а также аутентификационная информация PPP, полученная LAC. Эта информация может быть использована, чтобы инициировать PPP LCP и аутентификационные системы в LNS, позволяя PPP продолжить работу без повторного согласования параметров с LCP. LCP CONFREQ, полученный в исходном состоянии (ICCN) В AVP, полученного в исходном состоянии LCP CONFREQ, тип атрибута 26, предоставляет LNS исходное сообщение CONFREQ, полученное LAC от партнера PPP. LCP CONFREQ является копией тела полученного исходного CONFREQ, начиная с первой опции тела сообщения LCP. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ. Последний посланный LCP CONFREQ (ICCN) В AVP последнего посланного LCP CONFREQ, тип атрибута 27, предоставляет LNS последнего CONFREQ, посланного LAC партнеру PPP. LCP CONFREQ является копией тела финального CONFREQ, посланного клиенту с целью завершения LCP-согласования, начиная с первой опции тела LCP-сообщения. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ. Последний полученный LCP CONFREQ (ICCN) AVP последнего полученного LCP CONFREQ, тип атрибута 28, предоставляет LNS последнего CONFREQ, полученного концентратором LAC от PPP-партнера. LCP CONFREQ является копией тела последнего CONFREQ, полученного от клиента с целью завершения процедуры согласования LCP, начиная с первой опции тела LCP-сообщения. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ. Тип прокси Authen (ICCN) AVP типа прокси Authen, тип атрибута 29, определяет, должна ли использоваться прокси аутентификация. Тип Authen представляет собой 2-октетное целое число без знака. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 8. Определенные значения типа Authen: 0 - Зарезервировано Эта AVP должна присутствовать, если должна использоваться прокси аутентификация. Если она отсутствует, тогда предполагается, что этот партнер не может выполнить прокси аутентификацию, необходимую для повторного запуска фазы аутентификации в LNS, если клиент уже вошел в эту фазу с LAC (который может быть определен AVP Proxy LCP, если имеется). Далее описаны соответствующие AVP для каждого типа аутентификации. Имя прокси Authen (ICCN) AVP имени прокси Authen, тип атрибута 30, специфицирует имя аутентифицируемого клиента при использовании прокси аутентификации. Имя Authen является строкой октетов произвольной длины. Оно содержит имя, специфицированное в отклике аутентификации клиента. Эта AVP должна присутствовать в сообщениях, содержащих AVP типа Proxy Authen с типом Authen 1, 2, 3 или 5. Может быть, желательно применить AVP-сокрытие для защиты имени, представленного открытым текстом. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 6 плюс длина имени. Приглашение прокси Authen (ICCN) AVP приглашения прокси Authen, тип атрибута 31, специфицирует приглашение, посланное LAC партнеру PPP при использовании прокси аутентификации. Приглашение представляет собой строку из одного или более октетов. Эта AVP должна присутствовать для типов прокси Authen 2 и 5. Поле приглашения содержит приглашение CHAP, предлагаемое LAC клиенту. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6, плюс длина приглашения. ID прокси Authen (ICCN) AVP ID прокси Authen, тип атрибута 32, специфицирует код ID PPP-аутентификации, которая реализуется между LAC и PPP-партнером, когда используется прокси аутентификация. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 15. Поле значения атрибута для AVP ID прокси Authen ID представляет собой 2-октетное целое число без знака, старший октет которого должен быть равен нулю. AVP прокси Authen ID должна присутствовать для типов Proxy authen 2, 3 и 5. Для 2 и 5, поле ID содержит значение ID-байта переданное LAC клиенту в его приглашении (Challenge). Для 3 - это значение идентификатора Authenticate-Request. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Отклик прокси Authen Response (ICCN) AVP отклика прокси Authen, тип атрибута 33, специфицирует отклик аутентификации PPP, полученный LAC от PPP-партнера, когда используется прокси аутентификация. Отклик представляет собой строку октетов произвольной длины. Эта AVP должна присутствовать для типов прокси authen 1, 2, 3 и 5. Поле отклика содержит отклик клиента на приглашение. Для типов прокси authen 2 и 5, это поле содержит значение отклика, полученное LAC. Для типов 1 или 3, оно несет в себе открытый текст пароля, полученного LAC от клиента. В случае паролей с открытым текстом рекомендуется AVP-сокрытие. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина отклика. 4.4.6. AVP статуса вызова Ошибки вызова (WEN) AVP ошибок вызова, тип атрибута 34, используется LAC для посылки LNS информации об ошибке. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 16. Поле значения атрибута для AVP ошибок вызова Определены следующие поля:
Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 32. ACCM (SLI) AVP ACCM, тип атрибута 35, используется LNS, чтобы проинформировать LAC о ACCM, согласуемом LNS с PPP-партнером. Поле значения атрибута для этого AVP имеет следующий формат:
Рис. 17. Поле значения атрибута для AVP ACCM Посланное ACCM и полученное ACCM имеют по 4 октета, перед которыми размещаются 2 октета зарезервированного количества. Значение посланного ACCM должно использоваться LAC для обработки пакетов, которые он отправляет через канал. Значение полученного ACCM должно использоваться LAC для обработки пакетов, которые он получает через канал. Значения по умолчанию, используемые LAC для обоих этих полей равны 0xFFFFFFFF. LAC должен учитывать значения этих полей, если только нет конфигурационной информации, которая указывает, что запрошенная маска должна быть модифицирована, чтобы разрешить операцию. Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 16. 5. Протокольные операции Необходимая процедура установления PPP-сессии туннелирования L2TP включает в себя два этапа:
Туннель и соответствующий управляющий канал должны быть сформированы до инициализации входящего или исходящего вызовов. L2TP-сессия должна быть реализована до того, как L2TP сможет передавать PPP-кадры через туннель. В одном туннеле могут существовать несколько сессий между одними и теми же LAC и LNS.
Рис. 18. PPP-туннелирование 5.1. Установление контрольного соединения Управляющее соединение является первичным, которое должно быть реализовано между LAC и LNS, прежде чем запускать сессию. Установление управляющего соединения включает в себя безопасную идентификацию партнера, а также определение версии L2TP, возможностей канала, кадрового обмена и т.д.. Для установления управляющего соединения осуществляется обмен тремя сообщениями. Типичным является ниже приведенный обмен: LAC или LNS LAC или LNSSCCRQ ->
SCCCN ->
Если в очереди нет больше сообщений для партнера, посылается ZLB ACK. 5.1.1. Аутентификация туннеля L2TP включает в себя простую, опционную, CHAP-подобную [RFC1994] систему аутентификации туннеля в процессе установления \управляющего соединения. Если LAC или LNS хочет идентифицировать партнера, с которым контактирует или контактировал посредством AVP приглашения, включенного в SCCRQ или SCCRP-сообщения. Если в SCCRQ или SCCRP получена AVP приглашения, AVP отклика приглашения должна быть послана в следующем SCCRP или SCCCN, соответственно. Если ожидаемый отклик партнера не соответствует полученному, установление туннеля должно быть запрещено. При участии в аутентификации туннеля LAC и LNS должны обладать общим секретным кодом. Это тот же секретный код, который использовался для AVP-сокрытия (смотри раздел 4.3). 5.2. Установление сессии После успешного установления управляющего соединения, могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами. 5.2.1. Установление входящего вызова Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен: LAC LNS
Если в очереди нет больше сообщений для партнера, посылается ZLB ACK. 5.2.2. Установление исходящего вызова Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен: LAC LNS
(Выполнить операцию вызова) OCCN ->
Если в очереди нет больше сообщений для партнера, посылается ZLB ACK. 5.3. Переадресация кадров PPP Когда туннель сформирован, PPP-кадры от удаленной системы, получаемые LAC, освобождаются от CRC, канальных заголовков, и т.д., инкапсулированных в L2TP, и переадресуются через соответствующий туннель. LNS получает L2TP-пакет, и обрабатывает инкапсулированный PPP-кадр, как если бы он был получен через локальный интерфейс PPP. Отправитель сообщения, ассоциированный с определенной сессией и туннелем, помещает ID сессии и туннеля (специфицированные партнером) в соответствующие поля заголовка всех исходящих сообщений. Таким способом, PPP-кадры мультиплексируются и демультиплексируются через общий туннель для данной пары LNS-LAC. Для заданной пары LNS-LAC может быть реализовано несколько туннелей, а для любого туннеля несколько сессий. Значение 0 для ID-сессии и ID-туннеля является зарезервированным и не должно использоваться в качестве ID-сессии или ID-туннеля. Для случаев, когда ID-сессии еще не присвоен партнером (т.e., в процессе установления новой сессии или туннеля), поле ID-сессии должно содержать 0, а для идентификации сессии должна использоваться AVP ID-сессии сообщения. Аналогично, для случаев, когда ID-туннеля еще не присвоен партнером, ID-туннеля должен быть присвоен 0, а для идентификации туннеля должна использоваться AVP ID-туннеля. 5.4. Использование порядковых номеров в канале данных Порядковые номера определены в заголовке L2TP для управляющих сообщений и опционно для информационных (смотри раздел 3.1). Они используются для организации надежной транспортировки управляющих сообщений (смотри раздел 5.8) и опционно информационных сообщений. Каждый партнер поддерживает отдельную нумерацию для управляющего соединения и для каждой информационной сессии в пределах туннеля. В отличие от канала управления L2TP, информационный канал L2TP не использует нумерацию сообщений для повторной пересылки. Скорее информационные сообщения могут использовать порядковые номера для детектирования потерь пакетов и/или восстановления исходной последовательности пакетов, которые могут быть перемешаны при транспортировке. LAC может потребовать, чтобы порядковые номера присутствовали в информационных сообщениях, посредством AVP необходимого упорядочения (смотри раздел 4.4.6). Если эта AVP присутствует при установлении сессии, порядковые номера должны присутствовать всегда. Если эта AVP отсутствует, упорядочивание сообщений находится под управлением LNS. Сервер LNS управляет разрешением и запрещением использования порядковых номеров путем посылки информационных сообщений с или без порядковых номеров на протяжении всей сессии. Таким образом, если LAC получает информационное сообщение без порядкового номера, он должен прекратить посылку сообщений с порядковыми номерами. Если LAC получает информационное сообщение с порядковым номером, он должен начать посылку информационных сообщений с порядковыми номерами. Если LNS разрешает нумерацию сообщений после предыдущего запрещения в ходе сессии, порядковые номера устанавливаются в соответствии с состоянием их последнего применения. LNS может инициировать запрет нумерации сообщений в любое время в ходе сессии (включая первое информационное сообщение). Рекомендуется, чтобы для соединений, где возможна потеря или изменение порядка пакетов, нумерация сообщений была всегда разрешена. Запрещение нумерации возможно, только когда риск ошибки считается приемлемым. Например, если PPP-сессия при туннелировании не использует каких-либо посторонних протоколов или сжатия данных и работает только с IP (как это определено в ходе процедуры инициализации), тогда LNS может запретить нумерацию пакетов так как IP сам следит за их порядком. 5.5. Keepalive (Hello) Механизм keepalive используется L2TP, для того чтобы разделять простои туннеля от длительных периодов отсутствия управления или информационной активности в туннеле. Это выполняется путем введения управляющих сообщений Hello (смотри раздел 6.5) после специфицированного периода времени, истекшего с момента последнего получения управляющего сообщения через туннель. Как для любого другого управляющего сообщения, при недоставке сообщения Hello туннель объявляется нерабочим, и система возвращается в исходное состояние. Механизм перевода транспортной среды в исходное состояние путем введения сообщений Hello гарантирует, что разрыв соединения между LNS и LAC будет детектирован на обоих концах туннеля. 5.6. Прерывание сессии Прерывание сессии может быть инициировано LAC или LNS и выполняется путем посылки управляющего сообщения CDN. После того как последняя сессия прервана, управляющее соединение может быть также разорвано. Ниже приводится типовой обмен управляющими сообщениями: LAC или LNS LAC или LNSCDN -> (Clean up)
5.7. Разрыв контрольного соединения Разрыв контрольного соединения может быть инициирован LAC или LNS и выполняется путем посылки одного управляющего сообщения StopCCN. Получатель StopCCN должен послать ZLB ACK, чтобы подтвердить получение сообщения, и поддерживает состояние управляющего соединения на уровне достаточном для корректного приема StopCCN, а также повторения цикла, если ZLB ACK потеряно. Рекомендуемое время повторения цикла равно 31 секунде (смотри раздел 5.8). Ниже приводится типовой обмен управляющими сообщениями: LAC или LNS LAC или LNS
Программа может ликвидировать туннель и все сессии туннеля путем посылки StopCCN. Таким образом, не нужно прерывать каждую сессию, если разорван туннель. 5.8. Надежная доставка управляющих сообщений L2TP обеспечивает нижний уровень надежного транспорта для всех управляющих сообщений. Поля Nr и Ns заголовка управляющего сообщения (смотри раздел 3.1) относятся к этому транспорту. Функции верхнего уровня L2TP не занимаются повторной пересылкой или упорядочением управляющих сообщений. Надежный управляющий канал обеспечивается за счет специального протокола, например, TCP, поддерживающего повторную пересылку управляющих сообщений и контроль перегрузки. Каждый партнер поддерживает независимую нумерацию сообщений для управляющего канала в туннеле. Порядковые номера сообщений Ns начинаются с 0. Каждое последующее сообщение имеет номер на 1 больше, чем предыдущее. Номер по порядку, таким образом, является простым счетчиком, работающим по модулю 65536. Порядковый номер в заголовке полученного сообщения рассматривается меньше или равным последнему полученному числу, если его значение лежит в интервале между последним полученным кодом и предыдущими 32767 включительно. Например, если последний полученный номер был равен 15, тогда сообщения с порядковыми номерами 0 - 15, а также 32784 - 65535, будут рассматриваться как сообщение с меньшим или равным номером. Такое сообщение будет рассматриваться как дубликат уже полученного и не будет обрабатываться. Однако, для того чтобы гарантировать, что все сообщения подтверждены корректно (в частности в случае потери сообщения ZLB ACK), получение сообщения-дубликата должно быть подтверждено. Это подтверждение может быть реализовано косвенно, или непосредственно через ZLB ACK. Все управляющие сообщения в пространстве номеров занимают одну нишу, за исключением подтверждения ZLB. Таким образом, Ns не инкрементируется после посылки сообщения ZLB. Номер последнего полученного сообщения, Nr, используется для подтверждения сообщений, принятых L2TP-партнером. Этот код должен содержать порядковый номер сообщения, которые партнер ожидает получить следующим (например, последний Ns сообщения (non-ZLB) плюс 1, по модулю 65536). В то время как Nr в полученном ZLB используется для удаления сообщений из локальной очереди сообщений, ждущих imes повторной передачи в локальной очереди (смотри ниже), Nr следующего сообщения не должен обновляться при получении Ns ZLB. Протокол надежной доставки принимающего партнера ответственен за проверку того, что управляющие сообщения доставлены на верхний уровень в правильном порядке и без дублирования. Сообщения, пребывающие в неверном порядке, могут быть занесены в очередь для последующей корректной доставки, когда пропущенные сообщения будут получены, или они могут быть выброшены, что вынудит партнера послать их повторно. Каждый туннель поддерживает очередь управляющих сообщений, которые нужно передать его партнеру. Сообщение в начале очереди посылается с заданным значением Ns, и хранится до тех пор, пока не придет от партнера управляющее сообщение, в котором поле Nr указывает на то, что данное сообщение получено. Если в течение определенного времени (рекомендуемое значение равно 1 секунде) отклика не получено, сообщение посылается повторно. Повторно посылаемое сообщение имеет то же значение Ns, но величина Nr должна быть сделана равной номеру очередного ожидаемого сообщения. Каждая повторная посылка сообщения должна реализовываться по истечении задержки, величина которой возрастает экспоненциально от раза к разу. Таким образом, если первая повторная передача происходит спустя 1 секунду, следующая повторная передача может производиться по истечении 2 секунд, затем 4 секунд, и т.д.. Программная реализация может установить верхний предел на время между повторными пересылками сообщения. Этот предел должен быть не меньше 8 секунд. Если после нескольких повторных посылок, не зафиксировано никакого отклика от партнера, (рекомендуемое число попыток равно 5, но должно быть настраиваемым), туннель и все сессии должны быть аннулированы. Когда туннель закрывается не по причине обрыва соединения, состояние и механизм надежной доставки должны поддерживаться и работать в течение всего периода повторных передач. Механизм скользящего окна используется для передачи управляющих сообщений. Рассмотрим двух партнеров A & B. Предположим A задает размер приемного окна в сообщениях SCCRQ или SCCRP равным N. B при этом позволено иметь до N ожидающих подтверждения получения сообщений. Когда N послано, нужно ждать подтверждения, которое сдвинет окно, прежде чем посылать новое управляющее сообщение. Программная реализация может поддерживать приемное окно с размером 1 (т.e., посылать AVP размера приемного окна со значением 1), но должно воспринимать от своего партнера окна с шириной до 4 (например, имеет возможность послать 4 сообщения, прежде чем остановиться и ожидать отклика). Значение 0 для AVP размера приемного окна является недопустимым. При повторной передаче управляющих сообщений следует использовать медленный старт и окно подавления перегрузки. Рекомендуемая процедура для этого описана в приложении A . Партнер не должен отказываться подтверждать сообщения, в качестве меры управления потоком управляющих сообщений. Предполагается, что реализация L2TP способна работать с входными управляющими сообщениями, возможно реагируя с ошибками, отражающими невозможность выполнения запрашиваемых действий. В приложении B представлены примеры управляющих сообщений, подтверждений и повторных передач. 6. Протокольная спецификация контрольного соединения Следующие сообщения управляющего соединения используются для установления, ликвидации и поддержания L2TP-туннелей. Вся информация посылается в порядке, определенном для сети (старший октет первый). Любые "резервные" или "пустые" поля для обеспечения протокольной масштабируемости должны содержать 0. 6.1. Start-Control-Connection-Request (SCCRQ) Start-Control-Connection-Request (SCCRQ) является управляющим сообщением, используемым для инициализации туннеля между LNS и LAC. Оно посылается LAC или LNS в процессе установления туннеля. Следующие AVP должны присутствовать в SCCRQ: AVP типа сообщения (Message Type AVP) Следующие AVP могут присутствовать в SCCRQ: Возможности канала (Bearer Capabilities) 6.2. Start-Control-Connection-Reply (SCCRP) Start-Control-Connection-Reply (SCCRP) является управляющим сообщением, посланным в ответ на сообщение SCCRQ. SCCRP используется для индикации того, что SCCRQ было принято и установление туннеля должно быть продолжено. Следующие AVP должны присутствовать в SCCRP: Тип сообщения (Message Type) Следующие AVP могут присутствовать в SCCRP: Возможности несущего канала (Bearer Capabilities) 6.3. Start-Control-Connection-Connected (SCCCN) Start-Control-Connection-Connected (SCCCN) является управляющим сообщением, посылаемым в ответ на SCCRP. SCCCN завершает процесс установления туннеля.
6.4. Stop-Control-Connection-Notification (StopCCN) Stop-Control-Connection-Notification (StopCCN) является управляющим сообщением, посылаемым LAC или LNS для информирования своего партнера о том, что туннель закрывается (shutdown) и управляющий канал должен быть разорван. Кроме того, все активные сессии закрываются (без посылки каких-либо управляющих сообщений). Причина для отправки этого запроса указывается в AVP кода результата. Явно отклик на это сообщение не посылается, используется отклик ACK, который используется для обеспечения надежной связи для управляющего соединения транспортного уровня Следующие AVP должны присутствовать в StopCCN: Тип сообщения (Message Type) 6.6. Запрос входящего вызова ICRQ (Incoming-Call-Request) Incoming-Call-Request (ICRQ) является управляющим сообщением, посылаемым LAC к LNS, когда зарегистрирован входящий вызов. Это первое из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля. ICRQ используется для индикации того, что для данного вызова должна быть установлена сессия между LAC и LNS, и предоставляет LNS параметры сессии. LAC может отложить ответ на вызов, до тех пор пока он не получит ICRP от LNS, указывающий, что должна быть запущена сессия. Этот механизм позволяет LNS получить достаточно информации о вызове, прежде чем будет определено, следует ли на него отвечать. В качестве альтернативы LAC может ответить на вызов, согласовать аутентификацию LCP и PPP, и использовать информацию, полученную для выбора LNS. В этом случае, к моменту получения сообщения ICRP на вызов уже получен ответ; в этом случае LAC просто разыгрывает шаги "call indication" и "call answer". Следующие AVP должны присутствовать в ICRQ: Тип сообщения Следующие AVP могут присутствовать в ICRQ: Тип носителя (Bearer Type) 6.7. Отклик входящего вызова ICRP (Incoming-Call-Reply) Incoming-Call-Reply (ICRP) является управляющим сообщением, посылаемым LNS к LAC в ответ на полученное сообщение ICRQ. Он является вторым из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля. ICRP используется для индикации того, что ICRQ успешен, и для LAC, чтобы ответить на вызов, если это еще не было сделано. Оно позволяет также LNS индицировать необходимые параметры для L2TP-сессии. Следующие AVP должны присутствовать в ICRP: Тип сообщения (Message Type) 6.8. Incoming-Call-Connected (ICCN) Incoming-Call-Connected (ICCN) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение ICRP. Оно является третьим сообщением из трех сообщений обмена, используемых для установления сессий в пределах L2TP-туннеля. ICCN используется для индикации того, что ICRP принято, на вызов получен ответ, а L2TP-сессия должна перейти в состояние "установлена". Оно также предоставляет дополнительную информацию LNS о параметрах, используемых для вызова, на который получен ответ (параметры, которые не всегда быть доступны в момент посылки ICRQ). Следующие AVP должны присутствовать в ICCN: Тип сообщения (Message Type) Следующие AVP могут присутствовать в ICCN: Initial Received LCP CONFREQ 6.9. Запрос исходящего вызова OCRQ (Outgoing-Call-Request) Outgoing-Call-Request (OCRQ) является управляющим сообщением, посылаемым от LNS к LAC для индикации того, что необходимо осуществить исходящий вызов LAC. Оно является первым сообщением из трех, которые используются для установления сессии в пределах L2TP-туннеля. OCRQ используется для индикации того, что сессия для данного вызова между LNS и LAC установлена и предоставляет LAC параметры L2TP-сессии и вызова. LNS должен получить от LAC AVP Bearer Capabilities (возможностей носителя) на фазе установления туннеля, для того чтобы послать LAC исходящий вызов. Следующие AVP должны присутствовать в OCRQ: Тип сообщения (Message Type)
6.10. Отклик исходящего вызова OCRP (Outgoing-Call-Reply) Сообщение Outgoing-Call-Reply (OCRP) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение OCRQ. Оно является вторым из трех сообщений, которые используются при установлении сессии в L2TP-туннеле. OCRP используется для индикации того, что LAC может попытаться послать исходящий вызов и вернуть определенные параметры, относящиеся к попытке вызова. Следующие AVP должны присутствовать в OCRP: Тип сообщения (Message Type)
6.11. Outgoing-Call-Connected (OCCN) Сообщение Outgoing-Call-Connected (OCCN) является управляющим сообщением, посылаемым от LAC к LNS, следом за OCRP, и после того как исходящий вызов завершен. Это завершающее сообщение из трех, используемых при установлении сессии в пределах L2TP-туннеля. OCCN используется для индикации того, что результат запрошенного исходящего вызова положителен. Оно также предоставляет LNS информацию об определенных параметрах, полученных после реализации вызова. Следующие AVP должны присутствовать в OCCN: Тип сообщения (Message Type) Следующие AVP могут присутствовать в OCCN: Скорость обмена (Rx Connect Speed) 6.12. Call-Disconnect-Notify (CDN) Сообщение Call-Disconnect-Notify (CDN) является L2TP управляющим сообщением, посылаемым LAC или LNS с целью запроса разрыва соединения для определенного вызова в пределах туннеля. Его целью является информирование партнера о рассоединении и причине разрыва соединения. Партнер должен освободить все ресурсы, и не посылать сообщений о причине данной операции. Следующие AVP должны присутствовать в CDN: Message Type
6.13. WAN-Error-Notify (WEN) Сообщение WAN-Error-Notify является L2TP управляющим сообщением, посылаемым от LAC к LNS для индикации условий ошибки WAN (условия, которые реализовались в интерфейсе, поддерживающим PPP). Счетчики в этом сообщении являются накопительными. Это сообщение должно посылаться, только когда произошла ошибка, и не чаще чем раз в 60 секунд. Счетчики сбрасываются, когда реализуется новый вызов. Следующие AVP должны присутствовать в WEN: Тип сообщения (Message Type) 6.14. Set-Link-Info (SLI) Сообщение Set-Link-Info является управляющим сообщением L2TP, посланным от LNS к LAC для установления согласуемых опций PPP. Эти опции можно изменять в любое время на протяжении реализации вызова, таким образом, LAC должен быть способен обновлять свою собственную информацию вызова и поведение на протяжении активной PPP-сессии. Следующие AVP должны присутствовать в SLI: Тип сообщения (Message Type) 7. Машины состояний управляющего соединения Управляющие сообщения, определенные в разделе 6 пересылаются в соответствии с таблицами состояний, описанными в данном разделе. Таблицы определены для входящих вызовов, исходящих вызовов, а также для инициации самого туннеля. Таблицы состояний не задают таймауты и поведение при повторной передаче, так как это определяется механизмами, рассмотренными в секции 5.8. 7.1. Протокольные операции контрольного соединения Этот раздел описывает работу различных функций управляющего соединения L2TP и сообщения управляющего соединения, которые используются для их поддержания. Получение некорректного или неправильно сформатированного управляющего сообщения должно регистрироваться соответствующим образом, а управляющее соединение возвращается в исходное состояние, чтобы гарантировать восстановление заданного состояния. Управляющее соединение может затем перезапуститься инициатором операции. Некорректное управляющее сообщение определяется как сообщение, которое содержит тип сообщения, помеченное как обязательное (смотри раздел 4.4.1) и неизвестное программе управляющее сообщение, которое получено в правильной последовательности (например, в ответ на SCCRQ послано SCCCN). Примеры управляющих сообщений с некорректным форматом включают те, которые имеют неверное значение в своем заголовке, содержат AVP, сформированную некорректно или чье значение находится вне допустимых пределов, или сообщение, которое не имеет необходимого AVP. Управляющее сообщение с некорректным заголовком должно быть отброшено. Управляющее сообщение с некорректным AVP должно проверить M-бит для этого AVP, чтобы определить, является ли ошибка исправимой или нет. Неверно сформатированное, но исправимое необязательное (M-бит равен нулю) AVP в управляющем сообщении должно рассматриваться, также как нераспознанное необязательное AVP. Таким образом, если получена AVP с неверным форматом и битом M=1, сессия или туннель должны быть разорваны с соответствующим кодом результата или ошибки. Если M-бит не равен 1, AVP должно игнорироваться (за исключением записи об ошибке в местном журнале). Это не должно рассматриваться, как разрешение посылать неверно сформатированные AVP, а лишь как указание на то, как реагировать на неверно сформатированное сообщение в случае его получения. Невозможно перечислить все возможные ошибки в сообщениях и дать совет, как с ними обходиться. Примером исправимой неверно сформатированной AVP может быть случай, когда получена AVP скорости соединения Rx, атрибут 38, с полем длина 8, а не 10 и BPS с двумя, а не четырьмя октетами. Так как Rx Connect Speed не является обязательным, такое условие не может рассматриваться как катастрофическое. Как таковое, управляющее сообщение должно быть воспринято, как если бы AVP не было получено (за исключением записи в локальный журнал ошибок). В нескольких случаях в последующих таблицах, посылается протокольное сообщение, а затем случается "сброс". Заметим, что, несмотря на ликвидацию туннеля одним из партнеров, в течение определенного времени механизм надежной доставки должен быть сохранен (смотри раздел 5.8) вплоть до окончательного закрытия туннеля. Это позволяет сообщениям управления туннеля надежно доставляться партнеру. 7.2. Состояния контрольного соединения Протокол управляющего соединения L2TP не отличим от LNS и LAC, но различен для отправителя и получателя. Партнером инициатором является тот, кто первым формирует туннель (в конфликтной ситуации, это победитель). Так как LAC или LNS может быть инициатором, может произойти столкновение. Смотри Tie Breaker AVP в разделе 4.4.3, где описано разрешение такого конфликта. 7.2.1. Установление контрольного соединения
Состояниями, ассоциированными с LNS или LAC для установления управляющего соединения, являются: Idle (пассивно) Инициатор и получатель начинают функционирование из этого состояния. Инициатор посылает SCCRQ, в то время как получатель остается в пассивном состоянии вплоть до получения SCCRQ. wait-ctl-reply (ожидание управляющего отклика) Инициатор проверяет, не поступил ли запрос на установление еще одного соединения от того же самого партнера, и если это так, реагирует на столкновение, как это описано в разделе 5.8. Когда получено SCCRP, оно проверяется на совместимость версии. Если версия отклика ниже версии посланного запроса, должна использоваться более старая (низшая) версия. Если версия отклика более ранняя, и она поддерживается, инициатор переходит в состояние "установлено". Если версия более ранняя и не поддерживается, партнеру должно быть послано StopCCN, а инициатор переходит в исходное состояние и разрывает туннель. wait-ctl-conn (ожидание управляющего соединения) Состояние, когда ожидается SCCCN; после получения, проверяется отклик приглашения. Туннель оказывается установленным, или разорванным, если не прошла аутентификация. Established (установлено) Установленное соединение может быть аннулировано по местным причинам или в результате получения Stop-Control-Connection-Notification. В случае местного разрыва инициатор должен послать Stop-Control-Connection-Notification и ликвидировать туннель. Если инициатор получает Stop-Control-Connection-Notification, он должен разорвать туннель. 7.3. Временные соображения В силу того, что телефонная связь по своей природе работает в реальном времени, как LNS, так и LAC должны быть реализованы по многопроцессной схеме, такой чтобы сообщения, относящиеся к нескольким вызовам, не блокировались. 7.4. Входящие вызовы Сообщение Incoming-Call-Request генерируется LAC, когда зарегистрирован входящий вызов (например, звонки в телефонной линии). LAC выбирает ID-сессии и порядковый номер и индицирует тип носителя вызова. Модемы должны всегда индицировать аналоговый тип вызова. Вызовы ISDN должны индицировать цифровой тип вызова, когда доступно цифровое обслуживание и используется настройка скорости обмена, и аналоговый, если применен цифровой модем. Вызывающий номер, вызываемый номер и субадрес могут быть включены в сообщение, если они доступны через телефонную сеть. Раз LAC посылает Incoming-Call-Request, он ждет отклика от LNS, но необязательно отвечает на вызов из телефонной сети. LNS может решить не воспринять вызов если:
Если LNS решает принять вызов, он откликается посылкой Incoming-Call-Reply. Когда LAC получает Incoming-Call-Reply, он пытается подключить вызов. Последнее сообщение о подключении от LAC к LNS указывает, что статус вызова для LAC и LNS должнен перейти в состояние "установлено". Если вызов завершается до того, как LNS успел принять его, LAC посылает Disconnect-Notify, чтобы индицировать эту ситуацию. Когда телефонный клиент вешает трубку, LAC посылает сообщение Call-Disconnect-Notify. Если LNS хочет аннулировать вызов, он посылает сообщение Call-Disconnect-Notify и ликвидирует свою сессию. 7.4.1. Состояния LAC входящих вызовов
Состояниями, ассоциированными с LAC, для входящих вызовов являются: idle LAC детектирует входящий вызов на одном из своих интерфейсов. Обычно это означает, что по аналоговой линии получены звонки или ISDN TE зарегистрировало входное сообщение Q.931 SETUP. LAC инициализирует свою машину состояния, формирующую туннель, и переходит в состояние ожидания подтверждения существования туннеля. wait-tunnel В этом состоянии сессия ожидает открытия соединения или верификации того, что туннель уже открыт. Как только получено уведомление о том, что туннель открыт, может быть начат обмен управляющими сообщениями сессии. Первым таким сообщением будет Incoming-Call-Request. wait-reply LAC получает CDN-сообщение, указывающее, что LNS не хочет воспринимать вызов и переходит назад в состояние idle (пассивен), или получает сообщение Incoming-Call-Reply, означающее, что вызов принят, LAC посылает сообщение Incoming-Call-Connected и переходит в состояние "установлен". established Через туннель передаются данные. Вызов может быть аннулирован после:
7.4.2. Состояния LNS входящих вызовов
Состояниями, ассоциированными с LNS для входящих вызовов являются: idle Получено сообщение Incoming-Call-Request. Если запрос неприемлем, посылается Call-Disconnect-Notify LAC и LNS остается в состоянии idle. Если сообщение Incoming-Call-Request приемлемо, посылается Incoming-Call-Reply. Сессия переходит в состояние wait-connect. wait-connect Если сессия все еще подключена к LAC, он посылает сообщение Incoming-Call-Connected LNS, который затем переходит в состояние "установлено". LAC может послать Call-Disconnect-Notify для индикации того, что источник входящего запроса не может быть подключен. Это может произойти, например, если пользователь телефона случайно устанавливает в LAC стандартный голосовой режим, что приводит прерыванию диалога с модемом. established Сессия завершается при получении сообщения Call-Disconnect-Notify от LAC или путем посылки Call-Disconnect-Notify. Сброс системы в базовое состояние происходит на обеих сторонах вне зависимости от действий инициатора операции. 7.5. Исходящие вызовы Исходящие вызовы инициируются LNS и заставляют LAC реализовать вызов. Для исходящих вызовов используется три сообщения: Outgoing-Call-Request, Outgoing-Call-Reply, и Outgoing-Call-Connected. LNS посылает Outgoing-Call-Request, специфицирующий телефонный номер партнера, субадрес и другие параметры. LAC должен реагировать на сообщение Outgoing-Call-Request откликом Outgoing-Call-Reply, так как LAC определяет, что имеется возможность реализовать вызов, который должен быть административно авторизован. Например, разрешено ли LNS осуществлять международные телефонные вызовы? Если для исходящего вызова осуществлено соединение, LAC посылает LNS сообщение Outgoing-Call-Connected, характеризующее окончательный результат попытки вызова. 7.5.1. Состояния LAC исходящих вызовов
Состояниями, ассоциированными с LAC, для исходящих вызовов являются: idle Если Outgoing-Call-Request получен с ошибкой, посылается отклик Call-Disconnect-Notify. В противном случае, выделяется физический канал и посылается Outgoing-Call-Reply. Производится исходящий вызов и LAC переходит в состояние wait-cs-answer. wait-cs-answer Если вызов не завершен или произошел таймаут ожидания завершения вызова, посылается Call-Disconnect-Notify с соответствующими кодами ошибки и происходит переход в состояние idle. Если устанавливается соединение с коммутацией каналов и зафиксирован обмен кадрами, посылается Outgoing-Call-Connected, отмечающий успешную реализацию вызова и LAC переходит в состояние "установлено". established Если LAC получил Call-Disconnect-Notify, вызов должен быть аннулирован через соответствующий механизм и сессия закрыта. Если вызов аннулирован клиентом или интерфейсом, через который был осуществлен вызов, должно быть послано LNS сообщение Call-Disconnect-Notify. Отправитель сообщения Call-Disconnect-Notify переходит в состояние idle. 7.5.2. Состояние исходящего вызова LNS
Состояниями, ассоциированными с LNS, для исходящих вызовов являются: idle, wait-tunnel Когда инициирован исходящий вызов, сначала создается туннель. Когда туннель создан, посылается сообщение Outgoing-Call-Request LAC и сессия переходит в состояние wait-reply. wait-reply Если получено Call-Disconnect-Notify, произошла ошибка, и сессия переводится в исходное состояние idle. Если получено сообщение Outgoing-Call-Reply, вызов находится в развитии и сессия переходит в состояние wait-connect. wait-connect Если получено Call-Disconnect-Notify, вызов не состоялся; сессия возвращается в исходное состояние idle. Если получено Outgoing-Call-Connected, вызов прошел, и сессия может осуществлять обмен данными. established Если получено Call-Disconnect-Notify, вызов был аннулирован по причине, указанной в кодах результата и причины; сессия возвращается в состояние idle. Если LNS решает завершить сессию, он посылает LAC сообщение Call-Disconnect-Notify и затем переводит сессию в исходное состояние idle. 7.6. Ликвидация туннеля Разрыв туннеля происходит в случае посылки партнером сообщения Stop-Control-Connection-Notification. Отправитель этого уведомления должен ждать определенное время отклика на это сообщение, прежде чем ликвидировать управляющую информацию, имеющую отношение к туннелю. Получатель этого уведомления должен послать подтверждение получения этого сообщения и затем ликвидировать управляющую информацию. Конкретная программная реализация может использовать определенный алгоритм принятия решения о разрыве управляющего соединения. Некоторые реализации могут оставить туннель открытым на некоторое время. Другие могут решить закрыть туннель немедленно после разрыва последнего соединения пользователей. 8. Реализация L2TP через специфическую среду Протокол L2TP является само документируемым, работающим поверх уровня, который служит для транспортировки. Однако, необходимы некоторые детали подключения к среде, для того чтобы обеспечить совместимость различных реализаций. 8.1. L2TP через UDP/IP L2TP использует зарегистрированный UDP-порт 1701 [RFC1700]. Весь L2TP-пакет, включая поле данных и L2TP-заголовок, пересылается внутри UDP-дейтограммы. Создатель L2TP-туннеля выбирает доступный UDP-порт (который может быть или не быть 1701), и посылает пакет по нужному адресу места назначения с номером порта 1701. Получатель выбирает свободный номер порта в своей системе (который может быть или не быть 1701), и посылает отклик инициатору по его номеру порта и адресу. Раз номера портов отправителя и получателя определены, они должны оставаться неизменными в течение всей жизни туннеля. Может происходить IP-фрагментация, так как L2TP-пакет путешествует через Интернет. Протокол L2TP не предпринимает каких-то специальных усилий, чтобы оптимизировать этот процесс. По умолчанию для любых реализаций L2TP должно быть активизировано контрольное суммирование UDP как для управляющих, так и информационных сообщений. Реализация L2TP может предоставить опцию, способную блокировать контрольное суммирование UDP-дейтограмм для информационных сообщений. Рекомендуется, чтобы контрольные суммы UDP были всегда активированы для управляющих сообщений. Порт 1701 используется как пакетами L2F [RFC2341], так и L2TP. Поле версия в каждом из заголовков может использоваться, чтобы отличить пакеты этих двух типов (L2F использует значение 1, а версия L2TP, описанная в этом документе, использует 2). Реализация L2TP, работающая в системе, которая не поддерживает L2F, должна отбрасывать все L2F-пакеты. Для PPP-клиентов, использующих туннель L2TP-поверх-UDP/IP, PPP-связь имеет возможность менять порядок или отбрасывать пакеты. В первом случае могут нарушаться протоколы, отличные от IP и использующие для транспортировки PPP. Во втором - могут нарушаться протоколы, в которых предполагается по пакетный контроль ошибок, такой как TCP со сжатием заголовков. Контроль порядка можно осуществить, используя номера информационных L2TP-сообщений, если какой-то протокол, транспортируемый через PPP-туннель, не способен справиться с изменением порядка пакетов. Молчаливое отбрасывание пакетов может оказаться проблематичным для некоторых протоколов. Если в PPP разрешена надежная доставка [RFC1663], никакой выше расположенный протокол не может столкнуться с потерей пакетов. Если в L2TP разрешена нумерация пакетов, L2TP может контролировать потерю пакетов. В случае LNS, PPP и L2TP стеки присутствуют в LNS, и потеря пакета может регистрироваться, как если бы пакет получен с неверной CRC. Когда клиенты LAC и PPP физически различны, возможна аналоговая сигнализация, реализуемая путем посылки PPP-клиенту пакета с неверной контрольной суммой. Заметим, что это сильно усложнит отладку канальных программ клиента, так как статистика клиента не сможет отличить истинные ошибки транспортной среды от ошибок, инициированных LAC. Эта техника нереализуема на аппаратном уровне. Если используется VJ-сжатие, и не разрешена ни надежная доставка в PPP, ни нумерация пакетов, каждый потерянный пакет будет приводить к вероятности 2-16 того, что сегмент TCP будет переадресован с неверным содержимым [RFC1144]. Там где вероятность потери велика, не следует использовать сжатие заголовков TCP-сегментов. 8.2. IP При работе в IP-среде протокол L2TP должен обеспечить UDP-инкапсуляцию, описанную в 8.1. Другие конфигурации (возможно соответствующие формату со сжатием заголовков) могут быть определены и доступны в качестве конфигурируемой опции. 9. Соображения безопасности Протокол L2TP сталкивается при своей работе с несколькими проблемами безопасности. Ниже рассмотрены некоторые подходы для решения этих проблем. 9.1. Безопасность на конце туннеля Концы туннеля могут опционно выполнять процедуру аутентификации друг друга при установлении туннеля. Эта аутентификация имеет те же атрибуты безопасности, что и CHAP, и обладает разумной защитой против атак воспроизведения и искажения в процессе установления туннеля. Этот механизм не реализует аутентификации при формировании туннеля; так как достаточно просто для злонамеренного пользователя, который наблюдает обмен в туннеле, ввести свои пакеты, когда аутентификация полностью завершена. Для реализации аутентификации LAC и LNS должны использовать общий секретный ключ. Каждая из сторон использует один и тот же ключ, когда выполняет роль аутентификатора и аутентифицируемого. Так как используется только один ключ, AVP аутентификации туннеля несут в себе разные значения полей в CHAP ID для вычисления дайджеста каждого сообщения, чтобы противостоять атакам воспроизведения. Assigned Tunnel ID и Assigned Session ID (смотри раздел 4.4.3) должны быть выбраны непредсказуемым образом. Такая методика препятствует деятельности хакеров, которые не имеют доступа к пакетам, которыми обмениваются LAC и LNS. 9.2. Безопасность пакетного уровня Обеспечение безопасности L2TP требует, чтобы транспортная среда могла обеспечить шифрование передаваемых данных, целостность сообщений и аутентификацию услуг для всего L2TP-трафика. Этот безопасный транспорт работает с пакетом L2TP в целом и функционально независим от PPP и протокола, вложенного в PPP. Как таковой, L2TP ответственен за конфиденциальность, целостность и аутентифицированность L2TP-пакетов внутри туннеля (LAC и LNS). 9.3. Безопасность от начала до конца Защищая поток L2TP-пакетов, так как это делает безопасный транспорт, мы защищаем данные, передаваемые по PPP-туннелю от LAC к LNS. Такая защита не должна рассматриваться как замена для безопасности точка-точка при передаче данных между ЭВМ или приложениями. 9.4. L2TP и IPsec При работе поверх IP, IPsec (безопасный IP) предоставляет безопасность на пакетном уровне за счет ESP и/или AH. Все управляющие и информационные пакеты L2TP в конкретном туннеле выглядят для системы Ipsec, как обычные информационные UDP/IP-пакеты. Помимо транспортной безопасности IP, IPsec определяет режим работы, который позволяет туннелировать IP-пакеты. Шифрование и аутентификация на пакетном уровне, выполняемые режимом туннеля IPsec и средства L2TP, поддержанные IPsec предоставляют эквивалентные уровни безопасности. IPsec определяет также средства контроля доступа, которые необходимы для приложений, поддерживающих IPsec. Эти средства позволяют фильтровать пакеты, на основе характеристик сетевого и транспортного уровней, таких как IP-адрес, порт, и т.д.. В модели L2TP-туннеля, аналогичная фильтрация выполняется на PPP-уровне или сетевом уровне поверх L2TP. Эти средства управления доступом на сетевом уровне могут быть реализованы в LNS за счет механизма авторизации, специфицированного производителем, или на сетевом уровне, используя транспортный режим IPsec точка-точка между взаимодействующими ЭВМ. 9.5. Аутентификация прокси PPP L2TP определяет AVP, которые могут пересылаться в процессе установления сессии с целью передачи PPP аутентификационной информации, полученной в LAC, для перепроверки в LNS (смотри раздел 4.4.5). Это предполагает полное доверие между LAC и LNS. Если LNS решит использовать прокси аутентификацию, она должна быть конфигурируема, требуя нового цикла PPP-аутентификации по инициативе LNS (который может включать или нет новый раунд согласования параметров с LCP). 10. Соображения IANA Этот документ определяет ряд "магических" числе, которые определяются IANA. Эта секция объясняет критерии, которые должна использовать IANA при присвоении дополнительных чисел в каждый из этих списков. Следующие субсекции описывают политику присвоения для пространства имен, определенных в данном документе. 10.1. Атрибуты AVP Как это определено в разделе 4.1, AVP содержат поля ID производителя, атрибута и значения. Для ID производителя значение 0 IANA поддерживает регистр присвоенных атрибутов, а в некоторых случаях и значений. Атрибуты 0-39 присвоены согласно тому, как это описано в разделе 4.4. Остальные значения доступны для присвоения при согласовании с IETF [RFC 2434]. 10.2. Значения типа сообщения AVP Как определено в разделе 4.4.1, AVP типа сообщения (тип атрибута 0) имеет значение поддерживаемое IANA. Значения 0-16 определены в разделе 3.2, остальные - могут присваиваться по согласованию с IETF [RFC 2434] 10.3. Значения результирующих кодов AVP Как это определено в разделе 4.4.2, результирующий код AVP (тип атрибута 1) содержит три поля. Два из них (поля кодов результата и ошибки) имеют значения, обслуживаемые IANA. 10.3.1. Значения поля кода результата AVP кода результата может быть включено в сообщения CDN и StopCCN. Допустимые значения поля кода результата AVP зависят от значения типа сообщения AVP. Для сообщения StopCCN, значения 0-7 определены в разделе 4.4.2; для сообщения StopCCN, значения 0-11 определены в том же разделе. Оставшиеся значения поля кода результата для обоих сообщений доступны для присвоения через согласование с IETF [RFC 2434]. 10.3.2. Значения поля кода ошибки Значения 0-7 определены в разделе 4.4.2. Значения 8-32767 доступны для присвоения через согласование с IETF [RFC 2434]. Оставшиеся значения поля кода ошибки доступны для присвоения в соответствии с алгоритмом "первый пришел - первым обслужен" [RFC 2434]. 10.4. Framing Capabilities & Bearer Capabilities AVP Framing Capabilities и Bearer Capabilities (определенные в разделе 4.4.3) содержат 32-битовые маски. Дополнительные биты могут быть определены через стандартную процедуру [RFC 2434]. 10.5. Значения типов прокси аутентификации AVP AVP типа прокси Authen (тип атрибута 29) имеет ассоциированное значение, поддерживаемое IANA. Значения 0-5 определены в разделе 4.4.5, оставшиеся значения доступны для присвоения по схеме "первым пришел - первым обслужен" [RFC 2434]. 10.6. Биты заголовка AVP Имеется 4 резервных бита в заголовке AVP. Дополнительные биты должны присваиваться через стандартную процедуру [RFC 2434]. 11. Ссылки
Хотя каждая из сторон указала максимальный размер окна приема, рекомендуется, чтобы при передаче управляющих пакетов использовался медленный старт и метод подавления перегрузки. Методы, описанные здесь, базируются на TCP-алгоритме подавления перегрузки, как это описано в разделе 21.6 книги "TCP/IP Illustrated", том I, написанной W. Richard Stevens [STEVENS]. Медленный старт и подавление перегрузки используют несколько переменных. Окно перегрузки (CWND) определяет число пакетов, которые отправитель может послать, не дожидаясь подтверждения. Размер CWND расширяется и сокращается так, как это описано ниже. Заметим, однако, что CWND никогда не должно превышать размера окна, полученного из AVP приемного окна (далее предполагается, что любое увеличение ограничивается размером приемного окна). Переменная SSTHRESH определяет, когда отправитель переходит от медленного старта к подавлению перегрузки. Медленный старт используется, когда CWND меньше SSHTRESH. Отправитель начинает работу с фазы медленного старта. Начальный размер CWND равен одному пакету, а уровень SSHTRESH в начальный момент определяется размером окна (полученным из AVP приемного окна). Отправитель передает один пакет и ждет подтверждения получения. Когда подтверждение получено, окно перегрузки увеличивается на единицу и становится равным двум. Во время медленного старта, размер CWND увеличивается на единицу при получении каждого ACK. Увеличение CWND на 1 при получении ACK приводит к удвоению CWND за время RTT, что эквивалентно экспоненциальному росту. Когда значение CWND достигает SSHTRESH, фаза медленного старта завершается и начинается подавление перегрузки. При подавлении перегрузки, CWND расширяется более медленно. В частности, оно увеличивается на 1/CWND для каждого полученного подтверждения ACK. Расширение окна на фазе подавления перегрузки является линейным, с увеличением CWND на 1 за время RTT. Когда происходит перегрузка (индицируемая повторной передачей пакета) половина CWND записывается в SSTHRESH, а CWND делается равным 1. Отправитель после этого возвращается в режим медленного старта. Приложение B: Примеры управляющих сообщений B.1: Установление туннеля Lock-step В этом примере, LAC формирует туннель, при этом реализуется обмен сообщениями в обоих направлениях. В этом примере показано, что окончательное подтверждение посылается в сообщении ZLB ACK. Альтернативой может быть подтверждение, пришедшее в сообщении, посланном в ответ на ICRQ или OCRQ, которые направляются стороной, инициировавшей формирование туннеля. LAC или LNSLNS или LAC
Nr: 1, Ns: 1
B.2: Потеря пакета и повторная передача Существующий туннель имеет новую сессию, запрошенную LAC. Пакет ICRP потерян и должен быть послан LNS повторно. Заметим, что потеря ICRP несет в себе две проблемы: это не только блокирует машину состояний высокого уровня, но и лишает LAC своевременного прихода подтверждения его ICRQ на нижнем уровне. LAC LNS
ICRQ -> Nr: 1, Ns: 2 (Понимая, что он уже видел этот пакет, LNS отбрасывает его и посылает ZLB)
Nr: 2, Ns: 3
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.1.2 IP-туннели
UP:
4.4 Интернет
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
4.4.2 Протокол UDP
Семенов Ю.А. (ГНЦ ИТЭФ) |
Протокол UDP (user datagram protocol, RFC-768) является одним из основных протоколов, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает доставку дейтограмм, но не требует подтверждения их получения. Протокол UDP не требует соединения с удаленным модулем UDP ("бессвязный" протокол). К заголовку IP-пакета udp добавляет поля порт отправителя и порт получателя, которые обеспечивают мультиплексирование информации между различными прикладными процессами, а также поля длина udp-дейтограммы и контрольная сумма, позволяющие поддерживать целостность данных. Таким образом, если на уровне ip для определения места доставки пакета используется адрес, на уровне UDP - номер порта. Примерами сетевых приложений, использующих UDP, являются NFS(network file system), TFTP(trivial file transfer protocol, RFC-1350), RPC (remote procedure call, RFC-1057) и SNMP (simple network management protocol, RFC-1157). Малые накладные расходы, связанные с форматом UDP, а также отсутствие необходимости подтверждения получения пакета, делают этот протокол наиболее популярным при реализации приложений мультимедиа, но главное его место работы - локальные сети и мультимедиа. Прикладные процессы и модули UDP взаимодействуют через UDP-порты. Эти порты нумеруются, начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги (сервер), ожидает сообщений, направленных в порт, специально выделенный для этих услуг. Программа-сервер ждет, когда какая-нибудь программа-клиент запросит услугу. Например, сервер snmp всегда ожидает сообщения, адресованного в порт 161. Если клиент snmp желает получить услугу, он посылает запрос в UDP-порт 161 на машину, где работает сервер. На каждой машине может быть только один агент SNMP, т.к. существует только один порт 161. Данный номер порта является общеизвестным, т.е. фиксированным номером, официально выделенным в сети Internet для услуг SNMP. Общеизвестные номера портов определяются стандартами Internet (см. табл. 4.4.2.1). Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 5 записей в порт, то процесс-получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части. Формат UDP-сообщений представлен ниже на рис. 4.4.2.1:
Длина сообщения равна числу байт в UDP-дейтограмме, включая заголовок. Поле UDP контрольная сумма содержит код, полученный в результате контрольного суммирования UDP-заголовка и поля данные. Не трудно видеть, что этот протокол использует заголовок минимального размера (8 байт). Таблица номеров UDP-портов приведена ниже (4.4.2.1). Номера портов от 0 до 255 стандартизованы и использовать их в прикладных задачах не рекомендуется. Но и в интервале 255-1023 многие номера портов заняты, поэтому прежде чем использовать какой-то порт в своей программе, следует заглянуть в RFC-1700. Во второй колонке содержится стандартное имя, принятое в Internet, а в третей - записаны имена, принятые в unix. |
|
Previous:
4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)
UP:
4.4 Интернет
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.5 Протокол XTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Транспортный протокол XTP (xpress transport protocol; http://www.ca.sandia.gov/xtp/) разработан в 1992 году, является протоколом нового поколения и имеет целью преодолеть недостатки такого популярного протокола как TCP (медленный старт, неэффективная работа при возникновении потерь пакетов). В XTP функции обеспечения надежной передачи данных и управления разделены, протокол допускает управление пропускной способностью канала и успешно справляется с перегрузкой канала. Принципиальной особенностью XTP является независимость от числа участников информационного обмена (обычный режим эквивалентен мультикастингу, по этой причине XTP может использоваться и как мультикастинг-протокол) и возможность работы с MAC, IP или AAL5. Протокол призван в перспективе заменить TCP, UDP, Appletalk и IPX. Мультикастинг в XTP в отличии от других протоколов может гарантировать доставку информации, что может оказаться важным при многоточечном управлении или в некоторых распределенных базах данных. При передаче больших массивов информации последовательные пакеты нумеруются. В случае потери принимающая сторона посылает отправителю список не доставленных пакетов (TCP повторяет пересылку всех пакетов, начиная с потерянного). Именно алгоритм селективной ретрансмиссии и позволяет повысить эффективность использования канала. Длина пакетов XTP кратна 64 бит. Совокупность информации, описывающей состояние XTP, называется контекстом. Каждый контекст управляет как входящим, так и исходящим потоками данных. Два активных контекста и поток данных образуют ассоциацию. В исходном состоянии контекст оконечной системы пассивен и находится в состоянии ожидания. Первый передаваемый пакет содержит полную адресную информацию. После получения первого пакета контекст становится активным. С этого момента ассоциация сформирована и обмен может происходить в обоих направлениях. Каждый последующий пакет несет в себе ключевой код, определяющий его принадлежность к данному контексту. При завершении передачи устанавливаются соответствующие биты опций, связь разрывается, а контексты возвращаются в пассивное состояние. Все виды XTP-пакетов имеют один и тот же формат заголовков. Управление контекстом осуществляется с помощью флагов, содержащихся в заголовке. Всего предусмотрено 15 флагов. На рис. 4.4.5.1 показана зависимость пропускной способности канала для сети ATM при использовании транспортных протоколов TCP и XTP, в обоих случая использовался в качестве базового протокол IP. Измерения производились для приложений типа FTP. Из рисунка видно, что даже 1% потерянных или поврежденных пакетов понижает пропускную способность на 30% при работе с протоколом TCP. XTP требует только три пакета, чтобы сформировать виртуальный канал, в то время как XTP требует для тех же целей семь пакетов. Благодаря своей простоте XTP может легко подменить любой транспортный протокол в любом существующем телекоммуникационном приложении. Протокол предоставляет некоторые услуги недоступные в других протоколах, что оказывается особенно привлекательным для приложений мультимедиа.
Рис. 4.4.5.1. Зависимость пропускной способности канала при использовании протоколов TCP и XTP ( www.mentat.com/xtp.xtp.html и xtpdata.html XTP 95-20, Xpress Transport Protocol Specification (XTP revision 4.0), 1995, XTP Forum, Santa Barbara, CA 93108 USA ) При 5% потерях пакетов XTP обеспечивает в 6 раз большую пропускную способность, чем TCP. В таблице 4.4.5.1 приведены сравнительные результаты измерения пропускной способности канала ATM (155 Мбит/с) при использовании протоколов TCP, UDP и XTP (использовались пакеты длиной 8190 байт). Таблица 4.4.5.1. Сравнительные характеристики протоколов TCP, UDPи XTP
Из таблицы видно, что в нормальных условиях протокол XTP гарантирует пропускную способность на 25% выше, чем TCP или UDP. Все поля в XTP-пакетах передаются так, что наиболее значимый байт передается первым (порядок байт - "big-endian"). Формат заголовка XTP-пакета показан на рис. 4.4.5.2. Поле ключ определяет принадлежность пакета к тому или иному контексту, поле команда (CMD) задает процедуру обработки пакета. Поле длина (DLEN) определяет объем данных в пакете, а поле номер по порядку (SEQ) представляет собой порядковый номер пакета в последовательности. Поля контрольная сумма и синхронизация используются для проверки корректности доставки. Старший бит поля ключ (RTN - возврат, рис. 4.4.5.3) зарезервирован в качестве флага, указывающего на контекст передающей (=0) или принимающей стороны (принимающая сторона, посылая пакеты, ставит RTN=1). Код поля ключ должен быть уникальным. Для обеспечения этого остальная часть поля делится на два субполя: индекс и инстанция (распределение бит между ними зависит от реализации и реальных потребностей). Индекс служит для выбора контекста, а инстанция подтверждает корректность кода индекс. Так при получении пакета сначала по индексу определяется контекст, а затем производится сравнение кодов инстанции в пакете и в таблице контекстов.
Рис. 4.4.5.2 Формат кадра протокола XTP
Рис. 4.4.5.3 Структура поля ключ 32-разрядное поле команды содержит в себе субполе опции. Названия различных бит этого поля показаны на рис. 4.4.5.4.
Рис. 4.4.5.4. Формат поля команда
XTP-передатчик контролирует все биты поля опции для каждого пакета. Некоторые дополнительные данные о битах субполя опции можно найти в таблице 4.4.5.2. Таблица 4.4.5.2. Значения битов субполя опции
"По-пакетно" означает, что бит может изменяться от пакета к пакету. "Раз на ассоциацию" означает, что все контексты ассоциации должны иметь этот бит идентичным. "Один раз" означает, что бит может быть установлен один раз за время жизни контекста Таблица 4.4.5.3. Коды типов пакетов XTP (Pformat)
Младший байт поля команда содержит субполе типа пакета (ptype). Биты 0-4 этого субполя содержат код формата пакета (Pformat, см. таблицу 4.4.5.3). Биты 5-7 определяют версию протокола (ver). Для XTP 4.0 код версии равен 001. Поле DLEN содержит число байт в массиве данных пакета, следующем непосредственно за заголовком. Так как информационные пакеты с нулевым объемом данных запрещены, код dlen не может быть равен нулю. Поле Check содержит контрольную сумму. Если бит nochek=1, то в поле записана контрольная сумма только заголовка, в противном случае - всего пакета. Поле приоритет (sort) предназначено для задания приоритета пересылаемой информации. Это поле интерпретируется лишь в случае, если бит sort=1. При sort=0 поле приоритет должно быть обнулено. Контексты с приоритетным трафиком посылают пакеты с sort=1 и с определенным кодом в поле приоритет. Бесприоритетные контексты шлют пакеты с sort=0 и нулевым полем приоритета. На приемной стороне информация доставляется в соответствии с кодом приоритета. Поле приоритет характеризуется беззнаковым 16-разрядным числом. Код приоритет, равный нулю, указывает на самый низкий приоритет, чем больше этот код, тем выше приоритет. XTP обслуживает активные контексты в соответствии с присвоенными им приоритетами. Высокоприоритетная информация посылается раньше низкоприоритетной. Аналогичный порядок обслуживания работает и на принимающей стороне. 32-битовое поле синхронизация (Sync) служит для синхронизации диалога. Каждый контекст хранит код последнего посланного значения Sync в переменной Saved_sync. Когда пакет послан с Sreq=1, значение переменной Saved_sync увеличивается на единицу и этот код заносится в поле Sync отправляемого пакета. Получатель запоминает последний полученный код Sync в контекстной переменной Rcvd_sync. Значение этой переменной записывается в поле эхо каждого посылаемого управляющего пакета. Когда управляющий пакет получен, код поля sync сравнивается со значением Rcvd_sync. Если sync Ё Rcvd_sync, то управляющий пакет обрабатывается нормально. В противном случае управляющий пакет содержит информацию, которая старее полученной с предыдущими пакетами, и обрабатываться не должен. Поле номер по прядку (SEQ) характеризуется 64-разрядным числом без знака и представляет собой порядковый номер байта в передаваемом потоке. Для первого пакета (first) поле SEQ характеризует объем буферов для потока откликов, а для пакетов Join это поле содержит дентификатор получателя (ключ контекста). Join-пакет отклик на запрос содержит в поле SEQ порядковый номер байта для текущей ассоциации. Диапазон значений поля номер по порядку для информационных пакетов начинается с SEQ и простирается вплоть до SEQ+ DLEN - 1. Для DIAG пакетов поле SEQ содержит код SEQ входного пакета, который вызвал ошибку. Если посылка пакета DIAG вызвана не входным пакетом, код SEQ должен быть равен нулю. Вслед за заголовком обычно следует его расширение (сегмент), формат которого зависит от типа пакета. Используются управляющие и информационные сегменты. Управляющие сегменты несут в себе информацию о состоянии контекста, его приславшего. XTP пакеты, содержащие управляющие сегменты называются контрольными пакетами. Управляющие сегменты содержат пакеты типа Cntl, Ecntl и Tcntl. Управляющий сегмент Cntl-пакета несет в себе информацию об управлении обменом. Ecntl-пакеты включают в себя сегменты управления ошибками, а Tcntl-пакеты - сегменты управления трафиком. Формат управляющего сегмента показан на рис. 4.4.5.5.
Рис. 4.4.5.5 Формат общего управляющего сегмента пакета XTP Три поля общего управляющего сегмента представляют статусную информацию и содержатся во всех трех типах контрольных пакетов. Первые два поля RSEQ и alloc являются параметрами управления обменом. Поле Echo используется для идентификации контрольных пакетов, которые являются откликом на пакеты с битом SREQ=1. Поле RSEQ содержит в себе номер очередного байта, подлежащего пересылке, и определяет начало окна, управляющего обменом. Поле Alloc интерпретируется, когда разрешено управление обменом. Код поля Alloc определяет объем данных, который отправитель может послать (а получатель принять). Если бит RES=1, то поле Alloc задает размер буфера, зарезервированного для данной ассоциации. Поле Echo используется для установления соответствия между запросом статуса и контрольными пакетами. Код поля Echo равен наибольшему значению sync для полученных пакетов. Это значение хранится в контекстной переменной rcvd_sync. Когда формируется контрольный пакет, значение rcvd_sync заносится в поле Echo этого пакета. Формат сегмента управления ошибками показан на рис. 4.4.5.6. Этот сегмент включает в себя все поля общего управляющего сегмента, дополнительно использовано только два поля Nspan и Spans, которые сообщают о том, какие пакеты потеряны.
Рис. 4.4.5.6 Формат сегмента управления ошибками Сегмент управления ошибками используется в пакетах Ecntl. Поле Nspan определяет число Spans в Ecntl-пакете. Так как пакет Ecntl посылается только в случае потери информации, поле Nspan несет в себе код не меньше 1. Поле Spans содержит в себе Nspan пар чисел, которые характеризуют интервалы номеров байт, переданных корректно. Речь здесь идет о данных, имеющих номера больше того, который указан в поле RSEQ. На основании этих данных можно вычислить, какая именно информация потеряна. Формат сегмента управления трафиком показан на рис. 4.4.5.7. Помимо полей общего управляющего сегмента здесь присутствуют поля RSVD и XKEY, а также спецификация трафика. Поле RSVD является резервным и должно содержать нуль. Поле XKEY является обязательной принадлежностью всех Tcntl-пакетов, величина этого поля должна равняться значению ключа для контекста, посылающего пакет (бит RTN=1). Спецификация трафика используется в пакетах типа first и Tcnnl. Пакет first предлагает параметры режима обмена, а Tcntl несет в себе отклик на это предложение.
Рис. 4.4.5.7 Формат сегмента управления трафиком Поле tlen определяет длину спецификации трафика, включая 4-байтовый дескриптор (tlen Ё ). Поле service используется для задания типа транспортного сервиса на фазе установления режима обмена. Коды доступных видов сервиса представлены в таблице 4.4.5.4. Эта информация передается в пакете типа first. Таблица 4.4.5.4. Коды поля тип сервиса (service)
Поле tformat определяет формат поля traffic. Код tformat=0 используется тогда, когда не нужно ни какой спецификации трафика, в 4-байтовое поле traffic в этом случае записываются нули. В противном случае используется код tformat=0x01. Формат поля traffic для этого арианта показан на рис. 4.4.5.8.
Рис. 4.4.5.8 Формат поля traffic Поле maxdata несет в себе код максимального размера информационного сегмента, который отправитель может послать за время жизни ассоциации. Поля inrate и inburst представляют собой параметры, определяющие входной поток данных. Поля outrate и outburst являются параметрами, задающими выходной поток данных. Информационный сегмент включает в себя пользовательскую и другую протокольную и диагностическую информацию. XTP-пакеты, содержащие информационный сегмент, называются информационными пакетами. К их числу относятся пакеты типа data, first, join и diag. Информационные пакеты могут включать в себя сегмент данных, адресный сегмент, спецификатор трафика и диагностический сегмент. Формат полей адресного сегмента показан на рис. 4.4.5.9.
Рис. 4.4.5.9 Формат полей адресного сегмента Адресный сегмент используется в пакетах типа first и join. Протокол XTP использует параметрическую схему адресации, возможны несколько форматов адресов отправителя и места назначения. Поле Alen определяет полную длину адресного сегмента. Поле Adomain представляет собой адресный демультиплексор, допуская работу с несколькими адресными доменами. Поле Adomain используется в частности для того, чтобы обеспечить совместимость с протоколами UDP и TCP (для TCP Adomain=6, для UDP 17, а для XTP 36). Поле Aformat идентифицирует адресный синтаксис в соответствии с таблицей 4.4.5.5. Таблица 4.4.5.5. Значения кодов поля Aformat
Поле адрес несет в себе адреса отправителя и получателя пакетов, форматы которых заданы полем Aformat. Формат полей сегмента данных показан на рис. 4.4.5.10. Эти сегменты предназначены для применения на прикладных пользовательских уровнях и программами поддержки протокола XTP не интерпретируются. Сегмент включается в пакеты типа first и data.
Рис. 4.4.5.10 Формат полей сегмента данных Размер поля Data имеет произвольное значение, первые 8 байт (поле Btag) представляют собой специальную метку (если бит опций заголовка btag=1). При Btag=0 метка отсутствует. Интерпретация поля Btag осуществляется исключительно прикладной программой и для XTP его значение безразлично. Формат полей диагностического сегмента показан на рис. 4.4.5.11. Этот сегмент используется пакетами типа DIAG для информирования протокольной или прикладной программы о случаях ошибок. Поле Code определяет тип и категорию ошибки, вызвавшей отправку пакета типа DIAG. Поле val позволяет уточнить причину ошибки. Поле message является опционным и может иметь произвольную длину. Обычно это поле содержит текстовую интерпретацию полей Code и VAL.
Рис. 4.4.5.11 Форматы полей диагностического сегмента |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)
UP:
4.4 Интернет
|
|
|
|
4.4.7 Прокси-ARP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Еще одна разновидность протокола ARP служит для того, чтобы один и тот же сетевой префикс адреса можно было использовать для двух сетей. Этот протокол называется смешанным протоколом ARP (proxy). Предположим, мы имеем сеть из четырех ЭВМ (1-4; рис. 4.4.7.1), которую бы мы хотели соединить с другой сетью из четырех ЭВМ (5-8), причем так, чтобы машины взаимодействовали друг с другом так, будто они принадлежат одной сети. Решить эту проблему можно, соединив эти сети через маршрутизатор M, работающий в соответствии со смешанным протоколом ARP (функционально это IP-мост). Маршрутизатор знает, какая из машин принадлежит какой физической сети. Он перехватывает широковещательные ARP-запросы из сети 1, относящиеся к сети 2, и наоборот. Во всех случаях в качестве физического адреса маршрутизатор возвращает свой адрес. В дальнейшем, получая дейтограммы, он маршрутизирует их на физические адреса по их IP-адресам.
Рис. 4.4.7.1. Использование протокола proxy ARP Не трудно видеть, что в смешанном протоколе ARP нескольким IP-адресам ставится в соответствие один и тот же физический адрес. Поэтому системы, где предусмотрен контроль за соответствием физических и IP-адресов, не могут работать со смешанным протоколом ARP. Главным преимуществом этого протокола является то, что он позволяет путем добавления одного маршрутизатора (Gateway) подключить к Интернет еще одну сеть, не изменяя таблиц маршрутизации в других узлах. Этот протокол удобен для сети, где есть ЭВМ, не способная работать с субсетями. Протокол используется при построении сетей Интранет. |
|
Previous:
4.4.6 Протокол преобразования адресов ARP
UP:
4.4 Интернет
|
|
|
|
4.4.8 Протокол обратного адресного преобразования RARP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Обычно IP-адреса хранятся на диске, откуда они считываются при загрузке системы. Проблема возникает тогда, когда необходимо инициализировать рабочую станцию, не имеющую диска. Бездисковые системы часто используют операции типа TFTP для переноса из сервера в память образа операционной системы, а это нельзя сделать, не зная IP-адресов сервера и ЭВМ-клиента. Записывать эти адреса в ПЗУ не представляется целесообразным, так как их значения зависят от точки подключения ЭВМ и могут меняться. Для решения данной проблемы был разработан протокол обратной трансляции адресов (RARP - Reverse Address Resolution Protocol, RFC-0903, смотри также ниже описание протокола BOOTP). Форматы сообщений RARP сходны с ARP (см. рис. 4.4.8.1), хотя сами протоколы принципиально различны. Протокол RARP предполагает наличие специального сервера, обслуживающего RARP-запросы и хранящего базу данных о соответствии аппаратных адресов протокольным. Этот протокол работает с любой транспортной средой, в случае же кадра Ethernet в поле тип будет записан код 803516 (смотри таблицу 4.4.6.2).
Рис. 4.4.8.1. Формат RARP-сообщения Здесь обозначения те же, что и в описании ARP-формата. Значение n определяется числом, записанным в поле HA-Len, а m - числом из поля PA-Len. Для Internet PA-Len=4 и тип протокола=2048, а для Ethernet равно HA-Len=6 и тип оборудования=1. В RARP используется два кода операции. Код операции=3 используется для RARP-запросов, а код операции=4 - для RARP-откликов. В первом случае поле протокольный адрес отправителя и протокольный адрес адресата не определены. Обычно локальная сеть имеет несколько RARP-серверов, что позволяет загрузиться бездисковым машинам, даже если какой-то из серверов выключен или не исправен. |
|
Previous:
4.4.7 Прокси-ARP
UP:
4.4 Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.9 Протокол IGMP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||
|
Передача мультимедийных данных по сетям Интернет является одним из наиболее важных направлений. Этот вид информации передается обычно в режиме без установления соединения (протокол UDP-RTP). Наиболее типичной схемой в этом случае является наличие одного передатчика и большого числа приемников. Эта схема реализуется с использованием мультикастинг-адресации. Мультикастинг-адресация может осуществляться на IP- и MAC-уровнях. В Ethernet для этих целей зарезервирован блок адресов в диапазоне от 01:00:5E:00:00:00 до 01:00:5E:7F:FF:FF. Первый байт адреса, равный 01, указывает на то, что адрес является мультикастным. Данная схема резервирования адресного пространства позволяет использовать 23 бита Ethernet-адреса для идентификации группы рассылки при IP-мультикастинге (см. рис. 4.4.9.1.).
Рис. 4.4.9.1. Соотношение мультикастинговых MAC- и IP-адресов Область из 5 бит в IP-адресе, отмеченная *****, не используется при формировании Ethernet-адреса. Так как соотношение IP и MAC-адресов не является однозначным, драйверы должны обеспечивать обработку адресов с тем, чтобы интерфейсы получали только те кадры, которые действительно им предназначены. Для того чтобы информировать маршрутизатор о наличии участников мультикастинг-обмена в субсети, связанной с тем или иным интерфейсом, используется протокол IGMP. Протокол IGMP (internet group management protocol, RFC-1112) используется для видеоконференций, передачи звуковых сообщений, а также группового исполнения команд различными ЭВМ. Этот протокол использует групповую адресацию (мультикастинг). Групповая форма адресации нужна тогда, когда какое-то сообщение или последовательность сообщений необходимо послать нескольким (но не всем) адресатам одновременно. При этой форме адресации ЭВМ имеет возможность выбрать, хочет ли она участвовать в этой процедуре. Когда группа ЭВМ хочет взаимодействовать друг с другом, используется один групповой (мультикастинг) адрес. Групповая адресация может рассматриваться как обобщение обычной системы адресов, а традиционный IP-адрес - частный случай группового обращения при числе ЭВМ, равном 1. При групповой адресации один и тот же пакет может быть доставлен заданной группе ЭВМ. Членство в этой группе может динамично меняться со временем. Любая ЭВМ может войти в группу и выйти из группы в любое время по своей инициативе. В то же время ЭВМ может быть членом большого числа таких групп. ЭВМ может посылать пакеты членам группы, не являясь им сама. Каждая группа имеет свой адрес класса D (рис. 4.4.9.2, см. также рис. 4.4.9.1).
Адрес 224.0.0.1 предназначен для обращения ко всем группам (все узлы и серверы, вовлеченные в данный момент в мультикастинг-обмен, например, участвующие в видеоконференции). ЭВМ может участвовать в мультикастинг-процессе на одном из следующих уровней: Таблица 4.4.9.1. Коды мультикастинг-процессов
Ряд мультикастинг-адресов зарезервировано строго для определенных целей. Таблица 4.4.9.2. Зарезервированные мультикастинг-адреса
Для того чтобы участвовать в коллективных обменах в локальной сети ЭВМ должна быть снабжена программой, которая поддерживает этот режим. При этом сервер локальной сети (gateway) информируется о намерении использовать мультикастинг. Сервер передает эту информацию другим внешним серверам IP-сети. Следует иметь в виду, что мультикастинг также как и широковещательный режим, заметно загружает сеть. IGMP для передачи своих сообщений использует IP-дейтограммы (IGMP-пакеты инкапсулируются в них). Для подключения к группе сначала посылается IGMP-сообщение "всем ЭВМ" о включении в группу, при этом локальный мультикаст-сервер подготавливает маршрут. Локальный мультикаст-сервер время от времени проверяет ЭВМ и определяет, не покинули ли они группу (ЭВМ не подтверждает свое членство в группе). Все обмены между ЭВМ и мультикаст-сервером производятся в режиме ip-мультикастинга, те есть, любое сообщение адресуется всем ЭВМ группы. ЭВМ, не принадлежащая группе, IGMP-сообщений не получает, что сокращает загрузку сети. Формат сообщений в протоколе IGMP имеет вид, показанный ниже на рис. 4.4.9.3.
Рис. 4.4.9.3. Формат IGMP-сообщений Поле версия определяет используемую версию протокола, поле тип=1 говорит о том, что это запрос, отправленный мультикастинг-маршрутизатором, тип=2 указывает, что этот отклик послан ЭВМ. ЭВМ использует групповой адрес, чтобы сообщить о своем подключении к группе. Контрольная сумма вычисляется по тому же алгоритму, что и для ICMP. IGMP-сообщения используются мультикастинг-маршрутизаторами для того, чтобы отслеживать членство в группе каждой из сетей, подключенных к нему. В группе может участвовать несколько активных процессов в одной и той же ЭВМ, но при этом посылается только один запрос для регистрации. Когда какой-то процесс покидает группу, ЭВМ не шлет сообщения об этом, даже в случае, когда это последний из процессов - членов группы на данной ЭВМ. Просто при очередном запросе ЭВМ не подтвердит членство в группе. Мультикастинг-маршрутизатор регулярно посылает запросы с требованием подтвердить участие в группе. ЭВМ посылает отклик- подтверждение для каждой из групп, если у нее есть хотя бы один процесс - член группы. На основе этих запросов-откликов мультикастинг-маршрутизатор составляет и поддерживает таблицу интерфейсов, которые имеют одну или более ЭВМ, входящих в мультикастинг-группы. Протокол IGMP используется при организации мультикастинг-туннелей для передачи звуковой и видеоинформации. Для решения проблем мультимедиа в сетях Интернет используется идея MBONE. По умолчанию мультикаст-дейтограммы имеют значение поля TTL=1, что ограничивает их распространение одной субсетью. Приложения могут увеличивать значение TTL. Первая дейтограмма, тем не менее, всегда имеет TTL=1. Если получение этой дейтограммы не подтверждается сервером, посылается вторая - с TTL=2 и т.д. Таким образом попутно измеряется и число шагов между клиентом и сервером. Для случая, когда число шагов не более 1, зарезервирован блок адресов 224.0.0.0 - 224.0.0.255. Маршрутизатор не обрабатывает пакеты с такими адресами вне зависимости от кода поля TTL. При использовании мультикастинга MAC-переключатели переадресуют пакеты через все имеющиеся интерфейсы, что заметно ухудшает эффективность сети. Чтобы решить эту проблему компания CISCO разработала протокол CGMP (Cisco Group Management Protocol), который позволяет взаимодействовать маршрутизаторам и переключателям, что позволяет передавать мультикаст-пакеты только на те интерфейсы, где имеются активные члены группы. |
||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.8 Протокол обратного адресного преобразования RARP
UP:
4.4 Интернет
|
|
|
|
4.4.9.1 Мультикастинг и MBONE
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
MBONE - это виртуальная сеть, базирующаяся на мультикастинг-протоколах, которые были одобрены IETF летом 1992 года. В основу легли разработки, выполненные в компании Ксерокс. Данный режим работы поддерживается не всеми маршрутизаторами. Сеть представляет собой систему Ethernet-сетей, объединенных друг с другом соединениями точка-точка, которые называются "туннелями". Конечными точками таких туннелей обычно являются машины класса рабочих станций, снабженные соответствующим программным обеспечением. Впервые мультикастинг-туннель был реализован в Стэнфордском университете в 1988 году. IP-мультикастинг-пакеты инкапсулируются при передаче через туннели так, что они выглядят как обычные IP-уникаст-пакеты. Мультикастинг-маршрутизатор при посылке пакета через туннель подготавливает IP-пакет с заголовком, который содержит адрес маршрутизатора-партнера на другом конце туннеля, при этом поле IP-протокола содержит код 4 (IP). Маршрутизатор-приемник извлекает вложенный мультикастинг-пакет и направляет далее, если это требуется. MBONE требует пропускной способности магистральных каналов не ниже 500Kбит/с. Каждый туннель имеет определенный порог для переменной времени жизни пакета (time-to-live - TTL). Согласно договоренности (IETF) широкополосная видео-информация передается с малыми начальными значениями TTL. Малые значения TTL не позволяет видео-пакетам загружать слишком большие участки сети. Мультикастинг-дейтограмма с TTL=0 может быть доступна только процессу, существующему в ЭВМ, породившей эту дейтограмму. По умолчанию мультикастинг-дейтограммы имеют TTL=1, такая дейтограмма не может покинуть пределов субсети, и только дейтограммы с TTL>1 могут переадресовываться маршрутизаторами. Следует помнить, что маршрутизатор не откликнется ICMP-сообщением "время истекло", когда TTL достигнет нуля, так как вообще дейтограммы с мультикастинг-адресами не вызывают ICMP-откликов. Увеличивая TTL, прикладной процесс может расширять "зону взаимодействия". Сначала дейтограмма может посылаться с TTL=1, если отклика не получено, c TTL=2 и так далее. Эта схема позволяет найти ближайший сервер (с точки зрения числа шагов до него). Для приложений, которые ограничивают свою активность в пределах одного шага, предусмотрен специальный интервал адресов 224.0.0.0 - 224.0.0.255. Мультикастинг-маршрутизатор не должен переадресовывать дейтограммы с такими адресами вне зависимости от значения TTL. Адрес 224.0.0.1 является адресом группы "все ЭВМ" и относится ко всем ЭВМ и маршрутизаторам, способным работать в режиме мультикастинга. Каждая ЭВМ автоматически включается в эту группу при инициализации интерфейса. О членстве в этой группе ЭВМ не сообщает. Конфигурация системы в режиме мультикастинга производится автоматически. Для того чтобы изменить конфигурацию системы, или добавить еще один туннель используются специальные конфигурационные команды, которые записываются в /etc/mrouted.conf. Существует два типа таких команд: phyint <local-addr> [disable] [metric <m>] [threshold <t>] tunnel <local-addr> <remote-addr> [metric <m>] [threshold <t>] Первая команда может отменить мультикастинг-маршрутизацию для конкретного физического интерфейса, идентифицируемого по его IP-адресу (<local-addr>), или заменить значение метрики или порога. Эта команда должна выдаваться до команды tunnel. Последняя команда может служить для установления туннеля между местным IP-адресом (<local-addr>) и удаленным IP-адресом (<remote-addr>). Значения метрики и порога по умолчанию равны 1. Специфика мультикастинг-туннелей требует принципиально новых решений задачи маршрутизации, первой попыткой разрешить эту проблему был протокол DVMRP. Следует иметь в виду, что DVMRP может решить лишь часть задачи, хотя бы потому, что это внутренний протокол. Главной особенностью мультикастинг-маршрутизации является то, что нужно проложить маршруты от источника к совокупности адресатов, от которых пришли запросы участия в процессе. Режим мультикастинга поддерживается не всеми маршрутизаторами Интернет. Возможны конфликты при решении задачи маршрутизации, когда транзитный маршрутизатор не имеет "своих" участников группы (а должен выделить заметный ресурс каналов для удовлетворения внешних запросов). |
|
Previous:
4.4.9 Протокол IGMP
UP:
4.4 Интернет
|
|
|
||||||||||||||||||||||||
|
4.4.9.2 Протокол реального времени RTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||
|
В Интернет, также как и в некоторых других сетях, возможна потеря пакетов изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах. Мультимедийные приложения накладывают достаточно жесткие требования на транспортную среду. Для согласования таких требований с возможностями Интернет был разработан протокол RTP. Протокол RTP (См. RFC-2205, -2209, -2210, -1990, -1889; "RTP: A Transport Protocol for Real-Time Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на идеях, предложенных Кларком и Тенненхаузом [1], и предназначен для доставки данных в реальном масштабе времени (например, аудио- или видео). При этом определяется тип поля данных, производится нумерация посылок, присвоение временных меток и мониторирование доставки. Приложения обычно используют RTP поверх протокола UDP для того, чтобы использовать его возможности мультиплексирования и контрольного суммирования. Но RTP может использоваться и поверх любой другой сетевой транспортной среды. RTP поддерживает одновременную доставку по многим адресам, если мультикастинг поддерживается нижележащим сетевым уровнем. Следует иметь в виду, что сам по себе RTP не обеспечивает своевременной доставки и не предоставляет каких-либо гарантий уровня сервиса (QoS. Этот протокол не может гарантировать также корректного порядка доставки данных. Правильный порядок выкладки информации может быть обеспечен принимающей стороной с помощью порядковых номеров пакетов. Такая возможность крайне важна практически всегда, но особое внимание этому уделяется при восстановлении передаваемого изображения. На практике протокол RTP не отделим от протокола RTCP (RTP control protocol). Последний служит для мониторинга qos и для передачи информации об участниках обмена в ходе сессии. RTP гибкий протокол, который может доставить приложению нужную информацию, его функциональные модули не образуют отдельный слой, а чаще встраиваются в прикладную программу. Протокол RTP не является жестко регламентирующим. При организации аудио-конференции каждый участник должен иметь адрес и два порта, один для звуковых данных, другой для управляющих RTCP-пакетов. Эти параметры должны быть известны всем участникам конференции. При необходимости соблюдения конфиденциальности информация и пакеты управления могут быть зашифрованы. При аудио конференциях каждый из участников пересылает небольшие закодированные звуковые фрагменты длительностью порядка 20 мсек. Каждый из таких фрагментов помещается в поле данных RTP-пакета, который в свою очередь вкладывается в UDP-дейтограмму. Заголовок пакета RTP определяет, какой вид кодирования звука применен (PCM, ADPCM или LPC), что позволяет отправителю при необходимости сменить метод кодирования, если к конференции подключился новый потребитель с определенными ограничениями или сеть требует снижения скорости передачи. При передаче звука весьма важным становится взаимное положение закодированных фрагментов во времени. Для решения задачи корректного воспроизведения заголовки пакетов RTP содержат временную информацию и порядковые номера. Порядковые номера позволяют не только восстановить правильный порядок фрагментов, но и определить число потерянных пакетов-фрагментов. Так как участники конференции могут появляться и исчезать по своему усмотрению, полезно знать, кто из них присутствует в сети в данный момент, и как до них доходят передаваемые данные. Для этой цели периодически каждый из участников транслирует через порт RTCP мультикастинг-сообщение, содержащее имя участника и диагностические данные. Узел-участник конференции шлет пакет BUY (RTCP), если он покидает сессию. Если в ходе конференции передается не только звук но и изображение, они передаются как два независимых потока с использованием двух пар UDP-портов. RTCP-пакеты посылаются независимо для каждой из этих двух сессий. На уровне RTP не существует какой-либо взаимосвязи между аудио- и видео сессиями. Только RTCP-пакеты несут в себе одни и те же канонические имена участников. В некоторых случаях можно столкнуться с ситуацией, когда один из участников конференции подключен к сети через узкополосный канал. Было бы не слишком хорошо требовать от всех участников перехода на кодировку, соответствующую этой малой полосе. Для того чтобы этого избежать, можно установить преобразователь, называемый смесителем, в непосредственной близости от узкополосной области. Смеситель преобразует поток аудио-пакетов в следовательность пакетов, которая соответствует возможностям узкополосного канала. Эти пакеты могут быть уникастными (адресованными одному получателю) или мультикастными. Заголовок RTP включает в себя средства, которые позволяют мультиплексорам идентифицировать источники, внесшие вклад. Так что получатель может правильно идентифицировать источник звукового сигнала. Некоторые участники конференции, использующие широкополосные каналы, не доступны для IP-мультикастинга (например, находятся за Firewall). Для таких узлов смесители не нужны, здесь используется другой RTP-уровень передачи, называемый трансляцией. Устанавливается два транслятора по одному с каждой из сторон Firewall. Внешний транслятор передает мультикастинг-пакеты по безопасному каналу внутреннему транслятору. Внутренний же транслятор рассылает их подписчикам локальной сети обычным образом. Смесители и трансляторы могут выполнять и другие функции, например, преобразование IP/UDP пакетов в ST-II при видео конференциях. Определения Поле данных RTP: Информация, пересылаемая в пакете RTP, например фрагменты звука или сжатые видео данные. Пакет RTP: Информационный пакет, содержащий фиксированный заголовок. Один пакет транспортного нижнего уровня, например UDP, обычно содержит один RTP-пакет, но это требование не является обязательным. Поле источников информации может быть пустым. Пакет RTCP: Управляющий пакет, содержащий фиксированный заголовок сходный с RTP, за которым следуют структурные элементы, зависящие от типа RTCP-пакета. Обычно несколько RTCP-пакетов посылаются как составной RTCP-пакет, вложенный в дейтограмму нижележащего уровня. Транспортный адрес: Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя. Сессия RTP: Период с момента установления группы участников RTP-обмена до ее исчезновения. Для каждого из участников сессия определяется конкретной парой транспортных адресов (сетевой адрес и номера портов для RTP и RTCP). Транспортный адрес места назначения может быть общим для всех участников сессии. Допускается реализация нескольких сессий для каждого из участников одновременно. Источник синхронизации (SSRC): Источник потока RTP-пакетов, определяется 32-битным числовым SSRC-идентификатором, который записывается в заголовок RTP-пакета и не зависит от сетевого адреса. Все пакеты от источника синхронизации образуют часть с идентичной временной привязкой и нумерацией. Эти данные используются принимающей стороной при воспроизведении. Источниками синхронизации могут служить источники первичного сигнала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-идентификатор представляет собой случайное число, которое является уникальным для данной RTP-сессии. Участник сессии не должен использовать один и тот же SSRC-идентификатор для всех RTP-сессий мультимедийного набора. Если участник формирует несколько потоков в рамках одной RTP-сессии (например, от нескольких видеокамер), каждый участник должен быть снабжен уникальным SSRC-идентификатором. Информационный источник CSRC (contributing source): Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют парциальные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудио-конференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор. Оконечная система: Приложение, которое генерирует или воспринимает данные, посылаемые в виде RTP-пакетов. Оконечная система может выступать в качестве одного или нескольких источников синхронизации для конкретной сессии. Смеситель: Промежуточная система, которая получает RTP-пакеты от одного или нескольких источников, при необходимости меняет их формат, объединяет и пересылает их адресатам. Так как временная привязка входных пакетов может отличаться, смеситель осуществляет их синхронизацию и генерирует свой собственный поток RTP-пакетов. Таким образом все посылаемые пакеты имеют в качестве источника синхронизации смеситель. Транслятор: Промежуточная система, которая переадресует RTP-пакеты, не изменяя их идентификаторы источника синхронизации. Такие устройства используются для преобразования системы кодирования, перехода от мультикастинг- к традиционной уникаст-адресации или при работе с Firewall. Монитор: Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности диагностические сообщения, производит оценку состояния связи, копит долгосрочную статистику обмена. Все целочисленные поля передаются в соответствии c сетевым порядком, т.е. старший байт следует первым (big-endian). Порядок передачи описан подробно в работе [3]. Если не оговорено обратного все цифровые константы являются десятичными. Все поля заголовка выравниваются по их естественным границам, т.е. 16-битовые поля имеют четное смещение, а 32-битные имеют адрес, кратный 4. Октеты-заполнители содержат нули. Абсолютное время представляется с помощью временных меток в соответствии с форматом NTP (network time protocol), который характеризует время в секундах от начала суток (UTC) 1 января 1900 [4]. Полное разрешение временной метки NTP определяется 64-битовым числом с фиксированной запятой без знака. Целочисленная часть задается первыми 32 битами, а дробная часть последними. В некоторых полях, где допустимо более компактное представление, используются только средние 32 бита (16 бит целочисленная часть и 16 бит дробная). Заголовок RTP-пакета имеет следующий формат (см. рис. 4.4.9.2.1).
Рис. 4.4.9.2.1. Заголовок пакета RTP Первые 12 октетов присутствуют во всех RTP-пакетах, в то время как список CSRC-идентификаторов присутствует только, когда пакет формируется смесителем. Поля имеют следующие назначения: v (Версия): 2 бита Это поле идентифицирует версию протокола RTP. В настоящее время в это поле записывается код 2. Значение 1 использовалось в опытной версии RTP, а код 0 - в аудио приложении "vat". p (Заполнитель): 1 бит Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP. x (Расширение): 1 бит Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка. CC(CSRC count - число CSRC): 4 бита Число CSRC содержит код количества csrc-идентификаторов, которые записаны в пакете. M (маркер): 1 бит Интерпретация маркера определяется профайлом. Предполагается разрешить выделять в потоке пакетов существенные события, такие как границы кадра. Профайл может определить дополнительные маркерные биты или специфицировать отсутствие маркерных битов путем изменения числа битов в поле PT. PT(Тип данных): 7 бит Это поле идентифицирует формат поля данных RTP-пакета и определяет интерпретацию его приложением. Могут быть определены дополнительные коды типа данных. Исходный набор кодов по умолчанию для аудио и видео задан в профайле Internet-draft draft-ietf-avt-profile, и может быть расширен в следующих редакциях стандарта assigned numbers (RFC-1700) [5]. Номер по порядку: 16 бит Номер по порядку инкрементируется на 1 при посылке очередного RTP-пакета данных, этот код может использоваться получателем для регистрации потерь пакетов и для восстановления истинного порядка присланных фрагментов. Начальное значение кода является случайным. Алгоритм генерации таких кодов рассмотрен в [6]. Временная метка: 32 бита Временная метка соответствует времени стробирования для первого октета в информационном RTP-пакете. Время стробирования должно быть получено от часов, показания которых увеличиваются монотонно и линейно, чтобы обеспечить синхронизацию и вычисление временного разброса. Разрешающая способность часов должна быть достаточной для обеспечения приемлемой точности синхронизации (одного тика на видео кадр обычно не достаточно). Частота часов зависит от формата данных и задается статически в профайле, в спецификации поля данных, или динамически средствами, выходящими за пределы спецификации протокола RTP. Если RTP-пакеты генерируются периодически, используется временная привязка, определенная задающим генератором стробирования, а не показаниями системных часов. Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к и тому же видео кадру). SSRC: 32 бита Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор. CSRC-список: от 0 до 15 элементов, по 32 бита каждый CSRC-список идентифицирует источники информации, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы. Для эффективной реализации протокола число точек мультиплексирования должно быть минимизировано. В RTP, мультиплексирование осуществляется по транспортным адресам мест назначения, которые определены RTP-сессией. Использование пакетов с различным типом поля данных но с идентичным ssrc создает определенные проблемы: 1. Если один из типов данных будет изменен в ходе сессии, нет универсальных средств для определения, какое из старых значений следует заменить на новое. 2. ssrc определено для идентификации одного пространства номеров и временных меток. Совместное использование нескольких типов данных в общем потоке может потребовать разных средств синхронизации и разной нумерации, чтобы определять, какой из типов пакетов потерян. 3. RTCP-сообщения отправителя и получателя могут описать только одно пространство номеров и временных меток для каждого SSRC и не имеют поля типа данных. 4. RTP-смеситель не сможет объединять перекрывающиеся потоки при условии их несовместимости. 5. Работа со многими средами в пределах одной RTP-сессии предполагает: использование различных сетевых путей или разного размещения сетевых ресурсов; приема только одного субнабора, например аудио, когда видео недоступно из-за недостатка широкополосности. Использование различных ssrc для каждого вида среды, при посылке их в пределах одной RTP-сессии позволяет преодолеть первые три проблемы. Хотя существующие RTP-заголовки позволяют решать широкий круг проблем, предусмотрена возможность их модификации с помощью профайлов. При этом сохраняется возможность контроля и мониторирования с использованием стандартных средств.
В протоколе RTP предусмотрен механизм расширений заголовка, который позволяет модифицировать заголовок и экспериментировать с новыми форматами поля данных. Этот механизм устроен так, что расширения заголовка могут игнорироваться приложениями, которые не нуждаются в расширениях. Расширения заголовка предназначены для ограниченного использования. И многие приложения лучше реализовать, используя профайл. Формат реализации расширений показан на рис. 4.4.9.2.2.
Рис. 4.4.9.2.2. Формат расширения заголовка Если бит x в RTP-заголовке равен 1, то к заголовку добавлено расширение переменной длины, за которым может следовать список csrc. Расширение заголовка содержит 16-битовое поле длины, определяющее число 32-битных слов в расширении, исключая 4-октета заголовка расширения (т.о. значения поля длина, равное нулю вполне допустимо). Информационный заголовок RTP может иметь только одно расширение. Для того чтобы обеспечить работу различных приложений с различными расширениями заголовка или чтобы обеспечить работу с более чем одним типом расширений, первые 16 бит расширения заголовка остаются свободными для выбора идентификаторов или параметров. Формат этих 16 бит определяется спецификацией профайла, с которым работает приложение. Кроме оконечных систем RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP. RTP транслятор/смеситель соединяет две или более области на транспортном уровне. Обычно каждая область определяется сетью и транспортным протоколом (например, ip/udp), мультикаст-адресом или парой уникаст-адресов, а также портом назначения транспортного уровня. Одна система может служить транслятором или смесителем для нескольких RTP сессий. Для того чтобы исключить зацикливание при использовании транслятора или смесителя следует придерживаться следующих правил:
Аналогично все оконечные системы RTP, которые взаимодействуют через один или более трансляторов или смесителей, принадлежат одной и той же ssrc-области, т.е., ssrc-идентификаторы должны быть уникальными для задействованных оконечных систем. Существует большое разнообразие трансляторов и смесителей, спроектированных для решения различных задач и приложений. Некоторые служат для шифрования/дешифрования несущих дейтограмм. Различие между смесителями и трансляторами заключается в том, что последние пропускают через себя потоки данных, при необходимости их преобразуя, а смесители объединяют несколько потоков в один. Транслятор . Переадресует RTP-пакеты, не изменяя их SSRC-идентификаторы. Это позволяет получателям идентифицировать отдельные источники, даже если пакеты от всех источников проходят через один общий транслятор и имеют сетевой адрес транслятора. Некоторые типы трансляторов передают данные без изменений, другие кодируют данные и соответственно изменяют коды типа данных и временные метки. Приемник не может заметить присутствия транслятора. Смеситель . Принимает потоки RTP-данных от одного или нескольких источников, может изменять формат данных, определенным образом объединяет потоки и затем формирует из них один общий поток. Так как объединяемые потоки не синхронизованы, смеситель производит синхронизацию потоков и формирует свою собственную временную шкалу для исходящего потока. Смеситель является источником синхронизации. Таким образом, все пакеты данных, переадресованные смесителем, будут помечены SSRC-идентификатором смесителя. Для того чтобы сохранить информацию об источниках исходных данных, смеситель должен внести свои SSRC-идентификаторы в список CSRC-идентификаторов, который следует за фиксированным RTP-заголовком пакета. Смеситель, который, кроме того, вносит в общий поток свою составляющую, должен включить свой собственный SSRC-идентификатор в CSRC-список для данного пакета. Для некоторых приложений смеситель может не идентифицировать источники в CSRC-списке. Однако это создает опасность того, что петли, включающие эти источники, не смогут быть выявлены. Преимуществом смесителя перед транслятором для аудио- приложений является то, что выходная полоса не превосходит полосы одного источника, даже когда в сессии на входе смесителя присутствуют несколько участников. Недостатком является то, что получатели с выходной стороны не имеют никаких средств для контроля того, какой из источников передает данные даже в случае наличия дистанционного управления смесителем.
Рис. 4.4.9.2.3 Пример RTP сети с оконечными системами, смесителями и трансляторами Некоторый набор смесителей и трансляторов представлен на рис. 4.4.9.2.3. Здесь показано их влияние на SSRC и CSRC-идентификаторы. Оконечные системы обозначены символами ES и выделены желтым цветом. Трансляторы обозначены буквами TRS (на рисунке овалы голубого цвета) и смесители обозначены как MUX (прямоугольники сиреневого цвета). Запись "M1:13(1,17)" обозначает пакет отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2. Последовательное включение смесителей В RTP-сессии могут быть задействованы несколько смесителей и трансляторов, как это показано на рис. 4.4.9.2.3. Если два смесителя включены последовательно, так как MUX2 и MUX3, пакеты полученные смесителем могут быть уже объединены и включать CSRC-список со многими идентификаторами. Cмеситель (MUX3) должен формировать CSRC-список для исходящих пакетов, используя CSRC-идентификаторы уже смешанных входных пакетов (выход MUX2) и SSRC-идентификаторы несмешанных входных пакетов, поступивших от ES9 (E:36). Это отмечено на рисунке для выходных пакетов смесителя MUX3 как M3:99(9,11,36). Если число идентификаторов в списке CSRC превышает 15, остальные не могут быть туда включены. SSRC-идентификаторы в RTP-заголовках и в различных полях RTCP-пакетов являются случайными 32-битовыми числами, которые должны быть уникальными в рамках RTP-сессии. Очень важно, чтобы одни и те же числа не были использованы несколькими участниками сессии. Недостаточно использовать в качестве идентификатора локальный сетевой адрес (такой как IPv4), так как может быть не уникальным. Так как RTP трансляторы и смесители допускают работу с сетями, использующими различные адресные пространства, это допускает их случайное совпадение с большей вероятностью, чем в случае использования случайных чисел. Не приемлемо также получать идентификаторы SSRC путем простого обращения к функции random() без тщательной инициализации. Так как идентификаторы выбраны случайным образом, существует малая, но конечная вероятность того, что два или более источников выберут одно и то же число. Столкновение более вероятно, если все источники стартуют одновременно. Если N число источников, а L длина идентификатора (в нашем случае, 32 бита), вероятность того, что два источника независимо выберут одно и то же значение (для больших N [8]) составляет 1 - exp(-N2 / 2(L+1)). Для N=1000, вероятность примерно равна 10-4. Типовое значение вероятности столкновения много меньше худшего случая, рассмотренного выше. Рассмотрим случай, когда новый источник подключается к RTP-сессии, в которой все остальные источники уже имеют уникальные идентификаторы. Если N равно числу источников, а L длина идентификатора, вероятность столкновения равна N / 2L. Для N=1000, вероятность составит около 2*10 -7. Вероятность столкновения уменьшается еще больше в случае, когда новый источник получает пакеты других участников до того, как передаст свой первый пакет. Если новый источник отслеживает идентификаторы других участников, он легко может устранить вероятность конфликта. Преодоление столкновений и детектирование петель Хотя вероятность столкновения идентификаторов SSRC довольно мала, все RTP реализации должны быть готовы обнаруживать столкновения и предпринимать адекватные меры для их преодоления. Если источник обнаруживает в какой-либо момент, что другой источник использует тот же идентификатор SSRC, он посылает пакет RTCP BYE для старого идентификатора и выбирает новый. Если получатель обнаруживает, что два других источника имеют равные идентификаторы (столкновение), он может воспринимать пакеты от одного и игнорировать от другого до тех пор, пока это не будет зарегистрировано отправителями или CNAME. Так как идентификаторы уникальны, они могут использоваться для детектирования петель, которые могут создаваться смесителем или транслятором. Петля приводит к дублированию данных и управляющей информации:
Источник может обнаружить, что его собственный пакет движется по кругу, или что пакеты других источников осуществляют циклическое движение. Оба вида петель и столкновения приводят к тому, что пакеты приходят с тем же самым SSRC-идентификатором, но с разными транспортными адресами, которые могут принадлежать оконечной или какой-то промежуточной системе. Следовательно, если источник меняет свой транспортный адрес, он должен также выбрать новый SSRC-идентификатор с тем, чтобы ситуация не была интерпретирована, как зацикливание. Петли или столкновения, происходящие на дальней стороне транслятора или смесителя, не могут быть детектированы с использованием транспортного адреса источника, если все копии пакетов идут через транслятор или смеситель. Однако, столкновения могут быть детектированы, когда фрагменты двух RTCP SDES пакетов содержат равные SSRC-идентификаторы, но разные коды CNAME (см. описание протокола RTCP). Для того чтобы детектировать и устранять конфликты, реализации RTP должны содержать алгоритм, аналогичный описанному ниже. Он игнорирует пакеты от нового источника, которые входят в противоречие с работающим источником. Алгоритм разрешает конфликты с SSRC-идентификаторами участников путем выбора нового идентификатора и посылки RTCP BYE для старого. Однако, когда столкновение вызвано зацикливанием собственных пакетов участников сессии, алгоритм выбирает новый идентификатор только раз и после этого игнорирует пакеты от транспортного адреса, вызвавшего зацикливание. Это требуется для того, чтобы избежать потока пакетов BYE. Этот алгоритм зависит от равенства транспортных адресов для RTP и RTCP пакетов источника. Алгоритм требует модификации приложений, которые не отвечают этому ограничению. Этот алгоритм требует наличия таблицы транспортных адресов источников, упорядоченных по их идентификаторам. В таблицу заносятся адреса, откуда данный идентификатор был впервые получен. Каждый SSRC или CSRC идентификатор, полученный с информационным или управляющим пакетом ищется в этой таблице, для того чтобы корректно обработать полученные данные. Для управляющих пакетов каждый элемент с его собственным SSRC, например, фрагмент SDES, требует отдельного просмотра. SSRC в сообщениях-отчетах составляют исключение. Если SSRC или CSRC не найдены, создается новая запись в таблице. Эти записи в таблице удаляются, когда приходит пакет RTCP BYE с соответствующим кодом SSRC, или когда достаточно долго не приходит вообще никаких пакетов. Для того чтобы отслеживать зацикливание собственных пакетов участников, необходимо также завести отдельный список транспортных адресов источников, которые считаются конфликтными. Заметим, что это должен быть короткий список, обычно пустой. Каждый элемент этого списка хранит адрес источника и время, когда был получен последний конфликтный пакет. Элемент может быть удален из списка, когда за время 10 периодов посылки RTCP сообщений-отчетов не прибыло ни одного конфликтного пакета. Предполагается, что собственные идентификаторы и состояния участников записаны в таблицу идентификаторов источников. IF SSRC или CSRC-идентификатор не найден в таблице идентификаторов источников:
THEN создать новую запись и внести туда транспортный адрес источника и SSRC или В этом алгоритме все пакеты от вновь конфликтующих источников будут игнорироваться, а пакеты от исходного источника будут приниматься. Если в течение достаточно протяженного периода времени пакеты от исходного источника не приходят, соответствующая запись в таблице будет аннулирована. Когда из-за столкновения выбран новый SSRC-идентификатор, кандидат-идентификатор должен быть сверен с содержимым таблицы идентификаторов. Если такой код там уже имеется, должен быть выбран другой кандидат и процедура сверки повторена. Зацикливание информационных мультикастинг-пакетов может вызвать сильную перегрузку сети. Все смесители и трансляторы должны реализовывать алгоритм детектирования зацикливания с тем, чтобы немедленно прервать этот опасный процесс. Это должно уменьшить лишний трафик. Однако, в крайних случаях, где смеситель или транслятор не прерывают зацикливание, может быть необходимо для оконечных систем прервать передачу. Когда необходимо шифрование RTP или RTCP, все октеты будут инкапсулированы в одну дейтограмму нижележащего уровня и зашифрованы как единое целое. Для RTCP в начало последовательности перед шифрованием добавляется 32-битное случайное число, чтобы предотвратить возможные атаки. В случае RTP никаких префиксов не требуется, так как порядковый номер и временная метка и без того являются случайными числами. Алгоритмом шифрования по умолчанию является DES (Data Encryption Standard), работающий в режиме CBC (Cipher Block Chaining), как это описано в RFC 1423 [9], за исключением того, что используется заполнение кратное 8 октетам. Инициализационный вектор равен нулю, так как для RTP-заголовка используются случайные числа. Более подробно о векторах инициализации можно прочесть в [10]. Приложения, которые используют шифрование должны поддерживать алгоритм DES в режиме CBC. Этот метод выбран потому, что он показал на практике свою эффективность при работе с аудио и видео приложениями в Интернет. Возможно применение и других криптографических средств. В качестве альтернативы шифрованию на уровне RTP, можно определить дополнительные типы поля данных для шифрованных полей данных в профайлах. Этот метод позволяет шифровать только данные, в то время как заголовки остаются незашифрованными. Это может оказаться полезным для реализации шифрования и дешифрования. Для обеспечения демультиплексирования RTP полагается на нижележащий протокольный уровень. Для UDP и сходных с ним протоколов, RTP использует четные номера портов, а соответствующие RTCP-потоки используют нечетные номера портов. Если приложению предлагается использовать нечетный номер RTP-порта, этот номер должен быть заменен на ближайший четный меньше исходного. Информационные RTP-пакеты не имеют поля длины или каких-либо других средств ограничения размеров пакета, по этой причине RTP полагается на нижележащий протокол при задании размера поля данных. Максимальная длина RTP-пакетов ограничена размером используемых транспортных пакетов (например, UDP). Если RTP-пакеты переносятся посредством протокола, который поддерживает поточный метод передачи, должен быть определен механизм вложения. Механизм вложения должен быть детализован и в случае, когда транспортный протокол использует в поле данных заполнители. Механизм вложения может быть определен в профайле даже в случае, когда для транспортировки RTP используется не поточный протокол, это позволяет укладывать несколько RTP-пакетов в одну дейтограмму транспортного протокола (например, UDP). Передача нескольких RTP-пакетов в одном транспортном уменьшает издержки, связанные с заголовком и может упростить синхронизацию различных потоков. Константы, определяющие тип данных (PT) RTP-пакета, задаются профайлом а не самим протоколом. Однако, значение октета RTP-заголовка, который содержит бит(ы) маркера не должно ни при каких обстоятельствах равняться 200 и 201 (десятичные), для того чтобы отличить RTP-пакеты от RTCP-пакетов типа SR и RR. Использование протокола RTP в различных приложениях может предъявлять различные требования. Адаптация протокола к этим требованиям осуществляется путем выбора определенных параметров, использования различных расширений (см. рис. 4.4.9.2.2) или путем вариации формата на основе профайлов. Типовое приложение использует только один профайл. Спецификация формата поля данных определяет то, например, как, закодированный видеосигнал (H.261) должен переноситься RTP-пакетами. В рамках RTP-стандарта определены следующие элементы поля данных (этот список не следует рассматривать, как окончательный): Заголовок поля данных RTP. Октет RTP заголовка, содержащий маркер тип поля данных, может быть переопределен с помощью профайла (например, можно изменить число маркерных битов). Типы поля данных. Профайл обычно определяет набор форматов поля данных (напр., типов кодирования исходных данных) и соответствие между этими форматами и кодами типа поля данных. Для каждого описанного типа поля данных должна быть определена частота временных меток. Дополнения к заголовку RTP. К стандартному RTP-заголовку могут быть добавлены новые поля, расширяющие функциональность приложения. Расширения заголовка RTP. Структура содержимого первых 16 бит расширения RTP-заголовка должна быть определена профайлом (см. рис. 4.4.9.2.2). Безопасность. Профайл может специфицировать, какие услуги и алгоритмы безопасности должно обеспечить приложение. Установка соответствия между строкой и ключом. Профайл может специфицировать, какому ключу шифрования соответствует введенный пользователем пароль. Нижележащий протокол. Определяется нижележащий транспортный протокол, который служит для пересылки RTP-пакетов. Транспортное соответствие. Соответствие RTP и RTCP адресам транспортного уровня, например, UDP-портам. Инкапсуляция. Инкапсуляция RTP-пакетов может быть определена для того, чтобы позволить транспортировку нескольких RTP-пакетов в одной дейтограмме нижележащего протокола. Не предполагается, что для каждого приложения требуется свой профайл. В пределах одного класса приложений целесообразно использовать расширения одного и того же профайла. Простое расширение, такое как введение дополнительного типа поля данных или нового типа RTCP-пакета, может быть выполнено путем регистрации их через комитет по стандартным числам Интернет и публикации их описаний в приложении к профайлу. Алгоритмы работы отправителя и получателя RTP-пакетов описаны в RFC-1889 на примере кодов, написанных на языке СИ. Нижеприведенные определения заимствованы целиком из RFC, ссылка на который приведена в начале данного раздела. Все цифра представлены в формате, где первым является старший октет. Предполагается, что битовые поля размещаются без заполнителей в том же порядке, что и октеты. /** rtp.h -- Файл заголовка RTP (RFC 1889) */ #include <sys/types.h> /* * Нижеприведенные определения предполагают 32-битовое представление, а в случаях * 16- или 64-битового представлений необходимы соответствующие модификации. */ typedef unsigned char u_int8; typedef unsigned short u_int16; typedef unsigned int u_int32; typedef short int16; /* * Текущая версия протокола. */ #define RTP_VERSION 2 #define RTP_SEQ_MOD (1<<16) #define RTP_MAX_SDES 255 /* максимальная длина текста для SDES */ typedef enum { RTCP_SR = 200, RTCP_RR = 201, RTCP_SDES = 202, RTCP_BYE = 203, RTCP_APP = 204 } rtcp_type_t; typedef enum { RTCP_SDES_END = 0, RTCP_SDES_CNAME = 1, RTCP_SDES_NAME = 2, RTCP_SDES_EMAIL = 3, RTCP_SDES_PHONE = 4, RTCP_SDES_LOC = 5, RTCP_SDES_TOOL = 6, RTCP_SDES_NOTE = 7, RTCP_SDES_PRIV = 8 } rtcp_sdes_type_t; /* * Заголовок RTP-пакета */ typedef struct { unsigned int version:2; /* версия протокола */ unsigned int p:1; /* флаг заполнителя */ unsigned int x:1; /* Флаг расширения заголовка */ unsigned int cc:4; /* число CSRC */ unsigned int m:1; /* Бит маркера */ unsigned int pt:7; /* тип поля данных */ u_int16 seq; /* номер по порядку */ u_int32 ts; /* временная метка */ u_int32 ssrc; /* источник синхронизации */ u_int32 csrc[1]; /* опционный список CSRC */ } rtp_hdr_t; /* * Общее слово RTCP-заголовка */ typedef struct { unsigned int version:2; /* версия протокола */ unsigned int p:1; /* флаг заполнителя */ unsigned int count:5; /* варьируется в зависимости от типа пакета */ unsigned int pt:8; /* тип пакета RTCP */ u_int16 length; /* Длина пакета в словах */ } rtcp_common_t; /* * Маска версии, бита заполнителя и типа пакета */ #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe) #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR) /* * Блок отчета о приеме */ typedef struct { u_int32 ssrc; /* Источник, для которого составлен отчет */ unsigned int fraction:8; /* доля потерянных пакетов с момента последнего SR/RR */ int lost:24; /* полное число потерянных пакетов */ u_int32 last_seq; /* номер последнего полученного пакета */ u_int32 jitter; /* разброс времени прихода пакетов */ u_int32 lsr; /* последний SR-пакет от этого источника */ u_int32 dlsr; /* задержка с момента последнего SR пакета */ } rtcp_rr_t; /* * элемент SDES */ typedef struct { u_int8 type; /* тип элемента (rtcp_sdes_type_t) */ u_int8 length; /* Длина элемента (в октетах) */ char data[1]; /* текст */ } rtcp_sdes_item_t; /* * One RTCP packet */ typedef struct { rtcp_common_t common; /* общий заголовок */ union { /* sender report (SR) */ struct { u_int32 ssrc; /* Отправитель, генерирующий этот отчет */ u_int32 ntp_sec; /* временная метка NTP */ u_int32 ntp_frac; u_int32 rtp_ts; /* временная метка RTP */ u_int32 psent; /* послано пакетов */ u_int32 osent; /* послано октетов */ rtcp_rr_t rr[1]; /* список переменной длины */ } sr; /* Отчет о приеме (RR) */ struct { u_int32 ssrc; /* приемник, формирующий данный отчет */ rtcp_rr_t rr[1]; /* список переменной длины */ } rr; /* описание источника (SDES) */ struct rtcp_sdes { u_int32 src; /* первый SSRC/CSRC */ rtcp_sdes_item_t item[1]; /* список элементов SDES */ } sdes; /* BYE */ struct { u_int32 src[1]; /* список источников */ /* can't express trailing text for reason */ } bye; } r; } rtcp_t; typedef struct rtcp_sdes rtcp_sdes_t; /* * Информация состояния источников */ typedef struct { u_int16 max_seq; /* наибольший зарегистрированный номер */ u_int32 cycles; /* shifted count of seq. number cycles */ u_int32 base_seq; /* основной порядковый номер */ u_int32 bad_seq; /* последний 'плохой' порядковый номер + 1 */ u_int32 probation; /* sequ. packets till source is valid */ u_int32 received; /* пакетов получено */ u_int32 expected_prior; /* пакет, ожидаемый в последнем интервале */ u_int32 received_prior; /* пакет, полученный за последний интервал */ u_int32 transit; /* относительное время передачи для предыдущего пакета */ u_int32 jitter; /* оценка временного разброса */ /* ... */ } source; Получатель RTP-пакета должен проверить корректность заголовка. Здесь следует учитывать, что пакет может быть зашифрован. Если пакет не пройдет данную проверку (например, неверно дешифрован, ошибка в адресе или обнаружен неизвестный тип поля данных), должно быть выработано соответствующее сообщение. Ограниченная проверка допустима только для нового источника:
Последние три проверки достаточно сложны и не всегда возможны. Если SSRC-идентификатор в пакете соответствует одному из полученных ранее, тогда пакет вероятно корректен и следует проверить то, что его порядковый номер лежит в нужном диапазоне. Если SSRC-идентификатор ранее не встречался, тогда данный пакет может рассматриваться некорректным до тех пор, пока не будет получено несколько таких последовательно пронумерованных пакетов. Программа update_seq, приведенная ниже гарантирует, что источник декларирован правильно после получения MIN_SEQUENTIAL последовательно пронумерованных пакетов. Она также проверяет номера пакетов SEQ и актуализует состояние источника пакетов в структуре, на которую указывает S. Когда новый источник дает о себе знать впервые (т.е. его SSRC-идентификатор отсутствует в таблице), и для описания его состояния выделено место в памяти, S->probation должно быть сделано равным числу последовательных пакетов, которые должны быть зарегистрированы до того, как источник будет объявлен легальным (параметр MIN_SEQUENTIAL ), а переменной s->max_seq присваивается значение SEQ-1. s->probation помечает источник как еще нелегальный, так что описание его состояния может быть выброшено после короткой выдержки. После того как источник признан легальным, номер по порядку считается корректным, если он не больше чем на MAX_DROPOUT впереди S->max_seq и не больше на MAX_MISORDER после. В противном случае возвращается нуль, что означает неудачу проверки, а плохой последовательный номер запоминается. Если номер очередного полученного пакета имеет следующий номер по порядку, то он рассматривается как начало новой последовательности (возможно источник рестартовал). Так как при этом теряется много циклов, статистика потерь пакетов сбрасывается. Приведенные типовые значения параметров базируются на максимальном времени сбоя нумерации равном 2 секундам при скорости 50 пакетов/сек и времени таймаута 1 минута. Параметр таймаута MAX_DROPOUT должен соответствовать небольшой доле от 16-битового диапазона нумерации. Таким образом, после рестарта новый номер пакета с большой вероятностью не должен попасть в допустимый диапазон. void init_seq(source *s, u_int16 seq){ s->base_seq = seq - 1; s->max_seq = seq; s->bad_seq = RTP_SEQ_MOD + 1; s->cycles = 0; s->received = 0; s->received_prior = 0; s->expected_prior = 0; /* other initialization */ } int update_seq(source *s, u_int16 seq) { u_int16 udelta = seq - s->max_seq; const int MAX_DROPOUT = 3000; const int MAX_MISORDER = 100; const int MIN_SEQUENTIAL = 2; * * Источник нелегален до тех пор, пока не будет получено MIN_SEQUENTIAL пакетов * с последовательно нарастающими номерами. */ if (s->probation) { /* пакет соответствует последовательности */ if (seq == s->max_seq + 1) { s->probation--; s->max_seq = seq; if (s->probation == 0) { init_seq(s, seq); s->received++; return 1; } } else { s->probation = MIN_SEQUENTIAL - 1; s->max_seq = seq; } return 0; } else if (udelta < MAX_DROPOUT) { /* в порядке, с допустимым зазором */ if (seq < s->max_seq) { /* * Порядковый номер переполнен - начинаем новый 64K цикл. */ s->cycles += RTP_SEQ_MOD; } s->max_seq = seq; } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) { /* порядковый номер изменился слишком сильно */ if (seq == s->bad_seq) { /* * Два последовательных пакета - предполагается, что другая сторона рестартовала, не * предупредив нас об этом. re-sync (т.е., считаем, что получили первый пакет). */ init_seq(s, seq); } else { s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1); return 0; } } else { /* задублированные пакеты или пакеты с перепутанным порядком прихода */ } s->received++; return 1; } Проверка корректности может быть и жестче, требуя более двух пакетов с последовательными номерами подряд. Недостатком такого подхода будут трудности, связанные с каналами, где вероятность потери пакета велика. Однако, так как проверка корректности заголовка RTCP-пакета достаточно строга, можно ограничиться требованием двух последовательных информационных пакетов. Если начальная потеря данных в течение нескольких секунд приемлема, приложение может выбрасывать все информационные пакеты до тех пор, пока не будет получен от источника корректный RTCP-пакет. В зависимости от приложения и используемого кодирования для проверки можно использовать дополнительную информацию о структуре поля данных. Например, для типов данных, где используются временные метки, можно с некоторой точностью предсказывать очередное значение метки на основании знания предыдущей и разности номеров пакетов. Для того чтобы посчитать частоту потерь пакетов, нужно знать ожидаемое и реально полученное число пакетов для каждого из источников. Число полученных пакетов получается простым их подсчетом с учетом возможного дублирования и запаздывания. Ожидаемое число пакетов может быть подсчитано получателем как разность между наибольшим порядковым номером пакета (s->max_seq) и номером первого пакета в последовательности (S->base_seq). При этом нужно учитывать то, что номера имеют 16 бит, и по этой причине могут переполниться (число переполнений хранится в переменной s->cycles). extended_max = s->cycles + s->max_seq;expected = extended_max - s->base_seq + 1; Число потерянных пакетов определяется как разность между ожидаемым и реально полученным числом пакетов: lost = expected - s->received;Доля потерянных пакетов за отчетный период (с момента посылки предыдущего SR или RR пакета) вычисляется из разности ожидаемого и реально полученного числа пакетов за отчетный период, где expected_prior и received_prior представляют собой значения, записанные в момент подготовки предыдущего отчета.: expected_interval = expected - s->expected_prior;s->expected_prior = expected; received_interval = s->received - s->received_prior; s->received_prior = s->received; lost_interval = expected_interval - received_interval; if (expected_interval == 0 || lost_interval <= 0) fraction = 0; else fraction = (lost_interval << 8) / expected_interval; Результирующее значение доли равно 8-битовому числу с фиксированной запятой, расположенной слева. Генерирование псевдослучайных 32-битовых идентификаторов Ниже приведенная подпрограмма (заимствована из RFC-1889) генерирует псевдослучайные 32-битовые идентификаторы, используя программы MD5, опубликованные в RFC-1321 [11]. Системные программы могут и не присутствовать во всех операционных системах, но они помогают понять, какого рода информация может использоваться. o getdomainname() ,o getwd() , или o getrusage() "Живые" видео или аудио сигналы могут быть также не плохим источником случайных числе, при этом только следует позаботиться о том, чтобы микрофон не был отключен, а объектив камеры не был закрыт [7]. Использование этой или другой подобной программы предполагает определенную процедуру инициализации, которая нужна для получения первых псевдослучайных чисел. Так как эта программа заметно загружает процессор, ее непосредственное использование для генерации RTCP-периодов нельзя считать приемлемым. Следует заметить, что данная программа выдает один и тот же результат при последовательных вызовах до тех пор, пока не изменится показание системных часов или не будет задано другое значение аргумента type. /** Генерация псевдослучайного 32-битового числа. */ #include <sys/types.h> u_long */ #include <sys/time.h> /* gettimeofday() */ #include <unistd.h> /* get..() */ #include <stdio.h> /* printf() */ #include <time.h> /* clock() */ #include <sys/utsname.h> /* uname() */ #include "global.h" /* from RFC 1321 */ #include "md5.h" /* from RFC 1321 */ #define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final static u_long md_32(char *string, int length) { MD_CTX context; union { char c[16]; u_long x[4]; } digest; u_long r; int i; MDInit (&context); MDUpdate (&context, string, length); MDFinal ((unsigned char *)&digest, &context); r = 0; for (i = 0; i < 3; i++) { r ^= digest.x[i]; } return r; } /* md_32 */ /* * Полученный результат - 32-битовое число без знака. Используйте аргумент 'type' если вам * нужно получить несколько разных величин подряд. */ u_int32 random32(int type) { struct { int type; struct timeval tv; clock_t cpu; pid_t pid; u_long hid; uid_t uid; gid_t gid; struct utsname name; } s; gettimeofday(&s.tv, 0); uname(&s.name); s.type = type; s.cpu = clock(); s.pid = getpid(); s.hid = gethostid(); s.uid = getuid(); s.gid = getgid(); return md_32((char *)&s, sizeof(s)); } /* random32 */
Библиография
|
||||||||||||||||||||||||
|
Previous:
4.4.9.1 Мультикастинг и MBONE
UP:
4.4 Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.9.3 Транспортный протокол реального времени RTCP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Управляющий протокол RTCP (RTP control protocol; см. RFC-1889 "RTP: A Transport Protocol for Real-Time Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и используется лишь совместно с RTP. Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. RTCP выполняет четыре функции: 1. Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных. Обратная связь может быть непосредственно полезна при адаптивном кодировании [1,2], но эксперименты с IP мультикастингом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP-мультикастинга, сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети. 2. RTCP имеет постоянный идентификатор транспортного уровня для RTP источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы. 3. Первые две функции требуют, чтобы все участники посылали RTCP-пакеты, следовательно скорость передачи должна контролироваться для того, чтобы RTP мог работать с большим числом участников. При посылке каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это число используется при вычислении частоты посылки пакетов. 4. Четвертая опционная функция служит для передачи минимальной управляющей информации, например идентификаторов участников, для графического интерфейса пользователя. Это полезно для "слабо управляемых" сессий, когда участники входят и выходят без должного контроля и без согласования параметров. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он необязательно поддерживает все коммуникационные требования приложения. Функции 1-3 являются обязательными, когда RTP используется в среде с IP мультикастингом, и рекомендательными для всех остальных сред. Разработчикам приложений RTP рекомендуется избегать механизмов, которые могут работать только в уникастном режиме. Формат пакетов RTCP Стандарт определяет несколько типов RTCP пакетов, которые предназначены для переноса управляющей информации:
Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется RTP-пакетами, за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, для того чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол низкого уровня задаст общую длину и определит конец составного пакета. Каждый индивидуальный RTCP пакет в составном пакете может обрабатываться независимо без каких-либо требований к порядку или комбинации пакетов. Однако, для того чтобы выполнить функции протокола накладываются следующие ограничения:
Таким образом, все rtcp-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат: Префикс шифрования. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета. SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP -пакетом в составной дейтограмме является Bye. Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах. SDES. SDES-пакет, содержащий Cname, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционно добавлены, если этого требует характер приложения и позволяет пропускная способность используемого канала. Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться. Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников. Пример составного RTCP-пакета, который может быть сформирован смесителем, представлен на рис. 4.4.9.3.1. Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета. Приложение может игнорировать RTCP пакеты неизвестного ему типа. Дополнительныетипы RTCP-пакетов могут быть зарегистрированы IANA (internet assigned numbers authority).
Рис. 4.4.9.3.1. Пример составного пакета RTCP (#: SSRC/CSRC) Протокол RTP построен так, чтобы позволять приложению изменять число участников от единиц до тысяч. Например, при аудио конференциях информационный поток всегда ограничен (сколько бы не было участников, все они одновременно говорить не могут, так как не смогут ничего понять). Однако, трафик управления таким свойством не обладает. Если доклады о приеме от каждого участника поступают с постоянной частотой, трафик управления будет расти пропорционально числу участников. Следовательно, нужно принимать меры по ограничению трафика. Для каждой сессии предполагается, что предельно допустимый информационный трафик сессии делится между участниками. Эта полоса пропускания может быть зарезервирована. Полоса не зависит от метода кодирования, но на выбор метода кодирования может оказать влияние имеющаяся в распоряжении полоса пропускания используемого канала. Определенные ограничения на полосу сессии может накладывать конкретное приложение. Вычисления полосы пропускания, необходимой для управления, требует учета издержек транспортных протоколов (например, UDP и IP). Трафик управления должен быть ограничен малой долей полной полосы пропускания сессии: настолько малой, чтобы не нанести ущерба основной функции транспортного протокола - переносу информации. Предлагается, чтобы доля трафика сессии, выделенная на RTCP была фиксирована на уровне не более 5%. Параметры, определяющие трафик, должны быть идентичными для всех участников, так чтобы они могли корректно вычислить период рассылки отчетов. Эти параметры фиксируются в соответствующем профайле. Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты: o Отправители коллективно выделяют по крайней мере 1/4 управляющего трафика, так чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали cname узлов отправителей. o Вычисленный интервал между RTCP-пакетами должен быть больше 5 сек, с тем чтобы избежать превышения допустимого значения трафика при флуктуациях информационного потока, когда число участников мало. o Интервалы между RTCP-пакетами варьируются случайным образом в пределах [0.5-1.5] от вычисленного значения, с тем чтобы избежать непреднамеренной синхронизации работы участников [3]. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала. o Для того чтобы адаптироваться к количеству пересылаемой контрольной информации, вычисляется среднее значение размера составного пакета для отправляемых и получаемых дейтограмм. Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания RTCP должна быть равна 5% от этого значения. Вычисление периода рассылки RTCP-пакетов зависит от оценки числа узлов, участвующих в сессии. Новые узлы добавляются к этому числу, когда они услышаны и соответствующие записи занесены в таблицы SSRC или CSRC-идентификаторов. Новые записи не рассматриваются, как действующие, до тех пор, пока не будет получено несколько пакетов с новым SSRC. Записи могут быть стерты из таблицы, когда приходит пакет RTCP Bye с соответствующим идентификатором SSRC. Участник может пометить другой узел как пассивный, или удалить его из списка, если от него не получено RTP или RTCP-пакетов в течение нескольких периодов RTCP-отчетов (пороговое число периодов предлагается сделать равным 5). Это обеспечивает определенную устойчивость против случайной потери пакетов. Все узлы должны вычислить период RTCP-отчетов, чтобы корректно оценить время тайм-аута. Если зарегистрированный узел помечен как пассивный, он будет оставаться в списках достаточно долго и учитываться при вычислении распределения полосы пропускания для RTCP. Значение тайм-аута предлагается сделать равным 30 минутам. Заметим, что это значение почти в 5 раз больше, чем наибольшая величина периода рассылки RTCP-отчетов, который составляет 2-5 мин. Данная спецификация определяет несколько элементов описания источника (SDES). Сюда входит CNAME (каноническое имя), Name (персональное имя) и Email (электронный адрес). Спецификация предлагает также средства для определения типа RTCP-пакетов, специфического для конкретного приложения. Приложения должно проявлять определенную осторожность при выделении полосы для любой дополнительной информации, так как это неизбежно вызовет замедление скорости предоставления отчетов и задержит присылку. Рекомендуется, чтобы дополнительная информация индивидуального участника не занимала более 20% полосы, выделенной для RTCP. Более того, даже не предполагается, что все элементы SDES будут включаться каждым приложением. Например, приложение может посылать только CNAME, name и email и не посылать более никакой дополнительной информации. name может быть присвоен более высокий приоритет чем email, так как name будет отображаться пользовательским интерфейсом приложения постоянно, в то время как Email может отображаться только при запросе. При каждой RTCP рассылке, должны посылаться RR- и SDES-пакеты. Последний содержит элемент Cname. Для небольших сессий, работающих с минимальными периодами рассылки, это будет делаться в среднем каждые 5 секунд. Каждая третья рассылка (15 секунд) может содержать один дополнительный элемент в пакете SDES. Семь из восьми раз это будет элемент name, и каждый восьмой раз (2 минуты) это будет элемент Email. Когда несколько приложений работают одновременно, например, в случае мультимедиа конференции, допускается, чтобы дополнительная информация пересылалась только в рамках одной RTP-сессии. Остальные сессии будут использовать только элемент cname. RTP-получатели обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственным различием между формами отчета отправителя (SR) и получателя (rr), помимо кода типа пакета, является то, что отчет отправителя содержит 20-байтовую секцию информации об отправителе. SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отправляется пакет RR. Как SR так и RR-формы включают в себя нуль или более блоков отчетов о приеме, один для каждого источника синхронизации, от которого получатель принял информационные RTP-пакеты с момента последнего отчета. Отчеты не направляются для источников, перечисленных в списке CSRC. Каждый блок отчета о приеме содержит статистику данных, полученных от конкретного источника. Так как в SR или RR-пакет можно поместить максимум 31 блок отчетов, дополнительные RR-пакеты укладываются после исходного SR или RR-пакета. Пакет отчета отправителя состоит из трех секций (см. рис. 4.4.9.3.2), за которыми может следовать четвертая, которая определяется, если необходимо, профайлом. Первая секция - заголовок, имеет 8 октетов. Эта секция содержит следующие поля: Версия (v): 2 бита Идентифицирует версию протокола RTP, которая совпадает с версией RTCP-пакетов. Для данной спецификации v=2. Заполнитель (p): 1 бит Если бит заполнителя p=1, то этот пакет RTCP содержит некоторые октеты заполнителя после управляющей информации. Последний октет заполнителя содержит число октетов заполнителя. Заполнитель может быть нужен при некоторых алгоритмах шифрования, использующих фиксированные блоки. В составных RTCP-пакетах, заполнитель может быть нужен только последнему пакету, так как составной пакет шифруется как целое.
Рис. 4.4.9.3.2. Формат RTCP пакета сообщения отправителя Число отчетов о приеме (RC): 5 бит Число блоков отчетов о приеме, содержащихся в этом пакете. Допустимо значение нуль. Тип пакета(pt): 8 бит Содержит константу 200 для пакетов RTCP SR. Длина: 16 бит Длина rtcp-пакета в 32-битных словах минус один, включая заголовок и заполнитель. ssrc: 32 бит Идентификатор источника синхронизации для отправителя sr-пакета. Вторая секция информации из 20 октетов присутствует в каждом пакете отправителя. Поля этой секции имеют следующие значения: Временная метка NTP: 64 бита Указывает абсолютное время, когда данный доклад был послан, оно может быть использовано в комбинации с временными метками, присланными в докладах о приеме другими получателями, для измерения RTT до этих получателей. Временная метка rtp: 32 бита Соответствует тому же времени, что и временная метка ntp, но измеряется в тех же единицах и с тем же произвольным смещением, что и временные метки информационных пакетов RTP. Это соответствие может использоваться для внутри- и межсредовой синхронизации для источников, чьи временные метки NTP синхронизованы, и может быть использовано получателями, независящими от среды для оценки номинальной задающей частоты RTP. Заметьте, что в большинстве случаев эти временные метки не будут равны временным меткам RTP в любых последовательных информационных пакетах. Число пакетов отправителя: 32 бита Полное число информационных RTP-пакетов, переданных отправителем от начала передачи до момента генерации SR-пакета. Число сбрасывается в нуль, если отправитель изменяет свой SSRC-идентификатор. Число октетов отправителя: 32 бита Полное число октетов поля данных (исключая заголовки и заполнители), переданных в информационных RTP-пакетах отправителем, начиная с начала передачи до момента генерации SR-пакета. Это число сбрасывается в нуль, когда отправитель меняет свой SSRC-идентификатор. Это поле может быть использовано для оценки среднего потока данных. Третья секция состоит из нуля или более блоков отчета о приеме в зависимости от числа источников, пакеты от которых приняты с момента последнего отчета. Каждый блок отчета о приеме несет в себе статистику получения RTP-пакетов, поступающих от одного из источников синхронизации. Получатель не сохраняет статистику, когда источник изменяет свой ssrc-идентификатор. ssrc_n (идентификатор источника): 32 бита ssrc-идентификатор источника, к которому относится информация, содержащаяся в блоке отчета о получении. Доля потерянных (пакетов): 8 бит Часть информационных RTP-пакетов от источника ssrc_n потерянная с момента посылки предыдущего SR или RR-пакетов, представленная в виде числа с фиксированной запятой, помещенной слева. Это эквивалентно целому, полученному после умножения данного числа на 256. Эта доля получается в результате деления числа потерянных пакетов на ожидаемое число пакетов. Если потери из-за дубликатов оказались отрицательны, доля потерянных пакетов объявляется равной нулю. Заметим, что от источника, все пакеты которого были потеряны при транспортировке отчета о приеме послано не будет. Суммарное число потерянных пакетов: 24 бита Полное число информационных RTP-пакетов от источника SSRC_n, которые были потеряны с момента начала передачи. Это число определяется как разность между ожидаемым и полученным числами пакетов, где число полученных включает в себя и дубликаты. Таким образом, пакеты, пришедшие с опозданием, не считаются потерянными, а число потерянных пакетов может оказаться отрицательным, если получены дубликаты пакетов. Число ожидаемых пакетов определяется как разность между номером последнего полученного пакета и номером первого пакета. Наибольший номер из числа полученных пакетов: 32 бита Младшие 16 бит содержит наибольший порядковый номер полученного от источника SSRC_n информационного RTP-пакета. Старшие 16 бит несут в себе число циклов нумерации (переполнения счетчика номеров пакетов). Заметим, что различные получатели в рамках одной и той же сессии генерируют разные коды циклов нумерации (расширений), если они начали свою работу в разное время. Разброс времени доставки: 32 бита Оценка статистической вариации периода прихода RTP-пакетов, измеряемого с помощью временных меток и характеризуемого целым числом. Разброс периода прихода пакетов j определяется как усредненное отклонение разности D расстояния между пакетами со стороны получателя по отношению к той же величине для стороны отправителя. Эта величина характеризует относительный разброс времени транспортировки пакетов. Если si равно временной метке i-го пакета RTP, а ri - время прибытия в единицах временной метки пакета i, тогда для двух пакетов i и j D может быть выражено как di,j =(rj-ri)-(sj-si)=(rj-sj)-(ri-si) Разброс времени доставки вычисляется непрерывно для каждого пребывающего от SSRC_n пакета i, используя разность D для данного пакета и предыдущего пакета i-1 согласно формуле j=j+(|d i-1,i |-j)/16 Вычисление разброса времени доставки позволяет мониторам, независимым от профайла, осуществлять интерпретацию докладов, приходящих от различных приложений. Это алгоритм является оптимальным первым приближением и масштабный параметр 1/16 обеспечивает приемлемое уменьшение влияние шума и разумную скорость сходимости [4]. Последняя временная метка (LSR) (last SR): 32 бита Средние 32 бита из 64 во временной метке NTP, полученной как часть последнего отчета RTCP-отправителя (SR) об источнике SSRC_n. Если SR пока не получено, в поле заносится нуль. Задержка с момента последнего SR (DLSR- delay of last sr): 32 бита Задержка, выраженная в единицах 1/65536 секунды, между моментом получения последнего SR-пакета от источника SSRC_n и временем посылки блока отчета о приеме. Если ни одного пакета SR от ssrc_n пока не получено, в поле DLSR заносится нуль. Пусть SSRC_r обозначает получателя, отправляющего отчет о приеме. Источник SSRC_n может вычислить циклическую задержку маршрута RTT для SSRC_r путем записи времени a, когда этот блок доклада о приеме был получен. Он вычисляет полное время RTT A-LSR, используя поле последней временной метки SR (LSR), и затем путем вычитания получает (A - LSR- DLSR). Это проиллюстрировано на рис. 4.4.9.3.3. Это может быть использовано в качестве меры расстояния до кластера получателей, хотя некоторые связи имеют весьма асимметричный характер задержек. rr: rtcp-пакет отчета о приеме (RFC-1889) [10 nov 1995 11:33:25.125] [10 nov 1995 11:33:36.5] Рис. 4.4.9.3.3. Пример вычисления rtt
Рис. 4.4.9.3.4. Формат пакета отчета о приеме (RR) Формат пакета отчета о приеме (RR) аналогичен формату SR пакета за исключением того, что поле типа содержит код 201 и опущены первые пять слов информации об отправителе (это NTP/RTP временные метки, а также число пакетов и октетов отправителя). Остальные поля имеют то же самое значение, как и для пакета SR. Когда нет информации об отправке или приеме, в начало составного RTCP-пакета вставляется пустой RR-пакет (RC = 0). Профайл должен определять специфические для приложения расширения в докладах получателей и отправителей, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно сообщаться. Этот метод предпочтительнее, чем описание нового типа RTCP-пакета, так как не требует дополнительных издержек:
Если необходима дополнительная информация, она должна быть включена в первую очередь в расширение для отчета отправителя, но не будет присутствовать в отчетах о приеме. Если должна быть подключена информация о получателях, эти данные могут структуризоваться в виде массива блоков дополнительно к существующему массиву блоков-отчетов, т.е., число блоков будет задано полем RC. Ожидается, что качество обратной связи важно не только для отправителя и получателей, но и для независимых мониторов. Отправитель может модифицировать свою передачу на основе обратной связи, получатели могут определить, являются ли проблемы локальными, региональными или глобальными. Менеджер сети может использовать независимые мониторы, которые получают только RTCP-пакеты, а не соответствующие информационные RTP-пакеты, для оценки эксплуатационных параметров своей сети для мультикастного обмена. На основе информации отправителя независимый монитор может вычислить усредненное значение потока данных, не получая этих данных. Если можно предположить независимость вероятности потери пакета от его размера, тогда число полученных пакетов, умноженное на средний размер поля данных, может дать оценку для пропускной способности получателя. Для RTCP допустимо расщепление составных пакетов на пакеты нижележащего уровня, один зашифрованный и один открытый. Например, информация SDES может быть зашифрована, в то время как отчеты о приеме будут посылаться открыто для обеспечения мониторинга. В примере, представленном на рис. 4.4.9.3.5 информация SDES должна быть присоединена к RR-пакету, не содержащему отчета. Таким образом, соблюдается правило о том, что все составные пакеты начинаются с SR или RR пакетов.
Рис. 4.4.9.3.5. Зашифрованный и незашифрованный RTCP-пакеты (#ssrc) SDES: RTCP-пакет описания источника
Рис. 4.4.9.3.6. Формат пакета SDES Пакет SDES состоит из заголовка и нескольких фрагментов, каждый из которых содержит элементы описания источника, соответствующего данному фрагменту (число фрагментов может быть равно нулю). Поля версия (v), заполнитель (p) и длина имеют то же назначения что и в случае SR-пакетов. Тип пакета (pt): 8 бит Содержит константу 202, которая идентифицирует данный пакет как RTCP SDES. Число источников (SC): 5 бит Число фрагментов SSRC/CSRC, содержащихся в данном SDES-пакете. Значение нуль допустимо, но бесполезно. Каждый фрагмент состоит из идентификатора SSRC/CSRC, за которым следует список элементов описания источника SSRC/CSRC (число элементов может равняться нулю). Каждый фрагмент начинается на 32-битовой границе. Каждый элемент состоит из 8-битового поля типа, 8-битового поля числа октетов, характеризующего длину текста, исключая эти 2 октета заголовка, и собственно текста. Заметьте, что текст не может содержать более 255 октетов, но это вполне согласуется с требованиями ограничений на полосу, выделяемую для RTCP-пакетов. Текст кодируется согласно требованиям UTF-2, описанным в стандарте 10646 [5,6], annex F ISO. Эта кодировка известна также под названием UTF-8 или UTF-FSS. Она описана в документе "File System Safe UCS Transformation Format (FSS_UTF)", "X/open preliminary specification", документ номер P316 и "Unicode Technical Report #4". US-ASCII являются модификациями данного кодирования и требуют определенных доработок. Присутствие многооктетного кодирования задается путем установления старшего бита октета символа равным 1. Описания элементов плотно прилегают друг к другу, т.е., их описания не выравниваются на 32-битовые границы путем индивидуального заполнения. Текст не завершается нулем, так как мультиоктетное кодирование может включать в себя нули. Список элементов в каждом фрагменте завершается одним или несколькими нулевыми октетами, первый из которых интерпретируется как тип элемента нуль, завершающий список, а последующие служат для заполнения до 32-битовой границы. Фрагменты, содержащие только нулевые элементы (4 нулевых октета), допускаются, но бесполезны. Оконечные системы посылают один пакет SDES, содержащий их собственный идентификатор источника (то же, что и SSRC в фиксированных RTP-заголовках). Смеситель посылает один пакет SDES, содержащий фрагмент для каждого источника, от которого поступает SDES-информация, или несколько SDES-пакетов описанного выше формата в случае, когда число таких источников больше 31. Из числа SDES-элементов только cname является обязательным. Некоторые элементы, описанные ниже, могут оказаться полезными только для определенных профайлов, но типы элементов выделяются из общего кодового пространства, с тем чтобы обеспечить совместную работу различных приложений. Дополнительные элементы могут быть определены в профайле путем регистрации их кодов IANA. cname: Канонический идентификатор конечной системы (рис. 4.4.9.3.7).
Рис. 4.4.9.3.7. Формат Cname Идентификатор cname имеет следующие свойства:
Следовательно, cname должно по возможности получаться алгоритмически, а не вводиться вручную. Чтобы удовлетворить этому требованию следует использовать описанный ниже формат, если другой синтаксис или семантика не задана. Элемент cname должен иметь формат "user@host", или "host", если имя пользователя не доступно, как это бывает в однопользовательских системах. Для обоих форматов, "host" является либо полным именем домена ЭВМ, откуда поступают данные в реальном масштабе времени, форматированные согласно требованиям документов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [9]; или стандартным ASCII-представлением цифрового, сетевого адреса интерфейса ЭВМ, используемого для RTP-обмена. Например, стандартное ASCII-представление IP-адреса (версия 4) в "точечно-цифровом" виде. Стандартное полное имя домена более удобно для человека и исключает необходимость посылать в дополнение элемент Name, но в некоторых обстоятельствах его может быть трудно или невозможно получить. Примерами могут служить "dwarf@sleepy.beauty.com" или "dwarf@192.166.148.9" для мультипользовательских систем. В системах, где нельзя получить имя пользователя, можно применить "sleepy.beauty.com" или "192.166.148.9". Имя пользователя должно иметь форму, которая может быть использована в запросах "Finger" или "Talk", т.е., это скорее имя, вводимое при аутентификации, чем истинное имя пользователя. Имя ЭВМ не обязательно идентично электронному почтовому адресу участника. Этот синтаксис не обеспечит уникальность имени в тех случаях, когда приложение позволяет пользователю сформировать несколько источников на своей ЭВМ. Такое приложение должно полагаться на SSRC для дополнительной идентификации источника, или на профайл, для которого приложение должно будет специфицировать синтаксис идентификаторов cname. Если каждое приложение создает свои cname независимо, в результате можно получить дублирующие имена. Если необходимо осуществить связь между сессиями, работающими в разных средах, должны быть использованы специальные средства, которые с одной стороны обеспечат уникальность имен, а с другой припишут идентичные имена источникам, размещенным в одной ЭВМ, но работающих с разными средами. Разработчики приложений должны учитывать возможность того, что использование сетевого адреса, например, для Net-10 (описано в документе RFC-1597 [10]) может привести к появлению имен дубликатов. Дубликаты имен могут возникать, когда ЭВМ с частными адресами, не имеющие выхода в Интернет, переадресуют свои RTP-пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-1627 [11].) Для того чтобы разрешать такие конфликты приложение должно иметь средства для выработки и присвоения уникальных имен cname. Name: Имя пользователя (рис. 4.4.9.3.8).
Рис. 4.4.9.3.8. Формат элемента Name Это настоящее имя, используемое для описания источника, напр., "Иван Дурак, russia.com". Оно может быть сформировано пользователем в произвольной форме. Для приложений типа конференций эта форма имени может быть наиболее желательной при отображении в списках участников и, следовательно, может посылаться более часто, чем любые другие элементы помимо cname. Такой приоритет может быть установлен профайлом. Значение name предполагается неизменным, по крайней мере в пределах сессии. В то же время не требуется, чтобы оно было уникальным для группы участников сессии. Email: Адрес электронной почты (рис. 4.4.9.3.9).
Рис. 4.4.9.3.9. Формат элемента Email Адрес электронной почты должен иметь формат, согласующийся с требованиями документа RFC-822 [12], например, "yuri.semenov@itep.ru". Значение элемента Email предполагается неизменным в пределах сессии. phone: Телефонный номер
Рис. 4.4.9.3.10. Формат элемента phone Телефонный номер должен иметь формат с символом плюс, замещающим международный код. Например, , "+7 095 129 9442" для номера в России. LOC: Географический адрес пользователя
Рис. 4.4.9.3.11. Формат элемента LOC Различная детализация этого элемента сильно зависит от приложения. Для использования во время конференций строки типа "Zuzino, Moscow" может быть достаточно, в то время как для активной системы поиска сотрудников приемлемой может стать строка "room 322, itep bl 180". Значение LOC предполагается неизменным на время сессии. Исключение могут составлять мобильные ЭВМ. TOOL: Имя приложения или программного средства
Рис. 4.4.9.3.12. Формат элемента TOOL Строка, сообщающая имя и, возможно, версию приложения, формирующего поток, напр., "VC 2.1". Эта информация может быть полезной для отладочных целей и сходна с SMTP-заголовками. Предполагается, что значение TOOL остается постоянным в течение сессии. Note: Уведомление/статус
Рис. 4.4.9.3.13. Формат элемента Note Для этого элемента предлагается следующая семантика (она может быть определена профайлом). Элемент note предназначен для сообщений, характеризующих текущее состояние источника, напр., "on the phone, can't talk". Или, во время семинара этот элемент может быть использован для передачи темы обсуждения. Он может служить только для передачи необычной информации и не должен включаться в систематическую рассылку, так как замедлит скорость передачи отчетов. В частности, он не должен включаться в конфигурационный файл пользователя. Так как может быть важно отобразить элемент Note (в случае, когда он активен), скорость, с которой передаются другие элементы (кроме cname), такие как Name, может быть уменьшена с тем, чтобы передать элемент Note. Когда сообщение становится не актуальным, элемент note передается еще несколько раз с той же частотой, но с длиной строки, равной нулю. Однако, получатели должны рассматривать элемент Note потерявшим актуальность, если они не получают его, например, на протяжении 20-30 RTCP-интервалов. PRIV: Элемент частного расширения SDES
Рис. 4.4.9.3.14. Формат элемента расширения PRIV Этот элемент используется, для того чтобы определить экспериментальные или специфические для приложения расширения SDES. Элемент содержит префикс, включающий в себя субполя длины и строки префикса, за которыми следует строка значения, занимающая остальное пространство элемента, и несущая необходимую информацию. Поле длины префикса занимает 8 бит. Строка префикса представляет собой имя, определенное человеком, который сформировал элемент PRIV. Это имя должно быть уникальным и никакой другой элемент priv не может иметь такое же. Разработчик приложения может выбрать имя приложения плюс, если необходимо, дополнение. Заметьте, что префикс занимает некоторое место, из числа 255 октетов элемента, по этой причине желательно, чтобы он был короче. Префиксы SDESpriv не нужно регистрировать в IANA. Если некоторая форма элемента PRIV окажется достаточно универсальной, она должна быть приписана некоторому регулярному типу элемента SDES, зарегистрированному IANA, так что необходимость в префиксе отпадет. Это упростит использование и увеличит эффективность передачи. Bye: Пакет завершения сессии RTCP
Рис. 4.4.9.3.15. Формат пакета Bye Пакет Bye указывает на то, что один или более источников покинули сессию. Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов Тип пакета (PT): 8 бит Содержит код 203, который указывает на то, что это RTCP пакет Bye. Число источников (SC): 5 бит Число фрагментов SSRC/CSRC, содержащихся в данном bye-пакете. Значение нуль допустимо, но бесполезно. Если пакет bye получен смесителем, он переадресует этот пакет с идентификаторами SSRC/CSRC без изменений. Если сам смеситель отключается, он должен послать пакет Bye, перечислив все источники, вносившие вклад в поток, с которым он работал, а также свой идентификатор SSRC. Опционно пакет Bye может содержать 8-битовое число октетов, за которым следует текст соответствующей длины, объясняющий причину отключения, например "camera malfunction" или "RTP loop detected". Строка имеет то же кодирование, что описано для SDES. Если строка заполняет пакет до очередной 32-битовой границы, то в конце ее не будет нуля. В противном случае, пакет Bye дополняется нулевыми октетами. app: RTCP-пакет, определенный приложением
Рис. 4.4.9.3.16. Формат пакета, задаваемого приложением Пакет APP предназначен для экспериментального использования при разработке новых приложений или новых функций. Здесь не требуется регистрация типа пакета. APP-пакеты с не узнанными именами должны игнорироваться. После тестирования, когда предполагается широкое использование, рекомендуется новый APP-пакет переопределить без субтипа и поля имени, после чего его следует зарегистрировать в IANA (Internet Assigned Numbers Authority), как новый тип RTCP-пакета. Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов. Субтип: 5 бит Может использоваться в качестве субтипа, допуская описание набора APP-пакетов с уникальным именем, или для любых данных, специфических для конкретного приложения. Тип пакета (PT): 8 бит Содержит код 204, который указывает на то, что это RTCP пакет APP. Имя: 4 октета Имя, выбираемое разработчиком, который определил набор APP-пакетов. Это имя должно быть уникальным и не совпадать ни с одним другим именем другого APP-пакета данного приложения. Разработчик приложения может использовать для данной цели имя приложения. При этом новые типы пакетов приложения будут отличаться друг от друга кодом субтипа. Имя интерпретируется как последовательность четырех ASCII-символов, где строчные и прописные буквы не являются тождественными. Поле информация, зависящая от приложения имеет переменную длину. Информация, зависящая от приложения используется в APP-пакетах опционно. Она интерпретируется приложением, а не самим RTP. Размер поля должен быть кратным 32 бит. Обработка RTCP в трансляторах Кроме переадресации информационных пакетов (иногда с некоторой модификацией) трансляторы и мультиплексоры должны также обрабатывать RTCP-пакеты. Во многих случаях они разделяют на составные части комбинированные RTCP-пакеты, полученные от оконечных систем, собирают SDES-информацию и модифицируют SR или RR-пакеты. Пересылка этой информации может инициироваться приходом пакета или RTCP-таймером транслятора или смесителя. Транслятор, который не модифицирует информационные пакеты, например такой, который осуществляет связь между мультикастными и уникастными адресами, может просто переадресовывать RTCP-пакеты. Транслятор, который каким-то образом модифицирует поле данных, должен выполнить соответствующие преобразования в SR и RR-информации, так чтобы она отражала качество приема. Такие трансляторы не должны просто переадресовывать RTCP-пакеты. Вообще транслятор не должен объединять SR и RR-пакеты от различных источников, так как это ухудшит точность измерения задержки распространения, использующего поля LSR и DLSR. Информация отправителя SR. Транслятор не генерирует своей собственной информации отправителя, а переадресует SR-пакеты, полученные из одной области и адресованные в другие области. SSRC остается неизменным, но, если необходима трансляция, информация отправителя должна быть модифицирована. Если транслятор изменяет кодировку данных, он должен изменить поле число октетов отправителя. Если он объединяет несколько информационных пакетов в один, то нужно изменить поле число пакетов отправителя. Если он изменяет частоту временных меток, нужно модифицировать поле временная метка RTP в SR-пакете. Блоки отчетов о приеме SR/RR: Транслятор переадресует доклады о приеме, полученные из одной области сети в другие. Заметим, что эти сообщения движутся в направлении противоположном данным. SSRC при этом остается неизменным. Если транслятор объединяет несколько информационных пакетов в один выходной пакет, и, следовательно, изменяет номер по порядку, он должен позаботиться о модификации полей потерянных пакетов и наибольший номер из числа полученных пакетов. Транслятор не нуждается в своем собственном SSRC-идентификаторе, но может и завести такой идентификатор, для того чтобы посылать отчеты о том, что получено. Такие отчеты будут посылаться во все области сети, подключенные к транслятору. SDES. Трансляторы осуществляют переадресацию без изменения SDES-информации, полученной из сетевых областей, участвующих в сессии. Но они могут, например, решить отфильтровывать некоторую информацию, если этого требуют ограничения пропускной способности. Транслятор, который генерирует свои собственные RR-пакеты, должен посылать SDES CNAME-информацию о самом себе в область сети, куда он шлет эти RR-пакеты. BYE. Трансляторы переадресуют пакеты BYE без изменений. Трансляторы, имеющие свой собственный SSRC должны генерировать пакеты BYE с этим SSRC-идентификатором, если они намереваются прекратить свою работу по переадресации. APP. Трансляторы переадресовывают APP-пакеты без каких-либо изменений. Обработка RTCP в смесителях Так как смеситель генерирует, свой собственный информационный поток, он не пропускает через себя SR или RR-пакеты и вынужден формировать новые пакеты для отправки в обоих направлениях. Информация отправителя SR. Смеситель не пропускает через себя данные об отправителе от источников, которые он объединяет, так как характеристики потока при смешении кардинально меняются. Как источник синхронизации смеситель генерирует свои собственные SR-пакеты с информацией отправителя и посылает их в том же направлении, что и смешанный поток. Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую. SDES. Смесители обычно переадресуют без изменений SDES-информацию, которую они получают из сетевых областей зоны обслуживания, но могут отфильтровывать любую SDES-информацию помимо CNAME в случае ограничения полосы пропускания. CNAME должны доставляться, чтобы обеспечить работу по обслуживанию столкновений идентификаторов SSRC. (Идентификатор в списке CSRC, сгенерированный смесителем может вызвать столкновение с SSRC-идентификатором, сформированным оконечной системой.) Смеситель должен послать SDES CNAME информацию о самом себе той сетевой области, куда он посылает SR или RR пакеты. Так как смесители не переадресуют SR или RR пакеты, они обычно извлекают SDES-пакеты из составных RTCP-пакетов. Для того чтобы минимизировать издержки, фрагменты из SDES-пакетов могут быть уложены в один SDES-пакет, который вкладывается в SR или RR пакет, посылаемый смесителем. Смеситель, который не вводит идентификаторы CSRC, может также воздерживаться от пересылки SDES CNAME. В этом случае пространства идентификаторов SSRC для обоих сетевых областей оказываются независимыми. BYE. Смесители должны переадресовывать пакеты BYE. Они должны генерировать пакеты BYE со своим собственным идентификатором SSRC, если они намериваются прервать пересылку пакетов. APP. Обработка APP-пакетов смесителями зависит от вида приложения. Таблица 4.4.9.3.1. Типы пакетов RTCP
Эти значения типов были выбраны в диапазоне 200-204 для улучшенного контроля корректности заголовков RTCP пакетов. Когда поле типа пакета RTCP сравнивается с соответствующим октетом RTP-заголовка, этот диапазон соответствует маркерному биту 1 (который обычно отсутствует в информационных пакетах) и старшему биту стандартного поля типа данных равному 1 (так как статические типы поля данных обычно лежат в младшей половине). Другие константы определены IANA. Экспериментаторам предлагается зарегистрировать числа, которые им нужны, а затем аннулировать регистрацию, если необходимость в них отпадет. Таблица 4.4.9.3.2. Типы SDES
Типы пакетов RTCP. Могут быть определены и зарегистрированы IANA новые, специфические для определенных классов приложений типы пакетов RTCP. Период отчетов RTCP. Профайл должен специфицировать, какие значения констант будут использоваться для вычисления периода посылки RTCP докладов. Это доля полосы пропускания выделенная для RTCP, минимальный период посылки отчетов. Расширения SR/RR. Секция расширения может быть определена для RTCP SR и RR пакетов, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно передаваться. Проверка корректности заголовка RTCP Пакеты RTCP подвергаются следующим проверкам.
Фрагмент приведенной ниже программы выполняет все рассмотренные проверки (текст взят из ссылки, приведенной в начале раздела). Тип пакета для последующих пакетов не проверяется, так как не известный тип пакета должен игнорироваться. u_int32 len; /* Длина составного RTCP пакета в
словах */ Генерирование пакетов SDES RTCP Эта функция формирует фрагмент SDES, состоящий из элементов argc, взятых из массивов type, в буфере b. char *rtp_write_sdes(char *b, u_int32 src, int argc, Разбор пакетов RTCP SDES Эта функция осуществляет разбор пакета SDES, вызывая функции find_member() для поиска указателя на информацию для члена сессии с идентификатором SSRC и member_sdes() для запоминания новой информации SDES для этого участника. Этой функции необходим указатель на заголовок пакета RTCP. void rtp_read_sdes(rtcp_t *r) Вычисление периода рассылки RTCP Следующая функция в качестве результата выдает время между посылками RTCP-пакетов, измеренное в секундах. Она должна вызываться после посылки одного составного RTCP-пакета для вычисления времени до посылки следующего пакета. Эта функция должна также вызываться для вычисления времени посылки первого RTCP-пакета при запуске. Это исключает любые кластеры RTCP-пакетов, если приложение запущено в нескольких узлах одновременно, например, в результате объявления об открытии сессии. Параметры имеют следующий смысл: rtcp_bw: Предельная полоса RTCP, т.е., полная пропускная способность, которая будет использоваться для RTCP-пакетов всеми участниками сессии, выраженная в октетах в секунду. Она должна быть порядка 5% от "полосы сессии", этот параметр задается при конфигурировании приложения. senders: Число активных отправителей на момент посылки последнего отчета, известно из конструкции отчетов получателя. members: Оценка числа членов сессии, включая нас самих. Инкрементируется, когда мы обнаруживаем новых членов сессии при получении RTP или RTCP-пакетов, и декрементируется, когда какой-либо участник покидает сессию (послав RTCP BYE) или он объявлен таковым по тайм-ауту (рекомендуемое время 30 минут). При первом вызове этот параметр должен иметь значение 1. we_sent: Флаг, который равен true, если мы послали данные за время последних двух интервалов RTCP. Если флаг равен true, составной только что посланный пакет RTCP содержит SR пакет. packet_size: Размер составного только что посланного пакета RTCP, в октетах, включая сетевую инкапсуляцию (напр., 28 октетов для UDP поверх IP). avg_rtcp_size: Указатель оценщика размера составных пакетов RTCP; инициализируется и актуализуется для только что посланного пакета этой функцией, актуализуется также идентичной строкой программы приема пакетов RTCP для каждого пакета RTCP, полученного от другого участника сессии. initial: Флаг, который равен true для первого вызова при инициализации с целью вычисления момента посылки первого отчета. #include t = (*avg_rtcp_size) * n / rtcp_bw; /* Библиография
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.9.2 Протокол реального времени RTP
UP:
4.4 Интернет
|
|
|
|||||||||||||||||||||
|
4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||
|
DVMRP - (Distance Vector Multicast Routing Protocol) мультикастинг-протокол, где в качестве метрики применен вектор расстояния (см. также описание RIP, RFC-1058). DVMRP использует идеологию документа RFC-1054, а также алгоритм TRPB (Truncated Reverse Path Broadcasting). При получении первого пакета маршрутизатор не имеет информации о группе. Он посылает полученный пакет через все интерфейсы, кроме того, через который этот пакет получен. Если пакет пришел не через интерфейс, который используется маршрутизатором для посылки пакетов отправителю мультикаст-информации, полученный пакет выбрасывается. При получении пакета маршрутизатором, в зоне ответственности которого нет членов группы, он посылает сообщение об исключении (prun-команда). Эти сообщения используются для отсечения от дерева маршрутов веток, не содержащих членов группы. По истечении определенного времени "отрезанные" ветки дерева маршрутов "отрастают" вновь и снова могут быть отсечены (протокол TRPB). В настоящее время этот протокол рассматривается в качестве экспериментального и его широкое применение не рекомендуется. DVMRP относится к внутренним протоколам маршрутизации, пригодным для использования в пределах автономной системы. Протокол DVMRP используется для построения дерева мультикасинг-маршрутов. Предполагается, что в дальнейшем принцип "вектора расстояния" может быть заменен алгоритмом "состояния канала" (MOSPF аналог OSPF). Целью протокола DVMRP является описание обратного пути к источнику мультикастинг-дейтограмм. Протоколы состояния канала предполагают широковещательную рассылку информации о членстве в группе. При получении мультикаст-пакета маршрутизатор определяет дерево кратчайших маршрутов. DVMRP-дейтограмма состоит из небольшого заголовка фиксированного размера и длинного списка записей. Заголовок DVMRP-сообщений имеет формат IGMP (рис. 4.4.9.4.1):
Рис. 4.4.9.4.1 Формат заголовка DVMRP-сообщений Поле версия равно 1. Поле тип содержит всегда код 3. А поле субтип может принимать значения: 1 = Отклик; сообщение о маршрутах до некоторого (-ых) мест(а) назначения. Контрольная сумма вычисляется также как и в других IP-протоколах. Отдельные записи в указанном списке выполняют роль команд и их размер должен быть кратен 16 бит (их границы соответствующим образом выравниваются). Максимальная длина DVMRP-сообщения, включая заголовок, не может превышать 512 байт. В настоящее время IETF установлены следующие значения TTL и порогов при передаче видео- и аудио-информации по мультикастинг-каналам. Колонка TTL содержит значение времени жизни IP-пакета при его отправке для каждого из указанных приложений. В колонке порог записано значение TTL, при котором пакет будет пропущен дальше. Таблица 4.4.9.4.1. Значения TTL для различных приложений
Мультикастинг-дейтограмма с исходным TTL=64 доступна для достаточно обширной области, а мультикастинг-дейтограмма с исходным TTL=128 доступна для целого континента, дейтограмма же с исходным TTL=255 дойдет до любой точки сети Интернет. Понятия "узкий регион" и "обширная область" достаточно неопределенные и будут уточняться позднее. Маршрутные сообщения, посылаемые конкретному физическому интерфейсу, также как и запросы подтверждения членства в мультикастинг-группе должны иметь TTL=1. Цикл обмена маршрутной информацией между мультикастинг- маршрутизаторами (FULL_UPDATE_RATE) равен 60 сек. Подтверждение членства в группе должно посылаться каждые 120 сек (QUERY_RATE). Если подтверждение не получено в течение 2*QUERY_RATE+20 секунд, то членство в данной группе аннулируется. Соседний мультикастинг-маршрутизатор считается работающим при отсутствии подтверждений (UPDATE-сообщений) в течение 4*FULL_UPDATE_RATE. Описанные выше протоколы DVMRP и MOSPF имеют общий недостаток - широко используют широковещательные режимы рассылки пакетов и требуют каналов с высокой пропускной способностью. Они удобны для компактных групп (например, все члены группа находятся в пределах одной автономной системы). Для обслуживания более широких групп предложен протокол PIM. |
|||||||||||||||||||||
|
Previous:
4.4.9.3 Транспортный протокол реального времени RTCP
UP:
4.4 Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.9.5 Протокол PIM
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол PIM (Protocol Independent Multicast) призван решить проблемы маршрутизации для произвольного числа и расположения членов группы и для произвольного числа отправителей информации. В настоящее время протокол не является стандартом. Главным преимуществом данного протокола является эффективная поддержка работы "рассеянных" мультикастинг-групп. Такие группы могут включать не только членов из разных автономных систем, но и находящихся на разных континентах. Протоколы MOSPF и DVMRP хороши для сетей, где нет ограничений по пропускной способности каналов. PIM базируется на традиционных маршрутных протоколах, конкретно не связан ни с каким из них, им используются сформированные этими протоколами маршрутные таблицы. Существует два режима работы протокола - DM (для компактных групп) и SM (Protocol Independent Multicast-Sparse Mode (PIM-SM)). Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, RFC-2117, June 1997) (для рассеянных групп). В режиме DM протокол PIM строит дерево маршрутов аналогично DVMRP. В режиме SM маршрутизаторы, имеющие членов мультикастинг-группы, посылают сообщения о присоединении к дереву рассылки в узлы, которые называются точками встречи (RP). Отправители используют RP для объявления о своем существовании, а получатели, чтобы узнать о новых отправителях. В качестве RP может использоваться любой маршрутизатор, поддерживающий протокол PIM. Когда какой-то клиент хочет подключиться к некоторой группе, ближайший к нему маршрутизатор посылает специальное сообщение о включении в группу (PIM-joint) узлу, объявленному для данной группы точкой встречи (RP). Число RP в сети может быть произвольным. Узел RP пересылает сообщение о включении узлу-отправителю (или отправителям). Если маршрутизатор не имеет информации о RP, включается схема, работающая для компактных групп. При обработке сообщения о включении в группу промежуточные маршрутизаторы формируют часть дерева мультикастинг-маршрутов между RP и получателем. При отправке мультикастинг-пакета соответствующий маршрутизатор посылает узлу RP регистрационное сообщение (PIM-register), куда вкладывается информационный пакет. Если используется несколько RP, отправитель должен посылать пакеты всем RP. Получатель же должен быть подключен лишь к одному из RP. В случае, когда сообщение о включении достигнет отправителя раньше, чем RP, подключение осуществляется, минуя RP. Если необходимо оптимизировать дерево доставки пакетов, маршрутизаторы-получатели должны послать сообщение о включении самому отправителю. После этого дерево соединений видоизменяется, некоторыми узлами, если требуется, посылается сообщение об отключении. Ниже приведен пример взаимодействия узлов при формировании дерева маршрутов в режиме SM-PIM (рис. 4.4.9.5.1). Следует заметить, что большинство протоколов для маршрутизации мультимедийной информации формируют маршрут не от отправителя к получателю, а в обратном направлении. Это имеет под собой веские причины. Дерево рассылки должно быть построено так, чтобы поток отправителя как можно дольше и меньше разветвлялся. Желательно, чтобы разветвления происходили как можно ближе к получателю. Это соображение проиллюстрировано на рис. 4.4.9.5.2. На рисунке условно, в виде сетки маршрутизаторов (желтые кружочки) показан фрагмент сети Интернет. Зеленым прямоугольником отмечен передатчик, а голубыми кружочками приемники - члены группы. Маршруты от передатчика к приемникам можно проложить индивидуально (выделены зеленым цветом), а можно и "коллективно" (синий цвет). От передатчика до маршрутизатора отмеченного красным цветом следует один поток для всех приемников. Такое решение приводит к минимизации сетевой загрузки, ведь всем приемникам посылаются одни и те же пакеты. Чем позже их пути разойдутся, тем лучше. Именно этот алгоритм и реализует протокол PIM. Точки разветвления потоков на рис. 4.4.9.5.2 отмечены крестами (RP).
Рис. 4.4.9.5.1. Иллюстрация реализации протокола мультикастинг маршрутизации PIM Получатель посылает PIM-joint пакет в RP, устанавливая канал от RP до получателя. Из рисунка видно, что исходный маршрут d-c-b-a длиннее оптимального d-b-a. Последний может быть реализован после посылки PIM-joint команды от a к d. При решении транспортных задач в мультимедиа чаще используется протокол UDP (малая избыточность и отсутствие подтверждений).
Рис. 4.4.9.5.2. Ниже приводится более подробное, хотя и неполное описание протокола pim. Используемые сокращения и термины
Целью протокола PIM является построение дерева маршрутов для рассылки мультикастных сообщений. Маршрутизатор получает сообщения join/prune от соседних маршрутизаторов, которые обслуживают группы пользователей. Он переадресует информационные пакеты, адресованные группе G, только через те интерфейсы, через которые ранее было получено сообщение join. Специальный маршрутизатор DR (designated router) рассылает периодически сообщения join/prune в точки встречи (RP) для каждой группы, в которой имеются активные участники. Для описания дерева маршрута используются маршрутные записи, содержащие адрес отправителя, групповой адрес, номер входного интерфейса, через который принимаются пакеты, список интерфейсов, через которые осуществляется рассылка, таймеры, флаги и пр. Выходные интерфейсы указывают на соседние маршрутизаторы, через которые пролегает путь к RP. В центре этого маршрутного дерева, включающего в себя всех членов группы, находится RP. Когда источник информации посылает что-то группе в первый раз, его DR отправляет уникастное сообщение register в RP. Для того чтобы присоединиться к мультикатинг-группе G, ЭВМ передает IGMP-сообщение (или ICMP в случае IPv6). При этом предполагается, что ЭВМ будет выполнять функции получателя (R). Когда DR получает уведомление о членстве новой группы от IGMP G, он просматривает соответствующие RP. DR формирует запись мультикастинг-маршрута для группы (*,g) [wild card мультикастная запись для группы G, определяющая ее состояние]. Адрес RP включается в специальное поле маршрутной записи, содержащейся в периодически рассылаемых сообщениях join/prune (см. рис. 4.4.9.5.9). При этом в список выходных интерфейсов включается тот, к которому подключен новый член группы, а в качестве входного интерфейса указывается тот, через который посылаются уникастные пакеты к RP. Когда не остается ни одного непосредственно подключенного члена группы, протокол IGMP уведомляет об этом DR. Если DR не имеет ни локальных, ни удаленных получателей, запись (*,g) ликвидируется. Запись (*,g), инициирует формирование DR сообщения join/prune с RP-адресом в его join-списке и установленными битами WC и RPT. Равенство WC=1 говорит о том, что согласно этой записи будут пересылаться пакеты любого отправителя. Список удаления (prune) остается пустым. Когда бит RPT=1, это указывает на то, что подключение осуществлено через общее RP-дерево и, следовательно, сообщение join/prune будет идти по этому RP-дереву. Когда бит WC= 1, это означает, что адрес принадлежит RP, а получатели предполагают получать пакеты от всех отправителей. Каждый маршрутизатор, расположенный по пути к отправителю, создает и отслеживает изменения маршрутной записи для (*,g), когда он получает сообщения join/prune с RPT=WC=1. Интерфейс, через который получено сообщение join/prune, добавляется к списку выходных интерфейсов (OIF) для (*,g). На основе этой записи каждый маршрутизатор по пути между получателем и RP посылает сообщение join/prune, в котором RP включен в список join. Поле данных этого пакета содержит мультикаст-адрес=G, join=RP, wc-бит, RPT-бит, prune=null. Когда ЭВМ начинает посылать мультикастинг-пакеты группе, сначала DR должен доставить их в RP для последующей раздачи по дереву RP. DR отправителя в начале инкапсулирует каждый информационный пакет в сообщение register (см. рис. 4.4.9.5.7) и отправляет его по уникастному адресу RP данной группы. RP извлекает каждое сообщение register и переадресует вложенные информационные пакеты вдоль RP-дерева. Если поток данных позволяет использовать дерево кратчайшего пути до отправителя (SPT), RP может сформировать новую маршрутную запись для дерева мультикаст-маршрута, специфичного для данного отправителя (SP-дерево). DR отправителя прекратит инкапсуляцию информация в пакеты registers, когда он получит сообщение register-stop от RP. RP отравляет сообщения register-stop в качестве отклика на сообщение registers, если RP не имеет более активных членов группы. Новый приемник может подключиться к существующему RP-дереву, для которого установлено обрезание (prune state) (например, из-за того, что другие получатели переключились на SP-деревья). В этом случае состояние обрезания аннулируется с тем, чтобы обеспечить доставку данных новому получателю. В стабильном состоянии каждый маршрутизатор периодически посылает сообщения join/prune для каждой маршрутной записи PIM. Сообщения join/prune посылаются соседу, указанному в соответствующей записи. Такие сообщения позволяют отследить изменения состояния системы и топологию членства в группе. Для того чтобы получить информацию о RP, все маршрутизаторы в пределах PIM-домена собирают сообщения bootstrap. Сообщения bootstrap пересылаются от узла к узлу в пределах домена. За организацию рассылки этих сообщений несет ответственность специальный маршрутизатор BSR (bootstrap router). Сообщения bootstrap используются для выполнения динамического выбора BSR, когда это необходимо, а также для получения информации об RP. Домен в этом контексте представляет собой набор смежных маршрутизаторов, поддерживающих PIM, и сконфигурированных для совместной работы в рамках границ, определенных пограничными маршрутизаторами PMBR (PIM multicast border router), соединяющими PIM-домен с остальным Интернет. Маршрутизаторы используют набор доступных RP (называемый {RP-set}), для того чтобы осуществить связь отдельных групп с соответствующими RP. Некоторое число маршрутизаторов в домене конфигурируется как кандидаты для выполнения функций BSR. Для назначения BSR в домене существуют простые правила выбора. Часть маршрутизаторов в домене конфигурируются также как кандидаты для работы в качестве RP (C-RP); как правило, это те же маршрутизаторы, что и кандидаты в BSR. Кандидат в RP периодически посылает BSR домена уникастное сообщение candidate-rp-advertisement (C-RP-ADVS). C-RP-ADVS включает в себя адрес C-RP, а также опционный групповой адрес и поле длины маски. BSR включает набор этих кандидатов в RP (набор RP), вместе с соответствующим групповым префиксом периодически рассылаемых сообщений. Маршрутизаторы получают и запоминают содержимое сообщений bootstrap. Когда DR получает указание о членстве в группе от IGMP, DR использует хэш-функцию для установления соответствия между групповым адресом и одним из C-RP, чей префикс включает в себя данную группу. Для конкретной группы G, хэш-функция использует только те C-RP, чьи групповые префиксы покрывают G. Когда соответствие установлено, DR посылает сообщение join/prune (или уникастный пакет register) соответствующему rp. Сообщения bootstrap информирует о работоспособности точек встречи (rp), обслуживающих сессию. Если RP включен в сообщение, он считается рабочим, в то время как отсутствие rp в сообщении, приводит к удалению его из списка, с которым работает алгоритм. Каждый маршрутизатор продолжает использовать содержимое, полученное в последнем сообщении bootstrap, пока не будет получено новое сообщение bootstrap. Если зона PIM-домена теряют доступ к старому BSR, они выберут новый BSR, который разошлет RP-набор, содержащий RP, доступные в пределах данной зоны. Любая область в любой заданный момент времени обслуживается только одним BSR, который и осуществляет посылку сообщений bootstrap. Для того чтобы обеспечить совместимость с сетями, работающими в режиме DM, с протоколами типа DVMRP, все пакеты, генерируемые в области PIM-SM, должны быть переправлены мультикастным пограничным маршрутизаторам области PMBR (multicast border router) и переадресованы в сеть DVMRP. Маршрутизатор PMBR размещается на границе домена PIM-SM и взаимодействует с другими типами мультикаст-маршрутизаторов, например, такими, которые поддерживают протокол DVMRP. Таким образом, PMBR должен поддерживать оба протокола. Для поддержки совместной работы все маршрутизаторы должны поддерживать специальный тип маршрутных записей, обозначаемых (*,*,rp). Информационные пакеты, соответствуют записи (*,*,rp), если нет никаких других записи, например, (s,g) или (*,g), групповой адрес места назначения пакета согласуется с RP, указанным в записи (*,*,rp). В этом смысле запись (*,*,rp) представляет собой объединение всех групп, которые работают через данную точку встречи RP. PMBR инициализируют состояние (*,*,rp) для каждой RP в каждом доменном наборе RP. Состояние (*,*,rp) заставляет pmbr посылать сообщения (*,*,rp) join/prune каждой активной RP в домене. В результате деревья рассылки строятся так, что передают все пакеты, возникающие в пределах PIM-домена (и ретранслируются в точки встречи) в направлении пограничных маршрутизаторов PMBR. PMBR осуществляют также доставку внешних пакетов маршрутизаторам в пределах PIM-домена. Для решения этой задачи эти маршрутизаторы инкапсулируют внешние пакеты, полученные через интерфейсы DVMRP, в сообщения register, после чего уникастным образом переадресуют их в точку встречи RP PIM-домена. Сообщение register имеет бит, указывающий на то, что пакет сформирован пограничным маршрутизатором. Информационные пакеты обрабатываются также как и при других мультикаст-схемах. Маршрутизатор сначала проверяет адреса отправителя и группы. Затем определяется адрес RP, если непосредственная передача невозможна. Если пути доставки не существует, пакет выбрасывается. При наличии пути выясняется интерфейс, через который должна производиться передача, и пакет переадресуется. Информационные пакеты никогда не вызывают обрезания ветвей маршрутного дерева. Однако информационные пакеты могут запустить процессы, которые в конечном итоге приведут к такому результату. Когда имеется несколько маршрутизаторов, соединенных с сетью, имеющей много каналов доступа, один из них должен быть выбран в качестве ретранслятора (DR; обычно это маршрутизатор с наибольшим IP-адресом). Это справедливо для любой точки сети в любое время. Процедуре выбора предшествует обмен сообщениями Hello. При наличии параллельных проходов к источнику или RP для выбора маршрута применяются сообщения assert. Используя сообщения assert, адресованные `224.0.0.13' (группа all-pim-routers) в локальной сети, вышестоящий маршрутизатор может узнать, где осуществляется переадресация сообщений. Нижестоящие маршрутизаторы, получая сообщения assert, узнают, какой маршрутизатор выбран в качестве ретранслятора, и куда следует посылать сообщение join. Обычно это тот же нижележащий маршрутизатор-сосед (reverse path forwarding), но иногда это может быть и не так, например, когда в локальной сети используется несколько протоколов маршрутизации. RPF-сосед для конкретного отправителя или RP является следующим маршрутизатором, которому переправляются пакеты по пути к отправителю или RP. По этой причине он может рассматриваться как хорошая промежуточная инстанция для пересылки пакетов отправителем. Когда приходит пакет в выходной интерфейс, маршрутизатор посылает сообщение assert в локальную сеть с множественным доступом, указывая, какую метрику он использует для достижения отправителя информационных пакетов. Маршрутизатор с наименьшим значением метрики и станет базовым ретранслятором. Все прочие вышестоящие маршрутизаторы вычеркнут этот интерфейс из своего списка выходных интерфейсов. Нижестоящие маршрутизаторы также производят сравнение, если ретранслятором не является RPF-сосед. С понятием метрики связано и значение предпочтения метрики. Оно введено, чтобы решать проблемы в случае, когда вышестоящие маршрутизаторы использует другие уникастные протоколы маршрутизации. Численно меньшее значение предпочтения соответствует более высокому приоритету. Значение предпочтения рассматривается в качестве старшей части метрики при сравнении, которое осуществляется при обработке сообщений assert. Предпочтение может быть присвоено уникастному протоколу маршрутизации и должно быть взаимосогласованным для всех маршрутизаторов локальной сети с множественным доступом. Сообщения assert нужны для маршрутных записей (*,g), так как деревья RP и SP для некоторых групп могут возникать зоны перекрытия в сетях с множественным доступом. Когда assert посылается для записи (*,g), RPT-бит устанавливается равным 1. Первый бит поля предпочтения всегда устанавливается равным 1, для того чтобы отметить, что проход соответствует RP-дереву. RPT-бит всегда обнуляется для предпочтения, которое относится к записям SP-деревьев. Это приводит к тому, что проход через SP-дерево выглядит всегда редпочтительнее, чем проход через RP-дерево. Когда деревья SP и RP перекрываются для какой-то LAN, этот механизм устраняет дублирование для данной сети. DR может уступить процесс (*,g) assert другому маршрутизатору LAN, если существует несколько проходов к rp через lan. В этом случае DR не является более "ближайшим" маршрутизатором для местных получателей и он удаляет LAN из своего (*,g) списка выходных интерфейсов. Маршрутизатор-победитель становится "ближайшим" и ответственным за рассылку сообщений (*,g) join для RP. Подавление join/prune может использоваться в локальных сетях с множественным доступом, для того чтобы сократить число дублирующих управляющих сообщений. Для нормальной работы протокола этого не требуется. Если получено сообщение join/prune, которое соответствует существующим маршрутным записям (s,g), (*,g) или (*,*,rp) для данного входного интерфейса, а поле holdtime сообщения join/prune больше, чем join/prune-holdtime получателя, может быть запущен таймер (join/prune-suppression-таймер) маршрутной записи получателя с тем, чтобы заблокировать последующие сообщения join/prune. После завершения работы таймера получатель отправляет сообщение join/prune, и возобновляет периодическую посылку join/prune, для данной записи. Таймер join/prune-suppression должен перезапускаться каждый раз, когда приходит сообщение join/prune с большим значением holdtime. Когда уникастная маршрутизация претерпевает изменения, RPF производит проверку активных маршрутных записей (s,g), (*,g) и (*,*,rp) и вносит необходимые поправки. В частности, если в списке выходных интерфейсов появляется новый принимающий интерфейс, то он удаляется из этого списка. Предшествующий входной интерфейс может быть добавлен в список выходных интерфейсов с помощью последующих сообщений join/prune, поступающих от нижестоящих узлов. Сообщения join/prune, полученные текущим входным интерфейсом, игнорируются, а сообщения, полученные новыми или существующими выходными интерфейсами, обрабатываются. Остальные выходные интерфейсы останутся в прежнем состоянии до тех пор, пока не будут отключены нижележащими маршрутизаторами или по таймауту из-за отсутствия соответствующих сообщений join/prune. Если маршрутизатор имеет запись (s,g) с установленным битом spt, а обновленная запись IIF(s,g) не отличается от IIF(*,g) или IIF(*,*,rp), тогда маршрутизатор переводит бит SPT в нулевое состояние. Соседи-маршрутизаторы, поддерживающие протокол pim, периодически обмениваются сообщениями Hello (см. рис. 4.4.9.5.6). Сообщения Hello могут также рассылаться мультикастным образом с использованием адреса 224.0.0.13 (группа all-pim-routers). Пакет содержит значение holdtime (время сохранения информации). Когда маршрутизатор получает сообщение hello, он запоминает IP-адрес соседа, устанавливает таймер отправки на время, соответствующее holdtime, заключенное в Hello, и определяет выделенный маршрутизатор (DR) для данного интерфейса. В качестве DR выбирается объект с наибольшим Ip. Когда маршрутизатор, который является активным DR, получает Hello от нового соседа (например, от IP-адреса, которого нет в таблице DR), DR уникастным образом передает RP-информацию новому соседу. PIM-соседи, от которых в течение определенного времени не поступало сообщений Hello, считаются отключившимися. Если DR отключился, выбирается новый DR из числа соседей с наибольшим IP-адресом. Сообщения join/prune служат, для того чтобы подключить или удалить ветвь мультикастинг-дерева рассылки. Сообщение содержит как join-, так и prune-списки, любой из них может иметь нулевую длину. Эти сообщения содержат все подключенные и отсоединенные источники данных, достижимые через данный узел адресат сообщения. Период отправки сообщений join/prune определяется значением [join/prune-period]. Маршрутизатор периодически посылает сообщения join/prune каждому конкретному RPF-соседу, соответствующему каждой маршрутной записи (s,g), (*,g) и (*,*,rp). Сообщения join/prune посылаются только тогда, когда RPF-сосед является PIM-соседом. Кроме периодически рассылаемых сообщений некоторые из join/prune пакетов могут генерироваться как следствие следующих событий:
Может так случиться, что размер сообщения join/prune превысит MTU сети. В этом случае сообщение может быть фрагментировано, информация, относящаяся к различным группам, будет послана в разных пакетах. Однако, если сообщение join/prune должно быть фрагментировано, полный prune-список, соответствующий группе G, должен быть включен в одно сообщение join/prune согласно RP-дереву join для G. Если такая семантическая фрагментация невозможна, при транспортировке пакетов от соседа к соседу должна использоваться IP-фрагментация. Для любой новой записи (s,g), (*,g) или (*,*,rp), сформированной входящим сообщение join/prune, бит SPT сбрасывается. Если запись имеет таймер join/prune-suppression, полученное сообщение join/prune не указывает на маршрутизатор в качестве места назначения, тогда принимающий маршрутизатор рассматривает join- и prune-списки, с тем чтобы выяснить, нет ли там адресов полностью соответствующих существующим состояниям (s,g), (*,g) или (*,*,rp), для которых принимающий маршрутизатор осуществляет рассылку сообщений join/prune. Элемент join- или prune-списка полностью соответствует маршрутной записи, только тогда, когда их IP-адреса и RPT-флаги тождественны. Если приходящее сообщение join/prune полностью соответствует существующим записям (s,g), (*,g) или (*,*,rp), а сообщение join/prune приходит на входной интерфейс для данной записи, маршрутизатор сравнивает holdtime сообщения со своим собственным значением join/prune-holdtime. Если его значение join/prune-holdtime меньше, запускается таймер join/prune-suppression. Если join/prune-holdtime равно holdtime сообщения, коллизия разрешается в пользу отправителя сообщения join/prune, который имеет больший ip-адрес. Когда время join/prune таймера истекает, маршрутизатор отправляет сообщение join/prune для соответствующей маршрутной записи. Когда отправитель начинает отправку данных группе, его пакеты инкапсулируются в сообщения register и посылаются в RP. Если скорость передачи гарантируется каналом, RP устанавливает соответствующее состояние для отправителя и начинает посылать сообщения (s,g) join/prune отправителю с S в join-списке. Когда DR получает сообщение register-stop, он перезапускает таймер register-suppression в соответствующей записи (s,g) на register-suppression-timeout секунд. Если имеются данные, которые должны быть зарегистрированы, DR может послать RP сообщение register нулевой длины, за probe-time секунд до истечения времени таймера register- suppression. Сообщения assert используются для принятия решения, какой из параллельных маршрутизаторов, подключенных к локальной сети с множественным доступом, должен быть ответственным за ретрансляцию пакетов в LAN. Все управляющие сообщения PIM имеют номер протокола 103. Сообщения PIM являются либо уникастными (например, registers и register-stop), либо мультикастными для группы `all-pim-routers' `224.0.0.13' (например, join/prune, asserts, и т.д.). Формат заголовка пакета протокола PIM показан на рис. 4.4.9.5.3.
Рис. 4.4.9.5.3. Формат заголовка сообщения PIM Поле OIM VER - версия протокола (в настоящее время = 2). Поле тип характеризует PIM-сообщение. Возможные значения поля тип представлены в таблице 4.4.9.5.1. Таблица 4.4.9.5.1. Коды типа сообщений
Поле длина адреса характеризует длину кода адреса в байтах. Поле контрольная сумма вычисляется методом суммирования всего pim-сообщения по модулю 1, это поле имеет длину 16 бит. Формат закодированного группового адреса показан на рис. 4.4.9.5.4.
Рис. 4.4.9.5.4. Формат закодированного группового адреса Поле длина маски имеет 8 бит. Значение поля определяет число последовательных бит, выровненных по левому краю, которые определяют адрес. Маска равна или меньше длины адреса * 8 (то есть 32 бита для IPv4 и 128 для IPv6). Поле групповой мультикаст адрес содержит адрес группы и имеет число байт, равное указанному в поле длина адреса. Формат кодированного адреса отправителя показан на рис. 4.4.9.5.5.
Рис. 4.4.9.5.5. Формат кодированного адреса отправителя Поле бит s (бит рассеянности) содержит 1 для PIM-SM. Этот бит используется для обеспечения совместимости с PIM v.1. Поле бит W (бит WC). Бит WC =1, если подключение (join) или удаление (prune) используются для маршрутной записи (*,g) или (*,*,rp). Если wc=0, join или prune используются для маршрутной записи (s,g), где s - адрес отправителя. Сообщения join и prune, посылаемые в RP, должны иметь этот бит равным 1. Поле бит R (бит RPT). Бит RPT=1, если информация о (s,g) послана в RP. Если RPT=0, информация должна быть послана S, где S - адрес отправителя. Поле длина маски имеет длину 8 бит. Значение этого поля охарактеризовано выше в комментарии к рисунку 4.4.9.5.4. Поле адрес отправителя имеет длину, определяемую полем заголовка длина адреса. Для IPv4, она равна 4 октетам. Формат сообщения Hello показан на рис. 4.4.9.5.6. Первые два байта представляют собой заголовок PIM-сообщения. Поле optiontype определяет тип опции, значение которой задано в поле optionvalue. Поле optionlength задает длину поля optionvalue в байтах. Поле optionvalue имеет переменную длину и содержит значение опции. Поле опция может содержать следующие значения:
Рис. 4.4.9.5.6. Формат сообщения Hello optiontype = 1; optionlength = 2; optionvalue = holdtime; где holdtime равно времени в секундах, в течение которого получатель должен сохранять доступность к соседу. Если holdtime установлено равным `0xFFFF', получатель этого сообщения никогда не прервет соединение с соседом по таймауту. Это может использоваться для каналов ISDN, для того чтобы избежать поддержания канала путем периодической посылки сообщений Hello. Более того, если holdtime= 0, информация объявляется устаревшей немедленно. Диапазон значений optiontype 2 - 16 зарезервирован на будущее. Сообщение register посылается DR или PMBR в RP, когда необходимо передать мультикаст-пакет по rp-дереву. IP-адрес отправителя при этом равен адресу DR, а адрес места назначения - адресу RP. Формат сообщения register показан на рис. 4.4.9.5.7. Постоянная часть заголовка здесь идентична, показанной на рис. 4.4.9.5.3.
Рис. 4.4.9.5.7. Формат сообщения register Поле B - (бит border) пограничный бит. B=1, если маршрутизатор непосредственно соединен с отправителем. Поле N - бит нулевого регистра. n устанавливается DR равным 1 при тестировании RP до истечения времени регистрации (register-suppression timer). Поле информационный мультикаст-пакет представляет собой оригинальное сообщение, посланное отправителем. Сообщение register-stop является уникастным, направляемым от RP к отправителю сообщения register. IP-адрес отправителя является адресом, к которому направлялось сообщение регистрации. IP-адрес места назначения равен адресу отправителя сообщения register. Формат сообщения register-stop показан на рис. 4.4.9.5.8.
Рис. 4.4.9.5.8. Формат сообщения register-stop Поле закодированный групповой адрес имеет тот же смысл, что и на рис. 4.4.9.5.4. Для сообщений register-stop поле длины маски содержит длину адреса * 8 (32 для IPv4), если сообщение послано для одной группы. Поле уникастный адрес отправителя представляет собой IP-адрес ЭВМ отправителя из мультикастного информационного пакета. Длина этого поля в байтах задано полем длина адреса. Значение (0.0.0.0) может быть использовано для обозначения любого адреса. Сообщение join/prune посылается маршрутизаторами в направлении вышестоящих отправителей и RP. Сообщения join служит для построения совместно используемых маршрутных деревьев (RP-деревьев) или деревьев отправителей (SPT). Сообщения prune посылаются для отключения деревьев отправителей, когда участники покидают группу, а также для отправителей, которые не используют общее дерево. Формат сообщения join/prune показан на рис. 4.4.9.5.9.
Рис. 4.4.9.5.9. Формат сообщения join/prune Поле адрес вышестоящего соседа представляет собой IP-адрес RPF или вышестоящего соседа. Поле holdtime характеризует время в секундах, в течение которого получатель должен поддерживать активное состояние join/prune. Если holdtime сделано равным `0xffff', получатель сообщения отключает таймаут для данного выходного интерфейса. Если holdtime сделано равным `0', таймаут происходит немедленно. Поле число групп равно количеству мультикаст-групп, содержащихся в сообщении. Поле закодированный мультикастный групповой адрес имеет формат, показанный на рис. 4.4.9.5.4. Произвольная группа (wildcard) (*,*,rp) характеризуется адресом 224.0.0.0 и `4' в поле длина маски. Подключение (*,*,rp) имеет биты WC и RPT равные 1. Поле число подключенных отправителей равно количеству адресов подключенных отправителей для данной группы. Поля адрес подключенного отправителя -1 .. N представляют собой список отправителей, которым посылающий маршрутизатор переправляет мультикастные дейтограммы при получении их через интерфейс, на который пришло данное сообщение. Формат полей кодированного адреса отправителя следует описанию на рис. 4.4.9.5.5.
Рис. 4.4.9.5.10. Формат сообщения bootstrap Сообщения bootstrap пересылаются мультикастным способом группе `all-pim-routers', через все интерфейсы, имеющие PIM-соседей (за исключением того, через который получено сообщение). Сообщения bootstrap генерируются в BSR и посылаются с TTL=1. Формат сообщения bootstrap показан на рис. 4.4.9.5.10. Сообщение bootstrap делится на семантические фрагменты, если исходное сообщение превосходит предельный размер пакета. Формат этих фрагментов представлен ниже (см. также рис. 4.4.9.5.10): Поле метка фрагмента является случайным числом и служит для идентификации фрагментов принадлежащих одному и тому же сообщению. Фрагменты одного и того же сообщения имеют идентичные метки фрагмента. Поле длина хэш>-маски - это длина маски хэш функции в битах. Для IPv4 рекомендуется значение 30, а для IPv6 - 126. Поле BSR-приоритет содержит значение BSR-приоритета для включенного BSR. Это поле рассматривается как старший байт при сравнении BSR-адресов. Поле уникастный BSR-адрес является IP-адресом маршрутизатора (bootstrap) домена. Размер этого поля в байтах специфицирован в поле длина адреса. Поля закодированный групповой адрес -1..n является групповым префиксом (адрес и маска), с которым ассоциируются кандидаты RP. Поля число RP -1..N равны числу адресов кандидатов RP, включенных в сообщение bootstrap для соответствующего группового префикса. Маршрутизатор не замещает старый RP-набор для данного группового префикса до тех пор, пока не получит новое число RP-адресов для этого префикса. Адреса могут содержаться в нескольких фрагментах. Если получена только часть RP-набора для данного префикса, маршрутизатор эту часть выбрасывает, не изменяя RP-набора. Поля FRAG RP-cnt-1..m представляет собой число адресов кандидатов RP, включенных в этот фрагмент сообщения bootstrap, для соответствующего группового префикса. Поле ` FRAG RP-cnt ' облегчает разбор RP-набора для данного группового префикса, когда он размещается в более чем одном фрагменте. Поля уникастные rp-адреса -1..m представляют собой адреса кандидатов RP, для соответствующего группового префикса. Длина поля в байтах специфицировано полем длина адреса. Поля rp1..m-holdtime характеризуют значения holdtime для соответствующих RP. Это поле копируется из поля `holdtime' RP, записанного в BSR. Сообщение assert посылается когда мультикастный информационный пакет получен выходным интерфейсом, соответствующим (s,g) или (*,g), относящимся к отправителю. Формат такого сообщения представлен на рис. 4.4.9.5.11.
Рис. 4.4.9.5.11. Формат сообщения assert Поле закодированный групповой адрес характеризует групповой адрес места назначения пакетов, который явился причиной посылки сообщения assert. Поле уникастный адрес отправителя содержит IP-адрес отправителя из дейтограммы, вызвавшей посылку мультикастного пакета Assert. Длина поля в байтах определена полем длины адреса. Поле R представляет собой RPT-бит. Если IP мультикастинг дейтограмма, вызвавшая посылку пакета assert направляется вниз по RP-дереву, тогда RPT-бит равен 1. Если маршрутизация осуществляется вдоль SPT, бит равен 0. Поле предпочтение несет в себе значения кода предпочтения, присвоенного уникастному протоколу маршрутизации, который организует проход до ЭВМ. Поле метрика содержит значение метрики для таблицы маршрутизации. Единицы измерения должны соответствовать требованиям маршрутного протокола. Сообщения кандидата RP посылаются периодически C-RP способом и уникастно адресуются к BSR. Формат таких сообщений показан на рис. 4.4.9.5.12.
Рис. 4.4.9.5.12. Формат сообщения кандидата RP (C-RP) Поле # префиксов (Prefix-Cnt) содержит количество кодированных групповых адресов, включенных в сообщение, указывая групповые префиксы, для которых производится C-RP оповещение. Значение поля Prefix-Cnt = `0' предполагает использование префикса 224.0.0.0 с длиной маски 4, что означает - все мультикастные группы. Если C-RP не снабжена информацией о групповом префиксе, C-RP заносит в поле значение по умолчанию равное `0'. Поле A характеризует бит указания. Этот бит указывает, что BSR не должен переписывать информацию о групповых префиксах, приведенную в C-RP оповещении. В большинстве случаев C-RP устанавливает этот бит, равным 0. Поле Holdtime содержит значение времени, в течение которого оповещение корректно. Это поле позволяет определить время, когда оповещение устареет. Поле уникастный RP-адрес представляет собой адрес интерфейса, который объявляется кандидатом в RP. Длина этого поля в байтах определена полем длина адреса. Поле закодированный групповой адрес -1..n является групповым префиксом, для которого производится уведомление кандидатом в RP. Литература
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP
UP:
4.4 Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.9.6 Протокол резервирования ресурсов RSVP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205) используется ЭВМ для того, чтобы запросить для приложения определенный уровень качества сетевых услуг QoS (Quality of Service, например, определенный уровень полосы пропускания). RSVP используется также маршрутизаторами для доставки QOS-запросов всем узлам вдоль пути информационного потока, а также для установки и поддержания необходимого уровня услуг. RSVP-запросы обеспечивают резервирование определенных сетевых ресурсов, которые нужны, чтобы обеспечить конкретный уровень QOS вдоль всего маршрута транспортировки данных. Функция этого протокола крайне важна и многообразна, именно по этой причине это один из самых сложных протоколов. RSVP запрашивает ресурсы только для одного из направлений трафика и только по указанию получателя. RSVP работает поверх IPv4 или IPv6. Протокол относится к числу управляющих, а не транспортных. RSVP предназначен для работы с существующими и будущими маршрутными протоколами, управляющими как обычными, так и мультикастными потоками. В последнем случае ЭВМ сначала посылает IGMP-запрос, для того чтобы подключиться к мультикастинг-группе, а затем уже RSVP-сообщение для резервирования ресурсов по маршруту доставки. Механизм обеспечения QOS включает в себя классификацию пакетов, административный контроль и диспетчеризацию. Классификатор пакетов определяет QoS класс (а иногда и маршрут движения) для каждого пакета. В процессе реализации резервирования RSVP-запрос проходит два местных управляющих модуля: "контроль доступа" и "управление политикой". Контроль доступа определяет, имеет ли узел достаточно ресурсов для удовлетворения поступившей заявки. Управление политикой определяет, имеет ли пользователь административное разрешение сделать данное резервирование. Если обе проверки завершились успешно, параметры передаются классификатору пакетов и интерфейсу канального уровня (диспетчеру пакетов). Если же какой-либо из тестов не прошел, программа RSVP присылает прикладному процессу сообщение об ошибке. Структура и содержимое параметров QoS документировано в спецификации RFC-2210. Так как число участников группы, а также топология связей меняется со временем, структура RSVP предполагает адаптацию ЭВМ и маршрутизаторов к этим изменениям. Для этой цели RSVP периодически посылает сообщения для поддержания необходимого состояния вдоль всего маршрута обмена. При отсутствии этих сообщений происходит тайм-аут и резервирование аннулируется. Обобщая, можно сказать, что RSVP имеет следующие атрибуты:
Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме. Схема работы процесса RSVP показана на рис. 4.4.9.6.1.
Рис. 4.4.9.6.1. RSVP в ЭВМ и маршрутизаторе 1. Потоки данных RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой. Сессия RSVP описывается тремя параметрами: DestAddress, ProtocolId [, DstPort]. DestAddress - IP-адрес места назначения информационных пакетов (уникаст или мультикаст). ProtocolId - идентификатор IP протокола. Опционный параметр DstPort - обобщенный порт места назначения, т.е., еще одна точка демультиплексирования на транспортном или прикладном уровне. DstPort может быть определено полем порта места назначения UDP/TCP. Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут всегда иметь различные мультикаст-адреса. Однако, DstPort необходим для того, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя. Для уникастной передачи может быть один получатель, но много отправителей; RSVP может выполнить резервирование для передачи много_точек -> одна_точка. 2. Модель резервирования Простой запрос резервирования RSVP состоит из "flowspec" (спецификация потока) и "filter spec" (спецификация фильтра); эта комбинация называется "описателем потока". Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов. Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра - для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра обрабатываются без гарантий обеспечения оговоренного QOS. Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:
Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC-2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP). Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.
Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации. В каждом промежуточном узле запрос резервирования запускает две процедуры: A. Резервирование канала Процесс RSVP проходит стадии проверки допуска и политики. Если какой-либо тест не прошел, резервирование отвергается и посылается сообщение об ошибке. Если все тесты прошли успешно, узел устанавливает классификатор пакетов, для того чтобы отбирать пакеты, указанные в спецификации фильтра. Далее устанавливается контакт с соответствующим канальным уровнем для получения желательного QoS, заданного в flowspec. Для простой выделенной линии, желаемый QoS будет получен с помощью диспетчера пакетов в драйвере канального уровня. Если технология канального уровня поддерживает свои средства управления QoS, тогда RSVP должен согласовать с канальным уровнем получение требуемого QoS. Б. Переадресация запроса назад Запрос резервирования посылается от получателя отправителю (или отправителям) данных. Запрос резервирования, который переадресуется узлом дальше может отличаться от того, который он получил по двум причинам. Механизм управления трафиком модифицирует flowspec от узла к узлу. Что более важно, запросы резервирования, поступающие от получателей мультикастинг-дерева должны объединяться по мере продвижения процесса резервирования в направлении отправителя данных. Когда получатель данных отправляет запрос резервирования, он может запросить также присылку сообщения, подтверждающего резервирование. Процесс резервирования распространяется от получателей к отправителям, от узла к узлу. В каждом узле требования резервирования объединяются и сопоставляются с имеющимися возможностями. Это продолжается до тех пор, пока запрос не достигнет отправителя или пока не возникнет конфликт перегрузки. В результате получатель данных, направивший запрос резервирования, получит сообщение об успехе или ошибке. Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования. 3. Стили резервирования Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии. Другая опция резервирования контролирует выбор отправителей. В одних случаях каждому отправителю ставится в соответствие определенная спецификация фильтра, в других - таких спецификаций не требуется вовсе. В настоящее время определены следующие стили:
Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая "труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении. Символически можно представить запрос резервирования стиля WF как: WF( * {Q}), где звездочка представляет произвольную подстановку при выборе отправителя, а Q - спецификация flowspec
Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии. Символически простой запрос резервирования FF можно представить как: FF(S{Q}), где S - выбранный отправитель, а Q - соответствующая спецификация flowspec; эта пара параметров образуют дескриптор потока. RSVP позволяет применение нескольких простых стилей резервирования FF одновременно, при этом формируется список дескрипторов потоков: FF(S1{Q1}, S2{Q2}, ...) Полное резервирование в канале для данной сессии характеризуется суммой Q1, Q2, ... для всех отправителей, куда посланы запросы.
Стиль SE использует опции: "разделенное" (shared) резервирование и "явный" (explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей. Запрос резервирования SE, содержащий flowspec Q и список отправителей S1, S2, ... можно представить в символьной форме как: SE((S1,S2,...){Q} ) Разделенное резервирование, выполненное с применением стилей WF и SE, пригодно для мультикастных приложений, где несколько источников данных редко осуществляют передачу одновременно. Пакетная передача голоса может служить примером разделенного резервирования, так как лишь ограниченное число людей говорят одновременно. Каждый получатель может направить запрос резервирования WF или SE на удвоенную полосу пропускания, необходимую одному отправителю, позволяя тем самым говорить обоим партнерам одновременно. С другой стороны стиль FF, который осуществляет четкое резервирование для потоков отдельных отправителей, подходит для передачи видеосигналов. Правила RSVP не позволяют объединять разделенные резервирования с четкими резервированиями, так как эти модели абсолютно несовместимы. Не допускается также объединение явного и произвольного (wildcard) выбора отправителей, так как это может вызвать предоставление незаказанных услуг получателю, который указал тип услуг явно. Таким образом, стили WF, SE и FF не совместимы. Можно моделировать эффект WF резервирования, используя стиль SE. Когда приложение запрашивает WF, процесс RSVP получателя может использовать местный статус для выполнения эквивалентного резервирования SE, которое в явном виде перечисляет всех отправителей. Однако резервирование SE вынуждает классификатор пакетов в каждом узле в явном виде выбрать каждого отправителя из списка, в то время как WF позволяет классификатору пакетов осуществить произвольный выбор отправителя и порта с помощью "wild card". Когда список отправителей велик, стиль резервирования WF обеспечивает значительно меньшие издержки, чем SE. 4. Примеры стилей На рис. 4.4.9.6.2. показан пример маршрутизатора с двумя входными интерфейсами IА и IБ, через которые проходят входные потоки, и двумя выходными интерфейсами IВ и IГ, через которые осуществляется переадресация входных потоков. Пусть существует три отправителя S1 (S2 и S3), подключенные к интерфейсам IА и IБ, соответственно. Имеется три получателя R1 (R2 и R3), которые маршрутизированы через выходные интерфейсы IВ и IГ, соответственно. Будем также предполагать, что интерфейс IГ подключен к широковещательной сети, а R2 и R3 достижимы через разные маршрутизаторы, не показанные на рисунке. Здесь нужно специфицировать мультикастные маршруты в пределах узла, отображенного на рис. 4.4.9.6.2. Предположим сначала, что информационные пакеты от каждого из отправителей Si, показанных на рисунке, маршрутизованы на оба выходных интерфейса. При этих предположениях на рисунках 4.4.9.6.3, 4.4.9.6.4 и 4.4.9.6.5 проиллюстрированы стили резервирования WF, FF и SE, соответственно.
Рис. 4.4.9.6.2. Конфигурация маршрутизатора Для простоты эти примеры показывают flowspec как одномерное кратное повторение некоторого базового качества ресурса B. Колонка "Резервирует" показывает запросы резервирования RSVP, полученные через выходные интерфейсы IВ и IГ, а колонка "Получает" показывает результирующее состояние резервирования для каждого интерфейса. Колонка "Посылает" показывает запросы резервирования, посланные предшествующим узлам (IА и IБ). В колонке "Резервирует" каждая рамка представляет один зарезервированный виртуальный канал с соответствующим дескриптором потока. Рис. 4.4.9.6.3, демонстрируя стиль WF, показывает две ситуации, в которых требуется объединение.
Рис. 4.4.9.6.3. Пример резервирования WF (Wildcard-Filter) На рис. 4.4.9.6.4 проиллюстрирован стиль резервирования FF (Fixed-Filter). Для каждого выходного интерфейса, имеется отдельное резервирование для каждого запрошенного источника, но это резервирование будет общим для всех получателей, которые послали запрос. Дескрипторы для получателей S2 и S3, полученные через выходные интерфейсы IВ и IГ, вкладываются в пакеты запросов, направляемых предыдущему узлу (IБ). С другой стороны, три различных дескриптора потоков, специфицирующих отправителя S1, объединяются в один запрос FF( S1{4B} ), который посылается предыдущему узлу (IА). На рис. 4.4.9.6.5 показан пример стиля резервирования SE. Когда резервирования стиля SE объединяются, результирующая спецификация фильтра является объединением исходных спецификаций, а результирующая спецификация flowspec равна наибольшей из flowspec.
Рис. 4.4.9.6.4. Пример резервирования FF (Fixed-Filter)
Рис. 4.4.9.6.5. Пример резервирования SE (Shared-Explicit) Приведенные примеры предполагают, что информационные пакеты от S1, S2 и S3 маршрутизируются через оба выходных интерфейса. Нижняя часть рис. 4.4.9.6.2 показывает еще одно предположение о маршрутизации: информационные пакеты от S2 и S3 не переадресуются интерфейсу IВ, напр., из-за того что сеть обеспечивает более короткий путь для пакетов отправителя к R1. Рис. 4.4.9.6.3 показывает пример резервирования WF именно при этом предположении (стрелками отмечены допустимые маршруты). Так как нет пути от IБ к IВ, резервирование, переадресуемое интерфейсом IБ, рассматривает резервирование только для интерфейса IГ.
5. Механизмы протокола RSVP
Рис. 4.4.9.6.6. Маршрутизатор, использующий RSVP На рис. 4.4.9.6.6 проиллюстрирована модель RSVP узла маршрутизатора. Каждый поток данных приходит со стороны предшествующего узла через соответствующий входной интерфейс и выходит из маршрутизатора через один или несколько выходных интерфейсов. Один и тот же интерфейс для разных потоков в пределах одной сессии может выполнять как входную, так и выходную роль. Несколько предшествующих узлов и/или последующих узлов могут для коммуникаций использовать один и тот же физический интерфейс; например, на рисунке два узла Г и Г' подключены к широковещательной сети через интерфейс IГ. Существует два фундаментальных типа сообщений RSVP: Resv и Path. Каждый получатель посылает свой RSVP запрос резервирования в виде сообщений (Resv) отправителям данных. Эти сообщения должны двигаться в точности тем же маршрутом с учетом выбора отправителей, что и данные только в противоположном направлении. Они создают и поддерживают состояние резервирования в каждом узле вдоль маршрута. Сообщения Resv должны быть, в конце концов, доставлены ЭВМ-отправителям, таким образом, ЭВМ устанавливают параметры управления трафиком. Каждая ЭВМ отправитель передает RSVP сообщения "Path" вдоль уникаст/мультикаст маршрутов, сформированных с помощью маршрутных протоколов. Эти сообщения Path запоминают состояние пути в каждом узле вдоль маршрута. Это состояние пути включает в себя уникастный IP-адрес предыдущего узла, который используется для маршрутизации сообщений Resv от узла к узлу в противоположном направлении. Сообщение Path содержит помимо этого следующую информацию:
Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает формат пакетов данных, посылаемых отправителем. Этот шаблон имеет форму спецификации фильтра, которая может использоваться для отделения пакетов данного отправителя от других пакетов в пределах сессии. Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые используются в сообщениях Resv. Следовательно, шаблон отправителя может специфицировать только его IP-адрес и опционно UDP/TCP порт, с учетом идентификатора протокола, заданного для сессии.
Сообщения Path должны содержать спецификацию отправителя Tspec, которая определяет характеристики информационного трафика, формируемого отправителем. Спецификация Tspec используется для предотвращения избыточного резервирования.
Сообщение Path может нести в себе пакет данных оповещения OPWA, известный, как "Adspec". Пакет Adspec, полученный с сообщением Path, передается системе управления трафиком, которая присылает скорректированную версию Adspec. Последняя пересылается далее в виде сообщения Path. Сообщения Path посылаются с теми же адресами отправителя и получателя, что и данные, так что они будут корректно маршрутизироваться даже через сетевые области, не поддерживающие RSVP. С другой стороны, сообщения Resv посылаются от узла к узлу; каждый узел, поддерживающий RSVP, переправляет сообщение Resv по уникастному адресу предшествующего узла RSVP. 6. Объединение Flowspecs Сообщение Resv, переадресованное предшествующему узлу, несет в себе спецификацию flowspec, которая является "наибольшей" из всех flowspec, запрошенных последующими узлами, которым будут посылаться данные. Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе для выполнения объединения спецификаций flowspec. Заметим, что спецификации flowspecs представляют собой в общем случае многомерные векторы; они могут содержать как Tspec, так и Rspec компоненты, каждая из которых может сама быть многомерной. Например, если один запрос требует высокой пропускной способности, а другой - жесткого ограничения задержек, один не может быть "больше" другого. В таком случае, вместо взятия большего, прикладная программа объединения должна быть способна сформировать такую спецификацию flowspec, которая по крайне мере столь же велика, как и каждая из составляющих; математически это наименьший верхний предел LUB (least upper bound). В некоторых случаях спецификация flowspec по крайне мере настолько мала насколько возможно; это наибольший верхний предел GLB (Greatest Lower Bound). Для вычисления эффективного значения flowspec (Re, Te), инсталлируемого в интерфейс, используются следующие шаги [RFC 2210]. Здесь Te - эффективная спецификация Tspec, а Re - эффективная спецификация Rspec.
7. Гибкое состояние RSVP использует подход "soft state" (гибкое состояние) для управления состоянием резервирования в маршрутизаторах и ЭВМ. Гибкое состояние RSVP создается и периодически освежается посредством сообщений Path и Resv. Состояние уничтожается, если не приходит подтверждения в течение заданного времени тайм-аута очистки. Состояние может быть стерто также посредством сообщения "teardown" (уничтожение). По истечении каждого таймаута обновления и после любых изменений состояния RSVP осуществляет проверку, для того чтобы подготовить и отправить сообщения обновления Path и Resv последующим узлам. Сообщения Path и Resv практически эквивалентны (idempotent). Когда маршрут меняется, следующее сообщение Path инициализирует состояние прохода для нового маршрута, а последующие сообщения Resv установят для него резервирование. Состояние же на неиспользованном в данный момент сегменте маршрута будет аннулировано по таймауту. Следовательно, определение того, является ли сообщение "новым" или "обновляющим" принимается отдельно для каждого узла в зависимости от его текущего состояния. Протокол RSVP посылает свои сообщения в виде IP-дейтограмм без какого-либо улучшения надежности. Периодическая передача сообщений обновления от ЭВМ и маршрутизаторов позволяет компенсировать случайные потери отдельных RSVP сообщений. Если таймаут удаления установлен равным K периодам обновления, тогда RSVP может допускать потерю K-1 RSVP-пакетов подряд без аннулирования состояния. Механизм управления сетевым трафиком должен быть отконфигурирован так, чтобы предоставить минимальную полосу пропускания для сообщений RSVP, чтобы предотвратить их потерю из-за перегрузки канала. Состояние, поддерживаемое RSVP, является динамическим. Для изменения набора отправителей Si или изменения любого запроса QoS, ЭВМ просто начинает посылать измененные сообщения Path и/или Resv. В результате будет осуществлено соответствующее изменение RSVP-состояния во всех узлах вдоль пути, неиспользуемые состояния будут аннулированы по таймауту, если не поступит прямых указаний по их ликвидации до этого. В стабильном состоянии осуществляется обновление статуса узел за узлом. Когда полученное состояние отличается от хранящегося, последнее обновляется. О модификации состояния соседи оповещаются с помощью сообщений обновления, которые рассылаются сразу после изменения состояния. Но эта волна изменений может остановиться в узле, где в результате слияния получается состояние, которое не отличается от прежнего. Это минимизирует трафик управления RSVP, что весьма существенно для больших мультикастинг-групп. Состояние, которое получено через конкретный интерфейс I* никогда не должно переадресовываться этому интерфейсу. Состояние, которое направляется интерфейсу I* должно вычисляться на основе состояний, полученных от других интерфейсов, исключая I*. Тривиальный пример, поясняющий это правило приведен на рис. 4.4.9.6.7, на котором показан маршрутизатор с одним отправителем и одним получателем на каждом интерфейсе (R1, S1 и R2, S2). Интерфейсы IA и IБ выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на рис. 4.4.9.6.7 "Получает" и "Отправляет" подразумевает внешнее направление по отношению к маршрутизатору).
Рис. 4.4.9.6.7. Независимые резервирования Существует еще одно правило, которое управляет процессом переадресации сообщений Resv: состояние из сообщения Resv, полученное через выходной интерфейс Io, следует передавать входному интерфейсу Ii только в том случае, когда сообщение Path от Ii переадресовано к Io. 8. Аннулирование (Teardown) Сообщения RSVP "аннулирование" удаляет проход или состояние резервирования. Хотя прямое уничтожение старого резервирования не является обязательным, оно настоятельно рекомендуется, так как ускоряет переходные процессы в сети. Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям. Запрос аннулирование (teardown) может посылаться приложением оконечной системы (получатель или отправитель), или маршрутизатором в результате таймаута или при появлении привилегированной задачи. После инициализации запрос-аннулирование должен переадресовываться от узла к узлу без задержки. Сообщение аннулирование уничтожает специфицированное состояние в узле-получателе. Подобно другим сообщениям RSVP, запросы-аннулирования доставляются без гарантии надежности. Потеря такого запроса не вызовет катастрофы, так как не используемое состояние будет рано или поздно ликвидировано по таймауту. Если маршрутизатор не получил сообщения аннулирования, он ликвидирует соответствующее состояние по таймауту и формирует сообщение аннулирование, рассылаемое последующим узлам. Предполагая, что вероятность потери сообщения RSVP мала, наибольшее среднее время ликвидации ненужного состояния не превышает периода обновления. Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра. Например, в случае, показанном на рис. 4.4.9.6.7, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений. Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы. 9. Ошибки Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода. Однако для синтаксически верных запросов резервирования имеется много способов быть отвергнутыми. Узел может решить аннулировать установленное резервирование из-за более приоритетных заданий. Так как неудовлетворение запроса может быть вызвано объединением нескольких запросов, ошибка резервирования должна быть ретранслирована всем получателям группы. Кроме того, объединение разнородных запросов создает потенциальную трудность, известную как проблема "резервирования килера", в которой один запрос может блокировать услуги другого. В действительности существует две такие проблемы.
Чтобы решить эту проблему сообщения ResvErr устанавливают дополнительное состояние, называемое, "состояние блокады", в каждом из узлов, через которые проходит это сообщение. Состояние блокады в узле модифицирует процедуру объединения, так чтобы игнорировать блокирующие спецификации flowspec (Q1 в вышеприведенном примере), позволяя скромным запросам проходить и осуществлять свое резервирование. Состояние резервирования Q1 считается в данном случае заблокированным. Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены. Однако, эти резервирования были сохранены по следующим причинам:
10. Подтверждение Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее. Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и, если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос. Этот механизм подтверждения имеет следующую последовательность:
11. Управление политикой Механизм управления политикой определяет, каким пользователям или приложениям позволено осуществлять резервирование и в каком объеме. RSVP-запросы QoS позволяют определенным пользователям получить предпочтительный доступ к сетевым ресурсам. Для предотвращения злоупотреблений, необходима некоторая обратная связь. Такого рода обратная связь может быть реализована с помощью административной политики обеспечения доступа, или путем введения прямой или виртуальной оплаты резервирования. В любом случае требуется идентификация пользователя. Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: "Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?" и "Позволено ли данному пользователю осуществлять резервирование?" Эти два решения называются "управлением доступа" и "управлением политикой", соответственно. Различные административные домены в Интернет могут иметь разные политики резервирования. На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки данных могут включать в себя параметры доступа пользователя, его класс, номер аккоунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов. Перенос таких данных, поставляемых пользователями, в сообщениях Resv может представлять проблему в случае существенного увеличения числа пользователей. Когда мультикастинг-группа содержит большое число получателей, может оказаться невозможно или нежелательно транспортировать данные, описывающие политику, вдоль всего маршрута. Эти данные должны объединяться как можно ближе к получателям, чтобы избежать чрезмерного информационного потока. 12. Безопасность При использовании протокола RSVP возникают определенные проблемы безопасности.
Повреждение или фальсификация запросов резервирования может привести к получению услуг неавторизованными пользователями или к отказам в услугах. RSVP осуществляет защиту против таких атак с помощью механизма аутентификации, действующего в каждом из узлов и использующего шифрование с применением хэш-функций. Механизм поддерживается объектами INTEGRITY, которые могут быть включены в любое сообщение RSVP. Эти объекты используют технику криптографических дайджестов, которая предполагает, что соседи RSVP совместно владеют секретом шифрования (см. [Baker96]).
Управление политикой будет зависеть от положительного результата аутентификации для каждого из запросов резервирования. Информация, характеризующая политику, может быть включена в сообщение в виде криптографически защищенного сертификата пользователя.
Первые два пункта касались выполнения операций RSVP. Третий пункт касается резервирования для безопасных потоков данных. В частности, использование IPSEC (IP Security) в потоке данных создает проблему для RSVP: если транспортный и вышележащие заголовки зашифрованы, общие номера порта RSVP не могут использоваться для определения сессии или отправителя. Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль что и номер порта [RFC 2207]. 13. Области, не поддерживающие RSVP Невозможно развернуть протокол RSVP (или любой новый протокол) во всем Интернет одновременно. Более того, RSVP вероятно никогда не будет развернут повсеместно. RSVP должен гарантировать корректную работу, когда два RSVP маршрутизатора объединены друг с другом через сетевую область, не поддерживающую этот протокол. Конечно, промежуточная сетевая область, лишенная поддержки RSVP, не способна осуществлять резервирование ресурсов. Однако, если эта область обладает достаточной емкостью, она может обеспечить необходимый уровень услуг реального времени. Протокол RSVP приспособлен для работы через такие, не поддерживающие его, сетевые области. Как поддерживающие RSVP так и не поддерживающие RSVP маршрутизаторы переадресуют сообщения Path в соответствие с адресом места назначения, используя свои локальные таблицы маршрутизации. Следовательно, на маршрутизацию сообщений Path не оказывает влияние наличие промежуточных маршрутизаторов, лишенных RSVP поддержки. Когда сообщение Path проходит через сетевую область, не поддерживающую RSVP, оно, направляясь к следующему узлу, поддерживающему RSVP, несет в себе IP-адрес последнего RSVP-маршрутизатора. Сообщение Resv тогда переадресуется непосредственно следующему RSVP-маршрутизатору на пути к отправителю. Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг `NonRSVP' и передает его механизму управления трафиком. Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC 2210]. При некоторых топологиях маршрутизаторов с и без поддержки RSVP возможна доставка сообщений Resv в не тот узел, или не тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, тогда оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е., интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно попало. 14. Модель ЭВМ Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор (DestAddress, ProtocolId [, DstPort]), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.
Существует несколько соображений, касающихся синхронизации.
Получатель может просто игнорировать такие сообщения об ошибке или он может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.
15. Функциональная спецификация RSVP Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP, существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех), порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке. 16. Общий заголовок
Рис. 4.4.9.6.8. Формат общего заголовка В общем заголовке имеются следующие поля:
Vers. 4 бита - Номер версии протокола. В данном описании = 1. Дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась. Send_TTL: 8 бит Значение TTL для протокола IP, с которым было послано сообщение. Длина RSVP: 16 бит Полная длина RSVP сообщения в байтах, включая общий заголовок и объекты переменной длины, которые за ним следуют. 17. Форматы объектов Каждый объект состоит из одного или более 32-битных слов с 4-байтовым заголовком. Формат объекта показан на рис. 4.4.9.6.9:
Рис. 4.4.9.6.9. Формат объекта Заголовок объекта имеет следующие поля: Длина в байтах 16-битовое поле, содержащее полную длину объекта в байтах. Длина должна быть кратна 4 октетам, минимальное значение равно 4. Class-Num Идентифицирует класс объекта. Каждый класс объекта имеет свое имя, которое в данном документе записывается прописными буквами. Приложения RSVP должны распознавать следующие классы: NULL Объект NULL имеет код Class-Num равный нулю, а его C-тип игнорируется. Его длина должна быть, по крайней мере, равна 4, но может быть любой кратной 4. Объект NULL может появиться где угодно в последовательности объектов. Его содержимое получателем игнорируется. SESSION Содержит IP-адрес места назначения (DestAddress), идентификатор протокола IP, и обобщенный номер порта назначения, для того чтобы специфицировать сессию для других объектов, которые следуют далее. Этот класс должен присутствовать в любом сообщении RSVP. RSVP_HOP Несет в себе IP-адрес узла, поддерживающего протокол RSVP, который послал это сообщение, и дескриптор логического выходного интерфейса (LIH). Этот класс характеризует предшествующий узел (previous hop). TIME_VALUES Содержит значение периода обновления R, используемого отправителем сообщения. Необходим в каждом сообщении Path и Resv. STYLE Определяет стиль резервирования, а также зависящую от стиля информацию, которая не включена в объекты FLOWSPEC или FILTER_SPEC. Необходим в каждом сообщении Resv. FLOWSPEC Определяет желательный уровень QoS, в сообщениях Resv. FILTER_SPEC Определяет субнабор информационных пакетов сессии, которые должны получить желательный уровень QoS (специфицированный объектом FLOWSPEC), в сообщениях Resv. SENDER_TEMPLATE Содержит IP-адрес отправителя и, может быть, некоторые дополнительную информацию, идентифицирующую отправителя. Необходим в сообщениях Path. SENDER_TSPEC Определяет характеристики информационного трафика отправителя. Необходим в сообщениях Path. ADSPEC Несет в себе данные OPWA, в сообщении Path. ERROR_SPEC Специфицирует ошибку в сообщениях PathErr, ResvErr, или подтверждение в сообщении ResvConf. POLICY_DATA Несет в себе информацию, которая позволит локальному модулю, определяющему политику, принять решение, допустимо ли административно соответствующее резервирование. Может присутствовать в сообщениях Path, Resv, PathErr или ResvErr. INTEGRITY Несет в себе криптографические данные для аутентификации исходного узла и для верификации содержимого сообщения RSVP. Использование объекта INTEGRITY описано в ссылке [Baker96] в конце данного документа. SCOPE Несет в себе список ЭВМ-отправителей, к которым должно быть переадресовано данное сообщение. Может присутствовать в сообщениях Resv, ResvErr или ResvTear. RESV_CONFIRM Несет в себе IP-адрес получателя, который запросил подтверждение. Может присутствовать в сообщениях Resv или ResvConf. C-Type Тип объекта, уникален в пределах класса Class-Num. Максимальная длина объекта равна 65528 байт. Поля Class-Num и C-Тип могут использоваться совместно, как 16-битовое число, для определения уникального типа для каждого из объектов. Старшие два бита Class-Num используются для определения того, какие действия должен предпринять узел, если он не распознает Class-Num объекта. 18. Сообщения Path Каждая ЭВМ-отправитель периодически отправляет сообщения Path для каждого из информационных потоков, берущих здесь свое начало. Это сообщение содержит объект SENDER_TEMPLATE, определяющий формат пакетов данных, и объект SENDER_TSPEC, специфицирующий характеристики трафика потока. Опционно сообщение может содержать объект ADSPEC, несущий в себе информацию о потоке (OPWA). Сообщение Path направляется от отправителя к получателю по тому же маршруту, по которому движутся информационные пакеты. IP-адрес источника в сообщении Path должен характеризовать адрес отправителя, в то время как адрес места назначения должен быть равен DestAddress для текущей сессии. Эти адреса гарантируют, что сообщение будет корректно маршрутизовано даже через области сети, не поддерживающие RSVP. Формат сообщения Path имеет следующий вид: <Path Message> ::= <Common Header> [ <INTEGRITY> ] Если присутствует объект INTEGRITY, он должен следовать непосредственно за стандартным общим заголовком. Не существует каких-либо иных ограничений порядка передачи, хотя упомянутое выше требование является рекомендательным. Число объектов POLICY_DATA может быть произвольным. Объект PHOP (т.е., RSVP_HOP) каждого сообщения Path содержит адрес предшествующего узла, напр., IP-адрес интерфейса, через который только что было послано сообщение Path. Он также содержит дескриптор логического интерфейса (LIH). Каждый узел, поддерживающий RSVP, вдоль пути перехватывает сообщение Path и обрабатывает его, с тем чтобы сформировать состояние пути для отправителя, заданного объектами SENDER_TEMPLATE и SESSION. Любой из объектов POLICY_DATA, SENDER_TSPEC и ADSPEC также записываются в состояние пути. Если случилась ошибка при обработке сообщения Path, посылается сообщение PathErr первичному отправителю сообщения Path. Периодически процесс RSVP в узле сканирует состояние прохода, чтобы сформировать новые сообщения Path для посылки их получателям. Каждое сообщение содержит дескриптор, характеризующий одного отправителя, несет в себе IP-адреса отправителя и его источника. Процесс RSVP переадресует и размножает (если требуется, например при мультикастинге) сообщения Path, используя маршрутную информацию, которую он получает от соответствующих процессов маршрутизации. Маршрут зависит от DestAddress сессии и для некоторых протоколов маршрутизации от адреса источника. Маршрутная информация обычно включает в себя список выходных интерфейсов, куда должно направляться сообщение Path. Так как каждый выходной интерфейс имеет свой IP адрес, сообщения Path, посланные разными интерфейсами содержат отличные адреса PHOP. Кроме того, объекты ADSPEC, содержащие сообщения Path, будут отличаться для разных выходных интерфейсов. Состояние пути для данной сессии и отправителя не обязательно должны иметь уникальные PHOP или уникальный входной интерфейс. Существует два случая, соответствующие мультикастной и уникастной сессиям.
Мультикастинговая маршрутизация позволяет иметь стабильное дерево распределения, в котором сообщения Path от одного и того же отправителя приходят от более чем одного PHOP, и RSVP должен быть готов поддерживать все такие состояния пути. RSVP не должен пересылать сообщения Path, которые прибывают через входной интерфейс, отличный от указанного в маршрутной таблице.
В течение короткого периода времени, следующего после изменения уникастного маршрута, узел может получать сообщения Path от нескольких PHOP для данной сессии и отправителя. Узел не может надежно определить, какой из PHOP является правильным, хотя узел будет получать одновременно только один из PHOP. Одним из вариантов реализации RSVP является игнорирование PHOP и допущение для PHOP переключаться между имеющимися кандидатами. Другим вариантом является поддержание состояния пути для каждого PHOP и посылка сообщения Resv всем таким PHOP. В любом варианте ситуация является переходной, неиспользуемые состояния пути все равно будут удалены (явно или по таймауту). 19. Сообщения Resv Сообщения Resv несут в себе запросы резервирования от узла к узлу, от получателей к отправителям в направлении противоположном движению потока данных. IP-адрес места назначения сообщения Resv является уникастным адресом предшествующего узла, полученным из состояния прохода. IP-адрес источника является адресом узла, который посылает сообщение. Сообщение Resv имеет следующий формат: <Resv Message> ::= <Common Header> [ <INTEGRITY> ] Если присутствует объект INTEGRITY, он должен непосредственно следовать за общим заголовком. За объектом STYLE следует список дескрипторов потоков. Объекты в списке дескрипторов должны следовать требованиям записанных в BNF. Объект NHOP (напр., RSVP_HOP) содержит IP-адрес интерфейса, через который посылаются сообщения Resv, и LIH для логического интерфейса, где требуется резервирование. Появление объекта RESV_CONFIRM сигнализирует о запросе подтверждения резервирования и несет в себе IP-адрес получателя, которому должен быть послан ResvConf. Число объектов POLICY_DATA не лимитировано. Ниже приведены правила, которые специфицируют структуру дескриптора потока для каждого из стилей резервирования.
<flow descriptor list> ::= <WF flow descriptor>
<flow descriptor list> ::= Каждый запрос стиля FF описывается одной парой (FLOWSPEC, FILTER_SPEC), несколько таких запросов могут быть уложены в один список дескрипторов потока сообщения Resv. Объект FLOWSPEC может быть опущен, если он идентичен последнему такому объекту в списке; первый дескриптор потока стиля FF должен содержать FLOWSPEC.
<flow descriptor list> ::= <SE flow descriptor> Набор отправителей (reservation scope), которым направляется конкретный запрос резервирования, определяется следующим образом:
Резервирование переадресуется всем отправителям, чьи объекты SENDER_TEMPLATE, записанные в состоянии прохода соответствуют объекту FILTER_SPEC.
Запрос с произвольным выбором отправителя соответствует всем отправителям, которые маршрутизированы на данный выходной интерфейс. Когда сообщение Resv с произвольным выбором отправителя переадресуется более чем одному предыдущему узлу, в сообщение должен быть включен объект SCOPE. В этом случае список IP адресов для рассылки хранится именно в этом объекте. Сообщение Resv, которое пересылается узлом, является в общем случае результатом объединения входящих сообщений Resv. Если одно из этих объединенных сообщений содержит объект RESV_CONFIRM и имеет число FLOWSPEC, больше чем FLOWSPEC всех других объединенных запросов резервирования, тогда этот объект RESV_CONFIRM переадресуется в виде исходящего сообщения Resv. Объект RESV_CONFIRM из одного из объединенных запросов (чья спецификация flowspecs равна, меньше или сравнима с объединенной спецификацией flowspec и которая не подвергнута блокаде) запустит генерацию сообщения ResvConf, содержащего RESV_CONFIRM. Объект RESV_CONFIRM в запросе, который подвергнут блокаде, не будет переадресован или возвращен, он будет аннулирован в текущем узле. 20. Сообщения отмены прохода Получение сообщения PathTear (path teardown) аннулирует состояния прохода. Соответствующее состояние должно согласовываться с объектами SESSION, SENDER_TEMPLATE и PHOP. Кроме того, сообщение PathTear для мультикастной сессии может соответствовать только состоянию прохода для входного интерфейса, через который получено сообщение PathTear. Если соответствия состоянию прохода нет, сообщение должно быть отброшено без дальнейшей рассылки. Сообщения PathTear инициализируются непосредственно отправителем или в результате таймаута состояния прохода в каком-либо узле и направляются всем отправителям. Уникастное PathTear не должно переадресовываться, если состояние прохода соответствует той же сессии и отправителю, но имеет другой PHOP. Сообщение PathTear должно маршрутизоваться в точности также как соответствующие сообщения Path. Следовательно, его IP-адрес места назначения должен совпадать с DestAddress, а его IP-адрес источника должен быть адресом отправителя из состояния прохода. <PathTear Message> ::= <Common Header> [ <INTEGRITY> ] Сообщение PathTear может содержать в своем дескрипторе отправителя объект SENDER_TSPEC или ADSPEC, но они должны игнорироваться. Удаление состояния прохода в результате получения сообщения PathTear или таймаута должно модифицировать состояние резервирования в данном узле. Эта модификация зависит от стиля резервирования. Например, предположим, что PathTear удаляет состояние прохода отправителя S. Если стиль специфицирует явный выбор отправителя (FF или SE), всякое резервирование со спецификацией фильтрования, соответствующей отправителю S, должно быть удалено; если стиль предусматривает произвольный выбор отправителя (WF), резервирование удаляется, если S является последним отправителем, участвующим в сессии. Эти изменения резервирования не должны вызвать немедленную посылку сообщения обновления Resv, так как сообщение PathTear уже вызвало необходимые изменения. Они не должны также вызвать отправку сообщения ResvErr, так как это может вызвать лавину таких сообщений. 21. Сообщения отмены Resv Получение сообщения ResvTear (reservation teardown) удаляет соответствующие состояния резервирования. При этом проверяется соответствие объектов SESSION, STYLE и FILTER_SPEC, а также LIH в объекте RSVP_HOP. Если соответствие не обнаружено, сообщение ResvTear игнорируется. Сообщение ResvTear может отменить любой субнабор спецификаций фильтрации в состояниях резервирования стилей FF или SE. Сообщения ResvTear отправляются получателями или любым узлом, в котором состояние резервирование аннулируется в результате таймаута, далее они движутся в направлении получателей. Сообщение ResvTear должно маршрутизироваться аналогично соответствующим сообщениям Resv, а его IP-адрес места назначения является уникастным адресом предыдущего узла. <ResvTear Message> ::= <Common Header> [<INTEGRITY>] Объекты FLOWSPEC в списке дескрипторов потоков сообщения ResvTear будут игнорироваться и могут быть опущены. Сообщение ResvTear может включать в себя объект SCOPE, но он должен игнорироваться. В зависимости от изменения состояния узла получение сообщения ResvTear может вызвать переадресацию этого сообщения, посылку модифицированного сообщения Resv или не вызвать никакого сообщения. Эти три случая могут быть проиллюстрированы для стиля резервирования FF на рис. 4.4.9.6.4.
22. Сообщения об ошибке прохода Сообщения PathErr (path error) несут в себе данные об ошибке в обрабатываемых сообщениях Path. Они направляются отправителям данных и маршрутизируются от узла к узлу, используя состояние прохода. При каждом шаге IP-адрес места назначения является уникастным адресом предыдущего узла. Сообщения PathErr не модифицируют состояния узлов, через которые проходят; они предназначаются только приложению отправителя. <PathErr message> ::= <Common Header> [ <INTEGRITY> ] Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил эту ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA. 23. Сообщения об ошибках Resv Сообщения ResvErr (reservation error) сообщают об ошибках при обработке сообщений Resv, или о спонтанном нарушении резервирования, напр., в результате административного вмешательства. Сообщения ResvErr направляются соответствующим получателям, они маршрутизируются от узла к узлу с использованием состояния резервирования. В каждом из узлов в качестве IP-адреса места назначения используется уникастный адрес следующего узла. <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA. Объект RSVP_HOP содержит адрес предыдущего узла, а объект STYLE копируется из сообщения Resv. Следующие правила, зависящие от стиля, определяют структуру ошибки дескриптора потока.
<error flow descriptor> ::= <WF flow descriptor>
<error flow descriptor> ::= <FF flow descriptor> Каждый дескриптор потока в сообщении Resv стиля FF должен обрабатываться независимо и для каждого из них, имеющего ошибку, должно посылаться отдельное сообщение ResvErr.
<error flow descriptor> ::= <SE flow descriptor> Сообщение ResvErr стиля SE может представит список субнабора спецификаций фильтрации, которые вызвали ошибки, в соответствующем сообщении Resv. Заметим, что сообщение ResvErr содержит только один дескриптор потока. Следовательно, сообщение Resv, которое содержит N > 1 дескрипторов потока (стиль FF) может быть причиной N сообщений ResvErr. Вообще говоря, сообщение ResvErr следует пересылать всем получателям, которые могут быть причиной данной ошибки. Конкретнее:
Это сообщение ResvErr должно содержать информацию, необходимую для определения ошибки и для маршрутизации сообщения об ошибке последующим узлам. Такое сообщение, следовательно, включает в себя объект ERROR_SPEC, копию объекта STYLE и соответствующий дескриптор потока, где зафиксирована ошибка. Если ошибка является результатом отказа при попытке увеличить резервирование, тогда существующее резервирование должно быть сохранено и должен быть установлен бит-флаг InPlace в ERROR_SPEC сообщения ResvErr.
24. Сообщения подтверждения Сообщения ResvConf посылаются в ответ на запрос подтверждения резервирования. Сообщение ResvConf посылается в результате появления объекта RESV_CONFIRM в сообщении Resv. Сообщение ResvConf посылается по уникастному адресу ЭВМ получателя, адрес берется из объекта RESV_CONFIRM. <ResvConf message> ::= <Common Header> [ <INTEGRITY> ] Объект RESV_CONFIRM является копией объекта в сообщении Resv, который вызвал подтверждение. ERROR_SPEC используется только для переноса IP-адреса исходного узла в поле адрес узла с ошибкой (Error Node Address). Равенство кода ошибки и значения (Value) нулю свидетельствует о подтверждении. Список дескрипторов потоков специфицирует конкретное резервирование, которое подтверждается. Это может быть субнабор из списка дескрипторов потоков Resv, для которого запрошено подтверждение. 25. Использование портов Сессия RSVP определяется в норме тремя параметрами: DestAddress, ProtocolId, DstPort. Здесь DstPort является полем порта назначения UDP/TCP. DstPort может быть опущен (сделан равным нулю), если ProtocolId специфицирует протокол, который не имеет поля порта места назначения. RSVP допускает любое значение для ProtocolId. Однако, реализации оконечных систем RSVP могут знать об определенных значениях для этого поля и в частности значения для UDP и TCP (17 и 6 соответственно). Оконечная система может выдать сигнал ошибки приложению, которая:
Спецификации фильтра и шаблоны отправителя определяют пару: SrcAddress, SrcPort, где SrcPort поле UDP/TCP порта. В некоторых случаях SrcPort может быть опущен (установлен равным нулю). Существуют следующие правила использования нулевого значения полей DstPort и/или SrcPort в RSVP. 1. Порты назначения должны быть взаимосогласованными. Состояния прохода и резервирования для одного и того же DestAddress и ProtocolId должны иметь свои значения DstPort, которые все равны нулю или все не равны нулю. Нарушение этого условия в узле является ошибкой "конфликт портов назначения (Conflicting Dest Ports)". 2. Правило портов назначения. Если DstPort в описании сессии равен нулю, все поля SrcPort, используемые для этой сессии, также должны быть равны нулю. При этом предполагается, что протокол не имеет портов типа UDP/TCP. Нарушение этого условия в узле вызовет ошибку "Bad Src Ports". 3. Порты источников должны быть взаимосогласованы. ЭВМ-отправитель не должна посылать состояния прохода со значением SrcPort равным так и неравным нулю. Нарушение этого условия вызовет ошибку "Conflicting Sender Port". Заметим, что протокол не допускает произвольного назначения номеров портов (wildcard), т.е., нулевой порт не может соответствовать ненулевому порту. 26. Посылка сообщений RSVP Сообщения RSVP посылаются от узла к узлу между RSVP-маршрутизаторами, поддерживающими этот протокол, в виде IP-дейтограмм с кодом протокола 46. IP-дейтограммы предназначены также для использования между оконечными системами и первыми/последними маршрутизаторами. Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках. По прибытии RSVP-сообщения M, которое меняет статус, узел должен немедленно послать сообщение о модификации состояния. Однако это не должно привести к посылке сообщения через интерфейс, откуда пришло M (что может случиться, если приложение запустит процедуру обновления состояний для текущей сессии). Это правило предотвращает лавину пакетов в сетях с широковещательной рассылкой. Каждое RSVP-сообщение должно пересылаться только в одной IP-дейтограмме. Если оно превосходит MTU, такая дейтограмма будет фрагментирована. Восстановление сообщения будет произведено узлом-получателем. Это имеет несколько следствий:
RSVP использует свой механизм периодического обновления для предотвращения влияния случайной потери отдельных пакетов. При перегрузке сети, однако, существенные потери RSVP-сообщений могут вызвать серьезные нарушения при резервировании сетевых ресурсов. Для контроля задержек, связанных с обслуживанием очереди, и влияния потерь RSVP пакетов, маршрутизаторы должны быть сконфигурированы так, чтобы обеспечивать для данных целей приоритетное обслуживание. Если RSVP-пакеты идут через область сети, где вероятность потери значительна, следует увеличить значение таймаутов. Некоторые мультикастные протоколы маршрутизации обеспечивают туннели, которые организуют IP-инкапсуляцию мультикастных пакетов и их транспортировку через маршрутизаторы, которые не поддерживают мультикастную маршрутизацию. RSVP может работать через такие мультикастные туннели следующим образом:
27. Исключение циклов сообщений RSVP Переадресация сообщений RSVP должна исключать возможность образования петель. В спокойном состоянии сообщения Path и Resv направляются каждому узлу только раз за период обновления. Это исключает зацикливание пакетов, но имеется еще возможность петель "автоматического обновления". Такие петли автоматического обновления сохраняют состояние "вечно", даже если оконечные узлы прекращают их обновление до тех пор, пока получатели не покинут мультикастинг-группу и/или отправители прекратят посылку сообщения Path. С другой стороны сообщения об ошибке и об аннулировании (teardown) посылаются немедленно и могут служить причиной возникновения циклов. Рассмотрим каждый тип сообщения.
Если топология не содержит петель, зацикливания сообщений Resv и ResvErr при произвольном выборе отправителя можно избежать, следуя приведенному выше правилу: состояние, которое получено через определенный интерфейс, никогда не должно переадресовываться через этот же интерфейс. Однако, когда топология содержит петли, необходимы дополнительные усилия для предотвращения циклов автоматического обновления для сообщений Resv и ResvErr с произвольным выбором отправителя. Решением этой проблемы может быть включение списка адресов получателей в объект SCOPE. Когда сообщение Resv с стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE/ для сообщения Resv приведены ниже:
На рис. 4.4.9.6.10 показан пример Resv сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.
Рис. 4.4.9.6.10. Объекты SCOPE при резервировании в стиле WF Объекты SCOPE не являются необходимыми, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При использовании объектов SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил:
28. Состояние блокады Основным правилом при формировании сообщения обновления Resv является объединение спецификаций flowspecs резервирования в узле посредством вычисления их LUB (наименьший верхний предел). Однако это правило модифицируется при наличии "состояния блокады", возникшего из-за сообщений ResvErr при решении проблемы KR-II. Когда получено сообщение ResvErr, его спецификация flowspec Qe используется для формирования или обновления элемента местного состояния блокады. Каждый элемент состояния блокады состоит из спецификации flowspec Qb, взятой из спецификации сообщения ResvErr и соответствующего таймера блокады Tb. Когда время таймера блокады истекает, соответствующее состояние блокады аннулируется. Гранулярность состояния блокады зависит от стиля сообщения ResvErr, которое явилось ее причиной. Каждому конкретному стилю может соответствовать свой элемент состояния блокады (Qb(S),Tb(S)), где S - отправитель. Для произвольного стиля выбора отправителя состояние блокады определяется предыдущим узлом P. Элемент состояния блокады со спецификацией flowspec Qb называется блокадой резервирования со спецификацией flowspec Qi, если Qb не больше чем Qi. Например, предположим, что LUB (least upper bound) двух спецификаций flowspecs было вычислено путем выбора максимума составляющих их компонент. Тогда Qb блокирует Qi, если для некоторой компоненты j, Qb[j] ≤ Qi[j]. Предположим, что узел получает сообщение ResvErr от предыдущего узла P (или, если стиль выбора отправителя S является явным) в результате ошибки доступа. Тогда:
В результате предлагается модифицированное правило для объединения спецификаций flowspecs при формировании сообщения обновления резервирования.
Этот алгоритм объединения обновления применяется отдельно для каждого потока (каждого отправителя или PHOP), вносящего вклад в общее резервирование (стили WF или SE). На рис. 4.4.9.6.11 приведен пример использования состояния блокады для совместного резервирования (стиль WF). Имеется два предшествующих узла, помеченных как (a) и (b), и два последующих узла, помеченных как (c) и (d). Большее резервирование 4B пришло сначала от (c), но "застряло" где-то до PHOP (a), а не по пути через PHOP (b). Рисунок показывает оконечное состояние после меньшего резервирования 2B пришедшего позднее из (d). Это стабильное состояние нарушается каждые Kb*R секунд, когда состояние блокады удаляется по таймауту. Следующее обновление (4B), посылаемое предыдущему узлу (a), предположительно будет отвергнуто, путем посылки сообщения ResvErr, которое восстановит состояние блокады, возвращая ситуацию к тому, что изображено на рисунке. В то же самое время сообщение ResvErr будет направлено следующему узлу (c) и всем получателям, ответственным за резервирование 4B.
Рис. 4.4.9.6.11. Блокада для стиля WF 29. Локальное восстановление Когда маршрут изменяется, следующее сообщение обновления Path или Resv установит проход или состояние резервирования (соответственно) вдоль нового маршрута. Чтобы обеспечить быструю адаптацию к изменениям маршрута, не вводя чрезмерно коротких периодов обновления, местный модуль протокола маршрутизации может сообщить процессу RSVP об изменении маршрута до определенных мест назначения. Процесс RSVP должен использовать эту информацию для запуска обновления в соответствующих областях с учетом изменения маршрута. При этом используются следующие правила спецификации:
30. Временные параметры Существует два временных параметра, соответствующие каждому элементу прохода или состоянию резервирования RSVP в узле: период обновления R между последовательными коррекциями состояния соседнего узла и время жизни локального состояния L. Каждое сообщение RSVP Resv или Path может содержать объект TIME_VALUES, специфицирующий значение R, которое было использовано при генерации данного сообщения обновления. Эта величина R затем используется для определения значения L. Величины R и L могут варьироваться от узла к узлу. Более подробно:
31. Политика в области трафика и узлы с не интегрированными услугами Некоторые уровни QoS могут требовать определенной политики в управлении трафиком в некоторых или всех перечисленных ниже случаях:
RSVP знает, где такие точки находятся, и должен обеспечивать этими данными механизм управления трафиком. С другой стороны, RSVP не интерпретирует информацию в flowspec и, следовательно, не знает, использованы ли рекомендации управления в каждом конкретном случае. Процесс RSVP передает управлению трафиком специальный флаг политики для каждой из трех указанных выше ситуаций.
Этот флаг устанавливается для первого узла RSVP, который реализует управление трафиком. Например, ЭВМ-отправители должны поддерживать RSVP, но многие из них не поддерживают управление трафиком. В этом случае флаг E_Police_Flag в ЭВМ-отправителе должен быть равен нулю, флаг устанавливается равным 1, когда достигнута первая ЭВМ, поддерживающая управление трафиком. Это контролируется флагом E_Police в объектах SESSION.
Этот флаг должен быть установлен для резервирования, использующего стили WF или SE, когда объединяются потоки более чем одного отправителя.
Этот флаг должен быть установлен, когда инсталлированная flowspec меньше или сравнима с FLOWSPEC какого-либо другого интерфейса для того же самого FILTER_SPEC и SESSION. RSVP должен также проверять наличие вдоль пути узлов, не поддерживающих RSVP, и переправлять эту информацию управлению трафиком. На основании этого флага и другой сопутствующей информации система контроля трафиком может обнаружить узлы, которые не способны обеспечить управление QoS. Эта информация передается получателям в спецификации Adspecs [RFC 2210]. При обычной IP-переадресации, RSVP может обнаружить узлы без поддержки RSVP путем сравнения значения IP TTL, с которым послано сообщение Path, с полученным TTL. Для этой цели TTL помещается в общий заголовок. Однако, TTL не всегда является надежным индикатором узлов без поддержки RSVP, и для этих целей иногда используются другие средства. Например, если маршрутный протокол использует туннели с IP-инкапсуляцией, этот протокол должен проинформировать RSVP о наличии узлов, лишенных поддержки RSVP. В отсутствии автоматических механизмов осуществляется ручная конфигурация. 32. ЭВМ с несколькими сетевыми интерфейсами При работе с ЭВМ, имеющими несколько сетевых интерфейсов, требуется выполнение ряда специальных правил. К такого рода устройствам относятся и маршрутизаторы, которые поддерживают локальные прикладные программы. Приложение, исполняемое на такой машине, должно явно указывать через какой интерфейс осуществляется передача данного информационного потока, для того чтобы заменить интерфейс, заданный по умолчанию системой.
Приложение отправителя использует API вызов для декларации характеристик его информационного потока для RSVP. Этот вызов может опционно включать локальный IP-адрес отправителя. Если он установлен приложением, этот параметр должен быть адресом интерфейса для отправки информационных пакетов, в противном случае, используется системный интерфейс по умолчанию. Процесс RSVP ЭВМ посылает затем приложению сообщения Path только через специфицированный интерфейс. 33. Выполнение резервирования Приложение-получатель использует вызов API для запроса резервирования RSVP. Этот вызов может опционно включать локальный IP-адрес получателя, т.е., адрес интерфейса для получения информационных пакетов. В случае мультикаст-сессий это интерфейс, к которому подключилась группа. Если этот параметр опущен, система использует значение по умолчанию. Процесс RSVP должен посылать сообщения Resv приложению через специфицированный интерфейс. Однако, когда приложение исполняется в маршрутизаторе, а сессия является мультикастной, возникает более сложная ситуация. Предположим, что в этом случае приложение получателя присоединяется к группе через интерфейс Iapp, который отличается от Isp - ближайшего интерфейса по пути к отправителю. Теперь имеется два возможных пути для мультикастной маршрутизации при доставке информационных пакетов приложению. Процесс RSVP должен определить, какой вариант выбрать, просмотрев состояние прохода и решив, какой из входных интерфейсов следует использовать для посылки сообщений.
34. Будущая совместимость В будущем для существующих классов могут быть описаны новые объекты C-Типа, а могут быть определены и новые классы объектов. Крайне желательно использовать такие объекты Интернет в рамках старых приложений, которые их не распознают. К сожалению, это возможно с заметными ограничениями. Здесь нужно придерживаться следующих правил (`b' означает бит). 1. Неизвестный класс Существует три возможных способа, чтобы приложение RSVP могло работать с объектом неизвестного класса. Этот выбор определяется двумя старшими битами октета Class-Num.
Ниже приведены более детализированные правила для работы с нераспознанными классами объектов для Class-Num вида 11bbbbbb:
Хотя объекты с неизвестным классом не могут объединяться, эти правила позволяют передать их вплоть до узла, который сможет их распознать и объединить. 2. Неизвестный C-Тип для известного класса Появление объекта с неизвестным C-типом приведет к выбрасыванию всего сообщения и генерации сообщения об ошибке (ResvErr или PathErr). Сообщение об ошибке будет включать Class-Num и C-тип, который был не распознан. Оконечная система, которая отправила нераспознанное сообщение может использовать эту информацию, чтобы попытаться повторить попытку с объектом другого C-типа. Объекты определенных классов (FLOWSPEC, ADSPEC и POLICY_DATA) не прозрачны для RSVP, который просто передает их системе управления трафиком или другим модулям управления. В зависимости от внутренних правил любой из упомянутых модулей может отвергнуть C-Тип и информировать об этом RSVP-процесс; RSVP должен тогда отвергнуть такое сообщение и проинформировать об ошибке. 35. Интерфейсы RSVP RSVP в маршрутизаторе имеет интерфейсы для управления трафиком, а в ЭВМ - интерфейсы для приложений (т.е., API), а также для управления трафиком (если такой контроль предусмотрен). 35.1. Интерфейс приложения RSVP Структура реального интерфейса может зависеть от операционной системы. Некоторые из вызовов предполагают асинхронную присылку информации.
Вызов: SESSION( DestAddress , ProtocolId, DstPort Этот вызов инициирует RSVP обработку сессии, заданной DestAddress, ProtocolId и, возможно, номером порта DstPort. В случае успеха вызов SESSION возвращает локальный идентификатор сессии Session-id, который может использоваться при последующих вызовах. Параметр Upcall_Proc_addr определяет адрес вызова процедуры получения кода ошибки или информации о событии. Параметр SESSION_object включен для организации механизма поддержки более общего описания сессии ("обобщенный порт назначения"). Обычно SESSION_object опускается.
Вызов: SENDER( Session-id Отправитель использует этот вызов, чтобы определить или модифицировать атрибуты информационного потока. Первое обращение к SENDER для регистрации сессии как `Session-id' заставит RSVP начать рассылку сообщений Path для данной сессии; последующие вызовы будут модифицировать информацию о проходе. Параметры SENDER интерпретируются следующим образом:
Вызов: RESERVE( session-id, [ receiver_address , ] Получатель использует этот вызов, для того чтобы осуществить или модифицировать резервирование для сессии `session-id'. Первое обращение RESERVE инициирует периодическую передачу сообщений Resv. Последующие вызовы RESERVE могут служить для модификации параметров предыдущих обращений. Опционный параметр `receiver_address' может использоваться получателем в маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами; это IP-адрес одного из интерфейсов узла. Флаг CONF_flag должен быть установлен, если желательно подтверждение резервирования. Параметр `Policy_data' специфицирует управляющие данные получателя, в то время как параметр `style' указывает на стиль резервирования. Остальные параметры зависят от стиля; обычно они соответствуют спецификациям фильтра и flowspecs.
Вызов: RELEASE( session-id ) Этот вызов удаляет состояние RSVP для сессии, указанной в session-id. Узел затем шлет соответствующие сообщения отмены (teardown) и прекращает рассылку сообщений обновления для session-id.
Общая форма вызова имеет вид: Обращение: <Upcall_Proc>( ) -> session-id, Info_type, "Upcall_Proc" представляет собой процедуру, чей адрес был дан при вызове SESSION. Это обращение может произойти асинхронно в любое время после вызова SESSION до вызова RELEASE и служит для индикации ошибки или события. В настоящее время имеется пять типов обращений, отличающихся параметром Info_type. Выбор информационных параметров зависит от типа. 1. Info_type = PATH_EVENT Обращение Path Event приводит к тому, что получение первого сообщения Path для данной сессии, указывает приложению получателя на наличие, по крайней мере, одного отправителя или на изменение состояние прохода. Обращение (отклик): <Upcall_Proc>( ) -> session-id, Это обращение выдает спецификации Sender_Tspec, Sender_Template, Adspec и управляющую информацию из запроса Path. 2. Info_type = RESV_EVENT Обращение Resv Event запускается в результате получения первого сообщения RESV, или как следствие модификации предшествующего состояния резервирования для данной сессии. Обращение (отклик): <Upcall_Proc>( ) -> session-id, `Flowspec' - эффективное значение QoS, которое получено. Заметим, что сообщение Resv (стиль FF) может вызвать несколько обращений RESV_EVENT, по одному для каждого дескриптора потока. 3. Info_type = PATH_ERROR Событие Path Error индицирует ошибку в информации отправителя, которая была специфицирована в запросе SENDER. Обращение (отклик): <Upcall_Proc>( ) -> session-id, Параметр Error_code определяет ошибку, а Error_value может нести в себе некоторую дополнительную (возможно системно-зависимую) информацию об ошибке. Параметр Error_Node специфицирует IP-адрес узла, который обнаружил ошибку. Параметр Policy_data_list, если он присутствует, содержит любые объекты POLICY_DATA из неудачного сообщения Path. 4. Info_type = RESV_ERR Событие Resv Error указывает на ошибку в сообщении резервирования, в формирование которого приняло участие данное приложение. Обращение (отклик): <Upcall_Proc>( ) -> session-id, Параметр Error_Node специфицирует IP-адрес узла, который обнаружил данное событие. Имеется два флага Error_flags: - InPlace Этот флаг может быть равен 1 при ошибке контроля доступа для индикации наличия резервирования в узле, где произошла ошибка. Этот флаг устанавливается при ошибке и транспортируется сообщениями ResvErr. - NotGuilty Этот флаг может быть равен 1 при ошибке контроля доступа для индикации того, что запрошенная получателем спецификация flowspec оказалась меньше той, которая вызвала ошибку. Этот флаг устанавливается API получателя. Filter_spec_list и Flowspec содержат соответствующие объекты из ошибки дескриптора потока. List_count специфицирует число FILTER_SPECS в списке Filter_spec_list. Параметр Policy_data_list содержит любые объекты POLICY_DATA из сообщения ResvErr. 5. Info_type = RESV_CONFIRM Событие Подтверждение указывает, что получено сообщение ResvConf. Обращение (отклик): <Upcall_Proc>( ) -> session-id, Параметры интерпретируются также как и для отклика Resv Error. Хотя сообщения RSVP, указывающие на события path или resv могут приходить периодически, API должно послать соответствующие асинхронные отклики приложению только на первое из них или при изменении полученной информации. Все события, сопряженные с ошибками или подтверждениями должны доводиться до сведения приложения. 36. Интерфейс управления трафиком RSVP Трудно представить общий интерфейс для управления трафиком, так как детали установления резервирования сильно зависят от технологии реализации канального уровня в интерфейсе. Объединение RSVP-резервирований необходимо из-за мультикастной доставки данных, при которой информационные пакеты размножаются для отправки последующим узлам. В каждой такой точке размножения, RSVP должен объединять запросы резервирования от последующих узлов путем выбора "максимума" их спецификаций flowspecs. В данном маршрутизаторе или ЭВМ может присутствовать несколько таких точек объединения/размножения. 1. IP-уровень Мультикастная IP рассылка выполняет разветвление потока на IP-уровне. В этом случае RSVP должен объединять резервирования, соответствующих выходных интерфейсов для последующей отправки запроса резервирования далее. 2. Сеть Размножение пакетов может иметь место и после узла, например, в широковещательных сетях, в переключателях канального уровня или системе маршрутизаторов, не поддерживающих RSVP. В этих случаях RSVP должен объединять запросы резервирования от ряда предыдущих узлов, для того чтобы выполнить резервирование для одного выходного интерфейса 3. Драйвер канального уровня В технологиях со множественным доступом размножение пакетов может осуществляться на уровне канального драйвера или сетевого интерфейса. В общем, эти сложности не влияют на реализацию протокола RSVP, нужно только четко определить какие запросы резервирования следует объединить. Может оказаться желательным организовать реализацию RSVP из двух блоков: ядро, которое выполняет канально-независимую обработку и адаптационный уровень, учитывающий канальную специфику.
Вызов: TC_AddFlowspec( Interface, TC_Flowspec, Параметр TC_Flowspec определяет желательное значение QoS для управления доступом;. Его значение вычисляется как максимум совокупности спецификаций flowspecs для последующих узлов (см. ниже описание вызова Compare_Flowspecs). Параметр TC_Tspec определяет эффективное значение спецификации отправителя Tspec Path_Te. Параметр TC_Adspec задает спецификацию Adspec. Параметр Police_Flags несет в себе три флага E_Police_Flag, M_Police_Flag и B_Police_Flag. Если данный вызов оказался успешным, он устанавливает новый канал резервирования, соответствующий RHandle; в противном случае, он возвращает код ошибки. Код RHandle используется вызывающей программой для будущих ссылок на это резервирование. Если служба управления трафиком модифицирует flowspec, вызов вернет модифицированный объект Fwd_Flowspec.
Вызов: TC_ModFlowspec( Interface, RHandle, TC_Flowspec, Этот вызов используется для модификации существующего резервирования. TC_Flowspec передается блоку контроля разрешения. Если разрешения нет, текущая спецификация flowspec остается в силе. Соответствующие спецификации фильтров, если таковые имеются, остаются не затронутыми. Другие параметры определены также как и в TC_AddFlowspec. Если система модифицирует flowspec, вызов вернет также модифицированный объект Fwd_Flowspec.
Вызов: TC_DelFlowspec( Interface, RHandle ) Этот вызов ликвидирует существующее резервирование, включая спецификацию flowspec и все сопряженные спецификации фильтров.
Вызов: TC_AddFilter( Interface, RHandle, Этот вызов добавляет новую спецификацию фильтра для резервирования, заданного RHandle. Запрос посылается после успешного вызова TC_AddFlowspec. Этот вызов возвращает дескриптор фильтра FHandle.
Вызов: TC_DelFilter( Interface, FHandle ) Этот вызов используется для удаления какого-либо фильтра, идентифицируемого FHandle.
Вызов: TC_Advertise( Interface, Adspec, Этот вызов используется при OPWA и служит для вычисления выходной спецификации New_Adspec для заданного интерфейса. Битовый флаг Non_RSVP_Hop_flag должен устанавливаться в случае, когда демон RSVP обнаруживает, что предшествующий узел содержит один или более маршрутизаторов, не поддерживающих RSVP. TC_Advertise вставит эту информацию в New_Adspec для оповещениястить обнаружения такого узла.
Обращение (отклик): TC_Preempt() -> RHandle, Reason_code Для того чтобы выдать новый запрос резервирования, модули контроля разрешения и управления могут осуществить выделение квот для одного или двух существующих резервирований. Это вызовет отклик TC_Preempt() на каждое привилегированное RSVP резервирование, отправляя дескриптор резервирования RHandle и субкод причины. 37. Интерфейс маршрутизации RSVP Реализация RSVP нуждается в следующей поддержке со стороны механизма маршрутизации узла.
Для пересылки сообщений Path и PathTear процесс RSVP должен быть способен запрашивать процесс маршрутизации с целью получения маршрутных данных. Ucast_Route_Query( [ SrcAddress, ] DestAddress, В зависимости от протокола маршрутизации запрос может зависеть или нет от SrcAddress, т.е., от IP-адреса ЭВМ-отправителя, который является также IP-адресом источника сообщения. IncInterface характеризует интерфейс, через который ожидается прибытие пакета. Некоторые мультикастные протоколы маршрутизации могут не выдавать этот адрес. Если флаг Notify_flag = True, блок маршрутизации отправит сообщение о непреднамеренном изменении маршрута, если такое изменение произойдет. Мультикастный маршрутный запрос может вернуть пустой список OutInterface_list, если за оговоренным маршрутизатором нет ни одного получателя. Запрос маршрутной информации может вернуть сообщение `No such route' (такой маршрут отсутствует) возможно, в результате временной рассогласованности (например, сообщение Path или PathTear для запрошенного маршрута не дошло). В любом случае локальное состояние должно быть актуализовано так, как это требуется в запросе, который не может быть переслан далее.
При маршрутном запросе с флагом Notify_flag = True, процесс маршрутизации может послать асинхронное сообщение процессу RSVP, который уведомляет об изменении определенного маршрута. Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
RSVP должен быть способен запоминать, какой реальный и виртуальный интерфейсы являются активными, а также их IP-адреса. Должна быть предусмотрена возможность логической дезактивации интерфейса для RSVP. Когда интерфейс дезактивирован, сообщения Path не должны проходить через данный интерфейс, если сообщение RSVP получено, оно должно быть отброшено (возможно, с соответствующей записью в журнале операций). 38. Пакетные I/O интерфейсы RSVP Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла.
Пакеты, полученные для IP-протокола (код 46) но не адресованные узлу, должны быть переправлены программе RSVP для последующей обработки. Сообщения RSVP переправляемые таким образом включают сообщения Path, PathTear и ResvConf. Эти типы сообщений несут в себе IP-опцию оповещение маршрутизатора (Router Alert), которая может быть использована для выделения этих пакетов в высокоскоростном канале переадресации. В качестве альтернативы узел может перехватывать все пакеты с кодом протокола 46. В маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами идентификация интерфейса (реального и виртуального), через который получено заданное сообщение, также как IP-адрес источника и TTL, с которым оно получено, должна быть также доступна для процесса RSVP.
RSVP должен уметь обеспечить посылку дейтограммы через специальный выходной интерфейс (реальный или виртуальный) в обход обычного механизма маршрутизации. Виртуальным каналом может быть, например, мультикастный туннель.
RSVP должен быть способен специфицировать IP-адрес отправителя и TTL, которые могут использоваться при посылке сообщений Path.
RSVP должен быть способен вызвать посылку сообщения Path, PathTear и ResvConf с опцией оповещения маршрутизатора (Router Alert). 39. Манипуляции, зависящие от вида услуг Flowspecs, Tspecs и Adspecs являются объектами, совершенно недоступными для RSVP; их содержимое определено в документах спецификации услуг. Для того чтобы манипулировать этими объектами процесс RSVP должен иметь в своем распоряжении следующие программы, зависящие от типа услуг.
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> Возможный результат операции result_codes указывает: flowspecs равны, Flowspec_1 меньше, Flowspec_2 больше, flowspecs совместимы и можно вычислить LUB, или flowspecs не совместимы. Заметим, что, сравнивая две спецификации, мы косвенно сопоставляем Tspecs, которые они содержат. Хотя процесс RSVP не может сам осуществить разбор flowspec с целью извлечения Tspec, он может использовать вызов процедуры Compare_Flowspecs для косвенного вычисления Resv_Te.
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code Возможным результатом процедуры result_codes может быть: Tspecs равны или Tspecs не равны.
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum Этот вызов используется для вычисления Path_Te. 40. Приложение A. Определения объектов C-типы определены для двух семейств адресов Интернет IPv4 и IPv6. Для работы с другими адресными семействами можно легко определить новый C-тип. Все неиспользуемые поля должны заполняться нулями и игнорироваться при получении .
Класс сессии
Объект IPv6/UDP SESSION: Класс = 1, C-тип = 2
DestAddress Уникастный или мультикастный IP-адрес места назначения сессии. Это поле не должно быть равно нулю. Протокол Id Идентификатор IP-протокола для потока данных. Это поле не должно быть равно нулю. Флаги 0x01 = E_Police flag Флаг E_Police используется в сообщениях Path для определения эффективного "края" сети, с целью организации управления трафиком. Если ЭВМ отправитель сама не способна осуществлять управление трафиком, она установит этот бит в сообщениях Path, которые посылает. Первый узел, где RSVP имеется возможность управления трафиком (если это требуется), установит этот флаг равным нулю. >DstPort UDP/TCP порт места назначения сессии. Допустимо значение нуль, означающее отсутствие порта. Класс RSVP_HOP RSVP_HOP класс = 3.
Объект IPv4 RSVP_HOP: Класс = 3, C-Тип = 1
Объект IPv6 RSVP_HOP: Класс = 3, C-Тип = 2 Этот объект несет в себе IP-адрес интерфейса, через который последний RSVP-узел переслал это сообщение. Дескриптор логического интерфейса LIH (Logical Interface Handle) используется, для того чтобы различать логические выходные интерфейсы. Узел, получая LIH в сообщении Path, запоминает его величину и возвращает его в объектах HOP последующих сообщений Resv, посланных узлу, который сформировал LIH. LIH должен быть тождественно равен нулю, если не существует дескриптора логического интерфейса. Класс INTEGRITY INTEGRITY класс = 4. Класс TIME_VALUES TIME_VALUES класс = 5.
Период обновления Период таймаута обновления R, использованного для генерации этого сообщения (в миллисекундах). Класс ERROR_SPEC ERROR_SPEC класс = 6.
Поле адрес узла, где произошла ошибка является IP-адресом (IPv4 или Ipv6). Флаги 0x01 = InPlace Это значение поля флаги используется только для объектов ERROR_SPEC в сообщении ResvErr. Если флаг = 1, это указывает, что в узле, где произошла ошибка, установлено резервирование. 0x02 = NotGuilty Это значение поля флаги используется только для объекта ERROR_SPEC в сообщении ResvErr. Это значение устанавливается для интерфейса в прикладной программе получателя. Если флаг имеет такой код, спецификация FLOWSPEC, которая вызвала ошибку, больше запрошенной получателем. Код ошибки.Одно-октетное поле кода описания ошибки. Значение ошибки Двухоктетное поле, содержащее дополнительную информацию об ошибке. Его содержимое зависит от типа ошибки. Значения поля код ошибки и значение ошибки приведены в приложении B (см. ниже). Класс SCOPE = 7.
Этот объект содержит список IP-адресов, использованных для сообщений маршрутизации с произвольным выбором отправителей (wildcard) без петель. Адреса должны быть перечислены в возрастающем порядке.
Объект Ipv6 SCOPE: Класс = 7, C-тип = 2 Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт. Класс STYLE = 8.
Поле Флаги: 8 бит. (Пока не определены) Вектор опций: 24 бита Этот набор битовых полей определяет опции резервирования. Если в будущем будут добавлены новые опции, нужно будет ввести соответствующие поля в вектор опций со стороны младших разрядов. Если узел не распознает идентификатор стиля, он может интерпретировать ту часть вектора опций, которая ему известна, игнорируя новые незнакомые ему поля. Биты вектора опций определены (слева направо) следующим образом: 19 бит: Зарезервировано 3 бита: Управление выбором отправителя Младшие биты вектора опций определяются стилем: WF 10001bFF 01010b SE 10010b Класс FLOWSPEC Класс FLOWSPEC = 9.
Содержимое и правила кодирования этого объекта описаны в документах, подготовленных рабочей группой int-serv [RFC 2210]. Класс FILTER_SPEC = 10.
Объект IPv6 FILTER_SPEC: Класс = 10, C-тип = 2 Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт.
SrcAddress. Это поле характеризует IP-адрес источника для ЭВМ отправителя. Его значение не должно быть равно нулю. SrcPort. UDP/TCP номер порта отправителя, или нуль, указывающий на отсутствие порта. Метка потока. 24-битовое поле метки потока, определенной в IPv6. Этот код может использоваться классификатором пакетов для эффективной идентификации кадров, принадлежащих определенному потоку данных (отправитель-> место назначения). Класс SENDER_TEMPLATE = 11.
Определение то же, что и для объекта IPv4/UDP FILTER_SPEC.
Определение то же, что и для объекта IPv6/UDP FILTER_SPEC.
Класс SENDER_TSPEC = 12.
Содержимое и правила кодирования для этого объекта специфицированы в документах, подготовленных рабочей группой int-serv. Класс ADSPEC = 13.
Содержимое и формат этого объекта специфицированы в документах, подготовленных рабочей группой int-serv. Класс POLICY_DATA = 14.
Содержимое этого объекта будет определено в будущем. Класс Resv_CONFIRM = 15.
Объект характеризует 4-байтовый IP-адрес получателя (Ipv4).
Объект характеризует 15-байтовый IP-адрес получателя (Ipv6). 41. Приложение B. Коды и значения ошибки Нижеприведенные коды ошибок могут встретиться в объектах ERROR_SPEC, и предназначены для пересылки оконечным системам. За исключением специально оговоренных случаев эти коды могут использоваться только в сообщениях ResvErr.
Это код зарезервирован для использования в объекте ERROR_SPEC сообщения ResvConf. Значение ошибки также будет равно нулю.
Запрос резервирования отвергнут системой управления допуском из-за недостатка ресурсов. Для этого кода ошибки 16 бит поля значение ошибки имеют формат: ssur cccc cccc cccc где биты имеют следующие значения: ss = 00: Младшие 12 бит содержат глобально-определенный субкод (значение приведены ниже). ss = 10: Младшие 12 бит содержат организационно-специфический субкод. Предполагается, что RSVP интерпретирует этот код как обычное число. ss = 11: Младшие 12 бит содержат субкод, зависящий от вида услуг. Предполагается, что RSVP интерпретирует этот код как обычное число. Так как механизм управления трафиком может предлагать различные услуги, кодирование может включать в себя некоторые особенности используемой услуги. u = 0: RSVP отвергает сообщение без модификации локального состояния u = 1: RSVP может использовать сообщение для модификации локального состояния и для последующей пересылки. Это означает, что сообщение является информационным. r: зарезервированный бит, должен быть равен нулю. cccc cccc cccc: 12 битовый код. Следующие глобально-заданные субкоды могут появиться в младших 12 битах, когда ssur = 0000: - Субкод = 1: Предел (bound) по задержке не может быть обеспечен.
Сообщение резервирования или path было отвергнуто по административным причинам, например, не выполнены условия аутентификации, недостаточная квота и т.д.. Этот код ошибки может появиться в сообщении PathErr или ResvErr. Содержимое поля значение ошибки должно быть определено в будущем.
Для этого кода ошибки 16 бит поля значения ошибки имеют формат: ssur cccc cccc cccc Ниже приведены значения старших бит ssur, как они определены при коде ошибки 01. Глобально-заданные субкоды, которые могут появиться в младших 12 битах, когда ssur = 0000 должны быть определены в будущем.
Для этого кода ошибки 16 бит поля значения ошибки имеют формат: ss00 cccc cccc cccc Ниже представлены значения старших бит ss, как это определено для кода ошибки 01. Следующие глобально-заданные субкоды могут появляться в младших 12 битах (cccc cccc cccc), когда ss = 00:
Поле значения ошибки предоставляет информацию об ошибке с учетом конкретной реализации приложения. Предполагается, что RSVP не может интерпретировать его значение. Вообще каждое сообщение RSVP переформируется в каждом узле, а узел, в котором генерируется RSVP сообщение, несет ответственность за его правильную структуру. Аналогично, каждый узел должен контролировать корректность структуры полученного им сообщения. В случае, когда из-за ошибки программы будет генерировано сообщение с некорректным форматом, оконечная система не обязательно будет проинформирована об этом. Ошибка, скорее всего, будет зафиксирована локально и передана через механизмы управления сетью. Единственными ошибками формата сообщений, которые доводятся до сведения оконечной системы, являются несоответствия версии. Ошибки формата сообщения, которые могут быть зафиксированы локально и сообщены приложению RSVP, относятся к числу специфических для данной реализации. Наиболее типичными из них можно считать следующие:
42. Приложение C. UDP-инкапсуляция Реализации RSVP обычно требуют возможности выполнять любые сетевые операции ввода/вывода, т.е., посылать и получать IP-дейтограммы, используя код протокола 46. Однако, некоторые важные классы вычислительных систем могут не поддерживать такого рода операции. Для использования RSVP, такие ЭВМ должны инкапсулировать сообщения RSVP в UDP-дейтограммы. Базовая схема UDP-инкапсуляции использует два предположения:
Пусть Hu является ЭВМ, которая нуждается в UDP-инкапсуляции, а Hr ЭВМ, способная выполнять любые сетевые операции ввода/вывода. Схема UDP-инкапсуляции должна допускать RSVP взаимодействие ЭВМ типа Hr, Hu и маршрутизаторов. Сообщения Resv, ResvErr, ResvTear и PathErr посылаются по уникастным адресам, полученным из состояний прохода или резервирования узла. Если узел отслеживает, в каком из предыдущих узлов и в каком интерфейсе нужна UDP-инкапсуляция, эти сообщения при необходимости могут быть посланы с применением UDP инкапсуляции. С другой стороны, сообщения Path и PathTear могут посылаться адресату с применением как мультикастных, так и уникастных адресов. В таблицах 4.4.9.6.1 и 4.4.9.6.2 приведены базовые правила UDP-инкапсуляции сообщений Path и PathTear, для уникастных и мультикастных DestAddress. Другие типы сообщений, которые работают с уникастными адресами, должны следовать правилам из табл. 4.4.9.6.1. Записи в колонке `RSVP посылает' имеют формат `mode(destaddr, destport)'. Полезно определить две разновидности UDP-инкапсуляций, одна используется для посылки сообщений от Hu, другая от Hr и R. Это делается, для того чтобы избежать двойной обработки сообщения получателем. На практике эти два вида инкапсуляций разделяются по номерам UDP портов Pu и Pu'. В таблицах используются следующие символы.
Таблица 4.4.9.6.1. Правила UDP-инкапсуляции для уникастных сообщений Path и Resv
Таблица 4.4.9.6.2. Правила UDP-инкапсуляции для мультикастных сообщений Path
Маршрутизатор может определить, нуждается ли его интерфейс Х в UDP-инкапсуляции, контролируя поступление UDP-инкапсулированных сообщений Path, которые были посланы либо G* (мультикаст D) либо по адресу интерфейса X (уникаст D). Для данной схемы существует один неудачный режим: если нет ни одной ЭВМ в сети, которая бы выполняла функцию RSVP отправителя, тогда не будет сообщений прохода (Path), чтобы запустить UDP-инкапсуляцию. В этом случае будет необходимо сконфигурировать UDP-инкапсуляцию для интерфейса локального маршрутизатора. Когда получен UDP-инкапсулированный пакет, в большинстве систем TTL не доступно для приложения. Процесс RSVP, который получает UDP-инкапсулированное сообщение Path или PathTear должен использовать поле Send_TTL общего RSVP-заголовка для извлечения значения TTL. В тех случаях, когда это по каким-либо причинам не приемлемо, значение TTL может быть задано вручную при конфигурации. Мы предположили, что первый маршрутизатор, поддерживающий RSVP, подключен непосредственно к локальной сети. Существует несколько подходов в случае, когда это не так.
Библиография
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.9.5 Протокол PIM
UP:
4.4 Интернет
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.10 Протокол загрузки BOOTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
В больших сетях некоторые рабочие станции (например, Х-терминалы) могут не иметь системного диска, а операционная система и сетевое программное обеспечение загружается через сеть. Для этого рабочая станция должна иметь стартовую программу, записанную в ПЗУ. Такое постоянное запоминающее устройство часто производится на фирме, изготовившей эту рабочую станцию, и по этой причине не содержат информации ни об адресе сервера, ни даже о своем IP-адресе. Выше был описан протокол RARP, который способен решать подобные задачи для случая, когда сервер находится в пределах данной локальной сети. Ведь RARP выдает широковещательный запрос на связном уровне, а он не ретранслируется маршрутизаторами. Более мощным средством для загрузки бездисковых станций является протокол BOOTP (Bootstrap протокол, RFC-951, -1048, -1532). BOOTP пригоден и для загрузки бездисковых маршрутизаторов. BOOTP в качестве транспортного использует UDP-протокол. ЭВМ-клиент (порт=68), которая хочет воспользоваться BOOTP, посылает широковещательное сообщение (по адресу = 255.255.255.255). Сервер (порт=67) в отличии от случая RARP не обязательно должен находиться в пределах данной локальной сети. В поле IP-адрес клиента будет записано 0.0.0.0, так как клиент пока не знает своего адреса. Получив запрос через порт 67, маршрутизатор помещает свой IP-адрес в поле IP-адрес маршрутизатора (см. формат запроса на рис. 4.4.10.1) и пересылает запрос действительному BOOTP-серверу, увеличив на 1 значение поля Hop#. По пути к серверу может быть несколько маршрутизаторов (но обычно не больше 3). Сервер не знает физического адреса клиента. Воспользоваться ARP-запросом он не может, так как клиент пока не знает своего IP-адреса и на ARP-запрос не откликнется. У сервера, получившего запрос, имеется две возможности. 1. Проанализировать пакет, извлечь из него физический адрес клиента и скорректировать ARP-таблицу. Так как программа загрузки находится на прикладном уровне, и ей запрещено исправлять ARP-таблицы, реально доступен только второй путь. Использование разных номеров портов для сервера и клиента делает работу системы более эффективной. Когда отклик сервера является широковещательным, это позволяет не прерывать работу прикладных программ, работающих с номерами портов, отличными от 68 (порт Bootp-клиента). В Bootp ответственность за надежность связи лежит на ЭВМ-клиенте. При отсутствии отклика в отведенное время клиент повторяет Bootp-запрос. На IP-уровне, где данные не имеют контрольной суммы, целостность сообщения не гарантирована. Bootp требует, чтобы проверка контрольной суммы обязательно проводилась на UDP-уровне (следует заметить, что обычно это не является обязательным). Сервер читает UDP-дейтограммы через порт 67. Для повышения надежности обменов, как правило, блокируется фрагментация дейтограмм. Загрузка рабочих станций часто запускается броском напряжения сетевого питания. При этом несколько Bootp-процессов стартуют одновременно. Для того чтобы снизить вероятность столкновений, величина времени тайм-аута выбирается случайно в интервале 0-4сек. После каждого повторного запроса это время удваивается. Верхнее значение тайм-аута равно 60сек. Для справок время загрузки бездискового x-терминала при благоприятных условиях может составлять около 20 сек. bootp осуществляет загрузку в два этапа. На первом этапе bootp лишь снабжает клиента информацией, где лежит нужные ему данные. Далее ЭВМ-клиент использует протокол RFTP для получения искомого загружаемого файла. Bootp-сервер не обязательно должен работать на той же машине, где хранятся загружаемые файлы, но он должен знать их имена. Формат Bootp-сообщений представлен на рис. 4.4.10.1.
Рис. 4.4.10.1. Формат сообщений BOOTP Поле операция=1 говорит о том, что данное сообщение запрос, а значение операция=2 указывает на то, что сообщение является откликом. Поля H-тип и Hlen определяют тип используемого оборудования и длину аппаратного адреса (для Ethernet H-тип=1, а HLen=6). ЭВМ-клиент кладет в поле Hop# (число шагов) нуль. Если BOOTP-сервер, получив запрос, решит передать его другой ЭВМ, он увеличит значение этого поля на 1, и так далее. Поле идентификатор операции содержит целое число, которое на бездисковых машинах позволяет связать в пары запросы и отклики. Поле секунды хранит время с момента начала процедуры загрузки (BOOT). ЭВМ-клиент заполняет все последующие поля, если она этой информацией владеет, в противном случае поля обнуляются. Возможность указания имени BOOT(загрузочного)-файла позволяет учесть индивидуальность конфигурации конкретной ЭВМ и пожелания относительно загружаемой операционной системы. Поле специфическая информация поставщика содержит информацию, которая передается от сервера к ЭВМ-клиенту. Первые 4 октета этого поля носят название "волшебное печенье" (magic cookie) и определяют формат остальных субполей. Если в указанном поле имеется информация, субполе волшебное печенье имеет значение 99.130.83.99. Вслед за этим субполем следует последовательность субполей, содержащих один октет тип, опционный октет длина и многооктетное субполе значение. Стандарт предусматривает следующие разновидности субполей: Таблица 4.4.10.1 Разновидности субполей и их коды (BOOTP)
Определены и другие субполя (RFC-1533), субполе конец (255) помечает конец поля. Хотя маска субсети может быть получена с помощью ICMP-запроса, стандарт требует, чтобы маска присылалась BOOT-сервером в ответ на каждый запрос, что исключает лишние ICMP-сообщения. Маска субсети может быть записана в поле специфическая информация поставщика, как это видно из таблицы. Время дня (тип=2) отсчитывается в секундах от 1-го января 1900 года. В новом протоколе DHCP (Dynamic Host Configuration Protocol, RFC-1531, протокол динамического конфигурирования системы) размер поля специфическая информация поставщика расширен до 312 байт. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.9.7 Протокол COPS (Common Open Policy Service)
UP:
4.4 Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||
|
Основная задача сетей - транспортировка информации от ЭВМ-отправителя к ЭВМ-получателю. В большинстве случаев для этого нужно совершить несколько пересылок. Проблему выбора пути решают алгоритмы маршрутизации. Если транспортировка данных осуществляется дейтограммами, для каждой из них эта задача решается независимо. При использовании виртуальных каналов выбор пути выполняется на этапе формирования этого канала. В Интернет с его IP-дейтограммами реализуется первый вариант, а в ISDN - второй. Алгоритм маршрутизации должен обладать вполне определенными свойствами: надежностью, корректностью, стабильностью, простотой и оптимальностью. Последнее свойство не так прозрачно, как это может показаться на первый взгляд, все зависит от того, по какому или каким параметрам производится оптимизация. Эта задача иногда совсем не проста даже для сравнительно простых локальных сетей (смотри, например, рис. 4.4.11.1). Предположим, что поток данных между ЭВМ b и d, соединенных через концентратор (К) весьма высок, что окажет ощутимое влияние на скорость обмена между ЭВМ А и С. Но этот факт довольно трудно выявить, находясь в ЭВМ А или С. Внешне это проявится лишь как повышенная задержка и пониженная пропускная способность участка А-С.
Рис. 4.4.11.1 Среди параметров оптимизации может быть минимальная задержка доставки, максимальная пропускная способность, минимальная цена, максимальная надежность или минимальная вероятность ошибки. Алгоритмы маршрутизации бывают адаптивными и неадаптивными. Вторые, осуществляя выбор маршрута, не принимают во внимание существующую в данный момент топологию или загрузку каналов. Такие алгоритмы называются также статическими. Адаптивные же алгоритмы предполагают периодическое измерение характеристик каналов и постоянное исследование топологии маршрутов. Выбор того или иного маршрута здесь производится на основании этих измерений. Практически все методы маршрутизации базируются на следующем утверждении (принцип оптимальности). Если маршрутизатор M находится на оптимальном пути от маршрутизатора I к маршрутизатору J, тогда оптимальный путь от М к J проходит по этому пути. Чтобы убедиться в этом обозначим маршрут I-M R1, а m-j - R2. Если существует маршрут оптимальнее, чем R2, то он должен быть объединен с R1, чтобы образовать более оптимальный путь I-J, что противоречит исходному утверждению об оптимальности пути J-J. Следствием принципа оптимальности является утверждение, что оптимальные маршруты от всех отправителей к общему месту назначения образуют дерево, лишенное циклов (см. разделы "Протокол ospf" и "Элементы теории графов"). Такое дерево (называется sink tree) может быть не единственным, могут существовать другие деревья с теми же длинами пути. А это, в свою очередь означает, что любой пакет будет доставлен за строго ограниченное время, пройдя однократно определенное число маршрутизаторов Главным параметром при маршрутизации пакета в Интернет является ip-адрес его места назначения. Проблема оптимальной маршрутизации в современном Интернет, насчитывающем уже более десяти миллионов узлов, весьма сложна. Полная таблица маршрутов может содержать 107! записей (здесь ! означает знак факториала, а не выражение эмоций), что не по плечу не только сегодняшним ЭВМ. Обычный пользователь не задумывается и не должен задумываться над проблемами маршрутизации, но даже ему иногда может оказаться полезным понимать, что возможно, а что невозможно в Интернет. Нужно только четко разделять работу протоколов маршрутизации, которые формируют маршрутные таблицы, и процесс маршрутизации пакетов, когда эти таблицы используются. IP делит все ЭВМ на маршрутизаторы и обычные ЭВМ (host), последние, как правило, не рассылают свои маршрутные таблицы. Предполагается, что маршрутизатор владеет исчерпывающей информацией о правильных маршрутах (хотя это и не совсем так). Обычная ЭВМ имеет минимальную маршрутную информацию (например, адрес маршрутизатора локальной сети и сервера имен). Автономная система может содержать множество маршрутизаторов, но взаимодействие с другими as она осуществляет только через один маршрутизатор, называемый пограничным (border gateway, именно он дал название протоколу bgp). Пограничный маршрутизатор нужен лишь тогда, когда автономная система имеет более одного внешнего канала, в противном случае его функции выполняет порт внешнего подключения (gateway). Если адресат достижим более чем одним путем, маршрутизатор должен сделать выбор, этот выбор осуществляется на основании оценки маршрутов-кандидатов. Обычно каждому сегменту, составляющему маршрут, присваивается некоторая величина - оценка этого сегмента. Каждый протокол маршрутизации использует свою систему оценки маршрутов. Оценка сегмента маршрута называется метрикой. Здесь следует обратить внимание на то, что при выборе маршрута всем сегментам пути должны быть даны сопоставимые значения метрики. Недопустимо, чтобы одни сегменты оценивались числом шагов, а другие - по величине задержки в миллисекундах. В пределах автономной системы это обычно не создает проблем, ведь это зона ответственности одного администратора. Но в региональных сетях, где работает много администраторов, проблема выбора метрики может стать реальной трудностью. Именно по этой причине в таких сетях часто используется вектор расстояния, исключающий субъективность оценок метрики. Помимо классической схемы маршрутизации по адресу места назначения, часто используется вариант выбора маршрута отправителем (данный вариант получил дальнейшее развитие при введении стандарта IPv6). В этом случае IP-пакет содержит соответствующий код опции и список промежуточных адресов узлов, которые он должен посетить по пути к месту назначения. Существуют и другие схемы, например, использующие широковещательные методы адресации (flooding), где каждый приходящий пакет посылается по всем имеющимся исходящим каналам, за исключением того, по которому он получен. С тем чтобы исключить беспредельное размножение пакетов в заголовок вводится поле-счетчик числа шагов. В каждом узле содержимое поле уменьшается на единицу. Когда значение поля становится равным нулю, пакет ликвидируется. Исходное значение счетчика определяется размером субсети. Предпринимаются специальные меры против возможного зацикливания пакетов. Существует усовершенствованная версия широковещательной маршрутизации, называемая селективной широковещательной рассылкой. В этом алгоритме рассылка производится не по всем возможным направлениям, а только по тем, которые предположительно ведут в правильную сторону. Широковещательные методы не относятся к широко применимым. Но они используются там, где нужна предельно возможная надежность, например в военных приложениях, когда весьма вероятно повреждение тех или иных каналов. Данные методы могут использоваться лишь при формировании виртуального канала, ведь они всегда обеспечивают наикратчайший путь, так как перебираются все возможности. Если путь записывается в пакете, получатель может выбрать оптимальный проход и уведомить об этом отправителя. Большинство алгоритмов учитывают топологию связей, а не их качество (пропускную способность, загрузку и пр.). Но существуют подходы к решению проблемы статической маршрутизации, учитывающие как топологию, так и загрузку (flow-based routing). В некоторых сетях потоки между узлами относительно стабильны и предсказуемы. В этом случае появляется возможность вычислить оптимальную схему маршрутов заранее. Здесь на основе теории массового обслуживания производится оценка средней задержки доставки для каждой связи. Топология маршрутов оптимизируется по значению задержки доставки пакета. Исходными данными при расчете считается описание топологии связей, матрица трафика для всех узлов Ti,j (в пакетах в секунду) и матрица пропускных способностей каналов Bi,j в битах в секунду. Задержка t для каждой из связей оценивается по формуле t i,j = 1/(p*bi,j - ti,j), где 1/Р - среднее значение ширины пакета в битах, произведение p*bi,j выражается в пакетах в секунду, а t измеряется в мсек. Сформировав матрицу t i,j, можно получить граф кратчайших связей. Так как вычисления производятся не в реальном масштабе времени, особых трудностей здесь не возникает. Статические протоколы (примером реализации статических протоколов может служить первая версия маршрутизатора Netblazer) предполагают, что любые изменения в маршрутные таблицы вносит администратор сети. Рассмотрим для примера сеть, изображенную на рис. 4.4.11.2.
Рис. 4.4.11.2 Схема для иллюстрации методики составления маршрутных таблиц. Примитивная таблица маршрутизации для приведенного примера может иметь вид (для маршрутизатора g2):
Заметно сокращает размер маршрутной таблицы маршруты по умолчанию. В этой схеме сначала ищется маршрут в таблицах, а если он не найден, пакет посылается в узел, специально выбранный для данного случая. Так, когда имеется только один канал за рубеж, неудачный поиск в таблице маршрутов по России означает, что пакет следует послать по этому каналу и пусть там с ним разбираются. Маршруты по умолчанию используются обычно тогда, когда маршрутизатор имеет ограниченный объем памяти или по какой-то иной причине не имеет полной таблицы маршрутизации. Маршрут по умолчанию может помочь реализовать связь даже при ошибках в маршрутной таблице. Это может не иметь никаких последствий для малых сетей, но для региональных сетей с ограниченной пропускной способностью такое решение может повлечь серьезные последствия. Экономия на памяти для маршрутных таблиц - дурной стиль, который не доведет до добра. Например, из-за такого рода ошибки довольно долго пакеты из Ярославля в Москву шли через США, я уже не говорю о случае, когда машины, размещенные в соседних комнатах Президиума РАН, вели обмен через Амстердам (правда, это было достаточно давно). Алгоритм выбора маршрута универсален и не зависит от протокола маршрутизации, который используется лишь для формирования маршрутной таблицы. Описание алгоритма выбора маршрута представлено ниже: Извлечь IP-адрес (ID) места назначения из дейтограммы. Вычислить IP-адрес сети назначения (IN) Если сеть включает в себя субсети, то для каждой записи в маршрутной таблице производится побитная операция <И> для ID и маски субсети. Если результат этой операции совпадет с содержимым адресного поля сети, дейтограмма посылается серверу субсети. На практике при наличии субсетей в маршрутную таблицу добавляются соответствующие записи с масками и адресами сетей. Одна из базовых идей маршрутизации заключается в том, чтобы сконцентрировать маршрутную информацию в ограниченном числе (в идеале в одном) узловых маршрутизаторов-диспетчеров. Эта замечательная идея ведет к заметному увеличению числа шагов при пересылке пакетов. Оптимизировать решение позволяет backbone (опорная сеть), к которой подключаются узловые маршрутизаторы. Любая as подключается к backbone через узловой маршрутизатор. "Прозрачные" backbone не работают с адресами класса С (все объекты такой сети должны иметь один адрес, а для c-класса число объектов слишком ограничено). "Прозрачные" мосты трудно диагностировать, так как они не следуют протоколу ICMP (команда ping не работает, в последнее время такие объекты снабжаются snmp-поддержкой). За то они позволяют перераспределять нагрузку через несколько маршрутизаторов, что невозможно для большинства протоколов.
Рис. 4.4.11.3. В примере, приведенном на рис. 4.4.11.3, задача маршрутизации достаточно сложна. ЭВМ1,2 и ЭВМ6,1 можно связать многими путями: ЭВМ1,2 - GW1 - ЭВМ6,1; ЭВМ1,2 - GW2 - ЭВМ6,1; ЭВМ1,2 - GW3 - ЭВМ6,1; ЭВМ1,2 - GW4 - ЭВМ6,1; ЭВМ1,2 - GW1 - GW2 - GW3 - ЭВМ6,1; и т.д. Трафик между двумя географически близкими узлами должен направляться кратчайшим путем, вне зависимости от направления глобальных потоков. Так ЭВМ1,2 и ЭВМ1,1 должны соединяться через GW1. Маршрутизация через опорные сети (backbone) требует индивидуального подхода для каждого узла. Администраторы опорных сетей должны согласовывать свои принципы маршрутизации. Ситуация, когда узел не владеет исчерпывающей маршрутной информацией, в сочетании с использованием маршрутов по умолчанию может привести к зацикливанию пакетов. Например, если маршрут по умолчанию в GW1 указывает на GW2, а в GW2 на GW1, то пакет с несуществующим адресом будет циркулировать между gw1 и gw2 пока не истечет ttl (время жизни пакета), полностью блокируя канал. По этой причине желательно иметь полную таблицу маршрутизации, и, если не вынуждают обстоятельства, избегать использования маршрутов по умолчанию.
Рис. 4.4.11.4. Протоколы маршрутизации отличаются друг от друга тем, где хранится и как формируется маршрутная информация. Оптимальность маршрута достижима лишь при полной информации обо всех возможных маршрутах, но такие данные потребуют слишком большого объема памяти. Полная маршрутная информация доступна для внутренних протоколов при ограниченном объеме сети. Чаще приходится иметь дело с распределенной схемой представления маршрутной информации. Маршрутизатор может быть информирован лишь о состоянии близлежащих каналов и маршрутизаторов. Динамические протоколы (обычно используются именно они, наиболее известным разработчиком является компания CISCO): В маршрутизаторе с динамическим протоколом (например, BGP-4) резидентно загруженная программа-драйвер изменяет таблицы маршрутизации на основе информации, полученной от соседних маршрутизаторов. В ЭВМ, работающей под UNIX и выполняющей функции маршрутизатора, эту задачу часто решает резидентная программа gated или routed (демон). Последняя - поддерживает только внутренние протоколы маршрутизации. Применение динамической маршрутизации не изменяет алгоритм маршрутизации, осуществляемой на IP-уровне. Программа-драйвер при поиске маршрутизатора-адресата по-прежнему просматривает таблицы. Любой маршрутизатор может использовать два протокола маршрутизации одновременно, один для внешних связей, другой - для внутренних. Любая автономная система (AS, система маршрутизаторов, ЭВМ или сетей, имеющая единую политику маршрутизации) может выбрать свой собственный протокол маршрутизации. Внутренний протокол маршрутизации IGP (Interior Gateway Protocol) определяет маршруты внутри автономной системы. Наиболее популярный IGP - RIP (Routing Information Protocol, RFC-1058), разработан Фордом, Фулкерсоном и Белманом (фирма XEROX). Существует более новый протокол OSPF (Open Shortest Pass First, RFC-1131, -1245, -1247, -1253). Наиболее старые системы (IGP) используют протокол HELLO. Протокол HELLO поддерживался фирмой DEC, в качестве метрики он использует время, а не число шагов до цели. Для взаимодействия маршрутизаторов используются внешние протоколы (EGP - Exterior Gateway Protocols). Одной из разновидностей EGP является протокол BGP (Border Gateway Protocol, RFC-1268 [BGP-3], RFC-1467 [BGP-4]). Протокол IGRP (Interior Gateway Routing Protocol) разработан компанией CISCO для больших сетей со сложной топологией и сегментами, которые обладают различной полосой пропускания и задержкой. Это внутренний протокол маршрутизации имеет некоторые черты сходства с OSPF. IGRP использует несколько типов метрики, по одной на каждый вид QOS. Метрика характеризуется 32-разрядным числом. В однородных средах этот вид метрики вырождается в число шагов до цели. Маршрут с минимальным значением метрики является предпочтительным. Актуализация маршрутной информации для этого протокола производится каждые 90 секунд. Если какой-либо маршрут не подтверждает своей работоспособности в течение 270 сек, он считается недоступным. После семи циклов (630 сек) актуализации такой маршрут удаляется из маршрутных таблиц. IGRP аналогично OSPF производит расчет метрики для каждого вида сервиса (TOS) отдельно. Протокол IDPR (InterDomain Policy Routing Protocol, RFC-1477, -1479) представляет собой разновидность BGP-протокола. Протокол IS-IS (Intermediate System to Intermediate System Protocol, RFC-1195, -1142) является еще одним внутренним протоколом, который используется для маршрутизации CLNP (Connectionless Network Protocol, RFC-1575, -1561, -1526). IS-IS имеет много общего с OSPF. Смотри также бесклассовый протокол маршрутизации CIDR . Сразу после включения маршрутизатор не имеет информации о возможностях соседних маршрутизаторов. Статичесикие маршрутные таблицы могут храниться в постоянной памяти или загружаться из какого-то сетевого сервера. По этой причине первейшей задачей маршрутизатора является получение маршрутной информации от соседей, а для начала выявление наличия соседей и их адресов. Для этой цели посылается специальный пакет Hello через каждый из своих внешних интерфейсов. В ответ предполагается получить отклик, содержащий идентификационную информацию соответствующего маршрутизатора. Когда два или более маршрутизаторов объединены через локальную сеть, ситуация несколько усложняется. Смотри рис. 4.4.11.5. Маршрутизаторы E, F, G и H подключены непосредственно к локальной сети, некоторые из них имеют связи с другими маршрутизаторами (сети, которые они обслуживают, на рисунке не показаны). Одним из способов смоделировать локальную сеть - рассматривать маршрутизаторы E, F, G и H, как соединеные непосредственно, введя виртуальный узел сети L (выделен зеленым цветом). На правой части рисунка показан граф такой сети. Возможность прохода из узла F к G обозначена путем FLG. Для протоколов, учитывающих состояние канала, желательно иметь исчерпывающую информацию о нем (загрузка, задержка, пропускная способность, надежность, стоимость и т.д.). Некоторые из перечисленных параметров довольно легко измерить, например, задержку. Для этого вполне пригоден протокол ICMP. К сожалению многие из указанных параметров довольно сильно коррелированы и подвержены флуктуациям. В частности результаты измерения задержки зависят от загрузки канала (вариация времени ожидания в очереди).
Рис. 4.4.11.5. Маршрутизаторы, подключенные к локальной сети Рассмотрим трафик на пути А-Н. Допустим на основании анализа состояния канал выбран путь через узел Е. В этом случае он может оказаться перегружен, что приведет к большим задаржкам пакетов на пути А-Н. Последующий анализ ситуации может привести к тому, что более оптимальным может оказаться маршрут через узел F. Если будет принято решение переключить трафик на маршрут ACFH, может перегрузиться участок АСF и история повторится. Данный сценарий описывает типичную ситуацию с осцилляциями маршрута. Осцилляции маршрутов не так безобидны, как это может показаться. Маршрутные таблицы в маршрутизаторах актуализуются вдоль пути с заметными задержками и отнюдь не синхронно. Такие осцилляции могут в разы понизить пропускную способность сети, что необходимо учитывать, выбирая параметры протоколов маршрутизации. К сожалению многие современные протоколы маршрутизации не имеют встроенных средств аутентификации (контроля доступа), что делает их уязвимыми для различных злоупотреблений. В последнее время все больше людей обзаводятся компактными переносимыми ЭВМ, которые они берут с собой в деловые поездки, и хотели бы использовать в привычном режиме для работы в Интернет. Конечно, можно заставить модем дозвониться до вашего модемного пула в офисе, но это не всегда лучшее решение как по надежности так и по цене. Пользователи с точки зрения их подвижности могут быть разделены на три группы:
Предполагается, что все эти пользователи имеют свою постоянную приписку к какой-то сети и соответствующий постоянный IP-адрес. (см. RFC-2794 "Mobile IP Network Access Identifier Extension for IPv4. P. Calhoun, C. Perkins. March 2000). На рис. 4.4.11.6 показана схема подключения подвижных пользователей к Интернет. В этой схеме предполагается наличие в каждой области сети Интернет внешнего агента, обеспечивающего доступ к этой зоне подвижных ЭВМ (на рисунке такой агент помечен надписью "чужая LAN"). Доступ может осуществляться через мобильную телефонную сеть. Предполагается также наличие соответствующего агента в "домашней" LAN, куда стационарно приписана данная ЭВМ. Домашний агент отслеживает все перемещения своих пользователей, в том числе и тех, кто подключается к "чужим" LAN.
Рис. 4.4.11.6. Схема подключения к Интернет подвижных объектов Когда к локальной сети подключается новый пользователь (непосредственно физически или через модем сотовой телефонной сети), он должен там зарегистрироваться. Процедура регистрации включает в себя следующие операции:
Когда пользователь покидает зону обслуживания данной LAN или MAN, регистрация должна быть анулирована, а ЭВМ должна быть автоматически зарегистрирована в новой зоне. Когда посылается пакет мобильному пользователю, "домашняя LAN", получив его, маршрутизирует пакет внешнему агенту, зарегистрировавшему данного пользователя. Этот агент переправит пакет адресату. Процедуры переадресации выполняются с привлечением технологии IP-туннелей. Домашний агент предлагает отправителю посылать пакеты непосредственно внешнему агенту области, где зарегистрирована подвижная ЭВМ. Существует много вариантов реализации протокола с разным распределением функций между маршрутизаторами и ЭВМ. Существуют схемы и временным выделением резервного IP-адреса подвижному пользователю. Международный стандарт для решения проблемы работы с подвижными пользователями пока не разработан. В локальных или корпоративных сетях иной раз возникает необходимость разослать некоторую информацию всем остальным ЭВМ-пользователям сети (штормовое предупреждение, изменение курса акций и т.д.). Отправителю достаточно знать адреса всех N заинтересованных пользователей и послать им соответствующее сообщение. Данная схема крайне не эффективна, ведь обычная широковещательная адресация предлагает решение в N раз лучше с точки зрения загрузки сети (посылается одно а не N сообщений). Широковещательная адресация сработает, если в локальной сети нет маршрутизаторов, в противном случае широковещательные адреса МАС-типа заменяются на IP-адреса (что, впрочем, не слишком изящное решение) или применяется мультикастинг адресация. Маршрутизация для мультикастинга представляет собой отдельную задачу. Ведь здесь надо проложить маршрут от отправителя к большому числу получателей. Традиционные методы маршрутизации здесь применимы, но до крайности не эффективны. Здесь для целей выбора маршрута можно с успехом применить алгоритм "расширяющееся дерево" (spanning tree; не имеет циклических структур). Когда на вход маршрутизатора приходит широковещательный пакет, он проверяет, является ли интерфейс, через который он пришел, оптимальным направлением к источнику пакета. Если это так, пакет направляется через все внешние интерфейсы кроме того, через который он пришел. В противном случае пакет игнорируется (так как скорее всего это дубликат). Этот алгоритм называется Reverse Path Forwarding (переадресация в обратном направлении). Пояснение работы алгоритма представлено на рис. 4.4.11.7 (прямоугольниками на рис. обозначены маршрутизаторы). Секция I характеризует топологию сети. Справа показано дерево маршрутов для маршрутизатора I (sink tree). Секция III демонстрирует то, как работает алгоритм Reverse Path Forwarding. Сначала I посылает пакеты маршрутизаторам B, F, H, J и L. Далее посылка пакетов определяется алгоритмом.
Рис. 4.4.11.7. Алгоритм Reverse Path Forwarding При передаче мультимедиа информации используются принципиально другие протоколы маршрутизации. Здесь путь прокладывается от получателя к отправителю, а не наоборот. Это связано с тем, что там при доставке применяется мультикастинговый метод. Здесь, как правило, один отправитель посылает пакеты многим потребителям. При этом важно, чтобы размножение пакета происходило как можно ближе к кластеру адресатов. Такая стратегия иной раз удлинняет маршрут, но всегда снижает результирующую загрузку сети. Смотри описания протоколов DVMRP и PIM. В последнее время конфигурирование сетевого оборудования (маршрутизаторов, DNS и почтовых серверов усложнилось нкастолько, что это стало составлять заметную часть издержек при формировании коммуникационного узла. Заметного упрощенияи удешевления маршрутизаторов можно ожидать при внедрении IPv6. Следующим шагом станет внедрение объектно-ориентированного языка описания маршрутной политики RPSL (Routing Policy Specification Language). Здесь конфигурирование маршрутизатора будет осуществляться на основе описанной маршрутной политики. Теперь немного подробнее о наиболее популярных протоколах маршрутизации - RIP, OSPF, IGRP и BGP-4. Начнем с внутреннего протокола маршрутизации RIP. |
||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.10 Протокол загрузки BOOTP
UP:
4.4 Интернет
|
|
|
||||||||||||
|
4.4.11.1 Внутренний протокол маршрутизации RIP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||
|
Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей (алгоритм Белмана-Форда). Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC Unix (4BSD). Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. Описания этих маршрутов хранится в специальной таблице, называемой маршрутной. Таблица маршрутизации RIP содержит по записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя: IP-адрес места назначения. Первым двум полям записи мы обязаны появлению термина вектор расстояния (место назначение - направление; метрика - модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте, или произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать три типа ошибок:
Несоответствие маршрутной таблицы реальной ситуации типично не только для RIP, но характерно для всех протоколов, базирующихся на векторе расстояния, где информационные сообщения актуализации несут в себе только пары кодов: адрес места назначение и расстояние до него. Пояснение проблемы дано на рис. 4.4.1.11.1 ниже.
На верхней части рисунка показана ситуация, когда маршрутизаторы указывают маршрут до сети в соответствии со стрелками. На нижней части связь на участке GW1 <Сеть a> оборвана, а GW2 по-прежнему продолжает оповещать о ее доступности с числом шагов, равным 2. При этом GW1, восприняв эту информацию (если GW2 успел передать свою маршрутную информацию раньше GW1), может перенаправить пакеты, адресованные сети А, на GW2, а в своей маршрутной таблице будет характеризовать путь до сети А метрикой 3. При этом формируется замкнутая петля маршрутов. Последующая широковещательная передача маршрутных данных GW1 и GW2 не решит эту проблему быстро. Так после очередного обмена путь от gw2 до сети А будет характеризоваться метрикой 5. Этот процесс будет продолжаться до тех пор, пока метрика не станет равной 16, а это займет слишком много циклов обмена маршрутной информацией. Проблема может быть решена следующим образом. Маршрутизатор запоминает, через какой интерфейс получена маршрутная информация, и через этот интерфейс эту информацию уже не передает. В рассмотренном выше примере GW2 не станет посылать информацию о пути к сети А маршрутизатору GW1, от которого он получил эти данные. В этом случае в маршрутной таблице GW1 путь до А исчезнет сразу. Остальные маршрутизаторы узнают о недостижимости сети А через несколько циклов. Существуют и другие пути преодоления медленных переходных процессов. Если производится оповещение о коротком пути, все узлы-получатели воспринимают эти данные немедленно. Если же маршрутизатор закрывает какой-то путь, его отмена фиксируется остальными лишь по тайм-ауту. Универсальным методом исключения ошибок при маршрутизации является использование достаточно большой выдержки, перед тем как использовать информацию об изменении маршрутов. В этом случае к моменту изменения маршрута эта информация станет доступной всем участникам процесса маршрутизации. Но все перечисленные методы и некоторые другие известные алгоритмы, решая одну проблему, часто вносят другие. Многие из этих методов могут при определенных условиях вызвать лавину широковещательных сообщений, что также дезорганизует сеть. Именно малая скорость установления маршрутов в RIP (и других протоколах, ориентированных на вектор расстояния) и является причиной их постепенного вытеснения другими протоколами.Но даже усовершенствование, изложенное выше, не всегда срабатывает. На рис. 4.4.11.1а приведен пример, когда переходной процесс, несмотря на усовершенствование будет идти долго. При обрыве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает узлам А и Б. К сожалению А знает, что Б имеет проход к Г длиной 2, из чего он делает вывод о достижимости Г за три шага. Аналогично рассуждает Б о возможности достижимости Г через А. Далее при последующих рассылках метрика доступности Г, характеризуется все большими значениями, до тех пор пока не станет равной "бесконечности".
В RIP сообщения инкапсулируются в udp-дейтограммы, при этом передача осуществляется через порт 520. В качестве метрики RIP использует число шагов до цели. Если между отправителем и приемником расположено три маршрутизатора (gateway), считается, что между ними 4 шага. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, например, два шага по сегментам сети ethernet обеспечат большую пропускную способность, чем один шаг через последовательный канал на основе интерфейса RS-232. Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для других протоколов маршрутизации). Каждому маршруту ставится в соответствие таймер тайм-аута и "сборщика мусора". Тайм-аут-таймер сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время "уборки мусора" (2мин). При появлении эквивалентного маршрута переключения на него не происходит, таким образом, блокируется возможность осцилляции между двумя или более равноценными маршрутами. Формат сообщения протокола RIP имеет вид, показанный на рис. 4.4.11.2. Поле команда определяет выбор согласно следующей таблице: Таблица 4.4.11.1. Значения кодов поля команда
Поле версия для RIP равно 1 (для RIP-2 двум). Поле набор протоколов сети i определяет набор протоколов, которые используются в соответствующей сети (для Интернет это поле имеет значение 2). Поле расстояние до сети i содержит целое число шагов (от 1 до 15) до данной сети. В одном сообщении может присутствовать информация о 25 маршрутах. При реализации RIP можно выделить следующие режимы: Инициализация, определение всех "живых" интерфейсов путем посылки запросов, получение таблиц маршрутизации от других маршрутизаторов. Часто используются широковещательные запросы. Получен запрос. В зависимости от типа запроса высылается адресату полная таблица маршрутизации, или проводится индивидуальная обработка. Получен отклик. Проводится коррекция таблицы маршрутизации (удаление, исправление, добавление).
Рис. 4.4.11.2. Формат сообщения RIP. Регулярные коррекции. Каждые 30 секунд вся или часть таблицы маршрутизации посылается всем соседним маршрутизаторам. Могут посылаться и специальные запросы при локальном изменении таблицы. RIP достаточно простой протокол, но, к сожалению не лишенный недостатков:
Протокол RIP-2 (RFC-1388, 1993 год) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг; позволяет работать с масками субсетей. На рис. 4.4.11.3 представлен формат сообщения для протокола RIP-2. Поле маршрутный демон является идентификатором резидентной программы-маршрутизатора. Поле метка маршрута используется для поддержки внешних протоколов маршрутизации, сюда записываются коды автономных систем. При необходимости управления доступом можно использовать первые 20 байт с кодом набора протоколов сети 0xFFFF и меткой маршрута =2. Тогда в остальные 16 байт можно записать пароль.
Рис. 4.4.11.3 Формат сообщений протокола RIP-2 Проблемы аутентификации в протоколе RIP-2 c использованием дайджестов MD5 обсуждаются в документе RFC-2082 |
||||||||||||
|
Previous:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
|
4.4.11.6 Автономные системы
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Базовым элементом технологии Интернет является модуль IP. Его центральной частью является таблица маршрутов, используемая для принятия решения о направлении IP-пакета по тому или иному пути. Формат таблицы маршрутов задается используемым протоколом маршрутизации, а содержание - определяет администратор сети. Прямая маршрутизация имеет место при обмене пакетами между машинами, входящими в одну сеть. Большинство современных протоколов маршрутизации являются динамическими, то есть такими, где таблицы маршрутизации изменяются по мере изменения структуры и параметров окружающей сети. Такие протоколы заметно повышают надежность сети в целом, так как при выходе из строя какого-либо узла или канала связи поток пакетов может быть автоматически направлен в обход по резервному маршруту. При этом пользователи сети не должны ожидать момента, когда администратор сети вернется из отпуска, проснется или вернется из кафетерия и сам внесет необходимые коррективы. Автономной системой называют такую локальную сеть или систему сетей, которые имеют единую администрацию и общую маршрутную политику. Пользователь, связанный только с одним сервис-провайдером, должен принадлежать к общей с ним AS. Автономная система должна обязательно создаваться, когда оператор сети связан с более чем одной AS с отличной от его маршрутной политикой. Если же пользователь обращается к услугам двух или более сервис-провайдеров, придерживающихся различных маршрутных политик, то он должен создать свою независимую AS. Общим правилом является использование максимально возможного числа маршрутов. Это повышает надежность и способствует перераспределению нагрузки между каналами. Внедрение идеологии автономных систем сделали возможным существенно облегчить процедуру маршрутизации, сократить требуемое число IP-адресов и создать гибкую и эффективную схему описания маршрутной политики. |
|
Previous:
4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||
|
4.4.3 Протокол TCP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||
|
Протокол TCP (transmission control protocol, RFC-793, -1323) в отличии от udp осуществляет доставку дейтограмм, называемых сегментами, в виде байтовых потоков с установлением соединения. Протокол TCP применяется в тех случаях, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимости таймаутов и повторных передач для обеспечения надежности. Для отслеживания подтверждения доставки в TCP реализуется алгоритм "скользящего" окна. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (file transfer protocol - протокол передачи файлов) и telnet. Кроме того, TCP используют системы SMTP, HTTP, X-windows, RCP (remote copy), а также "r"-команды. Внутренняя структура модуля TCP гораздо сложнее структуры UDP. Подобно UDP прикладные процессы взаимодействуют с модулем TCP через порты (см. таблицу 4.4.2.1 в предыдущей главе). Под байтовыми потоками здесь подразумевается то, что один примитив, например, read или write (см. раздел "Программирование для сетей") может вызвать посылку адресату последовательности сегментов, которые образуют некоторый блок данных (сообщение). Примером прикладного процесса, использующего ветвь TCP, может служить FTP, при этом будет работать стек протоколов ftp/tcp/ip/ethernet. Хотя протоколы UDP и TCP могли бы для сходных задач использовать разные номера портов, обычно этого не происходит. Модули TCP и UDP выполняют функции мультиплексоров/демультиплексоров между прикладными процессами и IP-модулем. При поступлении пакета в модуль IP он будет передан в TCP- или UDP-модуль согласно коду, записанному в поле протокола данного IP-пакета. Формат сегмента (пакета) tcp представлен ниже на рис. 4.4.3.1. Если IP-протокол работает с адресами, то TCP, также как и UDP, с портами. Именно с номеров портов отправителя и получателя начинается заголовок TCP-сегмента. Поле код позиции в сообщении определяет порядковый номер первого октета в поле данных пользователя. При значении флага syn=1 в этом поле лежит код isn (смотри ниже описание процедуры установления связи). Поле HLEN - определяет длину заголовка сегмента, которая измеряется в 32-разрядных словах. Далее следует поле резерв, предназначенное для будущего использования, в настоящее время должно обнуляться. Поле размер окна сообщает, сколько октетов готов принять получатель (флаг ACK=1). Окно имеет принципиальное значение, оно определяет число сегментов, которые могут быть посланы без получения подтверждения. Значение ширины окна может варьироваться во время сессии (смотри описание процедуры "медленного старта"). Значение этого поля равное нулю также допустимо и указывает, что байты вплоть до указанного в поле номер октета, который должен прийти следующим, получены, но адресат временно не может принимать данные. Разрешение на посылку новой информации может быть дано с помощью посылки сегмента с тем же значением поля номер октета, который должен прийти следующим, но ненулевым значением поля ширины окна. Поле контрольная сумма предназначено для обеспечения целостности сообщения. Контрольное суммирование производится по модулю 1. Перед контрольным суммированием к TCP-сегменту добавляется псевдозаголовок, как и в случае протокола udp, который включает в себя адреса отправителя и получателя, код протокола и длину сегмента, исключая псевдозаголовок. Поле указатель важной информации представляет собой указатель последнего байта, содержащий информацию, которая требует немедленного реагирования. Поле имеет смысл лишь при флаге URG=1, отмечающем сегмент с первым байтом "важной информации". Значение разрядов в 6-битовом коде (флаги) описано в таблице 4.4.3.1. Если флаг ACK=0, значение поля номер октета, который должен прийти следующим, игнорируется. Флаг urg=1 в случае нажатия пользователем клавиш Del или Ctrl-c. Таблица 4.4.3.1 Значения бит поля флаги
Рис. 4.4.3.1 Формат TCP-сегмента Поле опции зарезервировано на будущее и в заголовке может отсутствовать, его размер переменен и дополняется до кратного 32-бит с помощью поля заполнитель. Формат поля опции представлен на рис. 4.4.3.2. В настоящее время определены опции: 0 Конец списка опций. В поле вид записывается код опции, поле LEN содержит число октетов в описании опции, включая поля вид и LEN. Определены также опции со значением вид=4,5,6,7. В предложении T/TCP (RFC-1644) описаны опции 11, 12 и 13.
Рис. 4.4.3.2. Формат опций для TCP-сегментов Поле данные в TCP-сегменте может и отсутствовать, характер и формат передаваемой информации задается исключительно прикладной программой, максимальный размер этого поля составляет в отсутствии опций 65495 байт. TCP является протоколом, который ориентируется на согласованную работу ЭВМ и программного обеспечения партнеров, участвующих в обмене информацией. Установление связи клиент-сервер осуществляется в три этапа:
Стандартная процедура установления связи представлена на рисунке 4.4.3.3 (под словом "стандартная" подразумевается отсутствие каких-либо отклонений от штатного режима, например, одновременного открывание соединения со стороны сервера и клиента). Если же соединение одновременно инициируется клиентом и сервером, в конечном итоге будет создан только один виртуальный канал.
Рис. 4.4.3.3. Алгоритм установления связи. В рамках представлены состояния клиента и сервера; пунктиром отмечены изменения cостояния после посылки сообщения (см. также рис. 4.4.3.4) Префикс S на рисунке указывает на сервер, а С - на клиента. Параметры в скобках обозначают относительные значения ISN. После установления соединения ISN(S) = s_seq_1, а ISN(C) = c_seq_1. Каждое соединение должно иметь свой неповторимый код ISN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (established, closed, listen, syn_sent, syn_received и т.д.; см. также RFC-793), переход между которыми строго регламентирован. Машина состояний для протокола TCP может быть описана диаграммой, представленной на рис. 4.4.3.4. Здесь состояние closed является начальной и конечной точкой последовательности переходов. Каждое соединение стартует из состояния closed. Из диаграммы машины состояний видно, что ни одному из состояний не поставлен в соответствие какой-либо таймер. Это означает, что машина состояний TCP может оставаться в любом из состояний сколь угодно долго. Исключение составляет keep-alive таймер, но его работа является опционной, а время по умолчанию составляет 2 часа. Это означает, что машина состояния может оставаться 2 часа без движения. В случае, когда две ЭВМ (C и S) попытаются установить связь друг с другом одновременно, реализуется режим simultaneous connection (RFC-793). Обе ЭВМ посылают друг другу сигналы SYN. При поучении этого сигнала партнеры посылают отклики SYN+ACK. Обе ЭВМ должны обнаружить, что SYN и SYN+ACK относятся к одному и тому же соединению. Когда C и S обнаружат, что SYN+ACK соответствует посланному ранее SYN, они выключат таймер установления соединения и перейдут непосредственно в состояние syn_recvd. В состоянии established пакет будет принят сервером, если его ISN лежит в пределах s_ack, s_ack+s_wind (s_wind - ширина окна для сервера; см. рис. 4.4.3.5). Аналогичный диапазон isn для клиента выглядит как: c_ack, c_ack+c_wind (c_wind - ширина окна для клиента). c_wind и s_wind могут быть не равны. Пакеты, для которых эти условия не выполняются, будут отброшены. Рассмотрим пример установления соединения для случая FTP-запроса (См. также http://www.cis.ohio-state.edu/~dolske/gradwork/cis694q). Пусть клиент С запускает процесс установления FTP-соединения с сервером s. Обычный порядок установления соединения показан ниже (см. рис. 4.4.3.3): c -> s:syn(isnc) isn - идентификатор пакета, посылаемого клиентом (С) или сервером (S). Клиент, послав syn серверу S, переходит в состояние syn_sent. При этом запускается таймер установления соединения. Как при установлении соединения так и при его разрыве приходится сталкиваться с проблемой двух армий. Представим себе, что имеется две армии А и Б, причем Б больше по численности чем А. Армия Б разделена на две части, размещенные по разные стороны от армии А. Если две части армии Б одновременно нападут на армию А, победа гарантирована. В то же время нападение на А одной из частей армии Б обрекает ее на поражение. Но как обеспечить одновременность? Здесь предполагается, что радио еще не изобретено и передача сообщений осуществляется вестовыми, которые в нашем случае могут быть перехвачены врагом. Как убедиться, что вестовой дошел? Первое, что приходит в голову, это послать другого вестового с подтверждением. Но он также с некоторой вероятностью может быть перехвачен. А отправитель не будет знать, дошел ли он. Ведь если сообщение перехвачено, отправитель первичного запроса не выдаст команды на начало, так как не уверен, дошло ли его первое сообщение. Возникает вопрос, существует ли алгоритм, который бы гарантировал надежность синхронизации решений путем обмена сообщениями при ненадежной доставке? Повысит ли достоверность увеличение числа обменов между партнерами? Ответом на этот вопрос будет - нет не существует. В этом читатель, порассуждав логически, может убедиться самостоятельно. Не трудно видеть, что схожие проблемы возникают в любом протоколе, работающем через установление соединения. Чаще всего эта проблема решается путем таймаутов и повторных попыток (это, слава богу, не война и все обходится без людских жертв). Сервер, получив SYN, откликается посылкой другого SYN. Когда С получает SYN от S (но не получает ACK, например, из-за его потери или злого умысла), он предполагает, что имеет место случай одновременного открытия соединения. В результате он посылает s syn_ack, отключает таймер установления соединения и переходит в состояние syn_received. Сервер получает syn_ack от C, но не посылает отклика. Тогда С ожидает получения syn_ack в состоянии syn_received. Так как время пребывания в этом состоянии не контролируется таймером, С может остаться в состоянии syn_received вечно. Из-за того, что переходы из состояния в состояние не всегда четко определены, протокол tcp допускает и другие виды атак (некоторые из них описаны в разделе "Сетевая безопасность"), там же рассмотрены алгоритмы задания и изменения ISN. Хотя TCP-соединение является полнодуплексным, при рассмотрении процесса разрыва связи проще его рассматривать как два полудуплексных канала, каждый из которых каналов ликвидируется независимо. Сначала инициатор разрыва посылает сегмент с флагом FIN, сообщая этим партнеру, что не намерен более что-либо передавать. Когда получение этого сегмента будет подтверждено (ACK), данное направление передачи считается ликвидированным. При этом передача информации в противоположном направлении может беспрепятственно продолжаться. Когда партнер закончит посылку данных, он также пошлет сегмент с флагом FIN. По получении отклика ACK виртуальный канал считается окончательно ликвидированным. Таким образом, для установление связи требуется обмен тремя сегментами, а для разрыва - четырьмя. Но протокол допускает совмещение первого ACK и второго FIN в одном сегменте, сокращая полное число закрывающих сегментов с четырех до трех. Машина состояний для протокола TCP не предусматривает изменения состояний при посылке или получении обычных пакетов, содержащих данные.
Когда оператор, работая в диалоговом режиме, нажимает командную клавишу, сегмент, в который помещается эта управляющая последовательность, помечается флагом PSH (push). Это говорит приемнику, что информация из этого сегмента должна быть передана прикладному процессу как можно скорее, не дожидаясь прихода еще какой-либо информации. Сходную функцию выполняет флаг URG. URG позволяет выделить целый массив данных, так как активизирует указатель последнего байта важной информации. Будет ли какая-либо реакция на эту "важную" информацию определяет прикладная программа получателя. urg-режим используется для прерываний при работе с FTP, telnet или rlogin. Если до завершения обработки "важной" информации придет еще один сегмент с флагом URG, значение старого указателя конца "важного" сообщения будет утеряно. Это обстоятельство должно учитываться прикладными процессами. Так telnet в командных последовательностях всегда помещает префиксный байт с кодом 255. В режиме удаленного терминала (telnet) при нажатии любой клавиши формируется и поcылается 41-октетный сегмент (здесь не учитываются издержки ethernet), который содержит всего один байт полезной информации. Эффективность работы может быть улучшена с помощью алгоритма Нагля (Nagle, 1984; RFC-896). Нагль предложил при однобайтовом обмене посылать первый байт, а последующие буферизовать до прихода подтверждения получения посланного. После этого посылаются все буферизованные октеты, а запись в буфер вводимых кодов возобновляется. Если оператор вводит символы быстро, а сеть работает медленно, этот алгоритм позволяет заметно понизить загрузку канала. Встречаются, впрочем, случаи, когда алгоритм Нагля желательно отключить, например, при работе в Интернет в режиме Х-терминала, где сигналы перемещения мышки должны пересылаться немедленно, чтобы не ввести в заблуждение пользователя относительно истинного положения маркера. Существует еще одна проблема при пересылке данных по каналам TCP, которая называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода проблема возникает в том случае, когда данные поступают отправителю крупными блоками, а интерактивное приложение адресата считывает информацию побайтно. Предположим, что в исходный момент времени буфер адресата полон и передающая сторона знает об этом (window=0). Интерактивное приложение считывает очередной октет из TCP-потока, при этом TCP-агент адресата поcылает уведомление отправителю, разрешающее ему послать один байт. Этот байт будет послан и снова заполнит до краев буфер получателя, что вызовет отправку ACK со значением window=0. Этот процесс может продолжаться сколь угодно долго, понижая коэффициент использования канала ниже паровозного уровня. Кларк предложил не посылать уведомление о ненулевом значении ширины окна при считывании одного байта, а лишь после освобождения достаточно большого пространства в буфере. Например, когда адресат готов принять MSS байтов или когда буфер наполовину пуст. Предполагается, что получатель пакета практически всегда посылает отправителю пакет-отклик. Отправитель может послать очередной пакет, не дожидаясь получения подтверждения для предшествующего. Таким образом, может быть послано k пакетов, прежде чем будет получен отклик на первый пакет (протокол "скользящего окна"). В протоколе tcp "скользящее окно" используется для регулировки трафика и препятствия переполнения буферов. Идея скользящего окна отображена на рис. 4.4.3.5. Здесь предполагается, что ширина окна равна 7 (k=7; это число может меняться в очень широких пределах).
Рис. 4.4.3.5. Схема использования скользящего окна После прихода отклика на пакет <1> окно смещается вправо на одну позицию. Теперь отправитель может послать и пакет <8>. Если порядок прихода откликов нарушается, сдвиг окна может задержаться. Размер окна в сегментах определяется соотношением: window > RTT*B/MSS, где B - полоса пропускания канала в бит/с, а MSS - максимальный размер сегмента в битах, а window - в сегментах. Для протокола TCP механизм скользящего окна может работать на уровне октетов или сегментов. В первом случае нужно учитывать каждый раз размер поля данных переданного и подтвержденного сегмента. В TCP-протоколе используется три указателя (стрелки на рис. 4.4.3.3б): Первый указатель определяет положение левого края окна, отделяя посланный сегмент, получивший подтверждение, от посланного сегмента, получение которого не подтверждено. Второй указатель отмечает правый край окна и указывает на сегмент, который может быть послан до получения очередного подтверждения. Третий указатель помечает границу внутри скользящего окна между уже посланными сегментами и теми, которые еще предстоит послать. Получатель организует аналогичные окна для обеспечения контроля потока данных. Если указатель 3 совпадет с указателем 2, отправитель должен прервать дальнейшее отправление пакетов до получения хотя бы одного подтверждения. Обычно получатель посылает одно подтверждение (ACK) на два полученных сегмента. Регулирование трафика в TCP подразумевает существование двух независимых процессов: контроль доставки, управляемый получателем с помощью параметра window, и контроль перегрузки, управляемый отправителем с помощью окна перегрузки cwnd (congestion window) и ssthreth (slow start threshold). Первый процесс отслеживает заполнение входного буфера получателя, второй - регистрирует перегрузку канала, а также связанные с этим потери и понижает уровень трафика. В исходный момент времени при установлении соединения cwnd делается равным одному MSS, а ssthreth=65535 байтам. Программа, управляющая пересылкой, никогда не пошлет больше байт, чем это задано cwnd и объявленным получателем значением window. Когда получение очередного блока данных подтверждено, значение cwnd увеличивается. Характер этого увеличения зависит от того, осуществляется медленный старт или реализуется процедура подавления перегрузки. Если cwnd меньше или равно ssthreth, выполняется медленный старт, в противном случае осуществляется подавление перегрузки. В последнем случае cwndi+1 = cwndi + MSS/8 +(MSS*MSS)/cwnd. Если возникает состояние перегрузки канала значение cwnd снова делается равным одному MSS. В качестве модуля приращения cwnd используется MSS. При получении подтверждения (ACK) окно перегрузки увеличивается на один сегмент ("медленный старт", CWNDi+1 = CWNDi + размер_сегмента, последнее слагаемое нужно, если размер окна задан в октетах, в противном случае вместо него следует использовать 1) и теперь отправитель может послать, не дожидаясь ACK, уже два сегмента и т.д.. Ширина окна, в конце концов, может стать настолько большой, что ошибка доставки в пределах окна станет заметной. Тогда будет запущена процедура "медленного старта" или другой алгоритм, который определит новое, уменьшенное значение окна. Окно перегрузки позволяет управлять информационным потоком со стороны отправителя, блокируя возможные перегрузки и потери данных в промежуточных узлах сети (о других методах подавления перегрузки канала смотри раздел "Сети передачи данных"). Если переполнения не происходит, CWND становится больше окна, объявленного получателем, и именно последнее будет ограничивать поток данных в канале. Размер окна, объявленный получателем, ограничивается произведением полосы пропускания канала (бит/с) на RTT (время распространения пакета туда и обратно). Максимально допустимый размер окна в TCP равен 65535 байт (задается размером поля). Конечной целью регулирования трафика является установление соответствия между темпом передачи и возможностями приема. Причиной перегрузки может быть не только ограниченность размера буфера, но и недостаточная пропускная способность какого-то участка канала. С учетом этого обстоятельства каждый отправитель формирует два окна: окно получателя и окно перегрузки (ширина этого окна равна cwnd). Каждое из этих окон задает число байтов, которое может послать отправитель. Реальное число байтов, которое разрешено послать, равно минимальному из этих окон. При инициализации соединения окно перегрузки имеет ширину равную максимальному сегменту, который может быть использован в данном канале. Отправитель посылает такой сегмент. Если будет прислано подтверждение до истечения времени таймаута, размер окна перегрузки удваивается и посылается два сегмента максимальной длины. При получении подтверждения доставки каждого из сегментов окно перегрузки увеличивается на один сегмент максимальной длины. Когда ширина окна перегрузки становится равной B сегментов и все B посланных сегментов получают подтверждение, окно перегрузки возрастает на число байт, содержащихся в этих сегментах. Таким образом, ширина окна перегрузки последовательно удваивается, пока доставка всех сегментов подтверждается. Рост ширины окна перегрузки при этом имеет экспоненциальный характер. Это продолжается до тех пор, пока не наступит таймаут или окно перегрузки не сравняется с окном получателя. Именно эта процедура и называется медленным стартом (Джекобсон, 1988). Как было сказано выше, помимо окон перегрузки и получателя в TCP используется третий параметр - порог (иногда он называется порогом медленного старта ssthresh). При установлении соединения ssthresh=64 Kбайт. В случае возникновения таймаута значение ssthresh делается равным CWND/2, а само значение CWND приравнивается MSS (см. рис. 4.4.3.6). Далее запускается процедура медленного старта, чтобы выяснить возможности канала. При этом экспоненциальный рост cwnd осуществляется вплоть до значения ssthresh. Когда этот уровень cwnd достигнут, дальнейший рост происходит линейно с приращением на каждом шагу равным MSS (рис. 4.4.3.6).
Рис. 4.4.3.6. Эволюция ширины окна при медленном старте Здесь предполагается, что MSS=1 Кбайт. Началу диаграммы соответствует установка значения ssthresh=16 Kбайт. Данная схема позволяет более точно выбрать значение cwnd. После таймаута, который на рисунке произошел при передаче c номером 12, значение порога понижается до 12 Кбайт (=cwnd/2). Ширина окна cwnd снова начинает расти от передачи к передаче, начиная с одного сегмента, вплоть до нового значения порога ssthresh=12 Кбайт. Стратегия с экспоненциальным и линейным участками изменения ширины окна переполнения позволяет несколько приблизить среднее его значение к оптимальному. Для локальных сетей, где значение RTT невелико, а вероятность потери пакета мала, оптимизация задания cwnd не так существенна, как в случае протяженных внешних (например, спутниковых) каналов. Ситуация может поменяться, если в локальной сети имеется фрагмент, где вероятность потерь пакетов велика. Таким фрагментом может быть МАС-бридж (или переключатель), один из каналов которого подключен к сегменту Fast Ethernet, а другой к обычному Ethernet на 10 Мбит/c. Если такой мост не снабжен системой подавления перегрузки (до сих пор такие приборы не имели подобных систем), то каждый из пакетов будет потерян в среднем 9 раз, прежде чем будет передан (здесь предполагается, что передача идет из сегмента FE). При этом cwnd будет практически все время равно MSS, что крайне неэффективно при передаче по каналам Интернет. Такие потери вызовут определенные ошибки при вычислении среднего значения и дисперсии RTT, а как следствие и величин таймаутов. Применение в таких местах маршрутизаторов или других приборов, способных реагировать на перегрузку посредством ICMP(4), решает эту проблему. Для взаимного согласования операций в рамках TCP-протокола используется четыре таймера:
Важным параметром, определяющим рабочие параметры таймеров, является RTT (время путешествия пакета до адресата и обратно). TCP-агент самостоятельно измеряет RTT. Такие измерения производятся периодически и по их результатам корректируется среднее значение RTT: RTTm = a*RTTm + (1-a)*RTTi , где RTTi - результат очередного измерения, RTTm - величина, полученная в результате усреднения предыдущих измерений, а - коэффициент сглаживания, обычно равный 0.9. RFC-793 рекомендует устанавливать время таймаута для ретрансмиссии (повторной передачи), значение RTO - Retransmission TimeOut равно RTO=RTTm*b, где b равно 2. От корректного выбора этих параметров зависит эффективная работа каналов. Так занижение времени ретрансмиссии приводит к неоправданным повторным посылкам сегментов, перегружая каналы связи. Для более точного выбора RTO необходимо знать дисперсию RTT. Несколько более корректную оценку RTO можно получить из следующих соотношений:
RTTm = RTTm + g(RTTi-RTTm) где D - среднее отклонение RTT от равновесного значения, а коэффициенты g = 0,125, D = 0,25. Чем больше g, тем быстрее растет RTO по отношению к RTT. Это хорошо работает до тех пор, пока не произойдет таймаут и ретрансмиссия. В этом случае, получив ACK, трудно решить, какому сегменту соответствует это подтверждение, первому или второму. На эту проблему впервые обратил внимание Фил Карн. Решением проблемы является приостановка коррекции RTTm при таймауте и ретрансмиссиях. Значение RTO зависит от пропускной способности канала и от специфических задержек, например в случае спутниковых каналов. В основном RTO лежит в секундном диапазоне (5-15 сек). Наиболее вероятная причина потери пакетов - это перегрузка канала на участках между отправителем и приемником. Указанием на то, что пакет потерян, может служить таймаут или получение дубликата сегмента ACK. Если произошел таймаут, система переходит в режим "медленного старта" (ширина окна перегрузки делается равной 1 сегменту, а значение порога медленного старта - ssthresh делается равным двум сегментам). При инициализации канала переменная ssthresh обычно равна 65535. Дублирование ACK индицирует потерю пакета до наступления таймаута. В этом случае сначала меняется алгоритм приращения величины окна перегрузки cwnd (замедляется темп его роста). После прихода очередного ACK новое значение cwnd вычисляется по формуле: cwndi+1 = cwndi + (размер_сегмента*размер_сегмента)/cwndi + размер_сегмента/8 Если же в этот момент величина окна перегрузки меньше или равна некоторому порогу (ssthresh - slow start threshold, обычно измеряется в байтах), осуществляется "медленный старт". Следует помнить, что TCP требует посылки немедленного подтверждения (дублированного ACK) при обнаружении прихода сегментов с нарушением порядка следования. Причиной нарушения порядка следования может быть флуктуация задержки в сети или потеря пакета. Если получено три или более задублированных ACK, это является убедительным указанием на потерю пакета и, не дожидаясь таймаута, осуществляется его повторная передача. Перехода в режим медленного старта в этом случае не производится, но понижаются значения cwnd и ssthresh (почти вдвое). Когда TCP-канал закрывается и за время сессии переслано более 16 полых окон, а адресат достижим не через маршрут по умолчанию, то в таблицу маршрутизации заносится следующая информация: усредненное значение RTT, значение дисперсии RTT и ssthresh. Если в ходе TCP-сессии получено сообщение ICMP(4) (переполнение канала - quench), требующее снижения потока данных, то cwdn делается равным одному сегменту, а величина порога медленного старта ssthresh не изменяется. На ICMP-сообщения о недостижимости сети или ЭВМ программы TCP-уровня не реагируют вообще. Нулевой размер окна блокирует посылку информации и этим система время от времени пользуется. Что произойдет, если получатель послал сегмент, объявляющий окно ненулевым, а подтверждение получения этого сегмента не прошло? TCP-протокол не предусматривает посылки ACK на само подтверждение. Адресат ждет в этом случае данных, так как он уже объявил о существовании ненулевого окна с помощью соответствующего ACK, а отправитель ждет этого недошедшего ACK, чтобы начать передачу данных. Для разрешения этой тупиковой ситуации используется таймер запросов, который периодически посылает зондирующие сегменты получателю. Цель этого зондирования - выяснение существования окна ненулевой ширины. Таймер запросов запускается при получении информации об обнулении ширины окна приемником. Если за определенное время не поступает сегмента, сообщающего об изменении размера окна, таймер начинает посылать зондирующие сегменты. Таймер запросов использует базовую временную шкалу с периодом в 500 мсек, а период посылки зондирующих сегментов лежит в диапазоне 5-60 сек. Такой сегмент содержит только один байт данных. Таймер запросов не прерывает своей работы до тех пор, пока не будет подтверждено открытие окна или пока прикладная задача не завершит свою работу, выключив канал связи. Будучи однажды создан, канал TCP может существовать "вечно". Если клиент и сервер пассивны, они не заметят того, например, что какой-то бульдозер оборвал кабель или спутник связи покоится на дне океана. Чтобы это обнаружить, либо клиент либо сервер должны попытаться послать какую-то информацию. Чтобы информировать систему об этих и подобных им жизненных неурядицах, предусмотрен таймер контроля работоспособности (keepalive). Многим читателям, возможно, приходилось легкомысленно выключать питание своего персонального компьютера, не позаботившись о корректном logout из процедуры telnet или FTP. Если бы не существовало этого таймера, включив ЭВМ, вы бы обнаружили, что "находитесь" в заморском депозитарии, где были вчера. Но таймер контроля работоспособности может и прервать сессию, если какой-то промежуточный маршрутизатор произвел перезагрузку или был вынужден поменять маршрут. Принцип работы таймера работоспособности предельно прост. Если канал пассивен, например, 2 часа, сервер посылает клиенту сегмент-зонд. При этом ЭВМ-клиент может быть в одном из четырех состояний.
Временная постоянная таймера keepalive является системной переменной единой для всех пользователей ЭВМ или даже локальной сети. Расширение пропускной способности и надежности телекоммуникационных каналов делает актуальной совершенствование протоколов. Так как TCP является основным транспортным протоколом, попытки усовершенствовать его предпринимаются, начиная с 1992 года (RFC-1323, Якобсон, Браден и Борман). Целью этих усовершенствований служит повышение эффективности и пропускной способности канала, а также обеспечение безопасности. При этом рассматриваются следующие возможности:
Оптимальный выбор MTU позволяет минимизировать или исключить фрагментацию (и последующую сборку) сегментов. Верхняя граница на MTU налагается значением MSS (максимальный размер сегмента). Разумно находить и запоминать оптимальные значения MTU для каждого конкретного маршрута. Так как в современных системах используются динамические протоколы маршрутизации, поиск оптимального MTU рекомендуется повторять каждые 10 мин (RFC-1191). Как уже отмечалось, размер TCP-окна определяется произведением полосы канала (в бит/с) на RTT в сек. Для Ethernet c полосой 10 Мбит/с и RTT=3 мсек это произведение равно 3750 байт, а для канала ИТЭФ-ДЕЗИ с пропускной способностью 1,5 Мбит/с и RTT=710 мсек (спутник) - 88750 байт, а это отнюдь не предел современной телекоммуникационной технологии. Но уже эти примеры говорят о том, что максимально возможный размер окна должен быть увеличен в раз 10-100 уже сегодня. Протокол же разрешает 65535 байт. Появление столь мощных каналов порождает и другие проблемы - потеря пакетов в них обходится слишком дорого, так как "медленный старт" и другие связанные с этим издержки сильно снижают пропускную способность. В последнее время алгоритм медленного старта заменяется более эффективными алгоритмами. Простое увеличение ширины окна до тех пор, пока не произойдет сбой, плохая стратегия при использовании традиционного медленного старта, так как заметную часть времени ширина окна будет неоптимальной - то слишком большой, то слишком малой. Оптимальная стратегия должна включать в себя прогнозирование оптимальной ширины окна. В новых версиях модулей TCP реализуются именно такие алгоритмы. В 1994 году Бракмо предложил вариант стратегии изменения параметров передачи, который на 40-70% повышает пропускную способность TCP-канала. Существуют и другие, могущие показаться забавными проблемы. Каждый сегмент в TCP-протоколе снабжается 32-битным идентификатором. Время жизни IP-пакета (TTL) определяется по максимуму 255 шагами или 255 секундами в зависимости оттого, что раньше наступит. Трудно предсказуемая ситуация может произойти, когда канал ликвидирован, затем создан снова (для той же комбинации IP-адресов и портов), а какой-то пакет из предшествующей сессии, погуляв по Интернет, придет уже во время следующей. Есть ли гарантия, что он будет верно идентифицирован? Одной из мер, упомянутых ранее, можно считать использование ограничения по максимальному времени жизни сегмента (MSL) или TTL, хотя снижение значения TTL не всегда возможно - ведь IP-пакетами пользуется не только TCP-протокол и нужна очень гибкая система задания его величины. Во многих приложениях MSL=30 сек (рекомендуемое значение 2 мин слишком велико). Технический прогресс ставит и некоторые новые проблемы. Высокопроизводительные каналы (1 Гбит/с) уже сегодня могут исчерпать разнообразие идентификационных кодов пакетов за один сеанс связи. Появление же двух пакетов с равными идентификаторами может породить неразрешимые трудности. Для передачи мегабайтного файла по гигабитному каналу требуется около 40 мсек (при этом предполагается, что задержка в канале составляет 32 мсек (RTT=64 мсек)). Собственно передача этой информации занимает 8 мсек. Из этих цифр видно, что традиционные протоколы, размеры окон и пр. могут свести на нет преимущества скоростного (дорогостоящего) канала. Пропускная способность такого канала определяется уже не его полосой, а задержкой. Понятно также, что необходимо расширить поле размера окна с 16 до 32 бит. Чтобы не изменять формат TCP-сегментов, можно сделать код размера окна в программе 32-разрядным, сохранив соответствующее поле в сегменте неизменным. Размер окна в этом случае задается как бы в формате с плавающей запятой. При установлении канала определяется масштабный коэффициент n (порядок) лежащий в интервале 0-14. Передача этого коэффициента (один байт) осуществляется сегментом SYN в поле опций. В результате размер окна оказывается равным 65535*2n. Если один из партнеров послал ненулевой масштабный коэффициент, но не получил такого коэффициента от своего партнера по каналу, то n считается равным нулю. Эта схема позволит сосуществовать старым и новым системам. Выбор n возлагается на TCP-модуль системы. Для того чтобы точнее отслеживать вариации RTT, предлагается помещать временные метки в каждый посылаемый сегмент. Так как в TCP используется одно подтверждение ACK на несколько сегментов, правильнее будет сказать, что RTT измеряется при посылке каждого ACK. Способность и готовность партнеров работать в таком режиме временных меток определяется на фазе установления канала. Более точное вычисление RTT позволяет не только корректно выбрать временные постоянные для таймеров, правильно вычислить задержку TIME_WAIT (TIME_WAIT=8*RTO), но и отфильтровать "старые" сегменты. Идеология временных меток используется и в алгоритме PAWS (Protection Against Wrapped Sequence Numbers) для защиты против перепутывания номеров сегментов. Предлагаемое усовершенствование TCP - T/TCP модифицирует алгоритмы выполнения операций. T/TCP вводит новую 32-битную системную переменную - число соединений (CC). СС позволяет сократить число пересылаемых сегментов при установлении канала, а также отфильтровывать "старые" сегменты, не принадлежащие данной сессии (установленной связи). Время отклика клиента в рамках указанных алгоритмов сокращается до суммы RTT и времени обработки запроса процессором. Данные пришедшие до SYN-сегмента должны буферизоваться для последующей обработки, а не отбрасываться. Ethernet (10 Мбит/c) в идеальных условиях позволяет осуществить обмен в рамках протокола TCP (например, при FTP-сессии) со скоростью 1,18 Мбайт/с. Как уже отмечалось, максимальная длина сегмента (MSS - Maximum Segment Size) в TCP-обменах величина переменная. Длина сегмента определяет длину кадра, в который он вложен. Для локальных Ethernet-сетей MSS=1460 октетов. Чем длиннее кадр, тем выше пропускная способность сети (меньше накладные расходы на заголовок кадра). С другой стороны, при передаче дейтограмм по внешним каналам, где размер пакета не столь велик, большое значение MSS приведет к фрагментации пакетов, которая замедлит обмен, поэтому администратор сети должен взвешивать последствия, задавая значения размера сегментов. Если MSS явно не задан, устанавливается значение по умолчанию (536 байт), что соответствует 576-байтной IP-дейтограмме. Для нелокальных адресов - это, как правило, разумный выбор. Ликвидация связи требует посылки четырех сегментов. TCP-протокол допускает возможность, когда один из концов канала объявляет о прекращении посылки данных (посылает FIN-сегмент), продолжая их получать (режим частичного закрытия - half-close). Посылка сегмента FIN означает выполнение операции active close. Получатель FIN-сегмента должен послать подтверждение его получения. Когда противоположный конец, получивший FIN, закончит пересылку данных, он пошлет свой FIN-сегмент. Прием подтверждения на получение этого сегмента означает закрытие данного канала связи. Возможно прерывание связи и с помощью посылки RST-сегмента. В этом случае все буферы и очереди очищаются немедленно и часть информации будет потеряна. |
||||||||||||||
|
Previous:
4.4.2 Протокол UDP
UP:
4.4 Интернет
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол передачи команд и сообщений об ошибках (ICMP - internet control message protocol, RFC-792, - 1256) выполняет многие и не только диагностические функции, хотя у рядового пользователя именно этот протокол вызывает раздражение, сообщая об его ошибках или сбоях в сети. Именно этот протокол используется программным обеспечением ЭВМ при взаимодействии друг с другом в рамках идеологии TCP/IP. Осуществление повторной передачи пакета, если предшествующая попытка была неудачной, лежит на TCP или прикладной программе. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице будет восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтограммах, но не дает информации об ошибках в самих ICMP-сообщениях. icmp использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтограмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP-протокол осуществляет:
ICMP-сообщения об ошибках никогда не выдаются в ответ на:
Эти правила призваны блокировать потоки дейтограмм, посылаемым в отклик на мультикастинг или широковещательные ICMP-сообщения. ICMP-сообщения имеют свой формат, а схема их вложения аналогична UDP или TCP и представлена на рис. 4.4.4.1.
Рис. 4.4.4.1. Схема вложения ICMP-пакетов в Ethernet-кадр Все ICMP пакеты начинаются с 8-битного поля типа ICMP и его кода (15 значений). Код уточняет функцию ICMP-сообщения. Таблица этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные - являются запросами): Таблица 4.4.4.1. Типы и коды ICMP-сообщений.
Процедура "отключение источника" (quench, поле тип ICMP=4) позволяет управлять потоками данных в каналах Интернет. Не справляясь с обработкой дейтограмм, ЭВМ-адресат может послать запрос "отключить источник" отправителю, который может сократить темп посылки пакетов или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на рис. 4.4.4.2) представлен формат эхо-запроса (ping) и отклика для протокола ICMP.
Рис. 4.4.4.2. Формат эхо-запроса и отклика ICMP
Поля идентификатор и номер по порядку служат для того, чтобы отправитель мог связать в пары запросы и отклики. Поле тип определяет, является ли этот пакет запросом (8) или откликом (0). Поле контрольная сумма представляет собой 16-разрядное дополнение по модулю 1 контрольной суммы всего ICMP-сообщения, начиная с поля тип. Поле данные служит для записи информации, возвращаемой отправителю. При выполнении процедуры ping эхо-запрос с временной меткой в поле данные посылается адресату. Если адресат активен, он принимает IP-пакет, меняет адрес отправителя и получателя местами и посылает его обратно. ЭВМ-отправитель, восприняв этот отклик, может сравнить временную метку, записанную им в пакет, с текущим показанием внутренних часов и определить время распространения пакета (RTT - round trip time). Размер поля данные не регламентирован и определяется предельным размером IP-пакета. Время распространения ICMP-запроса, вообще говоря, не равно времени распространения отклика. Это связано не только с возможными изменениями в канале. В общем случае маршруты их движения могут быть различными. Когда маршрутизатор не может доставить дейтограмму по месту назначения, он посылает отправителю сообщение "адресат не достижим" (destination unreachable). Формат такого сообщения показан ниже (на рис. 4.4.4.3).
Рис. 4.4.4.3. Формат ICMP-сообщения "адресат не достижим" Поле код содержит целое число, проясняющее положение дел. Перечень кодов таких сообщений помещена в таблице 4.4.4.1. Поле MTU на следующем этапе характеризует максимальную длину пакетов на очередном шаге пересылки. Так как в сообщении содержится Интернет-заголовок и первые 64-бита дейтограммы, легко понять, какой адрес оказался недостижим. Этот тип ICMP-сообщения посылается и в случае, когда дейтограмма имеет флаг DF=1 ("не фрагментировать"), а фрагментация необходима. В поле код в этом случае будет записано число 4. Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4 для каждого из не записанных в буфер сообщений. Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP, среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP (network time protocol) описан в RFC-1119. Когда дейтограммы поступают слишком часто и принимающая сторона не справляется с этим потоком, отправителю может быть послано сообщение с требованием резко сократить информационный поток (quench-запрос), снижение потока должно продолжаться до тех пор, пока не прекратятся quench-запросы. Такое сообщение имеет формат:
Рис. 4.4.4.4. Формат icmp-запроса снижения загрузки В Internet таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда таблицы все же меняются. Если маршрутизатор обнаружит, что ЭВМ использует неоптимальный маршрут, он может послать ей ICMP-запрос переадресации. Формат такого сообщения отображен на рисунке 4.4.4.5.
Рис. 4.4.4.5. Формат ICMP-запроса переадресации Поле Internet-адрес маршрутизатора содержит адрес маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтограмма достигла места назначения, указанного в ее заголовке. В поле internet-заголовок кроме самого заголовка лежит 64 первых бита дейтограммы, вызвавшей это сообщение. Поле код специфицирует то, как нужно интерпретировать адрес места назначения (см. табл. 4.4.4.1). Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс, через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP-запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу. Маршрутная таблица может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор посылает широковещательный запрос. Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450-600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP-сообщений такого рода (см. рис. 4.4.4.6).
Рис. 4.4.4.6. Формат ICMP-сообщений об имеющихся маршрутах Поле число адресов характеризует количество адресных записей в сообщении. Поле длина адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по отношению к другим маршрутам данной подсети. Чем больше этот код тем выше приоритет. Маршрут по умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов, рис. 4.4.4.7).
Рис. 4.4.4.7 Формат запроса маршрутной информации Так как следующий прогон (hop) дейтограммы определяется на основании локальной маршрутной таблицы, ошибки в последней могут привести к зацикливанию пакетов. Для подавления таких циркуляций используется контроль по времени жизни пакета (TTL). При ликвидации пакета по истечении TTL маршрутизатор посылает отправителю сообщение "время истекло", которое имеет формат (рис. 4.4.4.8):
Рис. 4.4.4.8. Формат сообщения "время (ttl) истекло" Значение поля код определяет природу тайм-аута (см. табл. 4.4.4.1). Когда маршрутизатор или ЭВМ выявили какую-либо ошибку, не из числа описанных выше (например, нелегальный заголовок дейтограммы), посылается сообщение "конфликт параметров". Это может произойти при неверных параметрах опций. При этом посылается сообщение вида (рис. 4.4.4.9):
Рис. 4.4.4.9. Формат сообщения типа "конфликт параметров" Поле указатель отмечает октет дейтограммы, который создал проблему. Код=1 используется для сообщения о том, что отсутствует требуемая опция (например, опция безопасности при конфиденциальных обменах), поле указатель при значении поля код=1 не используется. В процессе трассировки маршрутов возникает проблема синхронизации работы часов в различных ЭВМ. К счастью синхронизация внутренних часов ЭВМ требуется не так часто (например, при выполнении синхронных измерений), негативную роль здесь могут играть задержки в каналах связи. Для запроса временной метки другой ЭВМ используется сообщение запрос временной метки, которое вызывает отклик с форматом (рис. 4.4.4.10):
Рис. 4.4.4.10. Формат ICMP-запроса временной метки Поле тип=13 указывает на то, что это запрос, а тип=14 - на то, что это отклик. Поле идентификатор и номер по порядку используются отправителем для связи запроса и отклика. Поле исходная временная метка заполняется отправителем непосредственно перед отправкой пакета. Поле временная метка на входе заполняется маршрутизатором при получении этого пакета, а Временная метка на выходе - непосредственно перед его отправкой. Именно этот формат используется в процедурах ping и traceroute. Эти процедуры позволяют не только диагностировать, но и оптимизировать маршруты. Например, команда traceroute cernvm.cern.ch, выданная в ЭВМ SUN (ИТЭФ), может отобразить на экране (в скобках указаны IP-адреса узлов и значения времени жизни дейтограмм, значения RTT приводится в миллисекундах):
Отсюда видно, что наиболее узкими участками маршрута являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург является спутниковым и 500мс задержки здесь вносит время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) является общим также и для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP, как для локальной сети, так и для "окрестного" Интернет. При работе с субсетью важно знать маску этой субсети. Как уже отмечалось выше, IP-адрес содержит секцию адреса ЭВМ и секцию адреса сети. Для получения маски субсети ЭВМ может послать "запрос маски" в маршрутизатор и получить отклик, содержащий эту маску. ЭВМ может это сделать непосредственно, если ей известен адрес маршрутизатора, либо прибегнув к широковещательному запросу. Ниже описан формат таких запросов-откликов (рис. 4.4.4.11).
Рис. 4.4.4.11. Формат запроса (отклика) маски субсети Поле тип здесь специфицирует модификацию сообщения, тип=17 - это запрос, а тип=18 - отклик. Поля идентификатор и номер по порядку, как обычно, обеспечивают взаимную привязку запроса и отклика, а поле адресная маска содержит 32-разрядную маску сети. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.3 Протокол TCP
UP:
4.4 Интернет
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.11.2 Протокол OSPF (алгоритм Дикстры)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол OSPF (Open Shortest Pass First, RFC-1245-48, RFC-1583-1587, алгоритмы предложены Дикстрой) является альтернативой RIP в качестве внутреннего протокола маршрутизации. OSPF представляет собой протокол состояния маршрута (в качестве метрики используется - коэффициент качества обслуживания). Каждый маршрутизатор обладает полной информацией о состоянии всех интерфейсов всех маршрутизаторов (переключателей) автономной системы. Протокол OSPF реализован в демоне маршрутизации gated, который поддерживает также RIP и внешний протокол маршрутизации BGP. Автономная система может быть разделена на несколько областей, куда могут входить как отдельные ЭВМ, так и целые сети. В этом случае внутренние маршрутизаторы области могут и не иметь информации о топологии остальной части AS. Сеть обычно имеет выделенный (designated) маршрутизатор, который является источником маршрутной информации для остальных маршрутизаторов AS. Каждый маршрутизатор самостоятельно решает задачу оптимизации маршрутов. Если к месту назначения ведут два или более эквивалентных маршрута, информационный поток будет поделен между ними поровну. Переходные процессы в OSPF завершаются быстрее, чем в RIP. В процессе выбора оптимального маршрута анализируется ориентированный граф сети. Ниже описан алгоритм Дикстры по выбору оптимального пути. На иллюстративном рис. 4.2.11.2.1 приведена схема узлов (A-J) со значениями метрики для каждого из отрезков пути. Анализ графа начинается с узла A (Старт). Пути с наименьшим суммарным значением метрики считаются наилучшими. Именно они оказываются выбранными в результате рассмотрения графа ("кратчайшие пути").
Рис. 4.2.11.2.1 Иллюстрация работы алгоритма Дикстры Ниже дается формальное описание алгоритма. Сначала вводим некоторые определения. Пусть D(v) равно сумме весов связей для данного пути. Далее следует последовательность шагов, реализующих алгоритм.
Топология маршрутов для узла a приведена на нижней части рис. 4.2.11.2.1. В скобках записаны числа, характеризующие метрику отобранного маршрута согласно критерию пункта 3. Таблица 4.2.11.2.1. Реализация алгоритма
Таблица 4.2.11.2.1 может иметь совершенно иное содержимое для какого-то другого вида сервиса, выбранные пути при этом могут иметь другую топологию. Качество сервиса (QoS) может характеризоваться следующими параметрами:
Определяющими являются три характеристики: задержка, пропускная способность и надежность. Для транспортных целей OSPF использует IP непосредственно, т.е. не привлекает протоколы UDP или TCP. OSPF имеет свой код (89) в протокольном поле IP-заголовка. Код TOS (type of service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение TOS здесь задается в самих пакетах OSPF. Маршрутизация в этом протоколе определяется IP-адресом и типом сервиса. Так как протокол не требует инкапсуляции пакетов, сильно облегчается управление сетями с большим количеством бриджей и сложной топологией (исключается циркуляция пакетов, сокращается транзитный трафик). Автономная система может быть поделена на отдельные области, каждая из которых становится объектом маршрутизации, а внутренняя структура снаружи не видна (узлы на рис. 4.2.11.2.1 могут представлять собой как отдельные ЭВМ или маршрутизаторы, так и целые сети). Этот прием позволяет значительно сократить необходимый объем маршрутной базы данных. В OSPF используется термин опорной сети (backbone) для коммуникаций между выделенными областями. Протокол работает лишь в пределах автономной системы. В пределах выделенной области может работать свой протокол маршрутизации.
Рис. 4.2.11.2.2 Пример выделения областей при ospf маршрутизации в автономной системе (М - маршрутизаторы; c - сети). На рис 4.2.11.2.2 (см. также рис. 4.2.11.2.1) приведен пример выделения областей маршрутизации при ospf-маршрутизации в пределах автономной системы. На рис. 4.2.11.2.2 маршрутизаторы М4 и М2 выполняют функция опорной сети для других областей. В выделенных областях может быть любое число маршрутизаторов. Более толстыми линиями выделены связи с другими автономными системами. При передаче OSPF-пакетов фрагментация не желательна, но не запрещается. Для передачи статусной информации OSPF использует широковещательные сообщения Hello. Для повышения безопасности предусмотрена авторизация процедур. OSPF-протокол требует резервирования двух мультикастинг-адресов:
Любое сообщение ospf начинается с 24-октетного заголовка:
Рис. 4.2.11.2.3 Формат заголовка сообщений для протокола маршрутизации ospf Поле версия определяет версию протокола (= 2). Поле тип идентифицирует функцию сообщения согласно таблице 4.2.11.2.2: Таблица 4.2.11.2.2. Коды поля тип
Поле длина пакета определяет длину блока в октетах, включая заголовок. Идентификатор области - 32-битный код, идентифицирующий область, которой данный пакет принадлежит. Все ospf-пакеты ассоциируются с той или иной областью. Большинство из них не преодолевает более одного шага. Пакеты, путешествующие по виртуальным каналам, помечаются идентификатором опорной области (backbone) 0.0.0.0. Поле контрольная сумма содержит контрольную сумму IP-пакета, включая поле типа идентификации. Контрольное суммирование производится по модулю 1. Поле тип идентификации может принимать значения 0 при отсутствии контроля доступа, и 1 при наличии контроля. В дальнейшем функции поля будут расширены. Важную функцию в OSPF-сообщениях выполняет одно-октетное поле опции, оно присутствует в сообщениях типа Hello, объявление состояния канала и описание базы данных. Особую роль в этом поле играют младшие биты e и Т:
Бит E характеризует возможность внешней маршрутизации и имеет значение только в сообщениях типа Hello, в остальных сообщениях этот бит должен быть обнулен. Если E=0, то данный маршрутизатор не будет посылать или принимать маршрутную информацию от внешних автономных систем. Бит T определяет сервисные возможности маршрутизатора (TOS). Если T=0, это означает, что маршрутизатор поддерживает только один вид услуг (TOS=0) и он не пригоден для маршрутизации с учетом вида услуг. Такие маршрутизаторы, как правило, не используются для транзитного трафика. Протокол ospf использует сообщение типа Hello для взаимообмена данными между соседними маршрутизаторами. Структура пакетов этого типа показана на рис. 4.2.11.2.4.
Рис. 4.2.11.2.4 Формат сообщения Hello в протоколе OSPF Поле сетевая маска соответствует маске субсети данного интерфейса. Например, если интерфейс принадлежит сети класса B и третий байт служит для выделения нужной субсети, то сетевая маска будет иметь вид 0xFFFFFF00. Поле время между Hello содержит значение времени в секундах, между сообщениями Hello. Поле опции характеризует возможности, которые предоставляет данный маршрутизатор. Поле приоритет характеризует уровень приоритета маршрутизатора (целое положительное число), используется при выборе резервного (backup) маршрутизатора. Если приоритет равен нулю, данный маршрутизатор никогда не будет использован в качестве резервного. Поле время отключения маршрутизатора определяет временной интервал в секундах, по истечении которого "молчащий" маршрутизатор считается вышедшим из строя. IP-адреса маршрутизаторов, записанные в последующих полях, указывают место, куда следует послать данное сообщение. Поля IP-адрес соседа k образуют список адресов соседних маршрутизаторов, откуда за последнее время были получены сообщения Hello. Маршрутизаторы обмениваются сообщениями из баз данных OSPF, чтобы инициализировать, а в дальнейшем актуализовать свои базы данных, характеризующие топологию сети. Обмен происходит в режиме клиент-сервер. Клиент подтверждает получение каждого сообщения. Формат пересылки записей из базы данных представлен на рис. 4.2.11.2.5.
Рис. 4.2.11.2.5 Формат OSPF-сообщений о маршрутах Поля, начиная с тип канала, повторяются для каждого описания канала. Так как размер базы данных может быть велик, ее содержимое может пересылаться по частям. Для реализации этого используются биты I и М. Бит I устанавливается в 1 в стартовом сообщении, а бит M принимает единичное состояние для сообщения, которые являются продолжением. Бит S определяет то, кем послано сообщение (S=1 для сервера, S=0 для клиента, этот бит иногда имеет имя MS). Поле номер сообщения по порядку служит для контроля пропущенных блоков. Первое сообщение содержит в этом поле случайное целое число M, последующие M+1, M+2,...M+L. Поле тип канала может принимать следующие значения: Таблица 4.2.11.2.3. Коды типов состояния каналов (LS)
Поле идентификатор канала определяет его характер, в зависимости от этого идентификатором может быть IP-адрес маршрутизатора или сети. Маршрутизатор, рекламирующий канал определяет адрес этого маршрутизатора. Поле порядковый номер канала позволяет маршрутизатору контролировать порядок прихода сообщений и их потерю. Поле возраст канала определяет время в секундах с момента установления связи. После обмена сообщениями с соседями маршрутизатор может выяснить, что часть данных в его базе устарела. Он может послать своим соседям запрос с целью получения свежей маршрутной информации о каком-то конкретном канале связи. Сосед, получивший запрос, высылает необходимую информацию. Запрос посылается в соответствии с форматом, показанном ниже (рис. 4.2.11.2.6):
Рис. 4.2.11.2.6 Формат ospf-запроса маршрутной информации Три поля этого запроса повторяются согласно числу каналов, информация о которых запрашивается. Если список достаточно длинен, может потребоваться несколько запросов. Маршрутизаторы посылают широковещательные (или мультикастинговые) сообщения об изменении состояния своих непосредственных связей. Такое сообщение содержит список объявлений, имеющих формат (рис. 4.2.11.2.7):
Рис. 4.2.11.2.7 Сообщение об изменении маршрутов Сообщения об изменениях маршрутов могут быть вызваны следующими причинами: 1. Возраст маршрута достиг предельного значения (lsrefreshtime). Каждое сообщение о состоянии канала начинается с заголовка - "объявление состояния канала" (LS- link state). Формат этого типа заголовка приведен ниже (20 октетов):
Рис. 4.2.11.2.8 Формат ospf-сообщения, описывающего состояние канала Поле возраст ls информации (рис. 4.2.11.2.8) определяет время в секундах с момента объявления состояния канала. Поле опции содержит значения типов сервиса (TOS), поддерживаемые маршрутизатором, рассылающим маршрутную информацию. Поле тип LS (тип состояния канала) может принимать значения, описанные выше в табл. 4.2.11.2.3. Следует обратить внимание, что код, содержащийся в этом поле, определяет формат сообщения. Поле длина задает размер сообщения в октетах, включая заголовок. В результате получается сообщение с форматом, показанным на рис. 4.2.11.2.9. Зарезервированный октет должен быть обнулен. Идентификатор связи определяет тип маршрутизатора, подключенного к каналу. Действительное значение этого поля зависит от поля тип. В свою очередь информация о канале также зависит от поля тип. Число tos определяет многообразие метрик, соответствующих видам сервиса, для данного канала. Последовательность описания метрик задается величиной кода TOS. Таблица кодов TOS, принятых в OSPF протоколе приведена ниже. Таблица 4.2.11.2.4. Коды типа сервиса (TOS)
Рис. 4.2.11.2.9 Формат описания типа канала с LS=1 Если бит V=1 (virtual), маршрутизатор является оконечной точкой активного виртуального канала. Если бит E (external) равен 1, маршрутизатор является пограничным для автономной системы. Бит B=1 (border) указывает на то, что маршрутизатор является пограничным для данной области. Поле тип может принимать значения, приведенные в таблице 4.2.11.2.5. Таблица 4.2.11.2.5. Коды типов связей (см. рис. 4.2.11.2.9)
Поле идентификатор канала характеризует объект, с которым связывается маршрутизатор. Примеры идентификаторов представлены в таблице: Таблица 4.2.11.2.6. Коды идентификаторов канала
Маршрутизатор, получивший OSPF-пакет, посылает подтверждение его приема. Этот вид пакетов имеет тип=5 и структуру, отображенную на рис. 4.2.11.2.10. Получение нескольких объявлений о состоянии линий может быть подтверждено одним пакетом. Адресом места назначения этого пакета может быть индивидуальный маршрутизатор, группа маршрутизаторов или все маршрутизаторы автономной системы.
Рис. 4.2.11.2.10 Формат сообщения о получении OSPF-пакета Рекламирование сетевых связей относится к типу 2. Сообщения посылаются для каждой транзитной сети в автономной системе. Транзитной считается сеть, которая имеет более одного маршрутизатора. Сообщение о сетевых связях должно содержать информацию обо всех маршрутизаторах, подключенных к сети, включая тот, который рассылает эту информацию. Расстояние от сети до любого подключенного маршрутизатора равно нулю для всех видов сервиса (TOS), поэтому поля TOS и метрики в этих сообщениях отсутствуют. Формат сообщения о транзитных сетевых связях показан на рис. 4.2.11.2.11. Следует помнить, что приведенные ниже сообщения должны быть снабжены стандартными 24-октетными OSPF-заголовками (на рис. 4.2.11.2.11 отсутствует).
Рис. 4.2.11.2.11 Формат сообщения о сетевых связях (тип LS=2) Сетевая маска относится к описываемой сети, а поле подключенный маршрутизатор содержит идентификатор маршрутизатора, работающего в сети. Информация об адресатах в пределах автономной системы передается LS-сообщениями типа 3 и 4. Тип 3 работает для IP-сетей. В этом случае в качестве идентификатора состояния канала используется IP-адрес сети. Если же адресатом является пограничный маршрутизатор данной AS, то используется LS-сообщение типа 4, а в поле идентификатор состояния канала записывается OSPF-идентификатор этого маршрутизатора. Во всех остальных отношениях сообщения 3 и 4 имеют идентичные форматы (рис. 4.2.11.2.12):
Рис. 4.2.11.2.12 Формат сообщений об адресатах в пределах автономной системы Поля, следующие после заголовка, повторяются в соответствии с числом описываемых объектов. Рекламирование внешних маршрутов относится к пятому типу. Эта информация рассылается пограничными маршрутизаторами. Информация о каждом внешнем адресате, известном маршрутизатору, посылается независимо. Этот вид описания используется и для маршрутов по умолчанию, для которых идентификатор состояния канала устанавливается равным 0.0.0.0 (аналогичное значение принимает при этом и сетевая маска). Формат такого сообщения представлен на рис. 4.2.11.2.13.
Рис. 4.2.11.2.13 Формат описания внешних маршрутов Сетевая маска характеризует место назначения рекламируемого маршрута. Так для сети класса A маска может иметь вид 0xFF000000. Последующий набор полей повторяется для каждого вида TOS. Поля для TOS=0 заполняются всегда, и это описание является первым. Бит E характеризует внешнюю метрику. Если E=0, то она может непосредственно (без преобразования) сравниваться с метриками других каналов. При E=1 метрика считается больше любой метрики. Поле адрес пересылки указывает на место, куда будут пересылаться данные, адресованные рекламируемым маршрутом. Если адрес пересылки равен 0.0.0.0, данные посылаются пограничному маршрутизатору автономной системы - источнику данного сообщения. Метка внешнего маршрута - 32-битовое число, присваиваемое каждому внешнему маршруту. Эта метка самим протоколом OSPF не используется и предназначена для информирования других автономных систем при работе внешних протоколов маршрутизации. Маршрутная таблица OSPF содержит в себе:
Преимущества OSPF:
Недостатки:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.11.1 Внутренний протокол маршрутизации RIP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.11.3 Протокол IGRP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол IGRP разработан фирмой CISCO для своих многопротокольных маршрутизаторов в середине 80-х годов. Хотя этот протокол и не является стандартным, я счел возможным включить его описание, так как маршрутизаторы этой фирмы относятся к наиболее массовым. IGRP представляет собой протокол, который позволяет большому числу маршрутизаторов координировать свою работу. Основные достоинства протокола (описание протокола взято из депозитария FTP.CISCO.COM/pub/igrp.doc).
Сегодняшняя реализация протокола ориентирована на TCP/IP. Однако, базовая конструкция системы позволяет использовать IGRP и с другими протоколами. IGRP имеет некоторое сходство со старыми протоколами, например с RIP и Hello. Здесь маршрутизатор обменивается маршрутной информацией только с непосредственными соседями. Поэтому задача маршрутизации решается всей совокупностью маршрутизаторов, а не каждым отдельно. Для того чтобы исключить осцилляции маршрутов, протокол IGRP должен игнорировать новую информацию в течение нескольких минут после ее возникновения. OSPF-протокол вынужден использовать большую избыточность информации по сравнению с IGRP, как на уровне базы маршрутных данных, так и в процессе обмена с внешней средой. IGRP используется в маршрутизаторах, которые имеют связи с несколькими сетями и выполняют функции переключателей пакетов. Когда какой-то объект в одной сети хочет послать пакет в другую сеть, он должен послать его соответствующему маршрутизатору. Если адресат находится в одной из сетей, непосредственно связанной с маршрутизатором, он отправляет этот пакет по месту назначения. Если же адресат находится в более отдаленной сети, маршрутизатор перешлет пакет другому маршрутизатору, расположенному ближе к адресату. Здесь также как и в других протоколах для хранения маршрутных данных используются специализированные базы данных. Протокол IGRP формирует эту базу данных на основе информации, которую он получит от соседних маршрутизаторов. В простейшем случае находится один путь для каждой из сетей. Сегменты пути характеризуются используемым сетевым интерфейсом, метрикой и маршрутизатором, куда следует сначала послать пакет. Метрика - то число, которое говорит о том, насколько хорош данный маршрут. Это число позволяет сравнить его с другими маршрутами, ведущими к тому же месту назначения и обеспечивающим тот же уровень QOS. Предусматривается возможность (как и в OSPF) разделять информационный поток между несколькими доступными эквивалентными маршрутами. Пользователь может сам разделить поток данных, если два или более пути оказались почти равными по метрике, при этом большая часть трафика будет послана по пути с лучшей метрикой. Метрика, используемая в IGRP, учитывает:
Время задержки предполагается равным времени, необходимому для достижения места назначения при нулевой загрузке сети. Дополнительные задержки, связанные с загрузкой учитываются отдельно. Среди параметров, которые контролируются, но не учитываются метрикой, находятся число шагов до цели и MTU (maximum transfer unit - размер пакета пересылаемого без фрагментации). Расчет метрики производится для каждого сегмента пути. Время от времени каждый маршрутизатор широковещательно рассылает свою маршрутную информацию всем соседним маршрутизаторам. Получатель сравнивает эти данные с уже имеющимися и вносит, если требуется, необходимые коррекции. На основании вновь полученной информации могут быть приняты решения об изменении маршрутов. Эта процедура типична для многих маршрутизаторов и этот алгоритм носит имя Белмана-Форда. (см. также описание протокола RIP, RFC-1058). Наилучший путь выбирается с использованием комбинированной метрики, вычисленной по формуле: [(K1 / Be) + (K2 * Dc)] r [1], где: K1, K2 = константы; Be= пропускная способность канала (в отсутствии загрузки) * (1 - загрузка канала); r = относительная надежность. (% пакетов, успешно передаваемых по данному сегменту пути). Здесь загрузка измеряется как доля от 1. Путь, имеющий наименьшую комбинированную метрику, считается лучшим. В такой схеме появляется возможность, используя весовые коэффициенты, адаптировать выбор маршрутов к задачам конечного пользователя. Одним из преимуществ igrp является простота реконфигурации. В igrp маршрут по умолчанию не назначается, а выбирается из числа кандидатов. Когда маршрутизатор включается, его маршрутные таблицы инициализируются оператором вручную или с использованием специальных файлов. На рис. 4.4.11.3.1 маршрутизатор S связан через соответствующие интерфейсы с сетями 2 и 3.
Рис. 4.4.11.3.1 Таким образом, в исходный момент маршрутизатор S знает только о доступности сетей 2 и 3. За счет обмена информацией, полученной при инициализации и присланной позднее соседями, маршрутизаторы познают окружающий мир. Так S спустя некоторое время получит информацию от маршрутизатора R о доступности сети 1 и от T - о сети 4. В свою очередь S проинформирует T о доступе к сети 1. Очень быстро информация о доступности дойдет до всех маршрутизаторов и разрозненные сети станут единым целым. Для пояснения выбора маршрута в условиях многовариантности рассмотрим схему на рис. 4.4.11.3.2.
Рис. 4.4.11.3.2. Пример с альтернативными маршрутами Пусть каждый из маршрутизаторов уже вычислил комбинированную метрику для системы, изображенной на рис. 4.4.11.3.2. Для места назначения в сети 6 маршрутизатор A вычислит метрику для двух путей, через маршрутизаторы B и C. В действительности существует три маршрута из a в сеть 6: - непосредственно в B Маршрутизатору A не нужно выбирать между двумя маршрутами через C. Маршрутная таблица в A содержит только одну запись, соответствующую пути к C. Если маршрутизатор A посылает пакет маршрутизатору C, то именно C решает, использовать далее путь через маршрутизаторы B или D. Для каждого типа канала используется свое стандартное значение комбинированной задержки. Ниже приведен пример того, как может выглядеть маршрутная таблица в маршрутизаторе A для сети, изображенной на рис. 4.4.11.3.3.
Рис. 4.4.11.3.3. Пример маршрутной таблицы Для того чтобы обеспечить работу с большими и сложными сетями, в IGRP введены три усовершенствования алгоритма Белмана-Форда:
Значения вариации, отличное от единицы, позволяет использовать одновременно два или более путей с разной пропускной способностью. При дальнейшем увеличении вариации можно разрешить не только более "медленные" сегменты пути, но и ведущие в обратном направлении, что приведет с неизбежностью к "бесконечному" циклическому движению пакетов. Протокол маршрутизации IGRP предназначен для работы с несколькими типами сервиса (TOS) и несколькими протоколами. Под типами сервиса в TCP/IP подразумевается оптимизация маршрутизации по пропускной способности, задержке, надежности и т.д. Для решения этой задачи можно использовать весовые коэффициента K1 и K2 (формула [1] данного раздела). При этом для каждого TOS подготавливается своя маршрутная таблица. Среди мер, обеспечивающих cтабильность топологии связей, следует отметить следующее правило, которое поясняется на приведенном ниже примере.
Маршрутизатор A сообщает B о маршруте к сети 1. Когда же B посылает сообщения об изменении маршрутов в A, он ни при каких обстоятельствах не должен упоминать сеть 1. Т.е. сообщения об изменении маршрута, направленные какому-то маршрутизатору, не должны содержать данных об объектах, непосредственно с ним связанных. Сообщения об изменении маршрутов должны содержать: - адреса сетей, с которыми маршрутизатор связан непосредственно; Следует еще раз обратить ваше внимание, что в IGRP не используется измерение задержек, измеряется только надежность и коэффициент загрузки канала. Надежность определяется на основе сообщений интерфейсов о числе ошибок. Существует 4 временные константы, управляющие процессом распространения маршрутной информации (эти константы определяются оператором сети): - период широковещательных сообщений об изменении маршрутов (это время по умолчанию равно 90 сек); - время существования - если за это время не поступило никаких сообщений о данном маршруте, он считается нерабочим. Это время в несколько раз больше периода сообщений об изменениях (по умолчанию в 3 раза). - время удержания - когда какой-то адресат становится недостижим, он переходит в режим выдержки. В этом режиме никакие новые маршруты, ведущие к нему, не воспринимаются. Длительность этого режима и называется временем удержания. Обычно это время в три раза дольше периода сообщений об изменениях маршрутов. - время удаления - если в течение данного времени не поступило сообщений о доступе к данному адресату, производится удаление записи о нем из маршрутной базы данных (по умолчанию это время в 7 раз больше периода сообщений об изменениях маршрутов). IGRP-сообщение вкладывается в IP-пакет, это сообщение имеет следующие поля: version номер версии протокола 4 байта
opcode код операции Opcode - код операции определяет тип сообщения и может принимать значения: 1 - изменение; 2 - запрос Edition - (издание) является серийным номером, который увеличивается при каждом изменении маршрутной таблицы. Это позволяет маршрутизатору игнорировать информацию, которая уже содержится в его базе данных. Asystem - номер автономной системы. Согласно нормам Сisco маршрутизатор может входить в более чем одну автономную систему. В каждой AS работает свой протокол и они могут иметь совершенно независимые таблицы маршрутизации. Хотя в IGRP допускается "утечка" маршрутной информации из одной автономной системы в другую, но это определяется не протоколом, а администратором. Ninterior, nsystem, и nexterior определяют числа записей в каждой из трех секций сообщения об изменениях. Checksum - контрольная сумма заголовка и маршрутной информации, для вычисления которой используется тот же алгоритм, что и в UDP, TCP и ICMP. IGRP запрос требует от адресата прислать свою маршрутную таблицу. Сообщение содержит только заголовок. Используются поля version, opcode и asystem, остальные поля обнуляются. IP-пакет, содержащий сообщение об изменении маршрутов, имеет 1500 байт (включая IP-заголовок). Для описанной выше схемы это позволяет включить в пакет до 104 записей. Если требуется больше записей, посылается несколько пакетов. Фрагментация пакетов не применяется. Ниже приведено описание структуры для маршрута:
Субполе описание маршрута Number определяет IP-адрес места назначения, для экономии места здесь используется только 3 его байта. Если поле задержки содержит только единицы, место назначения недостижимо. Пропускная способность измеряется в величинах, обратных бит/сек, умноженных на 1010. (Т.е., если пропускная способность равна N Кбит/с, то ее измерением в IGRP будет 10000000/N.). Надежность измеряется в долях от 255 (т.е. 255 соответствует 100%). Загрузка измеряется также в долях от 255, а задержка в десятках миллисекунд. Ниже приведены значения по умолчанию для величин задержки и пропускной способности
Комбинированная метрика в действительности вычисляется по следующей формуле (для версии Cisco 8.0(3)): Метрика = [K1*пропускная_способность + (K2*пропускная_способность)/(256 - загрузка) + K3*задержка] * [K5/(надежность + K4)]. Если K5 == 0, член надежности отбрасывается. По умолчанию в IGRP K1 == K3 == 1, K2 == K4 == K5 == 0, а загрузка лежит в интервале от 1 до 255. В начале 90-х годов разработана новая версия протокола IGRP - EIGRP с улучшенным алгоритмом оптимизации маршрутов, сокращенным временем установления и масками субсетей переменной длины. EIGRP поддерживает многие протоколы сетевого уровня. Рассылка маршрутной информации здесь производится лишь при измении маршрутной ситуации. Протокол периодически рассылает соседним маршрутизаторам короткие сообщения Hello. Получение отклика означает, что сосед функционален и можно осуществлять обмен маршрутной информацией. Протокол EIGRP использует таблицы соседей (адрес и интерфейс), топологические таблицы (адрес места назначения и список соседей, объявляющих о доступности этого адреса), состояния и метки маршрутов. Для каждого протокольного модуля создается своя таблица соседей. Протоколом используется сообщения типа hello (мультикастная адресация), подтверждени (acknowledgent), актуализация (update), запрос (query; всегда мультикастный) и отклик (reply; посылается отправителю запроса). Маршруты здесь делятся на внутренние и внешние - полученные от других протоколов или записанные в статических таблицах. Маршруты помечаются идентификаторами их начала. Внешние маршруты помечаются следующей информацией:
Протокол EIGRP полностью совместим с IGRP, он обеспечивает работу в сетях IP, Apple Talk и Novell. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.11.2 Протокол OSPF (алгоритм Дикстры)
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.11.4 Внешний протокол BGP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4; -1265-66, 1655) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае - это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, рис. 4.4.11.4.1). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.
Рис. 4.4.11.4.1. Формат BGP-сообщений об изменениях маршрутов Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении open равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:
После того как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано - это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме заголовка сообщение open содержит следующие поля (рис. 4.4.11.4.2):
Рис. 4.4.11.4.2 Формат сообщения open Поле версия описывает код версии используемого протокола, на сегодня для BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS отправителя. Поле время сохранения характеризует время в секундах, которое отправитель предлагает занести в таймер сохранения. После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее из полученного в сообщении open и значения, определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то согласно правилам должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах. Одно-октетный код идентификации позволяет организовать систему доступа, если он равен нулю, маркер всех сообщений заполняется единицами, а поле идентификационных данных должно иметь нулевую длину. При неравном нулю коде идентификации должна быть определена процедура доступа и алгоритм вычисления кодов поля маркера. Длина поля идентификационных данных определяется по формуле: Длина сообщения = 29 + длина поля идентификационных данных. Сообщения типа UPDATE (изменения) используются для передачи маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет сообщить об одном новом маршруте или объявить о закрытии группы маршрутов, причем объявление об открытии нового и закрытии старых маршрутов возможно в пределах одного сообщения. Сообщение UPDATE всегда содержит стандартный заголовок и может содержать другие поля в соответствии со схемой:
Рис. 4.4.11.4.3 Формат update-сообщения Если длина списка отмененных маршрутов равна нулю, ни один маршрут не отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные маршруты имеет переменную длину и содержит список IP-адресных префиксов маршрутов, которые стали недоступны. Каждая такая запись имеет формат:
Длина префикса (в битах), равная нулю означает, что префикс соответствует всем IP-адресам, а сам имеет нулевой размер. Поле префикс содержит IP-адресные префиксы, за которыми следуют разряды, дополняющие их до полного числа октетов. Значения этих двоичных разрядов смысла не имеют. Нулевое значение полной длины списка атрибутов пути говорит о том, что информация о доступности сетевого уровня в UPDATE-сообщении отсутствует. Список атрибутов пути присутствует в любом UPDATE-сообщении. Этот список имеет переменную длину, а каждый атрибут содержит три составные части: тип атрибута, длину атрибута и значение атрибута. Тип атрибута представляет собой двух-октетное поле со структурой:
Старший бит (бит0) поля флаги атрибута определяет, является ли атрибут опционным (бит0=1) или стандартным (well-known, бит0=0). Бит 1 этого поля определяет, является ли атрибут переходным (бит1=1) или непереходным (бит1=0). Для обычных атрибутов этот бит должен быть равен 1. Третий бит (бит 2) поля Флагов атрибута определяет, является ли информация в опционном переходном атрибуте полной (бит2=0) или частичной (бит2=1). Для обычных и для опционных непереходных атрибутов этот бит должен быть равен нулю. Бит 3 поля флагов атрибута информирует о том, имеет ли длина атрибута один (бит3=0) октет или два октета (бит3=1). Бит3 может быть равен 1 только в случае, когда длина атрибута более 255 октетов. Младшие 4 бита октета флагов атрибута не используются (и должны обнуляться). Если бит3=0, то третий октет атрибута пути содержит длину поля данных атрибута в октетах. Если же бит3=1, то третий и четвертый октеты атрибута пути хранят длину поля данных атрибута. Остальные октеты поля атрибут пути характеризуют значение атрибута и интерпретируются согласно флагам атрибута. Атрибуты пути бывают "стандартные обязательные" (well-known mandatory), "стандартные на усмотрение оператора", "опционные переходные" и "опционные непереходные". Стандартные атрибуты должны распознаваться любыми BGP-приложениями. Опционные атрибуты могут не распознаваться некоторыми приложениями. Обработка нераспознанных атрибутов задается битом 1 поля флагов. Пути с нераспознанными переходными опционными атрибутами должны восприниматься, как рабочие. Один и тот же атрибут может появляться в списке атрибутов пути только один раз. Предусмотрены следующие разновидности кодов типа атрибута: ORIGIN (код типа = 1) - стандартный обязательный атрибут, который определяет происхождение путевой информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения:
AS_PATH (код типа = 2) также является стандартным обязательным атрибутом, который составлен из совокупности сегментов пути. Атрибут определяет автономные системы, через которые доставлена маршрутная информация. Когда BGP-маршрутизатор передает описание маршрута, которое он получил от своего BGP-партнера, он модифицирует AS_PATH-атрибут, соответствующий этому маршруту, если информация передается за пределы автономной системы. Каждый сегмент AS_PATH состоит из трех частей <тип сегмента пути, длина сегмента пути и оценка сегмента пути>. Тип сегмента пути представляет в свою очередь однооктетное поле, которое может принимать следующие значения:
Длина сегмента пути представляет собой одно-октетное поле, содержащее число as, записанных в поле оценка сегмента пути. Последнее поле хранит один или более кодов автономной системы, по два октета каждый. NEXT_HOP (код типа = 3) - стандартный обязательный атрибут, определяющий IP-адрес пограничного маршрутизатора, который должен рассматриваться как цель следующего шага на пути к точке назначения. MULTI_EXIT_DISC (код типа = 4) представляет собой опционный непереходной атрибут, который занимает 4 октета и является положительным целым числом. Величина этого атрибута может использоваться при выборе одного из нескольких путей к соседней автономной системе. LOCAL_PREF (код типа = 5) является опционным атрибутом, занимающим 4 октета. Он используется BGP-маршрутизатором, чтобы сообщить своим BGP-партнерам в своей собственной автономной системе степень предпочтения объявленного маршрута. ATOMIC_AGGREGATE (код типа = 6) представляет собой стандартный атрибут, который используется для информирования партнеров о выборе маршрута, обеспечивающего доступ к более широкому списку адресов. aggregator (код типа = 7) - опционный переходной атрибут с длиной в 6 октетов. Атрибут содержит последний код автономной системы, который определяет агрегатный маршрут (занимает два октета), и IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4 октета). Объем информации о достижимости сетевого уровня равен (в октетах): Длина сообщения UPDATE - 23 - полная длина атрибутов пути - длина списка отмененных маршрутов. Информация о достижимости кодируется в следующей форме:
Поле длина определяет длину IP-адресного префикса в битах. Если длина равна нулю, префикс соответствует всем IP-адресам. Префикс содержит IP-адресные префиксы и двоичные разряды, дополняющие код до целого числа октетов. Информация о работоспособности соседних маршрутизаторов получается из KEEPALIVE-сообщений, которые должны посылаться настолько часто, чтобы уложиться во время, отведенное таймером сохранения (hold). Обычно это время не должно превышать одной трети от времени сохранения, но не должно быть и меньше 1 секунды. Если выбранное значение времени сохранения равно нулю, периодическая посылка KEEPALIVE-сообщений не обязательна. NOTIFICATION-сообщения посылаются, когда обнаружена ошибка. BGP-связь при этом немедленно прерывается. Помимо заголовка NOTIFICATION-сообщение имеет следующие поля:
Код ошибки представляет собой одно-октетное поле и указывает на тип данного сообщения. Возможны следующие коды ошибки: Таблица 4.4.11.4.1. Коды ошибок
При отсутствии фатальной ошибки BGP-партнер может в любой момент прервать связь, послав NOTIFICATION-сообщение с кодом ошибки прерывание. Одно-октетное поле cубкод ошибки предоставляет дополнительную информацию об ошибке. Каждый код ошибки может иметь один или более субкодов. Если поле содержит нуль, это означает, что никаких субкодов не определено. Таблица 4.4.11.4.2 Субкоды ошибок
Вся маршрутная информация хранится в специальной базе данных RIB (routing information base). Маршрутная база данных BGP состоит из трех частей:
Так как разные BGP-партнеры могут иметь разную политику маршрутизации, возможны осцилляции маршрутов. Для исключения этого необходимо выполнять следующее правило: если используемый маршрут объявлен не рабочим (в процессе корректировки получено сообщение с соответствующим атрибутом), до переключения на новый маршрут необходимо ретранслировать сообщение о недоступности старого всем соседним узлам. Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS (см. раздел "Автономные системы и маршрутная политика"). Политика отражается в конфигурационных файлах BGP. Маршрутная политика это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями, политика отражает соображения безопасности, экономические интересы и пр. Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов. BGP использует три таймера: BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации. В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая BGP, не обязательно является маршрутизатором. Сообщения обрабатываются только после того, как они полностью получены. BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не тоже самое что "Keepalive" функция в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Такая ситуация называется столкновением, одна из связей должна быть ликвидирована. При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4), если один из них не поддерживает эту версию, номер версии понижается. Протокол BGP-4 является усовершенствованной версией (по сравнению с BGP-3). Эта версия позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Концепция классов сетей и субсети находятся вне рамок этой версии. Для того чтобы приспособиться к этому, изменена семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICSпереименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы:
Бесклассовая интердоменная маршрутизация (CIDR- classless interdomain routing, RFC-1520, -1519) - способ избежать того, чтобы каждая С-сеть требовала свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466). Протокол совместим с RIP-2, OSPF и BGP-4. Основу протокола составляет идея бесклассовых адресов, где нет деления между полем сети и полем ЭВМ. Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети. Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 - 192.1.255.255, таким образом, число, следующее после косой черты, задает количество двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов (см. разд.4.4.11.4 - "Маршрутная политика"). Для приведенных примеров это в терминах масок выглядит следующим образом:
24 и 17 длины префикса сети. Следует помнить, что маски с разрывами здесь недопустимы. Ниже приведена таблица метрик маршрутизации для различных протоколов.
Колонка "маршрут недостижим" содержит коды метрики, которые говорят о недоступности маршрута. Обычно предполагается, что если послан пакет из точки <А> в точку <B>, то маршруты их в одном и другом направлении совпадают. Но это не всегда так. Пример, когда маршруты пакетов "туда" и "обратно" не совпадают, представлен на рис. 4.4.11.4.4. В предложенной схеме имеется две ЭВМ "Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора "GW-2" и "GW-1".
Рис. 4.4.11.4.4. Пример разных маршрутов для пути "туда" и "обратно". Предполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:
Команда же traceroute 192.148.165.80 распечатает:
Команда traceroute -g 192.148.165.80 сообщит вам:
Из приведенных примеров видна также полезность команды traceroute для понимания того, как движутся пакеты в сети. В некоторых случаях это может помочь оптимизировать маршрутизацию и улучшить пропускную способность сети. Другой полезной командой является Netstat, которая позволяет получить разнообразную информацию о состоянии сети. Существует четыре модификации этой команды: -a отображает состояния всех соединений; Например, команда netstat -r может выдать: Routing tables (таблицы маршрутизации)
Здесь приведен только фрагмент маршрутной таблицы. Колонка destination указывает на конечную точку маршрута (default - маршрут по умолчанию), колонка gateway - имена маршрутизаторов, через которые достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Базовая команда netstat может обеспечить следующую информацию: Active Internet connections (активные Интернет связи)
Active UNIX domain sockets (активные UNIX-соединители домена)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.11.3 Протокол IGRP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Вряд ли отцы-создатели Интернет предполагали, что когда-либо, тем более при их жизни возникнет дефицит IP-адресов. Уже в 1996 году было зарегистрировано более 100000 сетей. Разбивка сетей на три класса A, B и С уже не может отвечать современным требованиям. Сеть класса А с ее 16000000 адресов слишком велика, а класса С с 254 адресами, как правило, слишком мала. Сети класса B с 65536 машинами может показаться оптимальными, но на практике каждая из этих сетей не обеспечивает оптимального использования адресного пространства и всегда остаются неиспользованные адреса (для классов B и A количество пустующих адресов оказывается обычно значительным). Адресные блоки заказываются администраторами, которые полагают, что однажды их организация или фирма станет великой с тысячами ЭВМ (пока же у них есть всего несколько машин). Надо сказать, что такие оптимистические прогнозы сбываются крайне редко. Проблема маршрутизации может быть решена путем реализации более глубокой структурной иерархии, где каждый IP-адрес имеет код страны, региона, города, сети, но при этом размер адреса должен существенно превышать 32 разряда, так как адреса неизбежно будут использоваться крайне не эффективно - ведь Китаю и Монако будут выделены равные адресные зоны. Это может стать возможным при внедрении технологии IPv6. Если бы в адресах класса С для кода номера ЭВМ было выделено 10 или 11 бит (1024-2048), ситуация была бы более приемлемой. Маршрутизатор рассматривает IP-адресную среду на двух уровнях - адрес сети и адрес ЭВМ, при этом практически они работают только с адресами сетей. Число записей в маршрутной таблице должно будет быть равным половине миллиона записей (по числу блоков С-адресов). Проблема может быть решена, если забыть про разбиение всей совокупности IP-адресов на классы. Такая модель реализуется в рамках протокола CIDR (Classless InterDomain Routing). В этой модели каждой сети ставится в соответствие определенное число смежных блоков по 256 адресов. Далее используется известное географическое зонное распределение IP-адресов (см. Ethernet в Интернет, а также RFC-1519). Протокол при просмотре маршрутных таблиц предполагает применение специальных масок и индексных механизмов. |
|
Previous:
4.4.11.4 Внешний протокол BGP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
|
4.4.11.7 Маршрутная политика
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Содержанием политики маршрутизации являются правила обмена маршрутной информацией между автономными системами (RIPE-181.txt). Не следует путать "маршрутную политику" и просто "политику", между ними такое же различие, как между "милостивым государем" и "государем". Способы их описания разнятся столь же значительно. При описании обычной политики одной из главных задач является сокрытие истинных намерений, а одним из средств - многословие. При описании же маршрутной политики важна лаконичность и четкость. В Интернет для решения этой задачи выработан стандарт, краткое изложение которого на конкретных примерах будет приведено ниже. Объектами маршрутной политики являются автономные системы (AUT-NUM) и маршруты (route). Существует два акта маршрутной политики: оповещение (announce) и Эти акты определяют взаимодействие с ближайшими соседями. Совокупность информации, выданной всеми маршрутизаторами региональной сети, описывает ее граф. Следует иметь в виду, что в пределах автономной системы (AS) может работать только один внутренний протокол маршрутизации (IGP), а обмен маршрутной информацией между автономными системами происходит в соответствии с внешним протоколом маршрутизации (EGP). Эта идея продемонстрирована на рис. 4.4.11.4.1. ЭВМ (или узлы) A1,B1,C1,D1 и маршрутизатор G-1 составляют одну автономную систему, а A2,B2,C2,D2,E2 и маршрутизатор G-2 - вторую.
Рис. 4.4.11.4.1. Схема связи автономных систем Пусть имеются две автономные системы ASX и ASY, обменивающиеся маршрутной информацией. ASX знает, как можно достичь сети Net1, которая может и не принадлежать ASX. Аналогично ASY знает, как послать пакет для сети Net2. net1 .... ASX <----> ASY ...... Net2 Для того чтобы пакеты попали из Net1 в Net2 через ASX и ASY, автономная система ASX должна анонсировать сеть Net1 автономной системе ASY, используя один из внешних протоколов маршрутизации (EGP или BGP), а ASY должна воспринять эту информацию и использовать. Предметом маршрутной политики в этом случае является решение ASX послать маршрутную информацию ASY, а также решение ASY эту информацию принять и использовать. Не существует никаких правил, которые бы вынуждали ASX и ASY к принятию таких решений. Таким образом, протокол маршрутизации определяет формат маршрутной информации, способ ее пересылки и хранения, но решения о ее посылке той или иной AS, а также решение об использовании маршрутной информации, поступающей извне остаются в руках администратора AS. Так как все существующие протоколы маршрутизации используют при работе с пакетами только адрес места назначения, разделить поток пакетов кроме как по этому параметру не возможно. Если пакеты с одним и тем же адресом места назначения попали в общий маршрутизатор, AS или канал связи, они обречены далее двигаться вместе. Особый случай составляет топология, при которой две as имеют много возможных маршрутов связи с различными политиками маршрутизации.
Рис. 4.4.11.4.2 Под каналом в данном случае подразумевается любая среда коммуникации - Ethernet, FDDI и т.д.. Может так случиться, что AS2 предпочитает использовать канал 2 только для обмена с AS4. А канал 1 используется для связи с AS3 и в качестве резервного маршрута (back-up) к AS4 в случае выхода из строя канала 2. Для описания маршрутной политики используются атрибуты interas-in и interas-out. Эти атрибуты позволяют описать локальные решения AS, основанные на ее предпочтениях, так как это делается в протоколах BGP-4 или IGRP. Пример такого описания представлен ниже:
aut-num: AS2 - (номер автономной системы, формат: as-in: from AS3 10 accept AS3 AS4 (описание воспринимаемой маршрутной информации от других AS-партнеров. Формат описания: from Маршрутная политика (<выражение маршрутной политики>) может иметь следующие форматы.
Приоритеты операторов распределены в следующем порядке: для оператора () слева направо; для NOT - справа на лево; для AND и OR - слева направо. В отсутствии логических операторов элементы списка (AS, AS-макро, объединения и списки маршрутов) предполагаются объединенными оператором OR. as-out: to AS3 announce AS1 AS2 (описание сформированной маршрутной информации, рассылаемой другим AS-партнерам). Формат описания: to interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref= 5) accept AS3 interas-in: описывает локальные предпочтения для соединений с другими AS. Это описание имеет формат: from Ключевые слова from (от) и accept (воспринимает) могут отсутствовать. Предпочтение описывается, как <стоимость> - положительное число, служащее выражением относительной ценности исследуемых маршрутов. Чем меньше <стоимость> - тем предпочтительнее маршрут. <стоимость> имеет смысл при сравнении атрибутов interas-in и совершенно не применима для сравнения с атрибутами as-in. Любой маршрут, описанный в interas-in и неупомянутый в AS-IN, предполагается отвергнутым. Система диагностики выдаст при этом сигнал ошибки. Атрибуты interas-out сходны с interas-in, также как as-out и as-in. Если мы рассмотрим соответствующие атрибуты interas-out для AS3, то увидим следующее: aut-num: AS3 Оператор interas-out: имеет формат: to aut-num> <местный-rid> <соседний-rid> [<метрика>] Ключевые слова IN и announce могут и отсутствовать. Остальные фрагменты оператора идентичны описанным выше. <метрика> является необязательным параметром и описывается как: (
Атрибут as-exclude отмечает список транзитных AS, маршруты через которые должны быть исключены из рассмотрения. Формат использования: exclude
Атрибут default указывает на маршрут по умолчанию. Формат атрибута:
где aut-num: AS786 Здесь присутствует as-macro с именем AS-EBONE, описание которого может выглядеть как: as-macro: AS-EBONE (имя AS-макро) В результате описание маршрутной политики будет выглядеть как: aut-num: AS786 Community - это группа маршрутов, которые не могут быть представлены одной AS или группой AS. Это может быть полезно при описании доступа к супер-ЭВМ, это может быть группа маршрутов, используемых для специальных целей, возможно объединение в группу для получения сетевой статистики. Такие группы не обмениваются маршрутной информацией. Группа Community может использоваться в качестве объекта маршрутной политики автономных систем. Примерами объектов типа community могут служить HEPNET (объединение сетей для физики высоких энергий), NSFNET (Национальная Научная сеть США), опорная московская оптоволоконная сеть. Существует еще несколько атрибутов, которые помогают получить вспомогательную информацию. Более детальное описание форматов и алгоритмов решения проблем реализации различных политик маршрутизации читатель может найти в ссылке в начале раздела. |
|
Previous:
4.4.11.6 Автономные системы
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.12 DNS (структура, обработка запросов, ресурсные записи)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Главной ЭВМ любой системы является та, на которой работаете вы. Но помимо этой машины и маршрутизатора локальной сети не последнюю роль играет сервер имен (DNS-система, RFC-2137, -2052, -2136, -1996, -1918, -1793, -1712-13, -1706, -1664, -1611-12, -1536-37, -1401, -1383, -1183, -1101, -1034-35). Сервер имен это программа управления распределенной базой данных, в которой хранятся символьные имена сетей и ЭВМ вместе с их IP-адресами. Наиболее распространенным программным продуктом, решающим данную задачу является BIND (Berkrley Internet Name Domain). Иногда для этой цели выделяют специальную машину. Задача DNS - преобразование символьного имени в IP-адрес и наоборот в условиях, когда число узлов Internet растет экспоненциально, совсем не проста. Сама иерархическая система имен (DNS) настроена на упрощение решения этой проблемы. Схема взаимодействия программы пользователя с локальным и удаленными DNS-серверами показана ниже на рисунке 4.4.12.1.
Рис. 4.4.12.1. Структура взаимодействия с серверами имен База имен является распределенной, так как нет такой ЭВМ, где бы хранилась вся эта информация. Как уже отмечалось имя содержит несколько полей (длиной не более 63 символов), разделенных точками. Имя может содержать не более 255 октетов, включая байт длины. Анализ имени производится справа налево. Самая правая секция имени характеризует страну (двухсимвольные национальные коды смотри в приложении), или характер организации образовательная, коммерческая, правительственная и т.д.). Следующие 3-х символьные коды в конце Internet-адреса означают функциональную принадлежность узла: Таблица 4.4.12.1. Стандартизованные суффиксы имен
Секции .mil и .gov принадлежат исключительно американским сетям (хотя и многие другие трех-символьные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru - это имя домена itepnet (Институт Теоретической и Экспериментальной физики, Москва). cl.itep.ru - имя mvax-кластера в ИТЭФ, vxitep.itep.ru - имя vax-кластера, а suncom.itep.ru - имя одной из ЭВМ SUN в той же сети. По имени, как правило, нельзя определить является ли оно именем сети, маршрутизатора или конкретной ЭВМ. Для записи символьных имен используется исключительно латинский алфавит. Маленький фрагмент интернетовской иерархии имен показан на рис. 4.4.12.2. Число уровней реально больше, но обычно не превышает 5.
Рис. 4.4.12.2. Иерархия имен в Интернет-DNS (I - домен первого уровня; II - второго уровня) Каждому узлу (прямоугольнику на рисунке) соответствует имя, которое может содержать до 63 символов. Только самый верхний, корневой узел не имеет имени. При написании имени узла строчные и прописные символы эквивалентны. Имя домена, завершающееся точкой называется абсолютным или полным именем домена (например, itep.ru.). В некоторых странах создана структура имен сходная с com/edu/org. Так в Англии можно встретить адреса .ac.uk для академических учреждений и .co.uk - для коммерческих. Если имя домена не завершено символом точки, DNS может попытаться его дополнить, например имя ns может быть преобразовано в ns.itep.ru. На приведенной схеме каждому объекту трех верхних уровней соответствуют серверы имен, которые могут взаимодействовать друг с другом при решении задачи преобразования имени в IP-адрес. Можно было бы построить схему, при которой в любом сервере имен имелись адреса серверов .com, .edu, .ru и т.д. и при необходимости он мог бы послать туда запрос. Реальная схема серверов не столь идеальна и стройна - существуют серверы nsf.gov, oakland.edu и т.д., которые непосредственно связаны с базовым сервером имен. Каждый сервер содержит лишь часть дерева имен. Эта часть называется зоной ответственности сервера. DNS-сервер может делегировать ответственность за часть зоны другим серверам, создавая субзоны. Когда в зоне появляется новая ЭВМ или субдомен, администратор зоны записывает ее имя и IP-адреса в базу данных сервера. Администратор зоны определяет, какой из DNS-серверов имен является для данной зоны первичным. Число вторичных серверов не лимитировано. Первичный и вторичный серверы должны быть независимыми и работать на разных ЭВМ, так чтобы отказ одного из серверов не выводил из строя систему в целом. Отличие первичного сервера имен от вторичного заключается в том, что первичный загружает информацию о зоне из файлов на диске, а вторичный получает ее от первичного. Администратор вносит любые изменения в соответствующие файлы первичного сервера, а вторичные серверы получают эту информацию, периодически (раз в 3 часа) запрашивая первичный сервер. Пересылка информации из первичного во вторичные серверы имен называется зонным обменом. Как будет вести себя сервер, если он не имеет запрашиваемой информации? Он должен взаимодействовать с корневыми серверами. Таких серверов насчитывается около десяти и их IP-адреса должны содержаться в конфигурационных файлах. Список корневых серверов вы можете получить с помощью анонимного ftp по адресам: nic.ddn.mil или ftp.rs.internic.net . Корневые серверы хранят информацию об именах и адресах всех серверов доменов второго уровня. Существует два вида запросов: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса, а второй - адреса сервера, который может сообщить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй эффективнее - в вашем сервере копится информация об адресах серверов имен. Одним из способов повышения эффективности трансляции имен в адреса является кэширование, то есть хранение в оперативной памяти имен-адресов, которые использовались последнее время особенно часто. Рассмотрение процесса обмена между ЭВМ-клиентом и сервером имен может прояснить работу системы в целом. Прежде чем использовать протоколы UDP или TCP прикладная программа должна узнать IP-адрес объекта, куда она хочет послать дейтограмму. Для решения этой проблемы программа посылает запрос в локальный сервер имен. В Unix-системах имеются специальные библиотечные процедуры gethostbyname и gethostbyaddr, которые позволяют определить IP-адрес по имени ЭВМ и наоборот. В одном запросе может содержаться несколько вопросов. Если сервер не сможет ответить на вопросы, он пришлет отклик, где содержатся адреса других серверов, способных решить эту задачу. Ниже на рисунке 4.4.12.3 представлен формат таких сообщений (в качестве транспорта используется UDP или TCP, порт 53).
Рис. 4.4.12.3. Формат dns-сообщений Каждое сообщение начинается с заголовка, который содержит поле идентификация, позволяющее связать в пару запрос и отклик. Поле флаги определяет характер запрашиваемой процедуры, а также кодировку отклика. Поля число... определяют число записей соответствующего типа, содержащихся в сообщении. Так число вопросов задает число записей в секции вопросов, где записаны запросы, требующие ответов. Каждый вопрос состоит из символьного имени домена, за которым следует тип запроса и класс запроса. Значения битов поля флаги в сообщении сервера имен отображены в таблице 4.4.12.2. Разряды пронумерованы слева направо, начиная с нуля рис. 4.4.12.4.
Рис. 4.4.12.4. Назначение битов поля флаги. Таблица 4.4.12.2. Коды поля флаги
Ниже описан формат секции вопросов в DNS-сообщении.
Рис. . 4.4.12.5. Формат секции вопросов dns-запроса.
Поле символьное имя домена имеет переменную длину, содержит одно или более субполей, начинающихся с байта длины (0-63). Поле завершается 0. Например, для ns.itep.ru (цифры представляют собой октеты длины): В реальной нотации байты длины субполя могут иметь два старших бита равные 1, что преобразует интервал значений из 0-63 в 192-255. Такой байт в поле означает, что это не мера длины секции, а 16-битный указатель, 14 бит которого являются смещением от начала DNS-сообщения, указывающим на место продолжения секции. Смещение для первого байта поля идентификации равно нулю. Эти ухищрения придуманы для сокращения длины сообщений, так как одно и то же имя домена в отклике может повторяться много раз. Поле тип запроса характеризует разновидность запроса: Таблица 4.4.12.3.. Разновидности полей тип запроса и их коды
(Пропущенные коды являются устаревшими или экспериментальными). Последние две строки в таблице 4.4.12.3 относятся только к вопросам. Поле класс запроса позволяет использовать имена доменов для произвольных объектов (все официальные имена Интернет относятся к одному классу [IN] - 1). В сообщении DNS-сервера каждая из секций (дополнительной информации, ответов или узловых серверов имен) состоит из набора ресурсных записей, которые описывают имена доменов и некоторую другую информацию (например, их адреса). Появление ресурсных полей в DNS базе данных придают ей новые качества. Каждая запись описывает только одно имя, формат этих записей отображен на рис. 4.4.12.6.
Рис. 4.4.12.6. Формат ресурсных записей в DNS Имя домена в этой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так для тип=1 - это 4 байта IP-адреса. Сервер имен может обслуживать и другие запросы, например, по IP-адресу определять символьное имя домена или преобразовать имя домена в адрес почтового сервера. Когда организация присоединяется к Интернет, она получает в свое распоряжение не только определенную DNS-область, но и часть пространства в in-addr.arpa, соответствующую ее IP-адресам. Домен in-addr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании. Имена в домене IN-ADDR.ARPA могут иметь до четырех субполей помимо суффикса IN-ADDR.ARPA. Каждое субполе представляет собой октет IP-адреса, и содержит последовательность символов, отображающую коды в диапазоне 0-255. Так имя для IP-адреса 192.148.166.137 (если оно существует) содержится в домене с именем 137.166.148.192.IN-ADDR.ARPA. Запись адреса задом наперед диктуется общими принципами записи имен доменов (корневая часть имени находится справа). Направив несколько запросов в домен IN-ADDR.ARPA относительно имен объектов с интересующими вас IP-адресами, можно получить следующий результат:
где в левой колонке записаны IP-адреса, имена которых ищутся, во второй - записаны аппаратные адреса интерфейсов, через которые доступны искомые объекты. Поскольку первая и третья строки относятся к внешним по отношению к узлу ITEP объектам, здесь записан адрес интерфейса пограничного маршрутизатора. В третьей колонке содержится значение RTT в мсек, а в оследней - имена объектов. IP-адресу 192.148.166.102 не соответствует никакого имени. Задержка при выполнении команды telnet между выдачей команды и появлением на экране IP-адреса связана с доступом и работой DNS-сервера. Пауза между появлением надписи Trying и Connected to определяется временем установления TCP-связи между клиентом и сервером. База данных имен может содержать и другую информацию. Типы такой информации представлены в таблице 4.4.12.3. Для извлечения информации из этой распределенной базы данных можно воспользоваться программой host (SUN или другая ЭВМ, работающая под UNIX). Рассмотрим несколько примеров (курсивом выделены команды, выданные с терминала). host -t cname cernvm.cern.ch cernvm.cern.ch is a nickname for crnvma.cern.ch Напомним, что CNAME - каноническое имя узла или ЭВМ, иногда называемое также псевдонимом (alias). host -t hinfo ns.itep.ru ns.itep.ru HINFO SparcStation-1 SunOS-4.1.3 HINFO - информация об ЭВМ. Это обычно две последовательности символов, которые характеризуют ЭВМ и ее операционную систему. Много полезной информации можно узнать о почтовом сервере узла посредством команды:
host -t mx cl.itep.ru
host -v info.cern.ch
Trying domain "itep.ru"
For authoritative answers, see:
Additional information: dxmon.cern.ch 79157 IN A 192.65.185.10 Опция -v, используемая совместно с командой host позволяет получить более полную информацию об узле. Во второй колонке данной выдачи указано время жизни (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса (см. табл. 4.4.12.3). В пятой колонке идут названия серверов имен и IP-адреса ЭВМ. Далее следуют коды предпочтения. MX-записи активно используются почтовыми серверами. Обмен MX-записями производится в следующих случаях:
MX-записи снабжены 16-битными кодами предпочтения. Если для адреса имеется несколько MX-записей, они используются в порядке нарастания этого кода. Если вы хотите узнать список доступных услуг на той или иной ЭВМ, вы можете напечатать команду (WKS - Well Known Services, сюда не входят услуги прикладного уровня, например, услуги NEWS-сервера и пр.):
host -tv wks ns.itep.ru Если вам нужно узнать IP-адреса того или иного узла можно также воспользоваться командой host:
host vxdesy.desy.de Большая часть данных относится к типу "А". Выше уже говорилось, что для транспортировки DNS-запросов применяются протоколы UDP и TCP. Когда же следует использовать эти протоколы? Обычно используется UDP. Когда в ответ на запрос программа получает отклик с битом флагов TC=1 (сообщение укорочено), программа повторяет запрос, но уже с использованием протокола TCP. Этот протокол применяется также для зонных обменов между первичным и вторичным DNS-серверами. Обычно реализация сервера имен (версия BIND - Berkeley Internet Name Domain) предполагает наличие трех конфигурационных файлов:
named.boot - файл начальной загрузки сервера имен; Это текстовые файлы, строки и фрагменты, начинающиеся с точки с запятой, представляют собой комментарии. В первом из перечисленных файлов строка, начинающаяся со слова sortlist, указывает на порядок присылки адресов при условии, что отклик на запрос содержит несколько адресов. Строка, начинающаяся со слова directory, содержит название каталога, где хранятся конфигурационные файлы (по умолчанию /etc). Строка cache сообщает имя файла-буфера имен и адресов (по умолчанию named.ca). Далее обычно следует несколько строк, начинающихся со слова primary. Эти строки указывают имена файлов (например, named.hosts или named.local), где содержится информация о соответствии имен и адресов для определенных субдоменов. Вместо имени файла может быть указан IP-адрес. Укладка данных в файле соответствует требованиям документа RFC-1033. Для вторичного (secondary) DNS файл named.boot имеет схожую структуру. Вместо строк со словом primary в этом файле присутствуют строки secondary. Эти строки содержат помимо имен субдоменов и файлов IP-адрес первичного DNS. Последний выполняет и функцию переадресации запросов вышестоящим серверам. Вторичный DNS-сервер при невозможности выполнить запрос переадресует его первичному серверу, а не вышестоящему. Первичный сервер может создавать большой кэш-буфер для локального обслуживания часто поступающих запросов. Файл named.local служит для спецификации интерфейса сервера имен и содержит в себе запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первой строки файла определяет имя зоны. Здесь же указываются опционные параметры:
Запись может выглядеть как (RFC-1033): @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( В файле приводится имя первичного сервера имен для данного субдомена (флаг NS) и имя администратора с указанием адреса его электронной почты. Последняя запись в файле содержит указатель на местную ЭВМ. Первая цифра в строке этой записи содержит суффикс IP-адреса этой машины. Файл named.ca используется для заполнения кэша при первичной загрузке DNS. Примером, иллюстрирующим возможное содержимое файла можно считать следующее (взято из RFC-1033): ;list of possible root servers Первое поле представляет собой имя домена или субдомена, второе поле - значение TTL, третье - поле класс (Internet), четвертое - тип записи (NS для сервера имен или A для адреса), и последнее поле характеризует имя ЭВМ или IP-адрес. Если какие-то поля пусты, это означает, что они тождественны приведенным выше. Точка в начале первой строки указывает на корневой домен. Для администраторов, обслуживающих DNS, весьма полезно ознакомиться с документом RFC-1536 ("Common DNS Implementation Errors and Suggested Fixes"). Ошибки при конфигурации DNS-сервера могут привести к досадным ошибкам и отказам системы. Обычно, при получении запроса DNS сначала определяется его зона и просматривается кэш. Если запрос не может быть выполнен, просматривается список вышестоящих DNS-серверов, которые могут содержать необходимую информацию, и запрос пересылается одному из них. Если клиент прислал рекурсивный запрос и сервер поддерживает рекурсию, запрос пересылается соответствующим серверам. Если рекурсия не поддерживается, сервер возвращает клиенту список DNS-серверов, предоставляя ему решать свои проблемы самостоятельно. Однако в некоторых случаях DNS-сервер по ошибке может включить себя в такой список серверов. Если программное обеспечение клиента не проверяет список, запрос может быть послан этому серверу повторно, что вызовет бесконечный цикл запросов. Возможна и другая схема возникновения циклов запросов. Предположим, что сервер <1> содержит в своем списке внешних DNS сервер <2>, а последний в свою очередь содержит в своем списке сервер <1>. Такого рода перекрестные ссылки трудно обнаружить особенно, если в перечне фигурирует большое число серверов. Иногда возникает ситуация, когда клиент, получив список DNS-серверов, не знает, что с ним делать и посылает запрос повторно тому же серверу. Идентифицировать такого рода ошибки весьма трудно, особенно когда в это вовлечены внешние серверы, содержимое конфигурационных файлов которых недоступно. Иногда DNS-сервер в ответ на запрос не присылает сообщений об ошибке и никаких-либо данных клиенту. Это случается когда запрашиваемое имя вполне корректно, но записей нужного типа не найдено. Например, запрошен адрес почтового сервера домена xxx.com. Домен этот существует, но рекорда типа MX не обнаружено. Дальнейшие события зависят от характера программного обеспечения клиента. Если клиент считает такого рода "отклик" некорректным, он может послать запрос повторно и т.д. и т.д. По этой причине в случае, если программное обеспечение это позволяет, рекомендуется ограничить число повторных запросов клиента. Приведенные примеры показывают, насколько актуальна корректная конфигурация DNS клиента и сервера. В системах Windows часто используется своя служба имен WINS (Windows Internet Naming Service, см. RFC-2136 и RFC-2137). Эта служба совместима с системой динамического конфигурирования сети DHCP (Dynamic Host Configuration Protocol, использует динамическое распределение IP-адресов). В WINS, также как и в DHCP, имеются части, работающие у клиента и на сервере. WINS автоматически устанавливается и конфигурируется при установке системы DHCP. Эта система имеет удобную встроенную диагностику, позволяющую контролировать процесс обработки запросов к службе имен. WINS осуществляет преобразование NETBIOS-имен в IP-адреса. Эта техника предполагает использование протокола NetBIOS поверх TCP/IP (NetBT). В ОС WINDOWS 2000 технология WINS заменена DDNS (Dynamic Domain Name Service). WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 4.4.12.7.
В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, идентичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 4.4.12.8.
Поле флаги имеет следующую структуру:
Для поля флаги имени характерна следующая структура
Для поля флагов имени группы характерно следующее назначение бит
В последнее время развивается технология DDNS динамического обновления ресурсных записей зоны DNS внешними ЭВМ или процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями DDNS могут сами обновлять записи локальных серверов имен. Еще более интересное решение базируется на интеграции служб DHCP и DNS. В этом варианте серверы DHCP, поддерживающие DDNS, посылают соответствующему серверу DNS данные для обновления записей, включая имена NetBIOS клиентов DHCP. Запись обновляется после выделения IP-адреса. При реализации DDNS возникают проблемы безопасности. Часть этих проблем может быть решено путем использования цифровых подписей (RFC-2137). Еще одной проблемой, связанной со службой имен, являются атаки, которые сопряжены с имитацией DNS. Для преодоления таких атак разработан метод транзакционных подписей TSIG (Transaction SIGnarure). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.11.8 Язык описания маршрутной политики RPSL
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.13 Протокол управления SNMP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Интернет - гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ - сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP(Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089 разработан в 1988 году) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор. Протокол snmp работает на базе транспортных возможностей UDP и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212). Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица (4.4.13.1) команд (pdu - protocol data unit) SNMP: Таблица 4.4.13.1 Команды SNMP
Рис. 4.4.13.1 Схема запросов/откликов snmp Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (рис. 4.4.13.2):
Рис. 4.4.13.2 Формат snmp-сообщений, вкладываемых в UDP-дейтограммы Поле версия содержит значение, равное номеру версии snmp минус один. Поле пароль (community - определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления: Таблица 4.4.13.2. Номера и назначения используемых портов
Таблица 4.4.13.3. Коды ошибок
Если произошла ошибка, поле индекс ошибки (error index) характеризует, к какой из переменных это относится. error index является указателем переменной и устанавливается объектом управления не равным нулю для ошибок badvalue, readonly и nosuchname. Для оператора TRAP (тип PDU=4) формат сообщения меняется. Таблица типов TRAPпредставлена ниже (4.4.13.4): Таблица 4.4.13.4. Коды TRAP
Для тип TRAP 0-4 поле специальный код должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации. В последнее время широкое распространение получила идеология распределенного протокольного интерфейса DPI (Distributed Protocol Interface). Для транспортировки snmp-запросов может использоваться не только UDP-, но и TCP-протокол. Это дает возможность применять SNMP-протокол не только в локальных сетях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в документе RFC-1592. Пример заголовка snmp-запроса (изображенные поля образуют единый массив; см. рис. 4.4.13.3):
Рис. 4.4.13.3. Формат заголовка SNMP-запроса Поле Флаг=0x30 является признаком ASN.1-заголовка. Коды Ln - представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n - номер поля длины), если не оговорено другое. Так L1 - длина пакета-запроса, начиная с T1 и до конца пакета, а L3 - длина поля пароля. Субполя Tn - поля типа следующего за ними субполя запроса. Так T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA - является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.13.1) Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы - для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. СО - статус ошибки (СО=0 - ошибки нет); ТМ - тип MIB-переменной (в приведенном примере = 0x2B); ИО - индекс ошибки. Цифровой код MIB-переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризуется последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00. SNMP-протокол служит примером системы управления, где для достижения нужного результата выдается не команда, а осуществляется обмен информацией, решение же принимается "на месте" в соответствии с полученными данными. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.13.1 Управляющая база данных MIB
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Вся управляющая информация для контроля ЭВМ и маршрутизаторами Интернет концентрируется в базе данных MIB (Management Information Base, RFC-1213 или STD0017). Именно эти данные используются протоколом SNMP. Система SNMP состоит из трех частей: менеджера SNMP, агента SNMP и базы данных MIB. Агент SNMP должен находиться резидентно в памяти объекта управления. SNMP-менеджер может быть частью системы управления сетью NMS (Network Management System), что реализуется, например, в маршрутизаторах компании CISCO (CiscoWorks). MIB определяет, например, что IP программное обеспечение должно хранить число всех октетов, которые приняты любым из сетевых интерфейсов, управляющие программы могут только читать эту информацию. Согласно нормативам MIB управляющая информация делится на восемь категорий (см. также рис. 4.4.13.1.1): MIB-категория включает в себя информацию о
Таблица 4.4.13.1.1. Системные переменные MIB
Таблица 4.4.13.1.2. Переменные IFtable (интерфейсы)
Ниже представлена таблица цифро-точечного представления переменных, характеризующих состояние интерфейса. Эта таблица может быть полезной для программистов, занятых проблемами сетевой диагностики.
Таблица 4.4.13.1.3. Переменные IP-группы
Помимо простых переменных объектами MIB могут быть таблицы. Для каждой таблицы имеется один или несколько индексов. Таблица 4.4.13.1.4. Переменные TCP-группы
Таблица 4.4.13.1.5. Переменные ICMP-группы (тип данных - counter)
Таблица 4.4.13.1.6. Переменные AT-группы (attable, преобразование адресов).
Каждый протокол (например IP) имеет свою таблицу преобразования адресов. Для IP это ipnettomediatable. Способ пропечатать эту таблицу с помощью программы SNMPI описан ниже. MIB II содержит управляемые объекты, принадлежащие к группе snmp. SNMP-группа предоставляет информацию о SNMP-объектах, информационных потоках, о статистике ошибок:
Стандарт на структуру управляющей информации (SMI) требует, чтобы все MIB-переменные были описаны и имели имена в соответствии с ASN.1 (abstract syntax notation 1, формализованный синтаксис). ASN.1 является формальным языком, который обладает двумя основными чертами: используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. В SMI не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: integer, octet string, object identifier и null. Практически в протоколе SNMP фигурируют следующие виды данных: integer. Некоторые переменные объявляются целыми (integer) с указанием начального значения или с заданным допустимым диапазоном значений (в качестве примера можно привести номера UDP- или TCP-портов). octet string (последовательность байтов). В соответствии с требованиями BER (basic encoding rules, ASN.1) последовательность октетов должна начинаться с числа байт в этой последовательности (от 0 до n). object identifier (идентификатор объекта). Имя объекта, представляющее собой последовательность целых чисел, разделенных точками. Например, 192.148.167.129 или 1.3.6.1.2.1.5. null. Указывает, что соответствующая переменная не имеет значения. displaystring. Строка из 0 или более байт (но не более 255), которые представляют собой ASCII-символы. Представляет собой частный случай octet string. physaddress. Последовательность октетов, характеризующая физический адрес объекта (6 байт для Ethernet). Частный случай object identifier. Сетевой адрес. Допускается выбор семейства сетевых протоколов. В рамках ASN.1 этот тип описан как choice, он позволяет выбрать протокол из семейства протоколов. В настоящее время идентифицировано только семейство протоколов Интернет. IP-адрес. Этот адрес используется для определения 32-разрядного Интернет-адреса. В нотации ASN.1 - это octet string. time ticks (такты часов). Положительное целое число, которое используется для записи, например, времени последнего изменения параметров управляемого объекта, или времени последней актуализации базы данных. Время измеряется в сотых долях секунды. gauge (масштаб). Положительное целое число в диапазоне 0 - (232-1), которое может увеличиваться или уменьшаться. Если эта переменная достигнет величины 232-1, она будет оставаться неизменной до тех пор пока не будет обнулена командой сброс. Примером такой переменной может служить tcpcurresta, которая характеризует число TCP соединений, находящихся в состоянии established или close_wait. counter (счетчик). Положительное целое число в диапазоне 0 - (232-1), которое может только увеличиваться, допуская переполнение. sequence. Этот объект аналогичен структуре в языке Си. Например, MIB определяет sequence с именем udpentry, содержащую информацию об активных UDP-узлах. В этой структуре содержится две записи: 1. UDPlocaladdress типа ipaddress, содержит местные IP-адреса. 2. UDPlocalport типа integer, содержит номера местных портов. SEQUENCE OF. Описание вектора, все элементы которого имеют один и тот же тип. Элементы могут представлять собой простые объекты, например, типа целое. В этом случае мы имеем одномерный список. Но элементами вектора могут быть объекты типа SEQUENCE, тогда этот вектор описывает двумерный массив. В Интернет MIB каждый объект должен иметь имя (object identifier), синтаксис и метод кодировки. Стандарт ASN.1 определяет форму представления информации и имен. Имена переменных MIB соответствуют в свою очередь стандартам ISO и CCITT. Структура имен носит иерархический характер, отображенный на рис. 4.4.13.1.1.
Рис. 4.4.13.1.1 Структура идентификаторов переменных в MIB В приведенной ниже таблице охарактеризованы четыре простые переменные, идентификаторы которых помещены в нижней части рис. 4.4.13.1.1. Все эти переменные допускают только чтение.
Ниже приведено описание таблицы (udptable; index =
Согласно этой иерархии переменные, соответствующие ICMP, должны иметь префикс (идентификатор) 1.3.6.1.2.1.5 или в символьном выражении iso.org.dod.internet.mgmt.mib.icmp. Если вы хотите узнать значение какой-то переменной, следует послать запрос, содержащий соответствующий префикс и суффикс, последний определяет имя конкретной переменной. Для простой переменной суффикс имеет вид .0. Ветвь структуры на рис. 4.4.13.1.1, завершающейся узлом Interfaces (2) имеет продолжение в виде ifTable(2) и ifEntry(1). Таким образом переменная ifInUcastPkts будет иметь представление 1.3.6.1.2.1.2.2.1.11. Помимо стандартного набора переменных и таблиц MIB возможно использование индивидуальных расширений этой базы данных. Это можно продемонстрировать на примере MIB маршрутизаторов Cisco (рис. 4.4.13.1.2).
Рис. 4.4.13.1.2. Расширение базы данных mib маршрутизаторов Cisco Префикс 1.3.6.1.4.1. является стандартным, далее следует расширение, индивидуальное для маршрутизаторов компании Cisco. Например, группа IPcheckpoint accounting позволяет контролировать поток байтов с определенных адресов локальной сети, что бывает важно при работе с коммерческими провайдерами услуг. Коды-префиксы для различных производителей телекоммуникационного оборудования приведены в таблице 4.4.13.1.7. Таблица 4.4.13.1.7 Коды-префиксы производителей
Группа локальных переменных IP checkpoint accounting (1.3.6.1.4.1.9.2.4.7.1) представляет собой таблицу, содержащую в каждом рекорде по четыре переменных (в скобках указан суффикс адреса MIBдля переменной):
Маршрутизаторы Cisco поддерживают две базы данных: active accounting и checkpoint accounting. В первую заносятся текущие результаты измерения входящего и исходящего трафика. Эти результаты копируются в базу данных checkpoint accounting и, если там уже имеются предыдущие данные, они объединяются. Для очистки базы данных checkpointed database выдается команда clear IP accounting, а для базы checkpoint - clear IP accounting checkpoint (для использования этих команд необходимы системные привилегии). Объем памяти, выделяемой для этих баз данных задается командой IP accounting-threshold <значение>, по умолчанию максимальное число записей в базе данных равно 512. Лучшим способом закрепить в памяти все вышесказанное является использование программы SNMPI (SNMP initiator) или ее аналога. Если в вашем распоряжении имеется ЭВМ, работающая под unix, например SUN, вы можете попутно узнать много полезного о вашей локальной сети. Ниже описан синтаксис обращения к SNMPI. snmpi [-a agent] [-c community] [-f file] [-p portno] [-d] [-v] [-w] SNMPI - крайне простая программа, используемая для тестирования SNMPD. Для того чтобы проверить, работает ли она, выдайте команду: % SNMPI dump Следует отметить, что в ответ на эту операцию будет произведена весьма объемная выдача. Опция -a предлагает возможность ввести адрес SNMP-объекта - имя ЭВМ, IP-адрес или транспортный адрес. По умолчанию это местная ЭВМ. Аналогично опция -p позволяет задать номер UDP-порта. По умолчанию это порт 161. Опция -c позволяет задать групповой пароль (community) для snmp-запроса. По умолчанию - это public, т.е. свободный доступ. Опция -f позволяет выбрать файл, содержащий откомпилированные описания mib-модулей. По умолчанию - это objects.defs. Опция -w включает режим наблюдения, осуществляя выдачу на терминал всех служебных сообщений. Уход из программы по команде quit (q). Если вы работаете на IBM/PC, и ваша машина подключена к локальной сети, получите допуск к одной из UNIX-машин в сети (если вы его не имели) и приступайте. Можно начать с обращения типа: SNMPI -a 193.124.224.33 (адрес или символьное имя надо взять из вашей локальной сети) Машина откликнется, отобразив на экране SNMPI>, это означает, что программа имеется и вы можете вводить любые команды. Начать можно со знакомства с системными переменными системы (в дальнейшем курсивом выделены команды, введенные с клавиатуры): SNMPI> get sysdescr.0 snmpi> sysdescr.0="GS software (gs3-k), version 9.1(4) [fc1], software copyright (c) 1986-1993 by cisco systems, inc. compiled thu 25-mar-93 09:49 by daveu" snmpi> get sysobjectid.0 Код 0x06 (sysservices.0) представляет собой сумму кодов уровней модели iso, поддерживаемых системой. Для справок: 0x01 - физический уровень; 0x02 - связной уровень; 0x04 - Интернет; 0x08 - связь точка-точка; 0x40 - прикладной уровень. Если вы хотите получить информацию о состоянии интерфейсов на одной из ЭВМ, подключенных к вашей локальной сети (команды вызова snmpi далее не повторяются; в ниже приведенных примерах в круглых скобках помещены комментарии автора), выдайте команды: SNMPI> next iftabl (команда next в данном случае соответствует запросу get-next, здесь понятие "следующий" подразумевает порядок переменных в MIB) snmpi> ifindex.1=1 ifspeed.2=2048000 (2 Мбит/c радиорелейный последовательный канал, спутниковый канал был бы охарактеризован точно также). ifphysaddress.2= В приведенном примере размеры пересылаемых блоков для Ethernet и радиорелейного последовательного канала идентичны и равны 1500. Помните, что SLIP-канал характеризуется как pointtopointserial, а не slip. Скорость обмена по SLIP-каналу не сообщается. Теперь просмотрим некоторые UDP-переменные. Например: SNMPI> next UDP (Идентификатор этого объекта - 1.3.6.1.2.1.7.5.1.1.193.124.137.14.7.) SNMPI> next udplocalport Ниже показана методика выяснения алгоритма и параметров задания величины тайм-аута: SNMPI> get tcprtoalgorithm.0 tcprtomin.0 tcprtomax.0 tcpmaxconn.0
Чтобы получить информацию о состоянии таблицы адресных преобразований, выдайте команду: SNMPI -a 193.124.224.33 dump at (процедуры с использование субкоманды dump требуют определенного времени для своего исполнения)
Текст выдачи с целью экономии места сокращен. Обычно элементы таблицы расположены в порядке колонка-ряд. Если вы дошли до края колонки или всей таблицы ЭВМ выдаст вам, в зависимости от реализации программы, имя и значение следующего элемента или сообщение об ошибке. Чтобы получить полный текст адресной таблицы в рамках SNMPI достаточно выдать команду: SNMPI> dump ipaddrtable
(Маски субсетей)
ipadentbcastaddr.192.148.166.222= 1 (Все эти субсети используют для широковещательной адресации одни и те же биты).
ipadentreasmmaxsize.192.148.166.222= 18024 (С точки зрения фрагментации и последующей сборки дейтограмм данные субсети эквивалентны).
Данная пропечатка совместно с приведенной для IFtable позволяет получить достаточно полную картину о данной конкретной локальной сети. Чтобы познакомиться с ARP таблицей, можно воспользоваться командой: sun> arp -a itepgw.itep.ru (193.124.224.33) at 0:0:c:2:3a:49 и дополнить полученные данные с помощью SNMPI: SNMPI> dump ipnettomediatable SNMPI> ipnettomediaifindex.1.193.124.224.33= 1 Синтаксис каждого объекта описывается в рамках ASN.1 и показывает побитовое представление объекта. Кодирование объекта характеризует то, как тип объекта отображается через его синтаксис и передается по телекоммуникационным каналам. Кодирование производится в соответствии с базовыми правилами кодирования asn.1. Все описания объектов базируются на типовых шаблонах и кодах asn.1 (см. RFC-1213). Формат шаблона показан ниже: object (Объект): Имя типа объекта с соответствующим ему идентификатором объекта (object identifier) syntax (Синтаксис): Маршруты также являются объектами mib. Согласно требованиям к mib, каждому маршруту в этой базе соответствует запись, схема которой приведена ниже на рис. 4.4.13.1.3:
Рис. 4.4.13.1.3 Формат записи маршрутной таблицы в MIB Поле место назначения представляет собой IP-адрес конечной точки маршрута. Поле индекс интерфейса определяет локальный интерфейс (физический порт), через который можно осуществить следующий шаг по маршруту. Следующие пять полей (метрика 1-5) характеризуют оценку маршрута. В простейшем случае, например для протокола RIP, достаточно было бы одного поля. Но для протокола OSPF необходимо 5 полей (разные TOS). Поле следующий шаг представляет собой IP-адрес следующего маршрутизатора. Поле тип маршрута имеет значение 4 для опосредованного достижения места назначения; 3 - для прямого достижения цели маршрута; 2 - для нереализуемого маршрута и 1 - для случаев отличных от вышеперечисленных. Поле протокол маршрутизации содержит код протокола. Для RIP этот код равен 8, для OSPF - 13, для BGP - 14, для IGMP - 4, для прочих протоколов - 1. Поле возраст маршрута описывает время в секундах, прошедшее с момента последней коррекции маршрута. Следующее поле - маска маршрута используется для выполнения логической побитовой операции И над адресом в IP-дейтограммы перед сравнением результата с кодом, хранящимся в первом поле записи (место назначения). Последнее поле маршрутная информация содержит код, зависящий от протокола маршрутизации и обеспечивающий ссылки на соответствующую информацию в базе MIB. Новым расширением MIB является система удаленного мониторинга сетей (RMON; RFC-1513, -1271). RMON служит для мониторирования сети в целом, а не отдельных сетевых устройств. В RMON предусмотрено 9 объектных групп (см. табл. 4.4.13.1.8). Таблица 4.4.13.1.8. Функциональные группы RMON
Для того чтобы реализовать функционирование RMON-агента, сетевая карта должна быть способна работать в режиме 6 (promiscuous mode), когда воспринимаются все пакеты, следующие по кабельному сетевому сегменту. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.13 Протокол управления SNMP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.13.2 Нотация ASN.1
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Одной из наиболее сложных систем сегодня являются открытые системы связи OSI (Open System Interconnection). OSI представляет собой достаточно формализованную стандартную архитектуру управления межкомпьютерными коммуникациями. Для описания этой системы была разработана абстрактный синтаксис нотаций ASN.1 (Abstract Syntax Notation; См. A Layman's Guide to a Subset of ASN.1, BER, and DER. Burton S. Kaliski Jr., RSA Data Security, Inc. Redwood City, CA, 1991). ASN.1 является формальным языком, который обладает двумя основными чертами. Используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. Неотъемлемой частью ASN.1 являются базовые правила кодирования BER (Basic Encoding Rules), которые позволяют определить большое разнообразие типов данных. BER описывает то, как представить или закодировать любую величину в рамках стандарта ASN.1. Практически все величины здесь представляются в виде последовательности 8-битных октетов. Восьмой бит октета всегда считается самым старшим. BER позволяет закодировать величину более чем одним способом. Имеется также поднабор правил кодирования DER (Distinguished Encoding Rules, описаны в документе Х.509), которые определяют однозначные способы кодирования величин ASN.1. Ниже приведены базовые правила обозначений метасинтаксиса ASN.1.
ASN.1 имеет четыре разновидности типов: простые типы, не имеющие компонент, структурные типы, имеющие компоненты, помеченные (tagged) типы, которые получаются из других типов, а также прочие типы, которые включают в себя типы CHOICE и ANY. Типам и значениям могут присваиваться имена с помощью оператора (::=). Эти имена в дальнейшем могут использоваться для определения других типов и величин. Все типы ASN.1 кроме CHOICE и ANY имеют метки, которые состоят из класса и неотрицательного кода метки. Типы ASN.1 тождественны, если их числовые метки совпадают. Существует четыре класса меток.
Ниже приведена таблица 4.4.13.2.1 типов и их меток универсального класса. Таблица 4.4.13.2.1. Типы и их метки
ASN.1 типы и значения выражаются в нотации, близкой к используемой в языках программирования. Множественные пробелы и разрывы строк рассматриваются как один пробел. Комментарии выделяются парами дефисов или парой дефисов и переводом строки. Идентификаторы (имена значений и полей) и имена типов состоят из букв, цифр и пробелов. Идентификаторы начинаются со строчной буквы, а имена типов - с прописной. В SMI (Structure of Management Information) не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: INTEGER, OCTET STRING, OBJECT IDENTIFIER и NULL. Стандарт ASN.1 определяет форму представления информации и имен. Для строчных типов может быть введено ограничение на максимальный размер. В ASN.1 определено четыре структурированных типов:
Структурированные типы могут иметь опционные компоненты, в том числе со значениями по умолчанию. Существуют типы помеченные явно и неявно. Неявно помеченные типы получаются из других типов путем изменения метки. Для неявной пометки используется ключевое слово IMPLICIT. Явно помеченные типы получаются из других типов путем добавления внешней метки. Помеченный явно тип - это структурированный тип, состоящий из одного компонента основного типа. Для явной пометки используется ключевое слово EXPLICIT. Пометка (тэгирование) весьма удобна для различия типов в пределах одного приложения. Тип CHOICE обозначает объединение одного или более альтернатив. Тип ANY служит для обозначения произвольной величины для произвольного типа. Правила BER определяют один или более способов представить любую величину в виде строки октетов. Существует три метода кодирования величин (в рамках BER): примитивный с известной длиной; конструктивный при известной длине и конструктивный при неизвестной длине. Выбор метода зависит от типа величины и от того, известна ли длина преобразуемой величины. Для простых не строчных типов используется примитивный метод кодирования. В каждом методе BER-кодирование имеет три или четыре части:
Примитивный метод кодирования с заданной длиной Этот метод применим для простых типов и типов полученных из простых типов путем неявной пометки. Здесь необходимо, чтобы длина величины была известна заранее. Октеты идентификатора имеют два формата: для числовых меток от 0 до 31, и для числовых меток более 31. В первом случае биты 7 и 8 определяют класс (см. таблицу 4.4.13.2.2), бит 6 равен нулю, указывая на то, что метод кодирования primitive. Остальные биты используются для записи кода числовой метки. Во втором случае используется два или более октетов. В первом октете кодировка аналогична первому варианту за исключением того, что биты 1-5 содержат единицы. Таблица 4.4.13.2.2. Коды классов
Для октетов длины примитивного метода имеется два формата: короткий (один октет для длин 0-127) и длинный (2-127 октетов). Для короткой формы 8-ой бит октета всегда равен нулю. Для длинной формы восьмой бит первого октета всегда равен 1, биты 1-7 содержат код числа дополнительных октетов длины. Старшая цифра записывается первой. Конструктивный метод с заданной длиной Этот метод используется для простых строчных и структурированных типов, типов, производных от простых строчных типов, и некоторых других. Здесь октеты идентификатора и октеты длины имеют формат, идентичный используемому примитивным методом, за исключением того, что бит 6 первого октета идентификатора равен 1. Конструктивный метод кодирования с незаданной длиной Метод используется для простых строчных типов, структурированных типов и типов, полученных из простых и структурированных типов с помощью неявной пометки. Октеты идентификатора идентичны предшествующему. Октет длины содержит код 80. Два октета конца содержательной части содержат 00 00. Нотация типов, помеченных неявно, имеет вид: [[class] number] IMPLICIT Type class = UNIVERSAL | APPLICATION | PRIVITE где Type - тип, class - опционное имя класса и number - цифровая метка (неотрицательное целое число). Если имя класса отсутствует, тогда метка является контекстно-ориентированной. Такие метки могут появляться только в структурных компонентах или в типе CHOICE. Например: PrivateKeyInfo ::= SEQUENCE { Здесь исходным (порождающим) типом является Attributes, класс отсутствует (т.е. контекстно-ориентированный), а числовая метка равна нулю. Кодирование компоненты attributes величины PrivateKeyInfo осуществляется следующим образом. Октеты идентификатора равны 80, если значение порождающей величины Attributes имеет конструктивное BER-кодирование. Октеты длины и содержимого строго соответствуют октетам порождающей величины Attributes. Непосредственная (явная) пометка используется для опционных компонент SEQUENCE c порождающим типом ANY и для компонент version типа Certificate (X.509 и RFC-1114). Нотация типов, помеченных явно, имеет формат. [ [class] number] EXPLICIT Type class = UNIVERSAL | APPLICATION | PRIVATE где Type - тип, class - опционное имя класса, а number - числовая метка в пределах класса (неотрицательное целое число). Пример: ContentInfo ::= SEQUENCE { Тип ContentInfo имеет опционную компоненту content с явной контекстно-ориентированной меткой. Здесь порождающим типом является ANY DEFINED BY contentType, класс отсутствует, а числовая метка в пределах класса равна 0. Другим примером может являться тип Certificate [X.509], имеющий компоненту с явной контекстно-ориентированной меткой (ключевое слово EXPLICIT опущено). Certificate ::= . BER-кодирование величин, помеченных явно, является всегда конструктивным. Октеты содержимого идентичны соответствующим октетам порождающей величины. Например, BER-кодирование компоненты content величины ContentInfo имеет следующий вид. Октеты идентификатора равны нулю, Октеты длины представляют длину BER-кодирования порождающей величины ANY DEFINED BY contentType. Тип ANY Тип ANY обозначает произвольную величину произвольного типа, где произвольный тип возможно определен при регистрации идентификатора объекта или является целочисленным индексом. Нотация типа ANY имеет формат: ANY [DEINED BY identifier ] где identifier - опционный идентификатор. Форма ANY DEINED BY identifier может появиться только в компоненте типа SEQUNCE или SET, для которой identifier определяет какую-то другую компоненту и эта компонента имеет тип INTEGER или OBJECT IDENTIFIER. В этой форме истинный тип задается величиной этой другой компоненты. Например, тип AlgorithmIdentifier [X.509] имеет компоненту типа ANY: AlgorithmIdentifier ::= SEQUENCE { Здесь истинный тип компоненты parameter зависит от величины компоненты algorithm. Истинный тип будет определен при регистрации объекта величины идентификатора длякомпоненты algorithm. Битовые строки Тип BIT STRING обозначает произвольные битовые последовательности произвольной длины (включая ноль). Тип BIT STRING используется для цифровых сигнатур типа ExtendedCertificate или Certificate [X.509]. Нотация BIT STRING имеет формат. BIT STRING Например, тип SubjectPublicKeyInfo имеет компоненту типа BIT STRING: SubjectPublicKeyInfo ::= SEQUENCE { BER-кодирование величины BIT STRING может быть примитивным или конструктивным. При примитивном кодировании первый октет содержимого несет в себе длину битовой строки в октетах. В последующих октетах записывается сама битовая последовательность. Процедура кодирования может включать в себя дополнение битовой строки до целого числа октетов нулями (если это необходимо). Строка делится на октеты. При конструктивном кодировании октеты содержимого представляют собой соединение последовательности субстрок, только последняя из которых содержит код длины, выраженный в октетах. Например, при BER-кодировании значения BIT STRING "0111 1101 1001 1111 11" может быть представлена в одном из следующих видов, в зависимости от выбора схемы дополнения до целого числа октетов, от формата октетов длины и от метода кодирования примитивный/конструктивный).
Первый октет первых трех представлений содержат код типа (для BIT STRING = 03). Второй октет в первых двух представлениях - код октетов длины (ведь далее следует 4 октета). Третий октет первой и второй строк содержит число добавленных нулей до числа бит, кратного восьми. Во втором байте третей строки записана 8, что указывает на длинную форму представления октетов длины. Последующая 1 говорит о том, что использован один дополнительный октет длины. Код длины в четвертом примере записан также во втором октете (далее следует 9 октетов). В этом варианте битовая строка разбита на две субстроки, первая из которых имеет длину в два октета. DER-кодирование предполагает всегда примитивный метод представления с дополнением строки нулями до длины, кратной целому числу октетов. Тип CHOICE Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат. CHOICE { где identifier 1, ., identifiern являются опционными идентификаторами альтернатив, а типы Type 1, ., Type n - альтернативы. Идентификаторы нужны для документирования и не играют какой-либо роли при кодировании. Типы должны иметь определенные метки. Рассмотрим пример типа ExtendedCertificateOrCertificate, который относится к типу CHOICE. ExtendedCertificateOrCertificate ::= CHOICE { Здесь идентификаторами для альтернатив являются certificate и extendedCertificate, а сами альтернативы представлены типами Certificate и [0] IMPLICIT ExtendedCertificate. BER-кодирование для типа CHOICE сводится к кодированию альтернатив. При этом октеты идентификатора для рассмотренного примера содержат код 30, если выбранная альтернатива certificate, и A0 - в случае ExtendedCertificate. Строки IA5 Тип IA5String представляет любые последовательности IA5-символов (международный алфавит 5 - эквивалентно ASCII). Длина строки может быть любой, включая нуль. Этот тип используется для адресов электронной почты и неструктурированных имен. Нотация типа IA5String имеет простой формат. IA5String BER-кодирование величины IA5String может быть примитивным или структурированным. При примитивном кодировании октеты содержимого представляют собой символы IA5 в ASCII-кодов. При конструктивном кодировании октеты содержимого представляют собой соединение ряда IA5-субстрок. Рассмотрим примеры представления значения IA5-строки "test1@rsa.com".
DER-кодирование является всегда примитивным, октеты содержимого идентичны случаю BER-кодирования. Целое Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей) и типов RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter. Нотация типа INTEGER имеет формат: INTEGER [{ identifier 1( value1 ) . identifier n( valuen ) }] где identifier 1 . identifier n являются опционными идентификаторами, а value1 . valuen опционные целые значения. Например, Version RFC-1114 относится к целому типу со значением: Version ::= INTEGER { 1988(0) } Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate RFC-1114 использует идентификатор v1988для присвоения значения по умолчанию компоненту version: Certificate BER-кодирование значения INTEGER является всегда примитивным. Октеты содержимого представляют значение целого по модулю 256 в форме дополнения по модулю 2. Старшая цифра является первой. Значение нуль кодируется одним октетом 00. Примеры BER-кодирования (совпадающего в данном случае с DER-кодированием) представлены в таблице 4.4.13.2.3. Таблица 4.4.13.2.3. Примеры BER-кодирования
NULL Тип NULL обозначает нулевую величину и предназначен для использования в качестве параметра алгоритмов. Нотация для типа NULL имеет формат: NULL Кодирование для типа NULL является всегда примитивным, октеты содержимого пусты. Например, BER-представление значения NULL может иметь одну из приведенных ниже форм (зависит от используемого представления октетов длины). 05 00 DER-кодирование типа NULL является также примитивным и совпадает с первой строкой приведенного выше примера. Объектные идентификаторы Тип OBJECT IDENTIFIER служит для обозначения дентификаторов, которые представляют собой последовательность целочисленных компонент, которые идентифицируют такие объекты, как алгоритм или атрибут имени каталога. Значение OBJECT IDENTIFIER может содержать любое число неотрицательных компонент. Этот тип не относится в числу строчных. Значения OBJECT IDENTIFIER присваиваются при регистрации. Тип OBJECT IDENTIFIER используется для идентификации содержимого ContentInfo, алгоритмов в X.509 (AlgorithmIdentifier) и атрибутов Attribute и AttributeValueAssertion (X.501). Нотация OBJECT IDENTIFIER имеет формат. OBJECT IDENTIFIER Нотация величины OBJECT IDENTIFIER имеет вид: { [
identifier
] component1. componentn
} где identifier, identifier1, . identifiern являются идентификаторами, а value1 ., valuen - опционные целые числа. Идентификаторы без целых значений могут встретиться только для объектов, описанных в Х.208. Например, нижеприведенные величины объектных идентификаторов присвоены RSA DATA Security, Inc. { iso(1) member-body(2) 840 113549 } В таблице 4.4.13.2.4 представлены некоторые объектные идентификаторы и их значения. Таблица 4.4.13.2.4. Некоторые объектные идентификаторы и их значения
BER-кодирование OBJECT IDENTIFIER является всегда примитивным. Октеты содержимого представляют собой объединение n-1 строки октетов, где n число компонент объектного идентификатора. Каждая октетная строка несет в себе целое число по модулю 128 (старшая часть первая). 8-ой бит каждого октета, кроме последнего, равен 1. Пусть value1, ., valuen целые значения компонентов объектного идентификатора. Тогда n-1 субидентификаторов, из которых формируется октетная строка, будут иметь следующий вид.
Например, субидентификаторы объектного идентификатора RSA Data Security, Inc. равны 42 = 40╢ 1 + 2, 840, 113549 и 1. В шестнадцатеричном представлении BER-код этого объектного идентификатора имеет вид: 06 07 2A 86 48 86 F7 0D 01 DER-кодирование в данном случае совпадает с BER. Строки октетов Тип OCTET STRING служит для представления произвольных последовательностей октетов. Значение OCTET STRING может иметь любую длину, включая нуль. OCTET STRING используется для представления сообщений, включая зашифрованные, а также для типа PBEParameter. Нотация типа OCTET STRING имеет формат. OCTET STRING [SIZE ({ size | size1..size2 })] где size, size1 и size2 опционные ограничения размера. В форме OCTET STRING SIZE( size ) строка октетов должна иметь октеты size . В формате OCTET STRING SIZE( size1 .. size2 ) строка должна содержать число октетов между size1 и size2 . Например, тип PBEParameter имеет компоненту типа OCTET STRING: PBEParameter ::= SEQUENCE { Здесь размер компоненты salt всегда равен 8 октетам. BER-кодирование типа OCTET STRING может быть примитивным или конструктивным. При примитивном кодировании октеты содержимого несут в себе октеты строки с первого по последний. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок значения OCTET STRING. Например, BER-код значения OCTET STRING 01 23 45 67 89 AB CD EF может иметь один из следующих видов, в зависимости от формата октетов длины и вида кодирования (примитивное/конструктивное).
Строки печатных символов Тип PrintableString предназначен для описания произвольных последовательностей печатных символов из набора: A, B,.,Z Этот тип используется для представления атрибутов имен (Х.520). Нотация типа PrintableString имеет вид: PrintableString BER-кодирование значения PrintableString может быть примитивным или конструктивным. При примитивном кодировании печатных символов байты содержимого несут в себе строки октетов печатных ASCII-кодов. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок. Например, BER-код значения PrintableString "Test User 1" может быть представлено одним из ниже приведенных способов.
Тип SEQUENCE Тип SEQUENCE обозначает упорядоченную последовательность одного или более типов. Нотация типа SEQUENCE имеет вид: SEQUENCE { где identifier1 , ., identifiern являются опционными идентификаторами компонентов, Type1 , ., Typen - типы компонентов, а value1 ,., valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует. Например, тип Validity [X.509] относится к типу SEQUENCE и имеет два компонента. Validity ::= SEQUENCE { Здесь start и end являются идентификаторами компонент, а типом компонент служит UTCTime. BER-кодирование значения SEQUENCE является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов последовательности. Тип SEQUENCE OF Тип SEQUENCE OF обозначает упорядоченную последовательность из нуля или более компонентов данного типа, используется для имен в X.501. Нотация SEQUENCE OF имеет вид: SEQUENCE OF Type Так например, тип RNDSequence состоит из нуля или более компонент типа RelativeDistinguishedName. RNDSequence ::= SEQUENCE OF RelativeDistinguishedName BER-кодирование SEQUENCE OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов значений элементов последовательности в порядке их расположения. DER-кодирование имеет тот же формат. Тип SET Тип SET представляет собой неупорядоченное объединение из одного или более типов. Нотация типа SET имеет вид. SET { где identifier1 , ., identifiern являются опционными идентификаторами компонентов, Type1 , ., Typen - типы компонентов, а value1 ,., valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует. BER-кодирование для типа SET является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов набора. Тип SET OF Тип SET OF представляет неупорядоченный набор, состоящий из нуля или более компонентов заданного типа и предназначенный для атрибутов PKCS (Public-Key Cryptography Standard) и имен X.501. Нотация типа SET OF имеет вид: SET OF Type где Type - тип. Так тип RelativeDistinguishedName состоит из нуля или более компонентов типа AttributeValueAssertion. RelativeDistinguishedName ::= SET OF AttributeValueAssertion BER-кодирование типа SET OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов величин компонентов в порядке их исходного расположения. DER-кодирование также является всегда конструктивным, октеты содержимого представляются как и в случае BER-кодировки. Но компоненты лексикографически упорядочиваются. Тип UTCTime Тип UTCTime служит для обозначения универсального местного времени с привязкой по Гринвичу (GMT). Значение UTCTime характеризует местное время с точностью минут или секунд и временной сдвиг по отношению к GMT. Оно может иметь следующие формы: YYMMDDhhmmZ где
UTCTime используется для определения типа Validity [X.509]. Нотация типа UTCTime имеет вид. UTCTime BER-кодирование значения UTCTime может быть примитивным или конструктивным. При примитивном кодировании октеты представляют собой символы строки в виде ASCII-кодов. При конструктивном кодировании октеты образуют объединение BER-кодов последовательных субстрок. В качестве примера рассмотрим варианты представления времени 4:45:40 после полудня 6 мая 1991 года (Pacific Daylight Time) в виде величины UTCTime. "910506164540-0700" Это представление эквивалентно следующим BER-кодам: 17 0D 39 31 30 35 30 36 32 33 34 35 34 30 5A DER-кодирование типа UTCTime всегда является примитивным. Ниже приводится пример ASN.1 нотации имен типа X.501. Name ::= CHOICE { RNDSequence } RNDSequence ::= SEQUENCE OF RelativeDistinguishedName Тип Name идентифицирует объект в каталоге X.500. Name имеет тип CHOICE с одной альтернативой RNDSequence. Тип RNDSequence указывает проход по дереву каталогов X.500, начиная с корневой части. RNDSequence имеет тип SEQUENCE OF, состоящий из нуля или более компонентов RelativeDistinguishedName. Тип RelativeDistinguishedName присваивает уникальное имя объекту на дереве каталога. RelativeDistinguishedName имеет тип SET OF, состоящий из нуля или более компонентов AttributeValueAssertion. Тип AttributeValueAssertion присваивает значение атрибуту имени (например, определяющее принадлежность к стране). AttributeValueAssertion имеет тип SEQUENCE, состоящий из двух компонентов AttributeType и AttributeValue. AttributeType идентифицирует атрибут с помощью объектного идентификатора. AttributeValue присваивает значение атрибуту. Ниже предлагается пример DER-кодирования типа Name. В качестве имени использовано RSA Data Security, Inc. NOTARY (отдел Internet Privacy Enhanced Mail). (root) Каждый уровень соответствует одному значению RelativeDistinguishedName, в выбранном случае они имеют только одно значение AttributeValueAssertion. Значение AttributeType помещается до знака равенства, а AttributeValue (строка печатных символов с заданным типом атрибута) - после знака равенства. Тип атрибута DER-кодирование трех значений AttributeType согласно примитивному методу с заданной длиной дает следующие строки октетов.
Здесь countryName, organizationName и organizationalUnitName являются типами атрибутов Х.520, которые имеют следующие определения. AttributeType OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } Октеты идентификатора имеют формат с меткой, так как метка равна 6 для OBJECT IDENTIFIER. Биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, что говорит о примитивном методе кодирования. Октеты длины ориентированы на короткую форму представления. Октеты содержимого представляют собой объединения трех-октетных строк, полученных из субидентификаторов: 85 = 40x2 + 5; 4 и 6, 10 или 11. Значение атрибута DER-кодирование трех значений AttributeValue в соответствии с примитивным методом при заданной длине дает следующие строки:
Метка равна 19 (PrintableString) биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, отмечая примитивный метод кодирования. Октеты длины имеют "короткий" формат, а октеты содержимого являются ASCII-представлением значения атрибута. Атрибут ValueAssertion DER-кодирование трех значений AttributeValueAssertion в соответствии с конструктивным методом дает следующие строки октетов.
Октеты идентификатора используют короткий формат (low-octet form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют "короткому" формату, а октеты содержимого представляют собой объединение DER-кодов компонент attributeType и attributeValue. RelativeDistinguishedName</p> DER-кодирование трех значений RelativeDistinguishedName, выполняемое согласно конструктивному методу, дает следующие строки октетов. 31 0B
Октеты идентификатора используют короткий формат (low-octet form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют "короткому" формату, а октеты содержимого представляют собой объединение DER-кодов компонент AttributeValueAssertion. DER-кодирование значений RDNSequence, выполняемое согласно конструктивному методу при заданной длине, дает следующие строки октетов. 30 40 Октеты идентификатора используют короткий формат (low-octet form), так как для SEQUENCE OF метка равна 16. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют "короткому" формату, а октеты содержимого представляют собой объединение DER-кодов трех компонент RelativeDistinguishedName в порядке их следования. Name DER-кодирование значений Name выполняется аналогично значениям RDNSequence и выдает следующие результаты. 30 4013 02 55 53 13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69 13 06 4E 4F 54 41 52 59 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.13.1 Управляющая база данных MIB
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||
|
4.4.14 Протокол электронной почты SMTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||
|
Главной целью протокола simple mail transfer protocol (SMTP, RFC-821, -822) служит надежная и эффективная доставка электронных почтовых сообщений. SMTP является довольно независимой субсистемой и требует только надежного канала связи. Средой для SMTP может служить отдельная локальная сеть, система сетей или весь Интернет. SMTP базируется на следующей модели коммуникаций: в ответ на запрос пользователя почтовая программа-отправитель устанавливает двухстороннюю связь с программой-приемником (TCP, порт 25). Получателем может быть оконечный или промежуточный адресат. SMTP-команды генерируются отправителем и посылаются получателю. На каждую команду должен быть отправлен и получен отклик. Когда канал организован, отправитель посылает команду MAIL, идентифицирую себя. Если получатель готов к приему сообщения, он посылает положительное подтверждение. Далее отправитель посылает команду RCPT, идентифицируя получателя почтового сообщения. Если получатель может принять сообщение для оконечного адресата, он выдает снова положительное подтверждение (схема формирования откликов помещена в приложении 10.14). В противном случае он отвергает получение сообщения для данного адресата, но не вообще почтовой посылки. Взаимодействие с почтовым сервером возможно и в диалоговом режиме, например:
tn dxmint.cern.ch 25 (команда telnet с использованием порта 25)
250 dxmint.cern.ch hello crnvma.cern.ch, pleased to meet you (отклик 250 также является положительным)
250
221 dxmint.cern.ch closing connection (сообщение об успешном завершении процедуры) Почтовое сообщение отправлено без использования доступа к локальной почтовой программе (mail на sun, например). Следует отметить, что работа через порт 25 в данном случае открывает богатые возможности для хакеров. Вообще умелый программист может многого достичь, используя номера портов. Здесь есть над чем поработать людям, ответственным за безопасность сетей. Аналогично, не имея авторизации, можно выявить клиентов почтового сервера, используя команду VRFY:
tn ns.itep.ru 25 SMTP-отправитель и SMTP-получатель могут вести диалог с несколькими оконечными пользователями (рис. 4.4.14.1). Любое почтовое сообщение завершается специальной последовательностью символов. Если получатель успешно завершил прием и обработку почтового сообщения, он посылает положительное подтверждение. SMTP обеспечивает передачу почтового сообщения непосредственно конечному получателю, когда они соединены непосредственно. В противном случае пересылка может выполняться через одного или более промежуточных "почтовых станций".
Рис. 4.4.14.1 Схема взаимодействия различных частей почтовой системы Для решения поставленной задачи SMTP-сервер должен знать имя конечного получателя и название почтового ящика места назначения. Аргументом команды MAIL является адрес отправителя (обратный адрес). Аргументом команды RCPT служит адрес конечного получателя. Обратный адрес используется для посылки сообщения в случае ошибки. Все отклики имеют цифровые коды. Команды, отклики и имена ЭВМ не чувствительны к тому, строчные или прописные символы использованы при их написании. Это не всегда справедливо при написании имен и адресов получателя. Многие почтовые системы работают только с ASCII-символами. Если транспортный канал работает с октетами, 7-битные коды будут дополнены нулевым восьмым битом. Именно здесь коренилась проблема пересылки почтовых сообщений на русском языке несколько лет назад(русский алфавит требует 8-битового представления). Как уже было сказано, процедура отправки почтового сообщения начинается с посылки команды MAIL, которая имеет формат: MAIL где Эта команда сообщает SMTP-получателю, что стартует новая процедура и следует сбросить в исходное состояние все статусные таблицы, буферы и т.д. Если команда прошла, получатель реагирует откликом: 250 OK. Аргумент После прохождения команды MAIL посылается команда RCPT: RCPT Эта команда указывает адрес конечного получателя ( Аргумент DATA При правильном приеме этого сообщения SMTP-сервер реагирует посылкой отклика 354 Intermediate reply (промежуточный отклик), и рассматривает все последующие строки в качестве почтового текста. При получении кода конца текста отправляется отклик: 250 OK. Признаком конца почтового сообщения является точка в самом начале строки, за которой следует В некоторых случаях адрес места назначения может содержать ошибку, но получатель знает правильный адрес. Тогда возможны два варианта отклика: 1. 251 User not local; will forward to Это означает, что получатель берет на себя ответственность за доставку сообщения. Это случается, когда адресат, например, мигрировал в другую субсеть в пределах зоны действия данного почтового сервера. 2. 551 User not local; please try Получатель знает правильный адрес и предлагает отправителю переадресовать сообщение по адресу SMTP имеет команды для проверки корректности имени адресата (VRFY) и расширения списка адресов (EXPN). Обе команды в качестве аргументов используют строки символов (в некоторых реализациях эти две команды по своей функции идентичны). Для команды VRFY параметром является имя пользователя, а отклик может содержать его полное имя и адрес его почтового ящика. Реакция на команду VRFY зависит от аргумента. Так если среди клиентов почтового сервера имеется два пользователя с именем Ivanov, откликом на команду "VRFY Ivanov" будет "553 User ambiguous". В общем случае команда VRFY Ivanov может получить в качестве откликов: 250 Vasja Ivanov Ivanov@cl.itep.ru В случае пропечатки списка адресов отклик занимает несколько строк, например:
EXPN Example-People В некоторых системах аргументом команды EXPN может быть имя файла, содержащего список почтовых адресов. Основной задачей почты служит доставка сообщений в почтовый ящик адресата. Сходную форму услуги оказывают некоторые ЭВМ, доставляя сообщения на экран терминала (в рамках SMTP). Для посылки сообщений на экран терминала адресата предусмотрено три команды: 1. SEND Команда SEND требует, чтобы почтовое сообщение было доставлено на терминал. Если терминал адресата не активен в данный момент, то откликом на команду RCPT будет код 450. 2. SOML Команда Send Or MaiL (SOML) пересылает сообщение на экран адресата, если он активен, в противном случае сообщение будет уложено в его почтовый ящик. 3. SAML Команда Send And MaiL (SAML) предполагает доставку сообщение на экран терминала адресата и занесение в его почтовый ящик. Для открытия и закрытия коммуникационного канала используются команды: HELO Выражение Если SMTP-сервер обнаружит, что доставка сообщения по адресу При определенных условиях и ошибках в задании прямых и обратных адресов-маршрутов возможно зацикливание сообщений об этих ошибках. Чтобы заведомо избежать этого можно выдавать команду MAIL c нулевым обратным маршрутом: MAIL FROM:<> Если вы или ваша программа не указали обратного адреса, не следует думать, что это помешает работе почтовой программы и она не будет знать, куда посылать отклики. Ваш обратный IP-адрес указан в каждом пакете, посылаемом адресату! Некоторые другие команды, используемые в SMTP: Команда TURN используется для того, чтобы поменять местами функции программ, взаимодействовавших по телекоммуникационному каналу. Программа-отправитель становится получателем (после того как она выдаст команду TURN и получит отклик 250), а программа-получатель - отправителем. Если программа не хочет или не может поменять свою функцию, она пошлет отклик 502. Команда RESET (RSET) прерывает текущую процедуру отправки почтового сообщения. Все буферы и таблицы очищаются, получатель должен послать отклик 250 OK. Команда HELP вынуждает получателя послать справочную информацию отправителю команды HELP. Команда может содержать аргумент (имя команды). Команда не изменяет состояния таблиц или буферов. Команда NOOP не оказывает влияния на какие-либо параметры или результаты предшествующих команд, она только вынуждает получателя послать отклик 250 OK. Может использоваться для проверки работоспособности TCP-канала. Допустимо написание команд строчными или прописными символами, например: MAIL, Mail, mail, MaIl или mAIl. Для того чтобы программа SMTP-сервера была работоспособна, она должна понимать следующий минимум команд: HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT. Предельная длина имени пользователя или домена равна 64 символам. Максимальная длина |
||||||||||||||||||
|
Previous:
4.4.13.2 Нотация ASN.1
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.14.1 Протокол обмена UUCP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Этот протокол сыграл немалую роль в становлении современных телекоммуникационных технологий. Первые системы электронной почты использовали протокол UUCP (Unix-to-Unix Copy Program). Основополагающие идеи ОС UNIX расширили область взаимодействия вычислительных и управляющих процессов за рамки центрального процессора ЭВМ. Хотя большинство современных почтовых серверов базируется на протоколе SMTP, протокол UUCP продолжает применяться во многих приложениях, использующих ОС UNIX (см. www.isf.ru/~stas/doc/uucp-1.06/uucp_7.html). Современные программные пакеты UUCP поддерживают приоритеты для всех команд, которые варьируются от a (наивысший) до z и далее a-z. В UNIX эти коды приоритетов вставляются в имена командных файлов, создаваемых UUCP или UUX. Имя командного файла обычно имеет вид: c.nnnngssss, где g - код приоритета (от слова grade), nnnn - имя удаленной системы, а ssss - четырех символьный номер. Например, командный файл создаваемый системой sun2 с уровнем приоритета d может иметь имя c.sun2d1111. При этом в имени удаленной системы сохраняется лишь 7 символов, чтобы обеспечить совместимость с 14-символьным ограничением для имен файлов.
UUCP-протокол определяет взаимодействие между двумя программами. Этот диалог включает в себя три этапа: установление канала, последовательность запросов пересылки файлов и закрытие канала. Прежде чем начать диалог, инициатор обмена должен авторизоваться в ЭВМ, с которой планируется обмен, и активизировать тамошнюю систему UUCP. На рисунке инициатор обмена назван клиентом (в литературе можно также встретить также название master). Все сообщения начинаются с символа ^p (восьмеричный код '\020') и завершаются нулевым байтом (\000). В некоторых системах для завершения сообщений используется код перевода строки (\012). Установление канала инициируется сервером, который посылает сообщение \020shere=hostname\000, где hostname - имя ЭВМ сервера. В устаревших пакетах uucp можно встретить инициирующие сообщения вида \020shere\000. Клиент должен откликнуться сообщением \020shostname options\000, где hostname соответствует имени клиента (инициатора обмена). При этом допустимы следующие опции (опции могут и отсутствовать).
На запрос \020rok\000 возможно несколько откликов:
Если отклик не rok, то обе стороны прерывают сессию. Запрос сервера \020pprotocols\000, где protocols характеризует список поддерживаемых протоколов, причем каждому протоколу соответствует лишь один символ. Клиент может послать сообщение \020uprotocols\000, где инициатор сессии выбирает протокол из предлагаемого сервером списка. Если в предлагаемом списке нет нужного протокола, посылается сообщение \020un\000 и обе стороны разрывают сессию. Когда канал сформирован и определены его параметры, может начаться обмен командами. Если в процессе обмена командами выявляется ошибка, участники обмена переходят к диалогу для закрытия канала. Клиент может послать команды: s, r, x, e, или h (команды посылает только клиент). В качестве параметров этих команд используются имена файлов. Это могут быть абсолютные имена файлов, начинающиеся с символа /, файлы из публичного каталога с именами, которые начинаются с символов ~/, файлы из каталога пользователя, начинающиеся с строки ~user/, или файлы из временного буфера (spool). Собственно имена начинаются с c. для командных файлов, с d. для файлов данных, или с x. для исполнительных файлов. Команда клиента s, предназначенная для посылки файлов серверу, имеет формат: s from to user -options temp mode notify size. Параметр from представляет собой имя посылаемого файла, to - имя файла на сервере, куда будет скопирован файл, user - имя пользователя, инициировавшего пересылку файла, options - список опций, управляющих обменом, temp - имя пересылаемого файла в случае использования опции С. После успешного завершения обмена сервер стирает файл temp. Параметр mode задает разновидность файла на сервере. Если файл не из каталога spool, клиент создает его с mode=0666. Параметр notify может отсутствовать, он имеет смысл лишь при наличии опции n. В этом случае при успешном завершении обмена посылается уведомление через электронную почту по адресу notify. Поле size задает размер файла в байтах.
Сервер может откликнуться на s-команду следующими способами.
Последние три отклика сервера называются С-командами. При получении С-команды клиент может послать новую команду-запрос. Такой командой может быть r-команда, которая имеет следующий формат. r from to user -options size Это запрос клиента на получение файла от сервера. Параметр from - имя файла на сервере. Это не может быть spool-файл, имя не может иметь символов подмены (wildcard). Параметр to - имя файла, который должен появиться у клиента, user - имя пользователя, инициировавшего обмен, options - список опций, контролирующих обмен, size - определяет максимальный размер файла, который может принять клиент. Допускаются следующие опции.
Сервер может прислать следующие отклики на r-команду.
По завершении обмена клиент может послать следующие команды (сервер их может проигнорировать). cy файл благополучно передан; cn5 временный файл не может быть перемещен в окончательную позицию. Клиент может использовать команду x для запуска uucp на сервере. Команда может иметь формат x from to user -options. Параметр from - имя файла (или файлов) на ЭВМ-сервере, пересылку которого затребовал клиент. Команда может служить для пересылки файлов из сервера посторонней третьей системе. Параметр to является именем файла или каталога, куда будут перенесен файл (или файлы). Например, если клиент хочет получить файлы сам, можно использовать запись master!path. Сервер может прислать следующие отклики на команду x. xy запрос принят, соответствующие команды пересылки файлов поставлены в очередь для последующего исполнения. xn Запрос отклонен (причина отклонения не сообщается, может быть сервер не поддерживает Х-запросы). Клиент может послать команду Е, которая имеет следующий формат: e from to user -options temp mode notify size command Е-команда поддерживается системой taylor uucp и служит для реализации запросов исполнения без использования файлов x.*. Эта команда применяется в случае, когда исполняемая команда требует входного файла, который используется ей в качестве стандартного ввода. Основные параметры команды имеют то же значение, что и в случае команды s. Список опций, управляющих обменом, представлен в таблице.
В поле command записывается команда, которая должна быть исполнена. Это эквивалентно команде c файла Х.*. Отклики сервера на Е-команду эквивалентны откликам на команду s, только начальное s заменяется на Е. Для переведения соединения в пассивное состояние клиент может использовать h-команду (не имеет параметров или опций). Сервер реагирует на нее h-откликом.
Если обмен завершен и клиент не намерен выдавать какие-либо запросы, связь прерывается. Клиент посылает сообщение \020ОООООО\000, на что сервер откликается посылкой строки \02ООООООО\000 (6 символов 'О' в первом и 7 - во втором случае). Какой-либо смысловой нагрузки этот обмен не несет, по этой причине некоторые пакеты его не производят. В рамках UUCP предусмотрено несколько вспомогательных протоколов. g-протокол предназначен для коррекции ошибок и поддерживается всеми версиями UUCP. Стандартная ширина окна в этом протоколе равна 3, а размер пакета 64 байтам, но в принципе предусмотрена возможность расширения окна при реализации потоков до 7 при размере пакетов 4096 байт. Протокол базируется на стандартных пакетных драйверах. Для реализации g-протокола используются пакеты с 6-байтовыми заголовками (управляющие пакеты содержат только заголовок). Формат этих пакетов представлен на рис. 4.4.14.1.1.
Рис. 4.4.14.1. Формат пакетов g-протокола Пакет начинается с восьмеричного кода 020, далее следует поле k (1 ё k ё 9). Для управляющих пакетов k=9. Для информационных пакетов k определяет размер поля данных. k=1 соответствует 32 байтам данных, а k=9 - 4096 байтам. Далее следуют два байта контрольной суммы, контрольный байт, определяющий тип пакета, и xor-байт. Последний равен результату операции xor для полей k, младшего байта контрольной суммы, старшего байта контрольной суммы и контрольного байта. Этот байт служит для контроля целостности заголовка пакета. Управляющий байт заголовка содержит в себе три субполя (ttxxxyyy). Поле tt может принимать следующие значения.
Пусть длина поля данных, заданная k, равна 1, пусть также первый байт поля данных равен b1. Если b1 меньше 128, тогда истинное число байт в поле данных равно 1 - b1, начиная со второго байта. Если b1Ё 128 и второй байт поля данных b2, то истинное число байт в поле данных равно 1 - ((b1 & 0x7f) + (b2 << 7)), начиная с третьего байта. Контрольная сумма вычисляется для всех байтов поля данных. Один байт данных пересылается в любом случае. Для всех типов информационных пакетов поле ххх определяет порядковый номер пакета, а поле yyy определяет номер последнего пакета, принятого без ошибки, что и определяет максимальный размер окна, равный 7. Каждая из сторон, участвующих в обмене, использует окно, чтобы регистрировать число пакетов, которое может быть послано без получения подтверждения. Размер этого окна может лежать в пределах 1-7. Пакеты посылаются строго по очереди, получение всех пакетов должно быть подтверждено в том порядке, в каком они были посланы. В пакетах управления поле ххх может принимать следующие значения:
Контрольная сумма управляющего пакета равна 0хаааа - с, где с - контрольный байт заголовка. Контрольная сумма информационного пакета равна 0хаааа - (check ^ c), где ^ обозначает операцию исключающее ИЛИ, а check результат работы программы, приведенной ниже и обрабатывающей поле данных. Исходными параметрами для этой программы является указатель на начало блока данных z и число байтов в блоке c. Intigchecksum (z, c)
ichk2 += ichk1 ^ c; /* if the character was zero, or adding it to ichk1 caused an overflow, xor ichk2 to ichk1. */
Когда g-протокол запускается в работу, посылается управляющий пакет INITA с кодом желательного значения максимального размера окна. Сервер откликается пакетом INITA со своим предложением размера окна. После этого аналогичный обмен производится пакетами INITB и INITC. В результате каждая из сторон может использовать свой размер окна и длину посылаемых пакетов. Когда UUCP выдает команду, посылается один или более пакетов. В конце команды всегда посылается нулевой байт, который указывает на завершение командной строки. Когда пересылается файл, его завершение отмечается коротким информационным пакетом, содержащим нули. Прекращение работы протокола осуществляется посылкой управляющего пакета close. f-протокол. Этот протокол предназначен для пересылки 7-битных текстовых файлов. Здесь используются только символы от \040 (пробел) до \176 (~) и возврат каретки. Протокол весьма не эффективен для транспортировки 8-битовых данных. Его система контрольного суммирования не слишком надежна для больших файлов. Первоначально этот протокол предназначался для работы в сетях Х.25. В f-протоколе не предусмотрена процедура инициализации. При пересылке команды передается строка, завершающаяся символом возврат каретки. В процессе передачи файлов каждый байт b преобразуется в соответствии с таблицей.
Таким образом, байты между \040 и \171 включительно передаются без изменений, остальные перед отправкой преобразуются. Когда файл данных переслан, посылается 7-байтовая последовательность, включающая в себя два байта \176, за которыми следует 4 ASCII байта контрольной суммы (в шестнадцатеричном формате) и символ возврата каретки. Если контрольная сумма равна 0x1a2b, то будет послана последовательность \176\1761a2b\r. При вычислении контрольной суммы туда сначала заносится код 0xffff. Для вычисления контрольной суммы (ichk) используется следующая программа, которая выполняется перед отправкой каждого байта. /* rotate the checksum left. */
Принимающая файл сторона также вычисляет контрольную сумму данных и сравнивает ее с полученной по каналу. По результату этого сравнения передающей стороне посылается одно-символьный отклик, за которым следует код возврата каретки.
t-протокол. Протокол предназначен для каналов, обеспечивающих надежную связь по схеме точка-точка (аналог TCP) для 8-битных данных. При посылке команды сначала определяется ее длина с. Затем посылается (с/512 +1)*512 байт, которые включают в себя строку команды и соответствующее число нулевых байтов. При пересылке файлов обмен идет блоками по 1024 байта. Каждый блок начинается с 4 байтов, характеризующих объем данных в блоке (формат аналогичен используемому UNIX-утилитой htonl). В конце файла передается блок нулевых байтов. e-протокол. Протокол подобен t-протоколу. Но здесь нет управления потоком и контроля ошибок. При посылке команды передается командная строка, завершающаяся нулевым байтом. При пересылке файла сначала посылается код его размера в виде ASCII десятичных цифр. Эта строка дополняется до 20 символов нулевыми байтами. Так, если длина файла 40000 байт, сначала посылается последовательность 40000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, после чего посылается собственно файл. G-протокол. Протокол используется SVR4 UUCP. Он идентичен G-протоколу за исключением того, что можно модифицировать окно и размер пакетов. В SVR4 реализации G-протокола размер окна всегда равен 7 а длина пакета 64 байтам. \i-протокол. Протокол написан Яном Лансом Тейлором и использован в taylor UUCP. Это протокол пересылки данных со скользящим окном, подобно G-протоколу. Но в отличие от этого протокола i-протокол поддерживает обмен данными в двух направлениях одновременно. Пакеты в этом протоколе имеют 6-байтовый заголовок. За полем данных следует 4-байтовая контрольная сумма. Определено 5 типов пакетов: DATA, SYNC, ACK, NAK, SPOS и CLOSE. Все они могут содержать поле данных. Пакеты типа DATA, SPOS и CLOSE имеют порядковые номера. Каждая из сторон нумерует пакеты независимо по модулю 32. Каждый из пакетов характеризуется локальным и удаленным номерами каналов. Каждому типу команд в локальной системе ставится в соответствие ненулевой локальный номер канала. Аналогичное правило справедливо и для удаленной системы. Это позволяет решить проблему одновременного двухстороннего информационного обмена. Для каждого файла протокол формирует указатель, в исходный момент равный нулю. После получения очередного пакета указатель соответствующим образом инкрементируется. Исключение представляют пакеты типа spos, которые служат для изменения указателя файла. Формат пакета i-протокола представлен на рис. 4.4.14.1.2.
Рис. 4.4.14.1.2. Формат пакета i -протокола Заголовок начинается с флага ^g (восьмеричный код \007), далее следует 5-битовое поле пакет. Пакеты DATA, SPOS и CLOSE используют это поле для номера пакета. В пакетах NAK сюда заносится номер пакета, подлежащий повторной пересылке. В пакетах же ACK и SYNC это поле заполняется нулями. Поле ACK содержит 5 бит и служит для записи номера последнего пакета, принятого без ошибки. Это поле используется всеми типами пакетов. В трехбитовое поле тип определяет назначение пакета и может принимать следующие значения.
Однобитовое поле d =1 для пакетов клиента и =0 для пакетов сервера. Поле длины поля данных состоит из двух секций (полный байт содержит младшую часть), имеет суммарную протяженность 12 бит, что позволяет варьировать поле данных в пределах от 0 до 4095 байт. Однобайтовое поле контрольная сумма содержит код, который представляет собой результат операции XOR, выполненной для байт заголовка, начиная со второго по пятый. После заголовка следует поле данных, за которым помещается 32-разрядная контрольная сумма информационного поля (CRC). При инициализации i-протокола стороны обмениваются SYNC-пакетами, которые содержат по крайней мере 3 байта. Первые два байта несут в себе максимальный размер пакетов, посылаемых удаленной стороной (старший байт первый). Третий байт определяет размер окна, используемый удаленной стороной. При этом могут посылаться пакеты любого размера, но не больше указанного максимального. Если SYNC содержит четвертый байт, то он хранит в себе номер канала (1-7), который может использовать удаленная система. Размер окна определяет число пакетов, которое может быть послано, не дожидаясь подтверждения получения. Подтверждаться может не каждый пакет. Если получено подтверждение получения пакета n, все предшествующие считаются полученными корректно. Если потерян пакет, посланный одной из сторон, другая может передавать пакеты, как ни в чем не бывало. Команды посылаются в виде последовательности информационных пакетов с ненулевым полем номера локального канала. Последний из пакетов в этом случае должен содержать нулевой байт в конце (обычно команда укладывается в один пакет). Файла передаются в виде последовательности пакетов, завершающейся пакетом нулевой длины. При получении отклика sn пересылка файла абортируется. Применение номеров каналов позволяет посылать команды и пересылать файлы одновременно. j-протокол. Этот протокол является разновидностью i-протокола написанного тем же автором. Протокол предназначен для коммуникационных каналов с возможностью перехвата некоторых символов, например xon или xoff. Протокол не выполняет детектирования или исправления ошибок. При инициализации j-протокола системы обмениваются последовательностями печатных ascii-символов, чтобы указать, какие из них стороны хотят исключить из употребления. Такая последовательность должна начинаться с символа ^ (восьмеричный код 136) и завершаться символом ~ (восьмеричный код 176). После отправления такой строки система ждет аналогичной посылки с противоположной стороны. Строки состоят из esc-последовательностей типа \ooo, где o - восьмеричная цифра. Например, посылка последовательности ^\021\023~ означает, что следует избегать символов xon и xoff. Блокировка использования символов из диапазона \040 - \176 запрещена. После указанного обмена включается стандартный i-протокол, но пакеты i-протокола вкладываются в j-пакеты. Заголовок j-пакетов содержит 7 байт. Формат заголовка пакета j-протокола показан на рис. 4.4.14.1.3.
Рис. 4.4.14.1.3. Формат заголовка j-пакета Заголовок начинается с кода символа ^. Далее следует два байта поля длина (первый из них старший), которые характеризуют полную длину пакета в байтах. Запись в этом поле осуществляется в виде ascii-символов. Истинная длина пакета вычисляется согласно формуле: (l1 - 040)*0100 + (l2 - 040), где 040 ё l1 < 0177 и 040 ё l2 < 0140. После поля длина следует байт 075 (символ =), за которым следует два байта длины поля данных (равна размеру вложенного i-пакета в октетах). Заголовок завершается символом @ (восьмеричный код 0100). Все символы, запрещенные к использованию при инициализации, в случае их наличия в i-пакете подменяются печатными ASCII-символами. При этом для каждой такой подмены вводится два индексных байта (index-h и index_l). Индексные байты непосредственно следуют за байтами данных. В индексных байтах закодировано положение "запретного" символа в i-пакете. Преобразование запретных символов производится следующим образом. Если код символа больше или равно 0200, из него вычитается 0200, если при этом результат меньше 020 или равен 0177, над ним производится операция xor 020. Индексные байты представляют собой ASCII-символы. Истинное положение запретного символа вычисляется по формуле: (index-h - 040) * 040 + (index_l - 040). Значение index_l должно лежать в пределах 040 ё index_l < 0100, а index-h - 040 ё index-h < 0176. x-протокол. Протокол ориентирован на машины со встроенными картами Х.25 и предназначен для непосредственной пересылки 8-битовых данных без взаимодействия со слоями Х.28 или Х.29. Пересылка осуществляется 512 байтными пакетами. y-протокол. Протокол разработан Йоргом Квиком и используется в FX uucico. Протокол осуществляет контроль и коррекцию ошибок, он предназначен для передачи 8-битовых данных в поточном режиме. Здесь не предусмотрено подтверждения получения пакетов, по этой причине протокол удобен для полудуплексных каналов. Каждый пакет имеет 6-байтовый заголовок. Формат заголовка для y-пакетов показан на рис. 4.4.14.1.4.
Рис. 4.4.14.1.4. Формат заголовка для y-пакетов Первое поле номер содержит два байта номера пакета, причем первый из байтов является младшей частью номера (это справедливо и для других полей заголовка). Нумерация начинается с нуля. Так как первый пакет всегда SYNC, информационные пакеты имеют номера, начиная с 1. Каждая из систем, участвующих в обмене, нумеруют пакеты независимо. Если старший бит 16-битового поля длины равен нулю, то в этом поле записано число байт в поле данных, следующем за заголовком. Если же старший бит равен 1, то данных в пакете нет, а сам он является управляющим пакетом. В этом случае поле длина определяет тип пакета. Содержимое двухбайтового поля контрольная сумма вычисляется по программе, приведенной в описании протокола f. Для пакетов, не содержащих данных, контрольная сумма равна нулю. Инициализация протокола начинается с того, что стороны обмениваются SYNC-пакетами. SYNC-пакет должен содержать по меньшей мере 4 байта данных. Первый из них содержит код версии протокола. Далее следует байт длины пакета, которая измеряется в блоках по 256 байт (максимальный размер поля данных 32768 байт, что соответствует коду длины 128). Завершается блок данных пакета SYNC двумя байтами флагов. В настоящее время их функции не определены и их следует обнулять. Определены следующие типы управляющих пакетов.
Если получен управляющий пакет, отличный от 'YPKT_ACK', соединение обрывается (это же делается при обнаружении других ошибок). Команда в y-протоколе представляет собой последовательность пакетов, завершающаяся нулевым байтом. Конец передачи файла отмечается посылкой пакета с нулем в поле длина. Существуют также d-, h- и v-протоколы UUCP, но они не имеют заметного применения. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.14 Протокол электронной почты SMTP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
4.4.14.2 Почтовый протокол POP3
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
В некоторых небольших узлах Интернет бывает непрактично поддерживать систему передачи сообщений (MTS - Message Transport System). Рабочая станция может не иметь достаточных ресурсов для обеспечения непрерывной работы SMTP-сервера [RFC-821]. Для "домашних ЭВМ" слишком дорого поддерживать связь с Интернет круглые сутки. Но доступ к электронной почте необходим как для таких малых узлов, так и индивидуальных ЭВМ. Для решения этой проблемы разработан протокол POP3 (Post Office Protocol - Version 3, STD: 53. M. Rose, RFC-1939). Этот протокол обеспечивает доступ узла к базовому почтовому серверу. POP3 не ставит целью предоставление широкого списка манипуляций с почтой, он лишь получает и стирает почтовые сообщения. Более продвинутый и сложный протокол IMAP4 обсуждается в RFC-2060 (порт 143). Об аутентификации в POP3 можно прочесть в документе RFC-1734. В дальнейшем ЭВМ-клиентом будет называться машина, пользующаяся услугами POP3, а ЭВМ-сервером - сторона, предлагающая услуги POP3. Когда пользователь ЭВМ-клиента хочет послать сообщение, он устанавливает SMTP связь с почтовым сервером непосредственно и посылает все, что нужно через него. При этом ЭВМ POP3-сервер не обязательно является почтовым сервером. В исходный момент ЭВМ POP3-сервер прослушивает TCP-порт 110. Если ЭВМ-клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (см. также RFC-1734, -1957). После этого может производиться обмен командами и откликами. Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов CRLF. Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов. Сигнал отклика в POP3 содержит индикатор состояния и ключевое слово, за которым может следовать дополнительная информация. Отклик также завершается кодовой последовательностью CRLF. Длина отклика не превышает 512 символов, включая CRLF. Существует два индикатора состояния: положительный - "+OK" и отрицательный "-ERR" (все символы прописные). Отклики на некоторые команды могут содержать несколько строк. В этом случае последняя строка содержит код завершения 046 ("."), за которым следует CRLF. На практике многострочные отклики для исключения имитации завершаются последовательностью CRLF.CRLF. В процессе авторизации клиент должен представить себя серверу, передав имя и пароль (возможен вариант посылки команды APOP). Если авторизация успешно завершена, сессия переходит в состояние транзакции (TRANSACTION). При получении от клиента команды QUIT сессия переходит в состояние UPDATE, при этом все ресурсы освобождаются и TCP связь разрывается. На синтаксически неузнанные и неверные команды, сервер реагирует, посылая отрицательный индикатор состояния. POP3 сервер может быть снабжен таймером пассивного состояния (10 мин.), который осуществляет автоматическое прерывание сессии. Приход любой команды со стороны клиента сбрасывает этот таймер в нуль. Сервер нумерует все передаваемые сообщения из своего почтового ящика и определяет их длину. Положительный отклик начинается с +OK, за ним следует пробел, номер сообщения, еще один пробел и длина сообщения в октетах. Завершается отклик последовательностью CRLF. Переданные сообщения удаляются из почтового ящика сервера. Все сообщения, передаваемые во время сессии POP3 должны следовать рекомендациям формата Интернет сообщений [RFC822]. В состоянии транзакции клиент может посылать серверу последовательность POP3 команд, на каждую из которых сервер должен послать отклик. Далее следует краткое описание команд, используемых в состоянии транзакция. LIST [сообщение] Аргументы: номер сообщения (опционно), который не может относиться к сообщению, помеченному как удаленное. Команда может быть выдана только в режиме TRANSACTION. При наличии аргумента сервер выдает положительный отклик, содержащий информационную строку сообщения. Такая строка называется скэн-листингом сообщения (scan listing). scan listing состоит из номера сообщения, за которым следует пробел и число октетов в сообщении. Сообщения, помеченные как удаленные, не пересылаются. Примером отрицательного отклика может служить: -ERR no such message. Примеры использования команды LIST: Клиент выдает команду: LIST STAT - аргументов не использует, возможный отклик +OK nn mm, где nn - номер сообщения, а mm - его длина в байтах. Пример использования: К: STAT QUIT - аргументов не использует, возможный отклик +OK. Сервер POP3 удаляет все сообщения, помеченные как удаленные из почтового ящика, посылает соответствующий отклик и разрывает TCP связь. Пример: К: QUIT RETR msg (msg - номер сообщения) Если POP3-сервер выдал положительный отклик, то за начальным +OK следует сообщение с номером, указанным в аргументе. Отрицательный отклик имеет вид -ERR no such message. Пример использования команды: К: RETR 1 DELE msg (msg - номер сообщения) Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. При этом само сообщение не удаляется пока сессия не войдет в режим UPDATE. Пример использования команды: К: DELE 1 NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик. RSET (не использует каких-либо аргументов) Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик. Например: К: RSET С: +OK maildrop has 2 messages (320 octets) Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика. Далее следует описание команд, используемых в состоянии UPDATE. Ряд команд не входят в перечень обязательных (являются опционными). TOP msg n, где msg - номер сообщения, а n - число строк (используется только в режиме TRANSACTION). При положительном отклике на команду TOP сервер посылает заголовки сообщений и вслед за ними n строк их текста. Если n больше числа строк в сообщении, посылается все сообщение. UIDL [msg], где msg - номер сообщения является опционным (Unique-ID Listing). Если сервер выдаст положительный отклик, будет выдана строка, содержащая информацию о данном сообщении. Эта строка называется уникальным идентификатором сообщения ("unique-id listing"). При отсутствии аргумента аналогичная информация выдается для каждого из сообщений в почтовом ящике. Уникальный идентификатор сообщения состоит из 1-70 символов в диапазоне от 0x21 до 0x7E. Сообщения в почтовом ящике должны характеризоваться различными идентификаторами. Пример использования команды: К: UIDL USER name, где name - характеризует почтовый ящик сервера. Команда используется на фазе авторизации или после неудачного завершения команд USER или PASS. При авторизации клиент должен сначала послать команду USER и лишь после получения положительного отклика команду PASS. Команда может вызвать следующие отклики: +OK name is a valid mailbox К: USER frated PASS string (string - пароль для доступа к почтовому серверу) Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику. На команду PASS возможны следующие отклики: +OK maildrop locked and ready APOP name digest, где name - идентификатор почтового ящика, а digest - дайджест сообщения - MD5 (RFC-1828). Команда используется только на стадии авторизации. Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в [RFC822] и должны быть уникальными для всех заголовков уведомлений. Так для UNIX-приложений синтаксис временной метки должен иметь вид:
где `process-ID' представляет собой десятичное значение PID процесса, clock - десятичное показание системных часов, а hostname - полное имя домена, где размещен сервер POP3. Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр `name' семантически идентичен параметру `name' команды USER. Параметр `digest' вычисляется с использованием алгоритма MD5 [RFC1321] для строки, состоящей из временной метки (включая угловые скобки) за которой следует строка пароля, которая известна только клиенту и серверу. Параметр `digest' содержит 16 октетов, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII символов. Сервер, получив команду APOP, проверяет принятый дайджест и если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик и состояние сессии не изменяется. С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но не в коем случае оба метода попеременно. Сервер перед закрытием канала по команде QUIT должен удалить из почтового ящика все сообщения, которые были перенесены с помощью команд RETR. Предполагается, что все сообщения, передаваемые в ходе сессии POP3, имеют текстовый формат Интернет в соответствии с документом [RFC822]. |
|
Previous:
4.4.14.1 Протокол обмена UUCP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.14.3 Протокол Интернет для работы с сообщениями IMAP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол IMAP 4.1 (INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1, V.Crispin, RFC-2060, December 1996) базируется на транспортном протоколе TCP и использует порт 143. Протокол IMAP представляет собой альтернативу POP-3. Также как и последний он работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками. 1.Команды и отклики Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка. 1.1 Протокольный отправитель клиента и протокольный получатель сервера Любая процедура начинается с команды клиента. Любая команда клиента начинается с префикса-идентификатора (обычно короткая буквенно-цифровая строка, например A0001, A0002 и т.д.), называемого меткой (tag). Для каждой команды клиент генерирует свою метку. Имеется два случая, когда строка, посланная клиентом, не представляет собой законченную команду. В первом - аргумент команды снабжается кодом, определяющим число октетов в строке (см. описание литеральных строк в разделе "Форматы данных"). Во втором - аргументы команды требуют отклика со стороны сервера (см. описание команды authenticate). В обоих вариантах сервер посылает запрос продолжения команды, если он готов. Такой отклик сервера начинается с символа "+". Замечание: Если, вместо этого, сервер детектирует ошибку в команде, посылается отклик завершения bad с меткой, требующей игнорирования команды и предотвращения посылки клиентом каких-либо еще запросов. Отправитель может послать отклик завершения и в случае некоторых других команд (если одновременно исполняется несколько команд) или если данные не имеют меток. В любом случае, ожидается запрос продолжения, клиент предпринимает в ответ соответствующие действия и читает следующий отклик сервера. Во всех вариантах клиент должен завершить отправку одной команды прежде чем послать новую. Протокольный приемник IMAP 4.1 сервера читает строку команды, пришедшей от клиента, осуществляет ее разбор, выделяет ее параметры и передает серверу данные. По завершении команды сервер посылает отклик. 1.2 Протокольный отправитель сервера и протокольный получатель клиента Данные, передаваемые сервером клиенту, а также статусные отклики, которые не указывают на завершение выполнения команды, имеют префикс "*" и называются непомеченными откликами. Данные сервера могут быть посланы в ответ на команду клиента или отправлены сервером по своей инициативе. Формат данных не зависит от причины посылки. Отклик указывает на успешное выполнение операции или на ее неудачу. Отклик использует ту же метку, что и команда клиента, запустившая процедуру. Таким образом, если осуществляется более чем одна команда, метка сервера указывает на команду, вызвавшую данный отклик. Имеется три вида отклика завершения сервера: ok (указывает на успешное выполнение), no (отмечает неуспех) или bad (указывает на протокольную ошибку, например, не узнана команда или зафиксирована синтаксическая ошибка). Протокольный приемник клиента IMAP 4.1 читает строку отклика от сервера. Он должен предпринять действия, в соответствии с первым символом метки "*" или "+". Клиент должен быть готов принять любой отклик сервера в любое время. Это касается и не запрошенных данных, присланных сервером. Данные сервера должны быть записаны так, чтобы клиент мог их непосредственно использовать, не посылая серверу уточняющих запросов. Каждое сообщение имеет несколько связанных с ним атрибутов. Эти атрибуты могут быть определены индивидуально или совместно с другими атрибутами. Доступ к сообщениям в IMAP 4.1 осуществляется с помощью уникального идентификатора или порядкового номера сообщения. 1.3 Атрибут сообщения UID Каждому сообщению ставится в соответствие 32-битовый код, который при использовании совместно с уникальным идентификатором образует 64-битовую последовательность, гарантирующую однозначную идентификацию сообщения в почтовом ящике. Сообщения, приходящие позднее имеют больший код UID, чем полученные ранее. В отличие от порядкового номера сообщения, уникальные идентификаторы не образуют упорядоченной последовательности, но они работают и за пределами текущей сессии. Это позволяет осуществлять ссылки на сообщение в случае обрыва сессии [IMAP-DISC]. UID ассоциируется с почтовым ящиком и посылается в виде кода uidvalidity отклика (ok) на фазе выбора почтового ящика. Если UID из предыдущей сессии по какой-то причине не может быть использован, UID должен быть инкрементирован. Замечание: UID для данного почтового ящика должен всегда изменяться монотонно. Если порядок записей изменен вне рамок IMAP, необходимо перегенерировать UID для данного почтового ящика, так как порядок старых значений UID в этом случае уже не будет монотонным. Еще одной причиной не сохранения UID может служить стирание старого и создание нового почтового ящика с тем же именем. Так как имя почтового ящика не изменилось, клиент может не знать об этом и пытаться использовать старые UID. Хорошим значением UID можно считать 32-битное представление даты и времени создания почтового ящика. Вполне приемлемо и значение 1, если имеется гарантия, что это значение никогда не будет использовано повторно, даже в случае стирания и создания нового почтового ящика с тем же именем. UID сообщения не должно изменяться в пределах сессии, его не следует изменять и от сессии к сессии. Однако если невозможно сохранить UID сообщения в последующей сессии, каждая следующая сессия должна иметь новый уникальный код идентификатора, который больше чем любой UID использованный ранее. Атрибут порядкового номера сообщения Этот атрибут определяет порядковый номер сообщения в почтовом ящике, начиная с 1. Последующее сообщение всегда имеет значение этого атрибута на 1 большее, чем у предшествующего. Допускается изменение порядкового номера сообщения на протяжении сессии. Например, когда сообщение удаляется из почтового ящика, номера всех последующих сообщений изменяются. Аналогично, новому сообщению может быть присвоен номер удаленного сообщения. Номера сообщений могут использоваться при вычислениях, касающихся указателей. Например, если сообщение 287 в почтовом ящике, содержащем 523 сообщения, имеет UID 12345, имеется 286 сообщений, имеющих меньшее значение UID и 236 сообщений с большими UID. 1.4 Атрибут флагов сообщения Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путем его добавления к этому списку и обнуляется путем его удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть постоянным или действующим только на время данной сессии. Системным флагом является флаг, чье имя определено в данной спецификации. Все системные флаги начинаются с символа "\". Некоторые системные флаги (\deleted и \seen) имеют специальную семантику, заданную вне рамок данного документа. В настоящее время определены следующие системные флаги:
Если невозможно определить, является ли эта сессия первой для данного сообщения, его следует считать относящимся к текущей сессии. Ключевое слово определяется реализацией сервера. Ключевые слова не начинаются с символа "\". Серверы могут позволять клиенту создавать новые ключевые слова в почтовом ящике. Постоянные флаги клиент может устанавливать для данного сообщения или удалять на постоянной основе; таким образом, последующая сессия может воспользоваться новыми значениями флагов. Замечание: Системный флаг \recent имеет статус флага сессии. Флаг \recent не может использоваться в качестве аргумента команды store, и по этой причине не может быть изменен вообще. Внутренняя дата и время сообщения на сервере. Это не та дата и время, которые указаны в заголовке [RFC-822], а время и дата получения сообщения. В случае доставки сообщения посредством протокола [SMTP], это должна быть дата и время доставки конечному адресату. В случае сообщений, доставленных командой IMAP 4.1 copy, это должны быть внутренняя дата и время отправителя сообщения. В случае доставки сообщения командой IMAP 4.1 append, это должна быть дата и время, заданные в описании команды append. Атрибут размера сообщения определяет число октетов в сообщении (рассмотрен в документе [RFC-822]). Атрибут структуры конверта сообщения соответствует требованиям документа [RFC-822]. Атрибут структуры тела сообщения несет в себе информацию о структуре сообщения в соответствии с регламентациями [MIME-IMB]. Кроме доставки текстового сообщения, как это описано в RFC-822, IMAP 4.1 позволяет осуществлять передачу части текста. Можно отдельно доставить заголовок и тело сообщения или даже часть тела сообщения. 2. Состояние и диаграмма исполнения Сервер IMAP 4.1 находится в одном из четырех состояний. Большинство команд допустимо только во вполне определенных состояниях. Если клиент пытается реализовать команду в неправильном состоянии, это рассматривается как протокольная ошибка. В этом случае сервер откликнется командой bad или no в зависимости от реализации конкретной программы. В состоянии без аутентификации клиент должен предоставить имя и пароль, прежде чем станет доступно большинство команд. Переход в это состояние производится при установлении соединения, если только для данного соединения не была проведена предварительная аутентификация. В состоянии аутентификации клиент идентифицирован и должен выбрать почтовый ящик, прежде чем ему станут доступны команды для работы с сообщениями. Переход в это состояние происходит при установлении соединение с предварительной аутентификацией, когда выданы все необходимые идентификационные данные или при ошибочном выборе почтового ящика. В состояние выбора система попадает, когда успешно осуществлен выбор почтового ящика. В состояние выхода система попадает при прерывании соединения в результате запроса клиента или вследствие независимого решения сервера.
Рис. 4.4.14.2.1. Схема состояний для протокола IMAP (1) Cоединение без предварительной аутентификации (отклик OK) 3. Формат данных IMAP 4.1 использует текстовые команды и отклики. Данные в IMAP 4.1 могут иметь одну из следующих форм: атом, число, строка, список, заключенный в скобки или NIL. Атом состоит из одного или более неспециализированных символов. Число состоит из одной или более цифр и характеризует некоторое числовое значение. Строка может иметь одну из двух форм: литерал или строка в кавычках. Литеральная форма является основной формой строки. Строка в кавычках является альтернативной формой, исключающей избыточность литеральной формы за счет ограничений, налагаемых на символы, используемые в строке. Литерал представляет собой нуль или более октетов (включая CR и LF). Литерал начинается с октета, где хранится число символов. Этот октет заключается в фигурные скобки, за которыми следует последовательность CRLF. В случае передачи литералов от сервера к клиенту за CRLF следуют непосредственно данные. При передаче литералов от клиента серверу клиент должен подождать прихода команды продолжения, прежде чем начать пересылку данных. Строка в кавычках представляет собой последовательность из нуля или более 7-битовых символов за исключением CR и LF, начинающуюся и завершающуюся двойной кавычкой (<">). Пустая строка представляется как "" или как литерал {0}, за которым следует последовательность CRLF. Замечание: Даже если число октетов равно нулю, клиент, передающий литерал должен подождать прихода команды продолжения. 3.1. 8-битовые и двоичные строки 8-битовая текстовая и двоичная почта поддерживается посредством шифрования [MIME-IMB]. Реализации IMAP 4.1 могут передавать 8-битные или многооктетные символы в литералах, но должны это делать, только когда определен [CHARSET]. Если даже определена кодировка BINARY, незакодированные двоичные строки не могут быть разрешены. "Двоичная строка" - это любая строка из NUL символов. Реализации программ должны перекодировать двоичные данные в текстовую форму, такую как BASE64, прежде чем их пересылать. Строка с большим числом символов CTL может рассматриваться как двоичная. 3.2. Список в скобках Структуры данных представляются в виде списков, помещенных в скобки, элементы списка разделяются пробелами. Такой список может включать в себя другие "списки в скобках". Пустой список выглядит как () - "список в скобках" с нулевым числом членов. 3.3. NIL Специальный атом "NIL" представляет собой указание на отсутствие каких-то определенных данных типа строка или "список в скобках". Его следует отличать от пустой строки "" или пустого "списка в скобках" ().
4. Операционные соображения
Интерпретация имен почтовых ящиков является независимой от конкретной программной реализации. Однако имя почтового ящика INBOX является специальным именем, зарезервированным для "первичного почтового ящика данного пользователя на данном сервере" (значение не зависит от использования строчных или прописных букв). Почтовые ящики могут образовывать иерархическую структуру. Если желательно экспортировать иерархию имен почтовых ящиков, имена почтовых ящиков должны быть упорядочены по буквам слева направо. 4.2. Соглашение о пространстве имен почтовых ящиков В соответствии с соглашением первый иерархический элемент любого имени почтового ящика, который начинается с символа "#" указывает на "пространство имен" остальной части имени. Например, реализации, которые предлагают доступ к группам новостей USENET могут использовать пространство имен "#news", для того чтобы отделить пространство имен групп новостей от имен других почтовых ящиков. Таким образом, группа новостей comp.mail.misc будет иметь имя почтового ящика "#news.comp.mail.misc", а имя "comp.mail.misc" может относиться к другому объекту (напр., к почтовому ящику пользователя). 4.3. Международное соглашение об именах почтовых ящиков Согласно договоренности имена международных почтовых ящиков специфицированы в соответствии модифицированной версией кодировки UTF-7, описанной в [UTF-7]. Целью этих модификаций было устранение следующих проблем, связанных с UTF-7:
В модифицированном UTF-7, печатные символы US-ASCII за исключением "&" представляются в исходном виде; то есть, символами со значениями октетов 0x20-0x25 и 0x27-0x7e. Символ "&" (0x26) представляется в виде двух октетной последовательности "&-". Все другие символы (значения октетов 0x00-0x1f, 0x7f-0xff, и все уникодные 16-битовые октеты) представляются в модифицированной кодировке BASE64, с дополнительными видоизменениями из [UTF-7]. Модифицированная BASE64 не должна использоваться для представления любых печатных символов US-ASCII, которые должны представлять самих себя. Символ "&" используется для перехода к модифицированной кодировке BASE64 а "-" для возврата назад к US-ASCII. Все имена начинаются с US-ASCII, и должны завершаться US-ASCII (то есть, имя, которое заканчивается уникодным 16-битовым октетом, должно быть завершено символом "-"). Примером может служить имя почтового ящика, в котором смешаны фрагменты текста на английском, японском и китайском языках: ~peter/mail/&ZeVnLIqe-/&U,BTFw- 4.4. Размер почтового ящика и актуализации состояния сообщений В любое время сервер может послать данные, которые клиент не запрашивал. Иногда, такое поведение системы является необходимым. Например, агенты, внешние по отношению к серверу, могут положить сообщения в почтовый ящик, изменить флаги сообщения в почтовом ящике (например, одновременный доступ в почтовый ящик нескольких агентов), или даже удалить сообщения из почтового ящика. Сервер должен автоматически послать уведомление об изменении размера почтового ящика, если такое изменение произошло в процессе выполнения команды. Сервер должен автоматически послать уведомление об изменении флагов сообщений, не требуя соответствующего запроса клиента. Имеются специальные правила для оповещения клиента сервером об удалении сообщений, чтобы избежать ошибок синхронизации (смотри также описание EXPUNGE). Программа клиента должна своевременно фиксировать изменения размера почтового ящика. Она не должна полагаться на то, что любая команда после начального выбора почтового ящика возвращает значение его размера. 4.5. Отклик в случае, когда не исполняется никакой команды Реализациям сервера разрешается посылать непомеченные отклики (за исключением EXPUNGE), если в это время не выполняется ни одной команды. Реализации, которые посылают такие отклики, должны учитывать соображения управления трафиком. В частности, они должны либо (1) проверить, что размер данных не превосходит транспортные возможности, или (2) использовать неблокирующую запись. 4.6. Таймер автоматического отключения (Autologout) Если сервер имеет таймер выгрузки в случае длительной пассивности, тогда такой таймер должен быть настроен на время, по крайней мере, 30 минут. Получения любой команды от клиента в течение этого периода должно быть достаточно для сброса этого таймера. 4.7. Одновременное исполнение нескольких команд Клиент может послать другую команду, не дожидаясь отклика на предшествующую, сервер может начать обработку другой команды до завершения обработки текущей. Исключение может составлять случаи, когда результат выполнения одной команды зависит от выполнения других команд. Клиенты не должны посылать несколько команд, не дожидаясь результата, если возможна неопределенность из-за их взаимозависимости. Если сервер детектирует возможную неопределенность, он должен исполнить их последовательно в порядке их получения от клиента. Наиболее очевидный пример неопределенности реализуется, например, когда последовательно выполняются команды FETCH для флагов сообщения и STORE для тех же самых флагов. Неочевидные неопределенности возникают с командами, которые допускают немаркированный отклик EXPUNGE (команды отличные от FETCH, STORE и SEARCH), так как немаркированный отклик EXPUNGE может нарушить корректность порядковых номеров сообщений для последующих команд. Это не представляет проблем для команд FETCH, STORE или SEARCH, так как серверам запрещено посылать отклики EXPUNGE, когда исполняется одна их этих команд. Следовательно, если клиент посылает любую команду, отличную от FETCH, STORE или SEARCH, он должен ждать отклика, прежде чем посылать команду, содержащую номер сообщения. Например, следующая последовательность команд (без ожидания) является некорректной: FETCH + NOOP + STORE Ниже представлены примеры последовательностей, не требующих ожидания завершения предшествующих инструкций: FETCH + STORE + SEARCH + CHECK 5. Команды клиента Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы. 5.1. Команды клиента - любое состояние Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT. 5.1.1. Команда CAPABILITY Аргументы: отсутствуют. Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с "IMAP 4.1" в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с "AUTH=" указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора "blurdybloop" могут быть описаны как "AUTH=XBLURDYBLOOP", а не "XAUTH=BLURDYBLOOP" или "XAUTH=XBLURDYBLOOP". Другие имена возможностей относятся к расширениям, новым версиям или коррекциям данной спецификации. Пример: C: abcd CAPABILITY 5.1.2. Команда NOOP Аргументы: отсутствуют. Так как любая команда может прислать немаркированные данные об изменении состояния, команда NOOP может использоваться, как периодический запрос нового сообщения или информации об изменении статуса в периоды неактивности. Команда NOOP может также использоваться для сброса таймера прерывания сессии сервером из-за отсутствия активности. Пример: C: a002 NOOP 5.1.3. Команда LOGOUT Аргументы: отсутствуют. Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения. Пример: C: A023 LOGOUT 5.2. Команды клиента - в состоянии без аутентификации В состоянии без аутентификации, команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде. Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени "anonymous". Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации. По завершении аутентификации невозможно вернуться непосредственно в состояние "без аутентификации". В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "без аутентификации" возможны команды: AUTHENTICATE и LOGIN. 5.2.1. Команда AUTHENTICATE Аргументы: имя механизма аутентификации.
Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [IMAP-AUTH]. Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO. Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом "+", за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только "*". Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD. Механизм защиты обеспечивает целостность и конфиденциальность соединения. Если механизм защиты согласовыван, то в дальнейшем он используется для всех сообщений, проходящих через данное соединение. Механизм защиты начинает действовать сразу после ввода последовательности CRLF, которая завершает аутентификационный обмен для клиента, и прихода CRLF маркированного отклика OK сервера. Раз механизм защиты вступил в силу, поток октетов команд и откликов заносится в буферы шифрованного текста. Каждый буфер передается через соединение в виде потока октетов, который начинается с четырех октетов, содержащих длину последующих данных. Максимальный размер буфера для текста-шифра определяется выбранным механизмом защиты. Аутентификационные механизмы являются опционными. Механизмы защиты также опционны; аутентификационный механизм может реализоваться в отсутствии какого-либо механизма защиты. Если команда AUTHENTICATE не прошла и получен отклик NO, клиент может совершить повторную попытку, послав еще одну команду AUTHENTICATE, или может попытаться выполнить аутентификацию с помощью команды LOGIN. Другими словами, клиент может затребовать тип аутентификации в порядке понижения уровня предпочтения, команда LOGIN используется как последний вариант. Пример: S: * OK KerberosV4 IMAP4rev1 Server 5.2.2. Команда LOGIN Аргументы: имя пользователя, пароль. Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом. Пример: C: a001 LOGIN SMITH SESAME 5.3. Команды клиента в состоянии "аутентификация осуществлена" В состоянии "аутентификация осуществлена" разрешены команды манипуляции почтовыми ящиками, как объектами-атомами. Команды SELECT и EXAMINE реализует выбор почтового ящика и переход в состояние "выбрано" . В добавление к стандартным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "аутентификация осуществлена" допустимы следующие команды: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND. 5.3.1. Команда SELECT Аргументы: имя почтового ящика. Результат: OK - процедура выбора закончена, система находится в состоянии "выбрано"; Команда SELECT осуществляет выбор почтового ящика, так чтобы обеспечить доступ к сообщениям, находящимся там. Прежде чем присылать клиенту OK, сервер должен послать клиенту следующие немаркированные данные: FLAGS - флаги, определенные для почтового ящика. Сервер должен также послать "невидимый" код отклика внутри немаркированного сообщения OK, который представляет собой порядковый номер первого невидимого сообщения в почтовом ящике. Если клиент не может изменить состояние одного или нескольких флагов, перечисленных в немаркированном отклике FLAGS, сервер должен в немаркированном отклике OK послать код PERMANENTFLAGS, перечислив флаги, которые клиент может изменить. Единовременно для одного соединения может быть выбран только один почтовый ящик. Одновременный доступ к нескольким почтовым ящикам требует установления соответствующего числа соединений. Команда SELECT автоматически аннулирует выбор почтового ящика при повторной попытке его выбора. Следовательно, если почтовый ящик был выбран, а команда SELECT не прошла, предшествующий выбор ящика аннулирован. Если клиенту разрешено модифицировать почтовый ящик, сервер должен снабжать маркированный текст отклика OK префиксом "[READ-WRITE]". Если клиенту не позволено модифицировать почтовый ящик, но разрешен доступ для чтения, почтовый ящик выбирается в режиме "только для чтения" и сервер должен перед посылкой текста передать маркированный отклик OK в ответ на команду SELECT с кодом отклика "[READ-ONLY]". Доступ "только для чтения" тем не менее, отличается от команды EXAMINE, при нем некоторые почтовые ящики позволяют изменять постоянное состояние некоторых флагов пользователя. Сетевые новости из файла .newsrc являются примером того, как некоторые состояния могут изменяться для почтовых ящиков типа "только для чтения". Пример: C: A142 SELECT INBOX 5.3.2. Команда EXAMINE Аргументы: имя почтового ящика.
Команда EXAMINE идентична команде SELECT и дает тот же результат, однако, выбранный почтовый ящик идентифицируется как "только для чтения". Никакие изменения постоянного состояния почтового ящика в этом случае не разрешены. Текст маркированного отклика OK на команду EXAMINE должен начинаться с кода отклика "[READ-ONLY]". Пример: C: A932 EXAMINE blurdybloop 5.3.3. Команда CREATE Аргументы: имя почтового ящика.
Команда CREATE создает почтовый ящик с заданным именем. Отклик OK присылается в случае, когда новый почтовый ящик с указанным именем создан. Попытка создания INBOX или почтового ящика с именем, существующего почтового ящика, является ошибкой . Любая ошибка при попытке создания почтового ящика вызовет маркированный отклик NO. Если имя почтового ящика имеет суффикс с символом сепаратора иерархии сервера (в соответствии с тем, что получено при выполнении команды LIST), то это является декларацией клиента о намерении создать почтовый ящик с именем в рамках указанной иерархии. Реализации сервера, которые не требуют этой декларации, должны ее игнорировать. Если символ-сепаратор иерархии сервера появляется где-либо еще в имени, сервер должен создать любые имена более высокого уровня иерархии, которые необходимы для успешного завершения выполнения команды CREATE. Другими словами, попытка создания "foo/bar/zap" на сервере, для которого символ "/" является иерархическим сепаратором, должна привести к созданию foo/ и foo/bar/, если они до этого не существовали. Если новый почтовый ящик создан с именем стертого почтового ящика, то его идентификатор должен быть больше, использованного его предшественником, если только новая версия ящика не имеет другого значения UID. Пример: C: A003 CREATE owatagusiam/ Замечание: интерпретация этого примера зависит от того, является ли символ "/" иерархическим сепаратором. Если "/" иерархический сепаратор, создается новый иерархический уровень с "owatagusiam" с новым членом иерархии этого уровня "blurdybloop". В противном случае создаются два почтовых ящика на одном и том же уровне иерархии. 5.3.4. Команда DELETE Аргументы: имя почтового ящика. Команда DELETE навечно удаляет почтовый ящик с указанным именем. При этом присылается маркированный отклик OK только в том случае, когда ящик уничтожен. Ошибкой считается попытка стереть INBOX или ящик с несуществующим именем. Команда DELETE не должна удалять ящики с более низкой иерархией, чем текущая. Например, если почтовый ящик "foo" имеет иерархическую структуру "foo.bar" (предполагается, что "." является иерархическим сепаратором), удаление "foo" не должно удалять "foo.bar". Считается ошибкой попытка удаления имени, которому соответствуют нижележащие иерархические уровни, имеющие атрибут \Noselect. Разрешено удалять имена, которым соответствуют нижележащие иерархические уровни, но не имеющие атрибута имени \Noselect. В этом случае все сообщения из этого почтового ящика также будут удалены, а имя получит атрибут \Noselect. Значение наибольшего используемого уникального идентификатора удаленных почтовых ящиков должно сохраняться, так чтобы новые созданные ящики с тем же именем не использовали идентификаторы своих предшественников, если только новый ящик не имеет другое значение UID. Примеры: C: A682 LIST "" * 5.3.5. Команда RENAME Аргументы: имя существующего почтового ящика, имя нового почтового ящика.
Команда RENAME изменяет имя почтового ящика. Маркированный отклик OK присылается лишь в случае, когда почтовый ящик переименован. Считается ошибкой попытка переименовать не существующий почтовый ящик или присвоить ящику уже имеющееся имя. Любая ошибка при переименовании вызовет маркированный отклик NO. Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование "foo" в "zap" переименует "foo/bar" (предполагая, что "/" является иерархическим разделителем) в "zap/bar". Значение наибольшего использованного уникального идентификатора имени старого почтового ящика должно быть сохранено, так чтобы новый создаваемый с тем же именем почтовый ящик не использовал идентификатора своего предшественника, если только он не имеет другого значения UID. Переименование INBOX разрешено, но имеет свою специфику. Оно перемещает все сообщения в почтовый ящик с новым именем, оставляя INBOX пустым. Если реализация сервера поддерживает иерархические системы имен INBOX, это никак не сказывается на переименовании INBOX. Примеры: C: A682 LIST "" * 5.3.6. Команда SUBSCRIBE Аргументы: имя почтового ящика. Команда SUBSCRIBE добавляет специфицированное имя почтового ящика к списку "активных" или "подписных" ящиков сервера, как это реализуется командой LSUB. Эта команда присылает маркированный отклик OK только в случае успешного осуществления подписки. Сервер может проверить аргумент команды SUBSCRIBE, чтобы проконтролировать его корректность для данного почтового ящика. Однако он не должен в одностороннем порядке удалять существующее имя почтового ящика из подписного листа, даже если ящика с таким именем более не существует. Замечание: это требование возникает потому, что некоторые серверы могут удалить почтовый ящик с известным именем, например, "system-alerts") после того как срок годности его содержимого истек с тем, чтобы создать его вновь при появлении новых сообщений. Пример: C: A002 SUBSCRIBE #news.comp.mail.mime 5.3.7. Команда UNSUBSCRIBE Аргументы: имя почтового ящика. Команда UNSUBSCRIBE удаляет специфицированный почтовый ящик из списка "активных" или "подписных" почтовых ящиков данного сервера, как это определяется командой LSUB. Эта команда возвращает маркированный отклик OK только в случае, если ликвидация подписки прошла успешно. Пример: C: A002 UNSUBSCRIBE #news.comp.mail.mime 5.3.8. Команда LIST Аргументы: имя,
Команда LIST возвращает субнабор имен из полного набора, доступного клиенту. Присылается нуль или более немаркированных откликов LIST, содержащих атрибуты имен, иерархические разделители и имена. Команда LIST должна возвращать данные быстро без существенных задержек. Например, она не должна тратить время на выяснение статуса (\Marked или \Unmarked) или на выполнение другой трудоемкой обработки, ведь если каждое имя требует одной секунды, то обработка списка из 1200 имен займет 20 минут. Аргумент, содержащий пустую строку образца имени (""), указывает, что имя почтового ящика интерпретируется также, как это делает команда SELECT. Присланные имена почтовых ящиков должны соответствовать полученному шаблону имени. Непустой аргумент является шаблоном имени почтового ящика или уровеня иерархии и указывает на контекст, в котором интерпретируется имя. Пустой аргумент имени ("") представляет собой специальный запрос, требующий присылки иерархического разделителя и корневого имени. Значение, возвращаемое в качестве корневого имени, может быть нулем, если шаблону не соответствует никакая иерархия. Иерархический разделитель присылается во всех случаях. Это позволяет клиенту получить иерархический разделитель даже в случае, когда нет почтовых ящиков, соответствующих данному имени. Шаблон и имя почтового ящика интерпретируются по-разному в зависимости от реализации. В каноническом варианте анализ происходит слева направо. Любая часть аргумента шаблона, которая включена в интерпретированную форму, должна предшествовать интерпретированной форме. Она должна иметь тот же формат, что и аргумент шаблона имени. Это правило позволяет клиенту определить, соответствует ли присланное имя почтового ящика контексту шаблона. Без этого правила, клиент должен был бы знать семантику имен сервера. Ниже приведены некоторые примеры того, как могут интерпретироваться образцы и имена почтовых ящиков на серверах базирующихся на UNIX:
Первые три примера демонстрируют интерпретацию в контексте аргумента шаблона. Заметьте, что "~smith/Mail" не должно преобразоваться во что-то подобное "/u2/users/smith/Mail", иначе для клиента было бы невозможно определить, соответствовала ли интерпретация контексту шаблона. Символ "*" представляет собой подмену (wildcard), и соответствует нулю или более символов в данной позиции. Символ "%" подобен "*", но он не соответствует иерархическому разделителю. Если символ "%" является последним символом имени почтового ящика, то в отклике будут присланы и соответствующие уровни иерархии. Если эти уровни не являются почтовыми ящиками, которые можно выбрать, то их имена снабжаются атрибутом \Noselect. Реализациям сервера таким образом позволено спрятать некоторые почтовые ящики, имена которых могли бы быть раскрыты с использованием шаблонов с символами подмены (wildcard). Например, сервер на основе UNIX может ограничить интерпретацию "*" так, что начальный символ "/" будет приводить к несоответствию имени шаблону. Специальное имя INBOX включается в выдачу команды LIST, если INBOX поддерживается данным сервером для данного пользователя и, если строка "INBOX", напечатанная прописными буквами, соответствует интерпретированному шаблону. Пример: C: A101 LIST "" "" S: * LIST (\Noselect) "/" "" 5.3.9. Команда LSUB Аргументы: имя-шаблон,
Команда LSUB возвращает субнабор имен из списка пользователя, который декларирован как "активный" или "подписной". При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST. Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще. Если имени не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа даже, если такого ящика более не существует. Пример: C: A002 LSUB "#news." "comp.mail.*" 5.3.10. Команда STATUS Аргументы: имя почтового ящика, статусная информация имен. Команда STATUS запрашивает статусные данные для указанного почтового ящика. Она не изменяет выбор почтового ящика и не вносит каких-либо изменений в состояние сообщений для запрошенного ящика (в частности команда STATUS не должна вызывать потерю флага \Recent). Команда STATUS предоставляет альтернативу открытию дополнительного IMAP 4.1 соединения и реализует команду EXAMINE для запрашиваемого почтового ящика, не изменяя выбора, выполненного при первичном соединении. В отличии от команды LIST, команда STATUS не гарантирует быстрого отклика. В некоторых реализациях сервер обязан открыть почтовый ящик в режиме "только чтение", чтобы получить нужные статусные данные. Кроме того, команда STATUS не допускает символов подмены в шаблоне имени. В настоящее время определены следующие статусные данные, которые могут быть запрошены:
Пример: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) 5.3.11. Команда APPEND
Аргументы: имя почтового ящика, Отклики: команда не требует какого-либо специального отклика
Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым. Если специфицировано date_time, в результирующем сообщении должна быть установлена внутренняя дата, в противном случае, внутренняя дата и время результирующего сообщения будут установлены по умолчанию равными текущим значениям. Если команда append по какой-то причине не прошла, почтовый ящик должен быть возвращен в состояние, которое он имел до команды APPEND. Если почтовый ящик места назначения не существует, сервер должен сообщить об ошибке, а не должен автоматически создавать новый почтовый ящик. Если не ясно, может или нет быть создан почтовый ящик, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это указывает клиенту на возможность попытки исполнения команды CREATE, после чего, в случае успеха, повторить команду APPEND. Если в настоящее время почтовый ящик и выбран, то немедленно должны начаться почтовые операции. Сервер должен уведомить клиента об этом, послав немаркированный отклик EXISTS. Если сервер не делает этого, клиент после одной или более команд APPEND может выдать команду NOOP (или при неудаче команду CHECK). Пример: C: A003 APPEND saved-messages (\Seen) {310} Замечание: команда APPEND не используется для доставки сообщений, так как она не содержит в себе механизма передачи служебной информации [SMTP]. 5.4. Команды клиента в состоянии "выбор сделан" В состоянии "выбор сделан", разрешены команды, которые манипулируют сообщениями в почтовом ящике. Помимо универсальных команд (CAPABILITY, NOOP и LOGOUT), а также команд режима аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND), в данном режиме доступны следующие команды: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID. 5.4.1. Команда CHECK Аргументы: отсутствуют. Команда CHECK осуществляет проверку выбранного почтового ящика. Проверка относится к любым характеристикам, зависящим от реализации (например, выявление положения почтового ящика в памяти сервера и на диске). Если сервер не поддерживает таких возможностей, команда эквивалентна NOOP. Не существует гарантии, что в результате CHECK будет прислан немаркированный отклик. Для проверки поступления новой почты следует использовать команду NOOP, а не CHECK. Пример: C: FXXZ CHECK 5.4.2. Команда CLOSE Аргументы: отсутствуют. Команда CLOSE навечно удаляет из выбранного почтового ящика все сообщения, помеченные флагом \Deleted, и возвращает систему в состояние "аутентификация выполнена". Никакого немаркированного отклика EXPUNGE не посылается. Никаких сообщений не удаляется и никаких флагов ошибки не возвращается, если почтовый ящик был выбран командой EXAMINE или находился в режиме "только для чтения". Даже если почтовый ящик выбран, команды SELECT, EXAMINE или LOGOUT могут быть использованы без предварительного исполнения команды CLOSE. Команды SELECT, EXAMINE и LOGOUT безоговорочно закрывают выбранный в данный момент почтовый ящик без удаления сообщений. Однако когда удалено много сообщений, последовательность CLOSE-LOGOUT или CLOSE-SELECT значительно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT, так как здесь не посылается никаких немаркированных откликов EXPUNGE (которые клиент вероятно проигнорирует). Пример: C: A341 CLOSE 5.4.3. Команда EXPUNGE Аргументы: отсутствуют. Команда EXPUNGE навечно удаляет из выбранного почтового ящика все сообщения, которые помечены флагами \Deleted. Прежде чем выдать клиенту сигнал OK, посылается немаркированный отклик EXPUNGE для каждого из удаляемых сообщений. Пример: C: A202 EXPUNGE Замечание: в этом примере, сообщения 3, 4, 7 и 11 имеют установленный флаг \Deleted. Следует учитывать, что после каждого удаления сообщения перенумеруются. 5.4.4. Команда SEARCH Аргументы: опционны, [CHARSET]-спецификация. Команда SEARCH ищет почтовый ящик, который отвечает выбранным критериям отбора. Критерий отбора состоит из одного или более ключей поиска. Немаркированный отклик SEARCH от сервера содержит список номеров сообщений, которые соответствуют критериям отбора. Когда специфицировано несколько ключей, результатом является (функция AND) совокупность всех сообщений, отвечающим заданным критериям. Например, критерий DELETED FROM "SMITH" SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Смита, которые были положены в почтовый ящик после 1-го февраля 1994. (например, для объединения этих ключей с помощью функций OR и NOT). Опционная спецификация [CHARSET] состоит из слова "CHARSET", за которым следует зарегистрированное наименование символьного набора [CHARSET]. Он включает в себя [CHARSET] строк, которые используются в качестве критерия отбора. Транспортное кодирование содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/[MIME-IMB] заголовках, должны декодироваться перед сравнением текста в представлении [CHARSET], отличном от US-ASCII. US-ASCII должно поддерживаться всегда, но могут использоваться и другие символьные наборы. Если сервер не поддерживает специфицированный набор символов [CHARSET], он должен вернуть маркированный отклик NO (но не BAD). Для всех ключей поиска, которые используют строки, сообщение соответствует ключу, если строка является частью строки поля в сообщении. Соответствие не должно зависеть от использования строчных или прописных символов. Стандартными ключами поиска являются следующие слова и выражения.
Пример: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" 5.4.5. Команда FETCH Аргументы: набор сообщений, Команда FETCH извлекает данные, соответствующие сообщению в почтовом ящике. В качестве доставляемых данных может выступать отдельный атом или список элементов, помещенных в скобками. В настоящее время определены следующие типы данных, которые могут быть доставлены: ALL Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) Текст определенной части тела сообщения. Спецификация секции представляет собой нуль или более спецификаторов, разделенных точками. Спецификатором части является либо число, либо одно из имен: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT. Пустая спецификация относится ко всему сообщению, включая заголовок. Каждое сообщение имеет номер, по крайней мере, одной части. Сообщения не-[MIME-IMB] и несоставные сообщения [MIME-IMB] без инкапсуляции имеют только часть 1. Частям составных сообщений присваиваются последовательные номера в порядке появления. Если конкретная часть является составным сообщением, то его части должны быть выделены точкой, за которой следует номер части. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними могут размещаться один или более числовых спецификаторов частей сообщения, которые указывают на принадлежность типу MESSAGE/RFC822. Перед спецификатором части MIME должны размещаться один или более числовых спецификаторов. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заголовку сообщения [RFC-822] или инкапсулированному сообщению [MIME-IMT] MESSAGE/RFC822. За HEADER.FIELDS и HEADER.FIELDS.NOT следует список имен полей (как это определено в [RFC-822]). Субнабор, возвращаемый HEADER.FIELDS, содержит только те поля заголовка, имена которых соответствуют одному из имен списка. Аналогично, субнабор, возвращаемый HEADER.FIELDS.NOT, содержит только поля заголовка с несоответствующими именами полей. Соответствие является точным, но нечувствительным к использованию строчных и прописных букв. Во всех случаях, вставляется разграничивающая пустая строка между заголовком и телом сообщения. Спецификатор MIME части относится к заголовку [MIME-IMB] этой части. Спецификатор текстовой части относится к телу сообщения, без заголовка [RFC-822]. Ниже приведен пример составного сообщения с некоторыми спецификаторами его частей: HEADER ([RFC-822] заголовок сообщения) Имеется возможность доставить субстроку определенного текста. Это делается путем присоединения к спецификатору части открытой угловой скобки ("<"), положения первого нужного октета, точки, максимального требуемого числа октетов и закрывающей угловой скобки. Если начальный октет находится за пределами текста, возвращается пустая строка. При любой частичной доставке, при которой производится попытка чтения за пределами текста, фрагмент соответствующим образом обрезается. Замечание: это означает, что запрос BODY[]<0.2048> сообщения длиной 1500 октетов пришлет BODY[]<0> с литералом размера 1500, а не BODY[].
Пример: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) 5.4.6. Команда STORE Аргументы: набор сообщений, Команда STORE заносит данные в почтовый ящик. В норме команда STORE возвращает обновленную версию данных с немаркированным откликом FETCH. ".SILENT" в имени элемента данных блокирует немаркированный отклик FETCH, и сервер должен предполагать, что клиент определил обновленное значение сам или ему обновленное значение не нужно. Замечание: вне зависимости от того используется или нет суффикс ".SILENT", сервер должен послать немаркированный отклик FETCH, если внешние причины вызвали изменение флагов сообщения. В настоящее время определены следующие элементы данных:
Пример: C: A003 STORE 2:4 +FLAGS (\Deleted) 5.4.7. Команда COPY Аргументы: набор сообщений,
Команда COPY копирует специфицированное сообщение в конец указанного почтового ящика. Флаги и внутренняя дата сообщения должны быть сохранены в копии. Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY. Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик назначения в состояние, которое он имел до выполнения COPY. Пример: C: A003 COPY 2:4 MEETING 5.4.8. Команда UID Аргументы: имя команды, Команда UID имеет две формы. В первой форме она использует в качестве аргумента имена команд COPY, FETCH или STORE (с их аргументами). Однако числа в списке аргументов в этом случае представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Во второй форме команда UID использует команду SEARCH с ее аргументами. Интерпретация аргументов та же, что и в случае SEARCH; однако, числа, возвращаемые в отклике на команду UID SEARCH, представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Например, команда UID SEARCH 1:100 UID 443:557 возвратит уникальный идентификатор, соответствующий пересечению порядкового номера сообщения 1:100 и UID 443:557. Допускаются диапазоны номеров сообщений, однако, нет гарантии, что уникальные идентификаторы образуют монотонную последовательность без пропусков. Не существующие уникальные идентификаторы в списке сообщений игнорируются без генерации сообщения об ошибке. Число после "*" в немаркированном отклике FETCH всегда является порядковым номером сообщения, а не уникальным идентификатором, даже для отклика на команду UID. Однако реализации сервера должны безоговорочно включать значения UID в качестве части любого отклика FETCH, вызванного командой UID, вне зависимости от того, был ли UID специфицирован в качестве элемента сообщения для FETCH. Пример: C: A999 UID FETCH 4827313:4828442 FLAGS
5.5. Команды клиента - экспериментальные и расширения Аргументы: определяется приложением. Любая команда с префиксом X является экспериментальной командой. Команды, которые не являются частью этой спецификации стандарта, модификации стандарта или одобренного IESG экспериментального протокола, должны использовать префикс X. Любой добавленный немаркированный отклик, посланный экспериментальной командой также должен иметь префикс X. Реализации сервера не должны посылать такие немаркированные отклики, если только клиент не запрашивает их посредством какой-либо экспериментальной команды. Пример: C: a441 CAPABILITY 6. Отклики сервера Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом "Содержимое:". Клиент должен быть готов воспринять любой отклик в любое время. Отклики состояния могут быть маркированными или нет. Маркированные отклики состояния указывают на результат завершения команды клиента (OK, NO или BAD) и имеют метку, соответствующую команде. Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом "*" вместо метки. Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также "незапрашиваемыми данными". Определенные данные от сервера должны записываться клиентом при получении. Такие данные несут критическую информацию, которая влияет на интерпретацию всех последующих команд и откликов (например, создание или уничтожение сообщений). Прочие данные сервера следует записывать для последующих ссылок, если клиент не нуждается в записи данных или если запись данных не имеет очевидного смысла (например, отклик SEARCH, когда никакой команды SEARCH не исполняется), такая информация должна игнорироваться. Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии "выбрано". В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В норме, это часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение. Отклики запросов продолжения команды используют символ "+" вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды. 6.1. Отклики сервера - отклики состояния Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE - всегда не маркированы. Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:
Дополнительные коды откликов определенные конкретным клиентом или сервером должны иметь префикс "X", если они отклоняются от рекомендаций данного документа. Реализации клиента должны игнорировать отклики, которые ими не распознаются. 6.1.1. Отклик OK Содержимое: опционный код отклика; Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика. Немаркированная форма используется также как один из трех видов оповещения об установлении начального соединения. Эта форма указывает, что еще не выполнена аутентификация и необходима команда LOGIN. Пример: S: * OK IMAP4rev1 server ready 6.1.2. Отклик NO Содержимое: опционный код отклика; Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия. Пример: C: A222 COPY 1:2 owatagusiam 6.1.3. Отклик BAD Содержимое: опционный код отклика; Отклик BAD отмечает сообщение об ошибке со стороны сервера. В маркированной форме он сообщает об ошибке протокольного уровня в команде клиента; метка отмечает команду, которая вызвала ошибку. Непомеченная форма указывает на ошибку протокольного уровня, для которой нельзя указать команду, вызвавшую ошибку; это может также означать внутреннюю ошибку сервера. Текстовое сообщение описывает условия. Пример: C: ...very long command line... 6.1.4. Отклик PREAUTH Содержимое: опционный код отклика; Отклик PREAUTH является всегда непомеченным и представляет собой одну из трех возможных реакций при установлении соединения. Он указывает, что для соединения уже выполнена аутентификация, и команда LOGIN не нужна. Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith 6.1.5. Отклик BYE Содержимое: опционный код отклика; Отклик BYE является всегда непомеченным, он указывает, что сервер намеривается разорвать соединение. При этом пользователю может быть послано текстовое сообщение, проясняющее статус клиента. Отклик BYE посылается при выполнении одного из четырех условий:
Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно. Пример: S: * BYE Autologout; idle for too long 6.2. Отклики сервера - сообщения о состоянии сервера и почтового ящика Эти отклики всегда не маркированы. Они служат для передачи статусной информации сервера и почтового ящика клиенту. Большинство этих откликов являются результатом команд, носящих то же имя. 6.2.1. Отклик CAPABILITY Содержимое: список возможностей. Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом "IMAP 4.1". Имя возможности, которое начинается с "AUTH=" указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей. Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X". Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от "IMAP 4.1", они должны игнорировать неизвестные имена возможностей. Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN 6.2.2. Отклик LIST Содержимое: атрибуты имени, иерархический разделитель, имя. Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду. Определено четыре атрибута имени:
Если сервер не может определить, является ли почтовый ящик "интересным", или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет. Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика. Пример: S: * LIST (\Noselect) "/" ~/Mail/foo 6.2.3. Отклик LSUB Содержимое: атрибуты имени, иерархический разграничитель, имя. Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST. Пример: S: * LSUB () "." #news.comp.mail.misc 6.2.4. Отклик STATUS Содержимое: имя, статусный список, заключенный в скобки. Отклик STATUS является результатом команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика. Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) 6.2.5. Отклик SEARCH Содержимое: нуль или более чисел. Отклик SEARCH является результатом команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH - их уникальные идентификаторы. Числа отделяются друг от друга пробелами. Пример: S: * SEARCH 2 3 6 6.2.6. Отклик FLAGS Содержимое: список флагов, заключенный в скобки. Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом. Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 6.3. Отклики сервера - размер почтового ящика Эти отклики являются немаркированными. Они передают от сервера клиенту информацию об изменении размера почтового ящика. Число, которое следует за символом "*" определяет количество сообщений. 6.3.1. Отклик EXISTS Содержимое: отсутствует. Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом. Пример: S: * 23 EXISTS 6.3.2. Отклик RECENT Содержимое: отсутствует. Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Замечание: Нельзя гарантировать, чтобы порядковые номера для последних сообщений образовывали в почтовом ящике непрерывный ряд с предыдущими. Примерами, когда складывается такая ситуация могут служить варианты: несколько клиентов, имеют один и тот же открытый почтовый ящик; или случай, когда сообщения в почтовом ящике переставлены не-IMAP приложением. Единственным способом идентифицировать последние сообщения является рассмотрение флагов \Recent, или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом. Пример: S: * 5 RECENT 6.4. Отклики сервера - статусное сообщение Эти отклики являются немаркированными. Они несут информацию о том, как сообщения доставляются от сервера к клиентам, и возникают как результат работы одноименных команд. Сразу за символом "*" следует число, которое является порядковым номером сообщения. 6.4.1. Отклик EXPUNGE Содержимое: отсутствует. Отклик EXPUNGE уведомляет, сообщение с каким порядковым номером удалено из почтового ящика. Порядковые номера последующих сообщений немедленно уменьшаются на единицу. Как результат этого немедленного уменьшения порядковых номеров следует рассматривать то, что порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи "снизу-вверх" пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи "сверху вниз", пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5. Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда, или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера. Информация отклика EXPUNGE должна регистрироваться клиентом. Пример: S: * 44 EXPUNGE 6.4.2. Отклик FETCH Содержимое: текст сообщения. Отклик FETCH возвращает данные о сообщении клиенту. Данные сформированы в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера (например, об изменении флагов). В настоящее время существуют следующие информационные элементы: BODY Форма BODYSTRUCTURE без расширения данных. Строка, отражающая содержимое специфицированной секции. Строка должна интерпретироваться клиентом согласно транспортной кодировке, типу и субтипу тела. Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[]<0> может быть укорочено, но BODY[] никогда не укорачивается. Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено). Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка. Не текстовые данные, такие как двоичные, должны передаваться закодированными в текстуальной форме, например BASE64. Чтобы получить исходные двоичные данные клиент должен декодировать полученную последовательность. BODYSTRUCTURE - список, заключенный в скобки, который описывает [MIME-IMB], Эта структура вычисляется сервером путем разбора полей заголовка [MIME-IMB], и подставления при необходимости значений по умолчанию. Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48) Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой. Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.). Например, сообщение из двух частей, включающее в себя текст и приложение, закодированное в BASE64, может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED")) Данные расширения следуют за составным субтипом. Данные расширения никогда не присылаются при доставке тела, но могут быть доставлены с помощью BODYSTRUCTURE. Данные расширения, если они присутствуют, должны иметь следующий формат: Список параметров тела, заключенный в скобки. Список содержит пары атрибут/значение [например, ("foo" "bar" "baz" "rag"), где "bar" представляет собой значение "foo", а "rag" является значением "baz"] как это определено в [MIME-IMB]. Размещение тела Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах. Язык тела Строка или список в скобках, определяющие язык, так как это задано в [LANGUAGE-TAGS]. Любое из последующих расширений данных в данной версии протокола не определено. Такие расширения могут состоять из нуля или более NIL-строк, чисел, или вложенных списков таких данных, заключенных в скобки. Реализации клиента, которые осуществляют доставку BODYSTRUCTURE, должны быть готовы принять такие расширения данных. Реализации сервера не должны посылать такие расширения, до тех пор, пока они не войдут в новую версию протокола. Базовые поля несоставной части тела размещаются в следующем порядке: Тип тела Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB]. Субтип тела Строка, описывающая имя субтипа, как это определено в [MIME-IMB]. Список параметров тела, заключенный в скобки Список пар атрибут/значение, заключенный в скобки, [например, ("foo" "bar" "baz" "rag"), где "bar" является значением "foo", а "rag" - значением "baz"], как это описано в [MIME-IMB]. Идентификатор тела Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB]. Описание тела Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB]. Шифрование тела Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB]. Размер тела Число, указывающее размер тела в октетах. Заметьте, что этот размер характеризует размер тела с учетом транспортного кодирования. Размер исходного текста может быть иным. Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках. Тип тела TEXT сразу после базовых полей содержат размер тела в строках. Заметьте, что этот размер отражает размер фрагмента после выполнения транспортного кодирования. Данные расширения следуют после базовых полей и полей, перечисленных выше и зависящих от типа. Данные расширения никогда не транспортируются при передаче тела, но могут быть пересланы при доставке BODYSTRUCTURE. Данные расширения, если они присутствуют, должны быть упорядочены. Данные расширения для несоставной части тела располагаются в следующем порядке: MD5 тела Строка, содержащая значение MD5 тела, как это описано в [MD5]. Размещение тела Список, заключенный в скобки, с тем же содержимым и функциями, что и размещение тела для составной части тела. Язык тела Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS]. Любые последующие данные расширения пока не определены в данной версии протокола. ENVELOPE - список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения. Он вычисляется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию. Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки. Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [SMTP] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ. Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы. Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL. Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from.
Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) 6.5 Отклики сервера - запрос продолжения команды Отклик на запрос продолжения команды вместо метки выделяется символом "+". Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму. Этот отклик используется командой AUTHORIZATION, для того чтобы передать данные от сервера клиенту, и запросить дополнительные данные у клиента. Этот отклик применяется также, если аргументом какой-то команды является литерал. Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы. Пример: C: A001 LOGIN {11} 7. Пример соединения IMAP 4.1 Последующее является записью для соединения IMAP 4.1. (Данный пример и нижеприведенное описание синтаксиса практически без изменения взято из документа RFC-2060). S: * OK IMAP4rev1 Service Ready 8. Формальный синтаксис Последующая синтаксическая спецификация использует нотацию Бакуса-Наура (BNF - Backus-Naur Form), как это описано в [RFC-822] с одним исключением, разделителем, используемым в конструкции "#", служит одиночный пробел (SPACE), а не одна или более запятых. В случае альтернативных или опционных правил, в которых последующее правило перекрывается с более ранним, более приоритетным считается правило, встретившееся первым. Некоторые, но не все случаи таких правил представлены ниже. Если не указано обратного, все буквенные символы не зависят от использования строчных или прописных букв. Конкретные программные реализации должны воспринимать такие строки при любом написании. address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox SPACE addr_host ")" ;; Будущее расширение. Реализации клиента должны воспринимать flag_keyword ::= atom ;; Символьный набор [CHARSET] должен быть зарегистрирован IANA search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / ;; Выше этой строки все в [IMAP2] "DRAFT" / ;; * является наибольшим используемым числом. Для порядковых номеров set ::= sequence_num / (sequence_num ":" sequence_num) / ;; Идентифицирует набор сообщений. Для порядковых номеров SPACE ::= ;; Уникальные идентификаторы используются вместо uniqueid ::= nz_number ;; В возрастающем порядке ;; Число из 4 цифр со знаком hhmm, представляющее часы и минуты к западу от Гринвича
Протокольные операции IMAP 4.1, включая данные электронной почты, передаются через сеть открытым текстом, если только не согласовано применение конфиденциальных методов обмена посредством команды AUTHENTICATE. Сообщения об ошибках сервера для команды AUTHENTICATE, которая не прошла из-за неверных параметров аутентификации, не должна уточнять какой из параметров содержит ошибку. Использование команды LOGIN осуществляет передачу паролей открытым текстом. Этого можно избежать, используя для этого команду AUTHENTICATE. A. Библиография
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.14.2 Почтовый протокол POP3
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.15 Сетевой протокол времени NTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Время - самый важный и невосполнимый ресурс любого человека. Проблема эта занимала людей всегда, и уже более 4 тысяч лет люди пытаются как-то упорядочить учет расходования этого ресурса, создавая различные календарные системы и устройства измерения времени. Календарные системы древнего мира отражали сельскохозяйственные, политические и ритуальные нужды, характерные для того времени. Астрономические наблюдения для установления зимнего и летнего солнцестояния производились еще 4000 лет тому назад. Проблема создания календаря возникала только в обществах, где государственная стабильность поддерживалась в течение достаточно долгого времени (Китай, Египет, государство Майя). В 14-ом столетии до Рождества Христова в Китае была определена длительность солнечного года - 365.25 дней, а лунный месяц - 29.5 дней. Солнечно-лунный календарь действовал на ближнем востоке (за исключением Египта) и в Греции, начиная с 3-го тысячелетия до нашей эры. Ранние календари использовали либо 13 лунных месяцев по 28 дней или 12 месяцев с чередующейся протяженностью 29 и 30 дней. Древнеегипетский календарь имел 12 30-дневных лунных месяцев, но был привязан к сезонному появлению звезды Сириус (sirius - sothis). Для того чтобы примирить этот календарь с солнечным годом, был изобретен гражданский календарь, в котором добавлено 5 дней, доводящих длительность года до 365 дней. Однако со временем было замечено, что гражданский год примерно на одну четверть дня короче, чем солнечный год. Выбранная длительность года обеспечивала полное совпадение с солнечным годом раз за 1460 лет. Этот период называется циклом Сотиса (sothic-цикл). Так же как и shang chinese, древние египтяне установили длительность солнечного года равной 365,25 дней, что с точностью 11 минут совпадает с результатами современных вычислений. В 432 году до рождества Христа, около столетия после китайцев греческий астроном Метон вычислил, что 110 лунных месяцев по 29 дней и 125 лунных месяцев по 30 дней соответствуют 6940 солнечным дням, что лишь немного превышает 19 лет. 19-летний цикл, названный циклом Метона, установил длительность лунного месяца равной 29,532 солнечных дней, что с точностью 2 минут совпадает результатами современных измерений. В древнем Риме использовался лунный календарь. Юлий Цезарь пригласилалександрийского астронома Сосигенса, который разработал календарь (который по понятным причинам стал называться юлианским), принятый в 46 году до Рождества Христова. Календарь содержал 365 дней в году с добавлением одного дня каждые 4 года. Однако первые 36 лет по ошибке дополнительный день добавлялся каждые три года. В результате набежало лишних три дня, которые пришлось компенсировать вплоть до 8 года нашей эры. Семидневная неделя была введена лишь в четвертом столетии нашей эры императором Константином I. Во время романской эры 15-летний цикл переписи использовался при исчислении налогов. Последовательность имен дней недели воспроизводится через 28 лет, этот период называется солнечным циклом. Таким образом, учитывая 28-летний солнечный цикл, 19-летний цикл Метона и 15-летний переписи, получаем суперцикл протяженностью 7980-лет, называемый юлианской эрой, которая начинается в 4713 году до рождества христова. К 1545 году расхождение между юлианским календарем и солнечным годом достигло 10 дней. В 1582, астрономы Кристофер Клавиус и Луиджи Лилио предложили новую схему календаря. Папа Грегорий XIII выпусти указ, где среди прочего указывалось, что в году содержится 365.2422 дней. Для того чтобы более точно аппроксимировать эту новую величину, только столетние годы, которые делятся без остатка на 400, объявляются високосными, что предполагает длительность года 365,2425 дней. В настоящее время григорианский календарь принят большинством стран мира. Для того чтобы мерить расширение вселенной или распад протона необходимо стандартную схему нумерации дней. По решению Международного астрономического Союза был принят стандарт на секунду и юлианская система нумерации дней (jdn). Стандартный день содержит 86,400 стандартных секунд, а стандартный год состоит из 365,25 стандартных дней. В схеме (JDN), предложенной в 1583 французским ученым Джозефом Юлиусом Скалигером, JDN 0.0 соответствует 12 часам (полдень) первого дня юлианской эры - 1 января 4713 до нашей эры. Годы до нашей эры подсчитываются согласно юлианскому календарю, в то время как годы нашей эры нумеруются по григорианскому календарю. 1 января 1 года после рождества христова в григорианском календаре соответствует 3 января 1 года юлианского календаря [DER90], в JDN 1.721.426,0 день соответствует 12 часам первого дня нашей эры. Калиброванный эталон времени, например атомные часы, довольно сложное и дорогостоящее устройство, требующее квалифицированного обслуживания. По этой причине многие пользователи не могут позволить себе такие издержки и вынуждены обращаться к услугам удаленных эталонов. Это может быть первичный эталон, размещенный где-то в локальной сети, или радио-часы. Условия доступа к сети уже предполагают наличие определенной дисперсии для времени доставки калибровочной информации. Если же эталон размещен далеко в Интернет, значения задержки и дисперсии могут возрасти многократно. Для обеспечения большей надежности калибровки обычно используют несколько эталонов, а для снижения влияния временных разбросов привлекают довольно сложные алгоритмы усреднения. Сетевой протокол задания времени NTP (network time protocol; Network Time Protocol Version 3 Specification, Implementation and Analysis, David L. Mills, RFC-1305, March 1992) служит для осуществления синхронизации работы различных процессов в серверах и программах клиента. Он определяет архитектуру, алгоритмы, объекты и протоколы, используемые для указанных целей. NTP был впервые определен в документе RFC-958 [MIL85c], но с тех пор несколько раз переделан и усовершенствован (RFC-1119 [MIL89]). Протокол использует для транспортных целей UDP [POS80]. Целью протокола является обеспечение максимально возможной точности и надежности, несмотря на значительный разброс задержек при прохождении через большое число промежуточных маршрутизаторов. Протокол NTP обеспечивает механизмы синхронизации с точностью до наносекунд. Протокол предлагает средства для определения характеристик и оценки ошибок локальных часов и временного сервера, который осуществляет синхронизацию. Предусмотрены возможности работы с иерархически распределенными первичными эталонами, такими как синхронизуемые радио-часы. Точность, достижимая с помощью NTP, сильно зависит от точности локальных часов и характерных скрытых задержек. Алгоритм коррекции временной шкалы включает внесение задержек, коррекцию частоты часов и ряд механизмов, позволяющих достичь точности порядка нескольких миллисекунд, даже после длительных периодов, когда потеряна связь с синхронизирующими источниками. Существует ряд механизмов в Интернет, которые позволяют передавать и записывать время, когда произошло какое-то событие. Это протокол daytime [POS83a], time protocol [POS83b], сообщения ICMP "временная метка" [DAR81b] и опция IP "временная метка" [SU81]. Маршрутный протокол fuzzball [MIL83b], иногда называемый hellospeak, встраивает синхронизацию непосредственно в алгоритм маршрутного протокола. Он не является протоколом из стека IP. Юниксовский (4.3BSD) времязадающий демон [GUS85a] измеряет временные сдвиги различных клиентских процессов и рассылает им соответствующие поправки. В этой модели сервер определен с помощью алгоритма выбора [GUS85b], который исключает ситуации, где сервер не выбран или выбрано более одного сервера. Процесс выбора требует возможности рассылки широковещательных сообщений. Архитектура системы
В модели NTP некоторое число первичных эталонов времени, синхронизованных по кабелю или с помощью национальных радио служб времени, подключено к широкодоступным ресурсам, таким как порты опорной сети. Эти устройства функционируют как первичные серверы времени. Целью NTP является передача информации о точном времени от этих серверов к другим серверам через Интернет и коррекция ошибок, связанных с флуктуациями задержек в сети. Некоторое число локальных ЭВМ или внешних шлюзов могут выполнять функции вторичных серверов времени, общающихся с первичными эталонами на основе протокола NTP. Вторичные серверы позволяют минимизировать избыточность протокола, рассылая нужную временную информацию локально. В целях обеспечения надежности выбранные вторичные источники могут быть снабжены менее точными, зато более дешевыми радио-часами, используемыми в ситуациях, когда откажет первичный эталон или выйдет из строя ведущий к нему канал. Под стабильностью подразумевается степень постоянства задающей частоты часов, а под точностью - соответствие этой частоты национальным стандартам времени. Если не указано обратного, под временным сдвигом между часами подразумевается разница показаний этих часов. В то время как под сбоем (skew) подразумевается различие их рабочих частот (первая производная). Настоящие часы имеют конечную стабильность частоты (вторая производная не равна нулю). Нестабильность частоты называется дрейфом, но в рамках протокола NTP дрейф предполагается равным нулю. Протокол NTP создан с целью определения трех величин: смещения часов (clock offset), RTT и дисперсии, все они вычисляются по отношению к выбранным эталонным часам. Смещение часов определяет поправку, которую необходимо внести в показания местных часов, чтобы результат совпал показанием эталонных часов. Дисперсия характеризует максимальную ошибку локальных часов по отношению к эталонным. В протоколе NTP нет средств для нахождения партнера или управления. Целостность данных обеспечивается с помощью IP и UDP контрольных сумм. Система может работать в симметричном режиме, когда сервер и клиент неразличимы, и в режиме клиент-сервер, где сервер выполняет только то, что требует клиент. Используется только один формат сообщений NTP. В рамках модели необходимо определить минимально возможную частоту коррекций часов, обеспечивающую требуемую временную точность. Реализация модели Клиент посылает NTP-сообщения одному или нескольким серверам и обрабатывает отклики по мере их получения. Сервер изменяет адреса и номера портов, переписывает содержимое некоторых полей, заново вычисляет контрольную сумму и немедленно посылает отклик. Информация, заключенная в сообщение NTP, позволяет клиенту определить показания часов сервера по отношению к часам клиента и соответствующим образом скорректировать рабочие параметры местных часов. Кроме того, эта информация содержит данные, позволяющие оценить точность и надежность часов сервера и выбрать наилучший эталон времени. Модель клиент-сервер может быть вполне достаточна для локальных сетей, где один сервер обслуживает некоторое количество клиентов. В общем случае NTP требует одновременной работы большого числа распределенных пар партнеров (клиент-сервер), конфигурация которых изменяется динамически. Нужны достаточно сложные алгоритмы управления такой ассоциацией, для обработки данных и контроля множества локальных часов. Процесс передачи, управляемый независимыми таймерами для каждого из партнеров, осуществляет накопление информации в базе данных и посылает сообщения NTP. Каждое сообщение содержит локальную временную метку момента отправки сообщения, ранее полученные временные метки, а также необходимую вспомогательную информацию. Частота посылки сообщений определяется требуемой точностью локальных часов, а также предельными точностями часов партнеров. Процесс приема осуществляет получение сообщений NTP и, возможно, сообщений других протоколов, а также информации от непосредственно подключенных радио-часов. Когда получено сообщение NTP, вычисляется сдвиг между часами партнера и локальными часами, результат заносится в базу данных вместе с другой информацией, необходимой для вычисления ошибок и выбора партнера. Конфигурации сети Субсеть синхронизации представляет собой соединение первичных и вторичных серверов времени, клиентов и каналов передачи данных. Первичные серверы времени синхронизованы непосредственно от эталонов времени, обычно от радио-часов. Вторичные серверы могут быть синхронизованы от первичных серверов или других вторичных серверов времени. Система серверов имеет иерархическую структуру, построенную по схеме клиент-сервер. Понятно, что вторичные серверы обеспечивают более низкую временную точность. Следуя принципам, принятым в телефонной промышленности [BEl86], точность каждого сервера определяется номером слоя (stratum), наивысший уровень (для первичного сервера) имеет номер 1. На современном уровне технологий (радио-часы) точность однократной сверки имеет порядок одной миллисекунды. Точность однократной сверки падает по мере роста значения RTT и его разброса. Для того чтобы избежать сложных расчетов [BRA80], необходимых для оценки точности в каждом конкретном случае, полезно предположить, что средняя ошибка измерения пропорциональна RTT и ее дисперсии. Предполагая, что первичные серверы синхронизованы стандартами времени с известной точностью, можно получить вполне надежную оценку точности синхронизации субсети. Дополнительным фактором является то, что каждый переход от одного слоя к другому предполагает наличие ненадежного сервера времени, который вносит дополнительные ошибки. Алгоритм выбора серверов времени использует разновидность алгоритма маршрутизации Беллмана-Форда, при этом формируется дерево минимальных весов, основанием которого являются первичные сервера. Метрикой расстояния служит номер слоя плюс расстояние синхронизации, которое характеризуется суммой дисперсии и половины абсолютного значения задержки. Такая конструкция способствует тому, что субсеть автоматически реконфигурируется и настраивается на максимально достижимую точность даже при выходе из строя первичных или вторичных серверов времени. Если даже все первичные серверы выйдут из строя или станут недоступными, их функции будут выполнять вторичные серверы, если расстояние до них согласно алгоритму Беллмана-Форда не превышает значения метрики, соответствующего бесконечности (разрыву связи). Если все серверы окажутся на больших расстояниях, субсеть продолжит работу при установках, выполненных при последней синхронизации (коррекции внутренних часов). Даже в этом случае достижима точность порядка миллисекунд в сутки. Если два сервера находятся согласно алгоритму на равных расстояниях, допускается случайный выбор. Форматы данных Все арифметические операции в рамках протокола выполняются в формате с фиксированной запятой. По этой причине все переменные в NTP имеют именно этот формат. Биты пронумерованы слева на право (со старшего бита), начиная с нуля. Жестких требований на число разрядов после запятой не установлено. Если не оговорено обратного, все числа не имеют знака и занимают все отведенное для них поле (при необходимости в качестве заполнителей старших разрядов используются нули). Временные метки NTP представляют собой 64-битные числа с фиксированной запятой без знака, которое указывает число секунд с нуля часов 1-го января 1900 года. Целая часть содержит первые 32 разряда, а дробная часть остальные 32 разряда. Этот формат не совпадает с форматом меток ICMP, где время измеряется в миллисекундах. Точность представления составляет 200 пикосекунд, что должно удовлетворить самым экзотическим требованиям. Временная метка формируется путем копирования показания местных часов. Это производится в момент времени, заданный каким-то событием, например, приходом сообщения. Для поддержания наивысшей точности, важно, чтобы это делалось как можно ближе к оборудованию или программному обеспечению, инициирующего этот процесс. В случае, когда временная метка недоступна, например, производится перезагрузка машин, поле метки характеризуется 64 нулями. Заметим, что с 1968 года старший бит (бит 0 целой части) равен единице, а где-то в 2036 году 64-битовое поле переполнится. Переменные состояния и параметры Ниже приводится обзор различных переменных и параметров, используемых протоколом. Они распределены по классам системных переменных, которые имеют отношение к операционной среде и механизму реализации местных часов. Сюда входят переменные партнеров, которые характеризуют состояние протокольных машин участников обмена, переменные пакетов, описывающие содержимое пересылаемых NTP-сообщений, а также параметры, задающие конфигурацию текущей версии программного обеспечения. Имена переменных записываются строчными буквами, а имена параметров - прописными. Общие переменные Следующие переменные являются общими для двух или более систем, партнеров и классов пакетов. Когда необходимо отличить общие переменные с идентичными именами, вводится идентификатор переменной. Адрес партнера (peer.peeraddr, pkt.peeraddr), порт партнера (peer.peerport, pkt.peerport). 32-битный ip-адрес и 16-битный номер порта партнера. Адрес ЭВМ (peer.hostaddr, pkt.hostaddr), порт ЭВМ (peer.hostport, pkt.hostport). 32-битный IP-адрес и 16-битный номер порта ЭВМ. Эти переменные включаются в переменные состояния для поддержки мультиинтерфейсных систем. Индикатор приращения (sys.leap, peer.leap, pkt.leap) - это двухбитный код предупреждения о включении дополнительных секунд во временную шкалу NTP. Эти биты устанавливаются до 23:59 дня добавления и сбрасываются после 00:00 следующего дня. В результате день, для которого проведена эта процедура, окажется длиннее или короче на одну секунду. Для вторичных серверов эти биты устанавливаются протоколом NTP. Биты 0 и 1 (LI) принимают значения, перечисленные в таблице 4.4.15.1: Таблица 4.4.15.1 Значения кодов индикатора LI
Во всех случаях за исключением аварийного сигнала (alarm = 112), протокол NTP никак не изменяет эти биты, а только передает их программам преобразования времени, которые не являются частью протокола. Аварийная ситуация возникает, когда по какой-либо причине локальные часы оказываются не синхронизованными. Это может случиться в ходе инициализации системы или в случае, когда первичные часы оказываются недоступны в течение длительного времени. Режим (peer.mode, pkt.mode) - это целое 3-битовое число, обозначающее код режима ассоциации, который может принимать значения, приведенные в таблице 4.4.15.2: Таблица 4.4.15.2. Значения кодов Режим
Слой (sys.stratum, peer.stratum, pkt.stratum) - это целое число, указывающее код слоя локальных часов, который может принимать значения приведенные в таблице 4.4.15.3. Таблица 4.4.15.3. Значения кодов слой
Для целей сравнения значение нуль для кода слоя считается выше, чем любая другая величина. Заметим, что максимальное значение целого, закодированное как пакетная переменная, ограничено параметром ntp.maxstratum. Период обмена (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll). Это целая переменная со знаком, указывающая минимальный интервал между передаваемыми сообщениями, измеренный в секундах и представленный как степень 2. Например, значение 6 указывает на минимальный интервал в 64 секунды. Точность (sys.precision, peer.precision, pkt.precision). Это целая переменная со знаком, обозначающая точность часов в секундах и выраженная как ближайшая степень числа 2. Значение должно быть округлено в большую сторону до ближайшего значения степени 2, например, сетевой частоте 50-Гц (20 мс) или 60-Гц (16.67 мс) будет поставлено в соответствие величина -5 (31.25 мс), в то время как кварцевой частоте 1000-Гц (1 мс) будет поставлено в соответствие значение -9 (1.95 мс). Базовая задержка (sys.rootdelay, peer.rootdelay, pkt.rootdelay). Это число с фиксированной запятой со знаком, указывающее на величину полной циклической задержки (RTT) до первичного эталона частоты, выраженной в секундах. Базовая дисперсия (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion). Это число с фиксированной запятой больше нуля, указывающее на максимальное значение временной ошибки по отношению к первичному эталону в секундах. Идентификатор эталонных часов (sys.refid, peer.refid, pkt.refid). Это 32-битовый код, идентифицирующий конкретные эталонные часы. В случае слоя 0 (не специфицирован) или слоя 1 (первичный эталонный источник), 4-октетная ASCII-строка, выровненная по левому краю и дополненная при необходимости нулями, например: Таблица 4.4.15.4. Коды идентификаторов часов
В случае слоя 2 и выше (вторичный эталон) - это 4-октетный IP-адрес партнера, выбранного для синхронизации. Эталонная временная метка (sys.reftime, peer.reftime, pkt.reftime) - локальное время в формате временных меток, соответствующее моменту последней коррекции показаний часов. Если локальные часы не были синхронизованы, переменная содержит нуль. Базовая временная метка (peer.org, pkt.org) - локальное время в формате временных меток, соответствующее моменту посылки последнего NTP-сообщения. Если партнер недостижим, переменная принимает нулевое значение. Временная метка получения (peer.rec, pkt.rec) - локальное время в формате временных меток, соответствующее моменту прихода последнего NTP-сообщения, полученного от партнера. Если партнер недостижим, переменная принимает нулевое значение. Временная метка передачи (peer.xmt, pkt.xmt) - локальное время в формате временных меток, соответствующее моменту отправки NTP-сообщения. Системные переменные Следующие переменные используются операционной системой для синхронизации локальных часов. Переменная локальные часы (sys.clock) содержит показание локальных часов в формате временных меток. Локальное время получается от аппаратных часов конкретной ЭВМ и дискретно увеличивается с конструктивно заданными приращениями. Переменная Базовые часы (sys.peer) представляет собой селектор, идентифицирующий используемый источник синхронизации. Обычно это указатель на структуру, содержащую переменные партнера. Значение нуль указывает, что в настоящее время источник синхронизации отсутствует. Переменные партнера Ниже перечислены все переменные партнера, которые используются для управления и реализации измерительных процедур. Бит конфигурации (peer.config) - бит, индицирующий, что ассоциация была сформирована на основе конфигурационной информации и не должна быть расформирована, когда партнер становится недоступен. Временная метка актуализации (peer.update) - локальное время в формате временной метки, отмечающее момент, когда было получено последнее NTP сообщение. Переменная используется для вычисления дисперсии временного сдвига. Регистр достижимости (peer.reach) - сдвиговый регистр битов ntp.window, используемых для определения статуса достижимости партнера. Ввод данных производится со стороны младших бит (справа). Партнер считается достижимым, если как минимум один бит этого регистра равен 1. Таймер партнера (peer.timer) - целочисленный счетчик, используемый для управления интервалом между последовательно посылаемыми NTP-сообщениями. После установки значения счетчика его содержимое уменьшается на 1 (1сек) пока не достигнет нуля. При этом вызывается процедура передачи. Заметим, что работа этого таймера не должна зависеть от локальных часов. Пакетные переменные Номер версии (pkt.version) - целое число индицирующее номер версии отправителя. NTP сообщения всегда посылаются с текущим значением версии ntp.version и будут восприняты лишь при условии совпадения кодов версии (ntp.version). Исключения допускаются лишь при смене номера версии. Переменные фильтра часов Когда используются фильтры и алгоритмы отбора, дополнительно привлекаются следующие переменные состояния. Регистр фильтра (peer.filter) - сдвиговый регистр каскадов ntp.shift, где каждый каскад запоминает значения измеренной задержки, смещения и вычисленной дисперсии, соответствующих одному наблюдению. Эти три параметра вводятся со стороны старших разрядов и сдвигаются в направлении младших разрядов (направо). При получении результатов нового наблюдения старые результаты теряются. Счетчик корректных данных (peer.valid) - целочисленный счетчик, указывающий на корректные образцы, остающиеся в регистре фильтра. Он используется для определения состояния доступности и для управления увеличением и уменьшением периода рассылки сообщений. Смещение (peer.offset) - число с фиксированной запятой со знаком, индицирующее значение смещение часов партнера по отношению к локальным часам в секундах. Задержка (peer.delay) - число с фиксированной запятой со знаком, индицирующее полную циклическую задержку (RTT) часов партнера по отношению к локальным часам с учетом времени распространения сообщения и отклика в сети в секундах. Заметим, что переменная может принимать как положительное, так и отрицательное значение в зависимости от точности часов и накопившейся ошибки смещения. Дисперсия (peer.dispersion) - число с фиксированной запятой, индицирующее максимальную ошибку часов партнера по отношению к локальным часам с учетом сетевой задержки в секундах. Допускаются только значения больше нуля. Переменные аутентификации При использовании механизма аутентификации привлекаются следующие переменные состояния. Бит разрешения аутентификации (peer.authenable) - бит, указывающий, что ассоциация должна работать в режиме аутентификации. Бит аутентификации (peer.authentic) - бит, индицирующий то, что последнее сообщение, полученное от партнера, было корректно аутентифицировано. Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid) - целое число, идентифицирующее криптографический ключ, использованный при генерации аутентификационного кода сообщения. Криптографические ключи (sys.key) - набор 64-битных ключей DES. Каждый ключ создается в соответствии с берклиевскими UNIX-распределениями, которые состоят из 8 октетов, где 7 младших бит каждого октета соответствуют битам des 1-7, а старший бит соответствует биту четности DES. Контрольная крипто-сумма (pkt.check) - криптографическая контрольная сумма, вычисляемая процедурой шифрации. Параметры Ниже описаны параметры для всех реализаций, работающих в сети Интернет. Необходимо договориться относительно значений этих параметров для того, чтобы исключить ненужную избыточность и стабилизировать ассоциации партнеров. Приведенные параметры применимы для всех ассоциаций. Номер версии (ntp.version) - текущий номер версии NTP (3). Порт NTP (ntp.port) - стандартный номер порта (123), присвоенный протоколу NTP. Максимальный номер слоя (ntp.maxstratum) - максимальный номер слоя, который может быть использован при кодировании пакетной переменной. Этот параметр обычно интерпретируется как определение бесконечности (недостижимости для протокола маршрутизации в субсети). Максимальный возраст часов (ntp.maxage) - максимальный интервал в секундах, в течение которого эталонные часы будут рассматриваться корректными после последней сверки. Максимальный сбой (ntp.maxskew) - максимальная ошибка смещения, связанная со сбоем локальных часов за время ntp.maxage, в секундах. Отношение ntp.maxskew к ntp.maxage интерпретируется как максимальный сбой, вызванный всей совокупностью факторов. Максимальное расстояние (ntp.maxdistance) - максимально допустимое расстояние между партнерами при синхронизации с использованием алгоритма отбора. Минимальный период рассылки (ntp.minpoll) - минимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2. Максимальный период рассылки (ntp.maxpoll) -максимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2. Минимум избранных часов (ntp.minclock) - минимальное число партнеров, необходимое для синхронизации (при использовании алгоритма отбора). Максимум избранных часов (ntp.maxclock) - максимальное число партнеров, необходимое для организации отбора (при использовании алгоритма селекции). Минимальная дисперсия (ntp.mindisperse) - минимальное значение приращения дисперсии для каждого из слоев в секундах (при использовании алгоритма фильтрации). Максимальная дисперсия (ntp.maxdisperse) - максимальная дисперсия в секундах с учетом потерянных данных (при использовании алгоритма фильтрации). Размер регистра доступности (ntp.window) - размер регистра доступности (peer.reach) в битах. Размер фильтра (ntp.shift) - размер сдвигового регистра фильтра часов (peer.filter) в каскадах. Вес фильтра (ntp.filter) - вес, используемый при вычислении дисперсии фильтра (применяется при работе с алгоритмом фильтрации). Выбранный вес (ntp.select) - вес, используемый при вычислении выбранной дисперсии (применяется при работе алгоритма селекции). Режимы работы За исключением широковещательного режима, NTP-ассоциация формируется, когда два партнера обмениваются сообщениями и один или оба из них создает и поддерживает протокольную машину, называемую ассоциацией. Ассоциация может работать в одном из 5 режимов, заданных переменной peer.mode: симметрично активный, симметрично пассивный, клиент, сервер и широковещательный: Симметрично активный (1). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером. Симметрично пассивный (2). Этот тип ассоциации первоначально создается по прибытии сообщения от партнера, работающего в симметрично активном режиме. Он сохраняется, пока партнер достижим и функционирует в слое ниже или равном данной ЭВМ. В противном случае ассоциация распадается. Однако ассоциация будет существовать до тех пор, пока, по крайней мере, одно сообщение не будет послано в качестве отклика. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером. Клиент (3). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ, обычно это сетевая рабочая станция, оповещает о своем намерении быть синхронизованной партнером. Сервер (4). Этот тип ассоциации первоначально создается по прибытии запроса клиента и существует только для отклика на этот запрос. После отклика ассоциация ликвидируется. При работе в этом режиме ЭВМ, обычно рабочая сетевая станция, оповещает о намерении синхронизовать партнера. Широковещательный (5). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от доступности или слоя партнеров. При работе в этом режиме ЭВМ, обычно сетевой сервер времени, который работает в широковещательной среде, оповещает о намерении синхронизовать всех партнеров. ЭВМ, работающая в режиме клиента, иногда посылает NTP-сообщение ЭВМ, работающей в режиме сервера, например, сразу после перезагрузки и периодически после этого. Сервер откликается, меняя адреса и номера портов, занося необходимую информацию и отправляя сообщение назад клиенту. Серверы не должны хранить какую-либо статусную информацию в паузах между запросами клиента, в то время как клиенты могут варьировать интервалы между NTP сообщениями, для того чтобы удовлетворить локальным требованиям. В этих режимах протокольная машина, описанная в этой статье, может быть существенно упрощена без заметной потери точности или надежности особенно при работе в быстродействующей локальной сети. В симметричных режимах отличие клиента от сервера практически исчезает. Симметрично пассивный режим предназначен для использования временными серверами, работающими вблизи базовых узлов (нижний слой) субсети синхронизации и со сравнительно большим числом партнеров. В этом режиме идентификации партнера не требуется заранее, так как ассоциация с ее переменными состояния создана, только когда получено NTP-сообщение. Более того, запомненное состояние может быть использовано позднее, когда партнер станет недостижим или будет работать на более высоком уровне и по этой причине будет непригоден в качестве источника синхронизации. Симметрично активный режим предназначен для использования серверами времени, работающими вблизи оконечных узлов (наивысший слой) синхронизации. Надежный временной сервис обычно может быть реализован с помощью двух партнеров на ближайшем нижележащем слое и одном партнере в том же слое. По этой причине поток сообщений обычно невелик, даже когда связь потеряна, и на каждый запрос приходит отклик об ошибке. В норме, один партнер работает в активном режиме (симметричный активный, клиент или широковещательный), как это сконфигурировано в стартовом файле, в то время как другие работают в пассивном режиме (симметричный пассивный или сервер), часто без предварительной конфигурации. Однако оба партнера могут быть сконфигурированы для работы в симметричном режиме. Условие ошибки возникает, когда оба партнера работают в одном и том же режиме, но не в симметричном активном. В таких случаях каждый партнер будет игнорировать сообщения, поступающие от другого, и ассоциация, если она существовала, будет ликвидирована из-за недостижимости партнера. Широковещательный режим предназначен для работы в скоростных локальных сетях с большим числом рабочих станций, где не требуется высокая точность. При типичном сценарии один или более временных серверов LAN периодически посылают широковещательные сообщения рабочим станциям, которые затем определяют время на основе предварительно заданной задержки распространения порядка нескольких миллисекунд. Обработка событий Существенные события с точки зрения протокола NTP происходят при истечении времени таймеров партнера (peer.timer), один из которых ориентирован специально на данного партнера в активной ассоциации, а также при получении NTP-сообщения от различных партнеров. Событие может произойти как результат команды оператора или обнаруженной ошибки, такой как отказ первичного эталона. Обозначения Алгоритмы фильтрации и селекции NTP используют несколько переменных для хранения значений сдвига часов, RTT и дисперсии. Переменные, относящиеся к партнерам, обычно обозначаются строчными греческими буквами, а для первичного эталона времени используются прописные буквы. Эти алгоритмы базируются на параметре, называемом расстояние синхронизации (l) и вычисляемом с использованием rtt и дисперсии. Дисперсия партнера (e) содержит вклады от ошибок измерения (r) и накопления ошибок дрейфа (skew-error). Каждый раз, когда соответствующие переменные партнеров изменяются, значения дисперсии корректируются. Ниже приводятся основные определения переменных и формулы их вычисления:
q = peer.offset, где d = rtt, q - сдвиг часов, jt - накопление сбоя, j = ntp.maxskew/ntp.maxage, t - момент времени передачи исходной временной метки (на основе t вычисляется q и d), e s - дисперсия фильтра. Переменные, относящиеся к партнеру i, определяются следующим образом: q i = j i,d i = peer.rootdelay + d i, e i = peer.rootdispersion + e i + j t i (максимальная дисперсия часов партнера), l i= e i + |d i|/2, Окончательно, предполагая, что для синхронизации выбран i-ый партнер, система переменных определяется следующим образом: q = комбинированное окончательное смещение (combined final offset),d = d i, e = e i + ex + q, l = l i, где ex дисперсия выбора (select dispersion). Приводимые ниже тексты программ, реализующие вычисления переменных, записаны на условном языке, напоминающем СИ. Процедура передачи Процедура передачи запускается, когда таймер партнера станет равным нулю. В режиме клиента с широковещательным сервером сообщения вообще не посылаются. В режиме сервера сообщения посылаются только в качестве отклика на полученные запросы. Нижеприведенный фрагмент программы инициализирует пакетный буфер и копирует пакетные переменные.
pkt.hostaddr <- peer.peeraddr; pkt.hostport <- peer.peerport; pkt.leap <- sys.leap; pkt.version <- ntp.version; pkt.mode <- peer.mode; pkt.stratum <- sys.stratum; pkt.poll <- peer.hostpoll; pkt.precision <- sys.precision; pkt.rootdelay <- sys.rootdelay; if (sys.leap = 112 or (sys.clock - sys.reftime) > ntp.maxage) skew <- ntp.maxskew; else skew <- j (sys.clock - sys.reftime); {pkt.rootdispersion <- sys.rootdispersion + (1 << sys.precision)} + skew; pkt.refid <- sys.refid; pkt.reftime <- sys.reftime; Временная метка передачи pkt.xmt будет использована позднее, для того чтобы проконтролировать отклик. Таким образом, программа должна сохранить точное переданное значение. Кроме того, порядок копирования временных меток должен быть выбран так, чтобы не понизить точность.
pkt.xmt <- sys.clock; peer.xmt <- pkt.xmt; Регистр доступности сдвигается на одну позицию влево, в освободившийся разряд записывается нуль. Если все биты регистра равны нулю, вызывается процедура очистки (clear procedure) для обнуления фильтра часов и выбора, если необходимо, нового источника синхронизации. Если ассоциация не была сконфигурирована при инициализации, то она ликвидируется.
begin ликвидируем ассоциацию; exit; endif Если корректные данные введены в сдвиговый регистр фильтра хотя бы раз за время предыдущих двух периодов рассылки (младший бит peer.reach равен 1), счетчик корректных данных увеличивается на 1. После восьми таких удачных периодов интервал рассылки увеличивается. Процедура выбора часов вызывается, если необходимо заменить источник синхронизации.
else peer.hostpoll <- peer.hostpoll + 1; else begin
call clock-filter(0, 0, ntp.maxdisperse);
call poll-update; end transmit procedure; Процедура получения Процедура получения выполняется по приходу NTP-сообщения. Она проверяет сообщения, интерпретирует различные режимы и вызывает другие процедуры для фильтрации данных и выбора источника синхронизации. Если номер версии в пакете не соответствует текущей версии, сообщение может быть отброшено. Если получено управляющее сообщение NTP и код режима пакета равен 6 (управление), вызывается процедура управляющего сообщения. IP-адреса отправителя и адресата, а также номера портов устанавливаются соответствующими заданному партнеру. Если соответствия нет, производится новая инсталляция протокольной машины и формируется новая ассоциация. begin receive procedure
if (no matching association)
Вызов процедуры дешифровки осуществляется только в случае применения аутентификации. #ifdef (authentication implemented) Если код режима пакета не равен нулю, он определяет режим на следующем этапе; в противном случае, режим определяется по номеру порта.
else mode <- pkt.mode; case (mode, peer.hostmode) В случае ошибки пакет просто игнорируется, а ассоциация, если она не была предварительно сконфигурирована, ликвидируется. error: if (peer.config = 0) demobilize association; В случае recv пакет обрабатывается, а ассоциация помечается как достижимая при условии 5-8 успешных проверок. Если и проверки с первой по 4-ую проходят успешно (данные корректны), вызывается процедура коррекции показания локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она ликвидируется.
if (valid data) call clock-update; endif else if (peer.config = 0) ликвидировать ассоциацию; break; В случае xmit, пакет обрабатывается и посылается промежуточный отклик. Ассоциация затем ликвидируется.
call transmit; if (peer.config = 0) ликвидировать ассоциацию; break; В случае pkt, пакет обрабатывается, а ассоциация помечается как достижимая при условии, что тесты 5-8 (правильный заголовок), перечисленные в пакетной процедуре, прошли успешно. Если, кроме того, прошли тесты 1-4 (корректные данные), вызывается процедура коррекции показаний локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она сразу после отклика ликвидируется.
if (valid data) call clock-update; endif else if (peer.config = 0) begin
call transmit; ликвидировать ассоциацию; endif endcase end receive procedure; Пакетная процедура Пакетная процедура проверяет корректность сообщения, вычисляет задержку/смещение и вызывает другие процедуры для отбора данных и выбора источника синхронизации. Тест 1 требует, чтобы переданная временная метка отличалась от последней, полученной от того же партнера. Тест 2 требует, чтобы исходная временная метка соответствовала последней метке, посланной тому же партнеру. В случае широковещательного режима (5) rtt=0 и полная точность операции передачи времени будет недостижимой. Однако, полученная точность может быть вполне приемлемой для многих целей. Процедура вызова коррекции времени использует в качестве параметра peer.hostpoll (peer.peerpoll может быть изменено). begin packet procedure
else begin
endif
Тест 3 требует, чтобы исходная и полученная временные метки не были равны нулю. Если любая из них равна нулю, ассоциация не синхронизирована или потеряла доступ в одном или обоих направлениях. test3 <- (pkt.org ≠ 0 and pkt.rec ≠ 0); /* Тест 3 */ rtt и временное смещение по отношению партнера вычисляется следующим образом. Пусть i четное целое число.
d = (ti - ti-3) - (ti-1 - ti - 2), где, как и прежде, j = ntp.maxskew/ntp.maxage. << - обозначает сдвиг кода влево. Значение e представляет собой максимальную ошибку или дисперсию, связанную с ошибкой измерения на стороне ЭВМ, а также накопление ошибок из-за дрейфа локальных часов за время после посылки последнего сообщения, посланного партнером. Дисперсия корректируется процедурой фильтра часов (clock-filter). Рассмотренный метод эквивалентен непрерывному стробированию, которое используется в некоторых телефонных сетях [bel86]. Преимуществом метода является полная независимость от порядка и времени прихода сообщений, а также допустимость потери некоторых пакетов. Очевидно, что достижимые точности зависят от статистических свойств каналов связи. Тест 4 требует, чтобы вычисленная задержка лежала в допустимых пределах: test4 <- (|d| < ntp.maxdisperse И
e
Тест 5 используется, только если реализован механизм аутентификации. Он требует, чтобы либо аутентификация была явно блокирована, либо чтобы аутентификатор в точности соответствовал тому, что описано в процедуре дешифровки. #ifdef (authentication implemented) /* Тест 5 */
Тест 6 требует, чтобы часы партнера были синхронизованы, и время с момента последней коррекции было положительным и меньше чем ntp.maxage.
Тест 7 гарантирует, что ЭВМ не будет синхронизовано от партнера с большим кодом номера слоя.
Тест 8 требует, чтобы заголовок содержал соответствующие коды в полях pkt.rootdelay и pkt.rootdispersion. test6 <- (pkt.leap ≠ 112 and /* Тест 6 */ test7 <- {pkt.stratum ≤ sys.stratum} and /* Тест 7 */ test8 <- (| pkt.rootdelay | << ntp.maxdisperse and /* Тест 8 */ С точки зрения последующей обработки пакеты содержат корректные данные, если успешно проходят тесты 1-4 (test1 & test2 & test3 & test4 = 1), вне зависимости от результатов других тестов. Только пакеты с корректными данными могут использоваться для вычисления смещения (offset), задержки (delay) и дисперсии. Пакеты имеют корректные заголовки, если успешно
проходят тесты 5-8 (test5 & test6 & test7 & test8 = 1), вне зависимости от результатов остальных тестов. Только пакеты с корректными заголовками могут использоваться для определения того, может ли партнер быть выбран в качестве источника синхронизации. Заметим, что тесты 1-2 не используются в широковещательном режиме. Процедура "часовой фильтр" вызывается для вычисления задержки (peer.delay), смещения (peer.offset) и дисперсии (peer.dispersion) для партнера. Спецификация алгоритма часового фильтра не является составной частью протокола NTP. По этой причине описания, приводимые ниже, следует рассматривать как рекомендательные. peer.leap < pkt.leap; /* Копирование переменных пакета */ if (valid data) call clock-filter(q, d, e); /* обработка данных */
Процедура коррекции показаний часов Процедура коррекции показания часов вызывается процедурой приема, когда процедура фильтрации определила корректные значения смещения задержки и дисперсии для данного партнера. call clock-select; /* Выбор базовых часов */ Может так случиться, что локальные часы оказались сброшены. В этом случае вызывается процедура очистки (clear procedure) для каждого из партнеров, чтобы возвратить в исходное состояние фильтр часов, период рассылки и, если необходимо, осуществить выбор нового источника синхронизации. Процедура расстояния вычисляет базовую (root) задержку
d, базовую дисперсию e и базовое расстояние синхронизации l. ЭВМ не будет
синхронизовать выбранного партнера, если расстояние больше чем ntp.maxdistance.
l andistance(peer); /* обновление системных переменных */ if (local clock reset) begin /* если сброс, очистить системные переменные */ sys.peer <- peer; /* если нет, то подстроить локальные часы */ В некоторых конфигурациях системы прецизионный источник временной информации доступен в виде последовательности синхронизующих импульсов, следующих с периодом в одну секунду. Обычно это является дополнением к базовому источнику времязадающей информации, такому как радио-часы или даже сам протокол NTP, для того чтобы обеспечить подсчет секунд, минут, часов и
дней. В этих конфигурациях системные переменные устанавливаются с учетом источника, от которого поступают такие импульсы. Для конфигураций, которые поддерживают первичные эталонные источники, такие как радио-часы или калиброванные атомные часы код слоя устанавливается равным 1, поскольку
именно он является действительным источником синхронизации. Спецификация алгоритмов выбора часов и работы локальных часов не являются составной частью NTP. По этой причине описания этих алгоритмов, представленные ниже, следует рассматривать лишь как рекомендации.
Работа первичных часов (primary-clock procedure)
Когда ЭВМ связана с первичным эталоном времени, таким как радио-часы, удобно ввести информацию об этих часах в базу данных, как если бы это был обычный партнер. В процедуре первичных часов часы запрашиваются раз в минуту или около того, полученный же временной код используется для корректировки показаний местных часов. Когда обнуляется peer.timer для первичного партнера, процедура передачи не вызывается, а посылается запрос радио-часам с использованием ASCII-последовательности, предусмотренной для этого случая. Когда получен корректный временной код от радио-часов, он преобразуется в формат временной метки NTP и корректируются соответствующие
переменные партнера. Величина peer.leap устанавливается в зависимости от состояния бита оповещения временного кода, если таковой имеется, или вручную оператором. Значение для peer.peeraddr, которое становится равно sys.refid, когда вызывается процедура корректировки показаний часов, делается
равным ASCII-строке, описывающей часы. peer.leap <- "from" radio or operator; /* Копирование переменных */ call clock-filter({sys.clock -
peer.rec, 0, 1 << peer.precision}); /* образец процесса */ call clockupdate; /* коррекция локальных часов */
Процедуры инициализации Процедура инициализации вызывается при перезагрузке системы или при повторном запуске демона NTP. Состояние локальных часов при загрузке предполагается неопределенным; однако, некоторые виды оборудования обеспечивают доступ к локальным часам, как в ходе загрузки, так и сразу после нее. Переменная точности определяется внутренней архитектурой оборудования локальных
часов. Аутентификационные переменные используются лишь при реализации механизма аутентификации. Значения этих переменных определяются процедурами, выходящими за рамки протокола NTP. sys.leap <- 112; /* копирование переменных */ for (all configured peers) /* создание конфигурированных ассоциаций */
Процедура initialization-instantiation Эта процедура является аппаратно-зависимой и служит, среди прочего, для формирования ассоциации. Адреса и режимы работы партнеров определяются в процессе чтения при перезагрузке или в результате обработки команд оператора. В случае привлечения механизма аутентификации только аутентифицированный партнер может стать источником синхронизации. peer.peeraddr <- peer ip address; /* копирование переменных */ call clear; /* инициализация ассоциации */
Процедура receive-instantiation Процедура receive-instantiation вызывается процедурой приема, когда обнаруживается новый партнер. Она инициализирует переменные партнера и формирует ассоциацию. Если сообщение получено от партнера, работающего в режиме клиента (3), ЭВМ переводится в режим сервера
(4); в противном случае, она устанавливается в симметрично пассивный режим (2). peer.config <- 0; /* Копирование переменных */ if (pkt.mode = 3) /* Определение режима */ call clear; /* инициализация ассоциации */
Процедура primary clock-instantiation Эта процедура вызывается из процедуры инициализации для того, чтобы установить переменные состояния для первичных часов. Значение peer.precision определяется из спецификации радио-часов и аппаратного интерфейса. Значение peer.rootdispersion номинально равно удесятеренной
максимальной ошибке радио-часов, например, 10 мсек для WWVB или радио-часов goes и 100 мсек для менее точных радио-часов WWV. peer.config <- 1; /* копирование переменных */ call clear; /* инициализация ассоциации */ В некоторых конфигурациях, включающих в себя атомные часы или приемники LORAN-C, первичный эталон может выдавать только секундные импульсы и не предоставлять полного временного кода (числа секунд и пр.). В этих конфигурациях нумерация секунд может быть получена из других источников, таких как радио-часы или даже другие NTP-партнеры. В этих конфигурациях
переменные первичных часов должны отражать особенности первичного эталона, а не источника нумерации секунд. Однако если источник нумерации секунд отказал или работает некорректно, актуализация локальных часов от первичного эталона должна быть заблокирована.
Процедура очистки
Процедура очистки вызывается, когда произошло событие, которое значительно изменило достижимость или вызвало поломку локальных часов. peer.org <- 0 (undefined); /* пометка неопределенных временных меток */ peer.reach <- 0; /* сброс переменных состояния */ peer.filter <- [0, ,0, ntp.maxdisperse]; /* все ступени */ {peer.hostpoll <- ntp.minpoll}; /* первичная установка периода рассылки */ call clock-select; /* Выбор эталонных часов */
Процедура запроса-коррекции (poll-update)
Процедура запросов-коррекции вызывается, когда происходит событие, которое может вызвать изменение периода запросов (рассылки) или таймера партнера. Она проверяет значения периода запросов ЭВМ (peer.hostpoll) и партнера (peer.peerpoll), а также устанавливает их в заданных пределах. temp <- peer.hostpoll; /* определение периода запросов ЭВМ */ Если интервал запросов (рассылок) не изменился, а таймер партнера на нуле, то таймер просто сбрасывается в начальное состояние. Если интервал запросов изменен, и новое значение таймера больше текущего значения, никаких дополнительных действий не требуется; в противном случае величина выдержки таймера партнера должна быть уменьшена. Когда время выдержки
таймера партнера уменьшается, важно исключить тенденцию синхронизации обмена между партнерами. Благоразумной предосторожностью является рэндмизация первой передачи после уменьшения выдержки таймера. if (peer.timer = 0) /* сброс таймера партнера */
Процедура расстояния синхронизации (synchronization distance)
Процедура расстояния вычисляет расстояние синхронизации на основе переменных партнеров. begin distance(peer) procedure; Заметим, что, в то время как d может быть в некоторых случаях отрицательной, e и l всегда положительны.
Замечания о контроле доступа
Конструкция NTP устроена так, что случайная или намеренная модификация данных временного сервера не должна привести к серьезным ошибкам синхронизации. Однако успех этого подхода зависит от дополнительных временных серверов и альтернативных сетевых маршрутов, а также от предположения, что искажения не охватывают большинство временных серверов одновременно.
В принципе уязвимость субсети может быть улучшена разумным выбором временных серверов. Механизм аутентификации также позволяет повысить надежность синхронизации. Следует, правда, принимать во внимание, что шифрование/дешифрование данных заметно ухудшает точность синхронизации. Если требуется более надежная модель, система может базироваться на списке доступа, в который включаются 32-битовый IP-адрес, 32-битовая маска и 3-битовый код режима работы. Если логическое И адреса эталона (pkt.peeraddr) и маски на входе ЭВМ соответствуют соответствующим
адресу и режиму (pkt.mode), доступ разрешается, в противном случае отправителю запроса присылается ICMP-сообщение об ошибке. Список управления доступом служит фильтром, определяющим, какой из партнеров может сформировать ассоциацию.
Алгоритмы фильтрации и селекции
Наиболее важным фактором, влияющим на точность и надежность синхронизации, является набор алгоритмов, используемых для уменьшения статистических ошибок и искажений при сбоях в различных компонентах субсети. Алгоритмы, описанные в этой статье, не являются частью стандарта NTP, по этой причине допускается использование любых других алгоритмов. Для того чтобы NTP алгоритмы фильтрации и отбора работали эффективно, полезно иметь меру вариации для каждого из партнеров. Принятая мера вариации базируется на разностях первого порядка, которые легко вычислить. Существует две меры, одна называемая дисперсией фильтра
es
, и другая дисперсия выбора (select dispersion) ez
. Обе меры вычисляются как взвешенные суммы смещений из списка, сформированного на основе расстояний синхронизации. Если q
i (0ё i < n) смещение i-ой записи, тогда разность e
ij i-ой записи по отношению к j-ой
записи определяется как |q
i - q j|. Дисперсия относительно j-ой записи определяется как e
j =
Существует две процедуры, описанные ниже, процедура "часовой-фильтр" (clock-filter), которая используется для выбора лучших записей смещения для данных часов, и процедура "выбора часов" (clock-selection), которая используется, чтобы выбрать наилучшие часы среди иерархического набора часов.
Процедура часовой фильтр (clock-filter) Процедура часовой фильтр исполняется по прибытии сообщения NTP или другого события, в результате которого получены новые данные. Она использует аргументы (q, d, e), где q - результат измерения смещения часов, содержащийся в
записи, а d и e соответственно RTT и дисперсия. Процедура определяет значение отфильтрованного смещения часов (filtered clock offset - peer.offset), RTT (peer.delay) и дисперсии (peer.dispersion). Она также корректирует дисперсию хранящихся записей и текущее показание часов (peer.update). Процедура часового фильтра использует сдвиговый регистр (peer.filter), который состоит из NTP.SHIFT каскадов, каждый каскад содержит значения q
i, d
i и e i, которые пронумерованы, начиная с нуля, слева направо. Фильтр инициализируется процедурой очистки при этом заносятся значения [0, 0, NTP.MAXDISPERSE] во
всех каскадах. Новые данные записей вдвигаются в фильтр с левого конца. Пакетная процедура выдает записи в формате (q ,d, e), когда приходят новые корректирующие данные, в то время как процедура передачи выдает записи в форме [0, 0, NTP.MAXDISPERSE], когда истекает два периода запроса без поступления свежих данных. Когда одни и те же символы (q,
d, e) используютсядля аргументов, содержимого часового фильтра и переменных партнера, их значения обычно понятно из контекста. Ниже представлена псевдопрограмма, поясняющая работу данной процедуры. begin clock-filter procedure (q,
d, e) Дисперсия e
i для всех корректных записей в регистре фильтра должна корректироваться с тем, чтобы отражать накопление смещения со времени последней коррекции. Эти записи заносятся также во временный список, следуя стандартному формату записей [расстояние, индекс]. Записи в регистре сдвигаются вправо, новые записи вводятся слева, а самая правая запись теряется. Временный список сортируется по значению расстояния. Если в списке не остается записей, процедура прерывается без корректировки переменных партнера. for (i from ntp.size 1 to 1) begin /* коррекция дисперсии */ [q
0, d
0,
e
0] <- [q,
d, e]; /* ввести новую запись */ peer.update <- sys.clock; /* сбросить показание часов */ где [distance ||index] представляет собой объединение полей расстояния и индекса (расстояние занимает старшую позицию). Дисперсия фильтра
es
вычисляется и включается в дисперсию партнера. Заметим, что временный список для этой цели уже упорядочен. for (i from ntp.shift-1 to 0) /* вычисление дисперсии фильтра */ Смещение партнера q
0, задержка d
0 и дисперсия e
0 выбираются как величины, соответствующие записи с минимальным расстоянием; другими словами, записи, соответствующей первому элементу временного списка (в данной нотации имеет индекс 0). peer.offset <- q
0; /* корректировка переменных партнера */ Переменные peer.offset и peer.delay представляют смещение шкалы часов и RTT для локальных часов, измеренные относительно часов партнера. Обе они усредняются по большому числу измерений в течение длительного периода времени. Переменная peer.dispersion характеризует максимальную ошибку из-за неточности измерений, дрейфа и вариации записей. Все три переменные
используются при выборе часов для синхронизации.
Процедура выбора часов Процедура выбора часов использует переменные партнера q, d, e и t, она вызывается, когда эти переменные изменились или изменился статус доступности. Процедура включает в себя две составные части: алгоритм пересечения (intersection algorithm) и
алгоритм кластеризации (clustering algorithm). Алгоритм пересечения подготавливает список кандидатов партнеров, могущих стать источниками синхронизации и вычисляет доверительный интервал для каждого из них. Алгоритм кластеризации сортирует список кандидатов по кодам слоя и расстояния
синхронизации. Системная переменная sys.peer представляет собой указатель на наиболее вероятного кандидата, если таковой имеется, или на нулевую величину в противном случае.
Алгоритм пересечения begin clock-selection procedure Каждый из партнеров просматривается последовательно и добавляется в конец списка, если он прошел ряд тестов. Для каждого из m кандидатов в список заносятся 3 записи в форме [указатель, тип]: [q - l, - 1],
[q, 0] и [q + l, 1]. В результате в списке будет 3m записей, которые будут позднее упорядочены. for (each peer) /*обращение ко всем партнерам */ andistance (peer); /* запись в список */ if (m = 0) begin /* уход, если кандидаты отсутствуют */ Ниже приведенный алгоритм представляет собой адаптированную версию DTS [DEC89] и сконструирован так, чтобы отбирать только истинных кандидатов. Алгоритм начинается с инициализации значения f и занесения нуля в счетчики i и c. Затем, начиная с конца упорядоченного, для каждой записи [указатель, тип] значение типа вычитается из кода счетчика i, который
содержит число пересечений. Если код типа равен нулю, инкрементируется значение c, которое регистрирует число ложных кандидатов. Если для некоторых записей i Ё ≥ m - f, конец записи становится нижней границей пересечения; в противном случае, f увеличивается на 1 и процедура повторяется. Без сброса значений f или c, аналогичная процедура используется для нахождения верхней границы, за исключением того, что
значение кода тип добавляется к счетчику. Если после того как обе границы определены c ё f, процедура продолжается для найденных m - f кандидатов, в противном случае, f увеличивается на 1 и вся процедура повторяется. for (f from 0 to f ≥ m/2) begin /* обращение ко всем кандидатам */ for (each [endpoint, type] from lowest) begin /* нахождение нижней границы */ for (each [endpoint, type] from highest) begin /* нахождение верхней границы */ if (c ≤ f) break; /* продолжить, пока не будут найдены все ложные
кандидаты */ if (low > high) begin /* завершить, если не найдено ни одного
пересечения */ Заметим, что работа продолжается далее данной точки, только если имеется более m/2 пересечений. Однако возможно, но не слишком вероятно, что в области пересечения окажется менее m/2 кандидатов.
Алгоритм кластеризации
В исходном алгоритме DTS процедура выбора часов прерывается в данной точке с выбором кандидатов из центра области пересечения. Однако это ведет к заметной потере точности и стабильности, так как не учитываются индивидуальные статистические свойства партнеров. Следовательно, в NTP только кандидаты, которые остаются в результате описанного выше отбора, могут участвовать в последующей обработке. Список кандидатов преобразуется к форме [расстояние, индекс], где расстояние вычисляется на основе кода слоя и расстояния синхронизации l партнера.
Масштабный коэффициент позволяет реализовать механизм весового учета вкладов от кодов слоя и расстояния. Обычно, код слоя доминирует, если только один или более кандидатов имеют слишком большие расстояния. Список упорядочивается согласно величине расстояния. for (each peer) begin /* обращение ко всем партнерам */
l <- distance (peer); /* сформировать запись в списке */ Последующие шаги служат для того, чтобы отсеять кандидатов со слишком большими дисперсиями. Практика показывает, что число кандидатов здесь может быть достаточно велико. Это может привести к большому числу циклов повторения процедуры отбора, которые не дадут какого-либо улучшения результатов. Длина списка кандидатов ограничивается переменной
ntp.maxclock. Заметим, что exi представляет собой дисперсию относительно i-го партнера из списка кандидатов, которая может быть вычислена методом дисперсии фильтра, описанным выше. e
j - дисперсия j-ого партнера из списка, включающая в себя вклады от ошибок измерения, от накопления дрейфа и из-за
дисперсии фильтра. Если максимальное значение exi больше
чем минимальное значение e
j, а число кандидатов больше чем ntp.minclock, i-ый партнер удаляется из списка и процедура повторяется. Если текущий источник синхронизации является одним из членов списка и нет других кандидатов из более низкого слоя, процедура прерывается, и никакие другие последующие шаги не предпринимаются. В противном случае в качестве источника синхронизации берется первый кандидат из списка. В ниже приведенном тексте i, j, k, l - индексы партнеров, k - индекс текущего источника синхронизации (нуль, если такой источник отсутствует), l - индекс первого кандидата в списке. for (each survivor [distance, index]) begin /* вычисление дисперсии */ peer.survivor [i] <- 0; /* отбрасывание i-го партнера */ Алгоритм сконструирован так, чтобы отдавать предпочтение партнерам из головной части списка, которые размещены в более низком слое, имеют наименьшее расстояние и могут обеспечить наибольшую точность и стабильность. С помощью правильного выбора весового коэффициента v (называемого ntp.select), можно удалить некоторые записи из финальной части списка.
Локальные часы
Для того чтобы иметь точные локальные часы, ЭВМ должна быть оборудована аппаратными часами, состоящими из задающего генератора и интерфейса, обеспечивающего необходимые операции установки и коррекции. Логические часы конструируются, используя эти компоненты и программы, которые осуществляют подстройку частоты и абсолютного показания локальных часов. Такая
система позволяет достичь точности времени до 15 нс и стабильности частоты на уровне 0.3 мс в день. Предлагаемая модель удобна для применения как для компенсируемых, так и для некомпенсируемых кварцевых генераторов, пригодна она и для часов, использующих для создания временной шкалы частоту сети переменного тока. Важно заметить, что конкретная описанная реализация является лишь одной из многих возможных.
Реализация "пушистый шарик" (Fuzzball)
Локальные часы "пушистый шарик" представляют собой комбинация аппаратных и программных регистров, а также алгоритмов, которые осуществляют функционирование часов - работу управляемого задающего генератора, синхронизуемого от внешнего источника. Долее следует описание его компонент и способа работы. Заметим, что все числа представлены в представлении дополнений до 2, а все сдвиги являются арифметическими (заполнение знаком при сдвиге вправо и нулем при сдвиге влево). 48-битовый часовой регистр (clock) и 32-битовый предварительный счетчик (prescaler) образуют управляемый задающий генератор с периодом 1 мс. Дробная часть кода времени представляет число миллисекунд с начала суток. 32-битовый регистр коррекций (Clock-Adjust) используется для подстройки фазы часов постепенными шагами, что исключает неоднородности временной шкалы. Его содержимое обозначается x. 32-битовый регистр
компенсации дрейфа (Skew-Compensation) используется для подстройки частоты задающего генератора с помощью добавления небольших фазовых сдвигов (0,01%). Его содержимое обозначается символом y. 16-битовый счетчик оповещения (Watchdog) и 32-битный регистр согласования (Compliance) используются для определения корректности и служит также для задания периода рассылки запросов.
Содержимое регистра согласования обозначается символом z. 32-битовый регистр настройки (PPS-Adjust) служит для подстройки точности, когда имеется точный источник сигналов с периодом в одну секунду. 2-битовый регистр флагов управляет добавлением/вычитанием секунд к показаниям часов, когда это необходимо. Все регистры кроме предварительного счетчика обычно размещаются в памяти. В типовом интерфейсе часов, таком как DEC KWV11-C, регистр prescaler реализован в виде 16-битового буферного счетчика, управляемого кварцевым генератором с частотой, кратной 1000 Гц. Переполнение
счетчика вызывает прерывание процессора, которое осуществляет приращение содержимого регистра часов. Когда наступает момент подстройки, CLOCK.ADJ секунд вычитается из содержимого PPS-счетчика, но это CLOCK.ADJ делается лишь при условии, что там лежит число больше нуля. CLOCK.ADJ добавляется к коду счетчика Watchdog. Этот код не должен превышать значения NTP.MAXAGE,
поделенного на CLOCK.ADJ. Если счетчик Watchdog достигнет этой величины, часы считаются не синхронизованными, а Leap-биты устанавливаются равными 112.
Постепенная настройка фазы
Если локальные часы нескорректированы, они продолжают работать со смещением и частотой (при отсутствии дрейфа), установленными при последней коррекции. Корректирующая информация имеет формат 48-битного целого числа со знаком. Это число характеризует целое и дробное число миллисекунд (запятая располагается после 32-го двоичного разряда). Если полученная величина превосходит максимальное значение, заданное CLOCK.MAX, необходима постепенная
пошаговая коррекция. В норме величина поправки вычисляется в рамках алгоритма NTP. Однако, если код счетчика PPS больше нуля, вместо него должен использоваться регистр PPS-ADJUST. Пусть u представляет собой 32-битовый код с битами 0-31 равными разрядам 16-47 корректирующего кода. Если некоторые младшие биты корректирующего кода не используются, они устанавливаются
равными биту знака. Такие операции сдвигают положение запятой влево по отношению биту 16, что уменьшает влияние ошибок округления. Пусть b число начальных нулей в коде регистра Compliance и пусть c - число начальных нулей в коде счетчика W@atchdog. Тогда b установится равным: b = b - 16 + clock.comp
b не должно быть меньше нуля (это логарифм постоянной времени обратной связи). Затем установим c равным: c = 10 - c Величина c представляет собой логарифм времени интегрирования со времени последней коррекции. Затем вычисляются новые значения кодов для регистров CLOCK.ADJUST и Skew-Compensation. x = u >> b, В заключение вычисляем экспоненциальное среднее z = z + (u << (b + clock.mult) - z) >> clock.weight, где сдвиг влево переносит положения запятой с целью достижения большей точности. Для каждого периода подстройки определяется корректирующий код из двух составляющих. Первая составляющая (фаза) определяется как x >> clock.phase, эта величина затем вычитается из предшествующего значения регистра Clock-Adjust. Результат становится новым значением кода этого регистра. Вторая компонента - (частота) определяется как y >> clock.freq. Совокупность фазы и частоты представляет собой окончательный корректирующий код, который затем добавляется к коду регистра (clock). В заключение, счетчик Watchdog обнуляется. Величина b вычисленная ранее может использоваться для изменения величины системной переменной, характеризующей период запросов (коррекций) sys.poll. sys.poll <- b + NTP.MINPOLL. При условии, что шум коррекций велик, частота аппаратного задающего генератора может меняться быстро из-за изменений условий окружающей среды. В этом случае период запросов укорачивается. Когда шум незначителен, задающий генератор стабилен и период запросов растет вплоть до NTP.MAXPOLL секунд.
Ступенчатая подстройка фазы
Когда величина поправки превышает CLOCK.MAX, имеется возможность того, что часы окажутся настолько не синхронизованы, что наилучшим решением будет немедленная замена содержимого регистра часов. Однако, в случаях, когда вариация записи весьма высока, разумно не поверить в возможность скачкообразного изменения, если только со времени последней коррекции не
прошло достаточно много времени. Следовательно, если обнаружено скачкообразное изменение, а счетчик Watchdog содержит код меньше предварительно установленного значения CLOCK.MINSTEP, корректирующее сообщение игнорируется. Если обнаружено ступенчатое изменение, коррекция заносится непосредственно в регистры Clock, а содержимое регистров Clock-Adjust и Watchdog обнуляется. Другие же регистры остаются без изменений. Так как ступенчатое изменение показаний указывает на некорректность информации в часовых фильтрах (clock filters), биты добавления делаются равными 112 (не
синхронизовано) и вызывается процедура очистки часовых фильтров и переменных состояния для всех партнеров. На практике необходимость корректировать показания часов скачкообразно случается крайне редко, когда, например, локальные часы или эталон перезагружаются. Практически значения CLOCK.MAX могут быть превышены временным сервером лишь в условиях чрезмерной перегрузки канала или при сбоях оборудования. Наиболее часто встречаемый случай - это смена сервера при регистрации слишком большого числа ошибок или из-за сильной вариации задержки. Рекомендуется, чтобы реализации программ включали средства формирования
значений CLOCK.MAX для особых случаев. Величина, на которую можно превысить CLOCK.MAX, не нарушая требования монотонности, зависит от значения приращения регистра часов (Clock Register).
Обсуждение реализации
Базовая модель надежности NTP предполагает, что не должно быть никаких других способов изменения показаний кроме предусмотренных самим протоколом NTP. Системы с часами-календарем, имеющие питание от батареи или аккумулятора, считаются надежными, но менее точными, чем использующие NTP-синхронизацию. При последовательных коррекциях, если величина поправки превышает конфигурационный параметр (напр., 1000 секунд), поправка отбрасывается и посылается сообщение об ошибке. Некоторые реализации периодически записывают содержимое регистра Skew-Compensation (компенсация дрейфа) в системный файл или в NVRAM (память, сохраняемая при
отключении питания). Преобразование из формата NTP в обычный информационный формат осуществляется прикладными программами. В день накануне добавления/вычитания секунды из показаний времени значение sys.leap устанавливается на первичном сервере вручную. Следует иметь в виду, что
большинство радио-часов не имеет автоматических или ручных средств добавления/вычитания секунд. Но даже в случае некорректного добавления/вычитания секунды локальные часы будут вновь синхронизованы не позднее чем через число секунд, заданное CLOCK.MINSTEP.
Приложение А. Формат данных NTP - версия 3
Формат NTP-сообщения, которое следует сразу после UDP-заголовка, показан на рис 4.4.15.1.
Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1.
Рис. 4.4.15.1. Формат сообщения NTP.
Номер версии (VN) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).
Режим (Mode) - трехбитовое поле, определяющее режим, значения кодов режима приведены в таблице 4.4.15.2.
Слой
(Stratum) - 8-битовое поле, определяющее код слоя, где работают локальные часы. Коды слоя представлены в таблице 4.4.15.3. Возможные значения кодов лежат в интервале от нуля до NTP.INFIN включительно.
Период запросов (poll interval) - 8-битовое поле, указывающее на максимальное значение интервала между запросами. Код, записанный в этом поле, интерпретируется как целое число со знаком и характеризует значение периода в секундах, как ближайшее к величине степени двух. Коды, которые могут быть записаны в этом поле, должны лежать в
интервале между NTP.MAXPOLL и NTP.MAXPOLL включительно.
Точность (precision) - 8-битовое поле, обозначающее точность локальных часов в секундах. Код поля интерпретируется как целая степень со знаком числа 2.
Базовая задержка (Root Delay) - 32-битовое поле, характеризующее RTT до эталонного источника в секундах. Код поля интерпретируется как число с фиксированной запятой, размещенной между битами 15 и 16. Заметим, что величина этого кода может иметь и отрицательное значение (зависит от точности часов и величины дрейфа).
Базовая дисперсия (Root Dispersion) - 32-битовое поле, определяющее максимальную ошибку по отношению к эталонному источнику в секундах. Код поля интерпретируется как число с фиксированной запятой (между 15 и 16 битами). Допустимы только положительные значения.
Идентификатор эталонных часов (Reference Clock Identifier) - 32-битовое поле, идентифицирующее конкретные эталонные часы. В случае кода слоя нуль (не специфицировано) или слоя 1 (первичный эталон), это 4-октетная комбинация выравнивается по левому краю и дополняется нулями (ASCII). Когда идентификатор в NTP не специфицирован, предлагаются
ascii- идентификаторы, приведенные в таблице 4.4.15.4. В случае слоя 2 и больше (вторичный эталон) - это 4-октетный IP-адрес ЭВМ - первичного эталона.
Эталонная временная метка (Reference Timestamp) - поле локального времени (64-битовый формат временных меток), когда часы корректировались в последний раз.
Исходная временная метка (Originate Timestamp) определяет время, когда запрос направлен серверу (стандартный 64-битовый формат временных меток).
Получаемая временная метка (Receive Timestamp) - время, когда запрос прибыл к серверу (стандартный 64-битовый формат временных меток).
Передаваемая временная метка (Transmit Timestamp) - локальное время, когда послан отклик сервером (стандартный 64-битовый формат временных меток).
Аутентификатор (authenticator) (опционно) - поле, содержащее аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.
Приложение Б. Сообщения управления NTP
В сетевой среде должны быть средства управления программами NTP, такие как установка индикатора добавления секунды (Leap-Indicator) со стороны первичного сервера, настройка различных системных параметров и процедур мониторинга. Такие операции могут быть реализованы с привлечением протокола snmp и соответствующего расширения базы данных MIB. Однако в тех случаях,
когда такие средства недоступны, эти функции могут быть реализованы с помощью специальных управляющих NTP-сообщений. Управляющие сообщения NTP имеют код 6 в поле режима первого октета NTP-заголовка. Формат поля данных специфичен для каждой из команд или отклика. Однако, в большинстве случаев формат конструируется так, чтобы облегчить его непосредственное чтение. Как правило, он состоит из ASCII-строк. Если используется аутентификатор, поле данных дополняется нулями до границы, кратной целому числу 32-битных слов. IP-ЭВМ не должны обрабатывать дейтограммы длиннее 576 октетов; однако, некоторые команды или отклики могут содержать данные, непомещающиеся в одну дейтограмму. Для решения данной проблемы все октеты сообщения нумеруются, начиная с нуля. При передаче фрагментов
сообщения номер первого октета записывается в поле смещения (offset), а число октетов в поле длины. Бит (M - more) устанавливается во всех фрагментах за исключением последнего. Большинство контрольных функций включает посылку команды и получение отклика. Отправитель выбирает ненулевой порядковый номер и устанавливает статусное поле и биты R и E равными нулю. Получатель интерпретирует код операции и дополнительную информацию, содержащуюся
в поле данных, вносит изменение в поле статуса и устанавливает бит R=1, а также возвращает три 32-битного слова заголовка вместе с другой дополнительной информацией поля данных. В случае неверного формата сообщения или ошибки в поле данных получатель заносит соответствующий код в поле статуса, устанавливает биты R и E равными 1, и опционно записывает диагностическое сообщение
в поле данных. Некоторые команды осуществляют чтение или запись для системных переменных и переменных партнеров для ассоциации, идентифицированной в команде. Другие читают или записывают значения переменных, связанных с радио-часами и другими приборами, имеющими непосредственное отношение к эталонам времени. Для определения ассоциации используется ее 16-битовый идентификатор.
Для системных переменных используется идентификатор нуль. Управляющий объект может затребовать текущий список идентификаторов с тем, чтобы их использовать в дальнейшем. При попытке употребить уже недействительный идентификатор будет прислан соответствующий отклик, после чего необходимо запросить список идентификаторов еще раз. Некоторые события, такие как изменение статуса доступа к партнеру, не сопряжены с какими-либо командами и происходят асинхронно. Программа может запоминать информацию о таких событиях и пересылать ее в откликах. Текущий статус и краткая аннотация чрезвычайных событий
пересылаются каждым откликом. Биты в статусном поле указывают на то, произошло ли какое-либо событие с момента предыдущего отклика и было ли их больше одного.
Формат сообщений управления NTP Формат заголовков управляющих NTP-сообщений показан на рис. 4.4.15.2. Этот заголовок располагается непосредственно вслед за UDP-заголовком.
Рис. 4.4.15.2. Формат управляющего сообщения ntp Первые два бита, обозначенные ZZ, должны всегда содержать 0.
Номер версии (VN - version number) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).
Режим (Mode) - трехбитовое поле, определяющее режим, значение кода режима для управляющих сообщений равно 6.
Бит отклика (R) - равен нулю для команд и 1 для откликов.
Бит ошибки (E) - равен нулю для нормального отклика и 1 в случае ошибки.
Бит продолжения (M - more) - равен нулю для последнего фрагмента и 1 - для всех остальных.
Код операции (OP) - 5-битовое поле, определяющее код команды. Значения кодов и их функции представлены в таблице 4.4.15.5.
Таблица 4.4.15.5. Коду операции управляющего сообщения Код Функция 0 Зарезервировано 1 чтение статуса команда/отклик 2 чтение переменной команда/отклик 3 запись переменной команда/отклик 4 чтение переменных часов команда/отклик 5 запись переменных часов команда/отклик 6 установка адреса/порта trap команда/отклик 7 отклик на Trap 8-31 Зарезервировано на будущее Порядковый номер (Sequence) - 16-битовое поле, определяющее номер запроса или отклика, и облегчающее определения их соответствия. Статус - 16-битовое поле, содержащее код статуса системы, партнера или часов. Идентификатор ассоциации (Association ID) - 16-битовое поле, несущее в себе идентификатор ассоциации. Смещение (Offset) - 16-битовое поле, определяющее положение первого октета поля данных в сообщении, передаваемом в нескольких дейтограммах (позиция задается в октетах). Длина (Count) - 16-битовое поле, определяющее длину поля данных в октетах. Данные - это поле содержит информацию сообщения, как для команды, так и для отклика. Максимальное число октетов в поле данных равно 468. Аутентификатор (опционно). Поле, содержащие аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации. Статусные слова Статусные слова указывают на текущее состояние системы ассоциации и часов. Эти слова интерпретируются программами сетевого мониторинга и имеют 4 разных 16-битовых форматов. Статусные слова партнеров и системы соответствуют откликам для всех команд за исключением случая чтения/записи переменных часов и установки адреса/порта для TRAP. Идентификатор ассоциации нуль соответствует системным статусным словам, в то время как ненулевой идентификатор указывает на какую-то конкретную ассоциацию. Статусное слово, присланное в ответ на команду чтения или записи переменной часов, указывает на состояние оборудования и кодирующего программного обеспечения. Системные статусные слова Системное статусное слово может присутствовать в статусном поле отклика. Системное статусное слово имеет следующий формат. Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1. Источник часов (clock source) - 6-битовое поле, указывающее на используемый в данный момент источник синхронизации. Назначение кодов этого поля описано в таблице 4.4.15.6. Таблица 4.4.15.6. Коды источников временного эталона
Системный счетчик событий - четырех битовое целое число, обозначающее число событий, происшедших с момента последнего получения статусного слова системы. Счетчик обнуляется, когда присылается в статусном поле отклика и остается неизменным после достижения значения 15. Код системного события - четырехбитовое число, идентифицирующее последнее системное событие, новое значение переписывает предыдущее. Коды событий перечислены в таблице 4.4.15.7. Таблица 4.4.15.7. Коды системных событий
Статусное слово партнера Статусное слово партнера возвращается в статусном поле отклика на команду чтения статуса, а также чтения или записи переменных. Это слово появляется в списке идентификаторов ассоциации и статусных слов, присылаемых в ответ на команду чтения статуса с нулевым идентификатором ассоциации. Формат статусного слова партнера содержит следующие поля (рис. 4.4.15.3)
Рис. 4.4.15.3. Форматы статусных слов Статус партнера - 5-битный код, характеризующий состояние партнера, определяемого процедурой обмена. Значения этого поля представлены в таблице 4.4.15.8. Таблица 4.4.15.8. Коды состояния партнера
Выбор партнера (Sel) - 3-битный код, говорящий о состоянии партнера, определенного в результате процедуры выбора часов. Значения кодов представлены в таблице 4.4.15.9. Таблица 4.4.15.9. Коды выбора партнера
Счетчик событий партнера - 4-битовое число событий (exception) партнера, которые имели место со времени последнего получения статусного слова в рамках отклика или сообщения TRAP. Счетчик сбрасывается при занесении кода в поле статуса отклика, и перестает изменяться при достижении значения 15. Код события партнера - 4-битовое целое число, идентифицирующее последнее событие партнера. Новое значение переписывает предыдущее. Значения кодов представлены в таблице 4.4.15.10. Таблица 4.4.15.10. Коды события партнера >
Слово состояния часов Существует два способа подключить эталонные часы к NTP-серверу, как специальный прибор, поддерживаемый операционной системой или как партнера, управляемого NTP. Как и в случае команды чтения статуса идентификатор ассоциации определяет, часы какого из партнеров имеются в виду. При нулевом идентификаторе речь идет о системных часах. Протокол поддерживает только одни системные часы, число часов-партнеров практически не ограничено. Статусное слово часов системы или партнера записывается в поле статуса отклика на команды чтения или записи переменных, характеризующих часы. Это слово может рассматриваться как расширение системного статусного слова или статусного слова партнера. Формат слова описан ниже (См. также рис. 4.4.15.3). Состояние часов - 8-битовое число, характеризующее текущее состояние часов. Допустимые значения этого числа и их смысл представлены в таблице 4.4.15.11. Таблица 4.4.15.11. Коды состояния часов
Код события для часов - 8-битовый код, идентифицирующий последнее событие для данных часов (exception). Новое значение переписывает предыдущее значение кода. Когда значение кода становится ненулевым для поля статуса радио-часов, этот код копируется в статусное поле кода события и считается, что произошло событие для системных часов или часов партнера. Слово состояния ошибки Статусное слово ошибки присылается в поле статуса отклика, если обнаружена ошибка в формате сообщения или в его содержимом. Его присутствие указывается равенствами E (error) и R (response) битов 1. Коды ошибки и их значения собраны в таблице 4.4.15.12. Таблица 4.4.15.12. Коды ошибки
Команды Команды состоят из заголовка и опционного поля данных. Если поле данных присутствует, оно включает в себя список идентификаторов и, возможно, их значений.
где Команды интерпретируются следующим образом: Чтение статуса (1). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Команда работает по-разному в зависимости от значения идентификатора. Если идентификатор не равен нулю, отклик содержит идентификатор партнера и статусное слово. Если идентификатор ассоциации равен нулю, отклик содержит системный идентификатор (0) и статусное слово, в то время как поле данных содержит список пар двоичных кодов: <идентификатор ассоциации> <статусное слово>, по одному на каждую, определенную в данный момент ассоциацию. Чтение переменных (2). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Если идентификатор ассоциации не равен нулю, отклик включает в себя идентификатор запрашиваемого партнера и его статусное слово, в то время как в поле данных записывается список переменных партнера и их значения. Если идентификатор ассоциации равен нулю, поле данных содержит список системных переменных и их значения. Если партнер выбран в качестве источника синхронизации, отклик включает в себя идентификатор партнера и его статусное слово. Запись переменных (3). Поле данных команды содержит список присвоений, описанный выше. Отклик идентичен отклику на команду чтения переменных. Чтение переменных часов (4). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Идентификатор ассоциации выбирает переменные системных часов или партнера точно также, как в случае команды чтения переменных. Отклик включает в себя запрошенные идентификатор часов и статусное слово, а поле данных несет в себе список переменных часов и их значений, включая последний временной код, полученный от часов. Запись переменных часов (5). Поле данных команды содержит список присвоений, как это описано выше. Отклик имеет формат, как в случае команду чтения переменных часов. Установка адреса/порта Trap (6). Идентификатор ассоциации команды, статус и поле данных игнорируются. Адрес и номер порта для последующих TRAP-сообщений берутся из самого управляющего сообщения. Исходное значение счетчика TRAP для сообщений откликов заимствуется из поля номера по порядку. Идентификатор ассоциации, статус и поле данных в отклике несущественны. Отклик на TRAP (7). Это сообщение посылается, когда происходит событие (exception) в систему, у партнера или для данных часов. Код команды равен 7, а бит R=1. Содержимое trap-счетчика увеличивается на 1 для каждого сообщения данного типа. Поле номер по порядку сообщения равно содержимому этого счетчика. При посылке сообщения TRAP используется IP-адрес и номер порта, заданные командой установки адреса и порта TRAP. В случае системного TRAP идентификатор ассоциации устанавливается равным нулю, а поле статус содержит статусное слово системы. В случае TRAP партнера поле идентификатора ассоциации соответствует партнеру, а поле статус несет в себе его статусное слово. В поле данных опционно может быть включено любое символьное сообщение (ASCII). Приложение В. Аутентификация Требования надежности NTP подобны аналогичным для других протоколов, работающих с большим числом партнеров и служащих для маршрутизации, управления и доступа к файлам. Система должна противостоять случайным ошибкам и злонамеренным действиям. Механизм управления доступом в NTP отвечает всем базовым требованиям. Различные проверки препятствуют большинству возможных атак, связанных с подменой временных меток. Однако имеется возможность того, что хакер нарушит процедуру синхронизации путем модификации NTP-сообщений. Для подавления такой возможности нужно привлекать криптографические механизмы аутентификации (в частности сертификаты). Механизм, который работает на прикладном уровне, служит для того, чтобы исключить неавторизованную модификацию потока сообщений. Это достигается с помощью контрольных крипто-сумм, вычисляемых отправителем и проверяемых получателем. Однако сам протокол NTP не имеет средств для работы с сертификатами и ключами. Процедура вычисления контрольной крипто-суммы использует алгоритм DES (Data Encryption Standard) [NBS77]. Механизм аутентификации NTP Когда предполагается использовать аутентификацию, инициализируется ряд переменных, определяющих выбор сертификата, алгоритма шифрования и крипто-ключ и, возможно, другие параметры. Процедуры инициализации и выбора этих переменных не регламентируются протоколом NTP. Набор переменных партнера и пакетов может включать в себя следующие компоненты: Бит разрешения аутентификации (peer.authenable). Этот бит указывает, что ассоциация работает в режиме аутентификации. Для сконфигурированных партнеров этот бит определяется на фазе инициализации. Для неконфигурированных - этот бит делается равным 1, если приходящее сообщение содержит аутентификатор, в противном случае =0. Бит аутентификации (peer.authentic). Этот бит указывает, что последнее сообщение, полученное от партнера, было корректно аутентифицировано. Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid). Это целое число идентифицирует криптографический ключ, используемый для генерации кода аутентификации сообщения. Системная переменная peer.hostkeyid используется для активной ассоциации. Переменная peer.peerkeyid инициализируется нулем, когда ассоциация сформирована. Криптографические ключи (sys.key). Это набор 64-битовых ключей DES, где 7 младших бит каждого октета соответствуют битам 1-7 DES, а старший бит соответствует биту четности 8 (сумма нечетна). Контрольная крипто-сумма (pkt.check). Крипто-сумма вычисляется процедурой шифрования. Поле аутентификатора состоит из двух субполей, одно содержит переменную pkt.keyid, а другое переменную pkt.check, вычисленную программой шифрования, вызываемой процедурой передачи протокола NTP, а также программой дешифровки, которая вызывается процедурой приема NTP. Ее присутствия определяется по общей длине UDP-дейтограммы. Для целей аутентификации NTP-сообщение дополняется нулями, для того чтобы сделать ее длину кратной 64 битам. Аутентификатор содержит 96 бит, куда входят 32-битовый идентификатор ключа и 64-битовая крипто-сумма. Дополнительная информация (например, о сертификате и алгоритме шифрования), если необходимо, может быть вставлена между NTP-сообщением и идентификатором ключа. Подобно аутентификатору эта информация не включается в контрольное крипто-суммирование. Процедуры аутентификации NTP Когда используется аутентификация для реализации протокола NTP, привлекается две дополнительные процедуры. Одна из них формирует крипто-сумму для передаваемых сообщений, а другая дешифрует и проверяет корректность контрольной суммы получаемых сообщений. Процедуры представляют собой варианты программ, используемых для реализации алгоритма DES и описанных в [NBS80]. На самом деле процедура не связана жестко с алгоритмом DES, а лишь предполагают работу с 64-битовыми блоками данных. Приложение Г. Временная шкала NTP и ее хронометрия Ниже рассматривается соответствие временной шкалы NTP и UTC (Coordinated Universal Time). Синхронизация часов предполагает их согласование по частоте и времени. Для синхронизации необходимо уметь сравнить их частоты и показания. Базовыми источниками временных стандартов традиционно являлись периоды движения Земли, Луны и других космических объектов. К сожалению, они не слишком стабильны. Первичная частота и стандарты времени Первичными стандартами частоты являются осцилляторы с высокой стабильностью. Такие стандарты используют межуровневые переходы в атомах водорода, цезия и рубидия. В таблице 4.4.15.12 приведены характеристики типичных стандартов времени. Локальные же часы обычно используют некомпенсированные кварцевые генераторы. Такие генераторы не только подвержены дрейфам под действием изменения параметров окружающей среды, но систематически меняют свои свойства со временем (старение). Даже если кварцевый генератор имеет температурную компенсацию, его частота должна время от времени сравниваться первичным стандартом для обеспечения высокой точности. Обычно часовые осцилляторы классифицируются по трем параметрам: стабильность, разброс и блуждание. Стабильность определяется систематическими вариациями частоты со временем. Синонимом нестабильности является старение и дрейф. Разброс (называемый также временным дрожанием) характеризует кратковременные случайные вариации частоты с составляющими более 10 Гц, в то время как блуждание характеризует медленные вариации частоты с составляющими менее 10 Гц. Таблица 4.4.15.12. Точность и стабильность часов для различных слоев
Конструкция, работа и характеристики осциллятора слоя 1 предполагаются сопоставимыми с национальными стандартами времени и часто базируются на цезиевом стандарте. Часы слоя 4 соответствуют требованиям обычных цифровых каналов и систем PBX. Слои 2-3 могут использоваться для работы с мощными синхронными каналами связи. Раздача времени и частоты Для того чтобы атомное и обычное время могли быть взаимосвязаны, национальные администрации обеспечивают работу первичных стандартов времени и частоты и совместно координируют их функционирование. Большинство морских держав поддерживают широковещательные радиослужбы времени. Американский Национальный Институт Стандартов и Технологии (NIST - National Institute of Standards and Technology) поддерживает три радиослужбы для рассылки временной информации. Одна из них использует передачу (ВЧ или CCIR диапазон 7) на частотах 2.5, 5, 10, 15 и 20 Мгц. Сигнал распространяется, отражаясь от верхних слоев атмосферы, что неизбежно приводит к непредсказуемым вариациям задержки на принимающей стороне. С 60-секундным интервалом передается временной код, который транслируется на 100 килогерцной субнесущей со скоростью передачи 1 бит/с. Этот код содержит информацию об UTC времени и дате, но не включает в себя данных о текущем годе и оповещения о добавлении/вычитании секунды для последней минуты данного дня. Существуют и другие сходные службы времени (например, в Оттаве), гарантирующие точность на уровне 1-10 мсек. Вторая служба времени NIST использует передачу (НЧ или CCIR диапазон 5) на частоте 60 КГц, она доступна на континентальной части США и вблизи берегов. Сигнал распространяется в нижней части атмосферы и по этой причине слабо подвержен вариациям времени распространения. Временной код передается с периодом в 60 секунд со скоростью 1 бит/с. Достижимая точность составляет 50 миллисекунд [BLA74]. Ряд европейских стран предлагают аналогичные службы времени (Великобритания - MSF; Германия - DCF77). Коды времени здесь включают информацию о текущем годе и предупреждение о добавляемой/вычитаемой секунде. Третья служба NIST использует передачу на частоте 468 МГц (УВЧ или CCIR диапазон 9) с геостационарных спутников GOES, три из которых перекрывают западное полушарие. Временной код перемежается с сообщениями, адресованными удаленным датчикам и состоит из 600 4-битовых слов, передаваемых с периодом в 30 секунд. Временной код содержит информацию об UTC времени-дне-годе, а также предупреждение о добавлении/вычитании секунды в конце дня. Точность этой службы составляет 0,5 мсек. Министерство обороны США разработало глобальную систему определения координат GPS (Global Positioning System). Эта система базируется на 24 спутниках, движущихся по орбитам с периодом 12 часов. Система GPS может обеспечить точность определения времени на уровне нескольких наносекунд [VAN84]. Американская береговая охрана в течение многих лет использует службу радионавигации LORAN-C [FRA82]. Эта служба обеспечивает временную точность менее 1 мксек. Система радионавигации военно-морского флота США и других стран OMEGA [VAS78] состоит из 8 передатчиков, работающих на частотах от 10.2 до 13.1 КГц (УНЧ или CIR диапазон 4) и перекрывающих весь земной шар 24 часа в сутки. Точность этой системы составляет около 1 мсек. Система OMEGA обеспечивает высокую точность для частоты, но не передает временного кода. По этой причине приемник должен предварительно получить географические координаты с точностью до градуса и время UTC с точностью 5 секунд от независимых источников. Заметим, что не все службы времени передают информацию о текущем годе и предупреждения о добавлении/вычитании секунды. Протокол NTP позволяет решить эту проблему. Определение частоты В течение многих лет наиболее важным использованием времени и частоты были всемирная навигация и космическая наука, которые зависят от наблюдений солнца, луны и звезд. За стандартную секунду (в 1957 году) принята 1/31,556,925.9747 периода вращения Земли вокруг Солнца (тропический год). Согласно этой шкалы тропический год длится 365.2421987 дней, а лунный месяц 29.53059 дней. Однако тропический год может быть определен лишь с точностью около 50 мсек. С древнейших времен человечеству были известны три осциллятора (процесса задающих временную шкалу) - вращение земли вокруг своей оси, вращение Луны вокруг Земли и вращение Земли вокруг Солнца. К сожалению, с точки требований современных технологий все эти три осциллятора не обладают достаточной стабильностью. В 1967 стандартная секунда была переопределена и теперь равняется 9,192,631,770 периодов перехода в атоме цезия-133. С 1972 стандарты времени и частоты базируются на международном атомном времени TAI (International Atomic Time). Точность таких часов составляет около микросекунды в сутки. Важно то, что новая шкала абсолютно однородна и не подвержена дрейфам. Определение времени и необходимости добавления/вычитания секунды Международное бюро мер и стандартов IBWM (International Bureau of Weights and Measures) использует астрономические наблюдения, выполненные морской обсерваторией США и другими обсерваториями для определения UTC. Для более точной временной привязки событий после 1972 года необходимо знать, когда вставлялись или удалялись секунды коррекции (удаление пока никогда не производилось). Как определено в докладе 517 CCIR, который воспроизведен в [BLA74], дополнительные секунды вставляются после 23:59:59 в последний день июня или декабря. Неоднородность во временную шкалу (TAI) помимо добавляемых секунд вносят также 100 миллисекундные коррекции UT1, называемые DUT1, которые служат для повышения точности при навигации. Следует признать, что момент добавления секунды является началом новой (однородной) временной шкалы. Временная шкала NTP базируется на шкале UTC, но необязательно всегда совпадает с ней. В 0 часов 1 января 1972 начинается эра UTC, часы NTP были установлены на 2,272,060,800 стандартных секунд после 0 часов 1 января 1900. Ссылки
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.14.5 Программа Sendmail
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.16 Протокол SNTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол SNTP V 4 отличается от предыдущей версии NTP и SNTP (Simple Network Time Protocol (SNTP) V.4 for IPv4, IPv6 and OSI, D. Mills, RFC-2030) модификацией интерпретации заголовка с целью осуществления совместимости адресации с IPv6 [DEE96] и OSI [COL94]. 1. Введение Протокол сетевого времени (NTP v3), описанный в документе RFC-1305 [MIL92], широко используется для синхронизации часов ЭВМ в глобальном Интернет. Он обеспечивает доступ к национальным системам точного времени. В большинстве мест Интернет протокол гарантирует точность синхронизации с точностью 1-50 мс, в зависимости от свойств источника синхронизации и сетевых задержек. RFC-1305 специфицирует машину протокола NTP v3 в терминах событий, состояний, функций перехода и действий. Кроме того, там определены инженерные алгоритмы улучшения точности синхронизации и выбора из списка эталонных источников, некоторые из которых могут быть неисправны. Эти алгоритмы необходимы для компенсации влияния вариаций задержки пакетов в сети Интернет. Однако, во многих обстоятельствах приемлемы точности порядка доли секунды. В таких случаях используется более простые протоколы времени [POS83]. Эти протоколы обычно использует RPC-обмен, где клиент запрашивает время дня, а сервер присылает его значение в секундах после некоторого известного эталонного момента. NTP создан для использования клиентами и серверами с широким диапазоном возможностей для широкого интервала сетевых задержек и большого временного разброса. Большинство пользователей NTP синхронизации используют программное обеспечение с полным набором опций и алгоритмов (смотри http://www.eecis.udel.edu/~ntp). SNTP v 4 предполагает совместимость с NTP и SNTP v 3 как для клиентов так и для серверов. Кроме того, клиенты и серверы SNTP v.4 могут реализовывать расширения для работы в эникаст режиме. Клиенты SNTP должны работать только на самом верхнем уровне субсети в конфигурациях, где синхронизация NTP или SNTP клиентов не зависит от других клиентов. Серверы SNTP должны работать только на первом (базовом) уровне субсети и в конфигурациях, где нет других источников синхронизации кроме надежных радио или модемных служб точного времени. 2. Рабочие режимы и адресация SNTP v.4 может работать в уникастном (точка-точка), мультикастном (один передатчик - много приемников) или эникаст (несколько передатчиков - один приемник). Уникастный клиент посылает запросы специально выделенному серверу по его уникастному адресу и ожидает отклика, из которого он может определить время и опционно RTT, а также сдвижку временной шкалы местных часов по отношению к шкале сервера. Мультикастный сервер периодически посылает сообщения по локальному мультикаст-адресу (IPv4 или IPv6). Мультикастный клиент воспринимает получаемые данные и не посылает никаких запросов. Эникастный клиент посылает запрос по локальному специально выделенному мультикастному (IPv4 или IPv6) адресу, при этом один или более эникатных серверов отправляют клиенту отклик. Клиент связывается с первым из них и в дальнейшем продолжает работу уже в уникастном режиме адресации. Мультикастные серверы должны реагировать на уникастные запросы клиентов, а также самостоятельно посылать мультикастные сообщения. Мультикастные клиенты могут посылать уникастные запросы, чтобы определить задержку распространения пакетов в сети между сервером и клиентом с тем, чтобы в дальнейшем продолжить работу в мультикастном режиме. В уникастном режиме адреса клиенту и серверу присваиваются согласно обычной схеме IPv4, IPv6 или OSI. В мультикастном режиме сервер использует локальный широковещательный адрес или мультикастный групповой адрес. Локальный широковещательный IP-адрес имеет область действия, ограниченную субсетью, так как маршрутизаторы не ретранслируют широковещательные IP-дейтограммы. С другой стороны IP-адрес мультикастинг-группы имеет область действия, распространяющуюся потенциально на весь Интернет. Для IPv4 iana для целей NTP выделила мультикастный групповой адрес 224.0.1.1, который используется как для мультикаст серверов, так и для эникаст клиентов. Мультикастные клиенты прослушивают выделенный локальный широковещательный адрес или мультикастный групповой адрес. В случае мультикастного IP-адреса, мультикастный клиент и эникастный сервер должны реализовать протокол IGMP (Internet Group Management Protocol) [DEE89], для того чтобы местный маршрутизатор подключился к мультикаст-группе и ретранслировал сообщения, направленные по IPv4 или IPv6 мультикастным групповым адресам, присвоенным IANA. Очень важно оптимально выбрать значение поля TTL в IP-заголовке мультикастинг-сообщения, для того чтобы ограничить сетевые ресурсы, используемые данным видом сервиса. Режим эникаст сконструирован для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее. Эникастный клиент посылает запрос по локальному широковещательному адресу или групповому мультикастинг-адресу. Для этой цели используется групповой адрес NTP специально выделенный iana для этих целей. Один или более эникастных серверов воспринимают этот запрос и отправляют отклик по уникастному адресу клиента. Клиент устанавливает связь с сервером, от которого получил отклик раньше. Последующие отклики эникаст-серверов игнорируются. В случае SNTP, существует реальная угроза того, что SNTP мультикаст-клиент может быть введен в заблуждение поведением SNTP или NTP-серверов (возможно и преднамеренным), так как все они используют один и тот же групповой мультикаст-адрес, выделенный для этих целей IANA. Где необходимо, для выбора сервера, известного клиенту может проводиться отбор по адресу. Опционной является схема криптографической аутентификации, описанной в документе RFC-1305. 3. Формат временных меток NTP Протокол SNTP использует стандартный формат временных меток NTP, описанный в документе RFC-1305 и в предыдущих версиях стандарта. Для согласования со стандартной практикой в Интернет данные NTP характеризуются целыми числами с фиксированной запятой. Биты нумеруются так, что нулевой (старший) разряд размещается слева. Если не оговорено обратного, все числа не имеют знака и занимают все выделенное для них поле. Так как временная метка NTP представляет собой наиважнейшую часть протокола, для нее разработан специальный формат. Временные метки NTP характеризуются 64-битным числом без знака с фиксированной запятой, которое равно количеству секунд с 0 часов 1 января 1900. Для целочисленной части выделено 32 бита и столько же для дробной части. Рекомендуется заполнять несущественные младшие двоичные разряды временной метки случайной битовой строкой, что исключает систематические ошибки округления и является средством детектирования зацикливания. Одним из методов выполнения этого условия является генерация случайной 64-битовой последовательности, с последующим ее сдвигом вправо на число бит, равное количеству значащих разрядов временной метки, и добавлением результата к исходному значению временной метки. Максимальное число, которое может быть представлено в данном формате равно 4,294,967,295 секунд с точностью порядка 200 пикосекунд, что может удовлетворить самым экзотическим требованиям.
Рис. 4.4.16.1. Формат представления временной метки Заметим что с некоторого времени в 1968 (2,147,483,648 секунда) старший бит (бит 0 целочисленной части) стал равным 1 и 64-битовое поле переполнится в 2036 году. Если NTP или SNTP будут использоваться в 2036 г, будут необходимы некоторые внешние по отношению к данному протоколу меры для определения того относительно 1900 или 2036 года отсчитана приведенная дата (это справедливо и для других дат, кратных 136 годам). Так как формат временных меток NTP использовался в течение последних 17 лет, остается возможность того, что он будет использоваться еще 40 лет. Так как временных меток NTP до 1968 не существует, можно считать приемлемым, что при бите 0 равном 1, UTC-время лежит в диапазоне 1968-2036 с началом отсчета 0 час. 0 мин. 0 сек. 1 января 1900 г. Если же бит 0 равен нулю, время лежит в диапазоне 2036-2104 г., а UTC-время отсчитывается от 6 час. 28 мин. 16 сек. 7 февраля 2036. Заметим, что при этом вычислении 2000 год не считался високосным. 4. Формат сообщений NTP Протоколы NTP и SNTP используют в качестве транспортного протокол UDP. При этом работает UDP-порт 123 (NTP), который проставляется как в поле порта отправителя, так и получателя UDP-заголовка. Ниже приводится описание формата сообщений NTP/SNTP v.4, которые размещаются после UDP-заголовка. Этот формат идентичен описанному в RFC-1305, за исключением содержимого поля идентификатора эталона (reference identifier). Поля заголовка представлены на рис. 4.4.16.2:
Рис. 4.4.16.2. Формат заголовка SNTP-пакета Поле LI (Leap Indicator) содержит два бита кода предупреждения о добавлении/удалении секунды в последней минуте текущего дня. Значения кодов поля LI приведены в таблице 4.4.16.1: Таблица 4.4.16.1 Значения кодов поля LI
Поле VN (Version Number - номер версии) имеет длину три бита и содержит номер версии протокола NTP/SNTP. Это поле содержит 3 для V.3 (только IPv4) и 4 для V.4 (IPv4, IPv6 и OSI). Поле режим также содержит три бита и указывает на код режима. Значения кодов режима представлены в таблице 4.4.16.2. Таблица 4.4.16.2. Значение кодов поля режим
В уникастном и эникастном режиме клиент при запросе устанавливает это поле равным 3 (клиент), а сервер в отклике устанавливает его равным 4. В мультикастном режиме сервер записывает в данное поле код 5 (широковещательный). Поле слой (Stratum) содержит восемь бит, указывающих на уровень локальных часов. Значения кодов поля слой представлены в таблице 4.4.16.3. Таблица 4.4.16.3. Значения кодов поля слой (stratum)
Поле интервал запросов (Poll Interval - регистрация ) содержит 8 бит и указывает на максимальный интервал между последовательными сообщениями. Код (k) характеризует показатель степени 2. Интервал между запросами равен 2k секунд. Значения, которые могут появиться в этом поле лежат в диапазоне от 4 (16 сек) до 14 (16284 сек); однако большинство приложений использует субдиапазон от 6 (64 сек.) до 10 (1024 сек). Поле точность содержит 8 бит и характеризует точность локальных часов, в секундах (показатель степени 2, как и в предыдущем поле). Значения кодов в этом поле лежат в диапазоне -6 для частоты сети переменного тока до -20 для микросекундных часов. Поле Root Delay представляет собой 32-битовое число с фиксированной запятой, характеризующее RTT в секундах до эталона точного времени. Запятая в этом числе располагается между битами 15 и 16. Заметим, что эта переменная может быть положительной или отрицательной. Диапазон значений кодов этого поля лежит в диапазоне от минус нескольких миллисекунд до плюс нескольких сотен миллисекунд. Поле Root Dispersion представляет собой 32-битовое число без знака с фиксированной запятой, указывающее на номинальное значение временной ошибки относительно эталона в секундах. Разброс значений этого поля лежит в пределах от нуля до нескольких сот миллисекунд. Поле идентификатор эталона представляет собой 32-битовую строку, которая позволяет однозначно идентифицировать эталон времени. В случае первичных серверов (слой 0 или 1) NTP V.3 или V.4, идентификатор представляет собой четырех символьную ASCII-строку, размещенную в левой части поля. Свободная часть поля заполняется нулями. Для вторичных серверов NTP V.3, идентификатор равен 32-битовому адресу эталонного источника (IPv4). Для вторичных серверов NTP V.4, в качестве идентификатора используются младшие 32 бита последней временной метки эталонного источника. Первичные серверы NTP (слой 1) должны заносить в это поле коды, идентифицирующие внешние эталоны согласно таблице 4.4.16.4. Если код в таблице отсутствует, допускаются и другие коды. Таблица 4.4.16.4. Коды идентификатора эталона
Поле эталонная временная метка характеризует время, когда локальные часы были установлены или поправлены (64-битовый формат временной метки). Поле Originate Timestamp (исходная временная метка) соответствует времени, когда клиент направил запрос серверу (64-битовый формат временной метки). Поле Receive Timestamp характеризует время, когда запрос пришел на сервер (64-битовый формат временной метки). Поле Transmit Timestamp соответствует времени, когда сервер послал отклик клиенту (64-битовый формат временной метки). Поле аутентификатор (опционно) используется, когда необходима аутентификация, и содержит в себе ключевой идентификатор и сообщение. Поле дайджест хранит код аутентификации сообщения MAC (Message Authentication Code). 5. Операции клиента SNTP Клиент SNTP может работать в мультикастном, уникастном и эникаситном режимах. В мультикастном режиме клиент не посылает никаких запросов и ждет широковещательных сообщений (режим 5) от специально выделенного мультикастного сервера. В уникастном режиме клиент посылает запросы (режим 3) специально выделенному серверу и ожидает от него откликов (режим 4). В эникастном режиме клиент посылает запросы (режим 3) по специально выделенному местному широковещательному или мультикастному адресу и ожидает откликов (режим 4) от одного или более эникастных серверов. Клиент использует первый полученный отклик и устанавливает с соответствующим сервером связь в уникастном режиме. Последующие отклики от данного, или других серверов игнорируются. Запросы номинально посылаются с интервалом от 64 до 1024 секунд, в зависимости от стабильности частоты клиента и от требуемой точности. Уникастные или эникастные клиенты используют заголовок сообщения NTP, посылают запрос серверу и считывают время дня из поля Transmit Timestamp отклика. Для этой цели все поля заголовка NTP могут быть установлены равными нулю, за исключением первого октета и (опционно) поля Transmit Timestamp . В первом октете поле LI устанавливается равным 0 (никаких предупреждений), а в поле режим заносится код 3 (клиент). Поле VN должно соответствовать номеру версии сервера NTP/SNTP; однако, серверы V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и версии 2 (RFC-1119) воспринимают предшествующие версии, включая версию 1 (RFC-1059). Версия 0 (RFC-959) в настоящее время уже не поддерживается. Рекомендуется чтобы клиенты использовали последнюю версию, которую поддерживает выбранный сервер. Чтобы вычислить полную циклическую задержку d и смещение локальных часов по отношению к серверу t, клиент устанавливает значение поля transmit timestamp в запросе равным времени дня согласно часам клиента и в соответствии с форматом временных меток NTP. Сервер копирует этот код в поле originate timestamp отклика и устанавливает поле receive timestamp и transmit timestamp в соответствии с показанием своих часов. Когда будет получен отклик от сервера, клиент определяет значение переменной Destination Timestamp, как время прибытия по своим часам. В таблице 4.4.16.5. рассмотрены все 4 типа временных меток. Таблица 4.4.16.5. Типы временных меток
Циклическая (roundtrip) задержка d и смещение локальных часов t определяются как: d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2. В таблице 4.4.16.6. собраны операции клиента в уникаст, эникаст и мультикаст режимах. Рекомендуемые проверки ошибок представлены в колонках таблицы "Отклик" и "Мультикаст". Сообщение следует рассматривать как корректное только в случае, если все поля содержат допустимые коды. Следует ли воспринимать сообщение, если оно содержит неверные значения для поля (ей), помеченного ремаркой "Игнорируется", зависит от конкретной реализации программы. Таблица 4.4.16.6. Операции клиента и значения полей заголовка
6. Операции сервера SNTP Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности. В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной. В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов. Заметим, что крайне желательно чтобы серверы, поддерживающие мультикастинг, поддерживали и уникастный режим. Это необходимо для измерения RTT клиент/сервер, прежде чем осуществлять регулярный обмен в мультикастном режиме. В уникастном и эникастном режимах сервер может реагировать, а может и игнорировать запросы, если не синхронизован надлежащим образом с помощью радио-часов. Но предпочтительным поведением является присылка отклика в любом случае, так как позволяет убедиться в достижимости сервера. В мультикастном режиме сервер посылает широковещательные сообщения, только если он синхронизован. Остальные поля заголовка NTP заполняются следующим образом. Если сервер синхронизован и функционирует правильно, в поле LI заносится 0, а в поле слой - 1 (первичный сервер). Если это не так, в поле слой записывается 0, а в поле LI - 3. В поле точность заносится код, характеризующий точность локальных часов. Для всех практических случаев этот код вычисляется, как отрицательное число бит справа от запятой в формате временной метки NTP. Поля Root Delay и Root Dispersion для первичного сервера делаются равными 0. Поле Root Dispersion опционно может быть сделано равным значению, соответствующему максимальной ожидаемой ошибке радио-часов. В поле Reference Identifier заносится идентификатор первичного эталона времени, как это указано в таблице 4.4.16.4. Поля временных меток заполняются следующим образом. Если сервер не синхронизован или только что включился, все временные метки устанавливаются равными нулю. Если сервер синхронизован, в поле Reference Timestamp записывается время последней коррекции по радио-часам или модему. В уникастном и эникастном режимах в поля Receive Timestamp и Transmit Timestamp заносится время дня, когда было послано сообщение, а в поле Originate Timestamp записывается неизмененная копия поля Transmit Timestamp из запроса. В мультикастном режиме в поля Originate Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp время дня, когда послано сообщение. В таблице 4.4.16.7 представлены все перечисленные операции. Таблица 4.4.16.7
Наиболее важным индикатором неисправности сервера является поле LI, в котором код 3 указывает на отсутствие синхронизации. Когда получено именно это значение, клиент должен проигнорировать сообщение сервера вне зависимости от содержимого других полей. 7. Конфигурация и управление Исходная конфигурация SNTP серверов и клиентов может быть произведена на основе конфигурационного файла, если такой файл имеется, или через последовательный порт. Предполагается, что SNTP серверы и клиенты практически не требуют какого-то конфигурирования, специфического для данного узла (помимо IP-адреса, маски субсети или адреса OSI NSAP). Уникастные клиенты должны быть снабжены именем сервера или его адресом. Если используется имя сервера, то необходим один или несколько адресов ближайших DNS-серверов. Мультикастные серверы и эникастные клиенты должны снабжаться значением TTL, а также местным широковещательным или групповым мультикастным адресом. Эникастные серверы и мультикастные клиенты могут конфигурироваться с привлечением списков пар адрес-маска. Это обеспечивает контроль доступа, так что операции будут производиться только с известными клиентами или серверами. Эти серверы и клиенты должны поддерживать протокол IGMP, а также знать местный широковещательный или групповой мультикастный адрес. Существует несколько сценариев, которые помогают обнаружить и выбрать сервер для SNTP клиента без предварительной конфигурации (IP-адрес и маска субсети предполагается известной). Для IP-субсети или сегмента LAN, содержащих работающий NTP-сервер клиент может быть сконфигурирован для мультикастного режима, используя местный широковещательный адрес. Тот же подход может быть применен для других серверов, используя групповой мультикастинг-адрес. В обоих случаях предоставление списка адресов-масок серверов является желательным. В другом сценарии, удобном для протяженных сетей с большими задержками распространения клиенты могут конфигурироваться для эникастного режима, как на начальной фазе, так и в случае, когда выбранный уникастный источник становится недоступным. Следуя протоколу, клиент устанавливает связь с первым откликнувшимся сервером и далее продолжает обмен в уникастном режиме. В этом режиме локальные часы могут автоматически корректироваться с учетом задержки распространения. В еще одном сценарии, удобном для любой сети, где мультикастные услуги недоступны, DNS может быть сконфигурирована с одним CNAME, аналогично time.domain.net, и списком адресных записей для серверов NTP в домене. Используя адрес time.domain.net и получив список, клиент выбирает сервер и начинает с ним работу в уникастном режиме. 8. Ссылки
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.15 Сетевой протокол времени NTP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4 Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Виртуальная сеть виртуальных сетей - Интернет является самой большой и самой популярной сетью. Можно смело утверждать, что эта сеть сохранит это лидерство в ближайшие годы. Привлекательность сети не только в том, что это единая среда общения людей, находящихся в разных странах и на разных континентах. Интернет предоставляет все более широкий спектр услуг. Это и информационно-поисковые системы, телефония, аудио и видео письма, доставляемые за считанные секунды в любую точку мира (где имеется Интернет), видеоконференции, электронные журналы, службы новостей, дистанционное обучение, банковские операции и многое, многое другое. Интернету предстоит мучительная процедура перехода на 128-битовые адреса (IPv6), но по ее завершении можно ожидать дальнейшего расширения списка услуг. Уже сегодня Интернет стал средой, предоставляющей возможность целевой рекламы и дистанционной торговли. Уже в начале следующего века сети станут самым мощным средством массовой информации. Но для решения всех этих проблем в этой сфере еще очень много надо сделать. Современные поисковые системы, несмотря на впечатляющие успехи, требуют существенного улучшения эффективности, много надо сделать для того, чтобы Интернет пришел в каждую квартиру. Сегодня Интернет использует многие десятки протоколов. Если сюда добавить протоколы физического уровня, то их число превысит сотню. На уровне локальных сетей наиболее распространены различные разновидности Ethernet, а также Token Ring и некоторые другие. Особенно велико разнообразие протоколов межсетевого обмена. Здесь помимо PPP используется FDDI, X.25, ISDN, ATM, SDH, Fibre Channel и пр.. На транспортном уровне в Интернет работают протоколы UDP (без установления соединения) и TCP (с установлением соединения). Это два принципиально разных подхода к передаче данных. В обоих случаях и передатчик и приемник имеют индивидуальные IP-адреса и порты. Но в случае TCP они ассоциируются в соединители (socket) - две пары IP-адрес-порт и прием/передача в рамках одной сессии происходит по схеме точка-точка. Для UDP же допускается возможность передачи одновременно нескольким приемникам (мультикастинг) и прием данных от нескольких передатчиков в рамках одной и той же сессии. Протокол TCP используется для поточной передачи данных, при которой доставка гарантируется на протокольном уровне. Это обеспечивается обязательным подтверждением получения каждого пакета TCP. Напротив, протокол UDP не требует подтверждения получения. В этом случае, как правило, исключается также и фрагментация пакетов, так как пакеты при схеме без установления соединения никак не связаны между собой. По этим причинам UDP в основном служит для передачи мультимедийных данных, где важнее своевременность, а не надежность доставки. Протокол TCP используется там, где важна надежная, безошибочная доставка информации (файловый обмен, передача почтовых сообщений и WEB-технология). Схема без установления соединения привлекательна также тем, что позволяет при передаче данных от исходного источника к большому числу приемников минимизировать общий трафик. Если бы для этой цели использовался протокол TCP, то при N приемниках надо было бы сформировать N виртуальных каналов и транспортировать N идентичных пакетов (рис. 4.4.1). В случае UDP от передатчика до точки разветвления передается только один пакет, что уменьшает загрузку данного участка в N раз (рис. 4.4.2). Причем аналогичная экономия может быть реализована и по пути к очередной точке разветвления (смотри описание протокола мультикастинг-маршрутизации PIM). Рис.4.4.1 Рис. 4.4.2. В примере на рисунке 4.4.2 на участке 1 снижение трафика по сравнению с традиционным методом передачи данных происходит в 8 раз, на участке 2 - в 4 раза, а на сегментах 3 - в два раза. Все множество протоколов Интернет можно поделить на две группы. К первой относятся те, что имеют собственный стандарт на формат пакетов (IP, UDP, TCP, ARP, RARP, RTP, RIP, OSPF, BGP, IGRP, ICMP, SNMP, DNS, PIM, IGMP, BOOTP, IPX/SPX, AAL и др.). Вторую группу образуют протоколы, которые формализуют обмен на уровне сообщений. Они не имеют своих форматов на пакеты, а стандартизуют лишь форму сообщений и алгоритм обмена. Вторая группа использует для передачи своих сообщений протоколы первой группы. К этой группе относятся SMTP, NTP, POP, IMAP, FTP, HTTP, RSVP, Telnet, Finger, NNTP, Whois, SET, SSL и т.д. По существу, вторая группа располагается на прикладном уровне. Первая группа более консервативна и достаточно хорошо структурирована, вторая - динамична и постоянно расширяется. Ко второй группе примыкают некоторые стандартизованные утилиты типа ping, traceroute, а также поисковые системы. В перспективе на подходе протоколы для интерфейсов баз данных и мультимедиа. Особняком стоят алгоритмы обеспечения безопасности. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.3.7 Модемы
UP:
4.3 Региональные сети
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.6 Протокол преобразования адресов ARP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Любое устройство, подключенное к локальной сети (Ethernet, FDDI и т.д.), имеет уникальный физический сетевой адрес, заданный аппаратным образом. 6-байтовый Ethernet-адрес выбирает изготовитель сетевого интерфейсного оборудования из выделенного для него по лицензии адресного пространства. Если у машины меняется сетевой адаптер, то меняется и ее Ethernet-адрес. 4-байтовый IP-адрес задает менеджер сети с учетом положения машины в сети Интернет. Если машина перемещается в другую часть сети Интернет, то ее IP-адрес должен быть изменен. Преобразование IP-адресов в сетевые выполняется с помощью arp-таблицы. Каждая машина сети имеет отдельную ARP-таблицу для каждого своего сетевого адаптера. Не трудно видеть, что существует проблема отображения физического адреса (6 байт для Ethernet) в пространство сетевых IP-адресов (4 байта) и наоборот. Протокол ARP (address resolution protocol, RFC-826) решает именно эту проблему - преобразует ARP- в Ethernet-адреса. Рассмотрим процедуру преобразования адресов при отправлении сообщения. Пусть прикладная программа одной ЭВМ отправляет сообщение другой. Прикладной программе IP-адрес места назначения обычно известен. Для определения Ethernet-адреса просматривается ARP-таблица. Если для требуемого IP-адреса в ней присутствует Ethernet-адрес, то формируется и посылается соответствующий пакет. Если же с помощью ARP-таблицы не удается преобразовать адрес, то выполняется следующее: 1. Всем машинам в сети посылается пакет с ARP-запросом (с широковещательным Ethernet-адресом места назначения). Каждая машина, принявшая ARP-запрос, в своем ARP-модуле сравнивает собственный IP-адрес с IP-адресом в запросе. Если IP-адрес совпал, то прямо по Ethernet-адресу отправителя запроса посылается ответ, содержащий как IP-адрес ответившей машины, так и ее Ethernet-адрес. После получения ответа на свой ARP-запрос машина имеет требуемую информацию о соответствии IP и Ethernet-адресов, формирует соответствующий элемент ARP-таблицы и отправляет IP-пакет, ранее поставленный в очередь. Если же в сети нет машины с искомым IP-адресом, то ARP-ответа не будет и не будет записи в ARP-таблицу. Протокол IP будет уничтожать IP-пакеты, предназначенные для отправки по этому адресу. Протоколы верхнего уровня не могут отличить случай повреждения в среде ethernet от случая отсутствия машины с искомым IP-адресом. Во многих реализациях в случае, если IP-адрес не принадлежит локальной сети, внешний порт сети (gateway) или маршрутизатор откликается, выдавая свой физический адрес (режим прокси-ARP). Функционально, ARP делится на две части. Одна - определяет физический адрес при посылке пакета, другая отвечает на запросы других машин. ARP-таблицы имеют динамический характер, каждая запись в ней "живет" определенное время после чего удаляется. Менеджер сети может осуществить запись в ARP-таблицу, которая там будет храниться "вечно". ARP-пакеты вкладываются непосредственно в ethernet-кадры. Формат arp-пакета показан на рис. 4.4.6.1.
Рис. 4.4.6.1. Формат пакета ARP HA-Len - длина аппаратного адреса; PA-Len - длина протокольного адреса (длина в байтах, например, для IP-адреса PA-Len=4). Тип оборудования - это тип интерфейса, для которого отправитель ищет адрес; код содержит 1 для Ethernet. Ниже представлена таблица 4.4.6.1 кодов оборудования. Таблица 4.4.6.1. Коды оборудования
Таблица 4.4.6.2. Коды протоколов (для IP это 0800H).
Поле код операции определяет, является ли данный пакет ARP-запросом (код = 1), ARP-откликом (2), RARP-запросом (3), или RARP-откликом (4). Это поле необходимо, как поле тип кадра в Ethernet пакетах, они идентичны для ARP-запроса и отклика. ARP-таблицы строятся согласно документу RFC-1213 и для каждого IP-адреса содержит четыре кода:
В SUN и некоторых других ЭВМ имеется программа arp, которая позволяет отобразить ARP-таблицу на экране. С флагом -a команда отображает всю таблицу, флаг -d позволяет стереть запись, а -s - служит для внесения записей в таблицу (последние два флага доступны для операторов с системными привилегиями). Команда ARP без флагов с адресом или именем ЭВМ выдаст соответствующую строку таблицы: arp 192.148.166.129 ARP запросы могут решать и другие задачи. Так при загрузке сетевого обеспечения ЭВМ такой запрос может выяснить, а не присвоен ли идентичный IP-адрес какому-то еще объекту в сети. При смене физического интерфейса такой запрос может инициировать смену записи в ARP-таблице. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.5 Протокол XTP
UP:
4.4 Интернет
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.11.8 Язык описания маршрутной политики RPSL
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. Введение Язык описания маршрутной политики RPSL (Routing Policy Specification Language) позволяет оператору сети специфицировать маршрутную политику на различных уровнях иерархии Интернет, например, на уровне автономных систем (AS). Так что низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL является расширяемым и не препятствует внедрению новых протоколов маршрутизации. Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 [6] или RFC-1786 [7]. RIPE-81 [8] был первым языком, использованным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык. Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован так, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num) в сочетании с описанием маршрутизатора (класс inet-rtr), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set), и информацией об автономных системах отправителях и о маршрутных префиксах (классы route и route-set). Язык RPSL является объектно-ориентированным, то есть, объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями. О IRR смотри [1, 17, 4]. Далее рассматриваются классы, которые используются для определения различных политик и административных объектов. Класс "mntner" определяет средства, предназначенные для добавления, уничтожения и модификации набора объектов. Классы "person" и "role" описывают технический и административный персонал, с которым можно установить контакт. Автономные системы (AS) специфицируются с помощью класса "aut-num". Маршруты специфицируются посредством класса "route". Наборы объектов могут быть определены с помощью классов "as-set", "route-set", "filter-set", "peering-set" и "rtr-set". Класс "dictionary" предоставляет возможность расширения возможностей языка. Класс "inet-rtr" используется для спецификации маршрутизаторов. Многие из этих классов были определены ранее, смотри [6, 13, 16, 12, 5]. 2. Имена, зарезервированные слова и представления RPSL Каждый класс имеет набор атрибутов, где записывается некоторая информация об объектах класса. Атрибуты могут быть обязательными и опционными. Обязательный атрибут должен быть определен для всех объектов класса. Опционный атрибут может отсутствовать. Атрибуты могут быть одно- и многозначными. Каждый объект однозначно идентифицируется набором атрибутов класса "key". Значение любого атрибута имеет определенный тип. Язык RPSL не чувствителен к тому, в каком регистре записаны те или иные выражения. Далее перечислены наиболее часто используемые типы атрибутов.
Многие объекты в RPSL имеют имя. <object-name> составляется из букв, чисел, а также символов подчеркивания ("_") и дефисов ("-"), первым символов всегда должна быть буква, а последним символом - буква или цифра. Следующие слова зарезервированы в RPSL, и не могут использоваться в качестве имен: any as-any rs-any peeras Имена, начинающиеся с определенных префиксов зарезервированы для определенных типов объектов. Имена, начинающиеся с "as-" зарезервированы для имен автономных систем. Имена, начинающиеся с "rs-" зарезервированы для набора имен маршрутов. Имена, начинающиеся с "rtrs-" зарезервированы для набора имен маршрутизаторов. Имена, начинающиеся с "fltr-" зарезервированы для набора имен фильтров. Имена, начинающиеся с "prng-" зарезервированы для набора имен партнеров.
192.224.128.5/32, 192.148.0.0/16, 0.0.0.0/0. Следующие адресные префиксы являются неверными: 0/0, 192.10/16, так как 0 или 192.10 не являются строками, содержащими четыре целые числа.
Операторы диапазона могут применяться для наборов адресных префиксов. Например, для набора маршрутов rs-foo, rs-foo^+ (определенный ниже) содержит все специфические данные о префиксах в rs-foo. Применение двух операторов диапазона последовательно является ошибкой (напр. 30.0.0.0/8^24-28^+ - ошибка). Однако оператор диапазона может быть применен к набору адресных префиксов, содержащий диапазоны адресных префиксов (напр. {30.0.0.0/8^24-28}^27-30 не является ошибкой). В этом случае, внешний оператор ^n-m располагается над внутренним оператором ^k-l и становится оператором ^max(n,k)-m, если m больше или равно max(n,k), в противном случае префикс удаляется из набора. Заметим, что оператор ^n эквивалентен ^n-n. Префикс/l^+ эквивалентен префиксу prefix/l^l-32. Префикс/l^- эквивалентен префиксу prefix/l^(l+1)-32. Префикс {prefix/l^n-m}^+ эквивалентен префиксу {prefix/l^n-32}, а префикс {prefix/l^n-m}^- эквивалентен префиксу {prefix/l^(n+1)-32}. Например,
Значением атрибута может быть также список одного из этих типов. Элементы списка отделяются друг от друга запятыми. Например, "AS1, AS2, AS3, AS4". Заметим, что значение-список ортогонально многозначности. Многозначный атрибут имеет более одного значения, каждое из которых может быть, а может и не быть списком. С другой стороны однозначный атрибут может иметь значение-список. Объект RPSL текстуально представляется в виде списка пар атрибут-значение. Каждая пара атрибут-значение записывается на отдельной строке. Имя атрибута начинается с колонки 0 и завершается двоеточием. Далее следует значение атрибута. Атрибут, который имеет то же имя, что и класс объекта должен быть специфицирован раньше. Представление объекта завершается пустой строкой. Значение атрибута может занимать несколько строк, для этого очередная строка должна начинаться с символа пробел, табулятор или знак плюс ('+'). Символ "+" для строки продолжения позволяет значениям атрибута содержать пустые строки. Порядок размещения пар атрибут-значение является существенным. Описание атрибута может содержать комментарий. Комментарий может размещаться где угодно в определении объекта, он начинается с символа "#" и завершается первым же символом перехода на новую строку. Целые числа могут задаваться:
3. Контактная информация Классы mntner, person и role, а также атрибуты admin-c, tech-c, mnt-by, changed и всех классов характеризуют контактную информацию. Класс mntner специфицирует также аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать другие объекты. Эти классы не специфицируют маршрутную политику и каждый реестр может иметь различные или дополнительные требования. В документе "Routing Policy System Security" [20] описана модель аутентификации и авторизации. 3.1. Класс mntner Класс mntner специфицирует аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать объекты RPSL. Провайдер прежде чем создавать RPSL-объект, должен создать объект mntner. Атрибуты класса mntner показаны на рис. .1. Класс mntner описан в [13]. Атрибут mntner является обязательным и выполняет функцию ключа класса. Его значение - имя RPSL. Атрибут auth специфицирует схему, которая будет использоваться для идентификации и аутентификации запросов актуализации. Атрибут имеет следующий синтаксис: auth: <scheme-id> <auth-info>
Рис. .1. Атрибуты класса mntner auth: CRYPT-PW dhjsdfhruewf В настоящее время для <scheme-id> определены значения: NONE, MAIL-FROM, PGP-KEY и CRYPT-PW. <auth-info> представляет дополнительную информацию, необходимую для конкретной схемы: в случае MAIL-FROM, это регулярное выражение, соответствующее корректному электронному почтовому адресу. В случае CRYPT-PW, это пароль в крипто-формате UNIX. В случае PGP-KEY, это указатель на объект key-certif [22], содержащий открытый ключ PGP-пользователя. Если специфицировано несколько атрибутов auth, запрос эксплуатационный актуализации, удовлетворяющий любому из них, будет аутентифицирован. Атрибут upd-to представляет собой электронный почтовый адрес. При неавторизованной попытке актуализации объекта, по этому адресу будет послано сообщение. Атрибут mnt-nfy также представляет собой почтовый адрес. При добавлении, изменении или удалении объекта по этому адресу посылается уведомляющее сообщение. Атрибут descr является коротким текстовым описанием объекта, выполненным в произвольной форме. Атрибут tech-c представляет собой контактный дескриптор NIC. Он используется при возникновении технических проблем, например, при неверной конфигурации. Атрибут admin-c представляет собой административный контактный дескриптор NIC. Атрибут remarks представляет собой текстовый комментарий или разъяснение. Атрибут notify представляет собой электронный адрес, куда следует отправлять уведомление об изменении этого объекта. Атрибут mnt-by является списком имен объектов mntner. Атрибут changed определяет, кто последний раз изменял данный объект, и когда это изменение было произведено. Его синтаксис имеет следующий формат: changed: <email-address> идентифицирует человека, который внес последние изменения. <YYYYMMDD> представляет собой дату изменения. Атрибут source специфицирует реестр, где объект зарегистрирован. На рис. .2 показан пример объекта mntner. В этом примере использован криптографический формат UNIX для паролей аутентификации.
Рис. 2. Пример объекта mntner. Атрибуты descr, tech-c, admin-c, remarks, notify, mnt-by, changed и source являются атрибутами всех классов RPSL. Их синтаксис, семантика, а также статус mandatory (обязательный), optional (опционный), multi-valued (многозначный), или однозначный те же что и для всех классов RPSL. Единственным исключением является атрибут admin-c, который является обязательным для класса aut-num. 3.2. Класс person Класс person используется для описания информации о людях. Хотя он не описывает маршрутную политику, его описание здесь приводится, так как многие объекты политики делают ссылки на конкретных людей. Класс person был впервые описан в [15]. Атрибуты класса person представлены на рис. .3 Атрибут person представляет собой полное имя человека. Атрибуты phone и fax-no имеют следующий синтаксис: phone: +<country-code> <city> <subscriber> [ext. <extension>] phone: +31 20 12334676
Рис. .3: Атрибуты класса person phone: +44 123 987654 ext. 4711 На рис. .4 приведен пример объекта person.
Рис. .4. Пример объекта person. 3.3. Класс role Класс role подобен объекту person. Однако вместо описания человека он описывает роль, которую выполняет один или несколько человек. Примеры включают в себя консультационные пункты, центры сетевого мониторинга, системных администраторов и т.д. Объект role особенно полезен, так как человек, выполняющий роль, может быть заменен, а сама роль остается неизменной. Атрибуты класса role показаны на рис. .5. Атрибуты лиц nic-hdl и классы role используют совместно одно и то же пространство имен. Атрибут trouble объекта role может содержать дополнительную контактную информацию, которая может быть использована при возникновении проблемы в любом объекте, который ссылается на данный объект role. На рис. .6 показан пример объекта role.
Рис. .5. Атрибуты класса role
trouble:
Рис. .6. Пример объекта role. 4. Класс route Каждый маршрут interAS (называемый также междоменным маршрутом), начинающийся в AS, специфицируется с помощью объекта route. Атрибуты класса route представлены на рис. .7. Атрибут route представляет собой адресный префикс маршрута, а атрибут origin является номером AS, где этот маршрут начинается. Пара атрибутов route и origin являются ключом класса. На рис. .8 представлены примеры четырех объектов route. Заметим, что последние два объекта route имеют один и тот же адресный префикс 128.8.0.0/16. Однако они являются различными объектами route, так как они начинаются в разных AS (то есть они имеют разные ключи).
Рис. 7: Атрибуты класса route
Рис. .8. Объекты Route 5. Классы Set При спецификации политики часто полезно определить наборы объектов. Для этих целей определены классы as-set, route-set, rtr-set, filter-set, and peering-set. Эти классы определяют именованный набор. Члены этих наборов могут быть специфицированы непосредственно путем перечисления их в определении набора, или косвенно, имея ссылки членов-объектов на имена наборов. Допускается применение обоих методов. Имя набора является словом rpsl со следующими ограничениями. Все имена as-set начинаются с префикса "as-". Все имена route-set начинаются с префикса "rs-". Все наборы имен rtr-set начинаются с префикса "rtrs-". Все имена filter-set начинаются с префикса "fltr-". Все имена peering-set начинаются с префикса "prng-". Например, as-foo является корректным именем as-set. Имена наборов могут быть иерархическими. Имя иерархического набора представляет собой последовательность имен наборов и номеров AS, разделенных символом двоеточие ":". По крайней мере, одна компонента такого имени должна быть действительным именем набора (то есть начинается с одного из префиксов). Все компоненты имени набора иерархического имени должны иметь один и тот же тип. Например, следующие имена корректны: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS. Целью имени иерархического набора является выделение определенного пространства имен, так что администратор набора X1 управляет всем набором нижележащих имен, то есть X1:...:Xn-1. Таким образом, набор объектов с именем X1:...:Xn-1:Xn может быть создан администратором объекта с именем X1:...:Xn-1. То есть, только администратор AS1 может создать набор с именем AS1:AS-FOO. Только администратор AS1:AS-FOO может создать набор с именем AS1:AS-FOO:AS-BAR. 5.1. Класс as-set Атрибуты класса as-set показан на рис. .9. Атрибут as-set определяет имя набора. Он является именем RPSL, которое начинается с "as-". Атрибут members перечисляет членов набора. Атрибут members является списком AS, или других имен as-set.
Рис. .9. Атрибуты класса as-set На рис. .10 представлены два объекта as-set. Набор as-foo содержит две AS, в частности AS1 и AS2. Набор as-bar содержит членов набора as-foo и AS3, т.е. он содержит AS1, AS2, AS3. Набор as-empty не содержит членов.
Рис. .10. Объекты as-set. Атрибут mbrs-by-ref представляет собой список имен администраторов (maintainer) или ключевое слово ANY. Если используется этот атрибут, набор AS включает также автономные системы, чьи объекты aut-num зарегистрированы одним из этих администраторов и чей атрибут member-of относится к имени этого набора AS. Если значение атрибута mbrs-by-ref равно ANY, любой объект AS, относящийся к набору, является членом этого набора. Если атрибут mbrs-by-ref пропущен, только AS, перечисленные в атрибуте members, являются членами набора. as-set: as-foo
Рис. .11. Объекты as-set. На рис. .11 представлен пример объекта as-set, который использует атрибут mbrs-by-ref. Набор set as-foo содержит AS1, AS2 и AS3. AS4 не является членом набора as-foo не смотря на то, что объект aut-num ссылается на as-foo. Это происходит потому, что MNTR-OTHER отсутствует в списке атрибута as-foo mbrs-by-ref. 5.2. Класс route-set Атрибуты класса route-set показаны на рис. .12. Атрибут route-set определяет имя набора. Он является именем RPSL, которое начинается с "rs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список адресных префиксов или других имен route-set. Заметим, что, класс route-set является набором префиксов маршрутов, а не маршрутных объектов RPSL.
Рис. .12. Атрибуты класса route-set На рис. .13 приведены некоторые примеры объектов route-set. Набор rs-foo содержит два адресных префикса, в частности 128.9.0.0/16 и 128.9.0.0/24. Набор rs-bar содержит члены набора rs-foo и адресный префикс 128.7.0.0/16. За адресным префиксом или именем route-set в атрибуте members может опционно следовать оператор диапазона. Например, следующий набор: route-set: rs-foo Рис. .13. Объекты route-set route-set: rs-bar содержат все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 30.0.0.0/8, чья длина лежит в пределах 24 - 32, такие как 30.9.9.96/28, и все префиксы больше префиксов из маршрутного набора rs-foo. Атрибут mbrs-by-ref представляет собой список имен администраторов и может содержать ключевое слово ANY. Если используется этот атрибут, маршрутный набор включает также префиксы, чьи маршрутные объекты зарегистрированы одним из администраторов, и чей атрибут member-of указывает на имя этого маршрутного набора. Если значение атрибута mbrs-by-ref равно ANY, любой объект, связанный с именем маршрутного набора, является его членом. Если атрибут mbrs-by-ref отсутствует, только адресные префиксы, перечисленные в атрибуте members, являются членами этого набора. route-set: rs-foo Рис. .14. Объекты route-set. На рис. 14 представлен пример объектов route-set, которые используют атрибут mbrs-by-ref. Набор rs-foo содержит два адресных префикса, в частности 128.8.0.0/16 и 128.9.0.0/16, так как маршрутные объекты для 128.8.0.0/16 и 128.9.0.0/16 отнесены к набору имен rs-foo в их атрибуте member-of. Набор rs-bar содержит адресные префиксы 128.7.0.0/16 и 128.8.0.0/16. Маршрут 128.7.0.0/16 представлен явно в атрибуте members rs-bar, а маршрутный объект для 128.8.0.0/16 связан с именем набора rs-bar в атрибуте member-of. Заметим, что если адресный префикс представлен в атрибуте маршрутного набора members, он является членом этого маршрутного набора. Маршрутный объект, соответствующий этому адресному префиксу не должен содержать атрибут member-of, относящийся к имени этого набора. Атрибут маршрутного класса member-of является дополнительным механизмом для косвенной спецификации членов набора. 5.3. Объекты предопределенных наборов В этом контексте, который предполагает набор маршрутов (например, атрибут members класса route-set), номер автономной системы ASx определяет набор маршрутов, который исходит из Asx, а as-set AS-X определяет набор маршрутов, которые исходят из автономной системы AS-X. Маршрут p считается начинающимся в ASx, если существует маршрутный объект для p с ASx в качестве значения атрибута origin. Например, на рис. .15, набор маршрутов rs-special содержит маршруты 128.9.0.0/16, AS1 и AS2, а также маршруты автономных систем набора AS-FOO. route-set: rs-special Рис. .15. Использование номеров AS и маршрутных наборов. Набор rs-any содержит все маршруты, зарегистрированные в IRR. Набор as-any содержит все AS, зарегистрированные в IRR. 5.4. Класс Filters и filter-set Атрибуты класса filter-set представлены на рис. 16. Объект filter-set определяет набор маршрутов, которые соответствуют этому фильтру. Атрибут filter-set определяет имя фильтра. Он является именем RPSL, которое начинается с "fltr-".
Рис. .16. Атрибуты класса filter filter-set: fltr-foo Рис. .17. Объекты filter-set. Атрибут filter определяет фильтр политики для данного набора. Фильтр политики является логическим выражением, которое в случае приложения к набору маршрутов в качестве результата возвращает субнабор этих маршрутов. Считается, что фильтр политики соответствует возвращенному субнабору. Фильтр политики может соответствовать маршрутам, использующим любой атрибут BGP-прохода, такой как адресный префикс места назначения (или NLRI), AS-path, или атрибуты community. Фильтры политики могут составляться путем использования операторов AND, OR и NOT. Ниже представленные фильтры политики могут использоваться для селекции субнабора маршрутов:
{ 0.0.0.0/0 } За адресным префиксом может опционно следовать оператор диапазона (то есть содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 128.9.0.0/16, исключая 128.9.0.0/16, все префиксы больше 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16, и все префиксы больше 30.0.0.0/8, которые имеют длину в диапазоне 24 - 32, такие как 30.9.9.96/28.
aut-num: AS1 Ключевое слово PeerAS может использоваться вместо номера AS партнера. PeerAS является особенно полезным, когда партнерство охарактеризовано с помощью AS-выражения. Например: as-set: AS-FOO aut-num: AS1 то же самое, что и: aut-num: AS1 За именем набора маршрутов может также следовать один из операторов '^-', '^+', например, { 5.0.0.0/8, 6.0.0.0/8 }^+ эквивалентно { 5.0.0.0/8^+, 6.0.0.0/8^+ } и AS1^- эквивалентно всем адресным префиксам, соответствующим маршрутам, исходящим из AS1. Регулярные выражения для проходов AS. Регулярное выражение AS-path может использоваться в качестве фильтра политики путем заключения его в угловые скобки `<' и `>'. Фильтр политики AS-path соответствует набору маршрутов, который проходит через последовательность AS, которая согласуется с регулярным выражением AS-path. Маршрутизатор может проверить это, используя атрибут AS_PATH в протоколе BGP [19], или атрибут RD_PATH в протоколе IDRP [18]. Регулярное выражение формируется следующим образом:
Далее описываются операторы регулярных выражений. Эти операторы выполняются слева направо. Унарные постфиксные операторы * + ? {m} {m,n} {m,} Для регулярных выражений A, запись A* соответствует нулю или более использований A. A+ соответствует одному или более использованию A. A? соответствует нулю или одному использованию A. A{m} соответствует m использованиям A. A{m,n} соответствует от m до n использованиям A/, A{m,} соответствует m или более использованиям A. Например, [AS1 AS2]{2} соответствует AS1 AS1, AS1 AS2, AS2 AS1 и AS2 AS2. Унарные постфиксные операторы ~* ~+ ~{m} ~{m,n} ~{m,} Эти операторы имеют аналогичную функциональность, что и соответствующие операторы, перечисленные выше, но все включения регулярного выражения должны соответствовать одному образцу. Например, [AS1 AS2]~{2} соответствует AS1 AS1 и AS2 AS2, но не соответствует AS1 AS2 и AS2 AS1. Двоичный оператор объединения. Это неявный оператор, он вставляется между двумя регулярными выражениями A и B, когда не специфицирован другой оператор. Полученное выражение A B соответствует AS-path, если A соответствует некоторому префиксу AS-path, а B соответствует остальной части AS-path. Двоичный альтернативный оператор | Для регулярных выражений A и B, A | B соответствует любому AS-path, который соответствует A или B. Для изменения порядка действий, предусмотренного по умолчанию, можно использовать скобки. Для улучшения читаемости могут использоваться WS (пробел или символ TAB). Ниже приведены примеры фильтров AS-path:
Первый пример соответствует любому маршруту, чей AS-path содержит AS3, второй соответствует маршрутам, чьи AS-path начинаются с AS1, третий соответствует маршрутам, чьи AS-path заканчиваются AS2, четвертый соответствует маршрутам, чьи AS-path в точности равны "1 2 3", а пятый соответствует маршрутам, чьи AS-path начинаются в AS1 и заканчиваются в AS2 с любым числом промежуточных AS между ними. Составные фильтры политики. Последующие операторы могут использоваться при формировании составных фильтров политики.
NOT {128.9.0.0/16, 128.8.0.0/16} Первый пример соответствует любому маршруту кроме 128.9.0.0/16 и 128.8.0.0/16. Второй пример соответствует маршрутам AS226, AS227 и AS228. Третий пример соответствует маршрутам AS226, исключая 128.9.0.0/16. Четвертый пример соответствует маршрутам AS226, чья длина не больше 18. Атрибуты фильтров политики могут использоваться для сравнения значения других атрибутов. Атрибуты, чьи значения могут применяться в фильтрах политики, специфицированы в словаре RPSL. Пример использования атрибута BGP community приведен ниже: aut-num: AS1 Фильтры, использующие атрибуты маршрутной политики, определенные в словаре, вычисляются до выполнения операторов AND, OR и NOT.
5.5. Класс rtr-set Атрибуты класса rtr-set представлены на рис. .18. Атрибут rtr-set определяет имя набора. Он является словом RPSL, которое начинается с "rtrs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список имен inet-rtr, ipv4_addresses или других имен rtr-set.
Рис. .18. Атрибуты класса rtr-set На рис. .19 представлены два объекта rtr-set. Набор rtrs-foo содержит два маршрутизатора, в частности rtr1.isp.net и rtr2.isp.net. Набор rtrs-bar содержит членов набора rtrs-foo и rtr3.isp.net, то есть он содержит rtr1.isp.net, rtr2.isp.net, rtr3.isp.net.
Рис. .19. Объекты rtr-set. Атрибут mbrs-by-ref содержит список имен администраторов (maintainer) или ключевое слово ANY. Если использован этот атрибут, набор маршрутизаторов включает также маршрутизаторы, чьи объекты inet-rtr зарегистрированы одним из этих администраторов и чей атрибут member-of согласуется с именем этого набора маршрутизаторов. Если значение атрибута mbrs-by-ref равно ANY, любой объект inet-rtr соотносящийся набору маршрутизаторов, является членом этого набора. Если атрибут mbrs-by-ref отсутствует, только маршрутизаторы перечисленные в атрибуте members, являются членами набора. rtr-set: rtrs-foo Рис. .20. Объекты rtr-set. На рис. 20 представлен пример объекта rtr-set, который использует атрибут mbrs-by-ref. Набор rtrs-foo содержит rtr1.isp.net, rtr2.isp.net и rtr3.isp.net. 5.6. Партнерство и класс peering-set Атрибуты класса peering-set представлены на рис. .21. Объект peering-set определяет набор партнеров, который перечислен в его партнерских атрибутах (peering). Атрибут peering-set определяет имя набора. Он является именем RPSL, которое начинается с "prng-".
Рис. .21. Атрибуты класса filter Атрибут peering определяет партнеров, которые могут быть использованы для импорта или экспорта маршрутных данных.
Рис. .22. Пример топологии, состоящий из трех AS: AS1, AS2 и AS3, двух точек обмена: EX1 и EX2 и шести маршрутизаторов (IP[R1]= 1.1.1.1, IP[R2]= 2.2.2.1, IP[R3]= 1.1.1.2, IP[R4]= 1.1.1.3, IP[R5]= 2.2.2.2, IP[R6]= 2.2.2.3). При описании партнерства используется топология, показанная на рис. .22. В этой топологии имеется три автономные системы, AS1, AS2, and AS3; две точки обмена, EX1 и EX2, и шесть маршрутизаторов (R1-R6). Маршрутизаторы соединены с точками обмена. То есть, 1.1.1.1, 1.1.1.2 и 1.1.1.3 являются партнерами друг для друга, а 2.2.2.1, 2.2.2.2 и 2.2.2.3 - также партнеры друг для друга. Синтаксис спецификации партнерства: <as-expression> [<router-expression-1>] [at <router-expression-2>] | <peering-set-name> где <as-expression> является выражением для номеров AS и наборов AS, использующих операторы AND, OR и EXCEPT, а выражения <router-expression-1> и <router-expression-2> являются функциями IP-адресов маршрутизаторов, имен inet-rtr, и имен rtr-set, использующих операторы AND, OR и EXCEPT. Двоичный оператор "EXCEPT" семантически эквивалентен комбинации "AND NOT". То есть "(AS1 OR AS2) EXCEPT AS2" эквивалентно "AS1". Эта форма идентифицирует всех партнеров между любым локальным маршрутизатором в <router-expression-2> и любыми маршрутизаторами в <router-expression-1> в автономных системах из <as-expression>. Если <router-expression-2> не специфицировано, это по умолчанию предполагает, что все маршрутизаторы локальной AS связаны с AS из <as-expression>. Если используется <peering-set-name>, партеры перечислены в соответствующем объекте peering-set. Заметим, что объекты peering-set могут быть рекурсивными. Возможны также многие специальные формы этой общей спецификации партнеров. Ниже приведенные примеры иллюстрируют наиболее общие случаи с использованием атрибута import класса aut-num. В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2. (1) aut-num: AS1 В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3. (2) aut-num: AS1 В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3, а 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2. (3) aut-num: AS1 В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3. (4) as-set: AS-FOO aut-num: AS1
В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3, а 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3. (5) aut-num: AS1
В следующем примере AS1 импортирует 128.9.0.0/16 из AS3 через маршрутизатор 9.9.9.1 (6) aut-num: AS1 Это связано с тем, что "AS-FOO and not AS2" эквивалентно AS3 и "not 1.1.1.1" эквивалентно 9.9.9.1. В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3. aut-num: AS1 6. Класс aut-num Маршрутная политика специфицируется с использованием класса aut-num. Атрибуты класса aut-num представлены на рис. .23. Значение атрибута aut-num равно номеру AS, описанной данным объектом. Атрибут as-name является символическим именем (в рамках синтаксиса имен RPSL) AS. Импорт, экспорт и маршрутная политика по умолчанию AS специфицируются, используя атрибуты import, export и default, соответственно.
Рис. .23. Атрибуты класса aut-num 6.1. Атрибут import: Спецификация политики импорта В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:
Спецификация действия является опционной. Семантика атрибута import выглядит следующим образом: набор маршрутов, который соответствует <filter> импортируется от всех партнеров в <peerings>, в то время как импортируемые маршруты <peering-M>, <>ction-M> реализуются. Например Этот пример утверждает, что маршрут 128.9.0.0/16 воспринят от AS2 с предпочтением 1. Далее рассматривается спецификация действий (action). 6.1.1. Спецификация действия (Action) Действия политики в RPSL устанавливают или модифицируют атрибуты маршрутов, таких как предпочтение маршрута, добавляет атрибут BGP community или устанавливает атрибут MULTI-EXIT-DISCRIMINATOR. Действия политики могут также инструктировать маршрутизаторы по выполнению специальных операций, таких как гашение осцилляций маршрутов. Атрибуты маршрутной политики, чьи значения могут быть модифицированы посредством действий политики, специфицированы в словаре RPSL. Каждое действие при записи в RPSL завершаются символом точка с запятой (';'). Имеется возможность формировать составные действия политики путем последовательного их перечисления. В этом случае действия выполняются в порядке слева направо. Например, aut-num: AS1
устанавливает pref = 0, med = 0, и затем добавляет 10250 и 3561:10 к атрибуту прохода community BGP. Атрибут pref является инверсным по отношению к атрибуту local-pref (т.e. local-pref == 65535 - pref). Маршрут с атрибутом local-pref всегда предпочтительнее, чем без него. aut-num: AS1
Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 с предпочтением 1 и от AS3 с предпочтением 2 (маршруты с более низкими предпочтениями имеют больший приоритет, чем с большими значениями). aut-num: AS1
Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 для направления 1.1.1.1-1.1.1.2 с предпочтением 1, а для любого другого направления от AS2 с предпочтением 2. 6.2. Атрибут export: Спецификация экспортной политики Аналогично выражение экспортной политики специфицируется с помощью атрибута export. Атрибут export имеет следующий синтаксис:
Спецификация действия является опционной. Семантика атрибута export выглядит следующим образом: набор маршрутов, который соответствует <filter> пересылается всем партнерам, специфицированным в <peerings>, в то время как экспортируемые маршруты из <peering-M>, <action-M> реализуются. Например В этом примере, маршруты AS4 объявляются автономной системе AS2 со значением атрибута med, равным 5 и атрибута community = 70. Пример: В этом примере, AS1 объявляет все свои маршруты автономным системам AS из набора AS-FOO. 6.3. Другие маршрутные протоколы, мультипротокольные маршрутные протоколы и обмен маршрутами между протоколами Более сложный синтаксис атрибутов import и export выглядит следующим образом: import: [protocol <protocol-1>] [into <protocol-2>]
export: [protocol <protocol-1>] [into <protocol-2>]
Этот синтаксис используется там, где при описании политики других протоколов маршрутизации могут использоваться спецификации опционных протоколов, или для введения маршрутов одного протокола в другой протокол, или для многопротокольной маршрутной политики. Корректные имена протоколов определены в словаре. <protocol-1> является именем протокола, чьими маршрутами производится обмен. <protocol-2> представляет собой имя протокола, который принимает данные об этих маршрутах. Как <protocol-1> так и <protocol-2> являются протоколами по умолчанию для IEGP (Internet Exterior Gateway Protocol), в настоящее время его функцию выполняет BGP. В последующем примере все маршруты interAS передаются протоколу RIP. aut-num: AS1 В следующем примере, AS1 воспринимает маршруты AS2, включая любые адресные префиксы больше префиксов маршрутов AS2, но не передает эти дополнительные префиксы протоколу OSPF. aut-num: AS1 В следующем примере, AS1 передает свои статические маршруты (маршруты, которые являются членами набора AS1:RS-STATIC-ROUTES) маршрутному протоколу interAS и дважды добавляет AS1 к своему маршрутному набору AS. aut-num: AS1
В следующем примере, AS1 воспринимает другой набор уникастных маршрутов для реверсивной мультикастной переадресации из AS2: aut-num: AS1 6.4. Разрешение неопределенности Допускается, чтобы один и тот же обмен (peering) был описан в более чем одной спецификации партнерства в пределах выражения политики. Например: aut-num: AS1
Это не ошибка, хотя такая запись определенно не желательна. Чтобы убрать неопределенность, используется действие (action), соответствующее первой спецификации партнерства. То есть маршруты воспринимаются с предпочтением, равным 2. Это правило называется правилом порядка спецификаций. Рассмотрим пример: aut-num: AS1
где обе спецификации партнерства перекрывают маршруты 1.1.1.1-1.1.1.2, хотя вторая спецификация более специфична. Здесь также используется правило порядка спецификаций, выполняется только действие (action) "pref = 2". В действительности, вторая пара пиринговых действий бесполезна, так как первая пара пиринговых действий покрывает действие второй. Если требуется политика, при которой эти маршруты воспринимались данным пирингом с предпочтением 1 и с предпочтением 2 для всех остальных пирингов, пользователь должен специфицировать следующее: aut-num: AS1
Допускается также, чтобы более чем одно выражение политики покрывало один и тот же набор маршрутов в рамках одного пиринга. Например: aut-num: AS1 В этом случае, также используется правило порядка спецификаций. То есть маршруты AS4 от AS2 воспринимаются с предпочтением 2. Если фильтры перекрываются, но не тождественны: aut-num: AS1 маршруты AS4 воспринимаются от AS2 с предпочтением 2 и, тем не менее, маршруты AS5 также воспринимаются, но с предпочтением 1. Ниже приведено общее правило порядка спецификации для разработчиков программ RPSL. Рассмотрим два расширения политики: aut-num: AS1 Вышеприведенные выражения политики эквивалентны следующим трем выражениям, где нет неопределенности: aut-num: AS1 где peerings-3 - это набор маршрутов, которые покрываются как peerings-1, так и peerings-2, а peerings-4 - набор маршрутов, которые покрываются peerings-2, но не покрываются peerings-1 ("filter-2 AND NOT filter-1" соответствует маршрутам, которые согласуются с filter-2, но не с filter-1). Пример:
Рассмотрим два пиринга с AS2, 1.1.1.1-1.1.1.2 и 9.9.9.1- 2.2.2.2. Оба выражения политики покрывают 1.1.1.1-1.1.1.2. Для этого пиринга, маршрут 128.9.0.0/16 воспринимается с предпочтением 2, а маршрут 75.0.0.0/8 воспринимается с предпочтением 1. Пиринг 9.9.9.1-2.2.2.2 покрывается только вторым выражением политики. Следовательно, как маршрут 128.9.0.0/16 так и маршрут 75.0.0.0/8 воспринимаются с предпочтением 1 пирингом 9.9.9.1-2.2.2.2. Заметим, что аналогичное правило разрешения неопределенности применимо к выражениям политики по умолчанию и экспортной политики (рассылка маршрутной информации). 6.5. Атрибут default. Спецификация политики по умолчанию Политика маршрутизации по умолчанию специфицируется с помощью атрибута default. Атрибут default имеет следующий синтаксис: default: to <peering> [action <action>] [networks <filter>] Спецификации <action> и <filter> являются опционными. Семантика выглядит следующим образом: Спецификация <peering> указывает на AS (и маршрутизатор, если он имеется) по умолчанию; спецификация <action>, если присутствует, указывает на различные атрибуты конфигурации по умолчанию. Например, относительное предпочтение, если определено несколько маршрутов по умолчанию; а спецификация <filter>, если имеется, является фильтром политики. Маршрутизатор использует политику по умолчанию, если он получает от партнера маршруты, которые удовлетворяют требованиям фильтра <filter>. В следующем примере, AS1 маршрутизируется по умолчанию через AS2. aut-num: AS1 В следующем примере, марштутизатор 1.1.1.1 в AS1 маршрутизуется по умолчанию через 1.1.1.2 в AS2. aut-num: AS1 В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и AS3, но предпочитает AS2, а не AS3. aut-num: AS1 В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и использует 128.9.0.0/16 в качестве сети по умолчанию. aut-num: AS1 6.6. Спецификация структурированной политики Политики импорта и экспорта (рассылки и приема маршрутной информации) могут быть структурированы. Применение структурированной политики рекомендуется для продвинутых пользователей RPSL. Синтаксис спецификации структурированной политики выглядит следующим образом:
В конце <import-factor> должна быть точка с запятой. Если спецификация политики не структурирована эта точка с запятой является опционной. Синтаксис и семантика для <import-factor> определена в разделе 6.1. <import-term> представляет собой либо последовательность <import-factor>, заключенную в фигурные скобки, либо один <import-factor>. Семантика <import-term> заключается в объединении <import-factor> с использованием правила порядка спецификаций. <import-expression> представляет собой либо один <import-term>, либо <import-term>, за которым следуют ключевые слова "except" и "refine", с завершающим <import-expression>. Заметим, что данное определение допускает вложенные выражения. Следовательно, могут существовать исключения к исключениям, уточнения к уточнениям или даже уточнения к исключениям и т.д. Семантика для оператора except имеет вид. Результатом операции исключения является еще один член <import-term>. Результирующий набор политики содержит описание политики правой стороны, но его фильтры модифицированы так, что остаются только маршруты, соответствующие левой стороне. Политика левой стороны, в конце концов, включается, а ее фильтры модифицируются так, чтобы исключить маршруты, соответствующие левой стороне. Заметим, что фильтры модифицированы во время этого процесса, но действия скопированы один к одному. При нескольких уровнях вложения операции (принять или уточнить) выполняются справа налево. Рассмотрим следующий пример:
} где маршрут 128.9.0.0/16 порождается AS226, а AS226 является членом набора AS as-foo. В этом примере, маршрут 128.9.0.0/16 воспринят от AS3, любой другой маршрут (не 128.9.0.0/16) порожденный AS226 воспринимается от AS2, и любые другие маршруты AS из as-foo получены от AS1. Можно прийти к тому же заключению, используя алгебраические выкладки, определенные выше. Рассмотрим спецификацию внутреннего исключения: from AS2 action pref = 2; accept AS226; Эквивалентно { from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16}; Следовательно, исходное выражение эквивалентно:
который эквивалентен
Так как AS226 находится в as-foo и 128.9.0.0/16 заключен в AS226, выражение упрощается:
В случае оператора refine, результирующий набор формируется с помощью декартова произведения для двух сторон следующим образом. Для каждой политики l левой стороны и для каждой политики r правой стороны, пиринг результирующей политики является пересечением множеств пирингов r и l. Фильтр результирующей политики соответствует пересечению фильтров l и r. Действие результирующей политики есть действие l, за которым следует действие r. Если общие пиринги отсутствуют, или если множество пересечения фильтров является пустым, результирующая политика не формируется. Рассмотрим следующий пример:
Здесь любому маршруту с community 3560:10 присваивается предпочтение 1 а любому маршруту с community 3560:20 присваивается предпочтение 2 вне зависимости от того, откуда они импортированы. Однако только маршруты AS1 импортированы из AS1, и только маршруты AS2 импортированы из AS2, и только маршруты AS3 импортированы из AS3, ни один маршрут не импортирован из каких-либо других AS. К тому же заключению можно прийти, используя алгебраические методы, описанные выше. То есть, это пример эквивалентен:
Рассмотрим следующий пример:
где воспринимаются только маршруты с длиной от 0 до 18, а значение med сделано равным 0, для того чтобы блокировать влияние med на все пиринги. Кроме того, из AS1 импортируются только маршруты AS1, а маршруты автономной системы AS1, импортированные от 1.1.1.1, предпочтительнее других пирингов. Это эквивалентно:
Описанный выше синтаксис и семантика применима также к структурированным описаниям экспортной политики с ключевым словом "from", замененным на "to", а "accept" - на "announce". 7. Класс dictionary Класс dictionary обеспечивает расширяемость для RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и маршрутные протоколы. Атрибуты маршрутной политики, впредь называемые rp-атрибутами, могут соответствовать действительным протокольным атрибутам, таким как атрибуты пути BGP (напр., community, dpa и AS-path), или они могут соответствовать особенностям маршрутизатора (напр., гашение осцилляций маршрутов в BGP). Когда вводятся новые протоколы, новые протокольные атрибуты, или новые возможности миршрутизатора, объект словаря актуализуется, с тем чтобы ввести соответствующее описание rp-атрибута или протокола. rp-атрибут относится к абстрактному классу, то есть представление данных не доступно. Вместо этого, доступ к ним определяется методом доступа. Например, rp-атрибут для BGP-атрибута AS-path называется aspath, и он имеет метод доступа, называемый prepend, который вставляет дополнительные номера AS в атрибуты AS-path. Методы доступа могут воспринимать аргументы. Аргументы строго типофицируются. Например, метод prepend воспринимает номера AS в качестве аргументов. Раз rp-аргумент определен в словаре, он может использоваться для описания фильтров и действий. Необходимы средства анализа политики, чтобы предоставить объект словаря и распознать вновь определенные rp-атрибуты, типы и протоколы. Средства анализа могут даже загружать программу для выполнения соответствующих операций, используя механизмы помимо RPSL. Ниже рассматривается синтаксис и семантика класса dictionary. Это описание не существенно для понимания объектов dictionary (но оно существенно для их создания). Атрибуты класса dictionary представлены на рис. .24. Атрибут dictionary является именем объекта словаря, подчиняющимся правилам присвоения имен в RPSL. Может существовать много объектов словаря, однако имеется только один стандартный объект "RPSL". Все средства используют этот словарь по умолчанию.
Рис. .24. Атрибуты класса dictionary Атрибут rp-attribute имеет следующий синтаксис:
где <name> является именем rp-атрибута, а <method-i> является названием метода доступа для rp-атрибута, требующего Ni аргументов, где j-ый аргумент имеет тип <type-i-j>. Название метода является либо именем RPSL, либо одним из операторов, определенных на рис. .25. Операторные методы за исключением operator() и operator[] могут воспринимать только один аргумент.
Рис. .25. Операторы Атрибут rp-attribute может иметь много методов, определенных для него. Некоторые из методов могут даже иметь то же самое имя, в этом случае их аргументы должны относиться к другому типу. Если список аргументов завершается "...", метод может воспринять переменное число аргументов. В этом случае, действительные аргументы после N-го аргумента имеют тип <type-N>. Аргумента строго типофицированы. <type> в RPSL является либо предопределенным, типом union, списочным, либо определенным в словаре. Предопределенные типы перечислены на рис. .26.
Рис. .26. Предопределенные типы аргументов За целочисленными и действительными предопределенными типами могут следовать младшие или старшие секции, которые позволяют специфицировать набор допустимых значений аргумента. Спецификация диапазона является опционной. Для представления целых действительных значений и символьных строк используется нотация языка Си (ANSI). За типом enum следует список имен RPSL, которые являются значениями данного типа. Булев тип может принимать значение true или false. as_number, ipv4_address, address_prefix и dns_name типы имеют те же значения, что типы фильтра (раздел 2) и фильтры политики (раздел 6). Значения фильтра следует помещать в скобки. Синтаксис типа union имеет следующий вид: union <type-1>, ... , <type-N> Синтаксис списочного типа приведен ниже: В этом случае элементы списка представляют <type>, а список содержит по крайней мере <min_elems> элементов, но не больше чем <max_elems>>. Размер спецификации является опционным. Если спецификация отсутствует, то никаких регламентаций на число элементов в списке не накладывается. Значение списочного типа представляется в виде последовательности элементов, разделенных символом запятой "," и заключенных в фигурные скобки "{" и "}". Атрибут typedef в словаре определяет именованный тип следующим образом: typedef: <name> <type>
где 7.1. Исходный словарь RPSL, пример действий политики и фильтры dictionary: RPSL
rp-attribute: # атрибут BGP multi_exit_discriminator
rp-attribute: # атрибут предпочтения места назначения BGP (dpa)
rp-attribute: # атрибут BGP aspath
typedef: # значение community в RPSL равно:
typedef: # список значений community { 40, no_export, 3561:70 }
rp-attribute: # атрибут BGP community
protocol: OSPF Рис. .27. Словарь RPSL На рис. .27 показан исходный словарь RPSL. Он имеет семь rp-атрибутов: pref для присвоения локального предпочтения воспринимаемым маршрутам; med для присвоения значения атрибуту MULTI_EXIT_DISCRIMINATOR BGP; dpa для присвоения значения атрибуту DPA BGP; aspath для присвоения значения атрибуту AS_PATH BGP; community для присвоения или проверки значения атрибута community BGP; next-hop для назначения следующих маршрутизаторов в случае статических маршрутов; cost для назначения цены статических маршрутов. Словарь определяет два типа: community_elm и community_list. Тип community_elm является либо 4-байтовым целым числом без знака, либо одним из ключевых слов Интернет, no_export или no_advertise. Целое число может быть специфицировано с помощью двух 2-байтовых чисел, разделенных двоеточием ":", чтобы разделить пространство кода community так, чтобы провайдер мог использовать номер AS первых двух байт, и определить семантику выбора последних двух байт. Исходный словарь (рис. .27) определяет только опции для BGP (Border Gateway Protocol): asno и flap_damp. Обязательная опция asno является номером AS партнера-маршрутизатора. Опция flap_damp инструктирует маршрутизатор гасить осцилляции маршрутов [21], при импортировании маршрутов от маршрутизатора-партнера. Она может быть специфицирована с или без параметров. Если параметры опущены, принимаются значения по умолчанию: flap_damp(1000, 2000, 750, 900, 900, 20000) То есть, назначается штраф 1000 для каждого переключения маршрута, маршрут закрывается, когда штраф достигает 2000. Штраф снижается вдвое после 15 минут стабильного режима вне зависимости оттого открыт путь или нет. Закрытый маршрут используется вновь, когда штраф падает ниже 750. Максимальный штраф маршрута может достигать 20,000 (т.e. максимальное время закрытия маршрута после стабилизации ситуации составляет около 75 минут). Действия политики и фильтров, использующих rp-атрибуты Синтаксис действия политики или фильтра, использующего rp-атрибут x выглядит следующим образом: x.method(arguments) где method представляет собой метод, а "op" - метод оператора rp-атрибута x. Если метод оператора используется при спецификации составного фильтра политики, он определяется раньше, чем операторы составных фильтров политики (т.e. AND, OR, NOT или оператор). rp-атрибуту pref может быть присвоено положительное целое число следующим образом: pref = 10; rp-атрибуту med может быть присвоено положительное целое число или слово "igp_cost" следующим образом: med = 0; rp-атрибуту dpa может быть присвоено положительное целое число следующим образом: dpa = 100; Значением атрибута community BGP является список, который состоит из 4-байтовых целых чисел, каждое их которых характеризует "community". Следующие примеры демонстрируют, как добавлять новые значения community к этому rp-атрибуту: community .= { 100 }; В последнем случае, 4-байтовое целое число, сформированное так, что наиболее значимые два байта равны 3561, а менее значимые два байта равны 10. Следующие примеры показывают, как удалять элементы из rp-атрибута community: community.delete(100, NO_EXPORT, 3561:10); Фильтры, которые используют rp-атрибут community могут быть определены, как это показано в следующем примере: community.contains(100, NO_EXPORT, 3561:10); community(100, NO_EXPORT, 3561:10); # shortcut rp-атрибуту community может быть присвоено значение, соответствующее списку community следующим образом: community = {100, NO_EXPORT, 3561:10, 200}; В этом первом случае, rp-атрибут community содержит значения (communities) 100, NO_EXPORT, 3561:10 и 200. В последнем случае, rp-атрибут community обнулен. rp-атрибут community может быть сравнен со списком communities следующим образом: community == {100, NO_EXPORT, 3561:10, 200}; # точное соответствие Чтобы повлиять на выбор маршрута, rp-атрибут BGP as_path может быть сделан длиннее путем предварительной прописи номеров AS следующим образом: aspath.prepend(AS1); Следующие примеры некорректны:
aut-num: AS1
as-set: AS3561:AS-PEERS aut-num: AS3561
Рис. .28. Пример политики с использованием rp-атрибута community. 8. Класс Advanced route Атрибуты components, aggr-bndry, aggr-mtd, export-comps, inject и holes используются для спецификации агрегатных маршрутов [11]. Объект route специфицирует агрегатный маршрут, если специфицирован любой из этих атрибутов за исключением inject. Атрибут origin для агрегатного маршрута производит объединение маршрутов на базе AS. Здесь термин "aggregate" используется в отношении генерируемого маршрута, термин "component" относится к маршрутам, использованным для формирования атрибута объединения (aggregate) path, а термин "more specifics" относится к любому маршруту, который более специфичен для объединения, вне зависимости от того, используется ли он при формировании атрибутов path. Атрибут components определяет, какой из составляющих маршрутов используется для формирования объединения. Его синтаксис выглядит следующим образом: components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]] где <protocol> представляет собой имя протокола маршрутизации, такого как BGP4, OSPF или RIP (допустимые значения определяются словарем), а <filter> - выражение политики. Маршруты, соотносятся с одним из этих фильтров и получены с помощью соответствующего протокола, используются для формирования объединения (aggregate). Если <protocol> опущен, по умолчанию предполагается любой протокол. <filter> неявно содержит термин "AND" с более специфическими префиксами объединения, так что выбираются только маршруты компоненты. Если используется ключевое слово ATOMIC, объединение выполнено на уровне атомов [11]. Если атрибут components пропущен, используются все более специфичные префиксы без ключевого слова ATOMIC. route: 128.8.0.0/15
Рис. .29. Два объекта агрегатных маршрутов. На рис. 29 показаны два объекта route. В первом примере объединяются более специфические префиксы 128.8.0.0/15 с проходами, начинающимися с AS2. Во втором примере агрегатированы некоторые маршруты, полученные от BGP и некоторые маршруты, полученные из OSPF. Атрибут aggr-bndry является AS-выражением для номеров и наборов (см. раздел 5.6). Результат определяет набор AS, который задает границу объединения (aggregation). Если атрибут aggr-bndry опущен, исходная AS является единственной границей объединения. За пределами границы объединения экспортируется только это объединение, а более специфичные префиксы передаваться не могут. Однако в пределах границы, более специфичные префиксы также могут пересылаться. Атрибут aggr-mtd определяет то, как формируется объединение. Его синтаксис показан ниже:
где <as-expression> - выражение для номеров AS и наборов (см. раздел 5.6). Если <as-expression> опущено, по умолчанию предполагается AS-ANY. Если специфицировано экспортное объединение, более специфические префиксы будут присутствовать в пределах AS, а объединение будет сформировано перед отправкой на всех inter-AS границах с AS в <as-expression>, за исключением AS, которые находятся на границе объединения. Если специфицировано импортное объединение, объединение формируется на всех границах inter-AS прежде чем переносить маршруты в агрегатор AS. Заметим, что <as-expression> не может быть специфицировано с использованием импортного объединения. Если атрибут aggr-mtd опущен, он не выполняет функции "outbound AS-ANY".
Рис. .30. Пример экспортного объединения большого числа AS. На рис. 30 показан пример экспортного объединения. В этом примере, AS1 и AS2 представляют собой объединение и оповещают окружающий мир только о менее специфических префиксах 128.8.0.0/15, обмениваясь друг с другом более специфическими префиксами. Эта форма объединения полезна, когда некоторые компоненты находятся внутри AS1, а некоторые в AS2. Когда агрегатируется набор маршрутов, предполагается экспортировать только агрегатные маршруты и блокировать экспорт более специфичных префиксов вне границы объединения, чтобы удовлетворить определенной политике и топологическим ограничениям (напр., компонента со многими интерфейсами (multi-homed)) часто необходимо экспортировать некоторые компоненты. Атрибут export-comps эквивалентен фильтру RPSL, который соответствует более специфичным префиксам. Если этот атрибут опущен, более специфические префиксы не экспортируются за пределы границы объединения. Заметим, что, фильтр export-comps содержит неявный оператор "AND" по отношению более специфичным префиксам объединения. На рис. 31 показан пример экспортного объединения. В этом примере, более специфические префиксы 128.8.8.0/24 экспортируются из AS1 в дополнение к объединению. Это полезно, когда 128.8.8.0/24 является многопортовым узлом, связанным с другими AS.
Рис. .31. Экспортное объединение с исключениями. Атрибут inject определяет, какие маршрутизаторы выполняют объединение, и когда они это делают. Синтаксис атрибута показан ниже:
где <action> - спецификация действия (см. раздел 6.1.1), <condition> - булево выражение, описанное ниже, <router-expression> описано в разделе 5.6. Все маршрутизаторы в <router-expression> и в агрегаторе (объединении) AS выполняют агрегацию. Если <router-expression> не специфицировано, все маршрутизаторы внутри агрегатора AS выполняют агрегацию. Спецификация <action> может установить атрибуты path объединения (aggregate), например, определить предпочтения для объединения. Так как условие является булевым выражением, объединение создается, если и только если это условие истинно. <condition> - булево выражение, использующее логические операторы AND и OR (т.e. оператор NOT не разрешен): HAVE-COMPONENTS { список префиксов } Список префиксов в HAVE-COMPONENTS может состоять из более специфических префиксов объединения. Список может также включать диапазоны префиксов (т.e. использование операторов ^-, ^+, ^n, и ^n-m). В этом случае, по крайней мере, один префикс из каждого диапазона префиксов должен присутствовать в каждой маршрутной таблице, для того чтобы условие было выполнено. Список префиксов в EXCLUDE может быть произвольным. Условие выполняется, когда ни один из перечисленных префиксов не содержится в маршрутной таблице. Список может содержать диапазоны префиксов, а ни один префикс из этого диапазона не должен присутствовать в маршрутной таблице. Ключевое слово static всегда предполагается равным true.
Рис. .32. Примеры инжекции. На рис. 32 показаны два примера. В первом случае, объединение вводится в два маршрутизатора, каждый из которых устанавливает атрибут прохода dpa по-разному. Во втором случае, объединение формируется только если в маршрутной таблице присутствуют как 128.8.0.0/16 так и 128.9.0.0/16, в отличие от первого случая, когда присутствия лишь одного из них достаточно для ввода (injection). Атрибут holes перечисляет компоненты адресных префиксов, которые не достижимы через агрегатный маршрут (возможно, что часть адресного пространства не распределена). Атрибут holes полезен для диагностических целей. На рис. .32, второй пример имеет дырку, в частности 128.8.8.0/24. Это может быть связано с тем, что клиент менял провайдера и брал для этой цели эту часть адресного пространства. 8.1.1. Взаимодействие с политикой в классе aut-num О сформированном объединении другие AS оповещаются только в случае, когда экспортная политика AS позволяет передавать объединения маршрутов. Когда объединение сформировано, более специфические префиксы запрещены для экспорта за исключением AS в aggr-bndry и компонент в export-comps. Если объединение не сформировано, тогда более специфические префиксы объединения могут экспортироваться другим AS, но только если экспортная политика AS допускает это. Другими словами прежде чем маршрут (объединение) будет экспортировано, производится двойная фильтрация, один отбор основан на маршрутных объектах, а другой -на экспортной политике AS.
Рис. .33. Взаимодействие с политикой в классе aut-num. На рис. 33 показан пример взаимодействия. При рассмотрении маршрутных объектов следует произвести обмен более специфическими префиксами 128.8.0.0/16 и 128.9.0.0/16 между AS1, AS2 и AS3 (граница объединения). Экспортное объединение выполнено для AS4 и AS5, но не для AS3, так как AS3 находится на границе объединения. Объект aut-num допускает экспортирование обоих компонентов в AS2, и только компонент 128.8.0.0/16 в AS3. Объединение может быть сформировано, если присутствуют все компоненты. В данном случае только об этом объединении оповещены AS4 и AS5. Однако, если одна из компонент не доступна, объединение не может быть создано, и любая из доступных компонент или более специфический префикс будет экспортирован в AS4 и AS5. Вне зависимости от того, выполнено объединение или нет, только более специфические префиксы будут экспортированы в AS6. При выполнении импортного объединения конфигурирующие генераторы могут опускать агрегационные заявления для маршрутизаторов, где импортная политика AS запрещает импортирование более специфических префиксов. 8.1.2. Разрешение неопределенности для перекрывающихся объединений Когда специфицированы несколько маршрутных объединений и они перекрываются, т.e. один менее специфичен чем другой, тогда сначала определяются более а затем менее специфичные. Когда для партнера осуществляется экспортное объединение (outbound aggregation), объединение и компоненты, перечисленные в атрибуте export-comps, доступны для генерации следующих менее специфичных объединений. Компоненты, которые не специфицированы в атрибуте export-comps, являются недоступными. Маршрут экспортируем в AS, если это наименее специфическое объединение, экспортируемое в эту автономную систему или маршрут упомянут в атрибуте export-comps. Заметим, что это рекурсивное определение.
Рис. .34. Перекрывающиеся объединения. На рис. 34, AS1 вместе с AS2 объединяют 128.8.0.0/16 и 128.9.0.0/16 в 128.8.0.0/15. Вместе с AS3, AS1 объединяет 128.10.0.0/16 и 128.11.0.0/16 в 128.10.0.0/15. Но все вместе они объединяют эти четыре маршрута в 128.8.0.0/14. Предполагая все четыре компоненты доступными, маршрутизатор в AS1 для внешней AS, скажем AS4, сначала сгенерирует 128.8.0.0/15 и 128.10.0.0/15. Это сделает 128.8.0.0/15, 128.10.0.0/15 и его исключение 128.11.0.0/16 доступным для генерации 128.8.0.0/14. Маршрутизатор из этих трех маршрутов будет затем генерировать 128.8.0.0/14. Следовательно, для AS4, 128.8.0.0/14 и его исключение, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми. Для AS2, маршрутизатор в AS1 сгенерирует только 128.10.0.0/15. Следовательно, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми. Заметим, что 128.8.0.0/16 и 128.9.0.0/16 являются также экспортируемыми, так как они не участвуют в объединении, допускающем экспорт в AS2. Аналогично, для AS3, маршрутизатор в AS1 будет генерировать только 128.8.0.0/15. В этом случае 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 могут экспортироваться. 8.2. Спецификация статических маршрутов Атрибут inject может служить для спецификации статических маршрутов, используя "upon static" в качестве условия:
В этом случае маршрутизатор в <router-expression> выполняет <action> и вводит маршрут в статическую маршрутную систему interAS. <action> может установить определенные маршрутные атрибуты, такие как next-hop router или cost. В следующем примере, маршрутизатор 1.1.1.1 вводит маршрут 128.7.0.0/16. Маршрутизаторы следующего шага (в этом примере, имеется два маршрутизатора "следующего шага") для этого маршрута имеют адреса 1.1.1.2 и 1.1.1.3, а маршрут имеет цену 10 для 1.1.1.2 и 20 для 1.1.1.3. route: 128.7.0.0/16 9. Класс inet-rtr Маршрутизаторы специфицируются с использованием класса inet-rtr. Атрибуты класса inet-rtr показаны на рис. 35. Атрибут inet-rtr представляет собой допустимое имя DNS описанного маршрутизатора. Каждый атрибут alias, если он присутствует, является каноническим именем DNS для маршрутизатора. Атрибут local-as специфицирует номер AS, которой управляет данный маршрутизатор.
Рис. .35. Атрибуты класса inet-rtr Значение атрибута ifaddr имеет следующий синтаксис: <ipv4-address> masklen <integer>> [action <action>] IP-адрес и длина маски являются обязательными для каждого интерфейса. Опционно можно специфицировать действие (action), которое позволяет установить другие параметры этого интерфейса. На рис. .36 предложен пример объекта inet-rtr. Имя маршрутизатора "amsterdam.ripe.net". "amsterdam1.ripe.net" является каноническим именем для маршрутизатора. Маршрутизатор соединен с четырьмя сетями. Их IP-адреса и длины масок специфицированы в атрибутах ifaddr. inet-rtr: Amsterdam.ripe.net Рис. .36. Объекты inet-rtr Каждый атрибут peer, если он имеется, специфицирует протокольный пиринг с другим маршрутизатором. Значение атрибута peer имеет следующий синтаксис:
где <protocol> - имя протокола, <ipv4-address> - IP-адрес маршрутизатора партнера, а <options> - список опций пиринга для <protocol>. Элементы списка разделяются запятыми. Вместо IP-адресов партнеров, может использоваться его inet-rtr-name. Допустимые имена протоколов и атрибуты определены в словаре (см. раздел 7). В выше приведенном примере, маршрутизатор имеет BGP-пиринг с маршрутизатором 192.87.45.195 в AS3334. Он включает подавление осцилляций маршрута, когда импортирует маршруты из этого маршрутизатора. Вместо одиночного партнера с помощью форм <rtr-set-name> и <peering-set-name> может быть специфицирована группа партнеров. Если использована форма <peering-set- name>, то включаются только пиринги из соответствующего набора данного маршрутизатора. На рис. .37 показан пример объекта inet-rtr с пиринг-группами. rtr-set: rtrs-ibgp-peers Рис. .37. Объект inet-rtr с пиринг-группами 10. Расширение RPSL Практика работы с языками описания маршрутной политики (PRDB [2], RIPE-81 [8], and RIPE-181 [7]) показывает, что язык описания должен быть расширяемым. Новые маршрутные протоколы или новые особенности существующих протоколов могут быть легко описаны, с помощью класса dictionary RPSL. Могут быть добавлены новые классы или новые атрибуты существующих классов. Класс dictionary является первичным механизмом расширения RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и протоколы маршрутизации. Чтобы добавить соответствующее определение rp-атрибута, протокола, или новых особенностей маршрутизатора, вводится модификация словаря RPSL. Когда изменяется словарь, должна быть обеспечена полная совместимость. Например, в случае демпфирования осцилляций аршрута спецификация параметров делается опционной, когда ISP на данном уровне не требует деталей. Предполагается, что любое средство, базирующееся на RPSL, выполняет по умолчанию определенные действия, встретив атрибуты маршрутной политики, которые не распознаны (напр., выдает предупреждение или просто игнорирует). Следовательно, старые средства демпфирования осцилляций маршрутов, обнаружив неизвестные им параметры спецификации, должны эти параметры игнорировать. Любой класс может быть расширен путем добавления новых атрибутов. Для обеспечения полной совместимости новые атрибуты не должны противоречить семантике объектов, к которым они добавлены. Любое средство, которое использует IRR, должно быть устроено так, чтобы игнорировать атрибуты, которые оно не понимает. Введение новых атрибутов рекомендуется, когда у существующего класса появляются новые черты. Например, класс RPSL route расширяет возможности препроцессора RIPE-181 путем введения нескольких новых атрибутов, которые разрешают агрегатирование и спецификации статических маршрутов. Новые классы могут добавляться к RPSL для записи новых типов данных, характеризующих политику. Так как любое средство запрашивает IRR только о классах, которые ему известны, проблемы совместимости возникнуть просто не может. Прежде чем добавлять новый класс, следует ответить на вопрос, относится ли информация, содержащаяся в объекте, к новому классу. Ссылки
B. Грамматические правила Ниже рассмотрены формальные грамматические правила RPSL. Основные типы данных определены в разделе 2. Правила записаны с использованием входного языка грамматического разбора GNU Bison. //**** базовые атрибуты ********************************************* //**** класс aut-num ************************************************* //// as_expression ///////////////////////////////////////////////////// opt_as_expression: | as_expression //// router_expression ///////////////////////////////////////////////// opt_router_expression: | router_expressionopt_router_expression_with_at: | KEYW_AT router_expression router_expression: router_expression OP_OR router_expression_term | router_expression_term router_expression_term: router_expression_term OP_AND router_expression_factor | router_expression_term KEYW_EXCEPT router_expression_factor | router_expression_factor router_expression_factor: '(' router_expression ')' | router_expression_operand router_expression_operand: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME //// пиринг /////////////////////////////////////////////////////////// peering: as_expression opt_router_expression opt_router_expression_with_at| TKN_PRNGNAME //// действие //////////////////////////////////////////////////////////// opt_action: | KEYW_ACTION action action: single_action | action single_action single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';' | TKN_RP_ATTR TKN_OPERATOR list_item ';' | TKN_RP_ATTR '(' generic_list ')' ';' | TKN_RP_ATTR '[' generic_list ']' ';' | ';' //// фильтр //////////////////////////////////////////////////////////// filter: filter OP_OR filter_term | filter filter_term %prec OP_OR | filter_termfilter_term : filter_term OP_AND filter_factor | filter_factor filter_factor : OP_NOT filter_factor | '(' filter ')' | filter_operand filter_operand: KEYW_ANY | '<' filter_aspath '>' | filter_rp_attribute | TKN_FLTRNAME | filter_prefix filter_prefix: filter_prefix_operand OP_MS | filter_prefix_operand filter_prefix_operand: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | TKN_RSNAME | '{' opt_filter_prefix_list '}' opt_filter_prefix_list: | filter_prefix_list filter_prefix_list: filter_prefix_list_prefix | filter_prefix_list ',' filter_prefix_list_prefix filter_prefix_list_prefix: TKN_PRFXV4 | TKN_PRFXV4RNG filter_aspath: filter_aspath '|' filter_aspath_term | filter_aspath_term filter_aspath_term: filter_aspath_term filter_aspath_closure | filter_aspath_closure filter_aspath_closure: filter_aspath_closure '*' | filter_aspath_closure '?' | filter_aspath_closure '+' | filter_aspath_factor filter_aspath_factor: '^' | '$' | '(' filter_aspath ')' | filter_aspath_no filter_aspath_no: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | '.' | '[' filter_aspath_range ']' | '[' '^' filter_aspath_range ']' filter_aspath_range: | filter_aspath_range TKN_ASNO | filter_aspath_range KEYW_PEERAS | filter_aspath_range '.' | filter_aspath_range TKN_ASNO '-' TKN_ASNO | filter_aspath_range TKN_ASNAME filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' | TKN_RP_ATTR TKN_OPERATOR list_item | TKN_RP_ATTR '(' generic_list ')' | TKN_RP_ATTR '[' generic_list ']' //// пара пиринг-действий /////////////////////////////////////////////// import_peering_action_list: KEYW_FROM peering opt_action | import_peering_action_list KEYW_FROM peering opt_action export_peering_action_list: KEYW_TO peering opt_action | export_peering_action_list KEYW_TO peering opt_action //// фактор import/export ////////////////////////////////////////////// import_factor: import_peering_action_list KEYW_ACCEPT filter import_factor_list: import_factor ';' | import_factor_list import_factor ';' export_factor: export_peering_action_list KEYW_ANNOUNCE filter export_factor_list: export_factor ';' | export_factor_list export_factor ';' //// термин import/export //////////////////////////////////////////////// import_term: import_factor ';' | '{' import_factor_list '}' export_term: export_factor ';' | '{' export_factor_list '}' //// выражение import/export ////////////////////////////////////////// import_expression: import_term | import_term KEYW_REFINE import_expression | import_term KEYW_EXCEPT import_expression export_expression: export_term | export_term KEYW_REFINE export_expression | export_term KEYW_EXCEPT export_expression //// протокол /////////////////////////////////////////////////////////// opt_protocol_from: | KEYW_PROTOCOL tkn_word opt_protocol_into: | KEYW_INTO tkn_word //**** атрибуты import/export **************************************** import_attribute: ATTR_IMPORT | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor export_attribute: ATTR_EXPORT | ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor opt_default_filter: | KEYW_NETWORKS filter default_attribute: ATTR_DEFAULT KEYW_TO peering filter_attribute: ATTR_FILTER filter peering_attribute: ATTR_PEERING peering //**** класс inet-rtr ************************************************** ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action //// атрибут peer //////////////////////////////////////////////////// opt_peer_options: | peer_options peer_options: peer_option | peer_options ',' peer_option peer_option: tkn_word '(' generic_list ')' peer_id: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME | TKN_PRNGNAME peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options //**** класс route ***************************************************** aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND | ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression //// атрибут inject ////////////////////////////////////////////////// opt_inject_expression: | KEYW_UPON inject_expression inject_expression: inject_expression OP_OR inject_expression_term | inject_expression_term inject_expression_term: inject_expression_term OP_AND inject_expression_factor | inject_expression_factor inject_expression_factor: '(' inject_expression ')' | inject_expression_operand inject_expression_operand: KEYW_STATIC | KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}' | KEYW_EXCLUDE '{' opt_filter_prefix_list '}' inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action opt_inject_expression //// атрибут components ////////////////////////////////////////////// opt_atomic: | KEYW_ATOMIC components_list: | filter | components_list KEYW_PROTOCOL tkn_word filter components_attribute: ATTR_COMPONENTS opt_atomic components_list //**** набор маршрутов ***************************************************** opt_rs_members_list: /* пустой список */| rs_members_list rs_members_list: rs_member | rs_members_list ',' rs_member rs_member: TKN_ASNO | TKN_ASNO OP_MS | TKN_ASNAME | TKN_ASNAME OP_MS | TKN_RSNAME | TKN_RSNAME OP_MS | TKN_PRFXV4 | TKN_PRFXV4RNG rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list //**** словарь ****************************************************** rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods | ATTR_RP_ATTR TKN_RP_ATTR methods methods: method | methods method method: TKN_WORD '(' ')' | TKN_WORD '(' typedef_type_list ')' | TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')' | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')' | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')' //// атрибут typedef //////////////////////////////////////////////// typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type typedef_type_list: typedef_type | typedef_type_list ',' typedef_type typedef_type: KEYW_UNION typedef_type_list | KEYW_RANGE KEYW_OF typedef_type | TKN_WORD | TKN_WORD '[' TKN_INT ',' TKN_INT ']' | TKN_WORD '[' TKN_REAL ',' TKN_REAL ']' | TKN_WORD '[' enum_list ']' | KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type | KEYW_LIST KEYW_OF typedef_type enum_list: tkn_word | enum_list ',' tkn_word //// атрибут protocol //////////////////////////////////////////////// protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options protocol_options: | protocol_options protocol_option protocol_option: KEYW_MANDATORY method | KEYW_OPTIONAL method //**** Описания лексем ********************************************* //// макросы flex, используемые при определении лексем ///////////////////////////// Документ RFC-2280 [3] содержит раннюю версию языка RPSL. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.11.7 Маршрутная политика
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. Введение Протокол динамической конфигурации ЭВМ DHCP (Dynamic Host Configuration Protocol, RFC-2131, -2132, -2485, -2563, -2610, -2855, -2937, -2939, -3004, -3011, -3046; [22], [23], [24] и [25]) служит для предоставления конфигурационных параметров ЭВМ, подключенных к Интернет. DHCP имеет два компонента: протокол предоставления специфических для ЭВМ конфигурационных параметров со стороны DHCP-сервера и механизм предоставления ЭВМ сетевых адресов. Протокол DHCP используется, помимо загрузки бездисковых станций или Х-терминалов (BOOTP), сервис-провайдерами для пулов модемов, когда число одновременно занятых модемов существенно меньше их полного числа. Это позволяет сэкономить заметное число IP-адресов. Протокол эффективен для случая распределения адресов за Firewall, где ЭВМ в защищенной зоне все равно бессмысленно выделять реальные IP-адреса. DHCP построен по схеме клиент-сервер, где DHCP-сервер выделяет сетевые адреса и доставляет конфигурационные параметры динамически конфигурируемым ЭВМ. ЭВМ не должна действовать как DHCP-сервер, если только она специально не сконфигурирована системным администратором. IP-протокол требует установки многих параметров. Так как IP-протокол может быть использован самым разным сетевым оборудованием, значения этих параметров не могут быть угаданы заранее. Кроме того, схема распределенного присвоения адресов зависит от механизма выявления уже используемых адресов. ЭВМ могут не всегда корректно зарезервировать свои сетевые адреса, таким образом, схема распределенного выделения адресов не может гарантировать уникальности сетевых адресов. DHCP поддерживает три механизма выделения IP-адресов. При "автоматическом выделении", DHCP присваивает клиенту постоянный IP-адрес. При "динамическом присвоении", DHCP присваивает клиенту IP-адрес на ограниченное время. При "ручном выделении", IP-адрес выделяется клиенту сетевым администратором, а DHCP используется просто для передачи адреса клиенту. Конкретная сеть использует один или более этих механизмов, в зависимости от политики сетевого администратора. Динамическое присвоение адресов представляет собой единственный механизм, который позволяет автоматически повторно использовать адрес, который не нужен клиенту. Таким образом, динамическое присвоение адресов является оптимальной схемой для клиентов, подключаемых к сети временно, или совместно использующих один и тот же набор IP-адресов и не нуждающихся в постоянных адресах . Формат сообщений DHCP базируется на формате сообщений BOOTP, чтобы можно было воспользоваться процедурами транспортировки данных, описанными в спецификации BOOTP [7, 21] и обеспечить совместимость DHCP-серверов с существующими клиентами BOOTP. Использование агентов транспортировки BOOTP исключает необходимость наличия DHCP-серверов в каждом физическом сегменте сети. 1.1. Сопряженные разработки Существует несколько протоколов Интернет, которые так или иначе связаны с проблемой присвоения сетевых адресов. Протокол RARP (Reverse Address Resolution Protocol) [10] через расширения, описанные в DRARP (Dynamic RARP [5]), не только позволяет определить сетевой адрес, но и включает в себя автоматический механизм распределения IP-адресов. Протокол TFTP (Trivial File Transfer Protocol) [20] обеспечивает транспортировку загрузочного модуля от boot-сервера. Протокол ICMP (Internet Control Message Protocol) [16] с помощью сообщений "ICMP redirect" информирует ЭВМ о дополнительных маршрутизаторах. ICMP может также предоставить информацию о масках субсетей (сообщения "ICMP mask request"). ЭВМ могут найти маршрутизатор через ICMP-механизм поиска маршрутизаторов [8]. BOOTP является транспортным механизмом сбора конфигурационной информации. Протокол BOOTP является масштабируемым, определены стандартные расширения [17] для нескольких конфигурационных параметров. Морган предложил расширение BOOTP для динамического присвоения IP-адресов [15]. Протокол NIP (Network Information Protocol), использованный в проекте Athena МТИ, предоставляет распределенный динамический механизм выделения IP-адресов [19]. Протокол RLP (Resource Location Protocol [1]) служит для нахождения серверов, предоставляющих услуги верхнего уровня. Бездисковые рабочие станции компании Sun Microsystems используют процедуру загрузки, которая с привлечением механизма RARP, TFTP и RPC, называемого "bootparams", предоставляет бездисковой ЭВМ конфигурационную информацию и фрагменты операционной системы. Существуют разработки, которые позволяют определить для заданного пути максимальный размер пакета (MTU) [14]. Существуют предложение по использованию протокола ARP (Address Resolution Protocol) для нахождения и выбора ресурсов [6]. Наконец, в RFC Host Requirements [3, 4] упоминаются специфические требования к конфигурированию ЭВМ, и предлагается сценарий инициализации бездисковых ЭВМ. 1.2. Постановка задачи Протокол DHCP предназначен для предоставления клиентам DHCP конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент DHCP должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Параметры стека TCP/IP, предоставляемые протоколом DHCP перечислены в приложении A. Не все эти параметры необходимы для первичной инициализации клиента. Клиент и сервер могут согласовывать список необходимых параметров. Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [12, 13]. DHCP не может использоваться для конфигурации маршрутизаторов. 1.3. Терминология В данном документе применены следующие определения:
1.4. Цели Ниже предлагается список основных задач DHCP.
DHCP должен:
2. Краткий обзор протокола С точки зрения клиента, DHCP является расширением механизма BOOTP. Такая схема позволяет существующим BOOTP-клиентам успешно сотрудничать с DHCP-серверами без необходимости изменения стартовой программы клиента. В RFC-1542 [2] детализировано взаимодействие между BOOTP- и DHCP-клиентами и серверами [9]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCP-клиентами и серверами (смотри разделы 3 и 4). На рис. .1 представлен формат сообщения DHCP, а в таблице 1 перечислены поля этого сообщения. Числа в скобках указывают размер каждого из полей в октетах. Существует два принципиальных отличия между DHCP и BOOTP. Во-первых, DHCP определяет механизмы, через которые клиентам на определенное время могут быть присвоены сетевые адреса, позволяя последовательное присвоение сетевого адреса различным клиентам. Во-вторых, DHCP предоставляет механизм, который позволяет клиенту получить все необходимые им для работы конфигурационные параметры. DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле "vendor extensions" в BOOTP переименовано в поле "опции" в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP "vendor extensions", которые именовались как "расширения производителя", теперь называются просто "опции".
Рис. 1. Формат сообщения DHCP DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1. Таблица 1. Описание полей сообщения DHCP
Поле опции имеет переменную длину. Клиент DHCP должен быть готов получать DHCP-сообщения с полем 'опции' длиной, по крайней мере, 312 октетов. Это требование подразумевает, что DHCP-клиент должен быть готов получать сообщения длиной до 576 октетов. DHCP-клиенты могут согласовать применение более длинных DHCP-сообщений с помощью опции 'maximum DHCP message size'. Поле options может быть еще расширено в полях 'файл' и 'sname'. В случае, когда клиент использует DHCP для начальной конфигурации (прежде чем программа клиента TCP/IP полностью сконфигурирована), DHCP требует использования клиентского программного обеспечения TCP/IP в вольной интерпретации RFC-1122. Программа TCP/IP должна принять и передать IP-уровню любой IP-пакет, доставленный по аппаратному адресу клиента, до того как IP-адрес будет сконфигурирован; DHCP-серверы и агенты транспортировки BOOTP могут быть неспособны доставить DHCP-сообщения клиентам, которые не могут принимать уникастные дейтограммы, до того, как программа TCP/IP сконфигурирована должным образом. Для того чтобы работать с клиентами, которые не могут воспринимать уникастные IP-дейтограммы до того, как будет сконфигурирована программа TCP/IP, DHCP использует поле 'флаги' [21]. Самый левый бит определен как флаг BROADCAST (B). Остающиеся биты поля флаги зарезервированы на будущее. Они должны быть установлены равными нулю клиентами и игнорироваться серверами и агентами транспортировки. На рис. 2 показан формат поля флаги.
B: флаг BROADCAST Рис. .2: Формат поля 'флаги' 2.1. Основные конфигурационные параметры Первым видом сервиса, предоставляемого DHCP, является запоминание сетевых параметров для клиента. Модель DHCP памяти характеризуется записями ключ - значение для каждого клиента, где ключ представляет собой некоторый уникальный идентификатор (например, номер IP-субсети и уникальный идентификатор в пределах субсети), а значение содержит набор конфигурационного параметров клиента. Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип "аппаратного адреса" с тем, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы, ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCP-клиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно из-за выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не прелагает идентификатор в явном виде, используя опцию 'client identifier'. Клиент может запросить DHCP-сервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры. 2.2. Динамическое выделение сетевых адресов Вторым видом сервиса, предоставляемым DHCP, является временное или постоянное выделение клиенту сетевого (IP) адреса. Основной механизм для динамического присвоения сетевых адресов достаточно прост: клиент запрашивает использование адреса на определенный период времени. Механизм выделения адреса (ассоциация DHCP-серверов) гарантирует, что адрес в течение оговоренного времени не будет использован для других целей, и пытается прислать тот же сетевой адрес всякий раз, когда клиент его запрашивает. Клиент может расширить это время последующими запросами. Клиент может послать серверу сообщение об освобождении адреса, когда клиент более не нуждается в этом адресе. Клиент может запросить постоянное присвоение адреса, потребовав бесконечное значение времени выделения адреса. Даже при "постоянном" выделении адресов, сервер может определить большой, но не бесконечный срок аренды адреса, чтобы позволить детектирование факта, что клиент перестал работать. При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса из-за отсутствия свободных адресов. При таких условиях, механизм выделения будет повторно присваивать адреса, чье время действительности истекло. Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно. Например, сервер может выбрать последний из присвоенных адресов. В качестве проверки совместимости сервер должен проверить повторно используемые адреса, прежде чем их повторно пускать в оборот. Это может быть, например, контроль посредством ICMP эхо-запроса, а клиент должен проверить вновь полученный адрес, например, посредством ARP. 3. Протокол клиент-сервер DHCP использует формат сообщение BOOTP, определенный в RFC-951 и представленный в таблице 1 и на рис. 1. Поле 'op' каждого сообщения DHCP, посланного клиентом серверу, содержит BOOTREQUEST. В поле 'op' DHCP-сообщения, посланного сервером клиенту, заносится BOOTREPLY. Первые 4 октета поля 'опции' сообщения DHCP содержат (десятичные) коды 99, 130, 83 и 99, соответственно (это те же коды (magic cookie), что определены в RFC-1497 [17]). Остальная часть поля 'опции' состоит из списка помеченных параметров, которые называются "опции". Все "vendor extensions" перечисленные в RFC-1497, являются также опциями DHCP. Документ RFC-1533 предоставляет полный набор опций, определенных для использования с DHCP. Несколько опций уже определено. Одной из них является опция "DHCP message type", которая должна включаться во все DHCP-сообщения. Эта опция определяет тип DHCP-сообщения. Дополнительные опции могут допускаться, требоваться или не разрешаться в зависимости от типа DHCP-сообщения. В рамках данного документа, DHCP-сообщения, которые содержат опцию 'тип сообщения DHCP' будут восприниматься согласно типу сообщения; например, сообщение DHCP с типом опции равным 1 будет восприниматься как сообщение "DHCPDISCOVER". 3.1. Взаимодействие клиента и сервера при выделении сетевого адреса Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на рис. 3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены; такое упрошенное взаимодействие описано в разделе 3.2.
Таблица 2: Сообщения DHCP
Рис. 3. Временная диаграмма обмена сообщениями между DHCP-клиентом и сервером в ходе присвоения нового сетевого адреса 3. Клиент получает одно или более сообщений DHCPOFFER от одного или более серверов. Клиент может предпочесть дождаться нескольких откликов. Клиент выбирает один сервер, которому пошлет запрос конфигурационных параметров, согласно предложению, содержащемуся в сообщении DHCPOFFER. Клиент широковещательно отправляет сообщение DHCPREQUEST, которое должно содержать опцию 'server identifier', чтобы указать, какой сервер им выбран, и которое может включать в себя другие опции, специфицирующие желательные конфигурационные значения. Опция 'requested IP-адрес' в сообщении сервера DHCPOFFER должна содержать значение 'yiaddr'. Сообщение DHCPREQUEST посылается широковещательно агентами транспортировки DHCP/BOOTP. Для того чтобы быть уверенным, что любой агент транспортировки BOOTP направляет сообщение DHCPREQUEST тому же набору DHCP-серверов, которые получили исходное сообщение DHCPDISCOVER, сообщение DHCPREQUEST должно использовать то же значение поля 'secs' заголовка DHCP-сообщения и должно посылаться по тому же широковещательному IP-адресу, что и оригинальное сообщение DHCPDISCOVER. Клиент реализует таймаут и повторно посылает сообщение DHCPDISCOVER, если не получает сообщений DHCPOFFER.
Клиент реализует таймаут и повторно посылает сообщение DHCPREQUEST, если клиент не получает ни сообщения DHCPACK ни DHCPNAK. Клиент повторно посылает DHCPREQUEST согласно алгоритму повторной пересылки, описанному в разделе 4.1. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго; например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно послать сообщение DHCPREQUEST четыре раза, при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент не получает ни сообщения DHCPACK ни DHCPNAK после применения алгоритма повторной пересылки, клиент возвращается в исходное состояние и перезапускает процесс инициализации. Клиент должен уведомить пользователя о том, что процесс инициализации не прошел и делается повторная попытка.
3.2. Взаимодействие клиента и сервера при повторном использовании ранее выделенных сетевых адресов Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма на рис. 4 показывает типовое взаимодействие клиента и сервера в случае повторного использования старого сетевого адреса.
Рис. .4. Временная диаграмма обмена сообщениями между DHCP-клиентов и сервером при повторном присвоении ранее использованного сетевого адреса Если запрос клиента не корректен (например, клиент переместился в другую субсеть), серверы должны реагировать посылкой клиенту сообщения DHCPNAK. Серверы не должны откликаться, если их информация не абсолютно надежна. Например, сервер, который идентифицирует запрос для набора параметров, который принадлежит другому серверу, и имеет истекший срок действия, сервер не должен реагировать сообщением DHCPNAK, если только серверы не используют явно механизм поддержания когерентности. Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент может не иметь правильного сетевого адреса или сетевой маски, и клиент может не отвечать на ARP-запрос. В противном случае, сервер должен послать сообщение DHCPNAK по IP-адресу транспортного агента BOOTP, записанного в 'giaddr'. Транспортный агент, в свою очередь, переадресует сообщение непосредственно по аппаратному адресу клиента, так что DHCPNAK будет доставлен, даже если клиент переместился в другую сеть.
Если клиент обнаруживает, что IP-адрес в сообщении DHCPACK уже использован, клиент должен послать сообщение DHCPDECLINE серверу и повторно запустить процесс конфигурации, послав запрос на новый сетевой адрес. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP, которая описана в разделе 4.4. Если клиент получает сообщение DHCPNAK, он не может повторно использовать свой запомненный сетевой адрес. Он должен вместо этого запросить новый адрес путем повторного запуска конфигурационного процесса. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP. Клиент выполняет таймаут и повторно посылает сообщение DHCPREQUEST. Если клиент не получает ни сообщения DHCPACK, ни DHCPNAK, клиент, согласно алгоритму из раздела 4.1, повторно посылает сообщение DHCPREQUEST. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго. Например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно передать сообщение DHCPREQUEST четыре раза при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент после повторной пересылки не получил ни сообщения DHCPACK, ни DHCPNAK, он может решить использовать присвоенный ранее сетевой адрес и конфигурационные параметры вплоть до истечения срока их действия. Это соответствует переходу в состояние BOUND на диаграмме состояний клиента, показанной на рис. 5.
Заметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора, например, клиент намеривается перейти в другую субсеть, он будет должен послать сообщение DHCPRELEASE. 3.3. Интерпретация и представление значений времени Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности. Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в DHCP-сообщения являются относительными, и должны интерпретироваться с учетом показаний локальных часов клиента. Время измеряется в секундах и представляется в виде 32-битных кодов без знака. Это позволяет описывать относительные интервалы времени от 0 до примерно 100 лет, что вполне приемлемо для целей протокола DHCP. Алгоритм интерпретации времени действия конфигурационного набора, представленный в предыдущем параграфе, предполагает, что часы клиента и сервера стабильны относительно друг друга. Если имеется относительный дрейф этих часов, сервер может считать время действия конфигурационного набора исчерпанным, а клиент - нет. Чтобы компенсировать такого рода эффект, сервер может послать клиенту значение времени действия короче того, которое он записывает в свою базу данных. 3.4. Получение параметров при внешне заданных адресах Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM. Сервер в целях совместимости должен проверить сетевой адрес в сообщении DHCPINFORM, но не должен проверять существующее значение времени действия конфигурационного набора. Сервер формирует сообщение DHCPACK, содержащее конфигурационные параметры для клиента, приславшего запрос, и посылает сообщение DHCPACK непосредственно клиенту. 3.5. Параметры клиента в DHCP Не все клиенты требуют инициализации всех параметров, перечисленных в приложении A. Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту. 1. Большинство параметров имеет значения по умолчанию, определенные в Host Requirements RFC; если клиент не получил параметров от сервера, которые переписывают значения по умолчанию, клиент использует эти значения. 2. В своем исходном сообщении DHCPDISCOVER или DHCPREQUEST, клиент может предоставить серверу список специфических параметров, которые ему нужны. Если клиент включает список параметров в сообщение DHCPDISCOVER, он должен включать этот список в любое последующее сообщение DHCPREQUEST. Клиент должен включить опцию 'maximum DHCP message size', чтобы позволить серверу знать, максимальный размер его DHCP-сообщений. Параметры, присланные в ответ клиенту, могут иметь размер больший, чем выделено для опций в сообщении DHCP. В этом случае, два дополнительных опционных флага (которые должны присутствовать в поле 'опции' сообщения) индицируют, что для опций должны использоваться поля 'file' и 'sname'. Клиент может проинформировать сервер о том, в каких конфигурационных параметрах заинтересован клиент, включив опцию 'parameter request list'. Кроме того, клиент может предложить значения для сетевого адреса и времени его действия в сообщении DHCPDISCOVER. Клиент может включить опцию 'requested IP-адрес', чтобы предложить конкретное значение IP-адреса, которое он хотел бы получить, и может включить опцию 'IP-адрес lease time', чтобы предложить предпочтительное значение времени действия конфигурационного набора. Другие опции, представляющие рекомендации по конфигурационным параметрам, допустимы в сообщении DHCPDISCOVER или DHCPREQUEST. Однако дополнительные опции могут игнорироваться серверами, и разные серверы могут прислать различные отклики на одни и те же опции. Опция 'requested IP-адрес' должна заноситься только в сообщение DHCPREQUEST, когда клиент проверяет конфигурационные параметры, полученные ранее. Клиент заполняет поле 'ciaddr', только когда он имеет корректный IP-адрес в состояниях BOUND, RENEWING или REBINDING. Если сервер получает сообщение DHCPREQUEST с некорректным 'запрошенным IP-адресом', он должен прислать клиенту сообщение DHCPNAK и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения. 3.6. Применение DHCP для клиентов с несколькими интерфейсами Клиент с несколькими сетевыми интерфейсами должен использовать DHCP для получения конфигурационных параметров через каждый из интерфейсов независимо. 3.7. Когда клиентам следует использовать DHCP? Клиент должен использовать DHCP для нового запроса или верификации своего IP-адреса и сетевых параметров всякий раз, когда локальные конфигурационные параметры изменились; например, во время перезагрузки системы или после сетевого разрыва, так как локальная сетевая конфигурация может измениться без информирования об этом клиента или пользователя. Если клиент знает предыдущий сетевой адрес и не может контактировать с локальным DHCP-сервером, клиент может продолжать использовать предыдущий сетевой адрес до тех пор, пока время действия адреса не истечет. Если время действия исчерпано до того, как клиент смог контактировать с DHCP-сервером, клиент должен немедленно прекратить использование текущего сетевого адреса и может проинформировать о данной проблеме локального пользователя. 4. Спецификация протокола DHCP для системы клиент-сервер В этом разделе, мы предполагаем, что DHCP-сервер имеет блок сетевых адресов, из которого он может удовлетворять запросы. Каждый сервер поддерживает базу данных присвоенных адресов и времен их действия. 4.1. Формирование и посылка сообщений DHCP Клиенты и серверы DHCP конструируют DHCP-сообщения путем заполнения полей в секции сообщения с фиксированным форматом и присоединяя помеченные информационные элементы переменной длины в секции опций. Область опций включает в себя 4-октетную секцию 'magic cookie' (которая описана в разделе 3), за которой следуют собственно опции. Последняя опция должна быть всегда опцией 'end'. DHCP использует в качестве транспортного протокола UDP. DHCP-сообщения от клиента к серверу посылаются через порт DHCP-сервера (67), а DHCP-сообщения от сервера к клиенту посылаются через порт DHCP-клиента (68). Сервер с несколькими сетевыми адресами (например, ЭВМ с несколькими сетевыми интерфейсами) может использовать для передачи исходящего DHCP-сообщения любой из своих сетевых адресов. Поле 'server identifier' используется как для идентификации DHCP-сервера в DHCP-сообщении, так и в качестве адреса места назначения при передаче информации от клиента серверу. Сервер с несколькими сетевыми адресами должен быть готов воспринимать любой из своих сетевых адресов в качестве идентификатора в DHCP-сообщении. Чтобы адаптироваться к потенциально не полной сетевой коннективности, сервер должен выбрать адрес в качестве 'server identifier', который по информации сервера доступен со стороны клиента. Например, если DHCP-сервер и DHCP-клиент подключены к одной субсети (т.e., поле 'giaddr' в сообщении от клиента равно нулю), сервер должен выбрать свой IP-адрес, используемый для передачи в пределах субсети в качестве 'server identifier'. Если сервер использует несколько IP-адресов в субсети, он может воспользоваться любым таким адресом. Если сервер получил сообщение через DHCP-агента доставки, сервер должен в качестве 'server identifier' выбрать адрес интерфейса, через который получено сообщение, (если только сервер не имеет других, лучших идей по поводу такого выбора). DHCP-клиенты должны использовать IP-адрес, переданный через опцию 'server identifier', для любого уникастного запроса, адресованного DHCP-серверу. Сообщения DHCP посылаются клиентом широковещательно, до тех пор пока он не получит свой IP-адрес, адрес поля отправителя в IP-заголовке при этом должно быть равно нулю. Если поле 'giaddr' в DHCP-сообщении клиента не равно нулю, сервер посылает любой отклик в порт 'DHCP server' агента транспортировки BOOTP, чей адрес указан в 'giaddr'. Если поле 'giaddr' равно нулю, а поле 'ciaddr' не равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по уникастному адресу, записанному в поле 'ciaddr'. Если 'giaddr' равно нулю и 'ciaddr' равно нулю, а бит broadcast =1, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по адресу 0xffffffff. Если бит broadcast =1 и 'giaddr' равно нулю и 'ciaddr' равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по аппаратному адресу клиента и адресу 'yiaddr'. Во всех случаях, когда 'giaddr' равно нулю, сервер широковещательно посылает любое сообщение DHCPNAK по адресу 0xffffffff. Если опции в DHCP-сообщении распространяются на поля 'sname' и 'файл', в поле 'опции' должна появиться опция 'option overload', со значением 1, 2 или 3, как это специфицировано в RFC-1533. Если в поле 'опции' присутствует опция 'option overload', опции в этом поле должны завершаться опцией 'end', и могут содержать один или более опций 'pad' (заполнитель). Опции в полях 'sname' и 'файл' (если их применение индицировано опцией 'options overload') должны начинаться с первого октета поля, завершаться опцией 'end', и за ними для заполнения пространства до конца поля должны следовать опции 'pad'. Любая индивидуальная опция в полях 'опции', 'sname' и 'файл' должна полностью умещаться в поле. Опции в поле 'options' должны интерпретироваться первыми, так чтобы любая 'option overload' могла быть воспринята. Поле 'файл' должно интерпретироваться следующим (если опция 'option overload' указывает, что поле 'файл' содержит опции DHCP), за ним должно следовать поле 'sname'. Значения, передаваемые в метку 'option' могут превосходить по длине 255 октетов, выделенных на одну опцию (например, список маршрутизаторов опции 'router' [21]). Опции могут появляться только раз, если только явно не указано обратного. Клиент присоединяет значения кратных опций к общему списку параметров для конфигурации. Клиенты DHCP ответственны за доставку всех сообщений. Клиент должен адаптировать стратегию повторных передач, которая включает в себя экспоненциальный алгоритм вычисления псевдослучайных задержек между повторными пересылками. Задержки между повторными пересылками должны быть выбраны так, чтобы предоставить достаточно времени для ответов сервера с учетом условия связи между клиентом и сервером. Например, в сети 10Mбит/c Ethernet, задержка перед первой повторной посылкой должна быть случайным образом равномерно распределенной при среднем значении 4 секунды. Задержка следующей (второй) ретрансмиссии должна быть также случайной и составлять 8 секунд. Значения последовательных повторных передач должны при каждой последующей попытке удваиваться. Максимальное значение равно 64 секунд. Клиент может обеспечить для пользователя индикацию попыток повторной передачи. Поле 'xid' используется клиентом для установления соответствия между приходящим DHCP-сообщением и отправленного ранее запросом. DHCP-клиент должен выбрать 'xid так чтобы минимизировать вероятность получения идентичных 'xid' разными клиентами. Например, клиент может выбирать разные, случайные начальные 'xid' каждый раз, когда клиент перезагружается, а далее использует инкрементацию этого значения при последующих передачах вплоть до следующей перезагрузки. Выбор нового 'xid' для каждой последующей повторной передачи относится на усмотрение конкретной программной реализации. Клиент может решить повторно использовать то же самое значение 'xid' или выбрать новый 'xid' для передачи каждого сообщения. В норме, DHCP-серверы и агенты доставки BOOTP пытаются доставить сообщения DHCPOFFER, DHCPACK и DHCPNAK непосредственно клиенту, используя уникастную адресацию. IP-адрес места назначения (в IP-заголовке) равен адресу 'yiaddr', а адрес связного уровня равен 'chaddr'. К сожалению, некоторые реализации клиентов не могут получать уникастные IP-дейтограммы до тех пор, пока приложение не будет сконфигурировано и клиент не получит корректный IP-адрес (это ведет к тупику, когда IP-адрес не может быть получен клиентом до тех пор, пока в результате конфигурационного процесса он этот самый адрес не получит). Клиент, который не может получать уникастные IP-дейтограммы, пока его протокольная программа не сконфигурирована, должен установить бит BROADCAST=1 в поле флагов в любом сообщении DHCPDISCOVER или DHCPREQUEST, которые клиент посылает. Бит BROADCAST укажет, что DHCP-сервер и агент транспортировки BOOTP должны посылать клиенту сообщения широковещательно. Клиент, который может получать уникастные IP-дейтограммы до того как его программа сконфигурирована, должен сделать бит BROADCAST равным 0. Сервер или агент доставки, посылающие или передающие DHCP-сообщение непосредственно DHCP-клиенту (т.e., не агенту транспортировки, указанному в поле 'giaddr'), должны анализировать бит BROADCAST поля 'флаги'. Если этот бит равен 1, DHCP-сообщение должно быть послано как широковещательное по адресу 0xffffffff. Если бит BROADCAST равен 0, сообщение должно быть послано по уникастному IP-адресу указанному в поле 'yiaddr'. Если уникастная транспортировка невозможна, сообщение может быть послано по широковещательному адресу 0xffffffff. 4.2. Административное управление сервером DHCP DHCP-серверы не обязаны откликаться на каждое сообщение DHCPDISCOVER и DHCPREQUEST, которое они получают. Например, сетевой администратор с целью сохранения строгого контроля за клиентами, подключенными к сети, может захотеть сконфигурировать DHCP-серверы так, чтобы они реагировали только на клиентов, которые были зарегистрированы ранее с помощью некоторого внешнего механизма. Спецификация DHCP описывает только взаимодействие между клиентами и серверами, когда они хотят этого; описание административного контроля со стороны системного администратора находится вне пределов данной спецификации. Специальные реализации DHCP-серверов могут включать в себя любые механизмы административного контроля. При некоторых условиях, DHCP-сервер будет должен проанализировать значения опций vendor class, включенные в сообщения DHCPDISCOVER или DHCPREQUEST с тем, чтобы определить корректные параметры для конкретного клиента. DHCP-сервер должен использовать некоторый уникальный идентификатор, для того чтобы установить соответствие между клиентом и его набором конфигурационных параметров. Клиент может решить выдать идентификатор с помощью опции 'client identifier'. Если клиент предоставляет 'client identifier', он должен использовать его во всех последующих сообщениях, а сервер должен использовать этот идентификатор для распознавания клиента. Если клиент не предоставляет опцию 'client identifier', сервер должен для идентификации клиента использовать содержимое поля 'chaddr'. Для клиента DHCP весьма важно использовать уникальный идентификатор в пределах субсети, к которой он подключен согласно опции 'client identifier'. Использование 'chaddr' в качестве уникального идентификатора клиента может вызвать непредсказуемые результаты, так как такой идентификатор может быть ассоциирован с аппаратным интерфейсом, который может быть передан новому клиенту. Чтобы избежать непредсказуемых изменений сетевого адреса клиента (из-за переноса аппаратного интерфейса) некоторые узлы могут использовать в качестве идентификатора клиента серийный номер производителя. Сетевые узлы могут также использовать в качестве идентификатора клиента DNS-имя. Клиенты DHCP вольны использовать любую стратегию при выборе DHCP-сервера из числа тех, список которых клиент получает в сообщении DHCPOFFER. Реализация клиента должна предоставлять для пользователя механизм выбора значений 'vendor class identifier'. 4.3. Поведение сервера DHCP DHCP-сервер обрабатывает приходящие от клиента DHCP-сообщения на основе текущего состояния набора конфигурирующих параметров клиента. DHCP-сервер может получать от клиента следующие сообщения: o DHCPDISCOVER В таблице 3 рассмотрено использование полей и опций в DHCP-сообщении сервера. 4.3.1. Сообщение DHCPDISCOVER Когда сервер получает от клиента сообщение DHCPDISCOVER, он выбирает сетевой адрес для клиента, приславшего запрос. Если нет свободного адреса, сервер может проинформировать о проблеме системного администратора. Если адрес доступен, новый адрес должен быть выбран следующим образом:
Как это описано в разделе 4.2, сервер может, по административным причинам, присвоить адрес отличный от запрошенного, или может повторно использовать адрес для конкретного клиента, даже если имеются свободные адреса. Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации. Если это не требуется для корректной работы DHCP, сервер не должен повторно использовать выбранный сетевой адрес, прежде чем клиент пришлет сообщение серверу DHCPOFFER. Сервер может решить записать этот адрес, как предложенный клиенту. Он должен также выбрать время действия конфигурационного набора, согласно следующим правилам:
Таблица 3. Поля и опции, используемые DHCP-серверами
Раз сетевой адрес и конфигурационный набор параметров определены, сервер формирует сообщение DHCPOFFER с предлагаемыми конфигурационными параметрами. Для всех DHCP-серверов важно прислать одни и те же параметры (с единственно возможным исключением - новым предлагаемым сетевым адресом), что гарантирует предсказуемое поведение клиента вне зависимости от того, какой из серверов он выберет. Конфигурация параметров должна быть выбрана согласно следующим правилам, представленным ниже. Сетевой администратор ответственен за конфигурацию всех DHCP-серверов, что гарантирует однородность откликов этих серверов. Сервер должен прислать клиенту:
Сервер должен предоставить столько запрошенных параметров, сколько возможно, должен опустить любые параметры, которые не может предоставить. Сервер должен включить каждый запрошенный параметр только один раз, если только не разрешено обратного в опциях DHCP и в документе Vendor Extensions BOOTP.
Сервер может прислать 'vendor class identifier', использованный чтобы определить параметры в сообщении DHCPOFFER, чтобы помочь клиенту решить, какой выбрать DHCPOFFER. Сервер вводит поле 'xid' из сообщения DHCPDISCOVER в поле 'xid' сообщения DHCPOFFER и посылает клиенту, приславшему запрос, сообщение DHCPOFFER. 4.3.2. Сообщение DHCPREQUEST Сообщение DHCPREQUEST может прийти от клиента, реагирующего на сообщение сервера DHCPOFFER, от клиента, верифицирующего ранее выделенный IP-адрес, или от клиента, расширяющего время действия конфигурационного набора. Если сообщение DHCPREQUEST содержит опцию 'server identifier', то это отклик на сообщение DHCPOFFER. В противном случае, сообщение является запросом верификации или расширения времени действия набора. Если клиент использует 'client identifier' в сообщении DHCPREQUEST, он должен использовать его во всех последующих сообщениях. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включить этот список во все последующие сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с полученными ранее в сообщении DHCPOFFER. Клиент должен использовать для конфигурации параметры из сообщения DHCPACK. Клиенты посылают сообщения DHCPREQUEST следующим образом: o DHCPREQUEST, сформированный в состоянии SELECTING: Клиент вводит адрес выбранного сервера 'server identifier', 'ciaddr' должен быть равен нулю, в 'запрошенный IP-адрес' должно быть записано значение yiaddr, взятое из DHCPOFFER. Заметим, что клиент может собрать несколько сообщений DHCPOFFER и выбрать наилучшее предложение. Клиент определяет свой выбор путем идентификации сервера в сообщении DHCPREQUEST. Если клиент получает неприемлемые предложения, клиент может попробовать другое сообщение DHCPDISCOVER. Следовательно, серверы не могут получить DHCPREQUEST, из которого они могли бы решить, принял ли клиент данное предложение. Так как серверы не осуществили присвоение какого-либо сетевого адреса на основе DHCPOFFER, они вольны повторно использовать предложенные сетевые адреса в откликах на последующие запросы. Серверы не должны повторно использовать предложенные адреса и могут реализовать зависимый от реализации механизм таймаутов в процессе принятия решения о повторном использовании предложенных адресов. o DHCPREQUEST генерируется в состоянии INIT-REBOOT: Поле 'server identifier' не должно быть заполнено, в опции 'Запрошенный IP-адрес' должен быть записан предшествующий адрес, присвоенный клиенту. 'ciaddr' должен быть равен нулю. Клиент пытается верифицировать присвоенный ранее конфигурационный набор. Сервер должен клиенту послать сообщение DHCPNAK, если 'запрошенный IP-адрес' не корректен, или относится к неверной сети. Определение того, находится ли клиент в состоянии INIT-REBOOT, осуществляется просмотром содержимого 'giaddr', опции 'requested IP-адрес', и базы данных. Если DHCP-сервер обнаружит, что клиент находится не в той сети (т.e., результат наложения локальной маски субсети или маски удаленной субсети (если 'giaddr' не равно нулю) на опцию 'запрошенный IP-адрес' выдает не реальный результат), тогда сервер должен послать клиенту сообщение DHCPNAK. Если с сетью все в порядке, тогда DHCP-сервер должен проверить, корректна ли запись клиента о его IP-адресе. Если нет, сервер должен послать клиенту сообщение DHCPNAK. Если DHCP-сервер не имеет записи об этом клиенте, тогда он должен оставаться пассивным, и может выдать предупреждение сетевому администратору. Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент не может иметь корректный сетевой адрес или сетевую маску, и клиент не может откликаться на ARP-запросы. Если в сообщении DHCPREQUEST установлен 'giaddr', клиент находится в другой субсети. Сервер должен установить широковещательный бит в DHCPNAK, агент отклика пошлет клиенту сообщение DHCPNAK широковещательно, так как клиент может не иметь корректного сетевого адреса или сетевой маски, и клиент может не откликаться на ARP-запросы. o DHCPREQUEST генерируется в состоянии RENEWING: 'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается расширить срок действия конфигурационного набора. Это сообщение будет послано по уникастному адресу, таким образом, в обмен не будет вовлечено никаких агентов транспортировки. Так как 'giaddr' не заполнен, DHCP-сервер будет полагаться на значениеn 'ciaddr', и использовать его при передаче данных клиенту. Клиент может пожелать обновить или расширить время действия конфигурационного набора до T1. Сервер может пожелать не расширять время действия (например, по решению сетевого администратора), но должен в любом случае откликнуться сообщением DHCPACK. o DHCPREQUEST генерируется в состоянии REBINDING: 'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается увеличить время действия набора параметров. Это сообщение должно быть передано широковещательно по IP-адресу 0xffffffff. DHCP-сервер должен проверить корректность 'ciaddr' прежде чем откликаться на DHCPREQUEST. DHCPREQUEST от клиента в состоянии REBINDING имеет целью согласовать узлы, имеющие несколько DHCP-серверов, а также предложить механизм для согласования времен действия конфигурационных наборов, предлагаемых разными серверами. DHCP-сервер может расширить время действия набора параметров клиента, только если он имеет для этого административные привилегии. 4.3.3. Сообщение DHCPDECLINE Если сервер получает сообщение DHCPDECLINE, клиент каким-то образом обнаружил, что предлагаемый сетевой адрес уже используется. Сервер должен пометить сетевой адрес как недоступный и уведомить администратора системы о возможной конфигурационной проблеме. 4.3.4. Сообщение DHCPRELEASE При получении сообщения DHCPRELEASE, сервер помечает сетевой адрес, как не присвоенный. Сервер должен хранить запись с конфигурационными параметрами клиента для возможного последующего использования при поступлении соответствующего запроса. 4.3.5. Сообщение DHCPINFORM Сервер реагирует на сообщение DHCPINFORM посылкой сообщения DHCPACK непосредственно по адресу, записанному в поле 'ciaddr' сообщения DHCPINFORM. Сервер не должен уведомлять клиента об истечении времени действия конфигурационного набора и не должен производить запись в 'yiaddr'. Сервер включает в сообщение DHCPACK другие параметры, как это определено в разделе 4.3.1. 4.3.6. Сообщения клиента Таблица 4 характеризует различие между сообщениями клиента в различных состояниях Таблица 4. Сообщения клиента для различных состояний
4.4. Поведение клиента DHCP На рис. 5 представлена диаграмма состояний для DHCP-клиента. Клиент может получить следующие сообщения от сервера: o DHCPOFFER Сообщение DHCPINFORM не показано на рис. 5. Клиент просто посылает DHCPINFORM и ждет сообщения-отклика DHCPACK. Раз клиент выбрал свои параметры, он завершил процесс конфигурации. Таблица 5 описывает использование полей и опций DHCP-сообщения клиента.
Рис. 5. Диаграмма состояний DHCP-клиента 4.4.1. Инициализация и выделение сетевого адреса Клиент начинает работу в состоянии INIT и формирует сообщение DHCPDISCOVER. Клиент должен ждать случайное время в интервале 1-10 секунд, для того чтобы десинхронизовать процессы при запуске DHCP. Клиент устанавливает 'ciaddr' равным 0x00000000. Клиент может запросить специфические параметры путем включения опции 'parameter request list'. Клиент может предложить сетевой адрес и/или время действия набора параметров путем включения опций 'запрошенный IP-адрес' и 'IP-address lease time'. Клиент должен включить его аппаратный адрес в поле 'chaddr', если это необходимо для доставки DHCP-откликов. Клиент может включить уникальный идентификатор в опцию 'client identifier', как это описано в разделе 4.2. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включать этот список во все последующие сообщения. Клиент генерирует и записывает случайный идентификатор транзакции, вставляет этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для использования позднее при вычислении времени пригодности набора конфигурационных параметров. Клиент затем посылает широковещательно DHCPDISCOVER по локальному аппаратному адресу 0xffffffff, по широковещательному IP-адресу и UDP-порту 'DHCP-сервера'. Если 'xid' приходящего сообщения DHCPOFFER не согласуется с 'xid' последнего сообщения DHCPDISCOVER, сообщение DHCPOFFER должно молча игнорироваться. Любое приходящее сообщение DHCPACK должно молча игнорироваться. Клиент собирает сообщения DHCPOFFER за определенный период времени, выбирает одно сообщение DHCPOFFER из числа приходящих сообщений DHCPOFFER (например, первое сообщение DHCPOFFER или сообщение DHCPOFFER от сервера, используемого ранее) и извлекает адрес сервера из опции 'server identifier' сообщения DHCPOFFER. Время, в течение которого клиент собирает сообщения, и механизм, используемый для выбора одного DHCPOFFER зависит от конкретной реализации. Таблица 5. Поля и опции, используемые клиентами DHCP
Если параметры приемлемы, клиент записывает адрес сервера, который предоставляет параметры из поля 'server identifier' и посылает этот адрес в поле 'server identifier' широковещательного сообщения DHCPREQUEST. Раз от сервера пришло сообщение DHCPACK, клиент инициализирован и переходит в состояние BOUND. Сообщение DHCPREQUEST содержит тот же 'xid' что и сообщение DHCPOFFER. Клиент записывает время истечения действия конфигурационного набора как сумму времени, когда был послан исходный запрос и длительности действия конфигурационного набора из сообщения DHCPACK. Клиент должен выполнить проверку предложенного адреса, чтобы убедиться, что адрес не используется. Например, если клиент находится в сети, которая поддерживает ARP, клиент может послать запрос ARP для предложенного адреса. При посылке широковещательного ARP-запроса для предлагаемого адреса, клиент должен записать туда, как отправитель, свой аппаратный адрес, и 0 в качестве IP-адреса отправителя, чтобы исключить конфликт с ARP-кэшами в других ЭВМ той же субсети. Если оказалось, что сетевой адрес используется, клиент должен послать серверу сообщение DHCPDECLINE. Клиент должен широковещательно послать ARP-отклик, чтобы уведомить о новом IP-адресе клиента и удалить устаревшие записи из ARP-кэша ЭВМ, размещенных в той же субсети. 4.4.2. Инициализация при известном сетевом адресе Клиент начинает работу в состоянии INIT-REBOOT и посылает сообщение DHCPREQUEST. Клиент должен вставить свой сетевой адрес в опцию 'requested IP-адрес' сообщения DHCPREQUEST. Клиент может запросить специфические конфигурационные параметры, включив опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и заносит этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для последующего использования при вычислении времени истечения пригодности конфигурационного набора параметров. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST. Клиент затем широковещательно посылает DHCP-серверу сообщение DHCPREQUEST с использованием аппаратного широковещательного адреса и UDP-порта. Раз от какого-то сервера пришло сообщение DHCPACK с полем 'xid' согласующимся с тем, которое содержится в сообщении клиента DHCPREQUEST, клиент инициализирован и он переходит в состояние BOUND. Клиент записывает время истечения годности конфигурационного набора параметров, которое равно сумме времени, когда было послано сообщение DHCPREQUEST и длительности пригодности конфигурационного набора, взятого из сообщения DHCPACK. 4.4.3. Инициализация при сетевом адресе заданном извне Клиент посылает сообщение DHCPINFORM, клиент может запросить специфические конфигурационные параметры путем включения их в опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и вводит его в поле 'xid'. Клиент помещает свой сетевой адрес в поле 'ciaddr'. Клиенту не следует запрашивать параметры времени действия конфигурационного набора. Клиент посылает уникастное сообщение DHCPINFORM DHCP-серверу, если он знает адрес сервера, в противном случае он посылает это сообщение широковещательно. Сообщения DHCPINFORM должны быть направлены 'DHCP-серверу ' через UDP-порт. Раз от любого из серверов получено сообщение DHCPACK с полем 'xid', согласующимся с тем, что содержалось в сообщении клиента DHCPINFORM, клиент инициализирован. Если клиент не получил DHCPACK в пределах разумного временного интервала (60 секунд или 4 попыток, если используется таймауты, предложенные в разделе 4.1), тогда клиент должен выдать сообщение пользователю, уведомляющее его о возникшей проблеме, а затем продолжить сетевую активность, используя разумные значения по умолчанию из приложения A. 4.4.4. Использование широковещательной и уникастной адресации DHCP-клиент широковещательно посылает сообщения DHCPDISCOVER, DHCPREQUEST и DHCPINFORM, если только клиент не знает адреса DHCP-сервера. Клиент посылает сообщения DHCPRELEASE серверу уникастно. Так как клиент отказывается использовать IP-адрес, предоставленный сервером, он посылает сообщения DHCPDECLINE широковещательно. Когда DHCP-клиент знает адрес DHCP-сервера, в состоянии INIT или REBOOTING, клиент может использовать адрес, записанный в DHCPDISCOVER или DHCPREQUEST, а не широковещательный IP-адрес. Клиент может также использовать уникастную адресацию при посылке сообщений DHCPINFORM известному DHCP-серверу. Если клиент не получает отклика на DHCP-сообщение, посланное по IP-адресу известного DHCP-сервера, DHCP-клиент переходит на широковещательную адресацию. 4.4.5. Восстановление и истечение пригодности Клиент поддерживает две временные переменные, T1 и T2, которые специфицируют времена, когда клиент пытается расширить время действия своего сетевого адреса. T1 равно времени, когда клиент попадает в состояние RENEWING и пытается контактировать с сервером, который предоставил клиенту сетевой адрес. T2 равно времени, когда клиент перешел в состояние REBINDING и пытается контактировать с каким-то сервером. T1 должно быть раньше T2, которое в свою очередь, должно быть раньше, чем время, когда истекает период годности конфигурационного набора параметров. Чтобы исключить необходимость синхронизации часов, T1 и T2 выражаются в опциях в относительных единицах [2]. В момент T1 клиент переходит в состояние RENEWING и посылает серверу (уникастно) сообщение DHCPREQUEST с тем, чтобы продлить действие набора конфигурационных параметров. Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент записывает локальное время, когда было послано сообщение DHCPREQUEST. Клиент не должен включать идентификатор сервера в сообщение DHCPREQUEST. Любые сообщения DHCPACK, которые приходят с 'xid', не согласующимся с 'xid' из сообщения клиента DHCPREQUEST, игнорируются. Когда клиент получает от сервера DHCPACK, он вычисляет время истечения пригодности конфигурационного набора параметров (равно сумме времени, когда клиент посылал сообщение DHCPREQUEST и длительности пригодности конфигурационного набора параметров из сообщения DHCPACK). Клиент успешно восстанавливает свой сетевой адрес, возвращается в состояние BOUND и может продолжить свою сетевую активность. Если не приходит никакого DHCPACK до T2, клиент переходит в состояние REBINDING и посылает широковещательно сообщение DHCPREQUEST с целью расширения времени действия конфигурационного набора. Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST. Времена T1 и T2 конфигурируются сервером посредством опций. T1 по умолчанию равно (0.5 * duration_of_lease). T2 по умолчанию равно (0.875 * duration_of_lease). Чтобы исключить синхронизацию восстановления состояния клиентов, времена T1 и T2 должны быть выбраны с некоторым случайным разбросом относительно фиксированных значений. Клиент может решить обновить или продлить время действия конфигурационного набора вплоть до T1. Сервер может решить расширить длительность пригодности конфигурационного набора параметров в соответствии с политикой сетевого администратора. Как в состоянии RENEWING, так и в REBINDING, если клиент не получает отклика на свое сообщение DHCPREQUEST. Клиент должен ждать половину остающегося времени вплоть до T2 (в состоянии RENEWING) и половину остающегося времени действия конфигурационного набора (в состоянии REBINDING), как минимум 60 секунд, прежде чем осуществить повторную отправку сообщения DHCPREQUEST. Если время действия конфигурационного набора иссякло, клиент получает DHCPACK, переходит в состояние INIT, должен остановить всякую сетевую активность и запросить инициализацию параметров. Если клиент получает затем DHCPACK, присваивающее клиенту его предыдущий сетевой адрес, клиенту следует продолжить сетевые операции. Если клиенту дали новый сетевой адрес, он не должен использовать предыдущий и ему следует уведомить локальных пользователей о возникшей проблеме. 4.4.6. Сообщение DHCPRELEASE Если клиент более не нуждается в использовании своего сетевого адреса (например, клиент завершил работу через shutdown), клиент посылает серверу сообщение DHCPRELEASE. Заметим, что корректная работа DHCP не зависит от передачи сообщений DHCPRELEASE. 5. Ссылки
A. Параметры конфигурации ЭВМ IP-layer_parameters,_per_host:_
Link-layer_parameters,_per_interface:_
TCP_parameters,_per_host:_
Key: Опция DHCP для протокола
аутентификации пользователей открытых групп Технический стандарт для клиента вычислительной сети разработан рабочей группой по сетевым вычислениям NCWG (Network Computing Working Group), он определяет схему аутентификации клиента-пользователя в вычислительной сети, которая носит название протокола аутентификации пользователя (UAP). UAP предлагает два уровня аутентификации, базовый и безопасный. Базовая аутентификация использует механизм, определенный в спецификации HTTP 1.1 [3]. Безопасная аутентификация является просто аутентификацией реализованной в рамках сессии SSLv3 [4]. В обоих случаях клиент UAP должен получить IP-адрес и номер порта службы UAP. В зависимости от реализации системы может потребоваться дополнительная информация о проходе. URL [5] представляет прекрасный механизм инкапсуляции этой информации, так как многие серверы UAP реализуются как часть HTTP/SSL-серверов. Большинство клиентов UAP конфигурируются при загрузке через DHCP. Ни одна из существующих опций DHCP [6] не имеет информационных полей, содержащих URL. Опция 72 содержит список IP-адресов WWW-серверов, но она не адекватна задаче, так как нельзя специфицировать номер порта и/или проход. Следовательно, нужна опция, которая содержит список URL. Опция протокола аутентификации пользователя Эта опция специфицирует список URL, каждый из которых указывает на сервер аутентификации пользователя, способный обрабатывать запросы, реализуемые через протокол UAP. Серверы UAP могут воспринимать соединения HTTP 1.1 или SSLv3. Если список содержит URL, который не содержит данных о номере порта, присваивается значение порта по умолчанию (т.e., порт 80 для http и порт 443 для https). Если список включает в себя URL, который не содержит данных о проходе, предполагается проход /uap. На рис. 1 показан формат опции аутентификации пользователя.
Рис. .1. Формат опции аутентификации пользователя
Ссылки
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.12 DNS (структура, обработка запросов, ресурсные записи)
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.14.4 Многоцелевое расширение почты Интернет (MIME)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Стандарт STD 11, RFC 822 определяет протокол представления сообщений, структуру их заголовков. При этом предполагается, что текст сообщения построен исключительно из кодов US-ASCII. Набор документов MIME (Multipurpose Internet Mail Extensions; RFC-2045-49) задает формат сообщений, который предоставляет следующие возможности.
Документ RFC-2045 характеризует различные заголовки, которые служат для описания структуры MIME-сообщений. RFC 2046 определяет общую структуру MIME и исходный набор типов среды. RFC 2047 описывает расширения документа RFC 822, позволяя применение в полях заголовков символьных наборов, отличных US-ASCII. RFC 2048 специфицирует различные ограничения, вводимые IANA, для процедур, сопряженных с MIME. RFC 2049 характеризует критерии соответствия требованиям MIME, содержит примеры допустимых форматов и библиографию. 1. Введение Документ RFC 822, который прослужил без малого 20 лет, регламентировал работу лишь с текстовыми сообщениями (передача аудио- видео- или графических сообщений в нем не рассматривалась). Но даже в случае чисто текстовых документов возникали проблемы при работе с языковыми наборами, требующими символов, которые отсутствуют в US-ASCII. Одним из существенных ограничений традиционной электронной почты, базирующейся на RFC 821-822, является установка предельного размера строки (1000 7-битовых US-ASCII символов). Это вынуждало пользователей конвертировать текст различными методами в последовательность US-ASCII-кодов (например, процедура uuencode или преобразование в коды Base-64). Существенные проблемы возникали при почтовом обмене между узлами, поддерживающими протоколы RFC 822 и X.400. Протокол X.400 [X400] определяет механизм включения нетекстовых материалов в почтовые сообщения. Существующие протоколы согласования работы X.400 и RFC 822 предполагают, что X.400 осуществляет преобразование нетекстовых вставок в формат IA5Text, или такие сообщения просто выбрасываются. Отправитель сообщения часто не знает о возможностях получателя, что может привести к тому, что последний, получив сообщения, попросту не сможет его прочесть. Таким образом, нужен механизм согласования возможностей отправителя и получателя на начальной стадии их взаимодействия до начала передачи тела сообщения. В протоколе MIME регламентируется следующее:
Важно заметить, что основополагающими принципами при создании MIME была совместимость с существующими стандартами и надежность работы. Для тех, кто попытается реализовать протокол MIME, определенный интерес могут представлять документы RFC 1344, RFC 1345 и RFC 1524. Далее все цифровые величины и октеты приводятся в десятичном представлении. Все значения типа среды, субтипы и имена параметров безразличны к регистру их написания. Значения параметров, напротив, зависимы от того строчными или прописными буквами они записаны. Терм CRLF в данном описании относится к последовательности октетов, соответствующих ASCII-символам CR (десятичный код 13) и LF (десятичный код 10), которые обозначают разрыв строки. Терм "символьный набор" используется в MIME для того, чтобы обозначить метод преобразования последовательности октетов в последовательность символов. Заметим, что безусловное и однозначное преобразование в обратном направлении не требуется, то есть не все символы могут быть представлены через данный символьный набор (более чем одна последовательность октетов может соответствовать одной и той же последовательности символов). Это определение имеет целью позволить различные виды символьного кодирования, начиная с простой ASCII-таблицы кончая сложными методами, использующими технику ISO 2022. Термин "символьный набор" был первоначально введен для описания прямых схем преобразования, таких как ASCII и ISO-8859-1, для которых характерна однозначная связь символов и кодовых октетов. Многооктетные кодированные символьные наборы и методики переключения несколько осложнили ситуацию. Термин "сообщение", обозначает сообщение типа RFC 822, передаваемое по сети, или сообщение, инкапсулированное в тело типа "message/rfc822" или "message/partial". Термин "объект" (entity) относится к полям заголовка MIME и содержимому сообщения или его части в случае, если оно составное. Спецификация таких объектов определяется исключительно MIME. Так как содержимое объекта часто называется "тело", имеет смысл говорить о теле объекта. Любой вид поля может быть представлен в заголовке объекта, но только поля, имена которых начинаются с "content-" имеют значение, связанное с протоколом MIME. Выражение "7-битовые данные" относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Октеты с кодом больше чем 127 или равные нулю не допустимы. Октеты CR (десятичный код 13) и LF (десятичный код 10) могут встречаться только в виде последовательности, отмечающей конец строки. Выражение "8-битовые данные " относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Но здесь допустимы октеты с десятичными значениями кодов, превышающими 127 (нулевые коды не допускаются). "Строки" в данном контексте представляют собой последовательности октетов, завершающиеся CRLF. Это согласуется с документами RFC 821 и RFC 822. 2. Поля заголовка MIME MIME определяет ряд новых полей заголовков по сравнению с RFC 822. Они описывают содержимое MIME-объекта. Эти поля заголовков используются в двух контекстах:
Ниже представлено формальное описание этих полей заголовка. entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] ; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения. MIME-part-headers := entity-headers [ fields ] ; Любое поле, не начинающееся с "content-" не может иметь какого-либо значения и может игнорироваться. ; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения. 3. Поле заголовка MIME-Version Так как документ RFC 822 был опубликован в 1982, там имелся только один формат для сообщений, передаваемых по каналам Интернет, и по этой причине не было необходимости декларировать тип такого стандарта. MIME является независимым дополнением документа RFC 822. Хотя протокол MIME строился так, чтобы обеспечить совместимость с RFC 822, бывают обстоятельства, когда почтовому агенту желательно выяснить, составлено ли сообщение с учетом нового стандарта. Поле заголовка "MIME-Version" служит как раз для того, чтобы можно было определить, какому стандарту соответствует тело сообщения. Сообщения, соответствующие MIME обязаны содержать такое поле заголовка со следующим текстом: MIME-Version: 1.0 Присутствие этого поля заголовка означает, что сообщение подготовлено согласно требованиям MIME. Так как существует возможность того, что в будущем формат документов может быть изменен, формальное BNF-представление поля MIME-Version следует записать следующим образом: version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT Таким образом, будущие спецификаторы формата, которые могут заменить версию "1.0", ограничены двумя цифровыми полями, разделенными точкой. Если сообщение получено со значением поля MIME-version, отличным от "1.0", оно может не соответствовать данному описанию. Заметим, что поле заголовка MIME-Version должно располагаться в самом начале сообщения. При составном сообщении не требуется, чтобы каждая из частей начиналась с поля версии. Это необходимо лишь в случае, когда заголовки встроенных сообщений типа "message/rfc822" или "message/partial" объявляют о совместимости со стандартом MIME. Для некоторых приложений согласование версий должно проводиться независимо. Некоторые форматы (такие как application/postscript) имеют внутреннюю систему нумерации версий для каждого типа среды. Там где имеет место такое соглашение, MIME не предпринимает попыток подменить эту систему. Там где такого соглашения нет, тип среды MIME может использовать параметр "version" в поле типа содержимого. При проверке значений MIME-Version любые строки комментария RFC 822 должны игнорироваться. В частности, следующие четыре записи поля MIME-Version эквивалентны. MIME-Version: 1.0 В отсутствии поля MIME-Version, принимающий почтовый агент (следующий стандарту MIME или нет) может опционно интерпретировать сообщения согласно локальным соглашениям. Нельзя быть уверенным, что почтовое сообщение, не согласованное с MIME, является непременно обычным текстом в кодировке ASCII, так как оно может содержать код согласно локальному соглашению (например, результат работы процедуры UUTNCODE или какого-то архиватора). 4. Поле заголовка Content-Type Задачей поля Content-Type является описание информации, содержащейся в теле сообщения. Этого описания должно быть достаточно, чтобы принимающий агент пользователя был способен воспринять и отобразить полученные данные. Значение этого поля называется типом среды. Поле заголовка Content-Type было первым, определенным в документе RFC-1049. В RFC-1049 использовался более простой и менее мощный синтаксис, который, в прочем, вполне согласуется с регламентациями MIME. Поле заголовка Content-Type специфицирует природу данных в теле объекта, сообщая тип среды и идентификаторы субтипа, а также предоставляя вспомогательную информацию, которая может требоваться для определенного типа среды. После типа среды и имен субтипов может следовать набор параметров, который описывается в нотации атрибут = значение. Порядок параметров не имеет значения. Тип среды верхнего уровня используется для декларирования общего типа данных, в то время как субтип определяет специфический формат информации. Таким образом, типа среды "image/xyz" достаточно, чтобы сообщить агенту пользователя, что данные представляют собой изображение, даже если агент пользователя не имеет представления о формате изображения "xyz". Такая информация может использоваться, например, для того чтобы решить, следует ли показывать пользователю исходные данные нераспознанного субтипа. Такая операция разумна для нераспознанного субтипа текста, но бессмысленна для изображения или звука. По этой причине, зарегистрированные субтипы текста, изображения, аудио и видео не должны содержать вложенной информации другого типа. Такой составной формат должен быть представлен с использованием "multipart" или "application" типов. Параметры являются модификаторами субтипа среды и по этой причине не могут существенно влиять на природу содержимого. Набор значимых параметров зависит от типа и субтипа среды. Большинство параметров связано с одним специфическим субтипом. Однако тип среды верхнего уровня может определить параметры, которые применимы к любому субтипу данного типа. Параметры могут быть необходимы для определенных типов и субтипов, могут они быть и опционными. Реализации MIME должны игнорировать любые параметры, если их имена не распознаны. Например, параметр "charset" применим к любому субтипу "текста", в то время как параметр "boundary" необходим для любого субтипа типа среды "multipart". Не существует параметров, применимых для всех типов среды. Исходный набор из семи типов среды верхнего уровня определен в документе RFC 2046. Пять из них являются дискретными типами. Остальные два являются составными типами, чье содержимое требует дополнительной обработки процессорами MIME. Этот набор типов среды верхнего уровня является замкнутым. Предполагается, что необходимые расширения набора могут осуществляться за счет введения субтипов к существующим базовым типам. В будущем, расширение базового набора допустимо лишь при смене стандарта. Если необходим какой-то новый базовый тип среды, его имя должно начинаться с "X-", что указывает на то, что он не является стандартным. 4.1. Синтаксис поля заголовка Content-Type В нотации BNF, значение поля заголовка Content-Type определяется следующим образом:
Заметим, что определение "tspecials" совпадает с определением "specials" в RFC 822 с добавлением трех символов "/", "?" и "=" и удалением "." (точка). Заметим также, что спецификация субтипа является MANDATORY - она не может быть удалена из поля заголовка Content-Type. Не существует субтипов по умолчанию. Тип, субтип и имена параметров не зависят от регистра, в которых они напечатаны. Например, TEXT, Text и TeXt являются эквивалентными типами среды верхнего уровня. Значения же параметров в норме чувствительны к регистру, в котором они напечатаны, но иногда интерпретируются без учета регистра в зависимости от приложения. (Например, границы типа multipart являются чувствительными к регистру, а параметр "access-type" для сообщения message/External-body не чувствителен.) Обратите внимание, что значение строки в кавычках не включает в себя сами кавычки. В полях заголовка в соответствии с RFC 822 допускаются комментарии. Таким образом, две приведенные ниже формы являются эквивалентными. Content-type: text/plain; charset=us-ascii (Plain text) Предполагается, что имена субтипов при их применении не вызовут конфликтов. Так недопустимо, чтобы в различных приложениях "Content-Type: application/foobar" означало различные вещи. Существует два приемлемых механизма определения новых субтипов среды.
4.2. Значения по умолчанию Content-Type Сообщения по умолчанию без MIME-заголовка Content-Type согласно протоколу должны содержать простой текст с символьным набором ASCII, который может быть специфицирован явно. Content-type: text/plain; charset=us-ascii Это значение подразумевается, если не специфицировано поле заголовка Content-Type. Рекомендуется, чтобы это значение по умолчанию использовалось в случае, когда встретилась нераспознанное значение поля заголовка Content-Type. В присутствии поля заголовка MIME-Version и отсутствии поля Content-Type, принимающий агент пользователя может также предположить, что отправитель предлагает простой текст в ASCII-кодировке. Простой ASCII-текст может предполагаться в отсутствии MIME-Version или в присутствии синтаксически некорректного поля заголовка Content-Type, хотя это может и не совпадать с намерениями отправителя. 5. Поле заголовка Content-Transfer-Encoding Многие типы среды, которые могут передаваться посредством электронной почты, представляются в своем естественном формате, таком как 8-битовые символы или двоичные данные. Такие данные не могут быть переданы посредством некоторых транспортных протоколов. Например, RFC 821 (SMTP) ограничивает почтовые сообщения 7-битовым символьным набором ASCII со строками короче 1000 символов, включая строчные разделители CRLF. Таким образом, необходимо определить стандартный механизм кодировки таких данных в 7-битный формат с короткими строками. В MIME для этой цели используется поле заголовка "Content-Transfer-Encoding". Это поле не было определено каким-либо прежним стандартом. 5.1. Синтаксис Content-Transfer-Encoding Значения полей Content-Transfer-Encoding представляют собой лексему, характеризующую тип кодирования, как это описано ниже.
Эти значения не чувствительны к регистру, в котором напечатаны. - Base64, BASE64 и bAsE64 эквивалентны. Тип кодировки 7BIT требует, чтобы тело уже имело 7-битовое представление, пригодное для передачи. Это значение по умолчанию, означает, что в отсутствии поля Transfer-Encoding предполагается "Content-Transfer-Encoding: 7BIT". 5.2. Семантика Content-Transfer-Encodings Лексема Content-Transfer-Encoding предоставляет два вида информации. Она специфицирует, какому виду кодового преобразования подвергнуто тело сообщения и, следовательно, какая процедура декодирования должна использоваться при восстановлении исходного вида сообщения. Преобразовательная часть любого Content-Transfer-Encodings специфицирует явно или неявно алгоритм декодирования, который либо восстановит исходный вид последовательности или обнаружит ошибку. Преобразования Content-Transfer-Encodings для нормальной работы никогда не требует какой-либо дополнительной внешней информации. Преобразование заданной последовательности октетов в другую эквивалентную кодовую последовательность совершенно легально. В настоящее время определены три преобразования: тождественное (никакого преобразования), преобразование в последовательность печатных символов и в последовательность кодов "base64". Значения Content-Transfer-Encoding "7bit", "8bit" и "binary" означают, что никакого преобразования не произведено. Они указывают на тип тела сообщения, и позволяют предполагать, какое кодирование может потребоваться при передаче данных. Кодирование в последовательность печатных символов или в кодовую последовательность base64 предполагает преобразование из произвольного исходного формата в представление "7bit", что позволяет передачу через любые транспортные среды. Всегда должна использоваться корректная метка Content-Transfer-Encoding. Пометка данных, преобразованных программой UUENCODE и содержащих 8-битовые символы, как "7bit" не допустима, такие данные должны помечаться только как "binary". При прочих равных условиях предпочтительным представлением является последовательность печатных символов или кодов base64. Передача почтовых сообщений закодированных программой uuencode описана в документе RFC 1652. Но следует иметь в виду, что ни при каких обстоятельствах Content-Transfer-Encoding "binary" нельзя считать приемлемым для e-mail. Однако когда используется MIME, двоичное тело сообщение может быть помечено как таковое. 5.3. Новое значение Content-Transfer-Encodings Программисты могут, если необходимо, определить частные значения Content-Transfer-Encoding. При этом должны использоваться x-лексемы, которые представляют собой имена с префиксом "X-", что указывает на нестандартный статус, например, "Content-Transfer- Encoding: x-my-new-encoding". Дополнительные стандартизованные значения Content-Transfer-Encoding должны быть специфицированы в официальных документах RFC. В отличие от типов среды и субтипов, формирование новых значений Content- Transfer-Encoding категорически не рекомендуется, так как может привести к полному выходу из строя системы. 4. Реализация и применение Если поле заголовка Content-Transfer-Encoding появляется как часть заголовка сообщения, оно относится ко всему телу сообщения. Если поле заголовка Content-Transfer-Encoding появляется в качестве части заголовка объекта, то зоной его действия будет тело этого объекта. Если объект имеет тип "multipart", то Content-Transfer-Encoding не может иметь значение "7bit", "8bit" или "binary". Следует заметить, что большинство типов среды определены в терминах октетов, а не бит, поэтому описываемые механизмы относятся к кодировке произвольных потоков октетов, а не бит. Если необходимо закодировать битовую последовательность, она должна быть преобразована в последовательность октетов с сетевой последовательностью бит ("big-endian"), в которой более ранние биты становятся старшими битами октетов. Битовые потоки, длина которых не кратна 8, должны быть дополнены нулями. Механизмы кодировки, определенные здесь, осуществляют преобразование любых данных в ASCII. Таким образом, предположим, например, что объект имеет следующие поля заголовка: Content-Type: text/plain; charset=ISO-8859-1 Это должно интерпретироваться так, что тело имеет кодировку base64, а исходные данные имели представление в ISO-8859-1. Определенные значения Content-Transfer-Encoding могут использоваться только с определенными типами среды. В частности, категорически запрещено использовать любую кодировку отличную от "7bit", "8bit" или "binary" с любым составным типом среды, т.e. включающим и другие поля Content-Type. В настоящее время допустимы составные типы среды "multipart" и "message". Все кодировки, допустимые для тел типа multipart или message должны использоваться на самом внутреннем уровне. Следует также заметить, что по определению, если составной объект имеет значение transfer-encoding равное "7bit", но один из составляющих объектов имеет менее регламентирующее значение, например, "8bit", тогда либо внешняя метка "7bit" является ошибкой, или внутренняя метка "8bit" устанавливает слишком высокое требование к транспортной системе (следовало проставить 7bit). Хотя запрет использования content-transfer-encodings для составного тела может показаться чрезмерно регламентирующим, следует избегать вложенных кодирований, в которых данные подвергаются последовательно обработке несколькими алгоритмами. Вложенные кодирования заметно повышают сложность агентов пользователя. Помимо очевидных проблем эффективности при множественном кодировании они могут затемнить базовую структуру сообщения. В частности они могут подразумевать, что необходимо несколько операций декодирования, чтобы определить, какие типы тел содержит сообщение. Запрет вложенных кодировок может осложнить работу некоторых почтовых шлюзов, но это представляется меньшей бедой, чем осложнение жизни агентов пользователя при вложенном кодировании. Любой объект с нераспознанным значением Content-Transfer-Encoding должен рассматриваться, как если бы он имел код Content-type "application/octet-stream", вне зависимости оттого, что утверждается полем заголовка Content-Type. Может показаться, что Content-Transfer-Encoding может быть выяснено из характеристик среды, для которой нужно осуществить кодирование или, по крайней мере, что определенное Content-Transfer-Encodings может быть предназначено для использования с определенными типами среды. Есть несколько причин, почему это не так. Во-первых, существующие различные типы транспорта, используемые для почты, некоторые кодирования могут годиться для определенных комбинаций типов среды и транспорта, но быть непригодными для других. Например, при 8-битовой передаче, при определенном символьном наборе для текста не потребуется никакого кодирования, в то время как такое кодирование очевидно необходимо для 7-битового SMTP. Во-вторых, определенные типы среды могут требовать различного транспортного кодирования при разных обстоятельствах. Например, многие PostScript-тела могут целиком состоять из коротких строк 7-битовых кодов, и, следовательно, совсем не требуют кодирования. Другие тела PostScript (в особенности те, что используют механизм двоичного кодирования уровня 2 PostScript) могут быть представлены с использованием двоичного транспортного кодирования. Наконец, так как поле Content-Type ориентировано на то, чтобы предоставлять открытые механизмы спецификации, строгие ассоциации типов среды и кодирования эффективно соединяют спецификацию прикладного протокола с определенным транспортом нижнего уровня. Это нежелательно, так как разработчики типа среды не должны заботиться обо всех видах транспорта и их особенностях. 5.5. Транслирующее кодирование Кодирование с использованием закавыченных строк печатных символов и кодов base64 устроено так, чтобы позволить взаимные преобразования. Единственная проблема, которая здесь возникает, это обработка принудительных разрывов строк для закавыченных последовательностей печатных символов. При преобразовании закавыченных строк в коды base64 принудительные разрывы строк отображаются последовательностями CRLF. Аналогично, последовательность CRLF в канонической форме данных, полученной после декодирования из base64, должна преобразоваться в принудительный разрыв строки в случае представления текста в виде закавыченной строки печатных символов. Каноническая модель кодирования представлена в документе RFC 2049. 5.6. Транспортное кодирование содержимого Quoted-Printable Кодирование Quoted-Printable имеет целью представление данных, состоящих по большей части из октетов, которые соответствуют печатным символам ASCII-набора. Оно преобразует данные таким образом, что результирующие октеты не будут видоизменены при транспортировке почты. Если преобразуемые данные представляют собой ASCII-текст, то после кодирования они сохранят читабельность. Тело, которое целиком состоит из ASCII-кодов, может быть также представлено в виде закавыченной строки печатных символов. При этом сохраняется целостность текста в процессе прохождении через шлюз, который осуществляет трансляцию символов и/или обработку разрывов строк. При этом кодировании октеты должны определяться согласно изложенным ниже правилам:
Так пусть имеется следующий текст, который надо преобразовать: Now's the time for all folk to come to the aid of their country. Это может быть представлено следующим образом с помощью закавыченных строк печатных символов: Now's the time = Это предоставляет механизм, с помощью которого длинные строки преобразуются таким образом, как они должны быть запомнены агентом пользователя. Ограничение в 76 символов не учитывает завершающие строку CRLF, но включают все прочие символы, включая знаки равенства. Так как символ дефис ("-") может отображаться в закавыченных строках самим собой, нужно следить за тем, чтобы при инкапсуляции закодированного так фрагмента, в одном или более составных объектов пограничные разделители не появились в закодированном теле. Хорошей стратегией является выбор в качестве границы последовательности символов "=_", которая не может встретиться в закавыченной строке печатных символов. Преобразование в закавыченные строки печатных символов представляет собой компромисс между читабельностью и надежностью при транспортировке. Тела, закодированные с помощью закавыченных строк печатных символов, пропускаются без проблем большинством почтовых шлюзов. Проблемы могут возникать только со шлюзами, осуществляющими трансляцию в коды EBCDIC. Кодирование с помощью base64 обеспечивает более высокий уровень надежности. Методом получения разумно высокой надежности транспортировки через шлюзы EBCDIC является представление символов !"#$@[\]^`{|}~ согласно правилу #1. Так как закавыченные последовательности печатных символов предполагаются ориентированными на строчное представление, разрывы между строками могут видоизменяться в процессе транспортировки. Если изменение кодов разрыва строк может вызвать искажения или сбои, следует использовать кодирование с помощью base64. Несколько видов субстрок не могут генерироваться согласно правилам кодирования для представления с помощью закавыченных последовательностей печатаемых символов. Ниже перечисляются эти нелегальные субстроки и предлагаются способы их кодирования.
Если двоичные данные закодированы в виде закавыченных последовательностей печатных символов, следует позаботиться о том, чтобы символы CR и LF были представлены в виде "=0D" и "=0A", соответственно. В частности, последовательность CRLF в двоичных данных должна кодироваться как "=0D=0A". В противном случае, если CRLF была бы представлена как "жесткий" разрыв строки, она может декодироваться некорректно на платформах с различными способами обработки разрывов строки. С формальной точки зрения, закавыченные последовательности печатных символов подчиняются следующей грамматике.
Добавление LWSP между элементами, показанное в данном BNF-представлении, не допустимо, так как данное BNF не специфицирует структурированных полей заголовка. 5.7. Транспортное кодирование Base64 (Content-Transfer-Encoding) Транспортное кодирование на основе Base64 создано для представления произвольной последовательности октетов в форме, которая не обязательно должна быть приемлемой для прочтения человеком. Алгоритмы кодирования и декодирования просты. Это кодирование сходно с тем что используется в почтовом приложении PEM (Privacy Enhanced Mail), как это определено в RFC-1421. Здесь используется 65-символьный субнабор ASCII, для каждого печатного символа выделено по 6 бит. Дополнительный 65-ый символ "=", используется для обозначения специальных функций обработки. Этот субнабор имеет важное свойство, которое заключается в том, что он представляется идентично во всех версиях ISO 646, включая US-ASCII, и все символы субнабора имеют аналоги во всех версиях EBCDIC. Другие популярные кодировки, такие как применение утилиты uuencode, Macintosh binhex 4.0 [RFC-1741] и base85, специфицированная как часть уровня 2 PostScript, имеют отличающиеся свойства и, следовательно, не выполняют условий переносимости, которым должна удовлетворять двоичное транспортное кодирование электронной почты. При кодировании входные 24-битовые группы преобразуют в 4 символа. Входная группа формируется из трех 8-битовых кодов и обрабатывается слева направо. Эти 24 бита рассматриваются в дальнейшем как 4 6-битовые группы, каждая из которых транслируется в одно число из алфавита base64. Когда кодируется битовый поток с использованием base64, предполагается, что старший бит передается первым. То есть, первый бит потока станет старшим битом первого 8-битового байта, а 8-ой бит станет его последним битом. Каждая 6-битовая группа используется как индекс массива из 64 печатных символов. Символ, на который указывает индекс, берется из массива и помещается в выходной поток. Эти символы представлены в таблице .1., из их перечня исключены коды, имеющие особое значение для протокола SMTP (например, ".", CR, LF), а также разграничитель секций составного сообщения "-" (RFC-2046). Таблица .1. Коды Base64
Закодированный выходной поток должен иметь формат последовательности из одной или более строк длиной не более 76 символов каждая. Все разрывы строк или другие символы, не содержащиеся в таблице .1. должны игнорироваться декодирующим программным обеспечением. В данных, представленных в кодах base64, символы отличные от тех, что представлены в таблице .1., разрывы строк и другие пробелы обычно указывает на ошибку передачи, которая вызовет предупреждение или даже выбрасывание сообщения. Если число бит в группе меньше 24, используется специальная обработка. Неполная битовая группа дополняется нулями справа до 24. Заполнение в конце информационной группы осуществляется с использованием символа "=". Так как последовательность кодов base64 представляет собой поток октетов, возможны следующие случаи:
Так как "=" используется для дополнения, его наличие указывает на то, что достигнут конец массива данных. Такая уверенность не возможна, когда число переданных октетов кратно трем и нет ни одного символа "=". Любые символы, не входящие в алфавит base64-должны игнорироваться. Следует позаботиться о том, чтобы использовались корректные октеты в качестве разделителей строк при работе с base64. В частности, разрывы строк должны быть преобразованы в последовательности CRLF до выполнения кодирования base64. 6. Поле заголовка Content-ID При создании агента пользователя высокого уровня, может быть желательно, допустить одному телу ссылаться на другое. Тела могут быть помечены с помощью поля заголовка "Content-ID", которое синтаксически идентично полю "Message-ID": id := "Content-ID" ":" msg-id Подобно значениям Message-ID, значения Content-ID должны генерироваться уникальными. Значение Content-ID может использоваться для идентификации MIME-объектов в нескольких контекстах, в частности для кэширования данных с доступом через механизм message/external-body. Хотя заголовок Content-ID является обычно опционным, его использование является обязательным в приложениях, которые генерируют данные опционного типа среды MIME "message/external-body". По этой причине каждый объект message/external-body должен иметь поле Content-ID, для того чтобы разрешить кэширование таких данных. 7. Поле заголовка Content-Description Часто оказывается желательным установить соответствие между описательной информацией и данным телом. Например, может быть полезным пометить тело типа "image" как "изображение старта космического корабля". Такой текст может быть помещен в поле заголовка Content-Description. Это поле всегда является опционным. description := "Content-Description" ":" *text Предполагается, что описание дается с использованием символьного набора US-ASCII, хотя механизм, специфицированный в RFC 2047, может быть использован и для значений Content-Description, не соответствующих стандарту US-ASCII. 8. Дополнительные поля заголовка MIME Будущие документы могут содержать дополнительные поля заголовков MIME для различных целей. Любое новое поле заголовка, которое описывает содержимое сообщения должно начинаться со строки "Content-", для того чтобы такие поля можно было с гарантией отличить от обычных полей заголовков сообщения, следующих стандарту RFC-822. MIME-extension-field := <Любое поле заголовка RFC-822, которое начинается со строки "Content-"> Используя поля заголовка MIME-Version, Content-Type и Content-Transfer-Encoding, можно подключить стандартным образом произвольные типы данных и добиться совместимости с требованиями документа RFC-822. Никакие ограничения введенные документами RFC-821 или RFC-822 не нарушаются, были приняты меры, чтобы исключить проблемы, связанные с дополнительными ограничениями из-за свойств некоторых механизмов пересылки почты по Интернет (см. RFC-2049). Приложение A -- обзор грамматики Это приложение содержит грамматические описания всех конструкций, содержащихся в протоколе MIME.
II. Типы среды 1. Введение Поле Content-Type используется для спецификации природы информации в теле MIME-объекта путем присвоения идентификаторов типа и субтипа среды и предоставления дополнительной информации, которая может быть необходима для данной разновидности среды. За именами типа и субтипа среды в поле следует набор параметров, заданных в нотации атрибут/значение. Порядок следования параметров не существенен. Тип среды верхнего уровня используется для декларации общего типа данных, в то время как субтип определяет специфический формат данного типа информации. Таким образом, тип среды "image/xyz" говорит агенту пользователя, что данные характеризуют изображение и имеют формат "xyz". Такая информация может использоваться, для того чтобы решить, отображать ли пользователю исходные данные нераспознанного субтипа. Такие действия могут быть разумными для нераспознанного фрагмента субтипа "text", но не для субтипов "image" или "audio". По этой причине, зарегистрированные субтипы "text", "image", "audio" и "video" не должны содержать встроенных фрагментов другого типа. Такие составные форматы должны использовать типы "multipart" или "application". Параметры являются модификаторами субтипа среды, и как таковые не оказывают никакого влияния на содержимое. Набор параметров зависит от типа и субтипа среды. Большинство параметров связано с одним специфическим субтипом. Однако определенный тип среды высшего уровня может определить параметры, которые приложимы к любому субтипу данного типа. Параметры могут быть обязательными или опционными. MIME игнорирует любые параметры, имена которых нераспознаны. Поле заголовка Content-Type и механизм типа среды спроектированы так, чтобы сохранить масштабируемость, обеспечивая постепенный рост со временем числа пар тип/субтип и сопряженных с ними параметров. Транспортное кодирование MIME, а также типы доступа "message/external-body" со временем могут обрести новые значения. Для того чтобы гарантировать то, что такие значения разработаны и специфицированы корректно, в MIME предусмотрен процесс регистрации, который использует IANA (Internet Assigned Numbers Authority) в качестве главного органа контролирующего данный процесс (см. RFC 2048). В данном разделе описаны семь стандартизованных типов среды верхнего уровня. 2. Определение типов среды верхнего уровня Определение типа среды верхнего уровня состоит из:
3. Обзор базовых типов среды верхнего уровня Имеется пять дискретных типов среды высокого уровня.
Существует два составных типа среды высшего уровня.
4. Дискретные значения типа среды Пять из семи базовых значений типа среды относятся к дискретным телам. Содержимое этих типов должно обрабатываться с использование механизмов за пределами MIME, они непрозрачны для MIME-процессоров. 4.1. Тип среды Text Тип среды "text" предназначен для посылки материала, который имеет принципиально текстуальную форму. Параметр "charset" можно использовать для указания символьного набора тела субтипов "text", включая субтип "text/plain", который является общим субтипом для чистого текста. Чистый текст не содержит форматирующих команд, спецификаций атрибутов шрифтов, инструкций обработки, директив интерпретации или разметки. Чистый текст представляет собой последовательность символов, которая может содержать разрывы строк или страниц. Помимо чистого текста существует много форматов, называемых "богатый" текст ("rich text"). Интересной характеристикой многих таких представлений является то, что они читабельны даже без программы, которая его интерпретирует. Полезно затем отличать их на верхнем уровне от таких нечитабельных данных как изображения, звук или текст, представленный в нечитаемом виде. В отсутствии подходящей интерпретирующей программы разумно показать субтипы "text" пользователю, в то время как это неразумно для большей части нетекстовых данных. Такие форматированные текстовые данные должны представляться с помощью субтипов "text". 4.1.1. Представление разрывов строк Каноническая форма любого субтипа MIME "text" должна всегда оформлять разрыв строки с помощью последовательности CRLF. Аналогично, любое появление CRLF в тексте MIME должно означать разрыв строки. Использование CR и LF по отдельности вне обозначения разрыва строки запрещено. Это правило работает вне зависимости от используемого символьного набора. Правильная интерпретация разрывов строк при отображении текста зависит от типа среды. Следует учитывать, что одно и то же оформление разрывов строк при отображении "text/plain" может восприниматься корректно, в то время как для других субтипов "text", например, "text/enriched" [RFC-1896] аналогичные разрывы строк будут восприниматься как неверные. Нет необходимости в добавлении каких-либо разрывов строк при отображении "text/plain", в то время как отображение "text/enriched" требует введения соответствующего оформления разрывов строк. Некоторые протоколы определяют максимальную длину строки. Например, SMTP [RFC-821] допускает максимум 998 октетов перед последовательностью CRLF. Для того чтобы реализовать транспортировку посредством такого протокола, данные, содержащие слишком длинные сегменты без CRLF, должны быть закодированы с применением соответствующего content-transfer-encoding. 4.1.2. Параметр Charset Критическим параметром, который может быть специфицирован в поле Content-Type для данных "text/plain", является символьный набор. Он специфицируется параметром "charset", например, как: Content-type: text/plain; charset=iso-8859-1 В отличие от других значений параметров, значения параметра символьный набор не чувствительны к регистру, в котором написано его имя. Значением по умолчанию параметра символьный набор равно US-ASCII. Для других субтипов "text", семантика параметра "charset" должна быть определена аналогично параметрам, заданным для "text/plain", т.e., тело состоит полностью из символов данного набора. В частности, авторы будущих определений субтипов "text" должны обратить особое внимание мультиоктетным символьным наборам. Параметр charset для субтипов "text" дает имя символьному набору, как это определено в RFC 2045. Заметим, что специфицированный символьный набор включает в себя 8-битовые коды и эти символы используются в теле, поле заголовка Content-Transfer-Encoding и для передачи данных с помощью транспортных протоколов (например, SMTP) необходима соответствующая кодировка, такая как [RFC-821]. Значение символьного набора по умолчанию, равное US-ASCII, являлось причиной многих неурядиц в прошлом. Для того чтобы исключить какие-либо неопределенности в будущем, настоятельно рекомендуется новым агентам пользователя задавать символьный набор в явном виде в качестве параметра типа среды в поле заголовка Content-Type. "US-ASCII" не указывает на произвольный 7-битовый символьный набор, а говорит о том, что все октеты в теле должны интерпретироваться как символы US-ASCII. Национальные и ориентированные на приложения версии ISO 646 [ISO-646] обычно не идентичны US-ASCII, и их непосредственное применение в электронной почте может вызвать проблемы. Имя символьного набора "US-ASCII" относится к кодам, заданным в документе ANSI X3.4-1986 [US- ASCII]. Полный набор символов US-ASCII представлен в ANSI X3.4-1986. Заметим, что управляющие символы, включая DEL (0-31, 127) не имеют определенного значения, исключение составляет комбинация CRLF (US-ASCII значения 13 и 10) обозначающая разрыв строки. Два символа имеют широко используемые функции, это: FF (12) - продолжить последующий текст с начала новой страницы, и TAB или HT (9) часто (хотя и не всегда) означает "переместить курсор в следующую колонку. Колонки нумеруются, начиная с нуля и их позиции кратны 8. Помимо этих случаев любые управляющие символы или DEL в теле объекта могут появиться при следующих условиях.
Определены следующие значения charset:
Символы с кодами в диапазоне 128-159 не имеют стандартизованных значений в рамках ISO-8859-X. Символы с кодами меньше 128 в ISO-8859-X имеют те же значения, что и в US-ASCII. Значения символьных наборов "ISO-8859-6" и "ISO-8859-8" специфицируют применение визуального метода [RFC-1556]. Все эти символьные наборы используются как чисто 7-битовые или 8-битовые без модификаций связанных Никакие символьные наборы, отличные от определенных выше, не могут использоваться в электронной почте без публикации и формальной регистрации в IANA. Допустимы частные соглашения, в этом случае имя символьного набора должно начинаться с "X-". Потребителям не рекомендуется определять новые символьные наборы, если это не диктуется крайней необходимостью. Параметр "charset" был первоначально определен для текстовых данных. Однако возможно его использование и для не текстовой информации, обычно это делается для синтаксической совместимости. Если широко используемый символьный набор А является подмножеством другого символьного набора Б, а тело содержит только символы из набора А, он должен быть помечен как А. 4.1.3. Субтип Subtype Простейшим и наиболее важным субтипом "text" является "plain". Он указывает, что текст не содержит форматирующих команд или директив. Чистый текст может отображаться непосредственно без какой-либо обработки. По умолчанию для электронной почты предполагается тип среды "text/plain; charset=us-ascii". 4.1.4. Не распознанные субтипы Не распознанные субтипы "text" должны обрабатываться как чистый текст ("plain"), поскольку реализация MIME знает, как работать с данным символьным набором. Не распознанные субтипы, которые также специфицируют нераспознаваемый символьный набор, должны обрабатываться как "application/octet- stream". 4.2. Тип среды Image Тип среды "image" указывает, что тело содержит изображение. Субтип называет имя специфического формата изображения. Эти имена не чувствительны к регистру. Исходным субтипом является "jpeg", который использует кодировку JFIF для формата JPEG [JPEG]. Не распознанные субтипы "image" должны обрабатываться как "application/octet-stream". 4.3. Тип среды Audio Исходный субтип "basic" специфицирован, для того чтобы удовлетворить требованиям, которые соответствуют самому нижнему в иерархии аудио-форматов. Предполагается, что форматы для более высококачественного воспроизведения и/или низко полосной передачи будут определены позднее. Содержимое субтипа "audio/basic" представляет собой моноканальное звуковое кодирование, использующее 8-битоый ISDN-стандарт с m-функцией преобразования [PCM] с частотой стробирования 8000 Hz. Не распознанные субтипы "audio" должны обрабатываться как "application/octet-stream". 4.4. Тип среды Type Тип среды "video" указывает, что тело содержит движущееся изображение, возможно цветное и в сопровождении звука. Термин 'video' используется в самом общем значении, и не подразумевает какого-то конкретного формата. Субтип "mpeg" относится к видео закодированного согласно стандарту MPEG [MPEG]. Не распознанные субтипы "video" должны обрабатываться как "application/octet-stream". 4.5. Тип среды Application Тип среды "application" следует использовать для дискретных данных, которые не могут быть отнесены ни к какой другой категории, в частности для данных, которые должны быть обработаны какой-то прикладной программой. Это информация, которая должна обрабатываться приложением до того как она станет доступной для просмотра пользователем. К предполагаемым применениям типа среды "application" относится файловый обмен, электронные таблицы, диспетчерские системы, базирующиеся на электронной почте. Такие приложения могут быть определены как субтипы типа среды "application". В данном документе определены два субтипа: octet-stream и PostScript. 4.5.1. Субтип Octet-Stream (поток октетов) Субтип "octet-stream" используется для индикации того, что тело содержит произвольные двоичные данные. В настоящее время определены следующие параметры:
Оба эти параметра являются опционными. 4.5.2. Субтип PostScript Тип среды "application/postscript" указывает на программу PostScript. В настоящее время допускается два варианта языка PostScript. Исходный вариант уровня 1 описан в [POSTSCRIPT], а более новый вариант уровня 2 рассмотрен в [POSTSCRIPT2]. Описания языка PostScript предоставляет возможности внутренней пометки специфических возможностей данного приложения. Эта пометка, называемая DSC (document structuring conventions) PostScript, предоставляет существенно больше информации, чем уровень языка. Использование DSC рекомендуется даже тогда, когда это непосредственно не требуется, так как обеспечивает более широкую совместимость. Документы, которые недостаточно структурированы, не могут быть проверены с целью выяснения того, могут ли они работать в данной среде. Работа универсальных интерпретаторов PostScript представляет серьезную угрозу безопасности, разработчикам не рекомендуется просто посылать тела PostScript имеющимся ("off-the-shelf") интерпретаторам. В то время как посылка PostScript-файла на принтер обычно безопасна, программисты должны рассмотреть все возможные последствия, прежде чем ввести интерактивное отображение тел типа PostScript на их читающих средствах MIME. Ниже перечислены возможные проблемы, связанные с транспортировкой объектов PostScript.
4.5.3. Другие субтипы приложений Ожидается, что в будущем будут определены многие другие субтипы "application". Реализации MIME должны уметь обрабатывать нераспознанные субтипы как "application/octet-stream". 5. Значения типа среды Composite (составной) Оставшиеся два из семи исходных значений Content-Type относятся к составным объектам. Составные объекты обрабатываются с использованием механизмов MIME -- процессор MIME обрабатывает тело объекта непосредственно. 5.1. Тип среды Multipart В случае составных объектов, когда один или более различных наборов данных объединяется в одном теле, в заголовке объекта должно присутствовать поле типа среды "multipart". Тело должно тогда содержать одну или более частей, каждая из которых начинается с разделительной строки. За разделительной строкой следует заголовок, пустая строка и тело объекта. Таким образом, часть тела по своему синтаксису аналогична сообщению в RFC-822, но имеет другое назначение. Часть тела является объектом и, следовательно, не должна интерпретироваться как сообщение RFC-822. Начнем с того, что части тела должны иметь заголовки. Допустимы части тела, которые начинаются с пустой строки. В таком случае отсутствие заголовка Content-Type обычно указывает, что соответствующее тело имеет тип содержимого "text/plain; charset=US-ASCII". Единственные поля заголовка, которые определяют назначение частей тела, имеют имена, начинающиеся с "Content-". Все другие поля в заголовке части тела могут игнорироваться. Для экспериментальных или частных назначений могут создаваться поля, с именами, начинающимися с "X-". Информация, содержащаяся в этих полях может теряться в некоторых шлюзах. Различие между сообщением RFC-822 и частью тела не велико, но существенно. Шлюз между Интернет и почтовым сервером X.400, например, должен быть способен различать части тела, содержащие изображение и инкапсулированное сообщение, тело которого представляет собой JPEG-образ. Для того чтобы представить последнее, часть тела должна иметь "Content-Type: message/rfc822", и ее тело после пустой строки должно представлять собой инкапсулированное сообщение со своим собственным полем заголовка "Content-Type: image/jpeg". Применение подобного синтаксиса способствует преобразованию сообщений в части тела и обратно. Как было заявлено ранее, каждая часть тела начинается со строки-разграничителя. Разграничитель не должен появляться внутри любой инкапсулированной части, или в качестве префикса любой строки. Это подразумевает, что генерирующий агент способен специфицировать уникальное значение пограничного параметра, которое не содержит в качестве префикса значения разграничительного параметра вкладываемой части. Все существующие и будущие субтипы типа "multipart" должны использовать идентичный синтаксис. Субтипы могут отличаться по своей семантике и могут вводить дополнительные ограничения на синтаксис, но должны согласовываться с базовым синтаксисом типа "multipart". Это требование гарантирует, что все агенты пользователя будут, по крайней мере, способны распознать и разделить части составного объекта, даже если они относятся к нераспознанным субтипам. Как задано в определении поля Content-Transfer-Encoding [RFC-2045], никакие кодировки кроме "7bit", "8bit" или "binary" не разрешены для объектов типа "multipart". Граничные разделители и поля заголовков "multipart" всегда представляются как 7-битовые коды US-ASCII, а данные внутри частей тела могут быть закодированы по-разному и иметь свои поля Content-Transfer-Encoding для каждой из частей. 5.1.1. Общий синтаксис Поле Content-Type для составных объектов требует одного параметра - "boundary". Строка-разделитель определяется как строка, содержащая два символа дефис ("-", десятичный код 45), за которыми следует значение пограничного параметра из поля заголовка Content-Type, опционный строчный пробел и заключительные CRLF. Символы дефис служат для некоторой совместимости с ранним методом (RFC-934) инкапсуляции сообщений, и для облегчения поиска границ для некоторых приложений. Однако следует заметить, что составные сообщения не вполне совместимы с инкапсуляцией, описанной в RFC-934. В частности, они не подчиняются RFC-934 регламентации использования кавычек для вложенных строк, которые начинаются с дефиса. Этот механизм был выбран помимо RFC-934, потому что при данной схеме происходит удлинение строк для каждого уровня закавычивания. Возрастание длины строк, а также то, что некоторые реализации SMTP осуществляют разрыв строк, делают механизм RFC-934 неприменимым для составных сообщений при большой глубине вложений. Грамматика для параметров поля Content-type такова, что в строке Content-type часто необходимо помещать пограничный параметр в кавычки. Это необходимо не всегда, но никогда не повредит. Программисты должны тщательно изучить грамматику, для того чтобы избежать генерации некорректных полей Content-type. Таким образом, типичное поле заголовка "multipart" Content-Type может выглядеть как: Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p Это значение Content-Type указывает, что содержимое состоит из одной или более частей со структурой, которая синтаксически идентична сообщению RFC-822, за исключением того, что область заголовка может быть совершенно пустой, а каждая из частей начинается со строки --gc0pJq0M:08jU534c0p Пограничный разделитель должен размещаться в начале строки, т.e., следовать за CRLF, а начальный CRLF рассматривается объединенным со строкой пограничного разделителя, а не частью предшествующей секции. За границей может следовать нуль или более символов строчного пробела (HT, SP). Далее следует еще один CRLF и поля заголовка следующей части, или два CRLF, что означает отсутствие полей заголовка следующей части. Если поле Content-Type отсутствует, предполагается объект типа "message/rfc822" в сообщении "multipart/digest", в противном случае "text/plain". Граничные разделители не должны появляться внутри инкапсулированного материала и не должны быть длиннее 70 символов, не считая двух начальных символов дефис. Строка пограничного разделителя, следующая за последней частью тела, является уникальной и указывает, что далее не следует более никаких частей тела. Такая разделительная строка идентична предшествующим с добавлением двух символов дефис после значения граничного параметра. --gc0pJq0M:08jU534c0p-- Сравнение пограничной строки должно сопоставлять значение пограничного параметра с началом каждой строки-кандидата. Полного совпадения всей строки-кандидата не требуется, достаточно наличия разграничителя, следующего за CRLF. Имеется место для дополнительной информации перед пограничным разделителем и после оконечного разграничителя. Эти области следует в норме оставлять пустыми, а программные реализации должны игнорировать размещенную там информацию. Некоторые реализации используют эти "ниши" для пересылки сообщений принимающим программам. Пограничный параметр в выше приведенном примере может быть результатом работы алгоритма, специально созданного для генерации кодов, которые с крайне малой вероятностью могут встретиться в инкапсулируемых данных. Другой алгоритм может выдать более "читаемый" код пограничного разделителя, что может потребовать предварительного просмотра инкапсулируемых данных. Простейшей строкой пограничного разделителя может служить "---", а закрывающим разделителем - "-----". Ниже представлен простой пример составного сообщения, имеющего две части, каждая из которых содержит чистый текст, введенный явно и неявно: From: Nathaniel Borenstein Это преамбула. Она будет проигнорирована, но, тем не менее, это удобное место, чтобы отправитель мог поместить сообщение для принимающей стороны, которая не поддерживает MIME.
Использование типа среды "multipart" в части тела в пределах другого составного объекта вполне допустимо. В таких случаях следует позаботиться о том, чтобы каждый из последовательно вложенных объектов использовал свой уникальный пограничный разделитель. Применение типа среды "multipart" при наличии только одной части тела может быть полезным в определенном контексте и вполне допустимо. Практика показала, что тип "multipart" с единственной составной частью полезен для посылки сообщений с нетекстовым типом среды. Он имеет возможность формирования преамбулы, как места, где можно поместить инструкции по декодированию. Кроме того, многие шлюзы SMTP перемещают или удаляют заголовки MIME, и хороший MIME-декодер таким путем может получить необходимую информацию даже в отсутствие заголовка Content-Type и корректно декодировать сообщение. Единственным обязательным глобальным параметром для типа среды "multipart" является граничный параметр, который состоит из 1 - 70 кодов из символьного набора, который надежен по отношению преобразований, осуществляемых почтовыми шлюзами. Значение параметра не должно завершаться пробелом. Формально это записывается в BNF-представлении следующим образом. boundary := 0*69 Вообще тело объекта "multipart" может быть специфицировано как: dash-boundary := "--" boundary
encapsulation := delimiter transport-padding CRLF body-part Введение пробелов (HT, SP) и комментариев RFC 822 между элементами, показанными выше, не допустимо, так как эти BNF не специфицируют структурированное поле заголовка. В определенных транспортных зонах регламентации RFC 822, такие как ограничение применения каких-либо символов, помимо печатных кодов US-ASCII могут не действовать. Ослабление этих ограничений может рассматриваться как локальное расширение определения тел, например, чтобы включить октеты вне набора US-ASCII, постольку, поскольку эти расширения поддерживаются системой передачи и соответствующим образом документированы в поле заголовка Content-Transfer-Encoding. Однако заголовки ни в коем случае не могут содержать чего-либо помимо кодов US-ASCII. 5.1.2. Обработка вложенных и составных сообщений Субтип "message/rfc822" не имеет других условий завершения кроме окончания массива данных. Аналогично, некорректно укороченный составной объект не будет иметь завершающего разделителя, что может вызвать нарушение работы почтовой системы. Существенно, чтобы такие объекты обрабатывались корректно, когда они сами вложены в другие составные структуры. Реализации MIME должны уметь распознавать граничные маркеры на любом уровне вложения. 5.1.3. Субтип Mixed Субтип "mixed" типа "multipart" предназначен для использования в условиях, когда части тела независимы и должны объединяться в определенном порядке. Любые субтипы "multipart", которые не распознаны программой, должны восприниматься как субтип "mixed". 5.1.4. Субтип Alternative Тип "multipart/alternative" синтаксически идентичен "multipart/mixed", но имеет иную семантику. В частности, каждая часть тела является альтернативой одной и той же информации. Системы должны распознавать, что содержимое различных частей взаимозаменяемы. Системы должны выбрать наилучший тип на основе локального окружения и в некоторых случаях с использованием диалога с пользователем. Как и для "multipart/mixed", порядок частей тела является существенным. В этом случае, альтернативы появляются в порядке возрастания правдоподобия оригинальному содержимому. Вообще наилучшим выбором является последняя часть типа, поддерживаемая локальной средой приемной системы.. "Multipart/alternative" может использоваться, например, для посылки сообщения в любом формате таким образом, чтобы его было легко отобразить: From: Nathaniel Borenstein --boundary42 --boundary42 В этом примере пользователи, чья почтовая система может работать с форматом "application/x-whatever", увидят только причудливую версию сообщения, в то время как другие пользователи увидят версию с обогащенным или чистым текстом, в зависимости от возможностей их системы. Вообще, агенты пользователя, которые формируют объекты "multipart/alternative" должны размещать части тела в порядке их предпочтения, то есть, предпочтительный формат следует последним. Посылающий агент пользователя должен поместить простейший формат текста первым, а обогащенный - последним. Принимающие агенты должны воспринять самый последний формат, который они способны отобразить. В случае, когда одной из альтернатив является тип "multipart", который содержит нераспознанные составные части, агент пользователя может отобразить эту альтернативу, более раннюю или даже обе версии сообщения. Возможен вариант, когда агент пользователя способен распознать и отобразить разные форматы, он может предложить окончательный выбор самому пользователю. Это имеет смысл, например, если сообщение включает графическую и текстовую версии сообщения. Агент пользователя не должен автоматически отображать все версии, какие он воспринял, он должен отобразить последнюю, или предоставить выбор оператору. Каждая часть объекта "multipart/alternative" представляет одну и ту же информацию, версии не необязательно тождественны. Например, информация теряется, когда осуществляется трансляция ODA в PostScript или в чистый текст. Рекомендуется, чтобы каждая часть имела свое значение Content-ID в тех случаях, когда содержимое частей неэквивалентно. Например, там, где несколько частей типа "message/external-body" специфицируют способы доступа к идентичной информации, следует использовать одни и те же значения поля Content-ID. Возможен вариант, когда одно значение Content-ID может относиться к объекту "multipart/alternative", в то время как одно или более других значений Content-ID будут относиться к частям внутри объекта. 5.1.5. Субтип Digest Этот документ определяет субтип "digest" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в дайджесте, значение по умолчанию Content-Type для части тела меняется с "text/plain" на "message/rfc822". Это сделано, для того чтобы допустить более читаемый формат дайджеста, совместимый с RFC-934. Хотя можно специфицировать значение Content-Type для части тела в дайджесте, который отличается от "message/rfc822", такая часть как "text/plain", содержащая описание материала в дайджесте, делает это нежелательным. Тип содержимого "multipart/digest" предназначен для использования при посылке группы сообщений. Если необходима часть "text/plain", она должна быть включена как отдельная компонента сообщения "multipart/mixed". Дайджест в этом формате может выглядеть как. From: Moderator-Address From: someone-else-again 5.1.6. Субтип Parallel Этот документ определяет субтип "parallel" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в параллельном объекте, порядок частей тела не играет роли. Представление этого типа заключается в одновременном отображении всех частей с использованием имеющихся оборудования и программ. Однако программа отправитель должна учесть то, что многие приемники почты не способны выполнять операции параллельно и отобразят все части сообщения последовательно. 5.1.7. Прочие субтипы Multipart В будущем ожидается появление новых субтипов "multipart". Реализации MIME должны уметь работать с нераспознанными субтипами "multipart" как с "multipart/mixed". 5.2. Тип среды Message Часто желательно при посылке почты вложить туда какое-то другое сообщение. Для решения этой задачи определен специальный тип среды "message". В частности, для вложения в сообщения RFC-822 служит субтип "rfc822" Субтип "message" часто накладывает ограничения на допустимые типы кодирования. Эти ограничения описаны для каждого специфического субтипа. Почтовые шлюзы, системы транспортировки и другие почтовые агенты иногда изменяют заголовки верхнего уровня в сообщениях RFC 822. В частности, они часто добавляют, удаляют и меняют порядок полей заголовков. Эти операции запрещены для заголовков, вложенных в тело сообщения типа "message." 5.2.1. Субтип RFC822 Тип среды "message/rfc822" указывает, что тело содержит инкапсулированное сообщение. Однако в отличие от сообщений верхнего уровня RFC-822, ограничение, связанное с обязательным присутствием в теле "message/rfc822" заголовков "From", "Date", и, по крайней мере, одного адреса места назначения, здесь удалено. Необходимо лишь присутствие одного из заголовков "From", "Subject" или "Date". Следует заметить, что, несмотря на использование чисел "822", объект "message/rfc822" не должен абсолютно следовать регламентациям RFC-822. Более того, сообщение "message/rfc822" может быть статьей новостей или сообщением MIME. В теле объекта "message/rfc822" не разрешены никакие кодировки помимо "7bit", "8bit" или "binary". Поля заголовка сообщения содержат только US-ASCII в любом регистре, а информация в теле может быть закодирована. Не-US-ASCII-текст в заголовках инкапсулированного сообщения может быть специфицирован с использованием механизма, описанного в документе RFC-2047. 5.2.2. Субтип Partial Субтип "partial" определен, для того чтобы разрешить разделять на части слишком большие объекты, которые затем доставляются в виде отдельных почтовых сообщений и автоматически восстанавливаются как единое целое принимающим агентом пользователя. Этот механизм может использоваться, когда промежуточный транспортный агент ограничивает максимальный размер почтового сообщения. Тип среды "message/partial", таким образом, указывает, что тело содержит фрагмент некоторого большого объекта. Так как данные типа "message" могут не быть закодированны в виде base64 или закавыченной строки печатных символов, может возникнуть проблема, если объекты "message/partial" созданы в среде, которая поддерживает двоичный или 8-битовый обмен. Проблема возникает из-за того, что двоичные данные надо будет разбить на несколько сообщений "message/partial", каждое из которых требует двоичного транспорта. Если такие сообщения встретят по пути шлюз с 7-битовой передачей, не будет никакой возможности перекодировать эти фрагменты для 7-битовой среды. Можно конечно дождаться прихода всех составных частей, собрать исходный объект, закодировать его с помощью, например, base64, после чего начать все с начала. Но даже такой сложный сценарий может оказаться неосуществимым из-за того, что фрагменты могут транспортироваться разными путями. По этой причине, было специфицировано, что объекты типа "message/partial" должны всегда иметь транспортное кодирование "7bit" (по умолчанию). В частности, даже для сред, которые поддерживают двоичный или 8-битовый обмен, использование транспортного кодирования "8bit" или "binary" для MIME-объектов типа "message/partial" запрещено. Это в свою очередь предполагает, что внутреннее сообщение не должно использовать кодирование "8bit" или "binary". Так как некоторые агенты пересылки сообщений могут выбрать автоматическую фрагментацию длинных сообщений, а также из-за того, что эти агенты могут использовать разные пороги фрагментации, может так получиться, что фрагменты после сборки в свою очередь окажутся частями сообщения. Это вполне допустимо. В поле Content-Type типа "message/partial" необходимо специфицировать три параметра. "id" - уникальный идентификатор, который должен использоваться для привязки фрагментов друг к другу. "number" - целое число, которое является номером фрагмента. "total" - целое число, характеризующее полное число фрагментов. Число фрагментов является опционным и обязательно присутствует только в последнем фрагменте. Заметим также, что эти параметры могут быть заданы в любом порядке. Таким образом, второй сегмент 3-фрагментного сообщения может иметь поля заголовка одного из следующих видов. ontent-Type: Message/Partial; number=2; total=3;
Но в третьем сегменте должно быть специфицировано полное число фрагментов. Content-Type: Message/Partial; number=3; total=3;
Заметьте, что нумерация фрагментов начинается с 1, а не 0. Когда фрагменты объекта, разорванные таким способом, складываются вместе, результатом всегда будет исходный MIME-объект, который может иметь свое собственное поле заголовка Content-Type, и, следовательно, иметь любой другой тип данных. 5.2.2.1. Фрагментация и сборка сообщений Семантика восстановленных фрагментов сообщений должна соответствовать "внутреннему" сообщению, а не сообщению, в которое оно вложено. Это делает возможным, например, посылку большого аудио-сообщения в виде нескольких сообщений-фрагментов таким образом, что получатель воспримет его как простое аудио-сообщение, а не инкапсулированное сообщение, содержащее аудио-сообщение. Такая инкапсуляция рассматривается как прозрачная. Когда формируются фрагменты и осуществляется сборка составных частей сообщения "message/partial", заголовки инкапсулированного сообщения должны объединяться с заголовками вложенных объектов. При реализации этой процедуры должны выполняться следующие правила:
5.2.2.2. Пример фрагментации и сборки Если аудио-сообщение разделено на два фрагмента, первая часть может выглядеть как: X-Weird-Header-1: Foo X-Weird-Header-1: Bar From: Bill@host.com Затем, когда фрагментируемое сообщение оказывается собрано, результат, отображаемый для пользователя, должен выглядеть как: X-Weird-Header-1: Foo Включение в заголовки второго и последующих секций фрагментированного сообщения поля "References" (ссылка), которое указывает на Message-Id (идентификатор сообщения) предшествующей секции, может быть полезно для системы чтения почты, которая умеет отслеживать ссылки. Однако генерация полей "References" является опционной. Наконец, следует заметить, что поле "Encrypted" заголовка является устаревшим из-за внедрения конфиденциальной почты PEM (Privacy Enhanced Messaging; RFC-1421, RFC-1422, RFC-1423, RFC-1424), но правила описанные выше, несмотря ни на что, описывают правильный путь его обработки, если оно встретится в контексте прямого и обратного преобразования фрагментов "message/partial". 5.2.3. Субтип External-Body Субтип external-body указывает, что в сообщении содержатся не данные, а ссылка на место, где эти данные находятся. В этом случае параметры описывают механизм доступа к внешним данным. Когда объект MIME имеет тип "message/external-body", он состоит из заголовка, двух последовательностей CRLF, и заголовка для инкапсулированного сообщения. Если появится еще одна пара последовательностей CRLF, это завершит заголовок инкапсулированного сообщения. Однако так как тело инкапсулированного сообщения само является внешним, оно не появится вслед за заголовком. Например, рассмотрим следующее сообщение: Content-type: message/external-body;
Content-type: image/jpeg Область в конце, которую можно назвать телом-фантомом, игнорируется для большинства сообщений с внешним телом. Однако оно может использоваться для хранения вспомогательной информации для некоторых таких сообщений, как это действительно бывает, когда тип доступа - "mail-server". Единственный тип доступа, описанный в этом документе и использующий тело-фантом, это "mail-server", но могут быть описаны другие типы в будущем. Инкапсулированные заголовки во всех объектах "message/external-body" должны включать в себя поле заголовка Content-ID, для того чтобы предоставить уникальный идентификатор, который служит для ссылки на данные. Этот идентификатор может быть использован в процессе кэширования и для распознавания входных данных, когда типом доступа является "mail-server". Заметим, что, как это специфицировано здесь, лексемы, которые описывают данные внешнего тела, такие как имена файлов и команды почтового сервера, должны быть записаны с использованием символьного набора US-ASCII. Как с "message/partial", объекты MIME типа "message/external-body" MUST имеют транспортное кодирование 7-бит (по умолчанию). В частности, даже в среде, которая поддерживает 8-битовую транспортировку, использование транспортного кодирования "8bit" или "binary" категорически запрещено для объектов типа "message/external-body". 5.2.3.1. Общие параметры External-Body С "message/external- body" могут использоваться следующие параметры:
5.2.3.2. Типы доступа 'ftp' и 'tftp' Тип доступа FTP или TFTP указывают, что тело сообщения доступно в виде файла с помощью протоколов FTP [RFC-959] или TFTP [RFC- 783], соответственно. Для этих типов доступа необходимы следующие параметры:
Кроме того, следующие параметры являются опционными:
5.2.3.3. Тип доступа 'anon-ftp' Тип доступа "anon-ftp" идентичен варианту "ftp", за исключением того, что пользователю не нужно предоставлять имя и пароль. Вместо этого протокол ftp воспользуется именем "anonymous" и паролем, равным почтовому адресу пользователя. 5.2.3.4. Тип доступа 'local-file' Тип доступа "local-file" указывает, что тело данных доступно в виде файла на локальной ЭВМ. Для этого типа доступа определены два дополнительные параметра:
5.2.3.5. Тип доступа 'mail-server' Access-Type Тип доступа "mail-server" указывает, что тело данных доступно на почтовом сервере. Для этого типа доступа определены два дополнительные параметра:
Так как почтовые сервера воспринимают разнообразные синтаксисы, некоторые из которых являются многострочными, полная команда, которая должна быть послана почтовому серверу, не включается в качестве параметра с поле заголовка content-type. Вместо этого, она заносится как тело-фантом, когда тип среды соответствует "message/external-body", а тип доступа - mail-server. Заметим, что MIME не определяет синтаксис почтового сервера. Скорее, оно позволяет включение произвольных команд почтового сервера в тело-фантом. Программные реализации должны включать тело-фантом в тело сообщения, которое посылается по адресу почтового сервера для получения нужных данных. В отличие от других типов доступа, доступ к почтовому серверу является асинхронным и происходит в произвольный момент времени. По этой причине важно, чтобы существовал механизм, с помощью которого полученные данные могли быть сопоставлены с исходным объектом "message/external-body". Почтовые серверы MIME должны использовать то же поле Content-ID в сообщении-отклике, которое было использовано в исходных объектах "message/external-body", для того чтобы облегчить такое сопоставление. 5.2.3.6. Соображения безопасности External-Body Объекты "Message/external-body" подводят к следующим важным соображениям безопасности:
5.2.3.7. Примеры и дальнейшие расширения Когда используется механизм внешнего тела в сочетании с типом среды "multipart/alternative", это расширяет функциональность "multipart/alternative", так как включает случай, когда один и тот же объект может быть получен через разные механизмы доступа. Когда это сделано, отправитель сообщения должен упорядочить части по предпочтительности формата, а затем по механизму доступа. Для распределенных файловых систем очень трудно знать заранее группу машин, где файл может быть доступен непосредственно. Следовательно, имеет смысл предоставить как имя файла на случай его прямой доступности, так имена одного или нескольких узлов, где может быть доступен этот файл. Программные реализации могут пытаться извлечь удаленные файлы, используя FTP или другой протокол. Если внешнее тело доступно за счет нескольких механизмов, отправитель может включить несколько объектов типа "message/external-body" в секции тела объекта "multipart/alternative". Однако механизм внешнего тела не ограничивается извлечением файлов, как это показывается типом доступа mail-server. Помимо этого, можно предположить, например, использование видео-сервера для внешнего доступа к видео клипам. Поля заголовка вложенного сообщения, которые появляются в теле "message/external-body" должны использоваться для декларации типа среды внешнего тела, если оно представляет собой нечто отличное от чистого текста US-ASCII, так как внешнее тело не имеет секции заголовка, чтобы декларировать тип. Аналогично здесь должно быть также декларировано любое транспортное кодирование, отличное от "7bit". Таким образом, полное сообщение "message/external-body", относящееся к объекту в формате PostScript, может выглядеть как: From: От кого-то --42
Content-type: application/postscript name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.bellcore.com"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript --42 access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Заметим, что в вышеприведенных примерах в качестве транспортного кодирования для Postscript данных предполагается "7bit". Подобно типу "message/partial", тип среды "message/external-body" предполагается прозрачным, т.е. передается тип данных внешнего тела, а не сообщение с телом данного типа. Таким образом, заголовки внешней и внутренней
частей должны быть объединены с использованием правил, изложенных выше для "message/partial". В частности, это означает, что поля Content-type и Subject переписываются, а поле From сохраняется в неизменном виде. Заметьте, что, так как внешние тела не передаются вместе с указателем, они не должны удовлетворять транспортным ограничениям, которые налагаются на сам указатель. В частности, почтовая транспортная среда Интернет
может реализовать 7-битовый обмен и накладывать ограничение на длину строк, но они не распространяются на указатели на двоичное внешнее тело. Таким образом, транспортное кодирование не обязательно, но допустимо. Заметим, что тело сообщения типа "message/external-body" регламентируется базовым синтаксисом сообщения RFC 822. В частности, все, что размещено перед первой парой CRLF является заголовком, в то время как все, что
следует после заголовка, представляет собой данные, которые игнорируются для большинства типов доступа. 6. Экспериментальные значения типа среды Значение типа среды, начинающееся с символов "X-" представляет собой частное значение, предназначенное для применения системами, которые согласились между собой работать в таком режиме. Любой формат, не
являющийся стандартным, должен иметь имя, начинающееся с префикса "X-", а утвержденные стандартные имена никогда не начинаются с "X-". Вообще, использование "X-" для типов верхнего уровня категорически не рекомендуется. Разработчики должны придумывать субтипы существующих типов. Во многих случаях субтип "application" будет более уместен, чем новый тип верхнего уровня. Приложение A -- обзор грамматики Данное приложение содержит все синтаксические конструкции, описанные в разделе MIME. Сама по себе данная грамматика не может считаться полной. Она базируется на нескольких правилах, определенных в документе RFC 822. Если какой-то термин не определен, его значение предполагается заданным в RFC 822. Сами правила RFC 822 здесь не представлены. boundary := 0*69 close-delimiter := delimiter "--" boundary берется из значения пограничного параметра из поля Content-Type. delimiter := CRLF dash-boundary Dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] preamble := discard-text III. Расширения для заголовков сообщений с не-ASCII текстом В этом разделе описывается техника кодирования не-ASCII-текста в различных частях заголовка сообщения RFC-822 [2]. Подобно тому, как это рассказано в первом разделе описания MIME, методика сконструирована так, чтобы допустить использование не-ASCII символов в заголовках сообщения так, чтобы даже специфические)
удаляют некоторые поля заголовков, сохраняя другие, (b) меняет содержимое адресов в полях To или Cc, (c) меняют вертикальный порядок размещения полей заголовка. Кроме того, некоторые почтовые программы не всегда способны
корректно интерпретировать заголовки сообщений, в которых встречаются некоторые редко используемые рекомендации документа RFC 822, например, символы обратной косой черты для выделения специальных символов типа "<", "," или ":". Расширения, описанные здесь, не базируются на редко используемых возможностях RFC-822. Вместо этого, определенные последовательности "обычных" печатных ASCII символов (известных как "encoded-words" - кодировочные слова) зарезервированы для использования в качестве кодированных данных. Синтаксис кодированных слов таков, что они
вряд ли могут появиться в нормальном тексте заголовков сообщений. Более того, символы, используемые в кодировочных словах, не могут иметь специального назначения в контексте, где появляются эти слова. Вообще, "encoded-word>" представляет собой последовательность печатных ASCII-символов, которая начинается с "=?", завершается "?=" и имеет два "?" между ними. Оно специфицирует символьный набор и метод кодирования, а также включает в себя оригинальный текст в виде графических ASCII-символов, созданный согласно правилам данного
метода кодирования. Отправители почты, которые используют данную спецификацию, предоставят средства для помещения не-ASCII текста в поля заголовка, но транслируют эти поля (или соответствующие части полей) в кодировочные слова, прежде чем помещать их в заголовок сообщения. Система чтения почты, которая реализует данную спецификацию, распознает кодировочные слова, когда они встречаются в определенной части заголовка сообщения. Вместо того чтобы отображать кодировочное слово, программа
осуществляет декодирование исходного текста с использованием соответствующего символьного набора. Данный документ в заметной мере базируется на нотации и терминах RFC-822 и RFC-2045. В частности, синтаксис для ABNF, используемый здесь, определен в RFC-822. Среди терминов, определенных в RFC-822 и использованных в данном документе: 'addr-spec' (спецификация адреса), 'атом', 'CHAR', 'комментарий', 'CTL', 'ctext', 'linear-white-space'
(HT| SP|CRLF), 'фраза', 'quoted-pair', 'закавыченная строка', 'пробел' и 'слово'. Успешная реализация расширения этого протокола требует тщательного внимания к определениям этих терминов в RFC-822. Когда в данном документе встречается термин "ASCII", он относится к "7-битовому стандарту, ANSI X3.4-1986. Имя этого символьного набора в MIME "US-ASCII". 2. Синтаксис кодированных слов (encoded-words) 'Кодировочное слово' определено согласно следующей ABNF-грамматике. Используется нотация RFC-822, за исключением того, что символы "white space" (HT и SP) не должны появляться между компонентами кодировочного слова. encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; см. секцию 3 encoding = token ; см. секцию 4 token = 1* ; (см. "Использование encoded-words в заголовках сообщений", часть 5) Слова 'encoding' и 'charset' не зависят от регистра, в котором напечатаны. Таким образом символьный набор с именем "ISO-8859-1" эквивалентен "ISO-8859-1", а кодирование с именем "Q" может записываться как "Q" или "q". 'Кодировочное слово' (encoded-word) не может быть длиннее 75 символов, включая 'charset', 'encoding', 'encoded-text' и разделители. Если желательно закодировать текст больший, чем 75 символов, можно использовать несколько кодировочных слов, разделенных CRLF SP. Хотя ограничений на длину многострочного поля заголовка, каждая строка поля заголовка, которая содержит одно или более кодировочных слов, ограничена 76 символами. Ограничения длины введены, для того чтобы облегчить сетевое взаимодействие различных почтовых шлюзов и упростить работу программ разборки кодировочных слов. 'Кодировочные слова' сконструированы так, чтобы быть узнаваемыми как "атомы" программой грамматического разбора RFC-822. Как следствие, незакодированные символы SP и HT в пределах кодировочных слов
запрещены. Например, символьная последовательность =?iso-8859-1?q?this is some text?= будет воспринята программой разборки RFC-822 как четыре атома, а не как один атом, или как ''кодировочное слово" (в случае программы разборки, воспринимающей кодировочные слова). Правильный способ
закодировать строку "this is some text" - это кодировать и сами пробелы, например: =?iso-8859-1?q?this=20is=20some=20text?= 3. Символьный набор Секция 'charset' кодировочного слова специфицирует символьный набор, соответствующий незакодированному тексту. 'charset' может представлять любой символьный набор, разрешенный параметром "charset" MIME
части тела "text/plain", или любой символьный набор с именем, зарегистрированным IANA для использования с типом содержимого text/plain MIME. Некоторые символьные наборы используют технику переключения кодов для перехода между режимом "ASCII" и другими режимами. Если текст в кодировочном слове содержит последовательность, которая заставляет
интерпретатор символьного набора переключиться из режима ASCII, он должен содержать дополнительные управляющие коды, которые переключат систему в ASCII-режим в конце кодировочного слова. Когда имеется возможность использования более одного символьного набора для представления текста в кодировочном слове и в отсутствии частного соглашения между отправителем и получателем сообщения, рекомендуется,
чтобы предпочтительно использовались члены символьного семейства ISO-8859-*. 4. Кодирование Первоначально легальными значениями кодирования являются "Q" и "B". Эти кодировки описаны ниже. Кодирование "Q" рекомендуется для использования, когда большинство символов, которые нужно преобразовать,
представлены в наборе ASCII; в противном случае, следует использовать "B"-кодирование. Несмортя ни на что программа, читающая почту, которая воспринимает кодировочные слова, должна быть способна обрабатывать любые кодировки для
любых символьных наборов, которые она поддерживает. В кодированном тексте может использоваться только субнабор печатных ASCII-символов. Символы SP и HT не допустимы, чтобы начало и конец кодировочного слова были выделены однозначно. Символ "?" используется в
"кодировочном слове" для разделения различных частей этого слова друг от друга. По этой причине "?" не может появляться в секциях "кодировочного слова". Другие символы могут также оказаться нелегальными в определенном контексте. Например,
'encoded-word' во 'фразе', предшествующей адресу в поле заголовка From не может содержать какие-либо специальные символы ("specials"), определенные в RFC-822. Наконец, некоторые другие символы также недопустимы в определенных
контекстах, это связано с необходимостью обеспечить надежность пересылки сообщений через почтовые шлюзы. "B"-кодирование автоматически отвечает этим требованиям. "Q"-кодирование допускает использование широкого перечня печатных символов в некритических позициях заголовка сообщения (например, в Subject), с ограниченным
списком символов, допустимых в других полях. 4.1. "B"-кодирование "B"-кодирование идентично "BASE64", описанному RFC-2045. 4.2. "Q"-кодирование "Q"-кодирование подобно закавыченным строкам печатных символов ("Quoted-Printable"), описанным в RFC-2045. Оно создано, для того чтобы позволить читать текст, содержащему по большей части ASCII-символы, а
алфавитно-цифровом терминале без декодирования. (1) Любой 8-битовый код может быть представлен с помощью символа "=", за которым следуют два шестнадцатеричных числа. Например, если бы используемый символьный набор был ISO-8859-1,
символ "=" кодировался как "=3D", а пробел (SP) как "=20". (Для шестнадцатеричных чисел следует использовать верхний регистр "A" - "F".) (2) 8-битовое шестнадцатеричное число 20 (напр., ISO-8859-1 SPACE) может быть представлено как "_" (знак подчеркивания, ASCII 95.). (Этот символ может не пройти через некоторые почтовые
шлюзы, но его использование существенно улучшает читаемость "Q"-кодированных данных в почтовых системах, которые поддерживают этот вид кодирования). Заметим, что "_" всегда представляется шестнадцатеричным кодом 20, даже если
символ пробел (SPACE) занимает другую кодовую позицию в используемом символьном наборе. (3) 8-битовые значения, которые соответствуют печатным ASCII-символам, отличным от "=", "?" и "_", могут быть представлены самими собой. Об ограничениях см. раздел 5. В частности, SP и HT не должны представляться самими
собой в пределах кодировочных слов. 5. Использование кодировочных слов в заголовках сообщений 'encoded-word' может появиться в заголовке сообщения или в заголовке тела секции в соответствии со следующими правилами: (1) 'encoded-word' может заменить текстовую лексему (как это определено в RFC-822) в любом из полей заголовка Subject или Comments, в любом поле расширения заголовка, или любом
поле секции тела MIME, для которого поле тела определено как '*text'. 'encoded-word' может также появиться в любом поле сообщения или секции тела, определенном пользователем ("X-"). Обычный ASCII-текст и 'кодировочные слова' могут появляться совместно в пределах одного и того же поля заголовка. Однако 'кодировочное слово', появляющееся в поле заголовка, определенное как '*text', должно быть отделено от любого смежного 'encoded-word' или 'текста' с помощью LWS (HT|SP|CRLF). (2) 'encoded-word' может появляться внутри 'комментария', ограниченного "(" и ")", т.е., там, где допустим 'ctext'. Более точно, ABNF-определение (RFC-822) для 'comment' следует скорректировать как: comment = "(" *(ctext | quoted-pair | comment | encoded-word) ")" "Q"-кодированное 'encoded-word', которое появляется в комментарии не должно содержать символов "(", ")" или ". 'Кодировочное слово', появляющееся в комментарии должно отделяться от смежного 'encoded-word' или 'ctext' с помощью LWS. Важно заметить, что комментарии распознаются только внутри структурированных полей тела. В полях, чьи тела определены как '*text', "(" и ")" обрабатываются как обычные символы, а не как разделители комментариев, и
применимо правило (1) этой секции. (См. RFC-822, секции 3.1.2 и 3.1.3) (3) В качестве замены для объекта 'word' во 'фразе', например, перед адресом в заголовке From, To или Cc.
ABNF-определение для 'phrase' RFC-822 приобретает вид: В этом случае набор символов, который можно использовать с "Q"-кодированным 'encoded-word' ограничивается до: < ASCII-буква верхнего и нижнего регистров, десятичные цифры, "!", "*", "+", "-", "/", "=" и "_" (ASCII 95.)>. 'Кодировочное слово', которое появляется внутри 'фразы', должно быть отделено от любого смежного 'слова', 'текста' или специального символа ('special') посредством LWS. Это единственные места, где может появиться 'encoded-word'. В частности: + 'encoded-word' не должно появляться в любой части 'addr-spec'. 'Кодированный текст' не должен продолжаться от одного 'encoded-word' к другому. Это предполагает, что секция кодированного текста 'B-encoded-word' будет иметь длину кратную 4 символам; для 'Q-encoded-word', за любым символом "=", который появляется в секции кодированного текста, следуют две шестнадцатеричные цифры. Каждое 'encoded-word' должно кодировать полное число октетов. 'Кодированный текст' в каждом 'encoded-word' должен быть хорошо оформлен согласно специфицированному кодированию. 'Кодированный текст' не может
продолжаться в следующем 'encoded-word'. (Например, "=?charset?Q?=?= =?charset?Q?AB?=" было бы нелегальным, так как два шестнадцатеричные числа "AB" должны следовать за "=" в одном и том же 'encoded-word'.) Каждое 'encoded-word' представлять собой целое число символов. Многооктетные символы не могут расщепляться между смежными 'кодировочными словами'. Согласно этой схеме кодируются только печатные символы и WS (HT и SP). Однако так как эти схемы кодирования позволяют работать с произвольными октетами, программы чтения почты, которые используют такое
декодирование, должны быть избавлены от любых нежелательных побочных эффектов при отображении данных на терминале получателя. Использование этих методов для кодирования нетекстовых данных (напр., изображения или голоса) в данном документе не определено. Применение 'кодировочных слов' для представления строк ASCII-символов допустимо, но не рекомендуется. 6. Поддержка 'кодировочных слов' в программах чтения почты Программа чтения почты должна осуществлять разбор сообщения и заголовков секций согласно правилам RFC-822, для того чтобы правильно распознать 'кодировочные слова'. 'кодировочные слова' должны распознаваться как: (1) Поле заголовка любого сообщения или части тела, определенное как '*text', или любое поле заголовка, определенное пользователем, должно разбираться следующим образом: Начало обозначается LWS (HR|SP|CRLF), любая последовательность вплоть до 75 печатных символов (не содержащая LWS) должна рассматриваться как кандидат в 'кодировочные слова' и проверяться на соблюдение правил синтаксиса, описанных в секции 2 данного раздела. Любую другую последовательность печатных символов следует рассматривать как обычный ASCII-текст. (2) Любое поле заголовка, не определенное как '*text' должно разбираться согласно синтаксическим правилам для данного поля заголовка. Однако любое 'слово', которое появляется в пределах 'фразы' должно обрабатываться как 'кодировочное слово', если оно отвечает синтаксическим правилам секции 2. В противном случае оно должно обрабатываться как обычное 'слово'. (3) Внутри 'комментария', любая последовательность с длиной до 75 символов (не содержащая LWS), которая отвечает синтаксическим правилам секции 2, должна обрабатываться как 'кодировочное слово'. В противном случае оно должно обрабатываться как обычный текст комментария. (4) Поле заголовка MIME-Version может отсутствовать в 'кодировочных словах', которые обрабатываются согласно данной спецификации. Причиной этого является то, что программа чтения почты не предполагает разбирать весь заголовок сообщения, прежде чем отображать строки, которые могут содержать 'кодировочные слова'. 6.2. Отображение кодированных слов Любые распознанные 'кодированные слова' декодируются и, если возможно, полученный в результате текст отображается с использованием стандартного символьного набора. Декодирование и отображение закодированных слов происходит, после того как структурные поля тела будут разобраны на лексемы. Следовательно, возможно спрятать 'специальные' символы в 'кодировочных словах', которые
при отображении будут неотличимы от 'специальных' символов окружающего текста. По этой и другим причинам вообще невозможно транслировать заголовок сообщения, содержащий 'кодировочные слова', к виду, который может анализироваться
программой чтения почты (RFC-822). При отображении конкретного поля заголовка, который содержит несколько 'кодировочных слов', любой
LWS, который разделяет пару смежных 'кодировочных слов', игнорируется. В случае определения в будущем другого кодирования, которое почтовая программа не поддерживает,
она может отобразить 'кодировочное слово', как обычный текст или выдать сообщение, что текст не может быть декодирован. Если почтовая программа не поддерживает использованный символьный набор, она может отобразить 'кодировочное слово', как обычный текст (т.е., так как оно записано в заголовке), может попробовать отобразить его с
использованием имеющегося символьного набора, или выдать сообщение, что текст не может быть отображен. Если используемый символьный набор реализует технику кодового переключения, отображение кодированного текста начинается в режиме "ASCII". Кроме того, почтовая программа должна проверить, что выходное
устройство снова в режиме "ASCII", после того как отображено 'кодировочное слово'. 6.3. Обработка почтовой программой некорректно сформированных 'кодировочных слов' Возможно, что 'кодировочное слово', которое легально согласно синтаксическим правилам секции 2, не корректно сформировано с точки зрения регламентаций использованного правила кодирования. Например: (1) 'Кодировочное слово', которое содержит символы нелегальные для конкретного кодирования (Например, "-" в "B"-кодировании, или SP и HT в "B"- или "Q"-кодировании), является некорректно сформированным. (2) Любое 'кодировочное слово', которое кодирует нецелое число символов или октетов является некорректно сформированным. Программа чтения почты не должна пытаться отобразить текст, ассоциированный с 'кодировочным словом', которое сформировано некорректно. Однако программа чтения почты не должна препятствовать отображению или
обработке сообщения из-за того, что 'кодировочное слово' некорректно сформировано. 7. Согласование Программа, формирующая почтовое сообщение и соответствующая данной спецификации, должна гарантировать, что любая строка печатных ASCII-символов, не содержащая HT и SP в пределах '*text' или '*ctext', начинается с
"=?" и завершается "?=" является корректным 'кодировочным словом'. ("Начинается" означает: в начале тела сразу после LWS, или сразу после "(" для 'кодировочного слова' в пределах '*ctext'; "завершается" означает: в конце тела, непосредственно перед LWS, или непосредственно перед ")" для 'кодировочного слова' в '*ctext'.) Кроме того, любое 'слово' в 'фразе', которое начинается с "=?" и завершается "?=" должно быть корректным 'кодировочным словом'. Программа, читающая почтовые сообщения, совместимые с данной спецификацией должна быть способна отделить 'кодировочное слово' от 'text', 'ctext', или 'слов', которые согласуются с правилами секции 6, где бы они не встретились в заголовке сообщения. Она должна поддерживать "B"- и "Q"-кодирование для любых символьных наборов, которые она поддерживает. Программа должна быть способна отобразить не кодированный текст, если символьный набор
соответствует "US-ASCII". Для символьных наборов ISO-8859-*, программа должна быть способна, по крайней мере, отобразить символы, которые совпадают с ASCII. 8. Примеры Ниже приведены примеры заголовок сообщений, содержащих 'кодировочные слова': From: =?US-ASCII?Q?Keith_Moore?= В выше приведенном примере в 'кодировочном слове' поля, последний символ "=" в конце кодированного текста необходим, так как каждое 'кодировочное слово' должно быть самодостаточным (символ "=" завершает группу из 4 символов base64 представляющих 2 октета). Дополнительный октет может быть закодирован в первом 'кодировочном слове' (так чтобы 'кодировочное слово' содержало число октетов кратное трем). Второе 'кодировочное слово' использует символьный набор, не совпадающий с тем, что применен в первом слове. From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= To: Dave Crocker Правила несколько отличаются для полей, определенных как '*text' так как "(" и ")" не распознаются в качестве разделителей комментария. [Секция 5, параграф (1)]. В каждом из следующих примеров, если бы одна и та же последовательность встретилась в поле '*text', форма "Отображается как" не рассматривалась бы как кодировочные слова, а была бы идентична форме
"Кодированное представление". Это происходит, потому что каждое из 'кодировочных слов' в ниже приведенных примерах соседствуют с символами "(" или ")".
Кодированное представление Отображается как (=?ISO-8859-1?Q?a?=) (a) (=?ISO-8859-1?Q?a?= b) (a b) В пределах 'комментария', HT или SP должны появляться между 'кодировочным словом' и окружающим текстом. [Секция 5, параграф (2)]. Однако HT или SP не нужны между начальным символом "(", который открывает 'комментарий', и 'кодировочным словом'.
HT или SP между смежными 'кодировочными словами' не отображаются.
Даже кратные пробелы между 'кодировочными словами' игнорируются.
Любое число LWS между 'кодировочными словами', даже если там содержится CRLF, за которым следует один или более пробелов, игнорируется.
Для того чтобы пробел был отображен в пределах кодированного текста, SP должен быть закодирован в качестве части 'кодировочного слова'.
Для того чтобы пробел был отображен между двумя строками кодированного текста, SP может быть закодирован как составная часть одного из 'кодировочных слов'. 9. Ссылки
IV. Процедуры регистрации 1. Введение Современные протоколы Интернет с самого начала создавались таким образом, чтобы их было легко расширить или модернизировать. В частности, MIME [RFC-2045] является открытой системой, допускающей введение новых типов объектов, символьных наборов и методов доступа без изменения базового протокола. Однако необходим процесс регистрации, чтобы гарантировать, что набор таких значений соответствует стандарту и может использоваться в общедоступных сетях. Здесь рассматриваются процедуры регистрации, которые осуществляются через IANA (Internet Assigned Numbers Authority), центральной инстанции для решения этих проблем. Процесс регистрации для типов среды был первоначально определен в контексте асинхронной почтовой среды Интернет. В этой почтовой среде существует необходимость ограничить число возможных типов среды, чтобы увеличить вероятность успешного взаимодействия с удаленной почтовой системой, когда ее возможности заранее не известны. 2. Регистрация типа среды Регистрация нового типа среды начинается с формирования регистрационного предложения. Регистрация может произойти в рамках различных регистрационных схем (деревьев), которые предполагают различные требования. Вообще, новое регистрационное предложение оценивается и рассматривается в зависимости от используемой схемы (дерева). Тип среды затем регистрируется, если предложение оказывается приемлемым. 2.1. Деревья регистрации и имена субтипов Для того чтобы увеличить эффективность и гибкость процесса регистрации различные структуры субтипов имен могут быть зарегистрированы так, чтобы удовлетворить различным естественным требованиям, например, субтип, который будет рекомендованa для широкого использования сообществом Интернет или субтип, который используется для переноса файлов, ассоциированных с некоторой частной программой. Последующие субсекции данного документа определяют регистрационные "деревья", отличающиеся использованием стандартной формы имен (например, имен вида "tree.subtree...type"). Заметим, что некоторые типы среды определены до появления данного документа и их имена не согласуются с данной схемой. Смотри приложение A, где рассматривается эта проблема. 2.1.1. IETF-дерево Дерево IETF служит для типов, представляющих общий интерес для сообщества Интернет. Регистрация в IETF требует одобрения IESG и публикации данного типа среды в каком-то документе RFC. Типы среды в IETF-дереве обычно обозначаются именами, которые не оформлены стандартным образом, т.е., не содержат символов точка (".", полный останов). "Хозяином" регистрации типа среды в рамках дерева IETF предполагается сама группа IETF. Модификации или изменения спецификации требуют той же процедуры, что и регистрация. 2.1.2. Дерево производителя (Vendor Tree) Дерево производителя используется для типов среды, соответствующих определенным коммерческим продуктам. Результат регистрации может быть ассоциирован с деревом производителя тем, кто нуждается в замене файлов, сопряженных с определенным программным продуктом. Однако регистрация формально принадлежит производителю или организации, разработавшей программу или формат. Регистрация в рамках дерева производителя выделяется с помощью префикса имени "vnd.". Далее может следовать имя известного производителя (например, "vnd.lapot"), адрес производителя или место расположения программы, заключительная секция имени может содержать наименование типа среды (например, vnd.bigcompany.funnypictures). 2.1.3. Частное дерево Регистрация типов среды, созданных с экспериментальными целями, могут быть зарегистрированы в рамках частного дерева. Регистрация такого вида имеет префикс имени "prs.". Хозяином "частной" регистрации и соответствующих спецификаций является человек или объект, осуществивший регистрацию. Публикация частных типов среды не требуется. 2.1.4. Специальное `x.'-дерево Для удобства и симметрии со схемой регистрации имена типов среды, начинающиеся с "x." могут использоваться для тех же целей, что и имена, начинающиеся с "x-". Эти типы не являются зарегистрированными и могут использоваться партнерами при взаимном согласии. Однако при упрощенной процедуре регистрации, описанной выше для частных типов и типов среды производителей трудно себе представить ситуацию, когда бы возникла необходимость использования незарегистрированных типов среды. 2.1.5. Дополнительные регистрационные деревья От случая к случаю как этого требует сообщество, IANA может по согласованию с IESG, создать новое регистрационное дерево верхнего уровня. Предполагается, что такие деревья могут быть созданы для внешней регистрации и управления, например научными сообществами для их внутреннего использования. Вообще, качество рассмотрения спецификаций для этих деревьев регистрации должно быть столь же тщательным, как и в случае IETF. О создании этих новых деревьев уведомляет публикация RFC, одобренная IESG. 2.2. Требования регистрации Предложения регистрации среды должны соответствовать требованиям изложенным ниже в последующих разделах. Заметим, что требования могут иной раз зависеть от дерева регистрации. 2.2.1. Требования функциональности Типы среды должны функционировать как настоящий формат среды. Регистрация вещей, которые относятся в большей мере к транспортному кодированию, выбору символьного набора не допускается. Например, хотя существуют приложения, которые осуществляют транспортное декодирование base64 [RFC-2045], base64 не может быть зарегистрировано в качестве типа среды. Это требование не зависит от используемого регистрационного дерева. 2.2.2. Требования к именам Всем зарегистрированным типам среды должны быть присвоены имена типов и субтипов MIME. Комбинация этих имен служит в дальнейшем для идентификации типа среды и формата субтипа. При выборе имени типа верхнего уровня должна учитываться природа типа среды. Например, среда, используемая для представления статической картинки должна быть субтипом типа изображение, в то время как среда, способная представлять звуковую информацию должна принадлежать аудио типу. Для получения дополнительной информации смотри RFC-2046. Новые субтипы типов верхнего уровня должны соответствовать регламентациям этого уровня. Например, все субтипы типа составных данных должны использовать один и тот же синтаксис инкапсуляции. В некоторых случаях новый субтип среды может не вполне согласовываться с определенным на текущий момент типом содержимого верхнего уровня. Если такое произошло, следует определить новый тип верхнего уровня, который бы согласовывался с данным субтипом. Такое определение должно быть выполнено согласно стандартной процедуре и опубликовано в RFC. Это требование не зависит от используемого регистрационного дерева. 2.2.3. Требования к параметрам Типы среды могут использовать один или более параметров MIME, некоторые параметры могут оказаться автоматически доступными для типа среды в случае, когда они применимы ко всему семейству субтипов. В любом случае имена, величины и назначение любого параметра должны быть полностью специфицированы при регистрации типа среды в рамках дерева IETF. Они должны быть специфицированы как можно полнее, когда тип среды регистрируется в рамках частного дерева или дерева производителя. Новые параметры не могут определяться с целью расширения функциональности для типов, зарегистрированных в рамках дерева IETF. Но новые параметры могут быть добавлены для передачи дополнительной информации, которая не изменяет существующую функциональность. 2.2.4. Требования к канонизации и формату Все зарегистрированные типы среды должны использовать один канонический формат данных вне зависимости от дерева регистрации. Спецификация формата каждого типа среды необходима для всех типов зарегистрированных для дерева IETF, эта информация должна присутствовать и в предложении для регистрации типа среды. Спецификации формата и особенностей обработки могут быть, а могут и не быть общедоступны для типов среды, зарегистрированных для дерева производителя. В предложения регистрации такого вида включаются только спецификации программы и ее версии пригодной для работы с данным типом среды. Включение спецификаций формата или ссылки на них в предложение регистрации желательно, но не обязательно. Спецификации формата необходимы для регистрации в рамках частного дерева, они могут быть опубликованы в RFC или помещены в депозитарий IANA. Спецификации, помещаемые в депозитарий должны отвечать тем же требованиям, что и регистрируемые. Некоторые типы среды включают в себя патентованные технологии. Регистрация типа среды, включающего в себя патентованные технологии, также разрешена. Однако устанавливаются ограничения (RFC-1602) на применение патентованных технологий в рамках стандартных протоколов. 2.2.5. Рекомендации по взаимозаменяемости Типы среды должны быть способны работать с максимально возможным числом систем и приложений. Однако некоторые типы среды неизбежно будут иметь проблемы при работе на некоторых платформах. Могут возникнуть трудности из-за различных версий, порядка байт, специфики работы шлюза и т.д. Способность работы с любыми типами среды не требуется, но желательно, чтобы были четко описаны границы применимости. Публикация типа среды не предполагает исчерпывающего обзора возможностей работы с различными платформами и приложениями. 2.2.6. Требования к безопасности Рассмотрение аспектов безопасности необходимо для всех типов, регистрируемых в рамках IETF-дерева. Аналогичный анализ для типов среды регистрируемых в рамках частного дерева или дерева производителя рекомендуется, но не является обязательным. Однако вне зависимости от того что анализ безопасности мог проводиться или нет, все описания соображений по безопасности должны быть выполнены крайне аккуратно вне зависимости от дерева регистрации. В частности, заявление, что "никакие соображения безопасности не сопряжены с этим типом" не следует путать с "безопасность сопряженная с данным типом не анализировалась и не оценивалась". Не существует требования, чтобы регистрируемые типы среды были безопасны и не несли в себе каких либо рисков. Несмотря на это, все известные риски должны быть идентифицированы при регистрации типа вне зависимости от используемого дерева. Секция безопасности подлежит дальнейшему развитию. Некоторые аспекты, которые следует учитывать при анализе безопасности типа среды, перечислены ниже.
В асинхронных почтовых системах, где информация о возможностях удаленного почтового агента часто не доступна для отправителя, максимум взаимодействия может быть достигнут путем ограничения числа типов среды, используемых для общих форматов, которые предполагается широко внедрять. Именно эта концепция, принятая в прошлом, явилась причиной ограничения числа возможных типов среды и привела к формированию процесса регистрации типов среды. Однако необходимость в "общих" типах среды не требует ограничения регистрации новых типов. Если для определенного приложения рекомендуется ограниченный набор типов среды, это должно быть определено отдельным заявлением применимости для приложения или среды реализации. 2.2.7. Требования к публикации Предложения для типов среды регистрируемых в рамках IETF-дерева должны публиковаться в виде RFC. RFC-публикации типа среды производителя или частного типа среды желательны, но не обязательны. Во всех случаях IANA сохраняет копии всех предложений по типам среды и публикует их как часть самого регистрационного дерева типов среды. Дерево IETF существует для типов среды, которые действительно требуют серьезного анализа и стандартного процесса одобрения, в то время как деревья производителей и частные деревья такой процедуры не требуют. Ожидается, что заявления о применимости для конкретных приложений будут публиковаться время от времени для типов среды, которые доказали свою эффективность в определенных контекстах. Как было обсуждено выше, регистрация типа среды верхнего уровня предполагает стандартную процедуру принятия и, следовательно, обязательную RFC-публикацию. 2.2.8. Дополнительная информация Различные виды опционной информации могут быть включены в спецификацию типа среды, если таковые имеются:
Такая информация часто оказывается весьма полезной и, если имеется, то должна предоставляться. 2.3. Процедура регистрации Следующая процедура была применена IANA для обзора и одобрения новых типов среды. Для регистрации в рамках дерева IETF, нужно следовать обычной процедуре, осуществляя на первом этапе рассылку интернет-проекта. Для регистрации в рамках частного дерева или дерева производителя осуществляется без широкого обсуждения. Проект непосредственно направляется IANA (по адресу iana@iana.org). 2.3.1. Представление типа среды на суд сообщества Все начинается с посылки предложения регистрации типа среды лист-серверу ietf-types@iana.org . Отклики ожидаются в течение двух недель. Этот подписной лист был учрежден для целей обсуждения предлагаемых типов среды и доступа. Предложенные типы среды, если они формально не зарегистрированы, не могут быть использованы; префикс "x-", специфицированный в RFC-2045, может применяться до тех пор, пока процесс регистрации не завершится. Типы среды, регистрируемые в рамках дерева IETF должны представляться на одобрение IESG. Получив подтверждение, что тип среды отвечает всем требованиям, автор может послать запрос регистрации IANA, которая зарегистрирует тип среды и сделает его доступным для всего сообщества. 2.4. Комментарии по поводу регистрации типа среды Комментарии по поводу регистрации типа среды могут быть направлены членам сообщества IANA. Эти комментарии будут переданы "хозяину" типа среды. Комментаторы могут потребовать, чтобы их замечания были присовокуплены к материалам регистрации данного типа среды и, если IANA одобрит это, такая процедура будет произведена. 2.5. Расположение списка зарегистрированных типов среды Материалы регистрации типа среды доступны через анонимный FTP сервер ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ , а все зарегистрированные типы среды будут перечислены в периодически обновляемом документе "Assigned Numbers" RFC [в настоящее время STD-2, RFC-1700]. Описания типа среды и другие материалы могут быть также опубликованы в виде информационных RFC путем посылки документа по адресу "rfc-editor@isi.edu" [RFC-1543]. 2.6. Процедура регистрации типа среды в IANA IANA регистрирует типы среды, принадлежащие дереву IETF. Частные типы и типы среды производителя регистрируются IANA автоматически и без формального обсуждения, если выполнены следующие условия:
2.7. Управление изменением Раз тип среды опубликован IANA, автор может потребовать изменения его описания. Запрос изменения оформляется также как и сама регистрация:
Изменения следует делать лишь при обнаружении серьезных упущений или ошибок в опубликованной спецификации. Владелец типа содержимого может передать ответственность за него другому лицу или организации, проинформировав об этом IANA и список рассылки ietf-типов. Это может быть сделано без обсуждения. IESG может переадресовать ответственность за определенный тип среды. Наиболее общим случаем является разрешение изменений в описании типа среды в ситуации, когда автор исходного документа умер, эмигрировал или стал недоступен и не может внести изменения крайне важные для сообщества пользователей. Регистрации типа среды не могут быть аннулированы. Типы среды, которые не используются более, объявляются устаревшими (OBSOLETE) путем изменения их поля "intended use" (область применения). Такие типы среды будет помечены соответствующим образом и в списках, публикуемых IANA. 2.8. Регистрационный шаблон To: ietf-types@iana.org
3. Типы доступа к внешнему телу RFC-2046 определяет тип среды message/external-body, в рамках которой объект MIME может действовать, как указатель на реальное информационное тело сообщения. Каждый указатель message/external-body специфицирует тип доступа, который определяет механизм получения реального тела сообщения. RFC-2046 определяет исходный набор типов доступа, но допустимо описание нового механизма доступа в процессе регистрации нового типа среды. 3.1. Требования к регистрации Спецификации нового типа доступа должны отвечать ряду требований, описанных ниже. Каждый тип доступа должен иметь уникальное имя. Это имя появляется в параметре типа доступа в поле заголовка типа содержимого message/external-body, и должно соответствовать синтаксису параметров MIME. Все протоколы транспортные средства и процедуры, используемые данным типом доступа, должны быть описаны в самой спецификации типа доступа или в какой-то другой общедоступной спецификации, достаточно подробно, чтобы этим мог воспользоваться квалифицированный программист. Использование секретных и/или частных методов доступа категорически запрещено. Ограничения, введенные документом RFC-1602 на стандартизацию патентованных алгоритмов, также должны быть учтены. Все типы доступа должны быть описаны в RFC. RFC может быть информационным, а не обязательно описанием стандарта. Любые соображения безопасности, которые возникают в связи с реализацией типа доступа, должны быть подробно описаны. Совсем не нужно, чтобы метод доступа был безопасным или лишенным рисков, но известные риски должны быть идентифицированы. 3.2. Процедура регистрации Регистрация нового типа доступа начинается с создания проекта RFC. Далее осуществляется рассылка проекта через список подписки ietf-types@iana.org . Для получения откликов выделяется две недели. Этот подписной лист создан для целей обсуждения предлагаемых типов среды и доступа. Предлагаемые типы доступа не должны применяться до момента формальной регистрации. Когда двухнедельный период истечет, ответственное лицо, назначенное региональным директором IETF, переадресует запрос iana@isi.edu, или отклоняет его из-за существенных возражений, высказанных в процессе обсуждения. Решения принятые ответственным лицом IETF рассылаются всем через подписной лист IETF-types всем заинтересованным лицам в пределах двух недель. Это решение может быть обжаловано в IESG. Утвержденная спецификация типа доступа должна быть опубликована в качестве документа RFC. Информационные RFC публикуются путем посылки их по адресу "rfc-editor@isi.edu". 3.3. Расположение списка зарегистрированных типов доступа Зарегистрированные спецификации типа доступа доступны через анонимное FTP на сервере ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/ . Все зарегистрированные типы доступа включаются в перечень типов доступа, периодически публикуемый в документе "Assigned Numbers" RFC-1700. 4. Транспортное кодирование Транспортное кодирование представляет собой преобразование, применяемое к типам среды MIME после конвертации в каноническую форму. Транспортное кодирование используется в нескольких целях.
Стандартизация большого числа видов транспортного кодирования представляется серьезным барьером для обеспечения совместной работы различных узлов. Несмотря ни на что, определена процедура для обеспечения средств определения дополнительных транспортных кодировок. 4.1. Требования к транспортному кодированию Спецификации транспортного кодирования должны отвечать определенному числу требований, описанных ниже. Каждый тип транспортного кодирования должен иметь уникальное имя. Это имя записывается в поле заголовка Content-Transfer-Encoding и должно согласовываться с его синтаксисом. Все алгоритмы, используемые при транспортном кодировании (напр. преобразование к печатному виду или сжатие) должны быть описаны в спецификациях транспортного кодирования. Использование секретных алгоритмов транспортного кодирования категорически запрещено. Ограничения, накладываемые документом RFC-1602 на стандартизацию патентованных алгоритмов должно непременно учитываться. Все виды транспортного кодирования должны быть применимы для произвольной последовательности октетов, имеющей любую длину. Зависимость от конкретного входного формата не допускается. Не существует требования, чтобы транспортное кодирование приводило к определенному выходному формату. Однако выходной формат каждого транспортного кодирования должен быть исчерпывающе документирован. В частности, каждая спецификация должна ясно объявить, являются ли выходные данные 7-битовыми, 8-битовыми или просто двоичными. Все виды транспортного кодирования должны быть полностью инвертируемыми на любой платформе. Всегда должна иметься возможность преобразовать данные к исходному виду с помощью соответствующей декодирующей процедуры. Заметим, что эти требования исключают все виды сжатия с частичной потерей информации и все виды шифрования в качестве разновидностей транспортного кодирования. Все виды транспортного кодирования должны предоставлять некоторый вид новых функциональных возможностей. 4.2. Процедура определения транспортного кодирования Определение нового вида транспортного кодирования начинается с создания проекта стандартного документа RFC. RFC должен определить транспортное кодирование точно и исчерпывающе и предоставить необходимое обоснование введения этого вида кодирования. Эта спецификация должна быть представлена на рассмотрение IESG. IESG может
4.3. Процедуры IANA для регистрации транспортного кодирования Не существует необходимости для специальной процедуры регистрации транспортного кодирования IANA. Все стандартные транспортные виды кодирования должны быть оформлены в виде RFC, таким образом, ответственность по информированию IANA об одобрении нового вида транспортного кодирования лежит на IESG. 4.4. Размещение списка зарегистрированных видов транспортного кодирования Регистрационные материалы по всем стандартизованным видам транспортного кодирования доступны через анонимное FTP на сервере ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/ . Все зарегистрированные типы транспортного кодирования обязательно заносятся в списки документа "Assigned Numbers" [RFC-1700]. V. Критерии совместимости и примеры Далее рассмотрено, какие части MIME должны поддерживаться MIME-совместимой программной реализацией. 1. Совместимость с MIME Механизмы, описанные в данном разделе являются открытыми для дальнейшего расширения. Не предполагается, что все реализации будут поддерживать все существующие типы среды. Для того чтобы обеспечить наибольшую область применимости полезно определить концепцию "MIME-совместимости", которая позволит обмениваться сообщениями, содержащими данные в формате, отличном от US-ASCII. Почтовый агент пользователя, совместимый с MIME должен:
Текст:
Изображение, аудио и видео:
Применение:
Составное сообщение:
Сообщение:
Есть и другое соображение, почему всегда безопасно посылать данные в формате, согласованным с MIME, ведь такая форма не вступит в конфликт с промежуточными почтовыми серверами, работающими в соответствие со стандартами RFC-821 и RFC-822. Агенты пользователя, которые адаптированы к MIME имеют дополнительную гарантию, что пользователю не будет представлена информация, не воспринимаемая как текст. 2. Базовые моменты при посылке почтовых сообщений Почта в Интернет не совершенная однородная система. Почта может оказаться поврежденной на нескольких этапах ее транспортировки к месту назначения. Почтовое сообщение может проходить через участки среды, использующие различные сетевые технологии. Многие сетевые и почтовые технологии не поддерживают полную функциональность, возможную в рамках протокола SMTP. Почтовое сообщение, проходя через эти среды, может быть модифицировано, для того чтобы решить проблему его передачи адресату. В сети Интернет имеется большое число почтовых агентов, которые в процессе реализации протокола SMTP, модифицируют сообщения на пролете. Следующие соображения могут оказаться полезными любому, кто разрабатывает формат данных (тип среды), который бы сохранялся неповрежденным в любых сетевых средах и для любых почтовых агентов. Заметим, что данные, закодированные в base64, удовлетворяют этим требованиям, а некоторые хорошо известные механизмы, в частности утилита UNIX uuencode, не удовлетворяет. Заметим также, что данные, закодированные с использованием закавыченных последовательностей печатных символов, успешно преодолевают большинство почтовых шлюзов, но могут быть повреждены в системах, которые используют символьный набор EBCDIC.
Заметим, что приведенный выше список не является рекомендацией для почтовых транспортных агентов. В документе RFC-821 не запрещается заменять символы или разрывать длинные строки. Более того, данный список отражает негативную практику для существующих сетей и программные реализации должны быть устойчивы против таких эффектов, с которыми им придется столкнуться. 3. Каноническая модель кодирования Процесс формирования объекта MIME можно смоделировать в виде цепочки последовательных шагов. Заметим, что эти шаги сходны с используемыми в PEM [RFC-1421] и реализуются для каждого "внутреннего" уровня тела сообщения.
Тело, которое подлежит пересылке, формируется в локальном системном формате. При этом используется местный символьный набор и, где возможно, локальное кодирование завершения строки. Тело сообщения может быть текстовым файлом системы UNIX, или растровым изображением, или индексным файлом VMS, или аудио данными в системно зависимом формате, хранящимися в оперативной памяти, или что-то еще, что соответствует локальной модели представления информации.
Все тело, включая вспомогательную информацию, такую как длины записи или атрибуты файлов, преобразуется в универсальную каноническую форму. Специфический тип среды тела также как и его атрибуты определяют природу используемой канонической формы. Преобразование в соответствующую каноническую форму может включать в себя преобразование символьного набора, трансформацию аудио данных, компрессию или различные прочие операции, специфические для данного типа среды. Если реализуется преобразование символьного набора, следует побеспокоиться об адаптации к семантике типа среды, что может оказать существенное влияние на преобразование очень многих символьных наборов. Например, в случае чистого текста, данные должны преобразовываться с использованием поддерживаемого символьного набора, а строки должны завершаться CRLF, как этого требует RFC-822. Заметьте, что ограничения на длины строк, налагаемые RFC-822, игнорируются, если на следующем шаге выполняется кодирование с использованием base64 или закавыченных строк печатных символов.
Применяется подходящее для данного тела транспортное кодирование. Заметим, что не существует жесткой связи между типом среды и транспортным кодированием. В частности, может оказаться вполне приемлемым выбор base64 или закавыченных строк печатных символов.
Закодированное тело вкладывается в объект MIME, снабженный соответствующими заголовками. Объект затем вкладывается в объект более высокого уровня, если это требуется. Преобразование из формата объекта в локальную форму представления производится в обратном порядке. Заметим, что реверсирование этих шагов может вызвать различный результат, так как не существует гарантии, что исходная и оконечная формы окажутся идентичными. Очень важно учесть, что эти шаги являются лишь моделью, а не руководством к тому, как на самом деле следует строить систему. В частности, модель не срабатывает в двух достаточно общих случаях.
Важным аспектом данного обсуждения является то, что несмотря на любые оптимизации или введение дополнительной обработки, результирующее сообщение должно быть совместимым с моделью, описанной здесь. Например, сообщение с полями заголовка: Content-type: text/foo; charset=bar должно быть сначала представлено в форме text/foo, затем, если необходимо, представлено в символьном наборе и, наконец, трансформировано с использованием алгоритма base64 в формат, безопасный для пересылки через любые шлюзы. Некоторые проблемы вызывают почтовые системы, которые для обозначения перехода на новую строку используют нечто отличное от CRLF, принятого в стандарте RFC-822. Важно отметить, что эти форматы не являются каноническими RFC-822/MIME. Заметим также, что форматы, где вместо последовательности CRLF заносится, например, LF не способны представлять сообщения MIME, содержащие двоичные данные с октетами LF, которые не являются частью последовательности CRLF. Приложение A. Сложный пример составного сообщения Данное сообщение содержит пять частей, которые должны быть отображены последовательно: - два вводных объекта чистого текста, встроенное составное сообщение, объект типа text/enriched и завершающее инкапсулированное текстовое сообщение с символьным набором не ASCII типа. Встроенное составное сообщение в свою очередь содержит два объекта, которые должны отображаться в параллель, изображение и звуковой фрагмент. MIME-Version: 1.0 Это область преамбулы составного сообщения. Программы чтения почты, приспособленные для чтения составных сообщений, должны игнорировать эту преамбулу. --unique-boundary-1 [Заметим, что пробел между границей и началом текста в этой части означает, что не было никаких заголовков и данный текст представлен в символьном наборе US-ASCII.] --unique-boundary-1 Это может быть частью предыдущей секции, но иллюстрирует различие непосредственного и неявного ввода текста частей тела. --unique-boundary-1 --unique-boundary-2 Content-Transfer-Encoding: base64 --unique-boundary-2 This is Ссылки
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.14.3 Протокол Интернет для работы с сообщениями IMAP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.17 Введение в MPLS, TE и QoS
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. Базовые предпосылки Интернет - это система взаимодействия удаленных программ. Совместимость этих программ гарантируется тем, что они следуют определенным регламентациям (протоколам). Управление трафиком представляет собой проблему, ставшую актуальной за последние несколько лет (если не считать составляющую, сопряженную с управлением перегрузкой). Период экстенсивного развития сети Интернет завершился несколько лет тому назад даже в РФ. Сейчас многие сервис-провайдеры пытаются привлечь клиентов дополнительными информационными услугами IP-телефония, интерактивные игры, доступ к разнообразным базам данных и депозитариям, электронным магазинам, видеоконференции, видео-телефония и т. д. Клиенты же ищут не просто доступа к Интернет, а интересуются полосой пропускания, безопасностью, стабильностью связи. Именно с этим сопряжен бум разработок основополагающих документов (RFC) в последние 5 лет. По этой причине многие компании, в первую очередь производящие сетевое оборудование, уделяют повышенное внимание средствам управления трафиком (ТЕ) и QoS. Если рассмотреть ситуацию на уровне L2, здесь имеется сильная зависимость от физического уровня (L1). В сетях с маркерным доступом (Token Ring или FDDI, см. book.itep.ru) существуют механизмы управления приоритетом и способы контроля доступа, гарантирующие определенное значение задержек сетевого отклика. В сетях ISDN и в особенности в ATM предусмотрен целый арсенал средств управления, работающих на фазе установления виртуального канала (процедура SETUP). Для Ethernet до последнего времени ситуация была много хуже. Здесь только некоторые переключатели поддерживают VLAN. Технология виртуальных сетей L2 позволяет сформировать в локальной сети соединение точка-точка. В таком соединении можно гарантировать пропускную способность на уровне 10/100Мбит/c. К сожалению VLAN L2 создаются и модифицируются, как правило администратором, но можно эту проблему перепоручить сценарию, например, на PERL, работающему с демоном SNMP сетевого прибора. В такой сети можно также гарантировать низкий уровень разброса времени реакции сети. Если сформировать VLAN с числом узлов (N) больше двух, можно гарантировать полосу лишь не ниже (10/100)/N. Для произвольной сети Ethernet никаких гарантий на уровне L2 предоставить нельзя. Здесь можно рассчитывать только на вышележащие уровни (IP/TCP/UDP). Принципы организации приоритетного трафика на уровне L2 рассмотрены в стандарте 802.1р. Стандарт 802.1р является частью стандарта 802.1D (мостовые соединения). В протоколе 802.1Q определена 4-байта метки (смотри рис.1). Поле EtherType=TPID (Tagged Protocol Identifier) содержит код 0x8100. Это поле соотвествует полю тип протокола стандартного поля кадра Ethernet и указывает на необходимость обработки кадра согласно требованиям IEEE 802.1Q. Смотри grouper.ieee.org/groups/802/1/pages/802.1v.html.
Поле приоритета пользователя - 3 бита, 1-битовое поле CFI (Canonical Format Identifier) и 12-битовое поле VID (идентификатор виртуальной сети) называются TCI (Tagged Control Information). 3-битовое поле IP-приоритета размещается здесь без проблем. После введения метки в кадр нужно персчитать контрольную сумму FCS. Канальный уровень в этом случае должен поддерживать множественные очереди. Добавление метки может привести к превышению предельно допустимой длины кадра (1518 байт). В этой связи IEEE разрабатывает спецификацию 802.3ас, где максимальная длина кадра равна 1522 октета. Группа IETF, разрабатывающая систему обеспечения требуемого уровня услуг на специфических нижних уровнях ISSLL (Integrated Services over Specific Lower Layers), предлагает способы отображения запросов протокола резервирования уровня L3 (RSVP) на 802.1р с помощью системы управления полосой пропускания субсети SBM (Subnet Bandwidth Manager). Смотри http://www.ietf.org/html.charters/issll-charter.html. Протокол SBM предполагает, что одна из станций в субсети выполняет функцию DSBM (Designated SBM), и осуществляет управление доступом для всех запросов на резервирование ресурсов, посылаемых DSBM-клиентами. При работе протокола SBM используются мультикатсинг-адреса 224.0.0.17 (все станции прослушивают этот адрес), а DSBM-кандидаты прослушивают - 224.0.0.16. Данная технология может использоваться, например, в IP-телефонии (TDMoIP - Time Division Multiplexing over IP)). В этом случае UDP-порт отправителя может быть равен 2-497d, а порт получателя = 2142. Топология связей в локальной сети на уровне L3 определяется протоколами маршрутизации (статическими или динамическими - RIP, OSPF, IGRP). В последнее время поставщики сетевого оборудования стали предлагать устройства уровня L2, способные осуществлять отбор пакетов на уровне L3 и даже L4 (TCP/UDP). В принципе ничто не мешает создать сетевые переключатели уровня L2, способные гарантировать пропускную способность, минимизировать вероятность потери пакета и т.д. Любые способы управления трафиком на уровне L3 для сетей, работающих в рамках стека протоколов TCP/IP, в настоящее время базируются на возможностях этих транспортных протоколов (IP, UDP, TCP). Протокол (см. IP) предусматривает задание значение ToS, определяемое соответствующим полем заголовка. Одно-октетное поле тип сервиса (TOS - Type Of характеризует то, как должна обрабатываться дейтограмма. Субполе приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).
0 Обычный уровень В новейших разработках (RFC-2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) поле TOS заменено на поле DSCP (Differentiated Services Code Point), где младшие 6 бит выделены для кода DS (Differentiated Services), а старшие два бита пока не определены и их следует обнулять. До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возрасло. Появилось предложение замены поля TOS на поле DSCP (Differenciated Services Code Point), которое также имеет 8 бит (см. RFC-2474). Смотри рис. 2. Биты CU пока не определены. Иногда это поле называется байтом DS (Differenttiated Services).
Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000.
На базе DSCP разработана технология "пошагового поведения" PHB (per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания. В маршрутизаторах компании CISCO Systems для классификации пакетов и выбора очередей используются два младших бита из трех. По умолчанию классу 0 выделяется 10% полосы, а классам 1, 2 и 3 - 20%, 30% и 40%, соответственно. Для очередей, основанных на классах QoS, пакеты, не принадлежащие ни одной группе, относятся к группе 0 и автоматически получают 1% от общей пропускной способности группы. Общий вес остальных групп не может превышать 99%. При наличии нераспределенной полосы, она относится к группе 0. В протоколе IPv6 поле приоритет имеет 4 бита (см. IPv6). Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. В таблице 1 приведены стандартизованные значения поля Type of Service (TOS) IP-пакета. Таблица .1. Значения TOS для разных протоколов (DTRC)
Помимо перечисленных значений может рассматриваться значение " Максимальная безопасность ". Строго говоря, значения TOS и QOS не эквивалентны, но именно значение ToS является базой для задания QoS. Присваивая при формировании IP-пакета определенное значение поля ToS, прикладная программа может попытаться реализовать определенные ограничения на QoS. Это поле может анализироваться маршрутизаторами, которые поддерживают протокол RSVP. В протоколе UDP нет никаких механизмов управления трафиком. Кое-что предлагает набор протоколов RTP/RTCP, предназначенный для мультимедийных приложений (например, позволяет ликвидировать влияние разброса времени доступа в каналах Ethernet на качество воспроизведения изображения и звука.). Некоторые приложения и сетевые приборы способны сигнализировать о перегрузке (потере пакетов из-за переполнения буферов), посылая ICMP(4). Протокол (смотри TCP) имеет в заголовке 6-битовое поле флаги (значения представлены в таблице 2). Значения битов флаги предоставляет дополнительные возможности управления. Таблица 2. Значения бит поля флаги
Указанные выше поля заголовков представляют собой основу существующих методов управления трафиком. Конечно, можно использовать и поля данных, но для этого нужно, чтобы это стало международным стандартом. Существенную проблему составляет необходимость идентифицировать пакеты, принадлежащие определенному процессу. Эта задача легко решается только в рамках протокола IPv6. Там в заголовке предусмотрено поле метка потока. Некоторые возможности предоставляет также протокол MPLS. 2. Управление трафиком В настоящее время используется несколько методов управления трафиком: 1. Динамическая маршрутизация (RIP, OSPF, IGRP, BGP) и т.д.). Здесь нет средства резервирования полосы, но имеется механизм изменения маршрута при изменении значений метрики или из-за выхода из строя узла или обрыва канала. Некоторые из таких протоколов (OSPF, IGRP) могут строить отдельные таблицы маршрутизации для каждого уровня TOS/QOS [1], но метрики для каждого уровня задаются сетевым администратором. Здесь имеется возможность запараллеливания потоков с целью увеличения пропускной способности. Эти протоколы работают только в пределах одной автономной системы (AS). Протокол же BGP, используемый для прокладки путей между автономными системами не способен как-либо учитывать уровень TOS/QOS (использует алгоритм вектора расстояния, что связано с трудностью согласования значений метрик состояния канала администраторами разных AS). Новая версия многопротокольного расширения MP-BGP специально создана для совместной работы с MPLS при формировании виртуальных сетей, но и он безразличен к TOS/QOS. 2. Формирование виртуальных сетей на уровнях L2 и L3. Протоколы VLAN обеспечивают повышенный уровень безопасности, но не способны резервировать полосу. К этому типу относится и протокол MPLS. 3. Резервирование полосы в имеющемся виртуальном канале (протокол RSVP). RSVP может работать с протоколами IPv4 и IPv6. Протокол достаточно сложен для параметризации, по этой причине для решения этой задачи был разработан протокол COPS, который существенно облегчает параметризацию. Функция COPS сходна с задачей языка RPSL для маршрутизации. 4. Автоматическое резервирование полосы при формировании виртуального канала процедурой SETUP в сетях ATM, ISDN, DQDB, Frame Relay и т.д. Управления очередями осуществляется аппаратно, но базовые параметры могут задаваться программно. Программы управления трафиком MPLS позволяют расширяют возможности L2 сетей ATM и Frame Relay. 5. Использование приоритетов в рамках протокола IPv6. Возможность присвоения потокам меток облегчает, например, разделение аудио- и видеоданных. 6. Управление перегрузкой (окно перегрузки в TCP, ICMP(4) для UDP-потоков (ICMP L2 и т.д.). 3. Качество обслуживания QoS QoS связана с возможностью сети предоставить клиенту необходимый ему уровень услуг в условиях работы поверх сетей с самыми разнообразными технологиями, включая Frame Relay, ATM, Ethernet, сети 802.1, SONET, и маршрутизуемые IP-сети. QoS представляет собой собрание технологий, которые позволяют приложениям запрашивать и получать предсказуемый уровень услуг с точки зрения пропускной способности, временного разброса задержки откликa, а также общей задержки доставки данных. В частности, QoS подразумевает улучшение параметров или достижение большей предсказуемости предоставляемых услуг. Это достигается следующими методами:
IEFT определяет для QoS следующие две архитектуры:
IntServ для явного задания уровня услуги (QoS) использует протокол RSVP. Это делается путем уведомления об этом требовании всех узлов вдоль пути обмена. Если все сетевые устройства вдоль пути могут предоставить запрошенную полосу, резервирование завершается успешно (смотри документ RFC-1633 [2]). DiffServ, вместо того чтобы уведомлять о требованиях приложения, использует в IP-заголовке DiffServ Code Point (DSCP), чтобы указать требуемые уровни QoS. Cisco IOS ╝ Software Release 12.1(5)T вводит совместимость маршрутизаторов Cisco c DiffServ (см. [15-16]). DSCP размещается в поле TOS IP-пакета. В таблице 3 представлены различные виды использования QoS.
Управление перегрузкой может осуществляться путем изменения порядка, в котором посылаются пакеты согласно приписанного им приоритету. QoS-управление перегрузкой имеет четыре модификации протоколов управления очередями, каждый из которых позволяет организовать разное число очередей. L2 QoS предполагает следующее: 1. Управление входными очередями: когда кадр приходит на вход порта, он может быть отнесен к одной из нескольких очередей, ассоциированных с портом, прежде чем он будет направлен на один из выходных портов. Обычно, несколько очередей используются тогда, когда различные информационные потоки требуют различных уровней услуг или минимизации задержки. Например, IP мультимедиа требует минимизации задержки, в отличие от передачи данных в FTP, WWW, email, Telnet>, и т.д. 2. Классификация: процесс классификации включает просмотр различных полей в заголовке Ethernet L2, а также полей IP-заголовка (уровень 3 - L3) и заголовков TCP/UDP (уровень 4 - L4), чтобы обеспечить определенный уровень услуг при коммутации пакетов. 3. Политика: осуществление политики является процессом анализа кадра Ethernet, чтобы определить, не будет ли превышен заданный уровень трафика за определенный интервал времени (обычно, это время является внутренним параметром переключателя). Если кадр создает ситуацию, при которой трафик превысит заданный уровень, он будет отброшен. Или значение CoS (Class of Service) может быть понижено. 4. Перепись: процесс переписи предоставляет возможность переключателю модифицировать CoS в заголовке или ToS (Type of Service) в IPv4-заголовке. Следует учесть, что заголовок Ethernet 802.3 поля CoS не имеет (именно эта версия стандарта наиболее распространена в РФ). 5. Управление выходными очередями: после процесса перезаписи переключатель поместит кадр Ethernet, в выходную очередь для последующей коммутации. Переключатель выполнит управление буфером так, чтобы не произошло переполнение. Это обычно осуществляется с помощью алгоритма RED (Random Early Discard), когда некоторые кадры случайным образом удаляются из очереди. Weighted RE (WRED) является директивой RED (используемой некоторыми модулями семейства Catalyst 6000), где значения CoS анализируются с целью определения того, какие кадры следует отбросить. Когда буферы окажутся заполнены до определенного уровня, кадры с низким уровнем приоритета отбрасываются, в очереди сохраняются только высокоприоритетные кадры. 4. Мультипротокольная коммутация меток (протокол MPLS) Основы протокола MPLS описаны в официальных документах RFC [3-9 и 14]. Существуют публикации и на русском языке [11-13]. Имеются три монографии, посвященных рассматриваемой проблематике [17-19]. Протокол MPLS хорошо приспособлен для формирования виртуальных сетей (VPN) повышенного быстродействия (метки коммутируются быстрее, чем маршрутизируются пакеты). Принципиальной основой MPLS являются IP-туннели. Для его работы нужна поддержка протокола маршрутизации MP-BGP (RFC-2858 [23]). Протокол MPLS может работать практически для любого маршрутизируемого транспортного протокола (не только IP). После того как сеть сконфигурирована (для этого используются специальные, поставляемые производителем скрипты), сеть существует, даже если в данный момент через нее не осуществляется ни одна сессия. При появлении пакета в виртуальной сети ему присваивается метка, которая не позволяет ему покинуть пределы данной виртуальной сети. Никаких других ограничений протокол MPLS не накладывает. Протокол MPLS предоставляет возможность обеспечения значения QoS, гарантирующего более высокую безопасность. Не следует переоценивать уровня безопасности, гарантируемого MPLS, атаки типа "человек посередине" могут быть достаточно разрушительны. При этом для одного и того же набора узлов можно сформировать несколько разных виртуальных сетей (используя разные метки), например, для разных видов QoS. Но можно использовать возможности АТМ (процедура setup), если именно этот протокол применен в опорной сети (возможные перегрузки коммутаторов не в счет). Для обеспечения структурирования потоков в пакете создается стек меток, каждая из которых имеет свою зону действия. Формат стека меток представлен на рис. 3 (смотри RFC-3032). В норме стек меток размещается между заголовками сетевого и канального уровней (соответственно L2 и L 3). Каждая запись в стеке занимает 4 октета.
Рис. 3. Формат стека меток Место заголовка МАС может занимать заголовок РРР. В случае работы с сетями АТМ метка может занимать поля VPI и VCI. Смотри рис 4. Глубина стека в данном случае не может превышать 1.
Рис. 4. Формат меток в ячейках АТМ На рисунке полю СoS соответствует субполю приоритет поля ToS. Поле CoS имеет три бита, что достаточно для поля приоритета IP-заголовка. 6-битовое поле кода дифференцированной услуги DSCP сюда записать нельзя. Можно попробовать разместить этот код в поле самой метки. S - флаг-указатель дна стека меток; TTL - время жизни пакета MPLS. Существующие версии программного обеспечения Cisco IOS (например, Cisco IOS Release 12.0) содержат набор средств управления трафиком. В частности, имеется возможность формировать статические маршруты и управлять динамическими маршрутами путем манипулирования значениями метрики . Иногда этого вполне достаточно, но в большинстве случаев провайдер нуждается в более эффективных средствах. Межрегиональные каналы являются одной из основных расходных статей провайдеров. Управление трафиком позволяет IP-провайдеру предложить оптимальный уровень услуг своим клиентам с точки зрения полосы и задержки. Одновременно эта технология снижает издержки обслуживания сети. MPLS представляет собой интеграцию технологий уровней L2 и L3. Управление трафиком в MPLS реализуется путем предоставления традиционных средств уровня L2 уровню L3. Таким образом, можно предложить в односвязной сети то, что достижимо только путем наложения уровня L3 на уровень L2. Управление коммутацией по меткам основывается на базе данных LIB (Label Information Base). Пограничный маршрутизатор MPLS LER (Label Edge Router) удаляет метки из пакетов, когда пакет покидает облако MPLS, у вводит их во входящие пакеты. Схема работы с помеченными и обычными IP-пакетами показана на рис. 5.
Рис. 5. Обработка помеченных и обычных IP-пакетов Управление трафиком MPLS автоматически устанавливает и поддерживает туннель через опорную сеть, используя возможности RSVP. Путь, используемый данным туннелем в любой момент времени определяется на основе ресурсных требований и сетевых возможностей, таких как полоса пропускания. В самом ближайшем будущем MPLS сможет решать проблему обеспечения требуемого уровня QoS и самостоятельно. Информация об имеющихся ресурсах доводится до сведения заинтересованных субъектов с помощью протокола IPG (Interior Protocol Gateway), алгоритм которого базируется на состоянии канала. Путь туннеля вычисляется, основываясь на сформулированных требованиях и имеющихся ресурсах (constraint-based routing). IGP автоматически маршрутизирует трафик через эти туннели. Обычно, пакет, проходящий через опорную сеть MPLS движется по одному туннелю от его входной точки к выходной. Управление трафиком MPLS основано на следующих механизмах IOS:
Одним из подходов управления опорной сетью является определение сети туннелей между всеми участниками обменов. Протокол IGP, работающий в начале туннеля, определяет то, какой трафик должен проходить через любой оконечный узел. Модули вычисление пути и управления MPLS определяют маршрут LSP туннеля. Для каждого туннеля подсчитывается число пропущенных пакетов и байт. Иногда, поток настолько велик, что его нельзя пропустить через один канал (туннель). В этом случае может быть создано несколько туннелей между отправителем и получателем. Для реализации MPLS управления трафиком сеть должна поддерживать следующие возможности Cisco IOS:
Дополнительные данные о MPLS и управлении трафиком можно найти в документации Cisco (поддерживается в реализациях 7620, 7640, 7200, 7500 и 12000):
Протоколы состояния канала типа IS-IS для вычисления кратчайшего пути для всех узлов сети используют алгоритм Дикстры SPF. Маршрутные таблицы получаются на основе дерева кратчайших путей. Эти таблицы содержат упорядоченный набор адресов места назначения и информацию о ближайших соседей. Если маршрутизатор осуществляет прокладку путей на основе алгоритма шаг-за-шагом, первым шагом является физический интерфейс, соединенный с маршрутизатором. Новые алгоритмы управления трафиком вычисляют пути до одного или более узлов в сети. Эти маршруты рассматриваются как логические интерфейсы исходного маршрутизатора. В данном контексте эти маршруты представляют собой LSP и рассматриваются как TE-туннели. Эти TE-туннели являются реальными маршрутами, контролируемыми маршрутизаторами, которые размещены в начале этих туннелей. В отсутствии ошибок TE-туннели гарантируют отсутствие петель, но маршрутизаторы должны согласовать использование TE-туннелей. Иначе могут стать возможными зацикливания двух или более таких туннелей. Вероятность возникновения такой ситуации незначительна, так как трасса туннеля определяется отправителем. Управление трафиком MPLS:
В рекомендациях CISCO [15] можно прочесть, что MPLS позволяет провайдеру маршрутизировать потоки данных так, чтобы клиенту гарантировать минимум задержки и максимум пропускной способности. Сформировав несколько виртуальных сетей для заданного набора узлов, можно попытаться объединять возможности этих сетей в случае возникновения такой необходимости, увеличивая пропускную способность. Можно для каждой из субсетей использовать разный уровень QoS с помощью протокола RSVP. Рассмотрение описания конфигурации MPLS в аппаратах CISCO [15] показывает отсутствие возможности задания какого-либо значения QoS. Но это не означает, что этого не будет возможно уже в 2003 году. 5. Протокол резервирования ресурсов RSVP Если сетевые условия позволяют, то, используя протокол RSVP (где QoS задается в спецификации потока ( flowspec ) - практически на сегодня это единственное реализуемое решение), можно попытаться зарезервировать для заданной виртуальной сети определенное значение полосы пропускания. Следует иметь в виду, что протокол RSVP приспособлен в основном для резервирования определенного значения полосы пропускания, а не произвольного QoS (спецификации QoS см. в RFC-2210, 2211 и 2212) для существующего виртуального соединения. Если виртуальное соединение разорвано, следом ликвидируются и все резервирования. Следует, разумеется, иметь в виду, что >RSVP может работать как c TCP- так и c UDP-сессиями поверх IPv4 и IPv6. Сессия резервирования инициируется получателем данных. Резервирование может осуществляться как для уникаст, так и мультикаст-потоков. Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205; http://book.itep.ru/4/44/Rsv_4496.htm; смотри также RFC-2206-10, -2490, -2745-47, -2750-52, -2872, -2961, -2996, -3097, -3175, -3181, -3209-10) определяет режим резервирования (способ объединения нескольких заявок для одного и того же интерфейса: WF, FF, SE), формирования резервирования и его поддержания в условиях отсутствия поддержки данного протокола в одном или нескольких узлах виртуального пути, пересылки QoS-запросов другим маршрутизаторам и т.д., но решения принимаются маршрутизатором локально без знания условий в остальной части пути. По этой причине здесь не может идти речь о минимизации задержки, обеспечении надежности или безопасности, хотя в перспективе это может стать возможным. Следует учитывать, что инициатором резервирования в RSVP всегда является клиент (именно он посылает первичные запросы). По этой причине могут возникнуть проблемы при попытке централизованного управления QoS посредством RSVP. RSVP не имеет механизмов управления очередями в конкретных интерфейсах, а механизм резервирования полосы пропускания для одного из направлений обмена является зоной ответственности изготовителя маршрутизатора и не публикуется. Кроме того, при скоростях несколько сот Мбит/с часто обработка процедур буферизации перепоручается аппаратным средствам (например, в случае компании CISCO). ╥ RSVP выполняет резервирование для уникастных и мультикастных приложений, динамически адаптируясь к изменениям членства в группе вдоль маршрута. ╥ RSVP является симплексным протоколом, т.е., он выполняет резервирование для однонаправленного потока данных. ╥ RSVP ориентирован на получателя, т.е., получатель данных инициирует и поддерживает резервирование ресурсов для потока. ╥ RSVP поддерживает динамическое членство в группе и автоматически адаптируется к изменениям маршрутов. ╥ RSVP не является маршрутным протоколом, но зависит от существующих и будущих маршрутных протоколов. ╥ RSVP транспортирует и поддерживает параметры управления трафиком и политикой, которые остаются непрозрачными для RSVP. ╥ RSVP обеспечивает несколько моделей резервирования или стилей, для того чтобы удовлетворить требованиям различных приложений. ╥ RSVP обеспечивает прозрачность операций для маршрутизаторов, которые его не поддерживают. ╥ RSVP может работать с IPv4 и IPv6. Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме. Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров: 1. "Rspec", который определяет желательное значение QoS, и 2. "Tspec", который описывает информационный поток. Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC 2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP). Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы. 1. Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC 2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP. 2. IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов. Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6. 3. IP-уровень безопасности как для IPv4, так и IPv6 может шифровать весь транспортный заголовок, скрывая номера портов промежуточных маршрутизаторов. Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации. Процесс RSVP проходит стадии проверки допуска и политики. Если какой-либо тест не прошел, резервирование отвергается и посылается сообщение об ошибке. Если все тесты прошли успешно, узел устанавливает классификатор пакетов, для того чтобы отбирать пакеты, указанные в спецификации фильтра. Далее устанавливается контакт с соответствующим канальным уровнем для получения желательного QoS, заданного в flowspec. Для простой выделенной линии, желаемый QoS будет получен с помощью диспетчера пакетов в драйвере канального уровня. Если технология канального уровня поддерживает свои средства управления QoS, тогда RSVP должен согласовать с канальным уровнем получение требуемого QoS. Когда получатель данных отправляет запрос резервирования, он может запросить также присылку сообщения, подтверждающего резервирование. Процесс резервирования распространяется от получателей к отправителям, от узла к узлу. В каждом узле требования резервирования объединяются и сопоставляются с имеющимися возможностями. Это продолжается до тех пор, пока запрос не достигнет отправителя или пока не возникнет конфликт перегрузки. В результате получатель данных, направивший запрос резервирования, получит сообщение об успехе или ошибке. Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования. Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии. Другая опция резервирования контролирует выбор отправителей. В одних случаях каждому отправителю ставится в соответствие определенная спецификация фильтра, в других - таких спецификаций не требуется вовсе. В настоящее время определены следующие стили: ╥ Стиль WF (Wildcard-Filter) Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая "труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении. ╥ Стиль FF (Fixed-Filter) Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии. ╥ Стиль SE (Shared Explicit) Стиль SE использует опции: "разделенное" (shared) резервирование и "явный" explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей. Для облегчения работы с RSVP разработан протокол COPS (Common Open Policy Service; RFC-2748, The COPS Protocol, D. Durham, Ed. Смотри также RFC-2749, -2940 и -3084). Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике. Предполагается, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [27-28]. Смотри также http://book.itep.ru/4/4/cops.htm В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении. При работе с АТМ ситуация ненамного лучше, программное обеспечение АТМ-коммутаторов также обычно не доступно. Но имеется возможность работы RSVP поверх АТМ [29-31]. Рассматривается внедрение протокола RSVP на уровень L2 [34]. При наличии механизмов реализации других типов QoS (смотри, например, RFC-2430 [21] и Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", где предлагается ввести дополнительные биты в заголовок), можно решить проблему в более общем виде (но эта технология находится лишь на стадии обсуждения и не внедрена ни на одном серийном приборе). В рамках одной автономной системы (AS), где используется внутренний протокол маршрутизации OSPF>, можно обеспечить требуемый уровень QoS, но это будет делаться вручную, во всяком случае, на уровне задания значений метрики. Теоретически можно это сделать и автоматически, например, в случае применения версии протокола IGRP (внутренний протокол компании CISCO), поддерживающего автоматическую оценку значений метрики. К сожалению, компания CISCO отошла от первоначального плана и значения метрики там задается в настоящее время также администратором. Реализация управления QoS предполагает организацию эффективной системы мониторинга базовых параметров, характеризующих требуемый уровень QoS. Для этого требуется контролировать уровень информационных потоков во всех фрагментах VPN, постоянно измерять значение RTT и его дисперсии, контролировать уровень вероятности потери пакетов во всех фрагментах виртуального пути. Желательно также отслеживать корреляции перечисленных параметров и локального значения загрузки. Схема мониторинга и управления QoS показана на рис. 6.
Управляющее воздействие может осуществляться с помощью скриптов или с привлечением механизмов политик. В любом случае нужно позаботиться об исключении влияния случайных флуктуаций результатов измерений. Выводы1. Для сетей TCP/IP основным инструментом управления QoS пока является протокол RSVP (это касается и MPLS). 2. Протокол MPLS является удобным средством формирования корпоративных сетей (VPN), которые позволяют поднять их безопасность. 3. Для обеспечения работы MPLS необходима поддержка протоколов IS-IS и MP-BGP всеми маршрутизаторами VPN. 4. Протокол MPLS предоставляет гибкие средства мониторинга трафика в пределах VPN. 5. Технология управления трафиком ТЕ предполагает совмещение возможностей протоколов уровней L2 и L3. 6. Протокольных средств управления очередями в Ethernet или в TCP/IP не существует. Такие средства имеются вATM-коммутаторах, ограниченные возможности имеются в некоторых маршрутизаторах CISCO и в коммутаторах L2 (например, выбор между режимами store-and-forward и cut through и т.д.). В любом случае такие режимы конфигурируются администратором индивидуально для каждого сетевого устройства. Разумеется, что-то можно сделать с помощью протокола SNMP дистанционно, если имеется пароль доступа ( community). 7. Переход на IPv6 существенно расширяет возможности управления трафиком за счет использования меток потоков (пока не ясно насколько эта возможность поддерживается программно). Данное свойство особенно важно для передачи мультимедийных данных, например, программ цифрового телевидения. Последнее предполагает значительное расширение интегральной полосы каналов опорной сети (хотя бы до 155Мбит/ c). 8. Все выше сказанное отражает ситуацию сегодняшнего дня, когда не стандартизовано дополнительных средств управления трафиком и QoS. Положение может измениться, если будут, например, стандартизованы какие-то дополнительные атрибуты потоков (как это было сделано при введении меток для VPN). Такие работы уже ведутся (см. [3]) 9. Возможности, заложенные в протоколе MPLS, предполагают определенный уровень сотрудничества между администраторами узлов, образующих VPN. Библиография
J. Wroclawski. RFC-2210, The Use of RSVP with IETF Integrated Services. September 1997. L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205. September 1997. Bates, Y. Rekhter, R., Chandra, D. Katz. Multiprotocol Extensions for BGP-4. RFC-2858. June 2000. J. Wroclawski. RFC-2211. Specification of the Controlled-Load Network Element Service. September 1997. S. Shenker. RFC-2212. Specification of Guaranteed Quality of Service. September 1997. D. Durham, Ed. RFC-2748. The COPS (Common Open Policy Service) Protocol. January 2000. Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC-2753, January 2000. L. Berger. RFC-2379. RSVP over ATM Implementation Guidelines. August 1998. L. Berger. RFC-2380. RSVP over ATM Implementation Requirements. August 1998. E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. RFC-2382. A Framework for Integrated Services and RSVP over ATM. August 1998. S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. RFC-2749 COPS usage for RSVP. January 2000. S. Herzog. RFC-2750. RSVP Extensions for Policy Control. January 2000. R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. RFC-2814. SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks. May 2000. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. RFC-3175. Aggregation of RSVP for IPv4 and IPv6 Reservations. September 2001. D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. RFC-3209. RSVP-TE: Extensions to RSVP for LSP Tunnels. December 2001. A. Smith, D. Partain, J. Seligson. RFC-2940. Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. October 2000. K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. RFC-3084. COPS Usage for Policy Provisioning (COPS-PR). March 2001. Максим Кульгин. Контроль трафика в сетях ATM. LAN/Журнал Сетевых решений #12/98 Алексей Лукацкий. Неизвестная VPN. http://abn.ru/inf/compress/network4.shtml http://www.cisco.com.ru/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/te120_7t.pdf (управление трафиком - ТЕ) Мультипротокольная коммутация по меткам (MPLS). http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt3/xcftagc.pdf http://www.tt.ru/?do=stech2&id=740 ("ТрансТелеКом", обзоры на русском) http://www.mplsforum.org (Оффициальная страница группы разработчиков MPLS). IP-Datentransport ist nur der Anfang. Wilhelm Greiner, LANline 10/2002, стр. 110-115; Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment; RFC-3353, D. Ooms, August 2002. Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks; RFC-3443, P. Agarwal, January 2003. Framework for Multi-Protocol Label Switching (MPLS)-based Recovery; RFC-3469, V. Sharma, February 2003. Generalized Multi-Protocol Label Switching (GMPLS)Signaling Functional Description; RFC-3471, L. Berger, January 2003. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions; RFC-3472, P. Ashwood-Smith, January 2003. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions; RFC-3473, L. Berger, January 2003. Graceful Restart Mechanism for Label Distribution Protocol; RFC-3478, M. Leelanivas, February 2003. Fault Tolerance for the Label Distribution Protocol (LDP); RFC-3479, A. Farrel, February 2003. Шринивас Вегешна, "Качество обслуживания в сетях IP", Cisco Press, 2003. Definition of the Differentiated Services Field (DS Field)in the IPv4 and IPv6 Headers; RFC-2474, K. Nichols, December 1998. Assured Forwarding PHB Group; RFC-2597,, J. Heinanen, June 1999. Multiprotocol Label Switching (MPLS) www.ietf.org/html.charters/mpls-charter.html Jim Guichard, Ivan Pepelnjak, "MPLS and VPN Architectures", Cisco Press, 2001 A QoS Engineering Architecture for the Next-Generation-Internet |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.16 Протокол SNTP
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
(E. Rosen. Multiprotocol Label Switching Architecture, RFC-3031.)
1. Введение в MPLS
В данном документе специфицирована архитектура многопротокольной коммутации меток (MPLS).
1.1. Обзор
Поскольку пакеты в случае протокола сетевого уровня без установления соединения переносятся от одного маршрутизатора к другому, каждый из них совершенно независим в принятии решения переадресации. То есть, каждый маршрутизатор анализирует заголовок пакета и каждый маршрутизатор реализует алгоритм маршрутизации сетевого уровня. Маршрутизатор независимо выбирает следующий шаг для пакета, основываясь на результатах анализа его заголовка и результата работы маршрутного алгоритма. Заголовки пакета содержат значительно больше информации, чем нужно для выбора следующего шага. Выбирая следующий шаг можно, следовательно, выполнять две процедуры. Первая делит весь набор пакетов на классы FEC (Forwarding Equivalence Classes). Вторая ставит в соответствие каждому FEC следующий шаг маршрута. В той части, которая касается переадресации, разные пакеты, поставленные в соответствие определенному FEC, не различимы. Все пакеты, которые принадлежат определенному FEC, и которые отправлены из конкретного узла будут следовать одним и тем же путем (или в случае многомаршрутного протокола, они будут следовать через один и тот же набор путей, ассоциированный с FEC).
При обычной IP переадресации, маршрутизатор рассматривает два пакета принадлежащими к одному FEC, если существует адресный префикс X в таблицах маршрутизации маршрутизатора, такой что Х, соответствует каждому адресу места назначения. Когда пакет проходит через сеть, на каждом шагу пакет последовательно просматривается и ему присваивается FEC.
В MPLS присвоение пакету определенного FEC делается только раз, когда пакет входит в сеть. FEC, к которому приписан пакет, кодируется, как код фиксированной длины, называемый меткой. Когда пакет переадресуется на следующем шагу, метка посылается вместе с ним, так что пакеты оказываются помечены, до того, как будут переадресованы.
При последующих шагах не производится никакого анализа заголовков пакетов сетевого уровня. Здесь для индексации следующего шага и новой метки используется присвоенная ему на входе метка. Старая метка замещается новой и пакет переадресуется в следующий узел.
В парадигме переадресации MPLS, поскольку пакет приписан определенному FEC, никакого последующего анализа заголовков в маршрутизаторах по пути следования не производится, а переадресация управляется исключительно на основе меток. Это имеет много преимуществ перед традиционной маршрутизацией на сетевом уровне.
- MPLS-переадресация может быть выполнена переключателями, которые способны осуществлять просмотр меток и их замещение, но не могут анализировать заголовки сетевого уровня (во всяком случае с достаточной скоростью).
- Так как пакет поставлен в соответствие определенному FEC, когда он входит в сеть, входной маршрутизатор может использовать при определении соответствия любую информацию, которую он имеет о пакете, даже если такая информация не может быть извлечена из заголовка сетевого уровня. Например, пакеты, приходящие через разные порты, могут быть связаны с разными FEC. Традиционная переадресация может рассматривать только информацию, которая транспортируется внутри пакета в его заголовке.
- Пакет, который входит в сеть через определенный маршрутизатор, может быть помечен иначе, чем такой же пакет, вошедший в сеть через другой маршрутизатор, и в результате решение о переадресации зависит от входного маршрутизатора и может быть легко осуществлено. Это не может быть сделано традиционной переадресацией, так как идентичность входного маршрутизатора не путешествует вместе с пакетом.
- Соображения, которые определяют то, как пакету ставится в соответствие FEC, могут становиться даже более сложными, без каких-либо последствий для маршрутизаторов, которые просто переадресуют помеченные пакеты.
- Иногда желательно заставить пакеты следовать определенным маршрутом, который выбран перед входом или во время входа пакета в сеть, вместо следования нормальному динамическому протоколу маршрутизации. Это может быть сделано в соответствии с разной политикой, или с привлечением техники управления трафиком. При традиционной переадресации это требует, чтобы пакет нес в себе информацию о маршруте, по которому он должен двигаться (маршрутизация отправителя). В MPLS, метка может использоваться для представления маршрута, так что идентичность маршрута не переносится вместе с пакетом.
Некоторые маршрутизаторы анализируют заголовок пакета сетевого уровня не только с целью выбора следующего шага, но и для определения приоритета и класса услуг. Они могут затем применить различные пороги отсева или графика обслуживания пакетов. MPLS допускает (но не требует) приоритетность или класс обслуживания, зависящие полностью или частично от метки. В этом случае, можно сказать, что метка представляет собой комбинацию FEC, приоритета или класса обслуживания. В MPLS "Multiprotocol" означает многопротокольный, так как его техника применима к любому протоколу сетевого уровня. В данном документе, однако, внимание сконцентрировано на использовании IP в качестве протокола сетевого уровня. Маршрутизатор, который поддерживает MPLS, называется "Label Switching Router", или LSR (маршрутизатором с коммутацией по меткам).
1.2. Терминология
| DLCI |
Метка, используемая в сетях Frame Relay для идентификации схем frame relay. |
|
forwarding equivalence class (FEC) |
Группа IP-пакетов, которые переадресуются каким-то образом (например, по тому же маршруту, с той же маршрутной обработкой) |
|
frame merge -
|
Слияние меток, когда это применяется к операциям в среде, базирующейся на кадрах (frame based), так что потенциальная проблема перекрытия ячеек не является проблемой. |
|
Label - Метка |
Идентификатор фиксированной длины, который используется для идентификации FEC, обычно имеет локальное значение. |
|
label merging -
|
Замещение множественных приходящих меток для определенного FEC с одной выходной меткой |
|
label swap - |
Базовая операция переадресации, состоящая из просмотра входной метки с целью определения выходной метки, инкапсуляции, порта и другой информации, сопряженной с обработкой поступающих данных. |
|
label swapping |
Парадигма переадресации, позволяющая осуществлять переадресацию данных путем использования меток для идентификации классов информационных пакетов, которые обрабатываются при переадресации неразличимым образом. |
|
label switched hop |
Шаг между двумя узлами MPLS, на которые осуществляется переадресация с привлечением меток. |
|
label switched path - путь с коммутацией меток |
Путь через один или более LSR на одном уровне иерархии для пакетов в определенном FEC. |
|
label switching router |
Узел MPLS, который способен переадресовывать пакеты L3 согласно их меткам |
|
layer 2- |
Протокольный уровень, ниже уровня 3 (который, следовательно, предлагает услуги уровню 3). Переадресация с использованием меток, происходит на уровне 2 вне зависимости от того, являлась ли рассмотренная метка ATM VPI/VCI, frame relay DLCI или метка MPLS. |
|
layer 3 -
|
Протокольный уровень, на котором IP и ассоциированные с ним протоколы маршрутизации взаимодействуют с канальным уровнем 2. |
|
loop detection -
|
Метод, при котором разрешено формирование петлевых маршрутов, такие структуры позднее выявляются |
|
loop prevention -
|
Метод, при котором данные никогда не передаются по петлевым маршрутам |
|
label stack - стек меток |
Упорядоченный набор меток |
|
merge point |
Узел, в котором произведено объединение меток |
|
MPLS domain -
|
Непрерывный набор узлов, реализующих MPLS -маршрутизацию и находящихся в одном маршрутном и административном домене. |
|
MPLS edge node -
|
Узел MPLS, который соединяет MPLS-домен с узлом, находящимся вне домена, потому что он не поддерживает MPLS, и/или из-за того, что он размещен в другом домене. Заметим, что если LSR имеет соседнюю ЭВМ, которая не работает с MPLS, тогда этот LSR является пограничным узлом MPLS. |
|
MPLS egress node -
|
Пограничный узел MPLS, если через него трафик выходит из домена MPLS |
|
MPLS ingress node - входной узел MPLS |
Пограничный узел MPLS, если через него трафик входит в домен MPLS |
|
MPLS label -
|
Метка, которая содержится в заголовке пакета и которая представляет FEC пакета |
|
MPLS node -
|
Узел, поддерживающий протокол MPLS. Узел MPLS распознает протоколы управления MPLS, реализует один или более протоколов маршрутизации L3, и способен переадресовывать пакеты на основе меток. Узел MPLS может опционно переадресовывать L3 пакеты в традиционном режиме. |
|
MultiProtocol Label Switching |
Рабочая группа IETF и разработки данной группы |
|
network layer - сетевой уровень |
Синоним уровня 3 |
|
stack |
Синоним стека меток |
|
switched path |
Синоним пути с коммутацией меток |
|
virtual circuit -
|
Схема, используемая технологией обмена с установлением соединения на уровне 2, такой как ATM или Frame Relay, требующая поддержки статусной информации в переключателях уровня 2. |
|
VC merge -
|
Объединение меток, когда метка MPLS переносится в поле ATM VCI (или в комбинации полей VPI/VCI), чтобы позволить объединение нескольких VC в один VC |
|
VP merge -
|
Объединение меток, когда метка MPLS переносится в поле ATM VPI, чтобы позволить объединение нескольких VP в один VP. В этом случае две ячейки будут иметь одно и то же значение VCI, только если отправлены из одного узла. Это позволяет различать ячейки разных отправителей с помощью VCI. |
|
VPI/VCI |
Метка, используемая в сетях ATM для идентификации схем |
1.3. Акронимы и аббревиатуры
ATM Asynchronous Transfer Mode - асинхронный режим передачи
BGP Border Gateway Protocol - протокол внешней маршрутизации
DLCI Data Link Circuit Identifier - идентификатор канала передачи данных
FEC Forwarding Equivalence Class - класс переадресации
FTN FEC to NHLFE Map - соответствие FEC и NHLFE
IGP Interior Gateway Protocol - внутренний протокол маршрутизации
ILM Incoming Label Map - таблица соответствия входящих меток
IP Internet Protocol - протокол Интернет
LDP Label Distribution Protocol - протокол пересылки меток
L2 Layer 2 - уровень 2
L3 Layer 3 - уровень 3
LSP Label Switched Path - путь с коммутацией меток
LSR Label Switching Router - маршрутизатор c коммутацией меток
MPLS MultiProtocol Label Switching - многопротокольная коммутация меток
NHLFE Next Hop Label Forwarding Entry - запись, содержащая адрес следующего шага при коммутации меток
SVC Switched Virtual Circuit - переключаемая виртуальная схема
SVP Switched Virtual Path - переключаемый виртуальный путь
TTL Time-To-Live - время жизни
VC Virtual Circuit - виртуальная схема
VCI Virtual Circuit Identifier - идентификатор виртуальной схемы
VP Virtual Path - виртуальный путь
VPI Virtual Path Identifier - идентификатор виртуального пути.
2. Основы MPLS
В этом разделе, вводятся некоторые базовые концепции MPLS, и описывается используемый общий подход.
2.1. Метки
Метка является коротким идентификатором фиксированной длины, который используется для идентификации FEC. Метка, которая вложена в определенный пакет, представляет класс переадресации FEC (Forwarding Equivalence Class), к которому данный пакет приписан. Обобщая, можно сказать, что пакет приписан FEC, базирующемуся частично или целиком на его адресе места назначения сетевого уровня. Однако кодировка метки никогда не совпадает c этим адресом.
Если Ru и Rd являются LSR, они могут договориться о том, что когда Ru передает пакет Rd, Ru снабжает пакет меткой с кодом L, если и только если пакет принадлежит определенному классу FEC F. То есть, они могут согласовать соответствие между меткой L и F для пакетов, транспортируемых от Ru к Rd. В результате такого соглашения L становится выходной меткой Ru, представляющей FEC F, а L становится входной меткой Rd.
Заметим, что L не обязательно представляет FEC F для любого пакета, посланного не Ru и адресованного не Rd. L имеет произвольное значение, чья связь F с Ru и Rd является локальной.
Когда говорится, что пакеты посланы из Ru в Rd, это не означает, что пакеты сформированы в Ru или, что местом назначения является Rd. Скорее, мы подразумеваем, что пересылаемые пакеты поступают в один или оба LSR.
Иногда может оказаться трудно или даже невозможно для Rd сообщить о прибывающих пакетах с меткой L, помещенной в пакет Ru, а не каким-то другим LSR. (Это обычно происходит, когда Ru и Rd не являются соседями). В таких случаях Rd должен убедиться, что имеет место соответствие межу меткой и FEC. То есть, Rd не должен соглашаться на ассоциацию L и FEC F1, в то время как с другим LSR Ru2 согласовано соответствие L с другим FEC F2, если только Rd не может при получении пакетов с меткой L всегда оповещать, вложена ли в пакет метка Ru1 или Ru2. Гарантия однозначной интерпретации меток находится в зоне ответственности LSR.
2.2. Вышестоящие и нижестоящие LSR
Предположим, что Ru и Rd договорились о соответствии метки L и FEC F, для пакетов, посланных из Ru в Rd. Тогда с учетом этого соответствия, Ru является "вышестоящим LSR", а Rd является "нижестоящим LSR".
Узел является вышестоящим, а другой нижестоящим с учетом того, что в данной ассоциации (метки и класса) метка представляет определенный FEC для пакетов, транспортируемых от вышестоящего узла к нижестоящему. Это, вообще говоря, не означает, что пакеты в этом FEC будут действительно маршрутизированы от вышестоящего узла нижестоящему.
2.3. Помеченные пакеты
Помеченным пакетом является пакет, в заголовке которого имеется метка. В некоторых случаях, метка размещается в заголовке инкапсуляции, который введен специально для этой цели. В других случаях, метка может помещаться в структуре, описывающий информационный канал или в существующем заголовке сетевого уровня, если имеется поле, предназначенное для этой цели.
Метод кодирования метки должен быть согласован субъектом, ее формирующим и субъектом адресатом.
2.4. Присвоение меток и рассылка
В архитектуре MPLS, решение об установлении соответствия конкретной метки L и класса FEC F принимается LSR, который является нижестоящим по отношению к этой ассоциации. Нижестоящий LSR информирует вышестоящий LSR об установлении этой ассоциации. Таким образом, метки присваиваются нижестоящим объектом и рассылаются "снизу-вверх".
Если LSR сконструирован так, чтобы анализировать метки и проверять их принадлежность определенному числовому диапазону, тогда нужно лишь позаботиться, чтобы значения меток действительно лежали в этом диапазоне.
2.5. Атрибуты ассоциации меток (Label Binding)
Конкретная ассоциация метки L и класса FEC F, анонсируемая Rd для Ru, может иметь соответствующие атрибуты. Если Ru работает как нижестоящий LSR, и анонсирует ассоциацию метки и класса FEC F, тогда при определенных обстоятельствах, может оказаться нужно разослать соответствующий атрибут, полученный от Rd.
2.6. Протоколы рассылки меток
Протокол рассылки меток представляет собой набор процедур, с помощью которых один LSR информирует другие об ассоциациях метка/FEC, которые он сформировал. Два LSR, которые используют протокол рассылки меток для обмена данными об ассоциациях метка/FEC, называются "партнерами рассылки меток". Если два LSR являются партнерами по рассылки меток, мы будем говорить о смежности рассылки меток между ними.
Протокол рассылки меток включает в себя также любые согласования, при которых партнеры изучают MPLS возможности друг друга.
Архитектура не предполагает, что должен существовать только один протокол рассылки меток. В действительности, стандартизовано несколько протоколов рассылки меток. Существующие протоколы расширены так, чтобы рассылка меток можно было совместить друг с другом (смотри, например, [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Определены новые протоколы специально для целей рассылки меток (смотри, например, [MPLS-LDP], [MPLS-CR-LDP]).
В данном документе, мы пытаемся использовать акроним "LDP" для ссылок на протокол, определенный в [MPLS-DP].
2.7. Unsolicited Downstream против Downstream-on-Demand
Архитектура MPLS позволяет LSR непосредственно посылать запросы узлу следующего шага относительно конкретного FEC, и ассоциации метка-FEC. Это называется рассылкой меток по схеме "запрос нижележащего" (downstream-on-demand).
Архитектура MPLS позволяет также LSR посылать ассоциации другим LSR, которые напрямую эти данные не запрашивали. Такой обмен называется рассылкой меток нижележащим без запроса (unsolicited downstream).
Ожидается, что некоторые реализации MPLS будут осуществлять рассылку меток только в режиме downstream-on-demand, другие - только в режиме unsolicited downstream, а некоторые - в обоих режимах. Какой из режимов будет реализован, зависит от характеристик интерфейсов, которые поддерживает конкретная реализация. Однако обе эти схемы рассылки меток могут использоваться в некоторых сетях одновременно. В любом конкретном случае вышестоящий и нижестоящий LSR должны согласовать, какая из схем рассылки будет применена.
2.8. Режим удержания меток (Retention Mode)
LSR Ru может получить (или уже получил) от LSR Rd ассоциацию метка-FEC, даже несмотря на то, что Rd не является следующим шагом для Ru (для данного FEC).
Ru теперь имеет выбор следует ли ему отслеживать такие ассоциации или отбрасывать их. Если Ru отслеживает такие ассоциации, тогда он может немедленно начать использование этой ассоциации, если Rd в конце концов, становится его следующим шагом для заданного FEC. Если Ru игнорирует такие ассоциации, тогда если Rd позднее станет следующим шагом, ассоциация должна быть воспринята снова. Если LSR поддерживает "свободный режим удержания меток" (Liberal label retention mode), он поддерживает ассоциации между меткой и FEC, который получен от LSR, не являющегося следующим шагом для этого FEC. Если LSR поддерживает "консервативный режим удержания меток" (Conservative label retention mode), он отбрасывает такие ассоциации.
Свободный режим удержания меток допускает быструю адаптацию к маршрутным изменениям, а консервативный режим сохранения меток требует от LSR поддержки много меньшего числа меток.
2.9. Стек меток
До сих пор мы обсуждали проблему, как если бы помеченные пакеты несли в себе только одну метку. Как мы увидим, полезно иметь более обобщенную модель, в которой помеченные пакеты несут в себе несколько меток, уложенных в порядке "последний_вошел-первым_вышел". Мы будем называть это стеком меток.
Хотя, как это мы увидим, MPLS поддерживает иерархию, обработка помеченных пакетов совершенно не зависит от уровня иерархии. Обработка всегда базируется на верхней метке, без учета того, что некоторое число других меток лежало поверх данной в прошлом, или того, что какое-то их число лежит под ней сейчас.
Непомеченный пакет может рассматриваться как пакет, чей стек меток пуст (т.e., глубина стека которого равна 0).
Если стек пакетных меток имеет глубину m, мы считаем, что метка на дне стека размещена на уровне 1, метка над ней (если таковая имеется) имеет уровень 2, а метка наверху стека имеет уровень m.
2.10. Запись Next Hop Label Forwarding (NHLFE)
"Next Hop Label Forwarding Entry" (NHLFE) используется при переадресации помеченных пакетов. Здесь содержится следующая информация:
1. Следующий шаг пакета
2. Операция, которая должна быть произведена над стеком меток. Это одна из следующих операций:
a) заместить метку на верху стека специфицированной новой меткой
b) извлечь метку из стека
c) заместить метку на верху стека специфицированной новой меткой, и затем ввести в стек одну или более специфицированных меток.
Она может содержать:
d) инкапсуляцию канальных данных, которая будет использована при пересылке пакета
e) метод кодирования стека меток, при пересылке пакета
f) другую информацию, необходимую для того чтобы корректно отобразить пакет.
Заметим, что для данного LSR, следующим шагом пакета может стать сам LSR. В этом случае, LSR должен будет извлечь метку из стека, и затем переадресовать полученный пакет самому себе. Затем он примет следующее решение переадресации, базирующееся на полученном состоянии стека меток.
Это подразумевает, что в некоторых случаях LSR будет должен работать с IP-заголовком, для того чтобы переадресовать пакет.
Если следующим шагом пакета является текущий LSR, тогда операцией над стеком меток должна быть "pop".
2.11. Установление соответствия для входных меток ILM (Incoming Label Map)
"Incoming Label Map" (ILM) устанавливает соответствие каждой входящей метки с набором NHLFE. Эта операция используется, когда переадресуемые пакеты являются помеченными.
Если ILM связывает определенную метку с набором NHLFE, который содержит более одного элемента, только один элемент должен быть выбран из набора, прежде чем пакет будет переадресован. Процедуры выбора элемента из набора находятся за пределами рассмотрения данного документа. Используя технику установления соответствия ILM, можно работать с набором, содержащим более одного NHLFE, что может оказаться желательно, например, при необходимости сбалансировать трафик между несколькими путями, имеющими равные метрики.
2.12. Установление соответствия между FEC и NHLFE (FTN)
Методика "FEC-to-NHLFE" (FTN) устанавливает соответствие между каждым FEC и набором NHLFE. Она используется при переадресации непомеченных пакетов, при необходимости их пометки до переадресации. Если FTN устанавливает соответствие между конкретной меткой и набором NHLFE, который содержит более одного элемента, только один из них должен быть выбран, прежде чем пакет будет переадресован. Процедуры выбора элемента из набора находятся за пределами рассмотрения данного документа.
2.13. Замена меток
Замена меток (Label swapping) представляет собой использование следующих процедур для переадресации пакетов. Для того чтобы переадресовать помеченный пакет, LSR рассматривает метку на верху стека. Он использует ILM для установления соответствия этой метки набору NHLFE. Используя информацию из NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета, затем записывает новую метку в стек пакета и переадресует его.
Для того чтобы переадресовать непомеченный пакет, LSR анализирует заголовок сетевого уровня, чтобы определить FEC пакета. Затем он использует FTN, для того чтобы установить соответствие с NHLFE. Используя информацию NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета. (Извлечение метки из стека в этом случае будет нелегальным).
Важно заметить, что когда используется коммутация меток, следующий шаг всегда берется из NHLFE. Это отличается в некоторых случаях от выбора следующего шага, когда не используется MPLS.
2.14. Область действия и уникальность меток
Данный LSR Rd может связать метку L1 с FEC F, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L2 с FEC F, и переправить эту ассоциацию партнеру Ru2. Является ли L1 == L2 не определяется архитектурой, это вопрос исключительно локальный.
Данный LSR Rd может связать метку L с FEC F1, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L с FEC F2, и переправить эту ассоциацию партнеру Ru2. Если и только если Rd может сообщить, когда он получает пакет с меткой на верху стека равной L, занесена ли она в стек RU1 или RU2, архитектура не требует равенства F1 == F2. В таких случаях, мы можем сказать, что Rd использует другое пространство для меток, которые он пересылает Ru1, чем для меток, посылаемых Ru2. Вообще, Rd может лишь сообщить, Ru1 или Ru2 положил данную метку со значением L на верх стека, если выполнены следующие условия:
- Ru1 и Ru2 являются партнерами, обменивающимися метками, и которым Rd пересылает значение метки L, и
- Ru1 и Ru2 оба соединены с Rd непосредственно через интерфейс точка-точка.
Когда эти условия выполнены, LSR может использовать метки, имеющие область действия "per interface", т.e., которые являются уникальными для каждого интерфейса. Можно сказать, что LSR использует "пространство меток интерфейса". Когда эти условия не выполнены, метки должны быть уникальными для LSR, который их присвоил, и мы можем сказать, что LSR использует "пространство меток платформы".
Если конкретный LSR Rd связан с некоторым LSR Ru через два интерфейса по схеме точка-точка, тогда Rd может пересылать Ru ассоциацию метки L с FEC F1, также как ассоциацию метки L с FEC F2, F1 != F2, если и только если каждая ассоциация корректна для пакетов, которые Ru посылает Rd через один из интерфейсов. Во всех других случаях, Rd не должен посылать ассоциации Ru, сопрягающие одну и ту же метку с двумя разными FEC.
Этот запрет сохраняется, даже если ассоциации относятся к различным уровням иерархии. В MPLS, не существует понятия разных пространств меток для различных уровней иерархии, когда метка интерпретируется, уровень метки значения не имеет.
Возникает вопрос, может ли LSR использовать мультиплатформные пространства меток, или использовать много пространств меток интерфейса для одного и того же интерфейсного устройства. Это не запрещено архитектурой. Однако в таких случаях LSR должен иметь некоторые средства, не специфицированные архитектурой, определения для заданной входной метки, какому пространству принадлежит данная метка. Например, [MPLS-SHIM] специфицирует, что различные пространства меток используются для уникастных и мультикастных пакетов, а для разделения этих пространств используется код канального уровня.
2.15. Маршрут с коммутацией меток (LSP), входной и выходной LSP
"Маршрут с коммутацией меток (LSP) уровня m" для определенного пакета P является последовательностью маршрутизаторов <R1, ..., Rn> со следующими свойствами:
1. R1, "вход LSP", является LSR, который вносит метку в стек пакета P, в результате формируется стек глубиной m;
2. Для всех i, 1<i<n, P (когда он приходит в LSR Ri) имеет стек меток глубиной m;
3. Никогда за время передачи P от R1 к R[n-1] глубина стека не будет меньше m;
4. Для всех i, 1<i<n: Ri передает P в R[i+1] посредством MPLS, т.e., путем использования метки в верхней позиции стека (метка уровня m) в качестве индекса в ILM;
5. Для всех i, 1<i<n: если система S получает и переадресует P, после того как P передан Ri, но до того как P получен R[i+1] (например, Ri и R[i+1] могут быть соединены через коммутируемую субсеть, и S может быть одним из переключателей информационного канала), далее решение переадресации S не базируется на метке уровня m, или на основе заголовка сетевого уровня. Это может быть, так как:
a) решение не основано на содержимом стека или заголовка сетевого уровня;
b) решение основано на содержимом стека, куда положены другие метки (т.e., на метке уровня m+k, где k>0).
Другими словами, мы можем описать уровень m LSP для пакета P, как последовательность маршрутизаторов:
1. Которая начинается с LSR ("вход LSP "), заносящий метку на уровень m.
2. Все маршрутизаторы, чьи промежуточные LSR, принимают решение о переадресации согласно метке на уровне m.
3. Которая завершается (в "выходном LSP"), когда решение переадресации делается на основе коммутации меток на уровне m-k, где k>0, или когда решение переадресации делается "традиционно", посредством не-MPLS процедур.
Следствием (или, пожалуй, предпосылкой) этого является то, что, когда бы LSR ни занес метку в стек уже помеченного пакета, он должен быть уверен, что новая метка соответствует FEC, чьим выходом LSP служит LSR, который сформировал метку, которая сейчас является второй в стеке. Мы будем называть последовательность LSR "LSP для определенного FEC F", если он является LSP уровня m для заданного пакета P, когда уровень метки P соответствует FEC F.
Рассмотрим набор узлов, которые могут быть входными LSP-узлами для FEC F. Тогда существует LSP для FEC F, который начинается с каждого из этих узлов. Если некоторое число этих LSP имеет идентичный выходной LSP, тогда можно рассматривать набор таких LSP как дерево, чьим корнем является выходной LSP. (Так как данные переносятся вдоль этого дерева по направлению к корню, эта структура может быть названа деревом мультиточка-точка). Мы можем, таким образом, говорить о "дереве LSP" для определенного FEC F.
2.16. Извлечение предпоследнего шага
Заметим, что согласно определениям из раздела 2.15, если <R1, ..., Rn> является LSP уровня m для пакета P, P может быть передан от R[n-1] к Rn с глубиной стека меток m-1. То есть, может быть выполнена операция pop для стека меток в предпоследнем LSR LSP, а не в выходном LSP.
С архитектурной точки зрения это вполне приемлемо. Целью метки уровня m является доставка пакета в Rn. Раз R[n-1] решил послать пакет Rn, метка не имеет более значения и не должна далее транспортироваться.
Имеется также практическое преимущество извлечения данных о предпоследнем шаге. Если так не сделать, тогда при получении пакета выходным LSP, он сначала просматривает верхнюю метку из стека, и определяет, что это действительно выходной LSP. Затем он должен извлечь из стека метку, и проверить, что осталось в стеке пакета. Если в стеке имеется другая метка, выходное устройство анализирует метку и осуществляет пересылку пакета на основе этого анализа. (В этом случае, выходное устройство для пакетов уровня m LSP является промежуточным узлом для его уровня m-1 LSP). Если в стеке нет других меток, тогда пакет переадресуется согласно его адресу места назначения сетевого уровня. Заметим, что это потребует от выходного устройства двух просмотров, либо просмотра двух меток, либо просмотра метки с последующим анализом адреса.
Если, с другой стороны, используется извлечение предпоследнего шага из стека, тогда предпоследний узел просматривает метку и определяет:
- это предпоследний шаг, и
- какой узел является следующим.
Предпоследний узел далее извлекает метку из стека и переадресует пакет на основе информации, полученной при просмотре метки, которая была до этого на верху стека. Когда выходной LSP получает пакет, метка, которая находится на верху стека, будет меткой, необходимой для просмотра, чтобы осуществить его собственное решение о переадресации. Или, если пакет нес в себе только одну метку, выход LSP просто просмотрит заголовок пакета сетевого уровня, который является как раз тем, что ему нужно просмотреть, чтобы принять решение о переадресации. Эта методика позволяет выходному шлюзу выполнить один просмотр, а также требует одного просмотра предпоследнему узлу.
Создание в программе коммутации меток "fastpath" может существенно помочь, если известно, что требуется лишь один просмотр метки:
╥
код может быть упрощен, если можно предположить, что ожидается только один просмотр
╥
код может быть
основан на "time budget", который предполагает, что
ожидается только один просмотр.
В действительности, когда предпоследний шаг извлечен из стека, конец LSP не должен быть обязательно LSR.
Однако некоторые аппаратные переключатели не могут извлекать метки из стека, поэтому это не может быть универсальным требованием. Могут также встретиться ситуации, в которых извлечение из стека предпоследнего шага нежелательно. Следовательно, предпоследний узел извлекает метку из стека, только если это запрашивается выходным узлом, ИЛИ если следующий узел в LSP не поддерживает MPLS.
LSR, который способен работать с метками, должен извлекать из стека метку предпоследнего шага, когда это затребовано его нижестоящим партнером.
Начальное согласование протокола рассылки меток должно позволять каждому LSR определить, способны ли соседние LSR извлекать метки из стека. LSR НЕ ДОЛЖЕН запрашивать своего партнера по обмену метками извлекать метку из стека, если только он не способен делать это.
Возможен запрос, может ли выходной узел корректно интерпретировать верхнюю метку в стеке приходящего пакета, если использована операция pop предпоследнего шага. Поскольку правила уникальности и области действия из раздела 2.14 выполняются, всегда возможно правильно интерпретировать верхнюю метку стека приходящего пакета.
2.17. LSP следующего шага
LSP Next Hop для определенного помеченного пакета в конкретном LSR является LSR, который представляет следующий шаг пути, как это выбрано записью NHLFE, использованной для переадресации пакета. LSP Next Hop для определенного FEC является следующим шагом пути, как это выбрано записью NHLFE, индексированной меткой, которая соответствует этому FEC.
Заметим, что LSP следующего шага может отличаться от того, который был бы выбран алгоритмом маршрутизации сетевого уровня. Мы будем использовать термин "следующий шаг L3", когда будем иметь в виду такой маршрут.
2.18. Неверные входные метки
Что должен сделать LSR, если он получает помеченный пакет с определенной входной меткой, но не имеет ассоциации для этой метки? Соблазнительно думать, что можно просто удалить метки и пакеты будут переадресовываться как непомеченные IP. Однако в некоторых случаях, реализация этого приведет к зацикливанию пакетов. Если вышестоящий LSR полагает, что метка сопряжена с определенным маршрутом, а нижестоящий LSR не считает метку, связанной с чем бы то ни было, и если маршрутизация шаг-за-шагом непомеченных IP-пакетов приведет пакет назад к вышестоящему LSR, тогда образуется петля.
Возможно, что метка, пытается определять маршрут, который не может быть получен из IP-заголовка.
Следовательно, когда получен помеченный пакет с неверной входной меткой, он должен быть отброшен, если только он не определен каким-то способом, так что его переадресация не может вызвать никакого вреда.
2.19. LSP управление: Ordered против Independent
Некоторые FEC соответствуют адресным префиксам, которые рассылаются алгоритмом динамической маршрутизации. Начальная установка LSP для этих FEC может быть выполнена двумя способами: независимым управлением LSP (Independent LSP Control) или упорядоченным управлением LSP (Ordered LSP Control).
В независимом управлении LSP, каждый LSR, учитывая, что он распознает определенный FEC, принимает независимое решение об ассоциации метки с FEC и рассылает эту ассоциацию своим партнерам. Это соответствует способу, реализуемому традиционной маршрутизацией IP-дейтограмм. Каждый узел принимает независимое решение относительно того, как обрабатывать конкретный пакет, и полагается на алгоритм маршрутизации. При упорядоченном управлении LSP, LSR только связывает метки с определенным FEC, если он является выходным LSR для данного FEC, или если он уже получил ассоциацию метки с FEC из узла следующего шага.
Если хочется гарантировать, чтобы трафик в конкретном FEC следовал пути с некоторыми специфицированными свойствами (например, чтобы трафик не пересекал один и тот же узел дважды, чтобы для трафика были выделены определенные ресурсы, чтобы трафик следовал определенному пути и т.д.) должен использоваться упорядоченное управление. При независимом управлении, некоторые LSR могут начать коммутацию трафика по меткам в FEC, до того как LSP полностью сконфигурирован, и таким образом часть трафика в FEC может следовать пути, который не имеет специфицированных свойств. Упорядоченное управление должно также использоваться, если распознавание FEC является следствием конфигурирования соответствующего LSP. Упорядоченное конфигурирование LSP может быть инициировано входным или выходным узлом.
Упорядоченное и независимое управление полностью совместимы. Однако если только не все LSR в LSP используют упорядоченное управление, результирующее влияние на поведение сети более существенно, чем в случае независимого управления, так как нельзя быть уверенным, что LSP не будет использован до того, как будет полностью сконфигурирован.
Эта архитектура позволяет сделать выбор между независимым и упорядоченным управлением исключительно местной проблемой. Так как взаимодействуют два метода, данный LSR должен поддерживать один или другой метод. Вообще говоря, выбор независимого или упорядоченного управления не оказывает какого-либо эффекта на механизмы коммутации пакетов, базирующиеся на метках.
2.20. Агрегатирование
Одним из путей распределения трафика в FEC является создание отдельного FEC для каждого адресного префикса, появляющегося в маршрутной таблице. Однако в пределах области MPLS, это может вызвать определенные последствия для набора FEC, в частности, все потоки в этих FEC будут следовать одним и тем же маршрутом. Например, набор различных адресных префиксов может иметь один и тот же выходной узел, а обмен меток может быть использован только для доставки трафика до выходного узла. В этом случае, в пределах домена MPLS, объединение таких FEC само является классом FEC. Это предлагает выбор: следует ли ассоциировать отдельные метки с каждым компонентом FEC, или следует ли ассоциировать отдельную метку с объединением, а метку использовать для всего трафика в объединении? Процедура ассоциации отдельной метки с объединением FEC, который сам является FEC (внутри некоторого домена), и применения меток для трафика в объединении, называется "агрегатированием". Архитектура MPLS допускает агрегатирование. Агрегатирование может уменьшить число меток, с которыми нужно иметь дело заданному набору пакетов, и может сократить объем управляющего трафика.
Данный набор FEC, который является "агрегатируемым" в одном FEC, допускается (a) агрегатировать их в один FEC, (b) агрегатировать их в набор FEC, или (c) не агрегатировать их совсем. Таким образом, мы можем говорить о "гранулярности" агрегатирования, начиная с (a) "грубой гранулярности", кончая (c) "тонкой гранулярностью".
Когда используется упорядоченное управление, каждый LSR должен адаптировать для данного набора FEC гранулярность, используемую на следующем шагу для этих FEC.
Когда используется независимое управление, допускается, чтобы имелись два смежных LSR, Ru и Rd, которые агрегатируют некоторый набор FEC по-разному.
Если Ru имеет более тонкую гранулярность, чем Rd, это не создает проблем. Это означает, что, когда Ru нужно переадресовать помеченные пакеты для этих FEC в Rd, может потребоваться установить соответствие между n и m метками, где n > m. В качестве опции Ru может отозвать набор из n меток, который он разослал, и затем разослать набор из m меток, соответствующих уровню гранулярности Rd. Совсем не нужно гарантировать корректность операции, но это вызовет сокращение числа меток, разосланных Ru, Ru не получает какого-либо преимущества при рассылке большего числа меток. Решение делать это или нет, является исключительно локальным.
Если Ru имеет более грубую гранулярность, чем Rd (т.e., Rd разослал n меток для набора FEC, в то время как Ru разослал m, где n > m), имеется два варианта:
- Можно принять более тонкий уровень гранулярности для Rd. Это бы потребовало отзыва разосланных m, и рассылки n меток. Это предпочтительная опция.
- Можно просто установить соответствие между m метками и субнабором Rd из n меток, если он может определить, что это не изменит маршрутизацию. Например, предположим, что Ru использует одну метку для всех потоков, которые должны пройти определенный выходной LSR, тогда как Rd привязывает к такому трафику некоторое число разных меток, в зависимости от места назначения пакетов. Если Ru знает адрес выходного маршрутизатора, и, если Rd связал метку с FEC, который идентифицирован этим адресом, тогда Ru может просто использовать эту метку.
В любом случае, каждый LSR должен знать (при конфигурации) какую гранулярность использовать для формируемых меток. Когда используется упорядоченное управление, требуется чтобы каждый узел знал гранулярность только для FEC, который покидает сеть MPLS в этом узле. Для независимого управления, наилучший результат может быть получен, путем конфигурации всех LSR так, чтобы они знали гранулярность каждого FEC. Однако во многих случаях это может быть сделано путем использования одной метки с гранулярностью, которая реализует все FEC (такой как "одна метка на IP-префикс таблицы переадресации" или "одна метка на выходной узел").
2.21. Выбор маршрута
Выбор маршрута сопряжен с методом, используемым при выборе LSP для определенного FEC. Предлагаемая архитектура протокола MPLS поддерживает две опции выбора маршрута: (1) маршрутизация шаг-за-шагом и (2) явная маршрутизация.
Маршрутизация шаг-за-шагом позволяет каждому узлу независимо выбрать следующий шаг для каждого FEC. Это обычный режим существующих сегодня IP-сетей. "маршрутизируемый шаг-за-шагом LSP" является LSP, чей маршрут выбирается по схеме шаг-за-шагом.
В LSP при явной маршрутизации, каждый LSR не выбирает следующий шаг независимо; скорее один LSR, обычно вход LSP или выход LSP, специфицирует несколько (или все) LSR в LSP. Если один LSR специфицирует весь LSP, LSP является явно маршрутизированным. Если один LSR специфицирует только некоторые LSP, LSP является "неточно" маршрутизированным.
Последовательность LSR, за которой следует явно маршрутизированные LSP, могут быть выбраны при конфигурации, или могут быть выбраны динамически одним узлом (например, выходной узел может использовать топологическую информацию, полученную из базы данных состояния канала, для того чтобы вычислить весь путь для дерева с корнем в выходном узле).
Явная маршрутизация может быть полезной для ряда целей, таких как политика маршрутизации или управление трафиком (TE). В MPLS, явный маршрут должен быть специфицирован в момент формирования метки, но явный маршрут не должен быть специфицирован для каждого IP-пакета. Это делает явную маршрутизацию MPLS более эффективной, чем альтернативная IP-маршрутизация отправителя.
Процедуры формирования явных маршрутов, точных или неточных, находятся за пределами данного документа.
2.22. Отсутствие выходной метки
Когда помеченный пакет транспортируется вдоль LSP, может так случится, что он достигнет LSR, в котором ILM не устанавливает соответствия между меткой входящего пакета и NHLFE, даже при условии, что сам пакет корректен. Это может случиться из-за переходных обстоятельств или по причине ошибки в LSR, который должен быть следующим шагом пакета.
Может показаться привлекательным в таких случаях, ликвидировать стек меток и попытаться переадресовать пакеты далее методами традиционной маршрутизации, базирующимися на содержимом заголовка сетевого уровня. Однако вообще это небезопасная процедура:
- Если пакет попадает в LSP маршрутизируемый явно, это может привести к образованию петель.
- Заголовок пакета сетевого уровня не может содержать достаточно информации, чтобы позволить данному конкретному LSR переадресовать пакет корректно.
Если нельзя определить, что ни одна из этих ситуаций не реализована, единственно безопасной процедурой может стать отбрасывания пакета.
2.23. Время жизни (TTL)
При традиционной IP переадресации, каждый пакет имеет в заголовке значение поля "Time To Live" (TTL). Когда бы пакет ни проходил через маршрутизатор, его TTL уменьшается на 1. Если TTL достигает 0, прежде чем пакет достигнет места назначения, он отбрасывается.
Это обеспечивает некоторый уровень защиты против петлевых маршрутов, которые могут существовать из-за ошибок конфигурации, или по причине ошибки или медленной сходимости алгоритма маршрутизации. TTL иногда используется для других функций, таких как определение зоны действия мультикастинга, и поддержка команды "traceroute". Это означает, что имеется две проблемы, связанные с TTL, которые MPLS должен решить:
(i) TTL как способ подавления зацикливания;
(ii) TTL как метод реализации других функций, таких как ограничение области распространения пакета.
Когда пакет движется по LSP, он должен появляться с тем же значением TTL, которое он бы имел, если бы он проходил через ту же последовательность маршрутизаторов, без коммутации меток. Если пакет проходит через иерархию LSP, полное число пройденных шагов-LSR должно быть отражено в его значении TTL. Способ, которым обрабатывается поле TTL, может варьироваться в зависимости от того, размещены ли значения меток MPLS в прослойке между заголовками [MPLS-SHIM], или метки MPLS транспортируются в заголовке L2, таком как заголовок ATM [MPLS-ATM] или заголовок frame relay [MPLS-FRMRLY].
Если значения меток вставлены в "прослойку", которая размещается между канальным и сетевым заголовками, тогда эта прослойка должна иметь поле TTL, которое должно заполняться также, как аналогичное поле заголовка сетевого уровня, декрементироваться при каждом шаге LSR, и копироваться в TTL-поле заголовка сетевого уровня, когда пакет выходит из его LSP.
Если значения меток записаны в заголовке канального уровня (например, поле VPI/VCI в заголовке AAL5 ATM), а помеченные пакеты переадресуются переключателем уровня L2 (например, ATM-переключателем), а канальный уровень сам не имеет поля TTL, тогда будет невозможно декрементировать TTL при каждом шаге LSR. Сегмент LSP, который состоит из последовательности LSR, которые не способны декрементировать TTL пакетов, будет называться сегментом "non-TTL LSP".
Когда пакет выходит из сегмента non-TTL LSP, он должен, однако получить TTL, отвечающее числу шагов LSR, которые он проходит. В уникастном случае, это может быть достигнуто путем транспортировки длины LSP входным узлам, позволяя входным устройствам декрементировать значение TTL, прежде чем переадресовывать пакеты в non-TTL LSP сегмент.
Иногда это может быть определено на входе сегмента non-TTL LSP так, что соответствующее значение TTL пакета достигнет нуля, прежде чем пакет дойдет выхода сегмента non-TTL LSP. В этом случае, LSR на входе non-TTL LSP сегмента коммутировать пакеты по меткам. Это означает, что должны быть разработаны специальные процедуры для поддержки функциональности traceroute, например, пакеты traceroute могут переадресовываться по стандартной схеме шаг-за-шагом.
2.24. Контроль петель
В non-TTL LSP сегменте, по определению, TTL не может использоваться для предотвращения петель маршрута. Важность контроля циклических путей зависит от конкретного оборудования, используемого для реализации LSR-функций в пределах non-TTL LSP сегмента.
Предположим, например, что для коммутационных целей в MPLS используются ATM-переключатели, с метками, транспортируемыми в поле VPI/VCI. Так как ATM коммутаторы не могут декрементировать TTL, здесь нет защиты против появления циклических маршрутов. Если оборудование ATM способно обеспечить хороший доступ к буферному пулу для входящих ячеек, имеющих разные значения полей VPI/VCI, петли не могут иметь негативного эффекта на остальной трафик. Если оборудование ATM не может обеспечить хороший доступ к буферам, тогда переходные петли могут вызвать серьезную деградацию эксплуатационных характеристик LSR.
Даже если может быть обеспечен хороший доступ к буферу, целесообразно иметь некоторые средства детектирования петель, которые имеют длину больше определенной. Кроме того, даже когда TTL и/или справедливая организация очередей в виртуальных каналах предоставляет возможности для сохранения петель, может быть желательно, где возможно избегать установления LSP с петлями. Все LSR, которые могут быть связаны с сегментами non-TTL LSP будут должны поддерживать общую методику детектирования петель; однако, использование детектирования петель является опционным. Методика детектирования петель специфицирована в [MPLS-ATM] и [MPLS-LDP].
2.25. Кодирование меток
Для того чтобы передавать стек меток вместе с пакетом, необходимо определить его конкретную структуру. Архитектура поддерживает несколько различных структур. Выбор структуры стека зависит от конкретного типа оборудования, используемого для переадресации пакетов.
2.25.1. MPLS-специфичное оборудование и/или программное обеспечение
Если для переадресации помеченных пакетов используется MPLS-специфичное оборудование и/или программы, наиболее очевидным способом представления стека меток является определение нового протокола, который будет использоваться в пределах прослойки между заголовками канального и сетевого уровней. Эта прокладка могла бы реально быть инкапсуляцией пакетов сетевого уровня. Она является протокольно независимой, такой, чтобы использоваться для инкапсуляции любого сетевого уровня. Следовательно, мы будем называть это как "общая MPLS-инкапсуляция".
MPLS-инкапсуляция будет в свою очередь инкапсулирована с привлечением протокола канального уровня. Общая MPLS-инкапсуляция специфицирована в [MPLS-SHIM].
2.25.2. ATM-коммутаторы в качестве LSR
Процедуры переадресации MPLS подобны тем, что используются в ATM-коммутаторах. ATM-коммутаторы используют входной порт и значение поля VPI/VCI входящего пакета в качестве индекса в таблице коммутации (cross-connect), из которой они получают номер выходного порта и выходного значения VPI/VCI. Следовательно, если одна или более меток могут быть занесены непосредственно в поля заголовков, которые доступны коммутаторам, тогда коммутаторы после модификации программ смогут быть использованы в качестве LSR. Мы будем называть такие устройства "ATM-LSR". Имеется три способа представления меток в заголовках ячеек ATM (предпочтительно использовать AAL5):
1. SVC кодирование
Используется поле VPI/VCI для записи метки, размещенной на верху стека. Эта методика может использоваться в любой сети. Посредством этой методики LSP реализуется как ATM SVC, а протокол рассылки меток становится сигнальным протоколом ATM. ATM-LSR не может выполнять команды "push" или "pop" для стека меток.
2. SVP кодирование
Используется поле VPI для записи метки, размещенной на верху стека, а поле VCI для записи второй метки стека, если такая существует. Эта методика имеет некоторые преимущества по отношению к предыдущей, здесь возможно переключение виртуальных каналов с помощью ATM "VP-switching". То есть, LSP реализуются как ATM SVP.
Однако эта методика не может использоваться всегда. Если сеть включает виртуальный маршрут ATM через ATM-сеть, не поддерживающую MPLS, тогда поле VPI необязательно доступно для использования в MPLS.
Когда используется этот метод представления, ATM-LSR на выходе виртуального канала VP эффективно реализует операцию "pop".
3. Многоточечное кодирование SVP
Для размещения метки на вершине стека используется поле VPI, а для размещения второй метки стека, если таковая имеется, используется часть поля VCI, остальная часть поля VCI служит для идентификации входного LSP. Если применяется эта технология, традиционные возможности ATM VP-коммутации могут использоваться для построения виртуальных маршрутов мультиточка-точка. Ячейки от разных пакетов будут нести тогда разные значения VCI. Как это будет показано в разделе 2.26, это позволяет нам осуществлять объединение меток, не получая проблем перекрытия ячеек, для ATM-коммутаторов, реализующих виртуальные маршруты мультиточка-точка, но которые не имеют возможностей объединения VC.
Эта методика зависит от наличия возможности присвоения 16-битовых значений VCI каждому ATM-коммутатору, так что ни одно значение VCI не будет соответствовать двум разным коммутаторам.
Если имеется больше меток в стеке, чем места в заголовке ATM, тогда ATM представление должно комбинироваться с общей инкапсуляцией.
2.25.3. Совместимость методов кодирования
Если <R1, R2, R3> является сегментом LSP, возможно, что R1 будет использовать одно представление стека меток при передачи пакета P в R2, но R2 будет использовать другое представление при передаче пакета P в R3. Вообще, архитектура MPLS поддерживает LSP с разным представлением стека меток на разных шагах маршрута. Следовательно, когда мы обсуждаем процедуры обработки помеченных пакетов, мы делаем это в терминологии взаимодействия со стеком меток. Когда приходит помеченный пакет, LSR должен декодировать его для определения текущего значения метки в стеке, затем должен преобразовать стек, чтобы определить новое значение метки перед отправкой пакета в следующий узел маршрута.
К сожалению, ATM-коммутаторы не имеют возможности осуществлять преобразование из одного представления стека меток в другое. Архитектура MPLS, следовательно, требует чтобы, когда два ATM-коммутатора оказываются последовательными LSR на уровне m LSP для определенных пакетов, эти два ATM-коммутатора используют одно и то же представление стека меток.
Естественно будут существовать MPLS сети, которые содержат комбинацию ATM-коммутаторов, работающих в качестве LSR, и других LSR, использующих MPLS заголовок-прокладку. В таких сетях могут быть некоторые LSR, имеющие ATM-интерфейсы а также интерфейсы "MPLS Shim" (прослойки). Это лишь один пример LSR с различным представлением стека меток. Такие LSR могут осуществлять подмену структур стека меток из представления ATM на входном интерфейсе в MPLS формат стека на выходном.
2.26. Объединение меток
Предположим, что LSR связал несколько входящих меток с конкретным FEC. При переадресации пакетов в этом FEC, хотелось бы иметь одну выходную метку, которая используется всеми такими пакетами. Тот факт, что два разных пакета класса FEC приходят с разными входными метками является нерелевантным. Хотелось бы переадресовывать их с одной и той же выходной меткой. Реализация этого называется "объединением меток". Будем говорить, что LSR способен объединять метки, если он может получать два пакета от разных входных интерфейсов, и/или с разными метками, а посылать оба пакета с одной и той же выходной меткой. Раз пакеты переданы, информация о том, что они пришли от разных интерфейсов и/или с разными входными метками теряется.
Будем считать, что LSR не способен объединять метки, если для любых двух пакетов, которые приходят из разных интерфейсов, или с разными метками, пакеты должны быть либо переданы через разные интерфейсы, или должны иметь разные выходные метки. ATM-LSR, использующие SVC или SVP представления, не могут реализовывать объединение меток.
Если некоторый LSR не может выполнить объединение меток, тогда, если два пакета в одном и том же FEC приходят с разными входными метками, они должны быть переадресованы с разными выходными метками. При объединении меток, число выходных меток на один FEC должно быть равно 1. Без объединения меток, число выходных меток на один FEC может равняться числу узлов в сети.
При объединении меток число входящих меток на FEC, которое необходимо конкретному LSR, никогда не превосходит числа смежных дистрибьюторов. В отсутствии объединения меток, число входящих меток на один FEC, которое необходимо конкретному LSR, достигает числа вышестоящих узлов, которые переадресуют трафик FEC данному LSR. В действительности, для LSR трудно даже определить, сколько входящих меток он должен поддерживать для конкретного FEC.
Архитектура MPLS приспосабливает как объединяющие, так не объединяющие LSR, но допускает также возможность того, что имеются LSR, не поддерживающие коммутацию меток.
2.26.1. Необъединяющие LSR
Процедура переадресации MPLS очень схожа с используемой в ATM и Frame Relay. То есть, приходит блок данных, ищется метка в коммутационной таблице (VPI/VCI или DLCI), на основе результата поиска выбирается выходной порт, а значение метки переписывается. В действительности, можно использовать такие технологии для переадресации MPLS. Протокол рассылки меток может быть использован в качестве сигнального протокола для формирования коммутационных таблиц. К сожалению, эти технологии необязательно поддерживают возможности объединения меток. В ATM, если попытаться осуществить объединение меток, в результате можно получить перекрытие ячеек от различных пакетов. Если ячейки от разных пакетов оказываются перекрытыми, невозможно осуществить сборку пакетов. Некоторые коммутаторы Frame Relay используют коммутацию ячеек на своих внутренних шинах (backplane). Эти коммутаторы могут также быть неспособными поддерживать объединение меток, по той же причине - ячейки разных пакетов могут перекрываться, и сборка исходных пакетов станет невозможной.
Мы предлагаем поддержать два решения этой проблемы. Первое, MPLS будет поддерживать процедуры, которые позволяют определенным ATM-коммутаторам функционировать как LSR, способные объединять метки.
Так как MPLS поддерживает объединяющие и необъединяющие LSR, MPLS содержит также процедуры, которые гарантируют корректное взаимодействие такого оборудования и программ.
2.26.2. Метки для объединяющих и необъединяющих LSR
Вышестоящий LSR, который поддерживает объединение меток, должен посылать только одну метку на FEC. Вышестоящий сосед, который не поддерживает объединение меток, должен посылать несколько меток на один FEC. Однако не существует метода узнать заранее, сколько нужно меток. Это будет зависеть оттого, сколько имеется вышестоящих LSR для оговоренного FEC.
В архитектуре MPLS, если определенный вышестоящий сосед не поддерживает объединение меток, ему не посылаются какие-либо метки для заданного FEC, если только он напрямую не запрашивает метку для данного FEC. Вышестоящий сосед может сделать несколько таких запросов, и получать каждый раз новую метку. Когда нижестоящий сосед получает такой запрос "сверху", а сам он не поддерживает объединения меток, тогда он должен в свою очередь запросить у своего нижестоящего соседа новую метку для заданного FEC.
Возможно, что существуют какие-то узлы, которые поддерживают объединение меток, но могут объединить лишь ограниченное число входящих меток в одну исходящую. Предположим, например, что из-за некоторых аппаратных ограничений узел может объединить четыре входящие метки в одну исходящую. Предположим, что этот конкретный узел получил шесть меток, пришедших для данного FEC. В этом случае этот узел может объединить их в две исходящие метки.
2.26.3. Объединение потоков в ATM
2.26.3.1. Методы исключения перекрытия ячеек
Существует несколько методов исключения проблемы перекрытия ячеек в ATM, таким образом, позволяющих ATM-коммутатором поддерживать объединение потоков данных:
1. Объединение VP, использующее мультиточечное представление SVP
Когда используется объединение VP, несколько виртуальных путей объединяются в один путь, но пакеты от разных отправителей отличаются разными VCI в пределах данного VP.
2. Объединение VC
Когда используется объединение VC, коммутаторы должны буферизовать ячейки от пакетов до тех пор, пока не будет принят весь пакет (это может быть определено путем просмотра индикатора конца кадра для AAL5).
Объединение VP имеет преимущество в том, что оно совместимо с подавляющим числом реализаций ATM-коммутаторов. Это делает более вероятным то, что объединение VP может использоваться в существующих сетях. В отличие от объединения VC, объединение VP не приводит к каким-либо задержкам в точках объединения, а также не накладывает никаких требований на буферы. Однако это имеет недостаток, так как требует координации пространства VCI в пределах VP. Существует несколько способов реализации этого.
Этот компромисс между совместимостью с существующим оборудованием, сложностью протокола и масштабируемостью предполагает, что желательна поддержка протоколом MPLS объединения как VP, так и VC. Для того чтобы реализовать это каждый ATM-коммутатор, участвующий в MPLS, должен знать, могут ли ближайшие ATM соседи осуществлять объединение VP или VC.
2.26.3.2. Взаимодействие: объединение VC, объединение VP, и отсутствие объединения
Взаимодействие различных форм объединения в ATM наиболее просто описать на примере взаимодействия систем с объединением VC и без.
В случае, когда соединены узлы, поддерживающие и не поддерживающие объединение VC, переадресация ячеек базируется во всех вариантах на VC (т.e., на соединении VPI и VCI). Для каждого вышестоящего узла, осуществляющего объединение VC, нужен только один набор VPI/VCI (это сходно с требованиями для одиночной метки в случае работы в среде кадров (frame media)). Если вышестоящий сосед не может осуществлять объединение, тогда он будет требовать одного VPI/VCI на поток для себя, плюс достаточное число VPI/VCI, чтобы осуществить передачу вышестоящему соседу. Необходимое число будет определено путем разрешения вышестоящим узлам посылать запросы дополнительных VPI/VCI от своих нижестоящих соседей (это аналогично методике объединения, используемой для кадров).
Аналогично можно поддержать узлы, которые выполняют объединение VP. В этом случае объединяющий VP узел, вместо посылки запроса одного или нескольких VPI/VCI от нижестоящего соседа, может запросить один VP (идентифицируемого посредством VPI), но несколько VCI в пределах VP. Кроме того, предположим, что узел, не поддерживающий объединение ниже расположен по отношению к двум другим узлам, объединяющим VP. Этот узел может нуждаться в запросе одного VPI/VCI (для трафика, исходящего именно из этого узла) плюс два VP (по одному для каждого вышестоящего узла), ассоциированные со специфицированными наборами VCI (в соответствии с запросом от вышестоящего узла).
Для того чтобы поддерживать узлы, объединяющие и не объединяющие VP и VC, необходимо разрешить вышестоящим узлам запрашивать комбинацию из нуля или более идентификаторов VC (состоящих из VPI/VCI), плюс нуль или более VP (идентифицируемых VPI), каждый из которых содержит специфицированное число VC (идентифицированное набором VCI, которые работают в пределах VP). Узлы, объединяющие VP, затребовали бы один VP, содержащий VCI для исходящего трафика (если таковой имеется) плюс VCI для каждого VC, запрошенного свыше (вне зависимости оттого, является или нет VC частью, содержащей VP). Узлы, объединяющие VC, затребовали бы только один VPI/VCI (так как они могут объединить весь трафик от вышестоящих узлов в один VC). Узлы, не поддерживающие объединение, передали бы любые запросы, полученные сверху, плюс запрос VPI/VCI для трафика, генерируемого ими самими (если таковой имеется).
2.27. Туннели и иерархия
Иногда маршрутизатор Ru предпринимает действия, чтобы доставить определенный пакет другому маршрутизатору Rd, даже если Ru и Rd не являются смежными углами на пути пакета, а Rd не является местом назначения пакета. Это может быть сделано, например, путем инкапсуляции пакета в пакет сетевого уровня, местом назначения которого является Rd. Это создает туннель от Ru к Rd .
2.27.1. Туннель, маршрутизированный шаг-за-шагом
Если туннелированный пакет следует маршрутом шаг-за-шагом от Ru к Rd , мы говорим, что это "туннель, маршрутизированный шаг-за-шагом", чье начало находится в Ru и чей конец в Rd.
2.27.2. Туннель, маршрутизированный явно
Если туннелированный пакет транспортируется из Ru в Rd по пути, отличному от маршрута шаг-за-шагом, мы говорим, что это "Туннель, маршрутизированный явно" с начальной точкой в Ru и конечной - в Rd. Например, мы можем послать пакет через туннель, маршрутизированный явно путем инкапсуляции его в пакет, маршрутизируемый отправителем.
2.27.3. Туннели LSP
Имеется возможность реализовать туннель в виде LSP и использовать коммутацию меток, а не инкапсуляцию сетевого уровня, чтобы заставить пакет идти через туннель. Туннель будет иметь вид LSP <R1, ..., Rn >, где R1 является началом туннеля, а Rn - концом туннеля. Это называется " LSP-туннелем".
Набор пакетов, которые посланы через LSP-туннель, представляет собой FEC, а каждый LSR в туннеле должен установить ассоциацию между меткой и FEC (т.e., нужно присвоить туннелю определенную метку). Критерий установления соответствия пакета LSP-туннелю является внутренним вопросом начальной точки туннеля. Чтобы направить пакет в LSP-туннель, передающий конец туннеля вводит метку туннеля в стек и посылает помеченный пакет узлу следующего шага туннеля.
Если для конечной точки туннеля не нужно определять, какой пакет получен через туннель, как это обсуждалось выше, стек меток может быть очищен на предпоследнем LSR туннеля.
" LSP-туннель, маршрутизированный шаг-за-шагом" представляет собой туннель, который реализован в виде LSP-туннеля, маршрутизированного по схеме шаг-за-шагом. "LSP-туннелем, маршрутизированным явно" является LSP-туннель, который представляет собой также LSP, маршрутизированный явно.
2.27.4. Иерархия: LSP туннели в LSP
Рассмотрим LSP <R1, R2, R3, R4>. Предположим, что R1 получил непомеченный пакет P, и заносит метку в его стек, чтобы пакет следовал заданным путем (путь шаг-за-шагом). Предположим далее, что R2 и R3 не являются непосредственно связанными, но они являются виртуальными соседями, так как представляют собой конечные точки LSP-туннеля. Итак, действительная последовательность LSR, через которые проходит P, соответствует <R1, R2, R21, R22, R23, R3, R4>. Когда P транспортируется из R1 в R2, он имеет глубину стека равную 1. R2, коммутирующий метки, определяет, что P должен войти в туннель. R2 сначала замещает входную метку меткой, имеющей смысл для R3. Затем он заносит метку в стек. Эта метка второго уровня имеет значение, понятное R21. Коммутация осуществляется для метки на уровне 2 устройствами R21, R22, R23. R23, который является предпоследним узлом в туннеле R2-R3, удаляет метку из стека до того, как будет выполнена переадресация пакета в R3. Когда R3 видит пакет P, P имеет только метку уровня 1, и покидает туннель. Так как R3 является предпоследним шагом P в LSP, он удаляет метку из стека, а R4 получает P непомеченным. Механизм стека меток допускает любую глубину вложения LSP-туннелей.
2.27.5. Иерархия и партнерство в рассылке меток
Предположим, что пакет P транспортируется на уровне 1 LSP <R1, R 2, R3, R4>, и при транспортировке из R2 в R3 движется по LSP уровня 2 <R2, R21, R22, R3>. С точки зрения LSP уровня 2, партером рассылки меток R2 является R21. С точки зрения LSP уровня 1, партерами рассылки меток R2 являются R1 и R3. Могут существовать партеры обмена метками на каждом уровне иерархии. В разделах 3.6 и 3.7 рассмотрены некоторые способы реализации этой иерархии. Заметим, что в этом примере R2 и R21 должны быть IGP-соседями, но R2 и R3 не обязательно ими являются.
Когда два LSR являются соседними IGP, мы называем их "локальными партнерам рассылки меток". Когда два LSR могут быть партнерами рассылки меток, но не являются соседними IGP, мы называем их "удаленными партнерами распределения меток". В выше приведенном примере R2 и R21 являются локальными партнерами рассылки меток, а R2 и R3 являются удаленными партнерами рассылки меток.
Архитектура MPLS поддерживает два способа рассылки меток на различных уровнях иерархии: явное и неявное партнерство (Peering).
Рассылка меток (пиринг) осуществляется путем обмена протокольными сообщениями, которые адресованы партнеру. Возможен обмен метками и с удаленным партнером. Это возможно одним из двух путей:
1. Явное партнерство
При явном партнерстве, метки пересылаются партнеру в протокольных сообщениях так же, как это делается при локальном обмене. Эта методика наиболее полезна, когда число удаленных партнеров мало, или число ассоциаций высокого уровня велико, или удаленные партнеры обмена метками размещены в удаленных областях или доменах. Конечно, может быть нужно знать, какие метки следует послать какому партнеру; это рассмотрено в разделе 3.1.2. Примеры использования явного партнерства представлены в разделе 3.2.1 и 3.6.
2. Неявное партнерство
При неявном партнерстве, протокольные сообщения рассылки меток, адресованные одному партнеру, не посылаются. Скорее, чтобы разослать метки высокого уровня удаленным партнерам, метка представляется в виде атрибута метки более низкого уровня, а затем производится рассылка метки низкого уровня вместе с этим атрибутом местным партнерам. Локальные партнеры обмена метками рассылают полученные данные дальше. Этот процесс продолжается до тех пор, пока информация не достигнет удаленных партнеров.
Эта техника наиболее полезна, когда число удаленных партнеров обмена метками велико. Неявное партнерство не требует сетки партнеров n-квадрат, чтобы разослать метки удаленным партнерам, так как имеется подстраховка за счет локального обмена информацией. Однако неявное партнерство требует, чтобы промежуточные узлы запоминали информацию, в которой они могут быть заинтересованы. Пример использования неявного партнерства можно найти в разделе 3.3.
2.28. Транспортировка протокольных сообщений рассылки меток
Протокол рассылки меток используется между узлами в сети MPLS для установления и поддержания привязки меток. Для того чтобы MPLS работал корректно, информация, сопряженная с рассылкой меток, должна рассылаться совершенно надежно, а протокольные сообщения рассылки меток, имеющие отношение к определенному FEC, должны посылаться в определенном порядке. Управление потоком также желательно, так как имеется возможность транспортировки нескольких сообщений с метками в одной дейтограмме.
Одним из способов достижения цели является использование TCP в качестве базового транспортного протокола, как это делается в [MPLS-LDP] и [MPLS-BGP].
2.29. Зачем нужно более одного протокола рассылки меток?
Эта архитектура не устанавливает жестких правил для выбора того, какой протокол рассылки меток следует использовать при конкретных обстоятельствах. Однако имеется возможность указать некоторые соображения.
2.29.1. BGP и LDP
Во многих сценариях, желательно установить связь между метками и FEC, который может быть сопряжен с маршрутами и адресными префиксами (смотри раздел 3.1).
Протокол BGP рассылает маршруты, и, если BGP-отправителю нужно разослать метки своим BGP-партнерам, использование BGP для целей распределения меток (смотри [MPLS-BGP]) имеет ряд преимуществ. В частности, это позволяет BGP рефлекторам маршрутов рассылать метки, таким образом обеспечивая существенную масштабируемость по сравнению с использованием LDP для пересылки меток между BGP партнерами.
2.29.2. Метки для RSVP Flowspecs
Когда используется RSVP при резервировании ресурсов для конкретных потоков, может быть желательно, помечать пакеты в этих потоках, так что не нужно будет использовать RSVP filterspec в каждом из узлов . Можно обосновать, что осуществление рассылки меток в рамках RSVP в качестве части процесса формирования пути, и резервирования ресурсов является наиболее эффективным методом решения проблемы.
2.29.3. Метки для явно маршрутизируемых LSP
В некоторых приложениях MPLS, в частности сопряженных с управлением трафиком (ТЕ), желательно формировать пути, маршрутизированные явно от точки входа до точки выхода. Хотелось бы также осуществлять резервирование ресурсов вдоль всего пути. Можно представить два подхода:
- Начать с существующего протокола, который используется при установлении резервирования, и расширить его в направлении поддержки явной маршрутизации и рассылки меток.
- Начать с существующего протокола, который используется для рассылки меток, и расширить его в сторону явной маршрутизации и резервирования ресурсов.
Первый подход реализован в протоколе, описанном в [MPLS -RSVP-TUNNELS], второй - специфицирован в [MPLS-CR-LDP].
3. Некоторые применения MPLS
3.1. MPLS и трафик, маршрутизируемый шаг-за-шагом
Ряд приложений MPLS требуют, чтобы пакеты с определенной меткой направлялись одним и тем же путем, маршрутизированным шаг-за-шагом. Этот путь будет использоваться для пакетов с адресом, который специфицирован в соответствующем поле заголовка сетевого уровня.
3.1.1. Метки для адресных префиксов
Вообще, маршрутизатор R определяет следующий шаг для пакета P путем нахождения подходящего адресного префикса X в своей маршрутной таблице. То есть, пакеты в данном FEC - это пакеты, которые соответствуют заданному адресному префиксу в маршрутной таблице R. В этом случае, FEC может быть идентифицирован адресным префиксом.
Заметим, что пакет P может быть приписан к FEC F, а FEC F может быть идентифицирован адресным префиксом X, даже если адрес места назначения P не согласуется с X.
3.1.2. Рассылка меток для адресных префиксов
3.1.2.1. Партнеры рассылки меток для адресного префикса
LSR R1 и R2 считаются партнерами рассылки меток для адресного префикса X, если и только если выполнено одно из следующих условий:
1. Маршрут R1 к X является маршрутом, который прислан определенным IGP, а R2 является соседом R1 по данным IGP.
2. Маршрут R1 к X является маршрутом, который прислан в какой-то момент в результате работы алгоритма маршрутизации A1, и этот маршрут рассылается алгоритмом маршрутизации A2, а R2 является соседом R1 согласно A2.
3. R1 является выходной точкой LSP-туннеля, который находится внутри другого LSP, а R2 является входной точкой этого туннеля, R1 и R2 являются клиентами IGP, и находятся в той же области IGP (если данный IGP имеет области), а маршрут от R1 к X был получен через IGP, или в результате рассылки R1 данному IGP.
4. Маршрут R1 к X является маршрутом, который прислан BGP, а R2 является BGP-партнером R1.
Вообще, эти правила гарантируют то, что, если маршрут до определенного адресного префикса рассылается через IGP, партнеры рассылки меток для данного адресного префикса являются IGP-соседями. Если маршрут определенного адресного префикса рассылается через BGP, партнеры рассылки меток для данного адресного префикса являются BGP партнерами. В других случаях LSP-туннелирования конечные точки туннеля являются партнерами по рассылке меток.
3.1.2.2. Рассылаемые метки
Для того чтобы использовать MPLS для переадресации пакетов согласно маршруту шаг-за-шагом, соответствующему какому-либо адресному префиксу, каждый LSR должен:
1. Связать один или более меток с каждым адресным префиксом, который обнаружен в маршрутной таблице.
2. Для каждого такого адресного префикса X, использовать протокол рассылки меток для уведомления партнеров (в рамках Х) о существовании ассоциации метки с данным префиксом.
Существует также обстоятельство, при котором LSR должен рассылать ассоциации меток для адресного префикса, даже если он не является LSR, который установил связь между меткой и префиксом:
3. Если R1 использует BGP для рассылки маршрута до X, называя некоторый другой LSR R2 в качестве следующего BGP шага к X, и если R1 знает, что R2 присвоена метка L, тогда R1 должен разослать уведомление об ассоциации L и X всем BGP-партнерам, которым он рассылает это маршрут.
Эти правила гарантируют, что метки, ассоциированные с адресным префиксам, которые соответствуют маршрутам BGP, рассылаются IGP-соседям, если и только если BGP-маршруты разосланы IGP. Другими словами, метки, привязанные к BGP-маршрутам, рассылаются только другим BGP-агентам.
Эти правила имею целью указать, какие ассоциации меток должны рассылаться данным LSR другим LSR.
3.1.3. Использование маршрутов шаг-за-шагом в качестве LSP
Если путь шаг-за-шагом, которому пакет P должен следовать, характеризуется <R1, ..., Rn >, тогда < R1, ..., Rn> может быть LSP до тех пор пока:
1. Существует один адресный префикс X , такой, что для всех i, 1<=i<n , X является наилучшим соответствием в маршрутной таблице Ri для адреса места назначения P ;
2. Для всех i, 1<i <n, Ri установил соответствие метки и X и разослал эту метку всем R[i-1].
Заметим, что LSP пакета может простираться только до ближайшего маршрутизатора, чья маршрутная таблица содержит запись с префиксом, имеющим наилучшее соответствие для адреса места назначения пакета. В этой точке LSP должен завершиться, а алгоритм поиска наилучшего соответствия должен быть запущен заново.
Предположим, например, что пакет P, с адресом места назначения 10.2.153.178 должен двигаться от R1 к R2 и далее к R3. Предположим также, что R2 анонсирует адресный префикс 10.2/16 для R1, но R3 анонсирует 10.2.153/23, 10.2.154/23 и 10.2/16 до R2. То есть, R2 анонсирует "агрегатный маршрут" для R1. В этой ситуации, пакет P может быть коммутируемым по метке до тех пор, пока он не достигнет R2, но так как R2 осуществил агрегатирование маршрутов, он должен запустит алгоритм поиска наилучшего соответствия, чтобы найти FEC для P.
3.1.4. Конец LSP и прокси конец LSP
LSR R считается конечным LSR LSP для адресного префикса X, если и только если выполнено одно из следующих условий:
1. R имеет адрес Y, такой что X является адресным префиксом в маршрутной таблице R, который наилучшим образом соответствует Y, или
2. R содержит в своей маршрутной таблице один или более адресных префиксов Y, таких что X является подходящей начальной субстрокой Y, но "предыдущие шаги LSP" R для X не содержат никакого адресного префикса Y. То есть, R является "точкой ликвидации агрегатирования" для адресного префикса X .
LSR R1 считается "прокси концом LSP" LSR для адресного префикса X, если и только если:
1. Следующим шагом R1 для X служит R 2, а R1 и R2 не являются партнерами по рассылке меток с точки зрения X (возможно потому, что R2 не поддерживает MPLS), или
2. R1 был сконфигурирован, чтобы работать в качестве прокси конца LSP для X
Определение LSP позволяет концу LSP быть узлом, который не поддерживает MPLS. В этом случае предпоследний узел в LSP является прокси выходным.
3.1.5. Неявная метка NULL
Неявная метка NULL представляет собой метку со специальной семантикой, которую LSR может связать с адресным префиксом. Если LSR Ru после получения справки в ILM видит, что помеченный пакет P должен быть переадресован следующему Rd, но что Rd разослал ассоциацию неявной метки NULL с соответствующим адресным префиксом, тогда вместо того, чтобы заменить значение метки на вершине стека, Ru опустошает стек меток, а затем переадресует полученный пакет в Rd.
LSR Rd рассылает ассоциацию неявной метки NULL и адресного префикса X в LSR Ru, если и только если:
1. Правила раздела 3.1.2 указывают, что Rd посылает Ru ассоциацию метки для X, и
2. Rd знает, что Ru может поддерживать неявные метки NULL (т.e., что он может очистить стек меток), и
3. Rd является концом LSP (а не прокси концом) для X.
Это заставляет предпоследний LSR на LSP очистить стек меток. Это вполне приемлемо, если конец LSP является концом MPLS для X, далее если предпоследний LSR не очистит стек меток, конечный узел LSP будет должен просмотреть метку, извлечь метку из стека, и затем посмотреть следующую метку (или просмотреть адрес L3, если меток больше нет). При выполнении предпоследним LSR команды pop для стека меток, конец LSP избавляется от необходимости просмотра двух меток, для того чтобы принять свое решение переадресации.
Однако если предпоследним LSR является ATM-коммутатор, он может не иметь возможности выполнить команду pop для стека меток. Следовательно, может быть послана ассоциация неявной метки в LSR, который может поддерживать эту функцию.
Если предпоследний LSR в LSP для адресного префикса X является прокси концом LSP, он действует, как если бы конец LSP разослал ассоциацию неявной метки NULL для X.
3.1.6. Опция: присвоение метки Egress Targeted
Существуют ситуации, в которых начало LSP Ri, знает, что пакеты нескольких разных FEC должны следовать одним и тем же LSP, завершающимся, скажем, конечным Re. В этом случае, корректная маршрутизация может быть реализована использованием одной метки для всех таких FEC, необязательно иметь отличающиеся метки для каждого FEC. Если и только если выполняются следующие условия:
1. Адрес LSR Re сам находится в маршрутной таблице (host route), и
2. Существует некоторый способ для Ri определить, что Re является концом LSP для всех пакетов в конкретном наборе FEC.
Затем Ri может связать одну метку со всеми элементами набора FEC. Это называется "Egress-Targeted Label Assignment".
Как может LSR Ri определить, что LSR Re является концом LSP для всех пакетов в конкретном FEC? Существует несколько возможных путей:
- Если сеть реализует алгоритм маршрутизации состояния канала, а все узлы в области поддерживают MPLS, тогда алгоритм маршрутизации предоставляет Ri достаточно информации, чтобы определить маршрутизаторы, через которые пакеты в данном FEC должны покинуть домен маршрутизации или область.
- Если сеть реализует BGP, Ri может определить, какие пакеты в заданном FEC должны покинуть сеть через некоторый конкретный маршрутизатор, который является "BGP Next Hop" для этого FEC.
- Можно использовать протокол рассылки меток, чтобы передать информацию о том, какие адресные префиксы подключены к какому концевому LSR. Этот метод имеет преимущество отсутствия зависимости от наличия маршрутизации по состоянию канала.
Если используется присвоение меток egress-targeted, число меток, которые необходимо поддерживать во всей сети может быть сокращено. Это может быть важно, если используется аппаратные переключатели для реализации MPLS, а коммутирующее оборудование может поддерживать ограниченное число меток.
Возможным подходом могло бы быть конфигурирование сети для использования присвоения меток egress-targeted по умолчанию, но при конфигурации конкретных LSR не использовать присвоения меток egress-targeted для одного или более адресных префиксов, для которых он является концом LSP. Мы вводим следующее правило:
- Если какой-то LSR не является концом LSP для некоторого набора адресных префиксов, тогда он должен присваивать метки адресным префиксам так же, как это делается узлом следующего шага LSP для этих адресных префиксов. То есть, предположим, Rd является маршрутизатором следующего шага (Ru) LSP для адресного префикса X1 и X2. Если Rd приписывает ту же метку X1 и X2, Ru должен сделать то же самое. Если Rd присваивает разные метки X1 и X2, тогда и Ru должен это сделать.
Например, предположим, что хочется осуществить присвоение метки egress-targeted по умолчанию, но присвоить разные метки тем адресным префиксам, для которых существует несколько возможных концов LSP (т.e., для тех адресных префиксов, которые являются multi-homed). Можно сконфигурировать все LSR для использования присвоения меток egress-targeted, и затем конфигурировать LSR, чтобы приписать разные метки тем адресным префиксам, которые являются multi-homed. Для конкретного адресного префикса multi-homed X, было бы нужно сконфигурировать LSR, которые являются либо концами LSP, либо прокси концами LSP для X.
Важно заметить, что если Ru и Rd являются смежными LSR в LSP для X1 и X2, переадресация будет выполнена корректно, если Ru присваивает разные метки X1 и X2, в то время как Rd присваивает одну метку для них обоих. Это лишь означает, что R1 будет устанавливать соответствие между разными входными метками и одной выходной.
Аналогично, если Rd присваивает разные метки X1 и X2, но Ru присваивает им обоим метку, соответствующую адресу их конца LSP или прокси конца, переадресация будет, тем не менее, осуществляться корректно. Ru будет лишь устанавливать соответствие между входной меткой и меткой, которую сформировал Rd для адреса конца LSP .
3.2. MPLS и LSP, маршрутизируемые явно
Существует несколько причин, почему желательно использовать явную маршрутизацию, а не схему шаг-за-шагом. Например, это позволяет маршрутам основываться на административной политике, допускать маршруты, которые формируют LSP согласно соображения управления трафиком [MPLS-TRFENG].
3.2.1. LSP-туннели, маршрутизируемые явно
В некоторых ситуациях сетевые администраторы могут захотеть переадресовывать определенные классы трафика по определенным специфицированным заранее маршрутам, где эти пути отличаются от маршрутов шаг-за-шагом, по которым шел трафик первоначально. Это может быть сделано для поддержки политики маршрутизации, или для управления трафиком (ТЕ). Явный маршрут может быть сконфигурирован, или он может быть определен динамически посредством, например, маршрутизации на основе ограничений.
MPLS позволяет выполнить это легко посредством LSP-туннелей, маршрутизированных явно. Для этого необходимо:
1. Средства отбора
пакетов, которые должны быть посланы в LSP-туннель, маршрутизированный явно;
2. Средства формирования маршрутизированного явно LSP-туннеля;
3. Средства, гарантирующие, что пакеты, посланные в туннель, не будут переадресованы принимающей стороной
туннеля в направлении передающей стороны (отсутствие петель).
Если передающий конец туннеля хочет поместить помеченный пакет в туннель, он должен сначала заменить метку на вершине стека меткой, присланной принимающей стороной туннеля. Затем он должен ввести в стек метку, которая соответствует самому туннелю и прислана маршрутизатором следующего шага в туннеле. Чтобы разрешить это, концы туннеля должны быть явными партнерами по обмену метками. Ассоциации меток, которыми они должны обменяться не представляют интереса для LSR в туннеле.
3.3. Стеки меток и неявное партнерство
Предположим конкретный LSR Re является прокси концом LSP для 10 адресных префиксов, и он имеет доступ к каждому адресному префиксу через отдельный интерфейс.
Можно было бы присвоить одну метку всем 10 адресным префиксам. Тогда Re будет концом LSP для всех этих префиксов. Это гарантирует, что пакеты для всех 10 адресных префиксов будут доставлены Re. Однако Re был бы должен просматривать сетевой адрес каждого такого пакета, для того чтобы правильно выбрать интерфейс, через который его следует послать.
В качестве альтернативы, можно было бы присвоить разные метки для каждого из интерфейсов. Тогда Re будет прокси концом LSP для 10 адресных префиксов. Это исключает необходимость для Re просматривать сетевые адреса пакетов, чтобы переадресовывать пакеты. Однако это может привести к использованию слишком большого числа меток.
Альтернативой может быть объединение всех 10 адресных префиксов вокруг одной общей метки уровня 1 (которая ассоциирована также с адресом самого LSR), после чего можно связать каждый адресный префикс с отдельной меткой уровня 2. Метка уровня 2 будет рассматриваться как атрибут ассоциации метки уровня 1, который мы будем называть "атрибутом стека". Мы вводим следующие правила:
- Когда LSR Ru помечает ранее непомеченные пакеты, если наилучшим соответствием адресу места назначения пакета равно X, а следующим шагом Ru LSP для X является Rd, и Rd послал Ru ассоциацию метки L1 и X, наряду с атрибутом стека L2, тогда
1. Ru должен занести в стек меток L2, а затем L1, а после этого переадресовать пакет Rd;
2. Когда Ru посылает ассоциацию метки для X своим партнерам по рассылке меток, он должен включить L2 в качестве атрибута стека.
3. Когда бы атрибут стека изменился (возможно в результате изменения следующего шага Ru LSP для X), Ru должен разослать новый атрибут стека.
Заметим, что хотя значение метки, связанное с X, может отличаться для последовательных шагов в LSP , значение атрибута стека передается без изменений, оно устанавливается узлом прокси конца LSP.
Таким образом, прокси конец LSP для X становится "неявным партнером" каждого прочего LSR в области или домене маршрутизации. В этом случае, явное партнерство было бы слишком тяжеловесным, так как число партнеров стало бы слишком большим.
3.4. MPLS и маршрутизация при нескольких путях
Если LSR поддерживает много путей для заданного потока, тогда он может приписать потоку много меток, по одной для каждого маршрута. Таким образом, получение второй ассоциации метки от определенного соседа для заданного адресного префикса должно интерпретироваться так, что любая из меток может представлять данный адресный префикс.
Если специфицировано несколько ассоциаций меток для заданного адресного префикса, они могут иметь разные атрибуты.
3.5. Деревья LSP как объекты мультиточка-точка
Рассмотрим случай, когда пакеты P1 и P2 имеют адреса места назначения в префиксе Х. Предположим, что маршрут шаг-за-шагом для P1 представляет собой <R1, R2, R3>, а путем шаг-за-шагом для P2 является <R4, R2, R3>. Давайте предположим, что R3 связывает метку L3 с X, и отсылает эту ассоциацию R2. R2 связывает метку L2 с X, и посылает эту ассоциацию в R1 и R4. Когда R2 получает пакет P1, его входная метка будет также L2. R2 заменит L2 на L3, и пошлет P1 в R3. Когда R2 получает пакет P2, его входная метка будет также L2. R2 снова заменит L2 на L3, и пошлет P2 в R3.
Заметим далее, что когда P1 и P2 двигаются от R2 к R3, они несут одну и ту же метку, и с точки зрения MPLS, они не различимы. Таким образом, вместо того чтобы говорить о двух разных LSP, <R1, R2, R3> и <R4, R2, R3>, мы можем говорить об одном дереве LSP мультиточка-точка (Multipoint-to-Point LSP Tree), которое мы можем обозначить как <{ R1, R4}, R2, R3>.
Это создает трудности, когда мы пытаемся использовать обычные ATM-коммутаторы в качестве LSR. Так как обычные ATM-коммутаторы не поддерживают соединения мультиточка-точка, должны существовать процедуры, гарантирующие, чтобы каждый LSP реализовал VC по схеме точка-точка. Однако если используются ATM-коммутаторы, которые поддерживают VC мультиточка-точка, тогда LSP может быть реализован эффективно по такой схеме. Альтернативой может служить ситуация, когда можно использовать многоточечное представление SVP (раздел 2.25.2), LSP может быть реализован как SVP мультиточка-точка.
3.6. LSP-туннелирование между пограничными BGP маршрутизаторами
Рассмотрим случай автономной системы A, которая пропускает трафик между другими автономными системами. Автономная система A будет иметь несколько пограничных маршрутизаторов BGP, и сеть BGP соединений между ними, через которые пересылаются BGP маршруты. Во многих таких случаях желательно избежать рассылки BGP-маршрутов маршрутизаторам, которые не являются пограничными. Если этого можно избежать, нагрузка по рассылке маршрутов этих маршрутизаторов существенно сокращается. Однако должны быть некоторые средства, гарантирующие, что транзитный трафик будет доставляться от одного BGP-маршрутизатора к другому с помощью внутренних маршрутизаторов.
Это может быть легко сделано с помощью туннелей LSP. Предположим, что BGP маршруты рассылаются только пограничным BGP-маршрутизаторам, а не внутренними маршрутизаторами, которые расположены по пути. LSP-туннели могут использоваться следующим образом:
1. Каждый пограничный маршрутизатор BGP посылает каждому другому пограничному маршрутизатору BGP в пределах автономной системы метку для каждого адресного префикса, которую он пересылает в рамках протокола BGP.
2. IGP для автономной системы поддерживает маршрут для каждого BGP-маршрутизатора. Каждый внутренний маршрутизатор рассылает свои метки для этих маршрутов каждому своему IGP-соседу.
3. Предположим, что:
a) Пограничный маршрутизатор BGP B1 получает непомеченный пакет P.
b) Адресный префикс X в маршрутной таблице B1 является наилучшим соответствием для адреса места назначения пакета P.
c) Маршрут до X является маршрутом BGP.
d) Следующим шагом BGP для X является B2.
e) B2 имеет ассоциацию метки L1 и X, и посылает эту ассоциацию в B1.
f) Следующий шаг IGP для адреса B2 является I1.
g) Адрес B2 содержится в маршрутных таблицах B1 и I1 IGP, а
h) I1 связывает метку L2 с адресом B2 и посылает эту ассоциацию B1.
Далее прежде чем послать пакет P в I1, B 1 должен сформировать стек меток для P, затем заносит туда метку L1, а на верх стека записывает L2.
4. Предположим, что пограничный BGP маршрутизатор B1 получает помеченный пакет P, где на верху стека размещена метка, соответствующая адресному префиксу X маршрута, и что условия 3b, 3c, 3d и 3e все выполнены. Тогда прежде чем посылать пакет P в I1, B1 должен заменить метку на верху стека на метку L1, и затем записать в стек метку L2.
Эти процедуры эффективно формируют LSP-туннель, маршрутизированный шаг-за-шагом, между пограничными маршрутизаторами BGP.
Так как пограничные BGP-маршрутизаторы обмениваются ассоциациями меток для адресных префиксов, которые неизвестны IGP, маршрутизаторы BGP должны стать партнерами по явному обмену метками.
Иногда можно сформировать LSP-туннель, маршрутизированный шаг-за-шагом, между двумя пограничными маршрутизаторами BGP, даже если они не принадлежат общей автономной системе. Предположим, например, что B1 и B2 находятся в AS1. Предположим также, что B3 является EBGP-соседом B2, и находится в AS2. Наконец, предположим, что B2 и B3 находятся в некоторой сети, которая является общей для обеих автономных систем ("демилитаризованная зона"). В этом случае LSP-туннель может быть сформирован непосредственно между B1 и B3 следующим образом:
╥ B3 посылает маршруты B2 (используя EBGP), опционно присваивая метки адресным префиксам;
╥ B2 перераспределяет маршруты к B1 (используя IBGP), указывая, что следующим шагом BGP для каждого такого маршрута является B3. Если B3 присвоил метки адресным префиксам, B2 передает эти метки далее без изменений вплоть до B1.
╥ IGP автономной системы AS1 имеет host route для B3.
3.7. Другие применения LSP-туннелей, маршрутизированных шаг-за-шагом
Использование LSP-туннелей, маршрутизированных шаг-за-шагом не ограничено туннелями между узлами BGP. Любая ситуация, в которой мог бы использоваться туннель с инкапсуляцией, является приемлемой для применения LSP-туннеля, маршрутизируемого шаг-за-шагом. Вместо инкапсуляции пакета с новым заголовком, чей адрес места назначения является адресом приемной точки туннеля, производится занесение в стек метки, соответствующей адресному префиксу, который ассоциируется с адресом конечной точки туннеля. Пакет, посланный в туннель, может быть помеченным или нет.
Если начальный узел туннеля намеревается направить помеченный пакет в туннель, он должен сначала заменить значение метки в стеке на значение, полученное от узла конца туннеля. Затем он должен занести в стек метку, которая соответствует самому туннелю. Чтобы разрешить это, конечные точки туннеля должны быть явными партнерами обмена метками. Ассоциации меток, которыми они должны обмениваться не играют никакой роли для LSR в пределах туннеля.
3.8. MPLS и мультикастинг
Мультикастная маршрутизация осуществляется путем формирования мультикаст-деревьев. Дерево, вдоль которого должен переадресовываться конкретный мультикаст пакет, зависит от адресов отправителя и получателя пакета. Когда конкретный LSR является узлом некоторого мультикаст-дерева, он связывает метку с этим деревом. Он рассылает эту ассоциацию вдоль данного дерева. Если рассматриваемый узел принадлежит локальной сети, и имеет партнеров в этой сети, он должен также рассылать указанные ассоциации своим партнерам. Это позволяет вышестоящим узлам использовать одну метку, когда осуществляется мультикатинг для всех нижестоящих объектов LAN.
Когда приходит помеченный мультикастный пакет, NHLFE , соответствующий метке, указывает на набор выходных интерфейсов для данного пакета, а также на выходную метку. Если используется один и тот же формат представления метки для всех выходных интерфейсов, один и тот же пакет может быть послан всем нижестоящим объектам.
4. Процедуры пересылки меток (Hop-by-Hop)
В этом разделе, мы рассматриваем только ассоциации меток, которые используются для трафика, который коммутируется по меткам в пределах пути, маршрутизованного по схеме шаг-за-шагом. В этих случаях, метка будет соответствовать адресному префиксу в маршрутной таблице.
4.1. Процедуры анонсирования и использования меток
Существует некоторое число различных процедур, которые могут использоваться для рассылки ассоциаций меток. Некоторые исполняются нижестоящим LSR, а некоторые вышестоящим LSR. Нижестоящий LSR должен выполнить:
- Процедуру рассылки и
- Процедуру отзыва.
Вышестоящий LSR должен выполнить:
- Процедуру Request и
- Процедуру NotAvailable и
- Процедуру Release и
- Процедуру labelUse.
Архитектура MPLS поддерживает несколько разных вариантов каждой процедуры. Однако архитектура MPLS не поддерживает все комбинации возможных вариантов. Набор поддерживаемых комбинаций будет обсужден в разделе 4.2, где рассматривается совместимость различных комбинаций.
4.1.1. Нижестоящий LSR: Процедура рассылки
Процедура рассылки используется нижестоящим LSR, чтобы определить, когда он должен разослать своим партнерам ассоциации меток для конкретного адресного префикса. Архитектура поддерживает четыре разные процедуры рассылки.
Вне зависимости от используемой процедуры рассылки, если ассоциация метки для заданного адресного префикса была послана нижестоящим LSR Rd вышестоящему LSR Ru, и, если в какой-то момент атрибуты ассоциации (как это определено выше) изменились, тогда Rd должен проинформировать Ru о новых атрибутах.
Если LSR поддерживает несколько маршрутов для заданного адресного префикса, то будет ли LSR ассоциировать несколько меток данному адресному префиксу (один на маршрут), и, следовательно, рассылать несколько ассоциаций, является исключительно локальной проблемой
4.1.1.1. PushUnconditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером по рассылке меток Rd с точки зрения X
Когда бы эти условия ни выполнялись, Rd должен связать метку с X и послать эту ассоциацию Ru. Отслеживание ассоциаций, которые посылаются Ru, и контроль того, что Ru всегда имеет эти ассоциации, является областью ответственности Rd.
Эта процедура должна использоваться LSR, которые выполняют не затребованное присвоение меток в независимом режиме управления LSP.
4.1.1.2. PushConditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Rd является либо концом LSP, либо прокси концом LSP для X , или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, и Rn связал метку с X и послал эту ассоциацию Rd.
Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru.
Поскольку PushUnconditional вызывает рассылку ассоциаций меток всем адресным префиксам маршрутной таблицы, PushConditional вызывает рассылку ассоциаций меток только тем адресным префиксам, для которых получены ассоциации от одного следующего шага LSP, или для которых не существует следующего шага с поддержкой MPLS L3.
Эта процедуру следует использовать LSR, которые выполняют не затребованное присвоение меток в упорядоченном режиме управления LSP.
4.1.1.3. PulledUnconditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
Затем Rd должен связать метку с X и послать эту ассоциацию Ru. Заметим, что если X отсутствует в маршрутной таблице Rd, или если Rd не является партнером Ru по рассылке меток с учетом X, тогда Rd должен проинформировать Ru о том, что в данный момент не может предоставить ассоциацию.
Если Rd уже переслал Ru ассоциацию метки для адресного префикса X, и получил новый запрос от Ru ассоциации для адресного префикса X, он свяжет вторую метку, и пошлет новую ассоциацию Ru . Первая ассоциация метки остается в силе.
Эта процедура будет использоваться LSR, выполняющими рассылку меток downstream-on-demand, используя независимый режим управления LSP.
4.1.1.4. PulledConditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
4. Rd является либо концом LSP, либо прокси концом LSP для X, или следующим шагом Rd L3 для X является Rn,
где Rn отличается от Ru, а Rn связал метку с X и послал эту ассоциацию Rd
Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru . Заметим, что если X отсутствует в маршрутной таблице Rd, а получить ассоциацию для X через следующий шаг Rd для X невозможно, или если Rd не является партнером Ru по пересылке меток с учетом X, тогда Rd должен проинформировать Ru, что не может в данный момент предоставить ему необходимую ассоциацию.
Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки.
Если Rd послал Ru ассоциацию метки для адресного префикса X, а спустя какое-то время любой из атрибутов ассоциации метки изменился, Rd должен заново послать Ru ассоциацию с новым значением атрибута. Он должен сделать это даже если Ru не послал нового запроса. Эту процедуру следует использовать LSR, которые осуществляют ассоциацию меток downstream-on-demand в упорядоченном режиме управления LSP.
В разделе 4.2, мы обсудим то, как выбрать конкретную процедуру, которую следует использовать в конкретной ситуации, и как гарантировать совместимость работы LSR, выбравших разные процедуры.
4.1.2. Вышестоящий LSR: процедура запроса
Процедура запроса используется вышестоящим LSR для адресного префикса, чтобы определить, когда следует запросить нижестоящий LSR связать метку с адресным префиксом и разослать эту ассоциацию. Существует три процедуры, которые могут быть использованы.
4.1.2.1. RequestNever
Никогда не делай запросов. Эта процедура полезна, если нижестоящий LSR использует процедуры PushConditional или PushUnconditional, но она бесполезна, если нижестоящий LSR использует процедуры PulledUnconditional или PulledConditional.
Эта процедура будет использоваться LSR, когда применена не запрошенная рассылка меток и свободный режим удержания меток.
4.1.2.2. RequestWhenNeeded
Осуществляет запрос всякий раз, когда меняется соотношение между следующим шагом L3 и адресным префиксом, или когда прислан новый адресный префикс, и нет уже ассоциации метки от следующего шага для заданного адресного префикса.
Эту процедуру следует использовать LSR, когда применен консервативный режим удержания меток.
4.1.2.3. RequestOnRequest
Процедура посылает запрос всякий раз, когда приходит запрос в дополнение к необходимым протокольным запросам (как это описано в разделе 3.1.2.2). Если Ru не способен быть входом LSP, он может выдать запрос, только когда получает запрос сверху.
Если Rd получает такой запрос от Ru, для адресного префикса, для которого Rd уже послал метку Ru, Rd присвоит новую метку, ассоциирует ее с X, и разошлет эту ассоциацию. Может ли Rd послать эту ассоциацию Ru немедленно или нет, зависит от используемой процедуры рассылки. Эту процедуру следует использовать LSR, которые осуществляют рассылку меток downstream-on-demand, но не выполняют объединения меток, например, ATM-LSR, которые не способны объединять VC.
4.1.3. Вышестоящий LSR: процедура NotAvailable
Если Ru и Rd являются соответственно вышестоящим и нижестоящим партнерами рассылки меток для адресного префикса X, Rd является следующим шагом Ru L3 для X, Ru запрашивает ассоциацию для X от Rd, но Rd отвечает, что не может предоставить ассоциацию в это время, так как он не имеет следующего шага для X. Далее процедура NotAvailable определяет, как должен реагировать Ru. Существует две возможные процедуры, управляющие поведением Ru:
4.1.3.1. RequestRetry
Ru должен выдать запрос снова спустя некоторое время. То есть, источник запроса ответственен за попытку получить необходимую ассоциацию позднее. Эту процедуру следует использовать, когда применена рассылка меток downstream-on-demand.
4.1.3.2. RequestNoRetry
Ru никогда не должен посылать запрос повторно, предполагая, что Rd предоставит необходимую ассоциацию автоматически, когда она станет доступной. Это полезно, если Rd использует процедуру PushUnconditional или PushConditional, т.e., если применена не запрошенная рассылка меток нижестоящим объектам.
Заметим, что если Rd отвечает, что он не может предоставить ассоциацию Ru, из-за тех же условий ошибки, а не по причине того, что Rd не имеет следующего шага, поведение Ru будет управляться условиями восстановления после ошибки протокола рассылки меток, а не процедурой NotAvailable.
4.1.4. Вышестоящий LSR: процедура Release
Предположим, что Rd является LSR, который связывает метку с адресным префиксом X, и который послал эту ассоциацию LSR Ru. Если Rd не оказался следующим шагом Ru L3 для адресного префикса X, или перестал быть следующим шагом Ru L3 для адресного префикса X, Ru перестанет использовать метку. Процедура Release определяет то, как Ru работает в этом случае. Существует две возможные процедуры, управляющие поведением Ru:
4.1.4.1. ReleaseOnChange
Ru должен ликвидировать ассоциацию и информировать Rd об этом. Эту процедуру следует использовать в консервативном режиме удержания меток (Label Retention Mode).
4.1.4.2. NoReleaseOnChange
Ru должен поддерживать ассоциацию, так что он сможет использовать ее немедленно, если Rd станет позднее следующим шагом Ru L3 для X . Эту процедуру следует использовать для реализации свободного режима удержания меток ( Liberal Label Retention Mode).
4.1.5. Вышестоящий LSR: процедура labelUse
Предположим, что Ru является LSR, который получил ассоциацию метки L для адресного префикса X от LSR Rd. Ru является вышестоящим по отношению к Rd с учетом X , и в действительности Rd является следующим шагом Ru L3 для X.
Ru воспользуется ассоциацией, если Rd является следующим шагом Ru L3 для X. Если в момент получения ассоциации Ru, Rd не является следующим шагом Ru L3 для X , Ru не будет использовать эту ассоциацию. Ru может однако начать использовать ассоциацию позже, если Rd станет следующим шагом Ru L3 для X. Процедура labelUse определяет, как Ru использует ассоциацию Rd. Существует две процедуры, которые может использовать Ru:
4.1.5.1. UseImmediate
Ru может начать использовать ассоциацию немедленно. В любое время, когда Ru получил ассоциацию для X от Rd , а Rd является следующим шагом Ru L3 для X, Rd будет также следующим шагом Ru LSP для X . Эта процедура применяется, когда не используется детектирование петель.
4.1.5.2. UseIfLoopNotDetected
Эта процедура аналогична UseImmediate, если только Ru не детектировал петлю в LSP. Если детектирована петля, Ru прекратит использовать метку L для переадресации пакетов в Rd.
Эта процедура используется, когда работает детектирование петель маршрутов. Это будет продолжаться до тех пор, пока не изменится следующий шаг для X, или пока не будет ликвидирован петлевой маршрут.
4.1.6. Нижестоящий LSR: процедура отзыва
В этом случае существует только одна процедура. Когда LSR Rd решает разорвать ассоциацию между меткой L и адресным префиксом X, тогда это решение должно быть доведено до сведения всех LSR, которым эта ассоциация была прислана. Требуется, чтобы уведомление о разрыве ассоциации между L и X было послано Rd в LSR Ru, прежде чем Rd пришлет Ru какие-либо иные ассоциации L с какими-либо префиксами Y, где X != Y. Если Ru узнал о новой ассоциации L и Y, до того как получил данные о разрыве ассоциации L и X, и если пакеты, соответствующие префиксам X и Y, переадресуются из Ru в Rd, тогда в течение некоторого времени Ru будет помечать пакеты, относящиеся к X и к Y меткой L.
Рассылка и отзыв ассоциаций меток осуществляется через протокол рассылки меток. Все протоколы рассылки меток требуют, чтобы был установлен контакт между партнерами рассылки меток (за исключением неявных партнеров). Если LSR R1 установил контакт по рассылке меток с LSR R2, и получил ассоциации меток от LSR R2 через это соединение, тогда если соединение будет разорвано одним из партнеров (либо в результате поломки, либо обычной работы), все ассоциации, полученные через это соединение, должны рассматриваться как отозванные.
Пока эффективное соединение по обмену метками остается в силе, отзыв ассоциаций меток должен производиться явно. Если вторая метка ассоциирована с адресным префиксом, первая метка при этом не отзывается, будут существовать обе ассоциации. Это необходимо, чтобы поддерживать маршрутизации с несколькими маршрутами. Если второй адресный префикс ассоциирован с меткой, ассоциация с первым префиксом при этом не отзывается, метка будет использоваться для обоих адресных префиксов.
4.2. Схемы MPLS: поддерживаемые комбинации процедур
Рассмотрим два LSR, Ru и Rd, которые являются партнерами рассылки меток для некоторого набора адресных префиксов, где Ru является вышестоящим партнером, а Rd - нижестоящим.
Схема MPLS, которая управляет взаимодействием Ru и Rd может быть описана с помощью пяти процедур: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. Так как существует только одна процедура отзыва, она здесь не упоминается. Появление "*" в одной из позиций в качестве подмены, означает, что в данной категории возможна любая процедура; появление "N/A" в некоторой позиции указывает, что не нужна никакая процедура данной категории.
Только схемы MPLS, которые специфицированы ниже, поддерживаются архитектурой MPLS. Другие схемы могут быть добавлены в будущем, если их необходимость будет доказана.
4.2.1. Схемы для LSR, которые поддерживают объединение меток
Если Ru и Rd являются партнерами по рассылке меток, и оба поддерживают объединение меток, должна использоваться одна из следующих схем:
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate >
Это не затребованная рассылка меток "вниз по течению" с независимым управлением, свободным режимом удержания меток и без детектирования маршрутных петель.
2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>
Это не затребованная рассылка меток "вниз по течению" с независимым управлением, свободным режимом удержания меток и детектированием петель.
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange,*>
Это не затребованная рассылка меток "вниз по течению" с упорядоченным управлением (со стороны конца) и консервативным режимом удержанием меток. Детектирование петель опционно .
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
Это не затребованная рассылка меток "вниз по течению" с упорядоченным управлением (со стороны конца) и свободным режимом удержанием меток. Детектирование петель опционно.
5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>
Это рассылка меток "вниз по течению по запросу" (downstream-on-demand) с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием петель.
6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>
Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и без детектирования петель.
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>
Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и детектированием петель.
4.2.2. Схемы для LSR, которые не поддерживают объединение меток
Предположим, что R1, R2, R3 и R4 являются ATM-коммутаторами, которые не поддерживают объединение меток, но используются в качестве LSR. Предположим далее, что маршрут L3 шаг-за-шагом для адресного префикса X имеет вид <R1, R2, R 3, R4>, и что пакеты, адресованные X, могут войти в сеть через любой из этих LSR. Так как здесь нет возможности реализовать схему мультиточка-точка, LSP должны быть реализованы как VC точка-точка, что означает необходимость трех таких VC для адресного префикса X: <R1, R2, R3, R4>, <R2, R3, R4> и <R3, R4>.
Следовательно, если R1 и R2 являются MPLS-партнерами, и любой из них является LSR, который реализован с использованием обычного коммутирующего оборудования ATM (т.e., без подавления перекрытия ячеек), или по какой то иной причине не способен осуществлять объединение меток, используемая схема MPLS между R1 и R 2 должна быть одной из следующих:
1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>
Это рассылка меток "вниз по течению по запросу" с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием маршрутных петель.
Использование процедуры RequestOnRequest вынудит R4 послать R3 три метки для X; R3 пошлет R22 метки для X, а R2 пошлет одну метку R1 для X.
2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>
Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и без детектирования петель.
3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>
Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и с детектированием петель.
4.2.3. Соображения совместимости
Легко видеть, что некоторые пятерки не образуют жизнеспособных схем MPLS. Например:
- <PulledUnconditional, RequestNever, *, *, *>
<PulledConditional, RequestNever, *, *, *>
В этих схемах MPLS, нижестоящий LSR Rd пересылает ассоциации меток вышестоящему LSR Ru только по запросу от Ru, но Ru никогда не делает таких запросов. Очевидно, эти схемы нежизнеспособны, так как они не способны осуществлять корректную рассылку ассоциаций меток.
- <*, RequestNever, *, *, ReleaseOnChange>
В этих схемах MPLS, Rd аннулирует ассоциации, если он их не использует, но он никогда не запрашивает их снова, даже если они ему позднее понадобятся. Эти схемы, таким образом, не гарантируют того, что ассоциации меток будут разосланы корректно.
В этом разделе специфицируются правила предотвращения того, чтобы партнеры по рассылке меток выбирали процедуры, которые ведут к недопустимым схемам MPLS. Эти правила требуют либо обмена информацией между партнерами по рассылке меток во время инициализации системы, либо априорного знания (полученного каким-то методом, который находится за пределами рассмотрения данного документа).
1. Каждый субъект должен объявить, поддерживает ли он объединение меток.
2. Если Rd не поддерживает объединение меток, Rd должен выбрать либо процедуру PulledUnconditional, либо PulledConditional. Если Rd выбирает PulledConditional, Ru вынужден использовать процедуру RequestRetry.
То есть, если нижестоящий LSR не поддерживает объединения меток, его предпочтения имеют приоритет, при выборе схем MPLS.
3. Если Ru не поддерживает объединение меток, а Rd поддерживает, Ru должен выбрать процедуру RequestRetry или RequestNoRetry. Это вынуждает Rd использовать соответственно процедуру PulledConditional или PulledUnConditional.
То есть, если только один из LSR не поддерживает объединение меток, его предпочтения имеют приоритет, при выборе схем MPLS.
4. Если как Ru, так и Rd поддерживают объединение меток, тогда выбор между свободным и консервативным режимами удержания меток остается за Ru. То есть, Ru предоставляется выбрать либо использование RequestWhenNeeded/ReleaseOnChange (консервативный), или использовать RequestNever/NoReleaseOnChange (свободный). Однако, выбор push либо pull и "условный" либо "безусловный" принадлежит Rd. Если Ru выбирает свободный режим удержания меток, Rd может выбрать либо PushUnconditional, либо PushConditional. Если Ru выбирает консервативный режим удержания меток, Rd может выбрать PushConditional, PulledConditional или PulledUnconditional. Такой выбор определяет использование схемы MPLS .
5. Соображения безопасности
Некоторые маршрутизаторы могут реализовать безопасные процедуры, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Базовая инкапсуляция MPLS подразумевает введение прослойки между заголовком канального и сетевого уровня. Это может вызвать отказ в работе некоторых процедур безопасности. Метка MPLS имеет свое значение благодаря соглашению между LSR, который записывает метку в стек (источник метки), и LSR, который интерпретирует метку (получатель метки). Если помеченный пакет получен от непроверенного отправителя, или если некоторая метка получена от LSR, которому она не посылалась, тогда пакеты могут маршрутизоваться некорректным образом.
6. Ссылки
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress.
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress.
[MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress.
[MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Перевод RFC-3353 В данном документе формулируются принципы внедрения IP -мультикастинга в среду MPLS. Представлен обзор последствий внедрения технологии MPLS в IP-мультикастинг. Рассматриваются плюсы и минусы существующих IP-мультикастинговых протоколов маршрутизации в контексте и обсуждаются соотношения различных способов запуска процессов формирования виртуальных путей на основе использования меток. Перечислены последствия применения различных технологий уровня 2 (L2). Обсуждаются сетевые схемы точка-точка и сети с множественным доступом. Таблица сокращений
1. Введение В облаке MPLS маршруты определяются протоколом уровня L3. Чтобы улучшить рабочие характеристики сети эти маршруты могут быть преобразованы в пути уровня L2. Кроме этого, MPLS предлагает средства улучшения сетевых услуг, такие как QoS/CoS, управление трафиком и т.д. Существующие уникастные протоколы маршрутизации формируют некоторый (оптимальный) кратчайший путь для определенной пары отправитель-получатель. Заметим, что уникастные протоколы могут работать по-разному в случае путей с эквивалентной метрикой. Для мультикастинга оптимальное решение (минимальная цена соединения N узлов) предполагает вычисление дерева Штайнера (Steiner). К сожалению, ни один современный мультикастный протокол маршрутизации не может сформировать такого дерева. Разные мультикастные протоколы формируют различные деревья. Обсуждение в данном документе концентрируется на протоколах внутридоменной мультикастинг маршрутизации. 2. Характеристики уровня 2 Хотя MPLS является мультипротокольным как для L3, так и L2, на практике IP рассматривается в качестве единственного протокола для L3. MPLS может работать поверх нескольких технологий L2 (PPP/Sonet, Ethernet, ATM, FR и т.д.). Когда переключение на основе меток переносится на уровень L2 (например, в качестве метки используются поля VPI/VCI), внимание фокусируется в основном на ATM [DAVI]. ATM предлагает высокие переключающие возможности и доступность обеспечения QoS, но в контексте имеет ряд ограничений, которые описаны в [DAVI]. Аналогичные соображения представлены для случая Frame Relay на уровне L2 в [CONT]. Ограничения можно суммировать как:
Все три ограничения могут оказать сильное влияние на реализацию
мультикастинга в MPLS. Когда базовый MPLS будет
разработан эти ограничения исчезнут. Более того, для каналов PPP и Ethernet может быть использована одна и
та же метка для уникастного и мультикастного LSP, так как для уникастного и мультикастного определены разные коды
EtherTypes [ROSE].
3. Систематика мултикастных IP протоколов маршрутизации в контексте MPLS
В настоящее время предложено и разрабатывается много мультикастинг протоколов маршрутизации. Все эти протоколы имеют различные характеристики (масштабируемость, вычислительную сложность, задержку, избыточность сообщений управления, тип дерева и т.д.). Целью данного документа не является
осуществление исчерпывающей систематики мультикастинг протоколов маршрутизации, а только рассмотрение их характеристик, имеющих отношение к технологии MPLS. Рассматриваются следующие характеристики:
- Агрегатирование
Обсуждение этих характеристик не ставит задачу выбора единственного наилучшего мультикастинг протокола маршрутизации. Вполне
возможно, что для целей мультикастинга в Интернет будут использованы различные протоколы маршрутизации.
3.1. Агрегатирование
В уникастинге различные адреса места назначения объединяются в
одной записи маршрутной таблицы, предоставляя один FEC и один LSP. Гранулярность
мультикастинг потоков равна (*, G) для совмещенных деревьев и (S,G) для деревьев отправителя, где
S - адрес отправителя, а G - мультикастинг адрес группы.
3.2. Широкая рассылка и отсекание ветвей
Чтобы сформировать мультикаст дерево протоколы маршрутизации
(например, DVMRP, PIM-DM) широко рассылают мультикаст-данные. Отдельные ветви могут быть затем отсечены
узлами, которые не хотят получать данные определенных мультикастинг-групп. Этот процесс периодически повторяется. Широкая
рассылка и отсекание ветвей протоколов мультикастинг-маршрутизации имеет
некоторые характеристики, которые значительно отличаются от параметров
уникастных маршрутных протоколов:
- Таким образом, LSP не могут быть сформированы заранее, как это обычно делается в случае уникастинга.
Чтобы минимизировать время между поступлением данных и формированием
LSP, желателен достаточно быстродействующий метод конфигурации LSP (setup method).
- Так как формирование и ликвидация маршрута L3 в каждом узле запускается самим трафиком,
это предполагает, что LSP, ассоциированный с маршрутом, формировался и уничтожался также процедурой,
управляемой трафиком.
- Если LSR не поддерживает переадресацию L3, технология управления трафиком требует, чтобы вышестоящий
LSR брал на себя инициативу формирования LSP (анонсирование меток Upstream Unsolicited или
Downstream on Demand).
3.3. Деревья с общим отправителем
Мультикастные IP протоколы маршрутизации формируют либо деревья отправителя (S,G), т.е.
по дереву для каждого отправителя (S) и для группы (G), или деревья с совмещением (*, G), т.е.
одно дерево для каждой мультикаст-группы (Рис. 1).
Рис. 1. Дерево с совмещением и деревья отправителя
Преимуществом использования деревьев с совмещением, в случае
применения переключения по меткам, является то, что деревья с совмещением
требуют меньше меток, чем деревья отправителя (1 метка на группу против одной
метки на отправителя и на группу). Однако проецирование деревьев с совмещением
на уровень L2 подразумевает формирование LSP мультиточка-мультиточка (mp2mp). Заметим,
что на практике деревья с совмещением часто используются только для выявления
новых отправителей групп, а переключение на дерево отправителя производится при
низких потоках данных.
3.4. Сосуществование деревьев с совмещением и деревьев отправителя
Некоторые протоколы поддерживают как деревья отправителя, так и
деревья с совмещением (например, PIM-SM) и один маршрутизатор может содержать (*, G) и (S,G)
состояния для одной и той же группы G. Два случая сосуществования описаны ниже. Рассмотрим топологии
с отправителями Si и получателями Ri. RP является точкой встречи (Rendezvous Point).
Ni представляют собой LSR. Числа являются номерами интерфейсов, "Reg" - интерфейс
Register. Все сообщения IGMP и PIM Join/Prune показаны на рисунках. Индицируется состояние бита RPT для состояния (S,G).
1) На рис. 2 показан переход от совмещенного дерева к дереву
отправителя. Предположим, что кратчайший путь от R1 к RP пролегает через
N1-N2-N5. N1, выделенный маршрутизатор получателя (Designated Router) R1, (DRrecv) решает инициализировать дерево
отправителя для S1. После получения данных через дерево отправителя в N2, N2 пошлет команду отсечения в
N5 для отправителя S1. Состояние сосуществования реализуется в узле, где начинается перекрытие деревьев с совмещением и отправителя
(N2), и в узле, где S1 не нуждается более в переадресации на дерево с совмещением (N5).
IJ=Igmp Join;
PJ=Pim Join (*,G);
PJS=Pim Join (S1,G);
PPS=Pim Prune (S1,G) Рис. 2 Ниже перечислены состояния, которые формируются в мультикастинг таблице маршрутизации (MRT): в RP: (*,G):Reg->1
(т.е. входящее itf=Reg; исходящее itf=1) 2) На рис. 3 показано, что состояние сосуществования может иметь место даже без переключения. Мультикастный трафик от отправителя сформирует состояние (S, G) в выделенном маршрутизаторе отправителя (DRsend; N3 на рис. 3 является DRsend отправителя S). Каждый узел совмещенного дерева имеет состояние (*,G). Таким образом Rsend имеет состояния (*, G) и (S,G). Если DRsend находится на дереве, он пошлет команду отсечения (prune) для S в направлении RP, формируя состояние (S,G) во всех узлах вплоть до первого маршрутизатора, который имеет ответвление (N1 и N2 на рис. 3).
Рис. 3 Состояния, формируемые при мультикастинг-маршрутизации в MRT, представлены ниже: в RP (*,G):Reg->1
(т.е. входящее itf=Reg; исходящее itf=1) В данных примерах можно видеть, что могут иметь место два типа сосуществования:
3.5. Одно и двунаправленные деревья с совмещением Двунаправленные деревья с совмещением (например, CBT [BALL]) имеют недостаток, который связан с формированием большого числа точек смежности (M) в узлах (N) совмещенного дерева. На рис. 4 показаны эти точки, полученные при двух отправителях S1 и S2 двунаправленного дерева.
Рис. 4. Потоки мультикаст-данных от двух отправителей для двунаправленного дерева На рис. 5 показана та же ситуация для однонаправленных деревьев. В этом случае данные отправителя направляются через туннель к корневому узлу R, формируя всего одну точку смежности (сам корень дерева).
Рис. 5. Потоки мультикаст-данных от двух отправителей для однонаправленного дерева 3.6. Инкапсулированные мультикастинг данные Отправители однонаправленных совмещенных деревьев и отправители, не являющиеся узлами двунаправленных совмещенных деревьев, инкапсулируют данные на пути к корневому узлу. Данные затем декапсулируются в корневом узле. Инкапсуляция и декапсуляция мультикастных данных осуществляется на уровне L3. Таким образом, в случае инкапсуляции/декапсуляции путь может вообще не совпадать с LSP: трафик не может быть ни переадресован на L2 через интерфейс Register DRsend (инкапсуляция), ни попасть в корневой узел на L2 (декапсуляция). Замечания
3.7. Отсутствие петель Протоколы мультикаст маршрутизации, которые зависят от уникастного протокола маршрутизации подвержены зацикливаниям при переходных процессах, как и все уникастные, однако воздействие таких петель в случае мультикаста много тяжелей. Это происходит по следующей причине, каждый раз, когда мультикаст пакет идет вдоль петли, копии этого пакета могут выходить за пределы этого кольцевого маршрута, если имеет место его ветвление. В настоящее время детектирование петель является конфигурируемой опцией в LDP и решение о механизме предотвращения кольцевых маршрутов отложено на будущее. 3.8. Характеристики существующих протоколов Выше перечисленные характеристики суммированы в таблице 1 для неполного списка существующих мультикастных протоколов маршрутизации: DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM [HOLB], SM [PERL]. Таблица 1.Систематика протоколов маршрутизации для IP-мультикастинга
Из таблицы 1 можно видеть, например, что DVMRP использует большое число меток, когда дерево Flood & Prune L3 проектируется на дерево L2. Более того, так как DVMRP использует деревья отправителя, он не сталкивается с проблемой объединения, когда используется коммутация по меткам. Таблица может быть интерпретирована аналогичным образом для других протоколов. 4. Смешанная переадресация L2/L3 в отдельном узле Так как уникастный трафик имеет один входной и один выходной интерфейс, трафик переадресуется либо на уровне L2, либо на уровне L3 (Рис. 6). Так как мультикастный трафик может переадресовываться более чем через один выходной интерфейс, можно считать, что трафик в некоторых ветвях переадресуется на уровне L2, а в других на уровне L3 (Рис. 7).
Рис. 6. Уникастная переадресация на уровне L3 или L2
Рис. 7. Мультикастная переадресация на уровне L3, смешанном L2/L3 или L2 Узлы, которые поддерживают эту возможность смешанной переадресации L2/L3, позволяют расщеплять мультикастное дерево на ветви, с переадресацией L3 и L2. Переадресация L3 должна заботится о том, чтобы трафик не переадресовывался в ветви, которые уже получили свой трафик L2. Это может быть осуществлено, например, добавлением специального бита в записи мультикастинг таблицы маршрутизации. Хотя смешанная L2/L3-переадресация требует обработки трафика на уровне L3, нагрузка на устройство переадресации L3 обычно меньше, чем в случае узла исключительно уровня L3. Поддержка этой смешенной переадресации L2/L3 имеет следующие преимущества: a) Пусть LSR A (Рис. 8) является оконечным узлом для ветви к LSR B и узлом ветвления для LSR C. Смешанная переадресация L2/L3 допускает, чтобы ветвь к C не загружалась проблемой возврата на уровень L3 в LSR A
Рис. 8. Смешанная L2/L3-переадресация в узле A b) Допускает использование триггера, управляемого трафиком, с режимом рассылки меток Downstream Usolicited или Upstream on Demand, как это объяснено в разделе 5.3.1. 5. Систематика IP-мульткаст LSP триггеров Формирование LSP для мультикаст-потоков может быть запущено различными событиями (триггерами), которые могут быть отнесены к следующим стандартным категориям запуск запросом, запуск топологией и запуск трафиком.
5.1. Управление запросами Установление LSP может быть запущено путем перехвата исходящих (метка должна быть затребована нижестоящим LSR) или входящих (метка должна быть затребована вышестоящим LSR) управляющих сообщений. На рис. 9 проиллюстрированы эти два случая.
Входящие Исходящие Рис. 9. Запуск по запросу (перехват resp. входящих и исходящих управляющих сообщений) Нижестоящий LSR (LSR-Dn) посылает управляющее сообщение вышестоящему LSR (LSR-Up). В случае, когда входные управляющие сообщения перехватываются и модуль в LSR-Up решает установить LSP, он пошлет LSR-Dn команду LDP bind (режим Upstream nsolicited) или запрос LDP bind (режим Downstream on Demand). В настоящее время, для мультикастинга, мы можем идентифицировать два важных типа управляющих сообщений: мультикастные маршрутные сообщения и сообщения резервирования ресурсов. 5.1.2. Сообщения мультикаст-маршрутизации В принципе этот механизм может быть использован только мультикастинг протоколами маршрутизации, в которых применяется прямая сигнализация: например, сообщения Join в PIM-SM или CBT. Заметим, что DVMRP и PIM-DM могут быть адаптированы для поддержки этого типа запуска [FARI], однако ценой модификации самого протокола мультикаст-маршрутизации! IP-сообщения мультикаст-маршрутизации могут формировать как жесткие состояния (например, CBT Join + CBT Join-Ack) так и "мягкие состояния" (например, периодически посылаются сообщения PIM-SM Join). Последние генерируют больше управляющего трафика для поддержания дерева и таким образом требуют больше обработки в модуле. Запуски формирования маршрута, базирующиеся на сообщениях мультикастинг-протоколов маршрутизации, имеют недостаток, который заключается в том, что вычисление мультикастинг таблицы маршрутизации, выполняемые мультикастным маршрутным демоном, повторяются модулем. Первый определяет дерево, которое будет использоваться на уровне L3, последний вычисляет идентичное дерево, которое будет использоваться на уровне L2. Так как одна и та же задача решается дважды, лучше сформировать мультикастный LSP на основе информации, извлеченной из самой мультикастинг таблицы маршрутизации (смотри раздел 5.2 и 5.3). Вычисление маршрута становится более сложным для протоколов, которые поддерживают переключение от дерева (*, G) к дереву (S, G), так как нужно интерпретировать больше сообщений. Когда ЭВМ имеет соединение с первым маршрутизатором по схеме точка-точка, может быть сформированы LSP до конечных пользователей путем перехвата не только маршрутных мультикастинг-сообщений, но и сообщений IGMP Join/Prune ([FENN]). 5.1.3. Сообщения резервирования ресурсов В случае уникаста для запуска процесса формирования маршрута LSP могут использоваться сообщения RSVP Resv. Отправитель мультикастной группы пошлет вниз по дереву сообщение RSVP Path, получатели могут затем откликнуться сообщением RSVP Resv. RSVP хорошо адаптируется и для мультикастинга a) Сообщения RSVP Resv могут быть совмещены. 5.2. Управление топологией Мультикастинг таблица маршрутизации (MRT) поддерживается демоном протокола мультикастинг маршрутизации. Модуль устанавливает соответствие (мэпинг) этих топологических данных дерева L3 и маршрутов LSP L2 p2mp. Модуль может просматривать MRT с целью получения топологии дерева. В качестве альтернативы, мультикастный демон может быть модифицирован так, чтобы непосредственно информировать модуль о любых изменениях MRT. Недостатком этого метода является то, что метки расходуются даже тогда, когда трафик отсутствует.
5.3. Управление трафиком Метод запуск формирования маршрута с помощью трафика создает LSP для деревьев, по которым проходит трафик. Он расходует меньше меток, чем способ, запускаемый топологией, так как метки резервируются лишь тогда, когда через дерево проходит реальный трафик. Если смешанная переадресация L2/3 не поддерживается (смотри раздел 4), запуск формирования LSP от трафика требует установления режима рассылки меток, в котором метки запрашиваются LSR-Up (режим Downstream on Demand или Upstream Unsolicite). На рис. 10 предполагается, что для определенной группы существует LSP до LSR-Dn1, а другой LSR-Dn2 хочет присоединиться к дереву. Для того чтобы LSR-Dn2 инициировал формирование прохода, он должен уже получать трафик от этого дерева. Это может быть реализовано на L2 или L3. Первый вариант представляет собой проблему цыпленок-яйцо. В последнем случае для добавления ветви L3 необходима поддержка смешанной переадресации L2/L3 в LSR-Up.
Рис. 10. LSR-Up должен запросить метку. 5.3.2. Пример реализации Выбирая схему запуска, можно прийти к выводу, что мультикастинг не зависит от установленного мультикастного протокола маршрутизации. Современные реализации на Unix-платформах мультикастинг протоколов маршрутизации (DVMRP, PIM) имеют MFC (Multicast Forwarding Cache). MFC является кэшированной копией мультикастинг таблицы маршрутизации. MFC запрашивает рекорд для определенной мультикаст-группы, когда обнаруживает отсутствие нужной информации в кэше для входящего пакета. Недостающая маршрутная информация предоставляется мультикаст-демоном. Если позднее ситуация с маршрутами изменится (добавлен или удален выходной интерфейс), мультикаст-демон обновит MFC. MFC реализован как общая часть (ядра), которая делает этот вид запуска привлекательным, так как он может быть прозрачно использован для любого мультикастного протокола маршрутизации. Рекорды в MFC удаляются, когда нет трафика для этого рекорда в течение определенного периода времени. Когда используется коммутация по меткам для определенного рекорда MFC, уровень L3 вообще не будет видеть приходящих пакетов. Чтобы поддержать нормальную работу MFC, счетчики L3 MFC должны быть скорректированы с учетом измерений на уровне L2. 5.4. Комбинации режимов запуска и рассылки меток В таблице 2 приведены допустимые комбинации методов рассылки меток и запуска формирования LSP, которые были обсуждены в предыдущих разделах. (X) означает, что комбинация допустима, если LSR поддерживает смешанную переадресацию L2/L3. Таблица 2. Допустимые комбинации методов запуска и рассылки меток
6. Перенос меток (Piggy-backing) На рис. 9 (outgoing case) можно видеть, что вместо отправки двух отдельных сообщений, анонсирование метки может осуществляться посредством существующих управляющих сообщений. Для мультикастинга имеется два кандидата для транспортировки (piggy-back):
За и против транспортировки меток с привлечением мультикаст маршрутных сообщений рассматриваются ниже. Такой вид транспортировки имеет следующие преимущества:
Можно отметить следующие недостатки такого типа транспортировки:
Совмещенная транспортировка является лишь одним возможным компонентом мультикастного решения для. 7. Непосредственная маршрутизация Явная маршрутизация для уникастинга сопряжена с переписыванием уникастной маршрутной таблицы, с использованием LSP. " Мультикастная явная маршрутизация" может быть определена как перепись дерева, сформированного мультикастным протоколом маршрутизации, с привлечением другого дерева LSP (например, дерева Штайнера, вычисленного где-то off-line). В этой интерпретации современный мультикастинг протокол маршрутизации 'кратчайшего пути' становится устаревшим и может быть заменен сообщениями рассылки меток, которые следуют явным маршрутом (например, ветвь дерева Штайнера). Другой способ интерпретации "Мультикастная явная маршрутизация" предполагает, что работают мультикастные протоколы маршрутизации, но что сообщения, генерируемые этими протоколами, для формирования дерева используют явно уникастные маршруты (вместо кратчайших путей IGP).
8. QoS/CoS Концепция дифференцированных услуг может быть применена и к мультикастингу. Это приводит к более тонкой гранулированности потоков (DSCP в качестве дополнительного средства разделения потоков). Отправитель может сформировать одно или более деревьев с разными DSCP. Эти деревья (S,G, DSCP) или (*, G, DSCP) могут быть легко спроектированы на LSP, если используется механизм формирования пути, запускаемый трафиком. В этом случае можно сформировать LSP с разными атрибутами для разных DSCP. Заметим, однако, что эти LSP используют тот же маршрут, так как механизм формирования дерева не использовал значения DSCP. 8.2. IntServ и RSVP RSVP может использоваться для формирования мультикастных деревьев с заданным QoS. Важным следствием использования мультикастинга является проблема, как связать парадигму 'гетерогенных получателей' с уровнем L2 (заметим, что эта задача не решена и в IP). Этот предмет серьезно обсуждается в [CRAW]. Прагматическими подходами являются модель ограниченной гетерогенности, которая допускает уровень услуг "максимальных усилий" (best effort) и один уровень QoS (например, QoS, предложенный отправителем в сообщении RSVP Path) и гомогенная модель, которая допускает только один уровень QoS. Первый поход приводит к формированию полных деревьев для каждого класса услуг. Отправитель должен послать свой трафик в сеть дважды (например, 1 в дерево "максимальных усилий" и 1 - в дерево QoS). В обоих деревьях может использоваться коммутация по меткам. При втором подходе конструируется одно дерево и пользователи услуги "максимальных усилий" подключаются к дереву QoS. Если ветви, созданные для пользователей "максимальных усилий" не используют коммутацию по меткам, (таким образом, следуя шаг-за-шагом вдоль LSP), мультикастный QoS-трафик должен следовать этим LSP по умолчанию. Эта функция может быть предоставлена системой смешанной переадресации L2/L3, описанной в разделе 4. Если она недоступна, объединение необходимо, чтобы избежать возврата на L3 в QoS LSP. 9. Сети с множественным доступом Мультикастный в сетях с множественным доступом представляет собой определенную проблему. LSR, который хочет присоединиться к группе, должен всегда быть готов воспринять метку, которая уже приписана группе LSP. Это может быть достигнуто тремя путями:
В отличие от уникастного варианта, мультикастный поток может иметь более одного нижележащего LSR, которые все должны использовать одну и ту же метку. Можно обсуждать две схемы анонсирования меток:
Так как LSP оправданы, если они живут долго, и так как число LSR в используемом совместно канале ограничено, второй подход представляется предпочтительным. Другой момент, связанный с мультикастингом в сетях с множественным доступом, сопряжен с тем, следует ли использовать для присвоения меток вышестоящий или нижестоящий LSR. Для мультикастного трафика, использование вышестоящего LSR проще, так как там может быть только один вышестоящий узел, принадлежащий данному мультикастному дереву. Этот (вышестоящий) узел может присвоить уникальную метку для заданного FEC. Рассылка меток "вниз по течению" должна учитывать тот факт, что может быть много нижестоящих узлов в заданном дереве для канала с множественным доступом; каждый узел может предложить свою метку для FEC, что потребует некоторого разбирательства, чтобы каждому мультикастному FEC была присвоена лишь одна метка. Раз метка присвоена, может возникнуть ситуация, когда инициатор возникновения данной метки покинет данное дерево. В случае присвоения меток "вниз по течению", это может случиться, когда инициатор присвоения покинет группу. В случае присвоения меток "вверх по течению" это может случиться, когда в вышестоящем LSR происходят изменения, сопряженные с вариацией топологии рассылки уникастных сообщений.
10. Дополнительные выводы Поле TTL в IP-заголовке обычно используется для детектирования петель. В IP мультикастинге оно также используется для ограничения области распространения пакетов. Таким образом, в LSR, которые не поддерживают функция декрементации TTL (например, ATM LSR), функция ограничения области действия пострадает. Предположим, что можно вычислить заранее число шагов для заданного LSP. В уникастном LSP значение TTL может декрементироваться на входе или выходе из узла. В случае мультикаста все ветви дерева могут иметь разную длину, так что TTL может декрементироваться только на выходе, потенциально растрачивая полосу пропускания, если TTL окажется меньше или равным нулю. 10.2. Независимое управление рассылкой меток против упорядоченного Существующая терминология для рассылки меток определена лишь для уникастного случая. Далее рассматривается, какой смысл эти термины могут иметь в случае мультикастинга. При независимом управлении ([ANDE]) каждый LSR может взять на себя инициативу присвоения меток. При упорядоченном управлении ([ANDE]) LSR ассоциирует метку, когда он уже получил ее от последующего узла. Все описанные выше методы запуска процесса формирования дерева (раздел 5) имеют отношение к независимому управлению. Заметим, что если используется подход с запуском по запросу при независимом управлении, рассылка меток осуществляется, как если бы применялось упорядоченное управление: управляющие сообщения направляются от выходного узла "вверх по течению", реализуя ту же последовательность анонсирования меток. Упорядоченное управление не применимо для запуска, управляемого трафиком в случае, когда узел не поддерживает смешенную L2/L3 переадресацию. Согласно таблице 2, этот случай предполагает, что метки запрашиваются вышестоящим LSR. Предположим, что на рис. 11 имеется LSP от S до R1 и нужно проложить новую вервь до R2. B будет воспринимать метки канала A - B только если они уже ассоциированы с каналом B-C. Однако для того чтобы определить метку для канала B-C, B должен уже получать трафик со стороны канала A-B.
Рис. 11. 10.3. Режимы консервативного и либерального удержания меток В консервативном режиме ([ANDE]) только метки, которые используются для переадресации (если следующим шагом для FEC является LSR, который анонсировал метку), присваиваются и поддерживаются. В либеральном режиме метки анонсируются и поддерживаются для всех соседей. Либеральный режим не чувствителен к мультикастингу. Для этого имеется две причины:
В таблице 3 показаны случаи, когда LSR знает, куда посылать запрос на метку. Таблица 3. Знает ли LSR, куда посылать запросы меток?
Для уникастного потока, LSR могут определить LSR следующего шага, которому следует послать запрос в случае режима работы Upstream Unsolicited или Downstream on Demand. LSR, однако, не может определить маршрутизатор предшествующего шага. Предыдущий шаг необязательно является следующим шагом в направлении отправителя, так как путь от A к B не обязательно совпадает с путем от B к A. Такая ситуация может случиться в результате асимметричных метрик в канале или в случае, когда имеется несколько маршрутов с идентичной метрикой [PAXS]. В случае мультикастинга, LSR знает как следующий шаг, так и предыдущий. Так как мультикастные деревья формируются реверсивным методом кратчайших путей, предшествующим шагом всегда является следующий узел по направлению к отправителю или корню дерева. 10.4. Выделение меток "вверх и вниз по течению" Метка может быть выделена либо нижестоящим LSR (режимы Downstream on Demand, Downstream Unsolicited) или вышестоящим LSR (режимы Upstream on Demand, Upstream Unsolicited, неявный). Преимущества выделения меток "вниз по течению" перечислены ниже:
Преимущество присвоения меток вышестоящим объектом заключаются в следующем:
10.5. Явная и неявная рассылки меток Помимо режимов явной рассылки меток (которые используют сигнальный протокол), [ACHA] предлагается метод неявной рассылки меток, использующий неизвестные метки. Этот метод имеет все преимущества выделения меток "вверх по течению" и является, вероятно, самым быстродействующим способом анонсирования меток для запуска формирования LSP трафиком. Неявная рассылка меток не применима, если ассоциация FEC-метка была анонсирована до прихода трафика, например, явная маршрутизация (т.е. если в пакете нет всей необходимой информации, чтобы идентифицировать FEC). Явная рассылка меток допускает предварительное установление LSP (до прихода данных) по топологии или по запросу. Ссылки [ACHA] A.
Acharya, R. Dighe и F. Ansari, "IP Switching Over Fast ATM Cell Transport
(IPSOFACTO) : Switching Multicast flows", IEEE Globecom '97. [ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress. [ANDE] Andersson, L., Doolan, P., Feldman, N., Fredette, A. и R. Thomas, "LDP Specification", RFC 3036, January 2001. [AWDU] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. yes"> и V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997. [CONT] Conta, D., Doolan, P. и A. Malis, "Use of Label Switching on Frame Relay Networks", RFC 3034, January 2001. [CRAW] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M. и J. Krawczyk, "A Framework for Integrated Services и RSVP over ATM", RFC 2382, August 1998. [DAVI] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. и P. Doolan, "MPLS using LDP и ATM VC switching", RFC 3035, January 2001. [DEER] Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Handley, M., Jacobson, V., Liu, C., Sharma, P. и L Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [FARI] D. Farinacci, Y. Rekhter, E. Rosen и T. Qian, "Using PIM to Distribute MPLS Labels for Multicast Routes", Work In Progress. [FENN] Fenner, W., "Internet Group Management Protocol, IGMP, Version 2", RFC 2236, November 1997. [GARR] Garrett, M. и M. Borden, "Interoperation of Controlled-Load Service и Guaranteed Service with ATM", RFC 2381, August 1998. [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress. [MOY] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. [NAGA] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. и P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001. [PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress. [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work In Progress. [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking 5(5), pp. 601-615. [ROSE] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. и A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.20 Требования для управления трафиком
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
4.4.19 Кодирование меток в MPLS
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
E. Rosen, RFC-3032, MPLS Label Stack Encoding Аннотация "Многопротокольная коммутация меток (MPLS)" [1] требует наличия набора процедур для пакетов со стеком меток (помеченных пакетов). Маршрутизаторы, которые поддерживают MPLS, называются LSR (Label Switching Routers). Для того чтобы переслать помеченный пакет по конкретному каналу, LSR должен поддерживать систему представления стека меток и обработки пакетов сетевого уровня. В данном документе специфицирована система представления стека меток, используемая LSR, для того чтобы передавать помеченные пакеты по каналам PPP (Point-to-Point Protocol), по каналам данных LAN, и возможно по другим каналам. В других каналах кодирование может быть иным, но представление стека меток должно быть стандартным. Здесь также специфицируются правила и процедуры для обработки различных полей записей в стеке меток. 1. Введение "Многопротокольная коммутация меток (MPLS)" [1] требует набора процедур для дополнения пакетов сетевого уровня "стеком меток", таким образом превращая их в помеченные пакеты. Маршрутизаторы, которые поддерживают протокол MPLS, называются LSR (Label Switching Routers). Для того чтобы передать помеченный пакет по определенному каналу, LSR должен поддерживать методику кодирования, и анализа помеченных пакетов. Данный документ специфицирует кодирование, используемое LSR, для того чтобы передать помеченный пакет по каналу данных PPP и LAN. Специфицированная кодировка может быть применена и в других каналах данных. Этот документ специфицирует также правила и процедуры обработки различных полей стека меток. Так как MPLS не зависит от сетевого протокола, большинство таких процедур являются протокольно независимыми. Некоторые, однако, являются разными для различных протоколов. В этом документе, мы специфицируем протокольно независимые процедуры, а также протокольно зависимые процедуры для IPv4 и IPv6. LSR, которые реализованы на определенном коммутационном оборудовании (таком как ATM-коммутаторы) могут использовать различные системы кодирования верхних записей в стеке. 2. Стек меток 2.1. Кодирование стека меток Стек меток представляет собой последовательность записей. Каждая запись в стек имеет длину 4 октета. Формат такой записи показан на рис. 1.
Рис. 1. Формат записи стека меток Запись стека меток размещается после заголовка канального уровня, и перед заголовком сетевого уровня (например, между Ethernet- и IP-заголовком). Верх стека записывается первым, а дно - последним. Сетевой заголовок следует сразу вслед за записью стека меток с битом S=1. Каждая запись стека меток содержит в себе следующие поля: 1. Дно стека (S) Этот бит устанавливается равным 1 для последней записи в стеке меток (т.e., для дна стека), и нулю для всех прочих записей. Замечание переводчика . Следует заметить, что данный формат меток не является единственно возможным (я здесь не имею в виду ATM или FR). В IP-телефонии, например, предлагается использовать метку, которая содержит (слева-направо) код 0х8100, за которым идет 3-битовое поле приоритета (0-7) и идентификатор VPN (0-4095). Смотри журнал LANline N10, 2002, стр 140). 2. Время жизни (TTL) Это 8-битовое поле служит для представления значения времени жизни пакета. Обработка этого поля описана в разделе 2.4. 3. Экспериментальное поле Это 3-битовое поле зарезервировано для экспериментальных целей (QoS). 4. Значение метки Это 20-битовое поле несет в себе код метки. Когда получен помеченный пакет, анализируется значение метки на верху стека. В результате этого анализа определяется: a) следующий шаг, куда должен быть переадресован пакет; b) операция, которая должна быть выполнена со стеком меток до переадресации; эта операция может быть заменой метки на вершине стека, или удаление записи из стека, или замещение верхней позиции в стеке и занесение туда затем одной или более новых записей. В дополнение к определению следующего шага и операции со стеком меток, можно также получить данные об инкапсуляции выходной информации, и возможно другие данные, которые необходимы, для того чтобы корректно переадресовывать пакеты. Существует несколько зарезервированных значений меток: i. Значение 0 представляет "IPv4 Explicit NULL Label". Это значение метки является единственно допустимым для дна стека меток. Оно указывает, что стек должен быть очищен, и переадресация пакета должна основываться на IPv4-заголовке. ii. Значение 1 представляет "Router Alert Label". Это значение метки является легальным в любом месте стека меток за исключением дна. Когда полученный пакет содержит такую метку на вершине стека, он доставлен локальному модулю для обработки. Действительная переадресация пакета определяется меткой, в его стеке. Однако, если пакет переадресуется дальше, еще до переадресации в стек должна быть занесена метка Router Alert. Использование этой метки сходно с применением опции "Router Alert" в IP-пакетах [5]. Так как эта метка не может лежать на дне стека, она не ассоциируется с определенным протоколом сетевого уровня. iii. Значение 2 представляет "IPv6 Explicit NULL Label". Это значение метки является единственно допустимым для записи на дне стека. Оно указывает, что стек должен быть очищен, а переадресация пакетов должна после этого основываться на заголовке IPv6. iv. Значение 3 представляет "Implicit NULL Label". Это метка, которую LSR может присваивать и рассылать, но которая в действительности никогда не используется при инкапсуляции. Когда LSR замещает метку на верху стека на новую, и эта новая метка является "Implicit NULL", LSR очистит стек вместо того, чтобы осуществить замену. Хотя это значение не может появиться при инкапсуляции, оно должно быть специфицировано в протоколе рассылки меток, так что значение может считаться зарезервированным. v. Значения 4-15 зарезервированы. 2.2. Определение протокола сетевого уровня Когда последняя метка удалена из стека (стек становится пустым), дальнейшая обработка пакета осуществляется на основе его заголовка сетевого уровня. LSR, который извлекает последнюю метку из стека, должен быть способен работать с протоколом сетевого уровня. Однако, стек меток не содержит поля, идентифицирующего протокол сетевого уровня. Это означает, что идентичность сетевого протокола должна определяться по значению кода метки, извлеченной со дна стека, возможно, вместе с самим содержимым заголовка сетевого уровня. Следовательно, когда в сетевой пакет заносится первая метка, она должна быть уникальной для конкретного сетевого уровня или для набора сетевых протоколов. Кроме того, когда бы в процессе передачи метка ни была заменена другой, новая метка также должна отвечать тем же критериям. Если эти условия не выполнены, LSR, который удаляет последнюю метку из пакета, не сможет идентифицировать сетевой протокол. Строгое соблюдение этих условий не обязательно приведет немедленно к тому, что узлы будут распознавать сетевой протокол. В обычных условиях, это необязательно, но в ситуациях ошибок это оказывается крайне желательным. Например, если промежуточный LSR определяет, что помеченный пакет не может быть доставлен, может быть желательно для данного LSR сформировать сообщение об ошибке, которое является специфическим для пакетов сетевого уровня. Единственные средства, которыми располагает промежуточный LSR для идентификации сетевого уровня, является анализ верха стека и заголовка сетевого уровня. Таким образом, если промежуточные узлы способны посылать протокольно зависимые сообщения об ошибках для помеченных пакетов, все метки в стеке должны отвечать критериям, приведенным выше для меток, которые занесены на дно стека. Если пакет не может быть переадресован по какой-то причине (например, его размер превосходит MTU канала), и либо его протокол сетевого уровня не может быть идентифицирован, либо не существует протокольно зависимых правил для обработки случаев ошибок, тогда пакет должен быть без комментариев отброшен.
2.3. Генерация ICMP-сообщений для помеченных пакетов В разделах 2.4 и 3 обсуждаются ситуации, в которых желательно формировать ICMP-сообщения для помеченных IP-пакетов. Для того чтобы конкретный LSR мог формировать и посылать ICMP пакеты отправителям IP-пакетов, должны выполняться два условия: 1. Данный LSR должен быть способен определить, что конкретный помеченный пакет является IP-пакетом. 2. Данный LSR должен быть способен проложить путь до места назначения IP-пакета. Условие 1 обсуждается в разделе 2.2. В следующих двух подразделах обсуждается условие 2. Однако встречаются ситуации, когда условие 2 совсем не выполняется, и в этих случаях невозможно сформировать сообщение ICMP. 2.3.1. Туннелирование через транзитную область маршрутизации Предположим, что MPLS используется для организации туннеля через транзитную область маршрутизации, где данные о внешних маршрутах не попадает к внутренним маршрутизаторам. Например, внутренние маршрутизаторы работают с протоколом OSPF, и могут только знать, как достичь объектов в пределах зоны OSPF. Домен может содержать несколько пограничных маршрутизаторов автономной системы ASBR (Autonomous System Border Routers), которые взаимодействуют друг с другом с помощью BGP. Однако в этом примере маршруты от BGP не рассылаются OSPF, и LSR, которые не являются ASBR, поддерживают BGP. В этом примере, только ASBR будет знать, как проложить маршрут до отправителя некоторого произвольного пакета. Если внутренний маршрутизатор должен послать сообщение ICMP отправителю IP-пакета, он не будет знать как маршрутизовать это ICMP-сообщение. Одним из решений является занесение ASBR маршрута по умолчанию в IGP. Это бы гарантировало то, что любой непомеченный пакет, который должен выйти из домена (такой как ICMP-пакет), попадет в маршрутизатор, который имеет полную маршрутную информацию. Маршрутизаторы с полной маршрутной информацией будет помечать пакеты, прежде чем их послать через транзитную область, так что использование маршрутов по умолчанию в пределах транзитного домена не приводило к образованию циклических путей. Это решение работает только для пакетов, которые имеют глобально уникальные адреса, и для сетей, в которых все ASBR имеют полную маршрутную информацию. В следующем подразделе описывается решение, которое работает, когда эти условия не выполняются. 2.3.2. Туннелирование частных адресов через общедоступную опорную сеть В некоторых случаях, когда MPLS используется для туннелирования через домен маршрутизации, может быть вообще невозможно проложить путь до адреса отправителя фрагментированных пакетов. Такая ситуация возникла бы, например, если IP-адреса в пакетах были частными адресами (т.e., не были глобально уникальными), и MPLS использовался для туннелирования таких пакетов через общедоступную опорную сеть. Маршруты по умолчанию в ASBR не будет работать в таких условиях. В этих условиях, для того чтобы послать ICMP-сообщение отправителю пакета, можно копировать стек меток исходного пакета в ICMP-сообщение, и затем осуществить коммутацию по меткам для ICMP-пакета. Это заставит сообщение двигаться в направлении места назначения исходного пакета, а не его отправителя. Если только сообщение не является коммутируемым по меткам на всем пути до ЭВМ назначения, оно завершит путь непомеченным в маршрутизаторе, который знает путь до отправителя исходного пакета, отсюда сообщение будет послано в правильном направлении. Эта технология может быть весьма полезной, если ICMP-сообщением является "Time Exceeded" (время истекло) или "Destination Unreachable because fragmentation needed and DF set" (место назначение недостижимо из-за необходимости фрагментации и DF=1). При копировании стека меток из исходного пакета в сообщение ICMP, значения меток должны копироваться точно, но значения TTL должны устанавливаться равными величине, размещенной в IP-заголовке ICMP-сообщения. Это значение TTL должно быть достаточным, чтобы позволить кружной маршрут, которому должен следовать ICMP-сообщение. Заметим, что если истечение TTL сопряжено с наличием петли маршрута, тогда в случае использования этой техники, ICMP-сообщение может циклить. Так как сообщение ICMP никогда не посылается в ответ на ICMP-пакет, и так как многие реализации ограничивают частоту посылки ICMP-сообщений, проблем это создать не должно. 2.4. Обработка поля времени жизни 2.4.1. Определения "Входное TTL" помеченного пакета по определению должно равняться значению поля TTL в записи наверху стека меток на момент получения пакета. "Выходное TTL" помеченного пакета по определению должно равняться большему из: a) входное значение TTL минус один, b) нуль. 2.4.2. Протокольно независимые правила Если выходное TTL помеченного пакета =0, тогда помеченный пакет не должен более переадресовываться и пакет следует далее непомеченным. Время жизни пакета в сети считается истекшим. В зависимости от значения метки в стеке, пакет может быть просто отброшен, или он может быть передан сетевому слою для обработки ошибки (например, для генерации ICMP сообщения об ошибке, смотри раздел 2.3). Когда помеченный пакет переадресуется, поле TTL записи наверху стека меток должно быть установлено равным выходному значению TTL. Заметим, что выходное значение TTL является функцией входного значения TTL, и зависит оттого, были ли перед этим в стек занесены или извлечены какие то метки до переадресации пакета. Значения поля TTL в записях, за исключением верхней, никакого влияния не оказывают. 2.4.3. Правила, зависящие от IP Мы определяем поле "IP TTL" равным величине поля IPv4 TTL, или значению поля IPv6 Hop Limit, в зависимости оттого, что используется. Когда IP-пакет помечен впервые, поле TTL в стеке должно быть установлено равным значению поля IP TTL. Когда все метки извлекаются из стека, и он оказывается пустым, значение поля IP TTL должно быть замещено величиной выходного TTL, как это определено выше. В случае IPv4 это потребует также корректировки контрольной суммы IP заголовка. Признается, что могут существовать ситуации, когда сетевая администрация предпочитает декрементировать IPv4 TTL на 1 при прохождении через домен MPLS, вместо того чтобы декрементировать IPv4 TTL на число LSR в домене. 2.4.4. Преобразование различных инкапсуляций Иногда LSR может получить помеченный пакет через, например, интерфейс ATM (LC-ATM) [9], и должен будет послать его через PPP или LAN. Тогда входной пакет будет получен без инкапсуляции, описанной в данном документе, а будет послан уже с применением такой инкапсуляции. В этом случае значение "входное TTL" определяется процедурами обработки помеченных пакетов, например, в интерфейсе LC-ATM. Обработка TTL будет тогда происходить так, как это описано выше. Иногда LSR может получить помеченный пакет через канал PPP или LAN, и должен его послать на выход через интерфейс LC-ATM. Тогда входной пакет будет принят с использованием инкапсуляции, описанной в данном документе, а выходной пакет послан с привлечением иной инкапсуляции. В этом случае процедура формирования значения "выходного TTL" определяется процедурами, применяемыми к помеченным пакетам, например, в интерфейсах LC-ATM. 3. Фрагментация и определение MTU пути Поскольку возможно получение непомеченной IP-дейтограммы, которая слишком велика, чтобы быть передана в выходной канал, имеется возможность получения помеченного пакета, который также невозможно передать по этой причине на выход. Возможно также, что полученный пакет (помеченный или нет), который первоначально был достаточно мал для передачи через канал, становится слишком большим, получив одну или более меток. При коммутации меток, пакет может расти в размере, если в его стек заносятся дополнительные метки. Таким образом, если получен помеченный пакет с 1500-байтовым полем данных, и в него записана дополнительная метка, переадресовать нужно будет пакет с размером 1504-байта. В этом разделе специфицируются правила обработки помеченных пакетов, которые являются "слишком большими". В частности, речь идет о правилах, которые гарантируют, что ЭВМ, использующие определение MTU пути [4], и ЭВМ, работающие с IPv6 [7,8], будут способны формировать IP-дейтограммы, которые не нуждаются в фрагментации, даже если эти дейтограммы получили дополнительные метки при прохождении через сеть. Вообще, ЭВМ IPv4, которые не используют определение MTU пути [4], посылают IP-дейтограммы, содержащие не более 576 байт. Так как большинство используемых MTU равняются 1500 байт или больше, вероятность того, что такие дейтограммы будут нуждаться в фрагментации, даже если они помечены, весьма мала. Некоторые ЭВМ, которые не используют определение MTU пути [4], формируют IP-дейтограммы, содержащие 1500 байт. Поскольку IP-адреса отправителя и получателя в одной и той же субсети, эти дейтограммы не проходят через маршрутизаторы, и, следовательно, не будут фрагментироваться Если же IP-адрес отправителя и получателя находятся в разных автономных системах, это единственный случай, когда имеется риск фрагментации при пометке пакета. В этом документе специфицированы процедуры, которые позволяют конфигурировать сеть так, что большие дейтограммы от ЭВМ, не использующих определение MTU пути, фрагментируются только раз, когда они впервые помечены. Эти процедуры делают возможным избежать фрагментации пакетов, которые уже помечены. 3.1. Терминология Что касается конкретного канала данных, можно использовать следующие термины: - Поле данных кадра: Содержимое поля данных кадра, исключая любые заголовки и поля завершения кадра (например, MAC-заголовки, LLC-заголовки, 802.1Q-заголовки, PPP-заголовки, контрольные суммы, и т.д.). Когда кадр несет в себе непомеченную IP-дейтограмму, поле данных кадра представляет собой саму IP-дейтограмму. Когда кадр несет в себе помеченную IP-дейтограмму, поле данных кадра состоит из записей стека меток и IP-дейтограммы. - Обычный максимальный размер поля данных кадра: Максимальный размер поля данных кадра определяется стандартами канала данных. Например, обычный максимальный размер поля данных кадра для Ethernet равен 1500 байтов. - Истинный максимальный размер поля данных кадра: Максимальный размер поля данных кадра, который можно послать и получить через интерфейс канала данных. Для сетей Ethernet и 802.3, считается, что истинный максимальный размер поля данных кадра на 4-8 байта больше обычного максимального размера поля данных (поскольку ни переключатель, ни бридж не могут увеличить размер заголовка в процессе транспортировки пакета до следующего узла сети). Например, считается, что большинство оборудования Ethernet может принимать и посылать пакеты, содержащие, по крайней мере, 1504 или даже 1508 байт, поскольку заголовок Ethernet не имеет полей 802.1Q или 802.1p. В каналах PPP, истинный максимальный размер поля данных кадра может быть неограниченным. - Эффективный максимальный размер поля данных для помеченных кадров: Это либо обычный максимальный размер поля данных кадра или истинный максимальный размер поля данных кадра, в зависимости от возможностей оборудования канала и размера заголовка канального уровня. - Первично помеченная IP-дейтограмма: Предположим, что непомеченная IP-дейтограмма получена конкретным LSR, и что LSR вводит метку в стек перед тем, как переадресовать эту дейтограмму. Такая дейтограмма будет называться первично помеченной в этом LSR IP-дейтограммой. - Ранее помеченная IP-дейтограмма: IP-дейтограмма, которая уже была помечена до того, как была получена конкретным LSR. 3.2. Максимальный исходный размер помеченной IP-дейтограммы Каждый LSR, который способен a) получать непомеченные IP-дейтограммы, b) добавлять метки в стек дейтограммы, и c) переадресовывать полученный в результате помеченный пакет, должен поддерживать конфигурационный параметр, называемый "максимальный размер первично помеченной IP-дейтограммы", который может быть установлен неотрицательным. Если этот конфигурационный параметр установлен равным нулю, он ни на что не влияет. Если он имеет положительное значение, то он используется следующим образом. Если: a) получена непомеченная IP-дейтограмма, и b) эта дейтограмма имеет в заголовке бит DF=0, и c) дейтограмма перед переадресацией должна быть помечена, и d) размер дейтограммы (до пометки) превышает значение данного параметра, тогда a) Дейтограмма должна быть разделена на фрагменты с размером не больше, чем указано в данном параметре, и b) Каждый фрагмент должен быть помечен и после этого переадресован. Например, если этот конфигурационный параметр установлен равным 1488, тогда любая непомеченная IP дейтограмма, содержащая более 1488 байт, будет фрагментирована до выполнения пометки. Каждый фрагмент будет способен передавать через канал 1500 байт, без последующей фрагментации, даже если в стек будет занесено до трех меток. Другими словами, установка этого параметра не равным нулю, позволяет исключить фрагментацию уже помеченных IP пакетов, но это может вызвать иногда фрагментацию первично помеченных IP-дейтограмм, когда это совсем не нужно. Заметим, что установка этого параметра не влияет на обработку IP-дейтограмм, которые содержат бит DF=1, следовательно, установка этого параметра не влияет на результат определения MTU пути. 3.3. Когда помеченная IP-дейтограмма слишком велика? Помеченная IP-дейтограмма, чей размер превышает обычный максимальный размер поля данных канала, может рассматриваться как "слишком большая". Помеченная IP-дейтограмма, чей размер превышает истинный максимальный размер поля данных кадра канала, через который она должна переадресоваться, считается "слишком большой". Помеченная IP-дейтограмма, которая не является "слишком большой" должна передаваться без фрагментации. 3.4. Обработка помеченных дейтограмм Ipv4, которые слишком длинны Если помеченная IPv4 дейтограмма "слишком велика", и бит DF в IP заголовке =1, тогда LSR может отбросить дейтограмму. Заметим, что отбрасывание таких дейтограмм является разумным, только если "Максимальный размер первично помеченной IP-дейтограммы" установлен равным ненулевому значению во всех LSR сети, способных добавлять метки в стек непомеченных IP-дейтограмм. Если LSR решает не отбрасывать помеченные IPv4-дейтограммы, которые слишком велики, или если в дейтограмме флаг DF=1, тогда должен быть выполнена следующая последовательность операций: 1. Удалить записи в стеке, чтобы получить IP-дейтограмму. 2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4). 3. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =0: a. Разбить ее на фрагменты, каждый из которых должен иметь размер, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля данных кадра. b. Преобразовать каждый фрагмент, снабдив его заголовком, который имела исходная дейтограмма. c. Переадресовать фрагменты. 4. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =1: a. Дейтограмма не должна переадресовываться. b. Сформировать ICMP-сообщение "Адресат недостижим": i. Установить значение поля [3] равным "Fragmentation Required and DF Set", ii. Установить значение поля Next-Hop MTU [4] равным разности между эффективным максимальным размером поля данных кадра и величиной N c. Если возможно, послать ICMP-сообщение "Адресат недостижим" отправителю отброшенной дейтограммы. 3.5. Обработка помеченных дейтограмм IPv6, которые слишком длинны Чтобы обработать помеченную IPv6-дейтограмму, которая слишком велика, LSR должен реализовать следующий алгоритм: 1. Удалить записи в стеке, чтобы получить IP-дейтограмму. 2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4). 3. Если IP-дейтограмма содержит более 1280 байтов (не считая записи стека меток), или, если она не содержит заголовка фрагмента, тогда: a. Сформировать ICMP-сообщение "Too Big Message", и установить значение поля Next-Hop MTU равным разности между эффективным максимальным размером поля данных кадра и величиной N. b. Если возможно, послать отправителю дейтограммы ICMP-сообщение "Too Big Message". c. Отбросить помеченную IPv6-дейтограмму. 4. Если IP-дейтограмма не длиннее 1280 октетов, и содержит заголовок фрагмента, тогда a. Преобразовать ее в фрагменты, каждый из которых должен быть по крайней на N байт меньше, чем эффективный максимальный размер поля данных кадра. b. Снабдить каждый фрагмент тем же помеченным заголовком, который имела исходная дейтограмма. c. Переадресовать фрагменты. Восстановление сообщения из фрагментов осуществляется конечным получателем. 3.6. Реализация с учетом определения MTU пути Описанные выше процедуры обработки дейтограмм, которые имеют в заголовке бит DF=1, но являются "слишком большими", связаны с процедурами определения MTU пути RFC 1191 [4]. ЭВМ, которые используют эти процедуры, определят MTU, который достаточно мал, чтобы позволить занесение в дейтограмму n маркеров, без необходимости фрагментации. Здесь n равно числу меток, заносимых на используемом пути через домен. Другими словами, дейтограммы от ЭВМ, которые используют определение MTU пути, никогда не потребуют фрагментации из-за занесения меток в заголовок. Заметим, что дейтограммы от ЭВМ, использующих определение MTU пути, имеют бит DF=1, и таким образом не могут быть фрагментированы в любом случае. Отметим также, что определение MTU пути будет работать корректно, только если в точке, где может потребоваться фрагментация помеченной IP-дейтограммы, возможна посылка отправителю ICMP сообщения "Destination Unreachable". Смотри раздел 2.3. Если невозможна посылка отправителю слишком большой дейтограммы ICMP-сообщения из MPLS "туннеля", но конфигурация сети предоставляет возможность LSR конца туннеля получать слишком большие пакеты, которые должны проходить через туннель, тогда: - LSR на передающем конце туннеля должен уметь определять MTU туннеля в целом. Он может это сделать путем посылки пакетов через туннель в направлении его приемной части, и выполняя процедуру определения MTU пути для этих пакетов. - Всякий раз, когда передающий конец туннеля должен посылать пакет в туннель, и этот пакет имеет DF=1, а его длина превышает значение MTU туннеля, передающий конец должен послать ICMP-сообщение "Destination Unreachable" узлу, приславшему пакет с кодом "Fragmentation Required and DF Set ", и полем Next-Hop MTU установленным так, как показано выше. 4. Передача помеченных пакетов через PPP Протокол PPP (Point-to-Point Protocol) [6] предоставляет стандартный метод транспортировки многопротокольных дейтограмм через каналы точка-точка. PPP определяет расширяемый протокол управления каналом и предлагает семейство протоколов управления сетью для установления и конфигурации различных протоколов сетевого уровня. В этом разделе определен протокол управления сетью для установления и конфигурации коммутации меток в канале PPP. 4.1. Введение PPP содержит три основные компонента: 1. Метод инкапсуляции мультипротокольных дейтограмм. 2. Протокол управления каналом LCP (Link Control Protocol ) установления, конфигурации и тестирования канала. 3. Семейство протоколов управления сетью для установления и конфигурирования различных протоколов сетевого уровня. Для того чтобы установить связь через канал точка-точка, каждый конец PPP канала должен сначала послать LCP-пакеты, чтобы сконфигурировать и протестировать канал. После того как канал установлен и согласованы опционные возможности, как это требует LCP, PPP должен послать пакеты "MPLS Control Protocol", чтобы разрешить посылку помеченных пакетов. Как только "MPLS Control Protocol" оказался открыт, можно посылать помеченные пакеты через канал. Канал будет оставаться сконфигурирован для коммуникаций, пока управляющие протокольные пакеты LCP или MPLS его не закроют, или пока не произойдет какое-то внешнее событие (сработает таймер пассивности или не вмешается сетевой администратор). 4.2. Протокол управления PPP для MPLS Протокол управления MPLS (MPLSCP) отвечает за разрешение/запрещение использования коммутации меток в канале PPP. Он использует тот же механизм обмена, что и протокол управления каналом LCP (Link Control Protocol). Пакеты MPLSCP не могут пересылаться до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Пакеты MPLSCP, полученные до достижения этой фазы, должны просто отбрасываться. Протокол управления MPLS тождественен протоколу управления каналом [6] за следующими исключениями: 1. Модификации кадра Пакет может использовать любые модификации базового формата кадра, которые были согласованы на фазе установления канала. 2. Поле протокола канального уровня В информационное поле пакета PPP вкладывается только один пакет MPLSCP, где поле протокола PPP содержит шестнадцатеричный код 8281 (MPLS). 3. Поле кода Используются только коды от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Прочие коды должны рассматриваться как нераспознанные и приводить к Code-Rejects. 4. Таймауты Пакеты MPLSCP не могут пересылаться, пока PPP не достигнет фазы протокола сетевого уровня. Реализация должна быть готова ждать окончания аутентификации и определения качества канала, прежде чем наступит таймаут в ожидании Configure-Ack или других откликов. 4.3. Посылка помеченных пакетов Прежде чем какие-либо пакеты будут посланы, PPP должен достичь фазы протокола сетевого уровня, и управляющий протокол MPLS должен стать активным (состояние Opened). В информационное поле пакета PPP вкладывается только один помеченный пакет, где поле протокола PPP содержит шестнадцатеричные значения кода тип 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальная длина помеченного пакета, переданного через канал PPP, та же что и максимальная длина информационного поля инкапсулированного пакета PPP. Заметим, что определены два кода для помеченных пакетов, один для мультикастных и один для уникастных. Как только MPLSCP переходит в рабочее состояние (Opened), по каналу PPP могут посылаться как мультикаст, так и уникаст-пакеты. 5. Пересылка помеченных пакетов в среде LAN В каждом кадре транспортируется только один помеченный пакет. Записи стека меток размещаются непосредственно после заголовка сетевого уровня, а сразу за ними следует заголовок канального уровня, включая, например, любые заголовки 802.1Q, которые только могут существовать. Шестнадцатеричный код Ethertype 8847 используется для индикации того, что кадр содержит уникастный MPLS-пакет. Шестнадцатеричный код Ethertype 8848 служит для указания того, что кадр содержит MPLS-пакет. Эти значения Ethertype могут быть использованы либо при Ethernet-инкапсуляции, либо при инкапсуляции 802.3 LLC/SNAP для транспортировки помеченных пакетов. Процедура выбора одной из этих инкапсуляций находится вне пределов рассмотрения данного документа. 6. Соображения IANA Значения меток 0-15 включительно имеют специальное назначение, как это определено в данном документе, или как позднее будет задано IANA. В этом документе, значения меток 0-3 специфицированы в разделе 2.1. Значения меток 4-15 могут быть определены IANA, на основе согласия с IETF. 7. Соображения безопасности Инкапсуляция MPLS, которая специфицирована здесь, не предполагает какой-либо дополнительной безопасности, помимо той, что заложена в архитектуре MPLS [1] или в структуре протокола сетевого уровня. Существует два соображения безопасности, следующие из архитектуры MPLS и рассматриваемые здесь: - Некоторые маршрутизаторы могут реализовать процедуры безопасности, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Эти процедуры не будут работать, когда используется MPLS-инкапсуляция, так как эта инкапсуляция имеет варьируемый размер. - Метка MPLS имеет силу в результате соглашения между LSR, который заносит метку в стек ("автор метки"), и LSR, который интерпретирует эту метку ("читатель метки"). Однако стек меток не предлагает никаких средств определения того, кто является автором конкретной метки. Если помеченные пакеты восприняты от ненадежных источников, результатом может стать то, что пакеты будут маршрутизированы незаконным образом. 8. Библиография [1] Rosen, E., Viswanathan, A., и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [4] Mogul, J. и S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [7] Conta, A. и S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995. [8] McCann, J., Deering, S. и J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. и G. Swallow, "MPLS Using LDP и ATM VC Switching", RFC 3035, January 2001. |
|
Previous:
4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
|
4.4.20 Требования для управления трафиком
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
D. Awduche, Requirements for Traffic Engineering Over MPLS, RFC-2702 1.0. Введение Мультипротокольная коммутация пакетов по меткам (MPLS) [1,2] интегрирует в себе технику операций с метками и сетевую маршрутизацию. Базовой идеей является присвоение меток фиксированной длины пакетам на входе облака MPLS (базирующегося на концепции переадресации классов эквивалентности [1,2]). Всюду внутри домена MPLS, метки, присвоенные пакету, используются для принятия решения о переадресации (обычно без рассмотрения исходных заголовков пакета). Одним из наиболее важных применений MPLS будет управление трафиком. Важность этого приложения является уже широко признанной (смотри [1,2,3]). Этот документ ориентирован исключительно на управление трафиком (Traffic Engineering) в рамках MPLS. Главной целью является рассмотрение требований управления трафиком в больших опорных сетях Интернет. Описаны базовые возможности и функциональности, которым должна соответствовать реализация MPLS. Следует заметить, что хотя основное внимание уделено опорным сетям, возможности, описанные в этом документе, в равной мере применимы для управления трафиком в корпоративных сетях. Вообще, эта технология может быть использована в любой сети с коммутацией по меткам, в которой имеется, по крайней мере, два пути между двумя узлами. Предлагается архитектура, которая включает в себя MPLS и RSVP, чтобы предоставить масштабируемые дифференцированные услуги и управление трафиком в Интернет. 2.0. Управление трафиком В этом разделе описываются базовые функции управления трафиком в автономной системе современного Интернет. Рассмотрены ограничения IGP с точки зрения управления трафиком и ресурсами. В этом разделе обосновываются требования, предъявляемые к MPLS. Управление трафиком (TE) связано с оптимизацией рабочих характеристик сетей. Вообще, ТЕ включает в себя технологию и научные принципы измерения, моделирования, описание, управление трафиком Интернет и приложение таких знаний и техники для получения определенных рабочих характеристик. Главной целью управления трафиком в Интернет является достижение эффективной и надежной работы сети. Управление трафиком стало непременной функцией многих автономных систем, из-за высокой стоимости услуг Интернет. 2.1. Объективные характеристики управления трафиком Ключевые характеристики, сопряженные с управлением трафиком, могут относиться к следующим категориям: 1. ориентированные на трафик или 2. ориентированные на ресурсы. Задачи, ориентированные на управление трафиком, включают в себя аспекты улучшения QoS информационных потоков. В модели "оптимальных усилий" для Интернет-сервиса ключевая задача управления трафиком включает в себя: минимизацию потерь пакетов и задержек, оптимизацию пропускной способности и согласование наилучшего уровня услуг. В данной модели минимизация вероятности потери пакетов является наиболее важным аспектом. Статистически заданные характеристики трафика (такие как разброс времени доставки пакетов, вероятность потери и максимальное время доставки) становятся важными в грядущих дифференцированных услугах Интернет. Одним из подходов решения таких проблем является оптимизация использования всех имеющихся ресурсов сети. В частности, желательно гарантировать, чтобы субнаборы сетевых ресурсов не были перегружены, в то время как аналогичные ресурсы на альтернативных маршрутах недогружены. Полоса пропускания является критическим ресурсом современных сетей. Следовательно, центральной функцией управления трафиком является эффективное управление пропускной способностью. Минимизация перегрузок является первичной задачей. Здесь речь идет не о кратковременных перегрузках, а о долгосрочных, влияющих на поведение сети в целом. Перегрузка обычно проявляется двояко: 1. Когда сетевых ресурсов недостаточно или они не соответствуют существующей загрузке. 2. Когда потоки трафика неэффективно распределены по имеющимся ресурсам. Первый тип проблем перегрузки может быть решен путем: (i) расширения ресурса, или (ii) применением классических средств управления перегрузкой, или (iii) сочетанием этих подходов. Классическое управление перегрузкой пытается регулировать уровень потребности, снижая его до имеющегося в распоряжении уровня ресурсов. Классическое управление перегрузкой включает в себя: ограничение потока, управление шириной окна для потока, управление очередями в маршрутизаторе, диспетчеризацию и т.д. (смотри [8]). Второй тип проблем перегрузки, связанный с неэффективным размещением ресурсов, может быть решен посредством управления трафиком. Вообще, перегрузка, связанная с неэффективным размещением ресурсов, может быть уменьшена с помощью политики балансировки нагрузки в различных фрагментах сети. Задачей таких стратегий является минимизация максимальной перегрузки или напротив минимизация максимума использования ресурса. Когда перегрузка минимизирована путем оптимального размещения ресурсов, потери пакетов и задержка доставки падают, а совокупная пропускная способность возрастает. Таким образом, восприятие конечным пользователем качества сетевого обслуживания становится лучше. Понятно, что балансировка определяет политику оптимизации рабочих характеристик сети. Не смотря ни на что, возможности, предоставляемые управлением трафиком, должны быть достаточно гибкими, чтобы сетевые администраторы могли реализовать другие политики, которые принимают во внимание господствующую структуру цен или даже модель получения доходов. 2.2. Управление трафиком и ресурсами Оптимизация рабочих характеристик сетей является фундаментальной проблемой управления. В модели процесса управления трафиком, инженер трафика, или подходящая система автоматизации, действует как контроллер в системе с адаптивной обратной связью. Эта система включает набор взаимосвязанных сетевых элементов, систему мониторирования состояния сети, и набор средств управления конфигурацией. Инженер трафика формулирует политику управления, отслеживает состояние сети посредством системы мониторинга, характеристики трафика, и предпринимает управляющие действия, чтобы перевести сеть в требуемое состояние, в соответствии с политикой управления. Это может быть осуществлено с помощью действий, предпринимаемых как отклик на текущее состояние сети, или превентивно, используя прогнозирование состояния и тенденции и предпринимая действия, предотвращающие нежелательные будущие состояния. В идеале управляющие действия должны включать: 1. Модификацию параметров управления трафиком, 2. Модификацию параметров, связанных с маршрутизацией, и 3. Модификацию атрибутов и констант, связанных с ресурсами. Уровень человеческого вмешательства в процесс управления трафиком, когда это возможно, должен быть минимизирован. Это может быть реализовано путем автоматизации операций, описанных выше. Операции эти могут быть распределенными и масштабируемыми. 2.3. Ограничения механизмов управления IGP В этом подразделе рассматриваются некоторые хорошо известные ограничения современных IGP с точки зрения управления трафиком. Возможности управления, предлагаемые существующими внутренними протоколами маршрутизации шлюзов Интернет, не соответствуют требованиям управления трафиком. Это делает трудным актуализировать эффективные политики, предназначенные для решения проблем совершенствования работы сети. Действительно, IGP, базирующиеся на алгоритмах кратчайшего пути, вносят заметный вклад в проблемы перегрузки в автономных системах Интернет. Алгоритмы SPF базируются на простой аддитивной метрике. Эти протоколы управляются топологией, так что полоса пропускания и параметры трафика не являются факторами, рассматриваемыми в процессе принятия маршрутных решений. Следовательно, перегрузка часто происходит, когда: 1. кратчайшие пути нескольких потоков трафика объединяются в каких-то каналах или интерфейсах маршрутизатора, или 2. данный трафик потока маршрутизирован через канал или интерфейс маршрутизатора, который не имеет достаточной полосы пропускания. Эти сценарии проявляются даже тогда, когда имеются альтернативные маршруты с избытком ресурсов. Это является тем аспектом проблем перегрузки (симптом неоптимального распределения ресурсов), которой управление трафиком стремится всеми способами избежать. Равномерное распределение загрузки может использоваться для разрешения второй проблемы, упомянутой выше, однако такое решение бесполезно в случае первого варианта перегрузки. Популярным подходом преодоления недостатков современных IGP является использование модели наложений, таких как IP поверх ATM или IP поверх frame relay. Модель наложений расширяет пространство для маневра, делая возможным произвольные виртуальные топологии, накладываемые поверх реальной физической сети. Виртуальная топология формируется из виртуальных каналов, которые проявляются как физические каналы в протоколах маршрутизации IGP. Модель наложений предоставляет дополнительные важные услуги для поддержания управления трафиком и ресурсами, включая: (1) маршрутизацию, базирующуюся на ограничениях в рамках VC, (2) поддержку административно конфигурируемых VC-путей, (3) сжатие маршрута, (4) функции управления доступом, (5) формирование трафика и функции реализации политики при управлении трафиком, и (6) надзор за VC. Эти возможности допускают реализацию самых разных политик в сфере управления трафиком. Например, виртуальные каналы могут легко перемаршрутизироваться, чтобы перенаправить трафик в менее загруженные каналы. Для управления трафиком в больших насыщенных сетях желательно снабдить MPLS определенным уровнем функциональности, чтобы сделать его более совместимым с настоящими моделями наложений. К счастью, это может быть сделано достаточно прямолинейно. 3.0. MPLS и управление трафиком В этом разделе дается обзор применимости MPLS для управления трафиком. В последующих разделах обсуждается набор возможностей, необходимых для удовлетворения требований управления трафиком. Протокол MPLS стратегически достаточен для управления трафиком, так как он может предоставить большую часть функций, доступных в модели наложений, и по относительно низкой цене по сравнению с конкурирующими альтернативными решениями. Столь же важно, что MPLS предлагает возможность автоматизировать функции управления трафиком. Это последнее соображение требует дальнейшего исследования и находится за пределами рассмотрения данного документа. Концепция каналов передачи данных MPLS используется достаточно широко в данном документе. Согласно Li и Rekhter [3], канал передачи данных представляет собой объединение потоков данных одного и того же класса, которые следуют маршруту с коммутацией пакетов по меткам. Канал передачи данных представляет собой абстракцию трафика, с которой могут быть ассоциированы определенные характеристики. Полезно рассматривать каналы передачи данных как объекты, которые можно маршрутизировать, то есть, путь, по которому переносятся данные, может меняться. С этой точки зрения, каналы передачи данных подобны виртуальным каналам в сетях ATM и Frame Relay. Важно, однако, подчеркнуть, что существует фундаментальное отличие между каналом передачи данных и путем. LSP представляет собой спецификацию пути с коммутацией по меткам, через который проходит трафик. На практике, термины LSP и канал передачи данных часто используются синонимично. Привлекательность MPLS для управления трафиком может быть ассоциирована со следующими факторами: (1) явные пути с коммутацией меток (которые не ограничиваются парадигмой переадресации, когда маршрут определяется на основе адреса места назначения) могут быть легко сформированы сетевым администратором или посредством стандартных протоколов, (2) LSP могут поддерживаться эффективно, (3) Каналы передачи данных могут быть смоделированы и поставлены в соответствие LSP, (4) Набор атрибутов может быть ассоциирован с каналами передачи данных, которые регулируют их рабочие характеристики, (5) Набор атрибутов может быть ассоциирован с ресурсами, которые ограничивают положение LSP и каналов передачи данных, (6) MPLS позволяет как агрегацию так и дисагрегацию трафика, в то время как классическая переадресация на основе IP-адреса места назначения допускает только агрегацию, (7) Относительно легко интегрировать "маршрутизацию на основе ограничений" в рамках MPLS, (8) Хорошая реализация MPLS может предложить заметно более низкую избыточность, чем конкурирующие альтернативы управления трафиком. Кроме того, через механизм коммутации меток MPLS позволяет наложить на современную модель маршрутизации Интернет квазиканальную коммутацию. Многие существующие предложения для управления трафиком посредством MPLS концентрируются на возможности формирования LSP. Хотя такая возможность является фундаментальной для управления трафиком, этого реально недостаточно. 3.1. Наведенный MPLS-граф В данном подразделе вводится концепция "наведенного MPLS-графа", которая является центральной при управлении трафиком в сфере MPLS. Наведенный MPLS-граф аналогичен виртуальной топологии в модели наложений. Он логически проектируется на физическую сеть путем выбора LSP для каналов транспортировки трафика. Наведенный MPLS-граф состоит из набора LSR, которые представляют собой узлы графа, и набора LSP, которые предоставляют логические соединение точка-точка между указанными LSR, и, следовательно, служат в качестве каналов наведенного графа. Имеется возможность сформировать иерархический наведенный MPLS-граф, базирующийся на концепции стеков меток (смотри [1]). Наведенные MPLS-графы важны потому, что базовые проблемы управления полосой пропускания в MPLS определяются тем, как эффективно совместить наведенный MPLS-граф с физической топологией сети. Абстракция наведенного MPLS-графа формализуется ниже. Пусть G = (V, E, c) является графом, отражающим физическую топологию сети. Здесь, V - набор узлов сети и E - набор каналов; то есть, для v и w из V, объект (v,w) содержится в E, если v и w являются непосредственно связанными в рамках G. Параметр "c" представляет собой набор емкостей и других ограничений, сопряженных с E и V. Мы будем рассматривать G как "основу" сетевой топологии. Пусть H = (U, F, d) является наведенным MPLS-графом, где U является субнабором V, представляющим набор LSR в сети, или более точно набор LSR, которые являются конечными точками, по крайней мере, одного LSP. Здесь, F представляет собой набор LSP, так что для x и y из U, объект (x, y) находится в F, если существует LSP с x и y в качестве конечных точек. Параметр "d" представляет собой набор требований и ограничений, ассоциированных с F. Очевидно, H является ориентированным графом. Можно видеть, что H зависит от переходных характеристик G. 3.2. Фундаментальные проблемы управления трафиком в MPLS Существует три фундаментальных проблемы, относящиеся к управлению трафиком в MPLS. - Первая проблема касается того, как определять соответствие пакетов определенному классу FEC (Forwarding Equivalence Class). - Вторая проблема касается того, как определять соответствие FEC и каналов передачи данных. - Третья проблема касается того, как определять соответствие каналов передачи данных физической топологии сети через маршруты с коммутацией по меткам. Данный документ не касается первых двух перечисленных проблем (хотя они весьма важны). Вместо этого, остальная часть документа посвящена возможностям, которые позволяют третей функции осуществлять эффективную и надежную работу сетей. Установление соответствия между наведенным MPLS-графом (H) и базовой топологией сети (G) является достаточно важной проблемой. 4.0. Расширенные возможности управления трафиком с помощью MPLS В предыдущих разделах рассмотрены базовые функции управления трафиком в современном Интернет. Остальная часть документа описывает функциональные возможности, необходимые для полномасштабного поддержания управления трафиком в больших сетях через посредство MPLS . Предлагаемые возможности включают в себя: 1. Набор атрибутов, связанных с каналами передачи данных, совокупность которых характеризует рабочее состояние сети. 2. Набор атрибутов, связанных с ресурсами, которые ограничивают размещение пути информационных потоков. Они могут рассматриваться также как топологические ограничения. 3. "Маршрутизация на основе ограничений", которая используется для выбора пути для канала передачи данных в соответствии с набором параметров пунктов 1 и 2, приведенных выше. Маршрутизация на основе ограничений не должна являться частью протокола MPLS. Однако они должны быть тесно связаны. Атрибуты, связанные с каналами передачи данных и ресурсами, а также параметры, ассоциированные с маршрутизацией, в совокупности представляют собой набор управляющих переменных, которые могут быть модифицированы в результате либо действий администратора, либо автоматических агентов, для того чтобы привести сеть в желательное состояние. В рабочей сети, крайне желательно, чтобы эти атрибуты можно было менять динамически в реальном масштабе времени без неблагоприятных последствий. 5.0. Атрибуты и характеристики канала передачи данных В этом разделе обсуждаются атрибуты, которые можно ассоциировать с каналами передачи данных и которые могут определять рабочие характеристики сети. Базовые свойства каналов передачи данных перечислены ниже: - Канал передачи данных представляет собой объединение потоков данных, принадлежащих одному классу. В определенном контексте, может быть желательно смягчить это определение и позволить каналам передачи данных содержать мультиклассные объединения потоков. - В одноклассной модели обслуживания, такой как современный Интернет, канал передачи данных может включать в себя все потоки между входным LSR и выходным LSR. - Каналы передачи данных являются маршрутизируемыми объектами (аналогично ATM VC). - Канал передачи данных отличается от LSP, через который он проходит. В операционном контексте, канал передачи данных может быть перенесен из одного пути в другой. - Каналы передачи данных являются однонаправленными. На практике, канал передачи данных может характеризоваться своими входным и выходным LSR, FEC, которому он соответствует, и набором атрибутов, которые определяют его рабочие характеристики. Имеется два пункта особой важности: (1) параметризация каналов передачи данных и (2) положение маршрута и правила управления каналом передачи данных. 5.1. Двунаправленные каналы передачи данных Хотя каналы передачи данных (traffic trunks) являются концептуально однонаправленными, во многих практических контекстах, полезно одновременно анализировать два канала передачи данных с идентичными конечными точками, но с разным направлением потоков. Два канала передачи данных логически связаны друг с другом. Один канал, называемый прямым, транспортирует трафик от исходного узла к узлу места назначения. Другой канал, называемый обратным, транспортирует трафик от узла места назначения к исходному узлу. Объединение двух таких каналов называется двунаправленным каналом передачи данных BTT (bidirectional traffic trunk), если выполняются следующие два условия: - Оба канала передачи данных инициализированы одновременно одним и тем же LSR, называемым исходным узлом, или возникли в результате одномоментной операции сетевой управляющей станции. - Ни один из образующих такую пару каналов не может существовать отдельно. То есть, оба создаются и исчезают одновременно. Следует также рассмотреть топологические свойства BTT. BTT может быть топологически симметричным или асимметричным. BTT считается "топологически симметричным", если составляющие его каналы передачи данных имеют одни и те же физические маршруты. Если, однако, составляющие его каналы передачи данных маршрутизированы через разные пути, тогда BTT называется "топологически асимметричным". Следует заметить, что двунаправленные каналы передачи данных имеют в основном административное удобство. На практике, большинство функций управления трафиком могут быть реализованы с использованием исключительно однонаправленных каналов передачи данных. 5.2. Базовые операции для канала передачи данных Базовые операции в канале передачи данных, важные для целей управления трафиком перечислены ниже. - Установить (Establish): создать канал передачи данных. - Активировать (Activate): запустить информационный обмен через канал передачи данных. Установление и активизация канала передачи данных логически не связанные события. Они могут, однако, быть реализованы в рамках одной операции. - Деактивировать (Deactivate): Останавливать информационный поток через канал передачи данных. - Модифицировать атрибуты (Modify Attributes): Изменить атрибуты канала передачи данных. - Сменить маршрут (Reroute): Изменить маршрут канала передачи данных. Это может быть сделано административно или автоматически с помощью базовых протоколов. - Ликвидировать (Destroy): Ликвидировать канал передачи данных и уведомить об имеющихся ресурсах. К таким ресурсам относится пространство меток и, возможно, дополнительная полоса пропускания. Выше рассматривались базовые операции каналов передачи данных. Возможны и дополнительные операции, сопряженные с реализацией политики и формированием трафика. 5.3. Мониторирование аккоунтинга и работы Возможности мониторинга аккоутнтинга и рабочих характеристик является крайне важным для задач билинга и контроля параметров трафика. Статистика трафика, полученная с помощью такой системы мониторинга, может использоваться для оптимизации рабочих характеристик канала и для планирования управления трафиком. Возможность получения статистики на уровне канала передачи данных так важна, что это следует рассматривать как существенное требование управления трафиком через MPLS. 5.4. Базовые атрибуты управления трафиком каналов передачи данных Атрибут канала передачи данных является параметром, который влияет на рабочие характеристики канала. Атрибуты могут быть явно присвоены каналам передачи данных администратором или заданы неявно базовыми протоколами, когда пакеты классифицируются и сортируются по классам эквивалентности (FEC) на входе в область MPLS. Независимо оттого как атрибуты были первоначально присвоены, для целей управления трафиком нужно допустить их административную модификацию. Основные атрибуты каналов передачи данных наиболее важные для управления трафиком перечислены ниже. - Атрибуты параметров трафика - Атрибуты управления и выбора пути - Атрибут приоритета - Атрибут приоритетной подмены (Preemption) - Атрибут устойчивости (Resilience) - Атрибут политики (Policing) Комбинация параметров трафика и атрибутов политики аналогична использованию параметрического управления в сетях ATM. Большинство атрибутов, перечисленных выше, имеют аналоги в хорошо установившихся технологиях. Следовательно, следует достаточно непосредственно установить соответствие между атрибутами канала передачи данных и многими существующими архитектурами переключения и маршрутизации. Приоритет и приоритетная подмена (preemption) могут рассматриваться как относительные атрибуты, так как они выражают определенные отношения между каналами передачи данных. Концептуально, эти двоичные отношения определяют способ взаимодействия каналов между собой, когда они соревнуются за получения сетевых ресурсов в процессе установления пути и его рабочих параметров. 5.5. Атрибуты параметров трафика Параметры трафика могут использоваться при сборе данных об информационных потоках (или более точно FEC), которые надлежит транспортировать через информационный канал. Такие характеристики могут включать пиковые загрузки, средние потоки. Параметры трафика важны потому, что они указывают требования к ресурсам канала передачи данных. Это полезно для выделения ресурсов и исключения перегрузки за счет политики предвидения. 5.6. Атрибуты управления и выбора пути Атрибуты управления и выбора пути определяют правила выбора пути канала передачи данных, а также правила работы с маршрутами, которые уже существуют. Маршруты могут быть вычислены автоматически с помощью протоколов маршрутизации или они могут быть определены сетевым администратором. Если требований к ресурсам или ограничений, сопряженных с каналом передачи данных, нет, тогда для выбора пути может быть использован протокол, управляемый топологией. Однако, если требования к ресурсам или ограничения, связанные с политикой, имеются, тогда следует использовать маршрутизацию, основанную на ограничениях. В разделе 7 описана маршрутизация, где путь вычисляется на основе определенных ограничений. Управление касается всех аспектов, имеющих отношение к поддержанию путей, через которые проходят каналы передачи данных. В некоторых операционных контекстах, желательно, чтобы реализация MPLS могла динамически себя реконфигурировать для адаптации к состоянию системы. Адаптивность и устойчивость являются аспектами динамического управления маршрутом. Чтобы контролировать выбор пути и процесс управления, необходим набор атрибутов. Базовые атрибуты и рабочие характеристики, связанные с выбором пути и управлением каналом передачи данных, описаны ниже. 5.6.1. Административно специфицированные маршруты Административно специфицированный путь для канала передачи данных конфигурируется в результате действий оператора. Административно специфицированный путь может быть определен полностью или частично. Путь полностью специфицирован, если указаны все шаги между начальной и конечной точками. Путь частично специфицирован, если представлен только субнабор промежуточных шагов. В этом случае, нужны базовые протоколы, чтобы сформировать окончательный маршрут. Из-за ошибок оператора, административно специфицированный путь может оказаться несогласованным или нелогичным. Базовые протоколы маршрутизации должны быть способны детектировать такую несогласованность и внести необходимые коррективы. Атрибут "path preference rule" (правило предпочтения пути) должно быть ассоциировано с административно специфицированными путями. Атрибут "правила предпочтения пути" представляет собой двоичную переменную, которая указывает, является ли административно сконфигурированный путь "обязательным" или нет. Если административно сконфигурированный путь выбран с "обязательным" атрибутом, должен использоваться этот (и только этот) путь. Если обязательный путь недопустим (например, конечные пункты топологически разделены), или, если путь не может быть использован, так как его ресурсы неадекватны, тогда процесс установки пути (setup) потерпит неудачу. Другими словами, если путь специфицирован как обязательный, тогда альтернативный путь не может использоваться ни при каких обстоятельствах. Обязательный путь, который успешно приписан, является неявно закрепленным. Раз путь присвоен, его нельзя изменить, а только ликвидировать или заменить новым. Однако если административно специфицированный путь выбран со значением атрибута предпочтения "необязательный", тогда путь следует использовать, если это возможно. В противном случае, может использоваться альтернативный путь, предлагаемый маршрутным протоколом. 5.6.2. Иерархия предпочтений для мультимаршрутов В некоторых практических контекстах, может быть полезно административно специфицировать набор кандидатов маршрутов для данного канала передачи данных и определить иерархию предпочтения этих маршрутов. Во время установления пути, правила предпочтения используются при выборе подходящего пути из списка кандидатов. В случае неполадки правила предпочтения используются для выбора альтернативного пути из списка кандидатов. 5.6.3. Атрибуты сродства классов ресурсов (Resource Class Affinity) Атрибуты сродства классов ресурсов, ассоциированные с каналом передачи данных, могут использоваться для спецификации класса ресурсов (смотри раздел 6), которые следует включить явно или исключить из пути канала передачи данных. Эти атрибуты политики, которые могут использоваться для введения дополнительных ограничений для маршрута канала передачи данных. Атрибуты сродства классов ресурсов могут быть специфицированы для трафика в виде последовательности пар: <resource-class, affinity>; <resource-class, affinity>; Параметр resource-class идентифицирует класс ресурса, для которого определено соотношение сродства в отношении канала передачи данных. Параметр affinity указывает на соотношение сродства; то есть, включены или исключены члены класса ресурсов в путь канала передачи данных. В частности, параметр affinity может быть двоичной величиной, которая принимает одно из следующих значений: (1) явное включение, и (2) явное исключение. Если атрибут сродства является двоичной переменной, можно использовать Булевы выражения для спецификации сродства класса ресурсов, ассоциированных с данным каналом передачи данных. Если не специфицировано никакого атрибута сродства класса, тогда предполагается значение отношения сродства " don't care" (безразлично) между каналом передачи данных и ресурсами. То есть, не существует никаких требований по включению или исключению каких-либо ресурсов для пути канала передачи данных. На практике - это режим по умолчанию. Атрибуты сродства классов ресурсов очень полезны и эффективны, так как они могут быть использованы при реализации самых разных политик. Например, они могут быть применены для размещения определенных каналов передачи данных в заданных топологических областях сети. "Маршрутизация на основе ограничений" (смотри раздел 7.0) может использоваться для вычисления точного пути для канала передачи данных так, чтобы удовлетворить ограничениям сродства класса ресурсов следующим образом: 1. Для прямого включения, перед началом вычисления пути удалить все ресурсы, не принадлежащие специфицированным классам. 2. Для прямого исключения перед началом вычисления пути, удалить все ресурсы, принадлежащие специфицированным классам. 5.6.4. Атрибут адаптивности Характеристики сети и ее состояние изменяются со временем. Например, появляются новые ресурсы, утраченные ресурсы могут быть снова активизированы, а выделенные ресурсы могут оказаться недоступными. Вообще, иногда могут оказаться доступными более эффективные пути. Следовательно, с точки зрения управления трафиком, необходимо иметь административные параметры управления, которые могут использоваться для спецификации того, как канал передачи данных будет реагировать на этот динамизм. При некоторых сценариях, может оказаться желательным динамически изменить пути некоторых информационных каналов в ответ на изменения состояния сети. Этот процесс называется реоптимизацией. При других сценариях реоптимизация может оказаться нежелательной. Атрибут адаптивности (adaptivity) является частью блока параметров пути, ассоциированного с каналом передачи данных. Атрибут адаптивности, ассоциированный с каналом передачи данных, указывает на то, является ли канал субъектом реоптимизации. То есть, атрибут адаптивности представляет собой двоичную переменную, которая принимает одно из следующих значений: (1) разрешить реоптимизацию и (2) запретить реоптимизацию. Если реоптимизация разрешена, канал передачи данных может под действие маршрутных протоколов изменить путь в ответ на изменение состояния сети. Напротив, если реоптимизация запрещена, канал передачи данных является закрепленным и его маршрут не может быть изменен при вариации ситуации в сети. Стабильность является главным соображением, когда разрешена реоптимизация. Чтобы содействовать стабильности реализация MPLS не должна быть слишком реактивной в ответ на эволюционные изменения в сети. В то же время, она должна достаточно быстро адаптироваться, чтобы оптимально использовать появляющиеся сетевые ресурсы. Отсюда следует, что частота реоптимизаций должна определяться административно, чтобы допускать настройку. Следует заметить, что реоптимизация не то же самое что и устойчивость к внешним воздействиям. Для спецификации характеристик устойчивости канала передачи данных используются другие атрибуты (смотри раздел 5.9). На практике, представлялось бы разумным ожидать, что канал передачи данных, подвергающийся реоптимизации, должен быть устойчив против отказов вдоль его пути. Однако канал передачи данных, который не подвергается реоптимизации и чей маршрут не специфицирован административно как "обязательный", также должен быть устойчивым против отказов связей и узлов вдоль своего пути. Формально, можно заявить, что адаптивность к состоянию эволюции через реоптимизацию влечет за собой устойчивость к отказам, тогда как устойчивость к отказам не предполагает общей адаптивности к изменениям состояния сети. 5.6.5. Распределение нагрузки в параллельных каналах передачи данных Распределение нагрузки по нескольким параллельным каналам передачи данных между двумя узлами является крайне важным. Во многих практических контекстах, суммарный трафик между узлами может быть таким, что ни один канал в отдельности (следовательно, и ни один маршрут) не сможет его пропустить. Однако суммарный поток может быть меньше, чем максимально допустимый поток через поперечное сечение ("min-cut"), разделяющее два узла. В этом случае, единственно возможным решением может быть деление трафика на несколько потоков. В домене MPLS, эта проблема может быть решена с помощью нескольких каналов, соединяющих два узла. Следовательно, нужны гибкие средства назначения нагрузки для параллельных каналов передачи данных, соединяющих два узла. В частности, в ситуациях, где параллельные потоки данных оправданы, было бы полезно иметь некоторые атрибуты, которые могут применяться для указания доли трафика, проходящего через каждый из каналов. Базовые протоколы реализуют нагрузку каналов в указанной пропорции. Желательно также обеспечивать порядок передачи пакетов, принадлежащих одному и тому же микро потоку (идентичные адреса отправителя, получателя, и номера порта). 5.7. Атрибут приоритета Атрибут priority (приоритет) определяет относительную важность канала передачи данных. Если с MPLS используется маршрутизация, базирующаяся на ограничениях, тогда приоритеты становятся очень важными, так как они используются в случае отказов для определения порядка, в котором выбираются пути для канала передачи данных из имеющегося списка. Приоритеты важны также в реализациях допускающих приоритетное обслуживание, так как они могут быть использованы для определения политики обслуживания каналов передачи данных. 5.8. Атрибут Preemption Атрибут preemption определяет, может ли канал передачи данных заместить другой канал на данном пути, и может ли другой канал передачи данных заместить заданный канал. Приоритетная подмена полезна как для схемы оптимизации, ориентированной на трафик, так и для схемы, ориентированной на ресурс. Приоритетное замещение может использоваться, чтобы гарантировать то, что канал передачи данных маршрутизирован через вполне определенный путь, а это особенно важно при оказании дифференцированных услуг Приоритетное замещение может также использоваться при реализации различных политик восстановления, вступающих в силу при отказах оборудования или программ. Атрибут preemption может использоваться для спецификации четырех режимов приоритетного замещения для канала передачи данных: (1) замещающий объект активирован (preemptor enabled), (2) non-preemptor, (3) допускающий подмену и (4) не допускающий подмены. Канал передачи данных, где разрешено приоритетное замещение (preemptor enabled) может заменять каналы с более низким приоритетом, признанные, как приемлемые для замены. Канал передачи, специфицированный, как не подлежащий подмене, не может быть замещен каким-либо иным каналом, вне зависимости от их относительных приоритетов. Канал передачи данных, допускающий замещение, может быть замещен другим каналом с более высоким приоритетом, который имеет атрибут preemptor enabled. Достаточно просто понять, что некоторые режимы замещения являются взаимно исключающими. Используя схему нумерации, описанную выше, можно назвать допустимые комбинации режимов для канала передачи данных: (1, 3), (1, 4), (2, 3) и (2, 4). Комбинация (2, 4) является режимом по умолчанию. Канал передачи данных, скажем "A", может заместить другой канал, скажем "B", только если все следующие пять условий будут выполнены: (i) " A" имеет относительно более высокий приоритет, чем "B", (ii) " A" претендует на ресурс, используемый "B", (iii) ресурс не может одновременно поддерживать "A" и "B", (iv) " A" может быть приемником, и (v) "B" допускает подмену. Атрибут preemption не рассматривается, как обязательный атрибут современной модели обслуживания в Интернет (best effort service), хотя и является полезным. Однако, в сценарии с дифференциальными услугами, необходимость подмены становится очевидной. Более того, в появляющихся архитектурах оптического Интернет, где функции защиты и восстановления, чтобы уменьшить цену, могут быть перенесены с оптического уровня на информационные сетевые элементы (такие как гигабитные и терабитные маршрутизаторы с коммутацией по меткам), стратегии приоритетного замещения могут использоваться для сокращения времени восстановления канала в условиях сбоев. 5.9. Атрибут устойчивости (Resilience) Атрибут resilience определяет поведение канала передачи данных в случае возникновения ошибок. То есть, когда ошибка происходит на пути, через который проходит канал. При таких обстоятельствах должны быть рассмотрены следующие проблемы: (1) детектирование ошибки, (2) уведомление об ошибке, (3) восстановление после сбоя. Очевидно, реализация MPLS должна содержать механизмы для решения всех этих задач. Многие политики восстановления могут быть специфицированы для каналов передачи данных, чьи маршруты подвержены отказам. Ниже представлены примеры приемлемых схем: 1. Не нужно изменять маршрут канала передачи данных (traffic trunk). Например, схема живучести может уже существовать и быть реализована за счет альтернативного механизма, который гарантирует непрерывность обслуживания в случае сбоя без необходимости изменения маршрута канала передачи данных. Примером такой альтернативной схемы (конечно существует и много других), является ситуация, когда между двумя узлами имеется несколько параллельных каналов, и в случае отказа одного LSP, его трафик будет перераспределен между остальными LSP согласно некоторой заданной политике. 2. Перенаправить маршрут на приемлемый путь с достаточными ресурсами. Если такового нет, тогда маршрут не изменять. 3. Поменять маршрут на любой доступный, игнорируя ограничения по ресурсам. 4. Возможно много других схем, включая комбинации перечисленных выше. "Базовый" атрибут resilience указывает на процедуру восстановления, которая должна быть запущена для данного канала, при возникновении отказа. В частности, "базовый" атрибут resilience является двоичной переменной, которая определяет, будет ли данный канал изменять маршрут, если сегмент его пути выдал отказ. "Расширенный" атрибут resilience может использоваться для подробной спецификации действий в случае сценария отказа. Например, расширенный атрибут resilience может специфицировать набор альтернативных путей, которые следует использовать в случае отказа, а также правил, которые управляют относительным предпочтением для каждого специфицированного пути. Атрибуты resilience обеспечивают тесное взаимодействие между MPLS и маршрутизацией. 5.10 Атрибут Policing Атрибут policing определяет действия, которые следует предпринять в рамках базовых протоколов, когда канал передачи данных становится нерабочим. То есть, когда какие-то параметры канала отклонились за оговоренные пределы. Вообще, атрибуты policing могут указывать, является ли неуправляемый канал передачи данных лимитированным по полосе пропускания, или он просто переадресуется без каких-либо действий, учитывающих местную политику. Если используется политика, тогда для реализации таких функций могут использоваться адаптации алгоритмов, таких как ATM GCRA [11]. Использование политики необходимое во многих рабочих сценариях, может быть неприемлемо в других. Вообще, обычно желательно реализовать какую-то политику на входе сети (чтобы обеспечить согласование с требованиями уровня обслуживания) и минимизировать применение политики в ядре, за исключением ситуации, когда ограничение емкости диктуют обратное. Следовательно, с точки зрения управления трафиком необходимо иметь возможность административно разрешать и запрещать использование политики для каждого канала передачи данных (traffic trun). 6.0. Атрибуты ресурсов Атрибуты resource являются частью параметров состояния топологии, которые используются, чтобы установить ограничения на маршрутизацию каналов передачи данных в рамках имеющихся ресурсов. 6.1. Максимально выделяемая доля (Maximum Allocation Multiplie) Максимально выделяемая доля MAM (maximum allocation multiplier) ресурса является административно задаваемым атрибутом, который определяет долю ресурса, доступную для канала передачи данных. Этот атрибут используется в основном для распределения полосы пропускания. Однако он может быть применен также для резервирования ресурсов LSR. Концепция MAM аналогична концепции параметров подписки и резервирования в сетях frame relay и ATM. Значения MAM могут быть выбраны так, чтобы ресурс был недораспределен или перераспределен. Ресурс считается недораспределенным, если суммарные требования всех каналов передачи данных, которые могут его использовать, меньше емкости ресурса. В противном случае ресурс считается перераспределенным. Недораспределение может использоваться, чтобы установить предел использования ресурсов. Однако, в случае MPLS это сложнее, чем в схемах с коммутацией каналов, так как для MPLS, некоторые потоки могут маршрутизоваться посредством обычных протоколов шаг-за-шагом без рассмотрения каких-либо ресурсных ограничений. Перераспределение может применяться, чтобы реализовать преимущества статистических характеристик трафика в рамках более эффективной политики использования имеющихся ресурсов. В частности, перераспределение можно применить в ситуации, когда пики загрузки трафика в разных каналах не совпадают по времени. 6.2. Атрибут класса ресурса Атрибуты класса ресурса являются параметрами, присваиваемыми административно, и вводят понятие класса для ресурсов. Атрибуты класса ресурса могут рассматриваться как "цвета", приписанные ресурсам, такие, что набор ресурсов с одним "цветом" концептуально принадлежит к одному классу. Атрибуты класса ресурса могут использоваться для реализации разнообразных политик. Ключевыми ресурсами здесь являются связи. В случае применения в отношении связей, атрибут класса ресурса становится эффективной характеристикой параметров состояния связи. Концепция атрибутов класса ресурса является достаточно мощной абстракцией. С точки зрения управления трафиком она может использоваться для реализации различных политик при оптимизации характеристик канала по трафику или по ресурсам. В частности, атрибуты класса могут использоваться для: 1. Реализации одинаковых политик для набора ресурсов, которые не обязательно находятся в одной и той же топологической области. 2. Спецификации относительного предпочтения для набора ресурсов, связанных с положением маршрута, по которому транспортируется поток данных. 3. Ограничения положения каналов передачи данных для заданного субнабора ресурсов. 4. Реализации обобщенного включения/исключения политик. 5. Реализации политики ограничения локальности трафика. То есть, политики, которая ищет способы размещения трафика в пределах оговоренных топологических областей сети. Кроме того, атрибуты класса ресурса могут использоваться для целей идентификации. Вообще, ресурс может быть ассоциирован более чем с одним атрибутом класса ресурса. Например, все каналы OC-48 в заданной сети могут быть приписаны определенному атрибуту класса ресурса. Субнаборы каналов OC-48, которые имеются, могут быть приписаны к дополнительным атрибутам класса, для того чтобы реализовать специальную политику или построить нужную вам сеть. 7.0. Маршрутизация, базирующаяся на ограничениях В этом разделе обсуждается вопросы, связанные с маршрутизацией, основанной на ограничениях, используемой в доменах MPLS. В современной терминологии, маршрутизация, основанная на ограничениях, часто называется "QoS маршрутизацией", смотри [5,6,7,10]. В этом документе используется термин "маршрутизация на основе ограничений " однако, если быть точным, QoS маршрутизация является лишь ее составной частью. Маршрутизация на основе ограничений делает возможным резервирование ресурсов по запросу, сосуществование с имеющимися внутренними протоколами маршрутизации Интернет, работающими по принципу шаг-за-шагом. Маршрутизация на основе ограничений, использует следующие данные в качестве входных: - Атрибуты, связанные с каналами передачи данных (traffic trunks). - Атрибуты, связанные с ресурсами. - Другую информацию, характеризующую состояние топологии сети. Базируясь на этой информации, процесс маршрутизации на основе ограничений автоматически вычисляет маршрут для каждого потока, исходящего из данного узла. В этом случае, маршрут для каждого информационного потока представляет собой спецификацию пути с коммутацией по меткам, который удовлетворяет требованиям, записанным в атрибутах канала. Ограничения формулируются на основе доступности ресурсов, административной политики и статусной топологической информации. Маршрутизация на основе ограничений может существенно сократить уровень ручной конфигурации и необходимого вмешательства для актуализации политики управления трафиком (Traffic Engineering policies). На практике инженер трафика, оператор, или даже автоматическая система специфицирует конечные точки канала передачи данных (traffic trunk) и приписывает набор атрибутов, который объединяет ожидаемые рабочие характеристики канала. Предполагается, что маршрутизация на основе ограничений найдет приемлемый путь, который удовлетворит имеющимся ожиданиям. Если необходимо для более тонкой оптимизации, инженер трафика или система поддержки управления трафиком может затем использовать административно сконфигурированные маршруты. 7.1 Базовые характеристики маршрутизации на основе ограничений Маршрутизация на основе ограничений должна, по крайней мере, иметь возможность автоматически получать базовые, приемлемые решения задачи размещения пути для канала передачи данных. Вообще, известно, что проблема маршрутизации на основе ограничений трудно разрешима для большинства реалистичных ограничений. Однако, на практике для нахождения приемлемого пути, если он существует, может использоваться очень простая хорошо известная эвристика (смотри, например, [9]): - Сначала отбрасываются ресурсы, которые не удовлетворяют требованиям атрибутов канала передачи данных. - Затем, для оставшегося графа связей запускается алгоритм поиска кратчайшего пути. Ясно, что если приемлемый путь для заданного канала передачи данных существует, тогда выше предложенная простая процедура его найдет. Могут быть специфицированы дополнительные правила для разрубания узлов и выполнения дальнейшей оптимизации. Вообще, оптимизация обычно сводится к минимизации перегрузки. Однако когда нужно маршрутизировать несколько каналов передачи данных, можно показать, что выше предложенный алгоритм не всегда находит решение, даже когда такое решение существует. 7.2 Соображения реализации Многие коммерческие реализации коммутаторов frame relay и ATM уже поддерживают некоторые аспекты маршрутизации на основе ограничений. Для таких приборов или для новых MPLS-реализаций должно быть относительно просто расширить существующие реализации маршрутизации на основе ограничений, чтобы удовлетворить специфическим требованиям MPLS. Для маршрутизаторов, которые используют топологически управляемые IGP, определяющие маршрут шаг-за-шагом, маршрутизацию на основе ограничений можно внедрить одним из двух способов: 1. Путем расширения существующих IGP протоколов, таких как OSPF и IS-IS для поддержки маршрутизации на основе ограничений. Прилагаются усилия для решения этой задачи в отношении протокола OSPF (смотри [5,7]). 2. Путем добавления процесса маршрутизации на основе ограничений в каждый маршрутизатор, который может сосуществовать с имеющимися IGP. Этот сценарий представлен на рис. 1.
Рис. 1. Процесс маршрутизации, базирующийся на ограничениях, на уровне 3 LSR Существует много важных деталей, связанных с реализацией маршрутизации на основе ограничений в устройствах уровня 3, которые здесь не обсуждались. Сюда входит следующее: - Механизмы обмена статусной топологической информацией (данные о доступности ресурсов, информация о состоянии связи, информация об атрибутах ресурсов) между процессами маршрутизации на основе ограничений. - Механизмы работы с топологической статусной информацией. - Взаимодействие между процессами маршрутизации на основе ограничений и процессами традиционных IGP. - Механизмы выполнения требований адаптивности каналов передачи данных. - Механизмы выполнение требований устойчивости и живучести каналов передачи данных. Короче, маршрутизация на основе ограничений помогает при осуществлении оптимизации сетей путем автоматического поиска приемлемых маршрутов, которые удовлетворяют набору ограничений, налагаемых на каналы передачи данных. Она может существенно уменьшить усилия по административной конфигурации и ручному вмешательству для решения задач управления трафиком. 8.0. Заключение В данном документе представлен набор требований для реализации управления трафиком (Traffic Engineering) посредством MPLS. Описаны многие возможности, целью которых является улучшение применимости MPLS для управления трафиком в Интернет. Следует заметить, что некоторые вопросы, описанные здесь, могут быть разрешены путем введения некоторого минимального набора модификаций в MPLS, и затем использования суперструктуры управления сетью, чтобы расширить функциональность. Маршрутизация на основе ограничений не является частью спецификаций ядра MPLS. Однако MPLS требует некоторого взаимодействия с маршрутизацией на основе ограничений, для того чтобы решить задачи управления трафиком. 9.0. Библиография [1] Rosen, E., Viswanathan, A. и R. Callon, "A Proposed Architecture for MPLS", Work in Progress. [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. и A. Viswanathan, "A Framework for Multiprotocol Label Switching", Work in Progress. [3] Li, T. и Y. Rekhter, "Provider Architecture for Differentiated Services и Traffic Engineering (PASTE)", RFC 2430, October 1998. [4] Rekhter, Y., Davie , B., Katz, D., Rosen, E. и G. Swallow, "Cisco Systems' Tag Switching Architecture - Overview", RFC 2105, February 1997. [5] Zhang, Z., Sanchez, C., Salkewicz, B. и E. Crawley "Quality of Service Extensions to OSPF", Work in Progress. [6] Crawley , E., Nair, F., Rajagopalan, B. и H. Sandick, "A Framework for QoS Based Routing in the Интернет", RFC 2386, August 1998. [7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. и D. Williams, "QoS Routing Mechanisms и OSPF Extensions", RFC 2676, August 1999. [8] C. Yang и A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks," IEEE Network Magazine, Volume 9, Number 5, July/August 1995. [9] W. Lee, M. Hluchyi, и P. Humblet, "Routing Subject to Quality of Service Constraints in Integrated Communication Networks,"IEEE Network, July 1995, pp 46-55. [10] ATM Forum, "Traffic Management Specification: Version 4.0" April 1996. |
|
Previous:
4.4.19 Кодирование меток в MPLS
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
|
4.4.21 BGP/MPLS VPN
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
E. Rosen. RFC-2547, March 1999 (Перевод Семенова Ю.А.) Аннотация Описан метод, с помощью которого, например, сервис провайдер на IP опорной сети, может организовать для клиентов частные виртуальные сети (VPN). MPLS (мультипротокольная коммутация пакетов по меткам - Multiprotocol Label Switching) используется для переадресации пакетов по опорной сети, а BGP (Border Gateway Protocol) служит для прокладки маршрутов через опорную сеть. Главной целью метода является поддержка внешних опорных IP сетей, предлагающих услуги корпоративным сетям. Это делается достаточно просто для предприятия, сохраняя гибкость и масштабируемость для сервис провайдеров. Данная технология может быть также использована, чтобы формировать VPN , которая сама предоставляет IP-услуги клиентам. 1. Введение 1.1. Частные виртуальные сети Рассмотрим набор сайтов, которые подсоединены к общей сети, называемой опорной. Определим некоторую политику при создании субнаборов этого набора, и введем следующее правило: два сайта могут взаимодействовать друг с другом через опорную сеть, только если, по крайней мере, один из этих субнаборов содержит оба эти сайта. Субнаборы, которые создаются, являются "Частными виртуальными сетями" (VPN). Два сайта имеют IP коннективность через опорную сеть, только если существует VPN, которая содержит в себе оба эти сайта. Два сайта, которые не имеют общих VPN, не имеют связи через опорную сеть. Если все сайты в VPN принадлежат одной и той же компании, VPN является корпоративной "интранет". Если разные сайты в VPN принадлежат различным компаниям, VPN считается "экстранетом". Сайт может состоять в более чем одной VPN, например, интранет и несколько экстранетов. Будем рассматривать интранеты и экстранеты, как VPN. Вообще, при использовании термина VPN в дальнейшем не будет делаться различия между интранетами и экстранетами. Будем рассматривать случай, когда опорная сеть принадлежит и обслуживается одним или несколькими сервис провайдерами (SP). Владельцы сайтов являются клиентами SP. Будет ли конкретный набор сайтов VPN, определяется политикой клиентов. Некоторые клиенты могут пожелать, чтобы реализация политики осуществлялась исключительно SP. Другие клиенты могут осуществлять политику самостоятельно, или делить ответственность с SP. В данном документе, обсуждаются механизмы, которые могут быть применены для реализации такой политики. Механизмы, которые рассматриваются, являются достаточно общими, чтобы реализовать политику либо самим SP, либо клиентом VPN совместно с SP . Большая часть обсуждения, однако, посвящена последнему варианту. Механизмы, обсуждаемые в данном документе, допускают реализацию широкого диапазона политик. Например, в пределах данной VPN, каждому сайту позволяется иметь прямой маршрут до любого другого сайта ("полная сетка"), или можно выделить определенные пары сайтов, которые будут связаны друг с другом ("частичная сетка"). В этом документе, рассматривается вариант, когда общая опорная сеть предоставляет IP услуги. Здесь обсуждается случай, когда предприятие использует опорную сеть провайдера, или нескольких провайдеров, с которыми он поддерживает отношения. 1.2. Оконечные устройства Предполагается, что на каждом сайте имеется одно или более оконечное устройство клиента CE (Customer Edge), каждое из которых подключено через какой-то канал (например, PPP, ATM, Ethernet, Frame Relay, GRE-туннель, и т.д.) к одному или более оконечному маршрутизатору провайдера PE (Provider Edge). Если конкретный сайт имеет одну ЭВМ, эта машина может быть оконечным устройством CE. Если конкретный сайт имеет одну субсеть, оконечным устройством CE может стать сетевой переключатель. Вообще, устройством CE может быть маршрутизатор, который называется в этом случае CE-маршрутизатором. Будем говорить, что PE-маршрутизатор подключен к определенной VPN, если он подключен к оконечному устройству CE, которое находится в VPN. Аналогично, будем считать, что маршрутизатор PE подключен к определенному сайту, если он подсоединен к устройству CE, которое находится в пределах этого сайта. Когда в качестве CE выступает маршрутизатор, он является маршрутным партнером PE, к которому подключен, но не является маршрутным партнером CE-маршрутизаторов в других сайтах. Маршрутизаторы в различных сайтах непосредственно не обмениваются маршрутной информацией. В действительности, они даже могут не знать о существовании друг друга (за исключением случая, когда это необходимо из соображений безопасности, смотри раздел 9). Как следствие, очень большие VPN (т.e., VPN с большим числом сайтов) хорошо поддерживаются, в то же время маршрутные стратегии каждого индивидуального сайта существенно упрощаются. Важно сохранять четкие административные границы между SP и их клиентами [4]. Маршрутизаторы PE и P должны администрироваться SP, а клиенты SP не должны иметь доступа к их управлению. Устройства CE должны управляться клиентом (если только клиент не заключил соглашение с SP). 1.3. VPN с перекрывающимися адресными пространствами Предположим, что любые две не пересекающиеся VPN (т.e., VPN, не имеющих общих сайтов) могут иметь перекрывающиеся адресные пространства. Один и тот же адрес может использоваться повторно для разных систем в различных VPN. Поскольку оконечное устройство имеет уникальный адрес в области VPN, которой оно принадлежит, оконечное устройство не нуждается в какой-либо дополнительной информации о VPN. В этой модели, владельцы VPN не имеют опорной сети, которую нужно администрировать, не имеют даже виртуальной опорной сети. SP не должен администрировать опорную сеть для каждой VPN. Оптимальной маршрутизацией является путь в опорной сети от сайт-к-сайту (в рамках ограничений политики, использованной при формировании VPN). 1.4. VPN с разными маршрутами до одной и той же системы Хотя сайт может находиться в нескольких VPN, не обязательно маршрут к данной системе в сайте будет тем же, что для всех прочих VPN. Предположим, например, что имеется интранет, состоящий из сайтов A, B и C, а также экстранет, включающий в себя A, B, C и "чужой" сайт D. Будем считать, что сайт A является сервером, и мы хотим предоставить клиентам из B, C или D доступ к этому серверу. Предположим также, что сайт B является файерволом. Мы хотим, чтобы весь трафик из сайта D к серверу проходил через файервол, так что может контролироваться доступ трафика из экстранета. Однако мы не хотим, чтобы трафик от C проходил через firewall на пути к серверу, поскольку это трафик интранет. Это означает, что нужно конфигурировать два маршрута к серверу. Один маршрут, используемый сайтами B и C, организует трафик к сайту A. Второй маршрут, используемый сайтом D, формирует трафик через firewall сайта B. Если firewall позволяет проходить трафику, он затем рассматривается как трафик, приходящий из сайта B, и следует маршрутом до узла A. 1.5. Таблицы переадресации в PE Каждый маршрутизатор PE должен поддерживать несколько различных таблиц переадресации. Каждому сайту, к которому подключен PE, должна быть поставлена в соответствие такая таблица переадресации. Когда пакет получен от определенного сайта, происходит обращение к ассоциированной с этим сайтом таблицей переадресаций, чтобы определить, как маршрутизовать данный пакет. В таблицу переадресации, ассоциированную с сайтом S, записываются только маршруты, которые ведут к другим сайтам, которые принадлежат, по крайней мере, одной VPN общей с S. Это предотвращает коммуникации между сайтами, которые не принадлежат общим VPN, и это позволяет двум VPN, не имеющим общих сайтов, использовать общее или перекрывающееся адресное пространство. 1.6. Маршрутизаторы опорной сети SP Опорная сеть SP состоит из PE-маршрутизаторов, а также их других маршрутизаторов (P-маршрутизаторы), которые не подключены к CE устройствам. Если каждый маршрутизатор в опорной сети SP должен поддерживать маршрутную информацию для всех VPN, поддерживаемых SP, такая модель будет иметь серьезные проблемы с масштабируемостью. Число поддерживаемых сайтов, будет лимитировано объемом маршрутной информации, хранимой одним маршрутизатором. Важно, следовательно, потребовать, чтобы маршрутная информация о конкретном VPN присутствовала только в тех PE-маршрутизаторах, которые соединены с этой VPN. В частности, P-маршрутизаторы не должны иметь какой-либо маршрутной информации о любых VPN. VPN может пользоваться услугами нескольких сервис-провайдеров. Предполагается, что когда путь между PE-маршрутизаторами пересекает границу между сетями SP, это делается согласно пиринговому соглашению, в рамках которого существует договоренность между двумя провайдерами. В частности, каждый провайдер должен доверять друг другу пересылку только корректной маршрутной информации, и передавать ее, в помеченных (в значении MPLS [9]) пакетах, только если эти пакеты были помечены отправителями, достойными доверия. Предполагается, что для маршрутов, коммутируемых по меткам, разрешается пересекать границы между сервис провайдерами. 2. Сайты и CE С точки зрения конкретной опорной сети, набор IP-систем представляет собой сайт, если эти системы имеют взаимную коннективность, а коммуникации между ними происходят без использования опорной сети. Вообще, сайт образуется из набора систем, которые географически близки. Однако это не является верным всегда; две географические позиции, соединенные через выделенную линию и отстоящие друг от друга сколь угодно далеко, будут представлять собой один сайт, так как коммуникация между ними не предполагает применение опорной сети. CE-устройства всегда рассматриваются принадлежащими одному сайту (хотя как мы это увидим, сайт может состоять из множества "виртуальных сайтов"). Сайт, однако, может принадлежать многим VPN. PE-маршрутизатор может быть подключен к CE-устройствам нескольких различных сайтов, если эти устройства CE размещены в одной или разных VPN. CE-устройства могут для надежности быть присоединены к нескольким маршрутизаторам PE, одного или нескольких сервис-провайдеров. Если CE устройством является маршрутизатор, то PE- и CE-маршрутизатор окажутся смежными. В то время как базовым блоком сети является сайт, описываемая архитектура позволяет создавать более тонкую степень гранулярности для управления коннективностью. Например, определенные системы сайта могут быть участниками Интернет или одного или нескольких экстранет, в то время как для других систем того же сайта может требоваться быть членами только интранет. 3. Таблицы переадресации сайта в PE Каждый PE-маршрутизатор поддерживает один или несколько таблиц переадресации сайта. Каждый сайт, к которому подключен PE-маршрутизатор, ассоциируется с одной из таких таблиц. Конкретный IP-адрес места назначения ищется в определенной таблице переадресации сайта, если только пакет пришел непосредственно от сайта, соответствующего этой таблице. Как заполняются таблицы переадресации сайтов? В качестве примера, пусть PE1, PE2 и PE3 являются PE-маршрутизаторами, и пусть CE1, CE2 и CE3 являются CE-маршрутизаторами. Предположим, что PE1 узнает, от CE1 маршруты, которые достижимы в сайте CE1. Если PE2 и PE3 подключены соответственно к CE2 и CE3 и имеется VPN V, содержащая CE1, CE2 и CE3, тогда PE1 использует BGP для посылки маршрутной информации PE2 и PE3, которую он получил от CE1. PE2 и PE3 используют эти маршруты для заполнения таблиц переадресации, которые ассоциируются ими с сайтами CE2 и CE3, соответственно. Маршруты из сайтов, которые находятся вне VPN V, не заносятся в эти таблицы, поэтому пакеты от CE2 или CE3 не могут быть посланы сайтам, которые не принадлежат VPN V. Если сайт является множественной VPN, таблица переадресации, ассоциированная с этим сайтом, может содержать маршруты от полного набора сетей VPN, членом которого является сайт. PE содержит вообще только одну таблицу переадресации на сайт, даже если он соединен с сайтом несколькими путями. Различные сайты могут использовать одну и ту же таблицу переадресации, если они намерены пользоваться одним и тем же набором маршрутов. Предположим, что пакет получен PE-маршрутизатором от определенного сайта, соединенного с ним непосредственно, но место назначения пакета не связано ни с одной из записей таблицы переадресации данного сайта. Если SP не предоставляет доступа к Интернет для данного сайта, тогда пакет отбрасывается. Если SP предоставляет доступ к Интернет для данного сайта, тогда просматривается таблица переадресации PE. Для поддержки надежной изоляции одной VPN от другой, важно, чтобы ни один маршрутизатор в опорной сети не принимал помеченных пакетов от смежных устройств неопорной сети, если только выполняются следующие условия: (a) метка в верхней позиции стека действительно прислана маршрутизатором опорной сети в устройство не опорной сети, и (b) маршрутизатор опорной сети может определить, что использование этой метки вызовет уход пакета из опорной сети, до того как будет рассмотрена какая-либо ниже лежащая в стеке метка, и до того как будет проанализирован IP-заголовок. Эти ограничения необходимы, для того чтобы препятствовать попаданию пакетов в VPN, которой они не принадлежат. Таблицы переадресации сайта в PE используются только для пакетов, которые приходят от сайта, непосредственно связанного с PE. Они не используются для маршрутизации пакетов, которые присылаются другими маршрутизаторами, принадлежащими опорной сети SP. В результате может существовать несколько разных маршрутов до одной и той же системы, которые определяются сайтом, из которого пакет попадает в опорную сеть. Например, может существовать маршрут до данной системы для пакетов из экстранет (где маршрут ведет через firewall), и другой маршрут для пакетов из интранет (включая пакеты, которые уже идут через firewall). 3.1. Виртуальные сайты В некоторых случаях, конкретный сайт может быть поделен клиентом на несколько виртуальных, возможно с привлечением техники VLAN. Виртуальные сайты могут быть членами различных наборов VPN. PE должен тогда содержать разные таблицы переадресации для каждого виртуального сайта. Например, если CE поддерживает VLAN, и нужно установить соответствие между VLAN и VPN, пакеты, пересылаемые между CE и PE, могут инкапсулироваться с использованием техники VLAN внутри сайта, это может осуществляться PE, совместно с интерфейсом, через который получен пакет, чтобы установить соответствие пакета и определенного виртуального сайта. В качестве альтернативы можно разделить интерфейс на несколько субинтерфейсов, (в частности, если интерфейс следует стандарту Frame Relay или ATM), и ассоциировать пакет с VPN на основе суб-интерфейса, через который он вошел. Можно также просто использовать отдельный интерфейс для каждого виртуального сайта. В любом случае, для одного сайта нужен только один CE-маршрутизатор, даже в случае большого числа виртуальных сайтов. Конечно, если хочется, можно использовать разные маршрутизаторы CE для каждого виртуального сайта. Заметим, что во всех случаях, механизмы, как и политика для управления того, какой трафик пропускать и для какого VPN, находится в руках клиента. Если желательно иметь определенную ЭВМ в составе нескольких виртуальных сайтов, тогда эта машина должна определять для каждого пакета, с каким виртуальным сайтом следует его ассоциировать. Это можно сделать, например, путем посылки пакетов из разных виртуальных сайтов в различные VLAN, или через разные сетевые интерфейсы. Эти схемы не требуют от CE поддержки MPLS. Раздел 8 содержит краткое описание того, как CE может поддерживать большое число виртуальных сайтов, если оно не поддерживает MPLS. 4. Распределение маршрутов VPN посредством BGP Маршрутизаторы PE используют BGP для рассылки маршрутов между VPN (точнее, для вынуждения VPN обмениваться маршрутами между собой). Отправитель BGP может анонсировать и разослать маршрут для данного адресного префикса. Каждая VPN может иметь свое адресное пространство, это означает, что некоторые адреса могут использоваться в любом числе VPN, где в каждой VPN адрес соотносится с разной системой. Отсюда следует, что нужно позволить BGP инсталлировать и рассылать по несколько маршрутов для одного IP-адресного префикса. Более того, нужно гарантировать, что для определения того, какой маршрут из списка, предоставленного BGP, может использовать сайт и какой из них будет прописан в таблице переадресации, служит политика. 4.1. Адресное семейство VPN-IPv4 Мультипротокольное расширение BGP [3] позволяет этому протоколу работать со многими "адресными семействами". Введем обозначение "VPN-IPv4 address family". Адрес VPN-IPv4 имеет 12-байт и начинается с 8 байт идентификатора маршрута RD (Route Distinguisher) и завершается четырьмя байтами адреса IPv4. Если две VPN используют один и тот же адресный префикс IPv4, PE транслирует их в уникальный адресный префикс VPN-IPv4. Это гарантирует, что в случае использования одного и того же адреса в двух разных VPN, будет возможно установить два совершенно разных маршрута до этого адреса по одному для каждого VPN. RD не предполагает какой-либо семантики, он не содержит информации о происхождении маршрута или о наборе VPN, куда маршруты следует рассылать. Целью RD является позволить формирование пути к общему адресному префиксу IPv4. RD может также использоваться для формирования множественных путей к одной и той же системе. В разделе 3, приводится пример, где маршрут к определенному серверу должен быть разным для интранет и экстранет. Это может быть достигнуто путем создания двух разных VPN-IPv4 маршрутов, которые имеют идентичную IPv4 часть, но разные RD. Это позволяет BGP установить несколько разных путей к одной и той же системе и разрешить использование политики (смотри раздел 4.2.3), чтобы решить, какие пакеты будут пользоваться данным маршрутом. RD структурированы так, что каждый сервис-провайдер может администрировать свою зону нумерации (т.e., может выполнить свои собственные присвоения для RD), не конфликтуя с RD, присвоенными другими сервис-провайдерами. RD состоит из двухбайтного поля типа, поля администратора и поля присвоенного номера. Значение поля типа определяет длины двух других полей, а также семантику поля администратор. Поле администратор идентифицирует систему присвоения номеров (assigned number authority), а поле присвоенного номера несет в себе число, которое служит для идентификации этой системы. Например, может существовать RD, чье поле администратор содержит ASN (Autonomous System number), и чье поле номера (4-байта) содержит число, присвоенное SP, которому этот код ASN присвоен IANA. Для RD выбрана такая структура, для того, чтобы гарантировать, что SP, который предоставляет услуги опорной сети, может всегда сформировать уникальный RD, когда это потребуется. Однако данная структура не предоставляет никакой семантики. Когда BGP сравнивает два таких адресных префикса, он полностью игнорирует структуру. Если субполя администратор и присвоенный номер адреса VPN-IPv4 установлены равными нулю, считается, что адрес VPN-IPv4 имеет то же значение, что и глобально уникальный адрес IPv4. В частности, этот VPN-IPv4 адрес и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как совместимые. Во всех других случаях, адрес VPN-IPv4 и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как несовместимые. Данная таблица переадресации сайта будет иметь только один маршрут VPN-IPv4 для любого заданного адресного префикса IPv4. Когда место назначения пакета соответствует маршруту VPN-IPv4, это соответствие касается только IPv4-части. PE должен быть сконфигурирован так, чтобы установить соответствие между маршрутами, ведущими к конкретному CE, и их RD. PE может быть сконфигурирован так, чтобы установить соответствие между всеми маршрутами, ведущими к одному CE и имеющими данный RD. Он может быть сконфигурирован и так, чтобы установить соответствие между разными маршрутами, имеющими различные RD даже если они ведут к одному и тому же CE. 4.2. Управление рассылкой маршрутов В данном разделе, обсуждается способ управления рассылкой маршрутов VPN-IPv4. 4.2.1. Атрибут Target VPN Каждая таблица переадресации соответствует одному или более атрибутам "Target VPN". Когда маршрут VPN-IPv4 сформирован маршрутизатором PE, он ассоциируется с одним или более атрибутами " Target VPN". Они рассматриваются протоколом BGP как атрибуты маршрута. Любой маршрут, ассоциированный с Target VPN T должен рассылаться каждому маршрутизатору PE, который имеет таблицу переадресации, ассоциированную с Target VPN T. Когда такой маршрут получен PE-маршрутизатором, он пригоден для инсталляции в каждой из таблиц переадресации PE, которая ассоциируется с Target VPN T. (Будет ли этот маршрут инсталлирован, зависит от процесса принятия решений BGP). По существу, атрибут Target VPN идентифицирует набор сайтов. Ассоциация конкретного атрибута Target VPN с маршрутом позволяет поместить маршрут в таблицу переадресации, которая используется для маршрутизации трафика, приходящего от соответствующих сайтов. Имеется набор Target VPN, которые маршрутизатор PE подключает к маршруту, полученному из сайта S. Имеется набор Target VPN, которые маршрутизатор PE использует для определения, будет ли маршрут, полученный от другого маршрутизатора PE, помещен в таблицу переадресации, ассоциированную с сайтом S. Эти два набора различны, и не должны быть идентичны. Функции, выполняемые атрибутом Target VPN, сходны с осуществляемыми атрибутом BGP Communities Attribute. Однако формат последнего не является адекватным, так как он позволяет только двухбайтовое пространство для нумерации. Самым простым решением является расширение пространства нумерации атрибута BGP Communities. Должно быть также возможно структурировать формат, аналогично тому, как это описано для RD (смотри раздел 4.1), так что поле тип определит длину поля администратор, а оставшаяся часть атрибута является номером из пространства нумерации администратора. Когда BGP маршрутизатор получил два маршрута до одного и того же префикса VPN-IPv4, он выбирает один, согласно BGP правилам предпочтения маршрутов. Заметим, что маршрут может иметь только один RD, но он может иметь несколько Target VPN. В BGP масштабируемость улучшается, если имеется один маршрут с несколькими атрибутами. Можно пренебречь атрибутом Target VPN, создавая больше маршрутов (т.e., используя большее число RD), но тогда свойства масштабируемости окажутся менее привлекательными. Как PE определяет, какой из атрибутов Target VPN, ассоциировать с данным маршрутом? Существует большое число различных способов. PE может быть сконфигурирован так, чтобы ассоциировать все маршруты, которые ведут к определенному сайту, с некоторым заданным Target VPN. Или PE может быть сконфигурирован так, чтобы определенные маршруты, вели к конкретномусайту с одним Target VPN, а к другому с другим. Или CE-маршрутизатор, когда он рассылает маршруты (смотри раздел 6), можно специфицировать один или более Target VPN для каждого маршрута. Последний метод перемещает управление механизмом, используемым для реализации политики VPN от SP к клиенту. Если используется этот метод, может быть желательным, чтобы PE удалил любую Target VPN, которая согласно его собственной конфигурации, не допустима, и/или добавил некоторую Target VPN, которая согласно его конфигурации является обязательной. Более точно было бы называть этот атрибут " Route Target" вместо "VPN Target". 4.2.2. Расылка маршрутов между PE посредством BGP Если два сайта VPN подключены к PE, которые размещены в одной автономной системе, PE могут рассылать маршруты VPN-IPv4 друг другу посредством соединения IBGP. Если два сайта VPN находятся в разных автономных системах (например, из-за того, что они соединены с разными SP), тогда PE-маршрутизатор будет вынужден использовать маршрутизатор IBGP для перераспределения VPN-IPv4 маршрутов в маршрутизатор ASBR (Autonomous System Border Router), или в маршрутизатор-рефлектор, клиентом которого является ASBR. ASBR будет вынужден использовать EBGP, чтобы перераспределить эти маршруты в ASBR из другой AS. Это позволяет соединить различные сайты VPN различным сервис-провайдерам.Однако маршруты VPN-IPv4 должны восприниматься только соединениями EBGP в точках пирингового обмена. Маршруты VPN-IPv4 не должны никогда рассылаться и восприниматься общедоступным Интернет. Если имеется много VPN, содержащих сайты, подсоединенные к различным автономным системам, не обязательно иметь только один ASBR между двумя AS, которые содержат все маршруты для всех VPN; могут быть несколько ASBR, каждый из которых содержит только маршруты для конкретного субнабора VPN. Когда маршрутизатор PE рассылает маршрут VPN-IPv4 через BGP, он использует свой собственный адрес в качестве " BGP next hop". Он также определяет и рассылает метки MPLS. (Существенно, что маршрутизаторы PE рассылают не VPN-IPv4 маршруты, а маркированные маршруты VPN-IPv4. [8]) Когда PE обрабатывает пакет, который имеет эту метку на вершине стека, PE очистит стек, и пошлет пакет непосредственно сайту, от которого ведет маршрут. Это обычно означает, что он посылает пакет маршрутизатору CE, от которого он узнал о маршруте. Метка может также определить инкапсуляцию данных в канале. В большинстве случаев, метка присвоенная PE, заставит послать пакет непосредственно к CE, а PE , который получает пакет с меткой, не будет искать адрес места назначения пакета в какой-либо таблице переадресации. Однако для PE возможно также присвоить метку, которая неявно идентифицирует некоторую таблицу переадресации. В этом случае, PE, получающий пакет, будет искать адрес места назначения пакета с меткой в одной из его таблиц переадресации. Заметим, что метка MPLS, которая рассылается таким способом, может использоваться, только если существует маркированный путь между маршрутизатором, его сформировавшим, и BGP-маршрутизатором на следующем шаге. Здесь не делается никакого предположения об используемой процедуре установления маркированного пути (процедура setup). Он может быть сформирован предварительно, или установлен, когда нужный маршрут будет инсталлирован. Это может быть оптимальный маршрут ("best effort"), или это может быть маршрут созданный в результате процедуры формирования трафика (traffic engineered). Между конкретным маршрутизатором PE и его BGP агентом следующего шага для конкретного маршрута может быть один или несколько LSP, возможно с разными характеристиками QoS. Доступны все обычные методы использования отражателей маршрутов [2] для улучшения масштабируемости, например, иерархии отражателей маршрутов. Если используются отражатели маршрута, нет нужды иметь отражатель маршрутов, который знает все VPN-IPv4 маршруты для всех VPN, поддерживаемых опорной сетью. Можно иметь отдельные отражатели маршрута, которые не взаимодействуют друг с другом, каждый из которых поддерживает субнабор общего набора VPN. Если данный маршрутизатор PE не подключен ни к одной Target VPN данного маршрута, он не должен получать этот маршрут. Другие PE или рефлекторы маршрута, которые посылают ему маршруты должны использовать внешние фильтры, чтобы избежать рассылки ненужных маршрутов. Конечно, если маршрутизатор PE получает маршрут через BGP, а данный PE не подключен к какой-либо target VPN маршрута, PE должен применить к этому маршруту внутреннюю фильтрацию, ни анонсируя и не пересылая его. Маршрутизатор, который не подключен к какой-либо VPN, т.e., P-маршрутизатор, вообще никогда не анонсирует какие-либо маршруты VPN-IPv4. Эти правила рассылки маршрутной информации гарантируют, что не будет устройства, которое должно знать все VPN-IPv4 маршруты, которые поддерживаются через опорную сеть. В результате полное число таких маршрутов, которые могут поддерживаться через опорную сеть не ограничивается емкостью какого-либо отдельного устройства, и, следовательно, может увеличиваться виртуально беспредельно. 4.2.3. Атрибут VPN of Origin Маршрут VPN-IPv4 может быть опционно ассоциирован с атрибутом VPN of Origin. Это атрибут уникально идентифицирует набор сайтов и идентифицирует соответствующий маршрут, как пришедший из одного из сайтов этого набора. Типичным применением этого атрибута может быть идентификация предприятия, которое владеет сайтом, куда ведет маршрут, он может также идентифицировать интранет сайта. Однако возможны и другие применения. Этот атрибут может быть представлен как расширение атрибута BGP communities. В ситуации, в которой необходимо идентифицировать источник маршрута, используется именно этот атрибут, а не RD. Этот атрибут может использоваться при формировании VPN, как это описано ниже. Возможно более корректно называть этот атрибут "Начало маршрута", а не " VPN of Origin". Он в действительности идентифицирует маршрут, приходящий из определенного набора сайтов вне зависимости оттого, составляет ли этот набор VPN.
Путем соответствующей установки атрибутов Target VPN и VPN of Origin, можно сконструировать VPN самого разного типа. Предположим, что нужно создать замкнутую группу пользователей CUG (Closed User Group), которая содержит определенный набор сайтов. Это может быть сделано путем формирования определенного атрибута Target VPN для CUG. Значение этого атрибута затем должно быть ассоциировано с таблицами переадресации сайта для каждого сайта в CUG, оно должно быть связано с каждым маршрутом, полученным от сайта в CUG. Любой маршрут, который имеет этот атрибут Target VPN, должен быть перераспределен так, чтобы достичь каждого маршрутизатора PE, подключенного к одному из сайтов. В качестве альтернативы, предположим, что желательно по какой-то причине создать VPN типа "hub and spoke" (ось и спица). Это может быть сделано путем использования двух значений атрибута Target, один со значением " Hub" а другой со значением "Spoke". Затем маршруты от spokes могут быть посланы hub, не вызывая посылки маршрутов в обратном направлении. Предположим, имеется определенное число сайтов, размещенных в интранет и экстранет, и некоторое число сайтов, принадлежащих только интранет. Далее могут существовать маршруты интранет и экстранет, которые имеют Target VPN, идентифицирующий весь набор сайтов. Сайты, которые содержат маршруты только интранет, могут отфильтровывать все маршруты с некорректным VPN of Origin. Эти два атрибута допускают большую гибкость, позволяя управлять процессом рассылки маршрутной информации между различными наборами сайтов, которые в свою очередь упрощают построение VPN. 5. Переадресация в опорной сети Если промежуточные маршруты в опорной сети не имеют никакой информации о маршрутах в VPN, как пакеты будут переадресованы из одного сайта VPN к другому? Это делается с помощью MPLS с двумя уровнями в стеке меток. Маршрутизаторы PE (и ASBR, которые перераспределяют адреса VPN-IPv4) должны ввести адресные префиксы /32 для самих себя в таблицы маршрутизации опорной сети. Это позволяет MPLS, в каждом узле опорной сети присвоить метку, соответствующую маршруту к каждому маршрутизатору PE. (Определенные процедуры для установления коммутации меток в опорной сети могут не требовать присутствия адресного префикса /32.) Когда PE получает пакет от CE-устройства, он выбирает определенную таблицу переадресации сайта, в которой ищется адрес места назначения пакета. Предположим, что такой адрес найден. Если пакет адресован устройству CE, подключенному к тому же самому PE, пакет посылается непосредственно устройству CE. Если пакет адресован не устройству CE, подключенному к тому же PE, важен "BGP Next Hop" пакета, а также метка, которую этот BGP следующего шага присвоил адресу места назначения пакета. Эта метка укладывается в стек меток пакета. Затем PE ищет маршрут IGP до BGP следующего шага, и таким образом определяет маршрутизатор следующего шага IGP, а также метку, приписанную адресу маршрутизатора следующего шага BGP. Эта метка заносится на верх стека меток пакета, а пакет затем переадресуется к маршрутизатору следующего шага IGP. (Если BGP следующего шага является тем же что и для IGP, вторая метка может не извлекаться из стека). В этой точке MPLS будет транспортировать пакет через опорную сеть и в соответствующее CE-устройство. То есть, все решения о переадресации в P- и PE-маршрутизаторах принимаются на уровне MPLS, а IP-заголовки пакетов не анализируются повторно до тех пор, пока они не достигнут устройства CE. Оконечный маршрутизатор PE прежде чем посылать пакет устройству CE, извлекает из стека MPLS очередную метку, таким образом, устройство CE получит обычный IP-пакет. Когда пакет входит в опорную сеть из определенного сайта через конкретный PE маршрутизатор, путь пакета определяется содержимым таблицы переадресации. Таблицы переадресации маршрутизатора PE, через который пакет покидает опорную сеть не существенны. В результате можно иметь несколько маршрутов до одной и той же системы, где конкретный маршрут, выбранный для конкретного пакета, определяется сайтом, через который пакет попал в опорную сеть. Заметим, что двухуровневая маркировка делает возможным увод всех маршрутов VPN от маршрутизаторов P, а это в свою очередь важно для гарантии масштабируемости модели. Опорная сеть не должна иметь маршрутов к CE (только к PE). 6. Как PE узнают о маршрутах от CE Маршрутизаторы PE, которые подключены к какой-то VPN, должны знать адреса для каждого сайта из данного VPN. В случае, когда CE-устройство является ЭВМ или сетевым переключателем, этот набор адресов будет конфигурироваться в маршрутизаторе PE, подключающем данное устройство. В случае, когда CE-устройство является маршрутизатором, существует много способов, с помощью которых PE-маршрутизатор может получить этот набор адресов. PE транслирует эти адреса в адреса VPN-IPv4, используя сконфигурированный RD. PE далее рассматривает эти маршруты в качестве входной информации протокола BGP. Ни при каких обстоятельствах маршруты из сайта не должны уходить в IGP опорной сети. Какой из методов рассылки маршрутов PE/CE возможен, зависит от того, является ли конкретное устройство CE "транзитным VPN" или нет. "Транзитная VPN" - это сеть, которая содержит маршрутизатор, получающий маршруты от "третей стороны" (т.e., от маршрутизатора, который находится вне VPN, но не является PE-маршрутизатором), и который перераспределяет эти маршруты в маршрутизатор PE. VPN, которая не является транзитной VPN, представляет собой "частичную VPN". Подавляющее большинство VPN, включая практически все корпоративные сети, следует считать такими. Возможные механизмы рассылки PE/CE: 1. Может использоваться статическая маршрутизация (т.e., конфигурация). 2. PE и CE-маршрутизаторы могут быть RIP-партнерами, а CE может использовать RIP, чтобы сообщить маршрутизатору PE набор адресных префиксов, которые достижимы для сайта CE. Когда RIP сконфигурирован в CE, следует позаботиться о том, чтобы адресные префиксы от других сайтов (т. e., адресные префиксы, полученные маршрутизатором CE от маршрутизатора PE) никогда не анонсировались PE. Точнее, если маршрутизатор PE, скажем PE1, получает VPN-IPv4 маршрут R1, и в результате посылает маршрут IPv4 R2 в CE, R2 не должен быть послан назад из сайта CE в маршрутизатор PE, скажем PE2, (где PE1 и PE2 может быть тем же маршрутизатором или разными маршрутизаторами), если только PE2 не ставит в соответствие R2 и маршрут VPN-IPv4, который отличается от (т.e., содержит другой RD) R1. 3. Маршрутизаторы PE и CE могут быть партнерами OSPF. В этом случае, сайт должен быть единой областью OSPF, CE должно быть ABR для этой области, а PE должно быть ABR, который находится вне области. Кроме того, PE не должен анонсировать никакие связи маршрутизатора кроме тех, что существуют до CE, размещенном в том же сайте. (Этот метод должен использоваться только в частичных VPN.) 4. Маршрутизаторы PE и CE могут быть партнерами BGP, а маршрутизатор CE может использовать BGP (В частности, EBGP, чтобы уведомить маршрутизатор PE о наборе адресных префиксов, которые находятся в сайте маршрутизатора CE. (Эта технология может использоваться в частичных или транзитных VPN). С чисто технической точки зрения это далеко не совершенная методика: a) В отличии от альтернатив IGP, это не требует от PE запускать несколько запросов алгоритму маршрутизации, для того чтобы взаимодействовать с несколькими CE. b) BGP сконструирован как раз для решения таких задач: пересылки маршрутной информации между системами, управляемыми разными администраторами. c) Если сайт содержит "BGP backdoors", т.e., маршрутизаторы с BGP-соединениями с маршрутизаторами, отличными от PE-маршрутизаторов, эта процедура будет работать корректно при любых обстоятельствах. Другие процедуры могут работать или нет, в зависимости от конкретных обстоятельств. d) Использование BGP упрощает для CE передачу атрибутов маршрутов PE. Например, CE может предложить определенный Target для каждого маршрута, из числа атрибутов Target, которые авторизованы PE для присвоения маршруту. С другой стороны, использование BGP вероятно является чем-то новым для CE администраторов, за исключением случая, когда клиент сам является Интернет сервис-провайдером. Если сайт не является транзитной VPN, он не должен иметь уникальный ASN (Autonomous System Number). Каждый CE, чей сайт не является транзитной VPN, может использовать один и тот же ASN. Значение может быть взято из частного ASN-пространства, оно будет ликвидировано PE. Маршрутные петли предотвращаются путем использования атрибута Site of Origin (см. ниже). Если набор сайтов представляет собой транзитную VPN, удобно представить их как BGP конфедерацию, так что внутренняя структура VPN окажется спрятанной от любого маршрутизатора, который находится вне VPN. В этом случае, каждый сайт в VPN потребует двух BGP-соединений с опорной сетью, одно будет внутренним по отношению к конфедерации, а другое - внешним. Обычные интра-конфедерационные процедуры должны будут слегка модифицированы, для того чтобы учесть возможность того, что опорная сеть и сайты могут иметь разную политику. Опорная сеть является членом конфедерации на одном из соединений, но не будет членом конфедерации на другом. Такие методики могут быть полезны, если клиентом для услуг VPN является ISP. Эта методика позволяет клиенту, который является ISP, получить услуги опорной сети VPN от одного из партнеров ISP. Когда нам не нужно различать разные пути, которыми PE может быть проинформирован об адресном префиксе, который существует в данном сайте, мы просто говорим, что PE узнал маршруты от сайта. Прежде чем PE сможет передать VPN-IPv4 маршрут, узнанный от сайта, он должен присвоить ему определенный атрибут. Существует три таких атрибута: - Исходный сайт (Site of Origin) Этот атрибут однозначно идентифицирует сайт, от которого маршрутизатор PE узнал о маршруте. Всем маршрутам, полученным от определенного сайта, должен быть присвоен один и тот же атрибут Site of Origin, даже если сайт имеет несколько соединений с одним PE, или соединен с несколькими PE. Определенные атрибуты Site of Origin должны использоваться с определенными сайтами. Этот атрибут может быть представлен как атрибут extended BGP communities (раздел 4.2.1). - VPN of Origin Смотри раздел 4.2.1. - Target VPN Смотри раздел 4.2.1. 7. Как CE узнает маршруты от PE В данном разделе мы предполагаем, что устройством CE является маршрутизатор. Вообще, PE может послать любой маршрут в CE, который PE поместил в таблицу переадресации, которую он использует для маршрутизации пакетов из CE. Существует одно исключение: если атрибут маршрута Site of Origin идентифицирует конкретный сайт, такой маршрут не должен никогда посылаться какому-либо CE этого сайта. В большинстве случаев, однако будет достаточно для PE просто послать CE маршрут по умолчанию. В некоторых случаях, может быть даже достаточно сконфигурировать CE с маршрутом по умолчанию, указывающим на PE. Это работает для любого сайта, который не требует рассылки маршрута по умолчанию другим сайтам. Например, если один сайт в корпоративной VPN имеет корпоративный доступ к Интернет, это сайт может нуждаться в рассылке маршрута по умолчанию другому сайту. Какая бы из процедур ни использовалась для рассылки маршрутов от CE к PE, она же может служить для передачи маршрутов от PE к CE. 8. Если CE поддерживает MPLS? В случае, когда CE поддерживает MPLS, и хочет импортировать весь набор маршрутов из своего VPN, PE может разослать метку для каждого такого маршрута. Когда PE получает пакет от CE с такой меткой, он (a) замещает эту метку соответствующей меткой, которую он получил через BGP, и (b) заносит метку в стек поверх метки, соответствующей BGP следующего шага для заданного маршрута. 8.1. Виртуальные сайты Если рассылка маршрутов CE/PE выполнена через BGP, CE может использовать MPLS, чтобы осуществить поддержку большого числа сайтов. CE может сам содержать отдельную таблицу переадресации для каждого виртуального сайта, которую он заполняет, как это указано атрибутом Origin and Target VPN маршрутов, получаемых им от PE. Если CE получает от PE полный набор маршрутов, PE не будет должен просматривать адреса пакетов, полученных от CE. В качестве альтернативы PE может в некоторых случаях посылать CE отдельный (помеченный) маршрут по умолчанию для каждого VPN. Затем, когда PE получает помеченный пакет от CE, он узнает, какую таблицу переадресации следует просматривать. Метка, помещенная в пакет CE, будет идентифицировать только виртуальный сайт, от которого пакет пришел. 8.2. Представление ISP VPN в качестве части VPN Если определенная VPN является в действительности ISP, но ее маршрутизаторы CE поддерживают MPLS, тогда VPN может рассматриваться как частичная VPN. Маршрутизаторы CE и PE должны только обмениваться маршрутами, которые являются внутренними по отношению к VPN. Маршрутизатор PE отправит маршрутизатору CE метку для каждого из этих маршрутов. Маршрутизаторы в других сайтах VPN могут тогда стать партнерами BGP. Когда маршрутизатор CE просматривает адрес назначения пакета, маршрутный поиск всегда возвращает внутренний адрес, обычно адрес BGP следующего шага. CE помечает пакеты соответствующим образом и посылает их к PE. 9. Безопасность
a) Помеченные пакеты не воспринимаются маршрутизаторами опорной сети, если они пришли из источников не внушающих доверия, если только не известно, что такие пакеты покинут опорную сеть до того как будут проанализированы IP-заголовки или какие-либо метки в стеке, и b) помеченные маршруты VPN-IPv4 не воспринимаются, если они пришли из источников не внушающих доверия, безопасность предоставляемая этой архитектурой виртуально идентична той, которая реализуется опорными сетями VPN Frame Relay или ATM. Не имеет никакого значения тот факт, что использование MPLS упрощает достижение уровня безопасности, который возможен при создании туннеля IP-поверх-IP вместо MPLS. Довольно просто отказать в допуске помеченных пакетов, если только не реализуется первое из указанных выше условий. Много труднее сконфигурировать маршрутизатор так, чтобы заблокировать прием IP-пакетов, если эти пакеты представляют собой IP-поверх-IP, идущие в "неправильное" место. Использование MPLS позволяет также расширить зону действия VPN на несколько SP вне какой-либо зависимости от междоменной рассылки маршрутной информации. Для пользователя VPN возможно также обеспечить себя повышенной безопасностью путем применения туннельного режима IPSEC [5]. Пользователи VPN, чувствительные к проблемам безопасности, могут требовать гарантии того, что некоторые или все пакеты, которые проходят через опорную сеть, были аутентифицированы и/или зашифрованы. Стандартный путь получения такого режима заключается в создании "безопасного туннеля" для каждой пары маршрутизаторов CE в VPN, используя туннельный режим IPSEC. Однако процедуры, описанные до сих пор, не позволяют маршрутизатору CE, посылающему пакет, определить идентичность следующего маршрутизатора CE, через который пройдет пакет. Эта информация необходима, для того чтобы использовать туннельный режим IPSEC. Итак, мы должны расширить данные процедуры, чтобы сделать эту информацию доступной. Способ достижения этого предложен в [6]. Каждый маршрут VPN может иметь атрибут, который идентифицирует следующий маршрутизатор CE, через который пройдет путь. Если эта информация предоставлена всем маршрутизаторам CE в VPN, может использоваться стандартный туннельный режим IPSEC. Если CE и PE являются BGP-партнерами, естественно представить эту информацию в виде атрибута BGP. Каждый CE, который должен использовать IPSEC, должен быть так сконфигурирован, чтобы запретить посылку небезопасного трафика по любому из оговоренных адресов. Это блокирует посылку небезопасного трафика CE, если по какой-то причине ему не удалось получить необходимую информацию. Когда MPLS используется для переноса пакетов между двумя конечными точками туннеля IPSEC, внешний заголовок IPSEC не выполняет в действительности никакой функции. Может быть желательно разработать форму туннеля IPSEC, которая позволяет отбрасывать внешний заголовок, в тех случаях, когда используется MPLS. 9.2. Многокомпонентные безопасные ассоциации Вместо построения безопасного туннеля между каждой парой маршрутизаторов CE, может оказаться более привлекательным сформировать одну безопасную ассоциацию с большим числом участников. В такой ассоциации, все маршрутизаторы CE, которые находятся в конкретной VPN, будут иметь идентичные параметры безопасности (например, некоторый ключ, определенный алгоритм и т.д.). Тогда устройство CE не должно будет знать, какое CE должно получать данные следующим, оно должно знать какой сети VPN предназначена эта информация. CE, которое принадлежит нескольким VPN, может использовать различные параметры безопасности для каждой из них, таким образом защищая, например, пакеты интранет от попадания в экстранет. Для такой схемы не может быть применен стандартный туннельный режим IPSEC, так как здесь нет способа заполнить поле IP-адреса места назначения внешнего заголовка. Однако когда MPLS используется для переадресации, реальной необходимости этого не существует; маршрутизатор PE может использовать MPLS, чтобы ввести пакет в конечную точку туннеля, даже не зная его IP-адреса; он только должен отслеживать IP-адреса места назначения внутреннего заголовка. Существенным преимуществом схемы, подобной этой, является то, что изменение в маршрутизации (в частности, изменение выхода CE для конкретного адресного префикса) прозрачны для механизма безопасности. Это может быть важным, в частности, в случае мультипровадерских VPN, где нужно пересылать информацию об изменении маршрутов с целью поддержания механизмов безопасности. Другим преимуществом является то, что исключена необходимость внешнего IP-заголовка, так как инкапсуляция MPLS берет на себя эту функцию. 10. Качество обслуживания Качество обслуживания (QoS) является ключевым компонентом любой системы VPN. В MPLS/BGP VPN, существующие возможности L3 QoS могут быть применены к помеченным пакетам посредством использования "экспериментальных" битов в промежуточном заголовке [10], или, в случае применения в качестве опорной сети ATM, за счет использования QoS-возможностей самой сети ATM. Управление трафиком, обсуждаемое в работе [1], также применимо к сетям VPN MPLS/BGP. Управление трафиком, если это желательно, может использоваться даже для установления LSP с конкретными параметрами QoS между определенными парами сайтов. Когда MPLS/BGP VPN охватывает нескольких SP, может быть применена архитектура, описанная в [7]. SP может реализовать либо intserv или diffserv возможности конкретной сети VPN. 11. Масштабируемость Мы обсуждали масштабируемость на протяжении всего документа. В данном разделе, кратко суммируются основные характеристики модели с точки зрения масштабирования. Опорная сеть сервис провайдера состоит из следующих компонентов: (a) PE-маршрутизаторов, (b) BGP отражателей маршрута, (c) P-маршрутизаторов (которые являются либо PE-маршрутизаторами, либо рефлекторами маршрута), и в случае мульти-провайдерской VPN, (d) ASBR. P-маршрутизаторы не поддерживают никакие VPN маршруты. Для того чтобы правильно маршрутизовать VPN трафик, P-маршрутизаторы должны поддерживать только маршруты до PE-маршрутизаторов и ASBR. Использование двух уровней пометки позволяет увести маршруты VPN от P-маршрутизаторов. Маршрутизатор PE поддерживает VPN маршруты, но только для тех VPN, с которыми связан непосредственно. Рефлекторы маршрутов и ASBR могут быть распределены в сетях VPN так, что каждая составная часть содержит маршруты только для субнабора VPN, обслуживаемого провайдером. Таким образом, одного рефлектора маршрутов или ASBR не достаточно для поддержания всех VPN. В результате ни один компонент в сети сервис-провайдера не должен поддерживать все маршруты для всех VPN. Итак, полная возможность сети для поддержания увеличивающегося числа участников VPN не ограничивается возможностями одного компонента. 12. Ссылки [1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress. [2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996. [3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998. [4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress. [5] Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress. [7] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC2430, October 1998. [8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress. [9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress. [10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress. |
|
Previous:
4.4.20 Требования для управления трафиком
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.9.7 Протокол COPS (Common Open Policy Service)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP) и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике [RSVP]. Мы предполагаем, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [WRK]. Характеристики протокола COPS содержат следующие моменты (RFC-2748):
1. Базовая модель
Рис. .1. Схема взаимодействия различных частей COPS. На рисунке .1 показано взаимодействие различных компонентов политики (взято из [WRK]). Здесь, COPS используется для обмена описаниями политики между узлами реализации политики PEP (Policy Enforcement Point) и удаленными пунктами принятия политических решений PDP (Policy Decision Point) в пределах контекста конкретного типа клиента. Может использоваться опционный пункт принятия локального политического решения LPDP (Local Policy Decision Point) в отсутствии PDP. Предполагается, что каждый конкретный клиент политики функционально совместим с PEP [WRK]. PEP может обмениваться информацией с сервером политики. PEP ответственен за инициализацию постоянного TCP-соединения с PDP. Узел PEP использует это соединение для посылки запросов и получения откликов-решений от удаленного PDP. Коммуникация между PEP и удаленным PDP происходит в основном в форме обменов запрос-решение, хотя удаленный PDP может по своей инициативе послать PEP и не запрошенное решение, чтобы вызвать изменение одобренных ранее состояний запросов. PEP имеет также возможность сообщать удаленному >PDP, что решение PDP успешно исполнено локально. Узел PEP ответственен за уведомление PDP об изменении состояния запроса в PEP. Наконец, в функции PEP входит аннулирование любого состояния, которое не может быть использовано из-за событий, имевших место у клиента, или в силу решений, принятых сервером. После этого PEP посылает конфигурационный запрос, и ожидает присылки от PDP именованных блоков конфигурационных данных (в виде сообщений-решений). Когда именованные конфигурационные данные успешно доставлены PEP, он должен послать PDP сообщение-отчет, подтверждающее получение конфигурационных данных. Сервер с помощью сообщения-решения может после этого обновить или удалить конфигурационную информацию. Когда PDP посылает решение об удалении именованной конфигурационной информации на PEP, PEP стирает специфицированные данные и посылает PDP в качестве подтверждения сообщение-отчет. Протокол политики предполагает коммуникацию с само идентифицируемыми объектами, которые содержат данные, необходимые для идентификации состояний запроса, устанавливающие контекст запроса, его тип, содержащие ссылки на поступившие ранее запросы, принятые политические решения, поступившие сообщения об ошибках и прочие данные специфичные для клиента. Чтобы идентифицировать разные виды клиентов, в каждом сообщении приводится тип клиента. Разные типы клиентов могут иметь различные специфические данные и могут требовать различных политических решений. Ожидается, что каждый новый тип клиента имеет соответствующее описание, характеризующее специфику его взаимодействия с данным протоколом описания политики. Контекст каждого запроса соответствует типу события, его вызвавшего. Объект контекста COPS идентифицирует тип запроса и сообщения, которые вызвали данное политическое событие, посредством своих полей типа сообщения и запроса. COPS идентифицирует три типа событий: (1) приход сообщения (2) выделение локальных ресурсов, и (3) переадресацию исходящего сообщения. Каждое из этих сообщений может потребовать различных решений. Содержимое сообщений COPS-запросов/решений зависит от контекста. Четвертый тип запроса полезен для типов клиентов, которые хотят получить конфигурационную информацию от PDP. Это позволяет >PEP послать конфигурационный запрос специфическому именованному устройству или модулю, который требует инсталляции конфигурационной информации. PEP может также иметь возможность принимать локальные политические решения с помощью LPDP (Local Policy Decision Point) [WRK], однако, PDP всегда остается точкой принятия решений. Это означает, что соответствующая информация о локальных решениях должна передаваться PDP. То есть, PDP должен быть предоставлен доступ к информации, чтобы принять окончательное политическое решение. Чтобы обеспечить такую возможность, PEP должен послать информацию о локальном решении удаленному PDP посредством объекта решения LPDP. PEP должен затем следовать решению PDP, так как оно является окончательным. Наконец, допустимость ошибки (fault tolerance) является обязательной особенностью данного протокола, в частности из-за того, что он ассоциируется с управлением услугами и безопасностью в распределенных сетях. Допустимость ошибки может быть достигнута за счет того, что PEP и удаленный PDP постоянно проверяют свое соединение путем посылки тестовых сообщений keep-alive ("еще жив?"). Когда обнаружен отказ, PEP должен попытаться восстановить контакт с удаленным PDP или соединиться с альтернативным (backup) PDP. Пока PEP не имеет связи, он должен ограничиться принятием локальных решений. Как только соединение восстановлено, PEP должен уведомить PDP о любом ликвидированном состоянии или о событиях, которые произошли с момента потери соединения. Кроме того, удаленный PDP может потребовать, чтобы все внутренние состояния PEP были заново синхронизованы (все ранее поступившие запросы должны быть продублированы). После отказа и до того как новое соединение будет восстановлено в полном объеме, ущерб в обслуживании может быть минимизирован, если PEP кэширует переданные ранее решения и продолжает их использовать в течение некоторого ограниченного времени. В разделах 2.3 и 2.5 детально рассмотрены механизмы COPS для обеспечения надежности. 2. Протокол 2.1. Общий заголовок Далее рассматриваются форматы сообщений и объекты, которыми обмениваются PEP и удаленный PDP. Каждое сообщение COPS состоит из заголовка, за которым следует некоторое число типизованных объектов.
//// далее обозначает зарезервированное поле и должно содержать 0. В заголовке имеются поля:
Ниже в таблице представлены значения поля код операции.
Поле Тип клиента: 16 бит Тип клиента идентифицирует клиента политики. Интерпретация всех инкапсулированных объектов Типы клиента, которые устанавливают старший бит в поле тип клиента, зависят от производителя (enterprise specific; это типы клиентов 0x8000 - 0xFFFF). Для сообщений KA тип клиента в заголовке должен быть установлен равным 0, так как KA используется для проверки связи. Длина сообщения: 32 бит Размер сообщения в октетах, который включает в себя стандартный заголовок COPS и все инкапсулированные объекты. Сообщения должны иметь длину кратную 4 октетам. 2.2. Форматы специфических объектов COPS Все объекты имеют один и тот же формат; каждый объект состоит из одного или более 32-битных слов с 4-октетным заголовком. Формат показан на рисунке:
Длина характеризуется двухоктетной величиной, которая описывает число октетов (включая заголовок), которые образуют объект. Если длина в октетах не попадает на границу слова, кратную 32-бит, должно использоваться заполнение вплоть до конца объекта, так чтобы обеспечивать выравнивание, прежде чем объект будет послан. На принимающей стороне соответствующая граница объекта определяется округлением объявленной ранее длины объекта до значения кратного ближайшим 32-бит. Обычно, C-Num идентифицирует класс информации в объекте, а C-тип идентифицирует субтип или версию информации, содержащейся в объекте. C-num: 8 бит
C-type: 8 бит. Значения, определенные для C-num. 2.2.1. Объект дескриптор (Handle) Объект Handle (дескриптор) содержит уникальную величину, которая идентифицирует инсталлированное состояние. Эта идентификация используется большинством операций COPS. Состояние, соответствующее дескриптору, должно быть непосредственно удалено, когда оно более не применимо. C-Num = 1 Поле дескриптора имеет переменную длину, дескриптор должен отличаться от других дескрипторов клиента того же самого PEP (соединение COPS TCP)для определенного типа клиента. Он всегда выбирается PEP в исходный момент и ликвидируется, когда он более не нужен. Дескриптор клиента используется, чтобы осуществить ссылку на состояние запроса инициализированного некоторым PEP и инсталлированным для типа клиента PDP. PEP специфицирует дескриптор клиента в своих сообщениях запроса (Request), отклика (Report) и ликвидации (Delete), посланных к PDP. Во всех случаях, дескриптор клиента служит для однозначной идентификации конкретного запроса PEP для данного типа клиента. Значение дескриптора клиента устанавливается PEP и является непрозрачным для PDP. PDP просто выполняет побайтовое сравнение со значением этого объекта с учетом значений дескрипторов объектов других поступивших запросов. 2.2.2. Объект Context Специфицирует тип события(ий), которое вызвало запрос. Этот объект необходим для сообщений-запросов. Запросы управления доступом, выделения ресурсов, и переадресации зависят от типов клиентов. Для допустимых типов клиента PEP может также послать запрос PDP с целью получения именованной конфигурационной информации. Эта именованная конфигурационная информация может иметь форму, полезную для установления системных атрибутов в PEP, или она может иметь форму правил политики, которые могут быть непосредственно проверены PEP. В одном запросе может присутствовать несколько флагов. Это, однако, допустимо, только если набор специфической информации клиента в комбинированном запросе идентичен набору, который был бы специфицирован в случае посылки отдельного запроса для каждого из флагов. C-num = 2, C-тип = 1
R-тип (флаг типа запроса)
M-Type (Тип сообщения специфичные для клиента (Client Specific) 16-битовые значения типов протокольного сообщения. 2.2.3. Объект In-Interface (IN-Int) Объект In-Interface используется для идентификации входного интерфейса, к которому относится запрос, и PEP, используется обратный адрес и ifindex. Объект Interface используется также для идентификации принимающего интерфейса через его ifindex. Поле ifindex может быть использовано, чтобы отличать субинтерфейсы от ненумерованных интерфейсов (смотри, например RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II. Поле ifindex специфицированное в In-Interface обычно имеет отношение к ниже лежащему потоку протокольных сообщений. Поле ifindex является интерфейсом, через который получаются протокольные сообщения. C-Num = 3
Для этого типа объекта интерфейса, IPv4-адрес специфицирует адрес, откуда пришло сообщение. C-Type = 2, IPv6-адрес + Интерфейс
Для данного типа объекта интерфейса, IPv6-адрес специфицируетIP-адрес, откуда пришло входное сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II PEP, как это описано выше. 2.2.4. Объект Out-Interface (OUT-Int) Объект Out-Interface используется для идентификации выходного интерфейса, которому адресован запрос, и адреса, куда должен быть переправлено сообщение. Для потоков или сообщений, направляемых локальной ЭВМ PEP, используется обратный адрес и ifindex. Out-Interface >имеет те же форматы, что и объект In-Interface. Этот интерфейсный объект используется также для идентификации выходного интерфейса через его ifindex. Поле ifindex может быть использовано для отличия субинтерфейсов от ненумерованных интерфейсов (смотри, например, RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II. Поле ifindex специфицированное в Out-Interface обычно связано с потоком протокольных сообщений. Поле ifindex определяет один из адресов, куда протокольное сообщение может быть переадресовано. C-Num = 4 Некоторые форматы C-типа выступают в качестве объекта In-Interface. IPv4-адрес специфицирует адрес, куда направлено исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP. C-Type = 2, IPv6-адрес + интерфейс Тот же формат C-типа, что и в случае объекта In-Interface. Для этого типа объекта интерфейса, адрес IPv6 специфицирует IP-адрес, которому адресовано исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP. 2.2.5. Объект Reason Этот объект специфицирует причину, почему состояние запроса было стерто. Объект появляется в запросах стирания (DRQ). Поле субкода причины зарезервировано для более подробного описания причины, специфической для клиента и описанной в соответствующих документах. C-Num = 5, C-тип = 1
2.2.6. Объект Decision Решение, принятое PDP. Присутствует в откликах. Специфические необязательные объекты решения необходимы в решениях для определенных запросов в зависимости от типа клиента. C-Num = 6
Команды: 0 = Решение NULL (Конфигурационные данные недоступны) Флаги: 0x01 = Trigger Error (сообщение об ошибке срабатывания, если установлена) Trigger Error применима для типов клиентов, которые могут посылать уведомления об ошибках для сигнальных сообщений. Значения поля флаги не применимые для данного контекста R-типа или типа клиента должны игнорироваться PEP. C-тип = 2, Stateless Data Этот тип объекта решения несет в себе дополнительную информацию (stateless), которая может быть использована PEP локально. Этот объект имеет переменную длину и его внутренний формат должен специфицироваться для данного типа клиента в соответствующем расширительном документе COPS. Этот объект для сообщений-решений является опционным и интерпретируется согласно текущему контексту. Ожидается, что даже посторонние PEP могут принимать некоторые простые политические решения в рамках их LPDP Так как этот набор хорошо известен и используется повсеместно, PDP обслуживает и его (обычным образом, через конфигурацию, или используя сообщение Client-Open). PDP может также включать эту информацию в свои решения, а PEP должен использовать ее в случае запросов выделения ресурсов. C-тип = 3, Данные замещения Этот тип объекта решения несет в себе информацию замещения, которая призвана заменить существующие данные в указанном сообщении. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе-расширении COPS. Он является опционным в сообщениях решениях и интерпретируется согласно текущему контексту. C-тип = 4, Данные решения, специфические для клиента Дополнительные типы решений могут быть введены с помощью информационного объекта специфического решения клиента (Client Specific Decision Data Object). Он имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе расширения COPS. Он является опционным в сообщениях-решениях и интерпретируется в соответствии с данным контекстом. C-тип = 5, именованные данные решения Информация об именованной конфигурации инкапсулируется в поле версии объекта решения, это делается в ответ на запрос конфигурации. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован в соответствующих документах расширения COPS для данного типа клиента. Для сообщений решения этот объект является опционным и интерпретируется в зависимости от контекста и флагов решения. 2.2.7. Объект LPDP-решение (LPDPDecision) Решение принятое LPDP PEP (Local Policy Decision Point) может присутствовать в запросах. Эти объекты имеют формат, идентичный формату объектов специфических решений клиента, описанному выше. C-Num = 7 C-тип = (тот же C-Type что и для объектов решения) 2.2.8. Объект Error Этот объект используется для идентификации конкретных протокольных ошибок COPS. Поле субкода ошибки содержит дополнительную спецификацию ошибки, характерную для данного клиента. Субкоды ошибки для конкретного типа клиента должны специфицироваться в соответствующем документе расширения. C-Num = 8, C-тип = 1
2.2.9. Объект специфической информации клиента (ClientSI) Для запросов необходимы различные типы этого объекта, он используется в откликах и, когда необходимо, в процедурах open. Объект содержит специфическую информацию для клиента данного типа. C-Num = 9, Поле переменной длины. Все объекты/атрибуты, специфичные для сигнального протокола клиента или внутреннего состояния, инкапсулируются в один или более информационных объектов, специфических для клиента. Формат данных, инкапсулированных в объект ClientSI, определяется типом клиента. C-Type = 2, Именованный ClientSI. Поле переменной длины. Содержит именованную конфигурационную информацию, полезную для передачи специфических данных о PEP, запросе, или сконфигурированном состоянии серверу PDP. 2.2.10. Объект Keep-Alive-таймер (KATimer) Значение времени кодируются в виде 2-октетных целых чисел и измеряются в секундах. Время выдержки таймера рассматривается как приращение. C-Num = 10, Объект таймер используется для спецификации максимального временного интервала, в течение которого сообщение COPS должно быть послано или получено. Диапазон значений таймаутов лежит в пределах 1 - 65535 секунд. Значение нуль соответствует бесконечности.
2.2.11. Объект идентификации PEP (PEPID) Объект идентификации PEP используется, для того чтобы идентифицировать PEP-клиента удаленному PDP. Это необходимо для сообщений Client-Open. C-Num = 11, C-Type = 1 Поле переменной длины. Это ASCII-строка, завершающаяся нулем, которая дополняется нулями до границы, кратной 32 бит. Идентификатор PEPID должен содержать ASCII-строку, однозначно идентифицирующую PEP в пределах политической области PEP. Например, он может быть статически приписанным IP-адресом PEP или DNS-именем. Этот идентификатор может использоваться PDP в качестве дескриптора для идентификации PEP в его политических правилах. 2.2.12. Объект тип отчета (Report-Type) Тип отчета, соответствующий запросу состояния для данного дескриптора: C-Num = 12, C-Type = 1
Report-Type: 1 = Success : Решение было успешным для PEP 2.2.13. Адрес пересылки PDP (PDPRedirAddr) PDP при закрытии PEP-сессии для конкретного типа клиента может опционно использовать этот объект для того чтобы переадресовать PEP на специфицированный адрес сервера и заданный порт TCP: C-Num = 13,
C-Type = 2, IPv6-адрес + TCP порт
2.2.14. Последний адрес PDP (LastPDPAddr) Когда PEP имеет определенный тип клиента, он должен специфицировать последний PDP, который он успешно открыл (им получено сообщение Client-Accept) со времени, когда PEP последний раз перезагружался. Если со времени последней загрузки не использовалось никакого PDP, PEP просто не включит этот объект в сообщение Client-Open. C-Num = 14, 2.2.15. Объект Accounting-таймер (AcctTimer) Время кодируется в виде двухоктетых целых чисел и измеряется в секундах. Значение таймера рассматривается как временной интервал между двумя событиями. C-Num = 15, Значение опционного таймера используется для определения минимального интервала между периодическими отчетами о типах аккоунтинга. Оно используется PDP для того чтобы охарактеризовать PEP приемлемое значение интервала между не запрошенными аккоунтинг-актуализациями через сообщения-отчеты, когда это применимо. Он обеспечивает для PDP метод управления объемом аккоунтинг-трафика в сети. Диапазон конечных значений времени лежит в пределах 1 - 65535 секунд (два октета). Значение нуль означает, что не должно быть не запрошенных аккоунтинг-актуализаций.
2.2.16. Объект целостность сообщения (Message Integrity) Объект целостности (integrity) включает в себя порядковый номер и дайджест сообщения, полезный для аутентификации и проверки целостности сообщения COPS. Когда используется этот объект, он размещается в самом конце сообщения COPS. Дайджест вычисляется для всего сообщения COPS за исключением самого дайджеста. Отправитель сообщения COPS вычисляет и заполняет дайджест-секцию объекта Integrity. Получатель сообщения вычисляет дайджест для этого сообщения и сравнивает его с тем, что хранится в объекте Integrity. C-Num = 16, Объект HMAC-целостности для вычисления дайджеста сообщения привлекает HMAC (ключевое хэширование для аутентификации сообщения) [HMAC], при этом используется ключ, общий для PEP и PDP. Объект Integrity специфицирует 32-битовый ID ключа, который определяет специфический ключ, используемый конкретным PEP и его PDP, а также используемый криптографический алгоритм. Для заданного PEPID ID ключа допускает существование одновременно нескольких ключей для PEP и оответствующих ключей PDP. Ключ, идентифицированный ID ключа, используется для вычисления дайджеста сообщения в объекте Integrity. Все программные реализации, как минимум должны поддерживать HMAC-MD5-96, который реализует алгоритм MD5 [MD5] вычисляющий дайджест сообщения длиной 96-бит. Этот объект включает в себя также порядковый номер, который представляет собой 32-битовое целое число без знака, которое служит для предотвращения атак откликов. Порядковый номер инициируется на фазе обмена сообщениями Client-Open, Client-Accept и инкрементируется каждый раз при посылке очередного сообщения тому же получателю через существующее TCP-соединение. Если порядковый номер достигает значения 0xFFFFFFFF, следующим номер будет равен нулю и процесс продолжится. Дайджест сообщения COPS вычисляется для области, начиная с заголовка, и вплоть до объекта Integrity (который должен быть последним объектом в сообщении COPS). В эту область попадают заголовок объекта Integrity, ID ключа и порядковый номер (Sequence Number). В случае HMAC-MD5-96, HMAC-MD5 выдает 128-битовый дайджест, который далее укорачивается до 96 бит.
2.3. Коммуникация Протокол COPS использует одно устойчивое TCP соединение между PEP и удаленным PDP. Реализация PDP на сервере должна прослушивать стандартный номер TCP-порта (COPS=3288 [IANA]). PEP ответственен за инициативу TCP-соединения с PDP. Положение удаленного PDP может быть сконфигурировано или получено с помощью механизма локации услуг [SRVLOC]. Если один PEP может поддерживать несколько типов клиентов, он может посылать соответствующее число сообщений Client-Open, адресованных PDP, через одно или более TCP-соединений. Аналогично, PDP с заданным адресом и номером порта может поддерживать один или более типов клиента. Для заданного набора поддерживаемых типов клиентов PDP может в каждом конкретном случае независимо воспринять или отвергнуть любой тип клиента. Если тип клиента отвергнут, PDP может перенаправить PEP на альтернативный PDP-адрес и TCP-порт для данного типа клиента через COPS. Различные TCP-порты могут использоваться для перенаправления PEP на другие программные реализации PDP, работающие на том же сервере. Один PEP может сформировать соединения с несколькими PDP. Это может происходить, когда физически различные PDP поддерживают разные типы клиентов (как это показано на рис.).
Рис. .2. Пример с несколькими PDP. Когда TCP-соединение разорвано, PDP ожидает, что необработанное состояние запроса, соответствующее обмену запрос/решение, будет удалено. Когда PEP регистрирует потерю соединения из-за таймаута, он должен послать сообщение Client-Close каждому открытому типу клиенту, содержащему объект <Error>, который указывает на код ошибки "Communication Failure". Кроме того, PEP должен постоянно пытаться контактировать с первичным PDP или, если не удается, с любым известным запасным PDP. В частности PEP должен проверить все доступные PDP, с которыми он был сконфигурирован до того, как он сможет установить соединение. Если PEP соединен с запасным PDP, а первичный PDP становится доступным, запасной PDP является ответственным за переадресацию PEP на первичный PDP (через сообщение <Client-Close>, содержащее объект <PDPRedirAddr>, идентифицирующий первичный PDP для каждого из типов клиента). В разделе 2.5 рассмотрены детали синхронизации PEP и PDP. 2.4. Использование дескриптора клиента (Client Handle) Дескриптор клиента служит для идентификации уникального состояния запроса для каждого из типов клиента для одного PEP. Дескрипторы клиента выбираются PEP и являются недоступными для PDP. PDP просто использует дескриптор запроса, чтобы однозначно идентифицировать состояние запроса для конкретного типа клиента, для конкретного TCP-соединения, и тем самым связать его решения с соответствующим запросом. Дескрипторы клиента инициализируются в сообщениях запроса и используются в последующих сообщениях запроса, решения и отчета для ссылки на то же состояние запроса. Когда PEP готов удалить состояние локального запроса, он посылает сообщение удаления (delete) PDP для соответствующего дескриптора клиента. Дескрипторы, относящиеся к различным состояниям запроса, должны быть уникальны в рамках контекста конкретного TCP-соединения и типа клиента. 2.5. Синхронизация При отсоединении от PDP, PEP должен перейти к принятию локальных решений. При восстановлении соединения PEP информирует PDP обо всех событиях, которые произошли под локальным управлением. Кроме того, удаленный PDP может потребовать, чтобы внутренние состояния всех PEP были заново синхронизованы (все ранее поступившие запросы были заново посланы) путем передачи сообщения синхронизации состояний (Synchronize State). После неудачи и до полного установления нового соединения, ухудшение сервиса может быть минимизировано, если PEP кэширует переданные ранее решения и продолжает использовать их в течение некоторого времени. PEP, который кэширует состояние предыдущего обмена PDP, должен сообщить о факте разрыва соединения любому PDP, с которым он может восстановить соединение. Это выполняется путем включения адреса и номера TCP-порта последнего PDP, для которого PEP кэширует состояние в сообщении Client-Open. Объект <LastPDPAddr> будет включен для последнего PDP, с которым PEP был полностью синхронизован. Если прерывание обслуживания было временным и PDP все еще содержит полное состояние для PEP, PDP может выбрать вариант, когда не все состояния синхронизованы. PEP ответственен за актуализацию всех состояний PDP, которые изменились за время прерывания обслуживания. Если PEP выходит из строя и теряет все кэшированные состояния для некоторого типа клиента, он просто не включает <LastPDPAddr> в свое сообщение Client-Open. 3. Содержимое сообщения Объект Integrity, если он включен, должен всегда быть последним объектом сообщения. Если необходимо обеспечить безопасность, а полученное сообщение не содержит корректного объекта Integrity, получатель должен послать сообщение Client-Close для Client-Type=0, определяющее соответствующий код ошибки. 3.1. Запрос (REQ) PEP -> PDP PEP устанавливает дескриптор состояния запроса клиента, для которого PDP может обеспечить нужное состояние. Удаленный PDP затем использует дескриптор, для ссылки на информацию и решения, переданные по TCP-каналу конкретному PEP для данного типа клиента. Раз для нового запроса определен дескриптор, любые последующие модификации запроса могут производиться с помощью сообщения REQ, специфицирующего инсталлированный дескриптор. PEP ответственен за уведомление PDP всякий раз, когда изменения его локального состояния отслеживает состояния PEP. Формат сообщения-запроса имеет вид: <Request Message> ::= <Common Header> Объект context используется для определения контекста, в рамках которого следует интерпретировать все другие объекты. Он также служит для определения вида решения, которое должен послать сервер, определяющий политику. Это решение может относиться к управлению доступом, размещению ресурсов, переадресации или замене объектов, а также в конфигурации. Объекты interface используются, чтобы определить соответствующий интерфейс, через который было получено или предполагается послать протокольное сообщение. Они обычно используются, если клиент запрашивает конфигурационные данные для какого-то конкретного интерфейса. ClientSI является информационным объектом клиента и содержит в себе специфическую информацию, для которой должно быть принято политическое решение. В случае конфигурации именованное ClientSI может включать в себя именованные данные о модуле, интерфейсе или функции, которые следует конфигурировать. Порядок следования для кратных ClientSI не существенен. Наконец, объект LPDPDecision содержит информацию согласно локальному решению, принятому LPDP. Сообщения Request с неверным форматом должны вызывать сообщения Decision PDP с соответствующим кодом ошибки. 3.2. Решение (DEC) PDP -> PEP PDP реагирует посредством REQ с сообщением DEC, которое включает в себя ассоциированный дескриптор клиента и один или более объектов решения, сгруппированные относительно пар типов объектов Context и флагов решения (Decision Flags). Если имела место протокольная ошибка, вместо этого присылается объект ошибки. Требуется, чтобы первое сообщение решения для нового или актуализованного запроса имело флаг требования в заголовке COPS равный 1. Это исключает отслеживание того, какому модифицированному запросу соответствует конкретное решение (т.е., запрос посылается повторно для того же самого дескриптора). Важно, чтобы для данного дескриптора существовало одно предпочтительное решение, соответствующее определенному запросу. Это по существу означает, что PEP не должен посылать более одного REQ (для данного дескриптора), прежде чем он получит соответствующий DEC с заданным набором флагов сообщения. PDP должен всегда посылать решения для запросов в порядке их получения и каждому запросу должно соответствовать решение. Чтобы избежать тупиков, PEP может делать выдержку после посылки запроса, пока не будет получено решение. Он должен аннулировать дескриптор, для которого время выдержки истекло, а решение не получено, новая попытка может быть осуществлена с новым дескриптором. Формат сообщения Decision представлен ниже: <Decision Message> ::= <Common Header> Сообщение Decision может включать либо объект Error, либо один или более объекта context и соответствующего объекта decision. О проблемах протокола COPS сообщается в объекте Error. Объект Decision зависит от контекста и типа клиента. 3.3. Состояние отчета (RPT) PEP -> PDP Сообщение RPT используется PEP, чтобы сообщить PDP об успехе или неудаче реализации решения PDP, или уведомить об изменении состояния. Report-Type специфицирует вид отчета и опционный ClientSI и может содержать дополнительную информацию для типа клиента. Для каждого сообщения DEC, содержащего контекст конфигурации, которое получено PEP, он должен сформировать соответствующее сообщение-отчет о состоянии с флагом запрошенного сообщения (Solicited Message flag), который указывает на то успешно или нет реализовано конфигурационное решение. RPT-сообщения, запрошенные решением для данного дескриптора клиента, должны устанавливать флаг запрошенного сообщения и должны быть посланы в том же порядке, к каком получены соответствующие сообщения решения. Не должно быть более одного сообщения отчета о состоянии, соответствующему флагу-требованию, установленному для заданного решения. Состояние отчета может также использоваться для реализации периодических модификаций специфической информации клиента для целей мониторирования состояния, зависящего от типа клиента. В таких случаях тип аккоунтинг-отчета должен специфицироваться с помощью соответствующего информационного объекта клиента. <Report State> ::== <Common Header> 3.4. Состояние аннулирования запроса DRQ (Delete Request State) PEP -> PDP При посылке это сообщение PEP указывает, что удаленный PDP, чье состояние идентифицируется дескриптором клиента, более недоступно или неверно. Эта информация будет затем использоваться удаленным PDP для инициации соответствующих служебных операций. Объект кода причины интерпретируется с учетом типа клиента и определяет причину аннулирования. Формат сообщения Delete Request State представлен ниже: <Delete Request> ::= <Common Header> Важно, что когда состояние запроса окончательно удаляется из PEP, сообщение DRQ для состояния запроса посылается PDP, так что соответствующее состояние может быть также удалено в PDP. Состояния запроса, не удаленные явно PEP, будут поддерживаться PDP, пока не будет закрыта сессия или пока не будет разорвано соединение. Сообщения Decision с неверным форматом должны запустить DRQ, специфицирующее соответствующий код ошибки (Bad Message Format) и любое ассоциированное состояние PEP должно быть либо удалено, либо повторно запрошено. Если Decision содержится в неизвестном объекте COPS Decision, PEP должен аннулировать его запрос, специфицирующий код причины объекта COPS Unknown, так как PEP будет неспособен работать с информацией, содержащейся в неизвестном объекте. В любом случае, после отправки DRQ, PEP может попытаться послать соответствующий запрос повторно. 3.5. Запрос состояния синхронизации (SSQ) PDP -> PEP Сообщение запроса состояния синхронизации имеет следующий формат: <Synchronize State> ::= <Common Header> Это сообщение указывает, что удаленный PDP хочет, чтобы клиент повторно прислал свое состояние. Если имеется опционный дескриптор клиента, только состояние, ассоциированное с этим дескриптором, синхронизуется. Если PEP не распознает запрошенный дескриптор, он должен немедленно послать сообщение DRQ PDP для дескриптора, специфицированного в SSQ-сообщении. Если в SSQ-сообщении не специфицировано никакого дескриптора, все активные состояния клиента должны быть синхронизованы с PDP. Клиент выполняет синхронизацию состояний путем повторной посылки запросов специфицированного типа клиента для существующего состояния PEP. Когда синхронизация завершена, PEP должен направить завершающее сообщение синхронизованного состояния в PDP. 3.6. Client-Open (OPN) PEP -> PDP Сообщение Client-Open может использоваться PEP, для того чтобы специфицировать PDP типы клиента, которые PEP может поддерживать, и последний PDP, с которым PEP устанавливал соединение при данном типе клиента. Сообщение Client-Open может быть послано PDP в любое время, допускаются множественные сообщения Client-Open для одного и того же типа клиента (в случае общих изменений состояния). <Client-Open> ::= <Common Header> PEPID является символическим именем с переменной длиной, которое однозначно идентифицирует клиента для PDP (смотри раздел 2.2.11). Именованный объект ClientSI может быть включен для передачи дополнительной глобальной информации о PEP к PDP, когда необходимо (как это специфицировано в соответствующем расширении документа для заданного типа клиента). PEP может также предоставить объект Last PDP Address в его сообщении Client-Open, специфицирующий последний PDP (для заданного типа клиента), для которого он кэширует решения с момента последней перезагрузки (reboot). PDP может использовать эту информацию, чтобы определить подходящий режим синхронизации (смотри раздел 2.5). Если PDP получает сообщение Client-Open с неверным форматом, он должен сформировать сообщение Client-Close, специфицирующее соответствующий код ошибки. 3.7. Client-Accept (CAT) PDP -> PEP Сообщение Client-Accept используется для позитивного отклика на сообщение Client-Open. Это сообщение пришлет PEP объект таймера, заключающий в себе максимальный временной интервал между сообщениями keep-alive. Опционно, если нужно, может быть добавлен таймер, специфицирующий минимально допустимый интервал между аккоунтинг-сообщениями-отчетами. <Client-Accept> ::= <Common Header> Если PDP отказывает клиенту, он пошлет сообщение Client-Close. Таймер KA соответствует максимальному приемлемому времени между сообщениями, посылаемыми от PDP к PEP. Время выдержки таймера определяется PDP и измеряется в секундах. Значение времени выдержки 0 означает, что не требуется верификации вторичного соединения. Опционный таймер ACCT позволяет PDP проинформировать PEP о том, что периодические аккоунтинг-отчеты не должны превышать специфицированный временной интервал для каждого дескриптора клиента. Это позволяет PDP контролировать частоту, с которой PEP посылает аккоунтинг-отчеты. Вообще, сообщения Report типа аккоунтинг посылаются PDP, когда определен соответствующий PEP. Аккоунтинг-таймер по большей части используется PDP, чтобы поддерживать частоту актуализаций на приемлемом уровне (т.e. предотвращать перегрузку PEP под действием аккоунтинг-отчетов от PDP). Не включение этого объекта в сообщение означает, что не существует для PDP каких-либо ограничений на частоту аккоунтинг-актуализации. Если PEP получает сообщение Client-Accept с неверным форматом, он должен сгенерировать сообщение Client-Close, где специфицирован соответствующий код ошибки. 3.8. Client-Close (CC) PEP -> PDP, PDP -> PEP Сообщение Client-Close может быть послано как PDP, так и PEP с тем, чтобы обратить внимание противоположной стороны на то, что указанный тип клиента более не поддерживается. <Client-Close> ::= <Common Header> Объект Error включен, чтобы описать причину закрытия (например, запрошенный тип клиента не поддерживается удаленным PDP или отказ в работе клиента). PDP может опционно включать PDP-объект адреса перенаправления, для того чтобы проинформировать PEP об альтернативном PDP, который он должен использовать для типа клиента, специфицированного в общем заголовке. 3.9. Keep-Alive (KA) PEP -> PDP, PDP -> PEP Сообщение keep-alive должно передаваться PEP в пределах периода, определенного минимальным значением выдержки KA-таймера, которая определяется в сообщениях CAT для данного соединения. Сообщение KA должно генерироваться случайным образом в пределах между 1/4 и 3/4 этого минимального интервала KA-таймера. Когда PDP получает сообщение keep-alive от PEP, он должен откликнуться таким же сообщением, адресованным PEP. Это сообщение обеспечивает подтверждение для каждой из сторон того, что соединение функционирует даже в случае, когда нет никаких других сообщений. Тип клиента в заголовке должен всегда быть установлен равным 0, так как KA используется для верификации соединения (а не для верификации сессии клиента). <Keep-Alive> ::= <Common Header> Как клиент, так и сервер могут предполагать, что TCP-соединение недостаточно для типа клиента с минимальным значением времени (специфицировано в сообщении CAT), если не зарегистрировано никакой телекоммуникационной активности в течение периода времени, превосходящего выдержку таймера. При этом PEP предполагает, что удаленный PDP или соединение не работает и PEP должен пытаться использовать альтернативный/запасной PDP. 3.10. Завершение состояния синхронизации (SSC) PEP -> PDP Сообщение завершения состояния синхронизации (Synchronize State Complete) посылается от PEP к PDP, после того как PDP пошлет запрос синхронизации состояния PEP и PEP завершит синхронизацию. Полезно, чтобы PDP знал, когда все старые состояния клиента успешно повторно запрошены и, таким образом, PEP и PDP полностью синхронизованы. Объект дескриптора клиента (Client Handle) следует включать только тогда, когда соответствующее сообщение синхронизации состояний (Synchronize State Message) непосредственно ссылается на определенный дескриптор (handle). <Synchronize State Complete> ::= <Common Header>
4. Общие операции
Безопасность сообщения COPS согласуется один раз на соединение и работает для всего последующего обмена через это соединение. Если требуется определенный уровень безопасности COPS, он должен быть согласован во время начального обмена сообщениями Client-Open/Client-Accept, специфицирующего тип клиента равный нулю (который зарезервирован для согласования уровня соединения и верификации соединения). Если PEP не конфигурировался для использования средств безопасности COPS, он просто пошлет PDP сообщения Client-Open для поддерживаемых типов клиента, как это задано в разделе 4.3 и не будет включать объект Integrity в какие-либо сообщения COPS. В противном случае, средства безопасности могут быть инициализированы PEP, если он посылает PDP сообщение Client-Open с Client-Type=0 до открытия любого другого типа клиента (Client-Type). Если PDP получает Client-Open с Client-Type=0, после того как другой тип клиента уже успешно открыт, он должен прислать сообщение Client-Close (для Client-Type=0) к PEP. Это первое сообщение Client-Open должно специфицировать Client-Type=0 и должно предоставить объекты PEPID и COPS Integrity. Этот объект Integrity будет содержать начальный порядковый номер, который PDP должен инкрементировать в дальнейшем, после исходного обмена Client-Open/Client-Accept и Key ID, идентифицирующего алгоритм и ключ, которые используются для вычисления дайджеста. Аналогично, если PDP принимает ключ безопасности PEP и алгоритм путем проверки дайджеста сообщения с использованием идентифицированного ключа, PDP должен послать PEP сообщение Client-Accept с Client-Type =0, содержащего объект Integrity. Этот объект Integrity будет включать исходный порядковый номер, идентификатор ключа (Key ID), задающий ключ и алгоритм, использованные для вычисления дайджеста. Если PEP, от перспективного PDP, который требует безопасности, потерпит неудачу или вообще не выполнит согласование требований безопасности, не послав исходное сообщение Client-Open с Client-Type=0, содержащее корректный объект Integrity, PDP должен послать PEP сообщение Client-Close с Client-Type=0, специфицирующее соответствующий код ошибки. Аналогично, если PDP, в процессе диалога с PEP, который требует безопасности, не выполнил согласования параметров, не послав сообщение Client-Accept со значением Client-Type=0 и корректным объектом Integrity, PEP должен послать PDP сообщение Client-Close со значением Client-Type=0, специфицируя соответствующий код ошибки. Такое сообщение Client-Close не должно нести в себе объект integrity (так как согласование безопасности еще не завершено). Инициализация безопасности может потерпеть неудачу по одной из следующих причин:
Раз начальное согласование уровня безопасности завершено, PEP знает, какие порядковые номера ожидает PDP, а PDP знает, какие порядковые номера ожидает PEP. Все сообщения COPS должны включать согласованный объект Integrity, специфицирующий корректный порядковый номер с соответствующий дайджест сообщения (включая сообщения Client-Open/Client-Accept для специфических типов клиента). Все последующие сообщения от PDP к PEP должны вызывать инкрементацию порядкового номера, осуществляемую PEP в объекте Integrity исходного сообщения Client-Open. Аналогично, все последующие сообщения от PEP к PDP должны вызывать инкрементацию порядкового номера, осуществляемую PDP в объекте Integrity исходного сообщения Client-Accept. Порядковые номера увеличиваются на 1, начиная с исходного значения. Например, если порядковый номер задан для PEP в исходном сообщении Client-Accept равным 10, следующее сообщение PEP посылаемое к PDP, предоставит объект Integrity с порядковым номером 11. Следующее сообщение, которое посылает PEP в направлении PDP, будет иметь порядковый номер 12 и т.д. Если любое последующее сообщение содержит неверный порядковый номер, неопределенный Key ID, некорректный дайджест сообщения, или не имеет объекта Integrity при условии, что параметры безопасности согласованы, то для Client-Type=0 должно быть сгенерировано сообщение Client-Close, содержащее корректный объект Integrity, где специфицируется соответствующий код ошибки. После этого соединение должно быть разорвано. 4.2. Работа с ключами Процедура работы с ключами находится за пределами данного документа, но реализации COPS должны, по крайней мере, предоставить возможность ручной конфигурации ключей и задания их параметров. Ключ, используемый для формирования дайджеста сообщения с объектом Integrity, идентифицируется с помощью поля Key ID. Таким образом, параметр Key ID используется для идентификации одного из множества ключей, используемых совместно PEP и PDP. Key ID имеет отношение к определенному PEPID для PDP, или к определенному PDP для PEP. Для каждого ключа должны быть также определены параметры времени действия и параметры, задающие криптографический алгоритм. Как минимум, все реализации COPS должны поддерживать криптографический алгоритм HMAC-MD5-96 [HMAC][MD5] для вычисления дайджеста сообщения, который включается в объект Integrity (Keyed Message Digest), присоединяемый к сообщению. Регулярное изменение ключей является хорошей практикой. Ключи должны быть конфигурируемы так, чтобы их время действия перекрывались, обеспечивая плавный переход с одного набора на другой. В середине периода действия ключа отправитель должен запустить процедуру перехода на следующий ключ. Тем временем, получатели просто воспринимают любой идентифицированный ключ, полученный в пределах его периода существования (lifetime) и отклоняют любые другие ключи. 4.3. Инициализация PEP Спустя некоторое время после установления соединения между PEP и удаленным PDP, после согласования условий обеспечения безопасности (если это требуется), PEP пошлет удаленному PDP одно или более сообщение Client-Open, по одному для каждого поддерживаемого PEP типов клиента. Сообщение Client-Open должно содержать адрес последнего PDP, с которым PEP хранит полный набор решений. Если не поступило ни одного решения от предыдущего PDP, объект LastPDPAddr не должен быть включен в сообщение Client-Open (смотри раздел 2.5). Каждое сообщение Client-Open должно, по крайней мере, содержать общий заголовок, указывающий на один тип клиента, который поддерживает PEP. Удаленный PDP откликнется сообщениями Client-Accept для каждого типа клиента, запрошенного PEP и поддерживаемого PDP. Если какой-то конкретный тип клиента не поддерживается PDP, PDP будет реагировать с помощью Client-Close, специфицируя неподдерживаемый тип клиента, и возможно предлагая альтернативный PDP-адрес и номер порта. В противном случае, PDP пошлет Client-Accept, специфицируя временную выдержку между сообщениями keep-alive, а PEP может начать посылку запросов PDP. 4.4. Нестандартные операции Когда PEP сталкивается с ситуацией, которая требует нового политического решения, он посылает удаленному PDP сообщение-запрос. То, что квалифицируется как случай определенного типа клиента, должно быть специфицировано в соответствующем документе, посвященном этому client-type. Удаленный PDP принимает решение и посылает сообщение-решение PEP. Так как запрос определяет состояние, запрос будет запомнен или инсталлирован на удаленном PDP. Уникальный дескриптор (уникальный для TCP-соединения и типа клиента), специфицированный в запросе и соответствующем ему решении идентифицирует состояние запроса. PEP отвечает за удаление этого состояния запроса, если запрос уже более не применим. PEP может актуализовать ранее инсталлированное состояние запроса путем повторной посылки запроса для соответствующего дескриптора. Удаленный PDP примет новые решения и пошлет сообщения-решения к PEP. Аналогично, сервер может изменить принятое ранее решение на любое инсталлированное состояние запроса в любое время путем посылки не запрошенного сообщения-решения. В любое время модуль PEP ожидает решения PDP и уведомляет PDP о любых изменениях. 4.5. Операции конфигурирования В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении. В любом случае, PEP может уведомить удаленный PDP о локальном статусе инсталлированного состояния, используя сообщение-отклик. Это сообщение, если нужно, может содержать специфическую информацию клиента. 4.6. Операции Keep-Alive Сообщение Keep-Alive используется для проверки соединения между клиентом и сервером, чтобы проверить функциональность соединения даже в отсутствие обмена сообщениями между PEP и PDP. PEP должен формировать COPS KA-сообщение случайным образом в диапазоне от одной четвертой до 3/4 минимальной величины выдержки KA таймера, заданной PDP в сообщении Client-Accept. При получении сообщения Keep-Alive от PEP, PDP должен реагировать на это сообщение Keep-Alive посылкой отклика Keep-Alive к PEP. Если любая из сторон не получит сообщение Keep-Alive или любого другого сообщения COPS за время выдержки KA-таймера, соединение должно считаться разорванным. 4.7. Закрытие PEP/PDP Наконец, сообщения Client-Close используются для аннулирования влияния соответствующих сообщений Client-Open, оповещающих партнера о том, что специфицированный тип клиента не поддерживается или не является активным. Когда PEP регистрирует потерю связи, связанную с таймаутом keep-alive он должен послать сообщение Client-Close для каждого открытого типа клиента, специфицирующего код ошибки разрыва соединения. Затем PEP может разорвать соединение с PDP, попытаться восстановить связь или использовать альтернативный PDP. Когда PDP завершает работу, он должен послать сообщения Client-Close всем PEP для всех типов клиента, при этом может специфицироваться альтернативный PDP, который может заменить прежний. 5. Соображения безопасности Протокол COPS предоставляет объект Integrity, который может обеспечить аутентификацию, целостность сообщения, и предотвратить подмену с использованием записи предыдущих сообщений. Все реализации COPS должны поддерживать работу с объектом COPS Integrity. Чтобы гарантировать, что клиент (PEP) обменивается с корректным сервером политики (PDP), необходима аутентификация PEP и PDP, с использованием общего ключа (secret), и согласованная проверка того, что соединение является корректным. Ключ используется в сочетании с содержимым сообщения COPS, чтобы вычислить дайджест сообщения, который является частью объекта Integrity. Объект Integrity затем используется для проверки всех сообщений COPS, посланных через TCP-соединение между PEP и PDP. Объект COPS Integrity предоставляет также порядковый номер, чтобы исключить атаки откликов. PDP выбирает начальный порядковый номер для PEP, а PEP выбирает начальный порядковый номер для PDP. Эти начальные номера затем инкрементируются каждым последующим сообщением, пересланным через данное соединение в соответствующем направлении. Исходный порядковый номер должен быть выбран так, чтобы для заданного ключа в процессе монотонного приращения не получалось идентичных номеров. Безопасность обмена между клиентом (PEP) и сервером (PDP) может быть обеспечена за счет IP Security [IPSEC]. В этом случае, заголовок аутентификации IPSEC (AH) должен использоваться для проверки правильности соединения; кроме того, безопасное поле данных IPSEC ESP (Encapsulation Security Payload) может использоваться для реализации, как безопасности, так и конфиденциальности. TLS [Transport Layer Security] может использоваться, как для обеспечения соединения, так и для гарантии конфиденциальности. Тип клиента идентифицирует Client-type приложения, к которому относится сообщение. Значения типа клиента в диапазоне 0x0001-0x3FFF зарезервированы для статуса необходимой спецификации (Specification Required), как это определено [IANA-CONSIDERATIONS]. Эти значения должны быть зарегистрированы IANA и их поведение и применимость должны быть описана в документе расширения COPS. Значения типа клиента (Client-type) в диапазоне 0x4000 - 0x7FFF зарезервированы для частного использования, как это определено в [IANA-CONSIDERATIONS]. Значения типа клиента в диапазоне 0x8000 - 0xFFFF относятся к типу "первым пришел - первым обслужен", как это определено в [IANA-CONSIDERATIONS]. 6. Ссылки
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.9.6 Протокол резервирования ресурсов RSVP
UP:
4.4 Интернет
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
4.4.14.5 Программа Sendmail
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Одной из досадных особенностей программы Sendmail является огромное количество опций. К счастью большинство из них обычно не используются. Иной раз может показаться, что назначение некоторых опций знает только их автор. Часть этих опций служит для тестирования конфигурационного файла и файла псевдонимов. Такие опции как -bt и -bv используются при изменении конфигурационного файла, чтобы гарантировать, что новые наборы правил работают безошибочно. Наиболее важные опции служат администратору для установления отладочного уровня (-d#), или для установки программы в фоновый режим или режим демона (-bd), или для установки самого отладочного режима (-v). Почтовая программа sendmail должна запускаться в фоновом режиме с помощью строки в стартовом скрипте. Например: /usr/lib/sendmail -bd -q30m Эта командная строка предлагает обрабатывать занесенные в очередь сообщения каждые 30 минут. Время после опции -q может быть задана как произвольная комбинация дней, часов, минут и секунд. В этом случае за числами должны следовать соответственно символы d, h, m или s. Так, например, запись: -q1d2h30m15s указывает, что очередь будет обрабатываться с периодичностью 1 день, 2 часа, 30 минут и 15 секунд. Конфигурационный файл sendmail является читаемым текстовым. Этот файл начинается с перечня опций и макросов, далее следует набор правил. Эти правила определяют метод дешифровки адресов почтовых сообщений. Обычно настройке подвергаются опции и макросы. Макросы начинаются с символа D, за которым следует одна буква, определяющая имя макро, и текст расширения. Буква-имя чувствительна к регистру в котором она напечатана. Макросы используются для определения имен (имя ЭВМ, имя домена и т.д.). Практически все опции, доступные при запуске программы sendmail, могут быть описаны и в конфигурационном файле (буквенные имена совпадают). Описание опции начинается с символа О. В остальном справедливы замечания, представленные в предыдущем абзаце о макро. Прежде чем изменять конфигурационный файл рекомендуется сделать его копию. Усовершенствования не всегда работают так, как ожидает их автор. Опция OL# определяет уровень работы журнала операций. Эта опция управляет объемом информации, которая записывается в log-файл при работе программы sendmail. Чем больше число, проставленное вместо символа #, тем больше информации будет записано. Наибольшему уровню соответствует цифра 9. Опция Om служит для расширения псевдонимов. Если пользователь посылает сообщение адресату, обозначенному псевдонимом, и имя отправителя присутствует в списке псевдонимов, действием по умолчанию будет блокировка посылки самому себе. Опция Om переписывает значение по умолчанию и отправитель также получит свое сообщение. Некоторые пользователи используют такую возможность для контроля того, что сообщение было действительно послано. Опции Or<время> и OT<время> являются опциями таймаута. Опция ОТ производит запись проблемного сообщения в очередь и осуществляет повторную попытку через специфицированный промежуток времени, прежде чем отправитель будет проинформирован о неудаче. Опция Or специфицирует значение таймаута для операций чтения. Если при получении почты от удаленной ЭВМ возникает пауза, в течение которой не приходит ничего, sendmail по истечение заданного времени прерывает процесс и закрывает соединение. Так как эта опция, вообще говоря, нарушает стандарт RFC-821, значение таймаута должно быть достаточно велико. Опция OW специфицирует пароль для операций процессора. По существу это лазейка для выполнения пользователем некоторых операций, которые непосредственно для почтовой программы не нужны. Эта опция используется программистами для выявления проблем в работе основной программы, реализующей почтовый протокол. Сразу после инсталляции следует поменять значение этого пароля (заменить значение, установленное по умолчанию). Удаление строки соответствующей данной опции, автоматически приведет к установлению пароля по умолчанию. Опция -о или Оо означает, что имена получателей могут разделяться пробелами (стандарт требует применения запятых). Опция OD служит, для того чтобы автоматически осуществлять актуализацию базы данных при изменении файла псевдонимов (alias). Привилегированные пользователи могут изменить имя поля From, которое используется при посылке сообщений об ошибках. Это имя может быть изменено с помощью команды -f<пользователь>. Файл alias обычно размещается в каталоге /usr/lib/aliases и служит для создания почтовых ящиков, которым не соответствует никакой аккоунт пользователя. В этом файле определяется, в какой почтовый ящик следует направлять сообщение, адресованное субъекту с указанным псевдонимом. Допускается направление сообщений вместо какого-либо почтового ящика на stdin. Стандартная строка переадресации в этом файле выглядит как. alias: имя_пользователя или Первая строка перенаправляет все сообщения, адресованные alias пользователю с указанным именем. Второй пример соответствует случаю, когда все сообщения, адресованные alias переадресовываются всем пользователям из предлагаемого списка. Этот список может быть продолжен на следующей строке, если пред CR ввести символ \. В качестве имен пользователей могут быть записаны полные почтовые адреса типа vanja.ivanov@somewhere.ru или локальное имя. Для особо длинных списков имен можно указать файл, где этот список содержится. Для этого в файл /usr/lib/aliases нужно занести стоку типа. Participants: ":include:/usr/local/lib/participants.list" Обычно желательно включать псевдоним "почтмейстера" и администратора. Когда пользователь на удаленной ЭВМ не может найти имя аккоунта или ЭВМ, он может послать запрос по одному из этих псевдонимов. Одной из наиболее эффективных (и опасных в то же самое время) особенностей файла alias является возможность перенаправлять приходящую почту программе, базирующейся на псевдониме. Когда первый символ имени аккоунта в псевдониме является вертикальной чертой (|), имя воспринимается как наименование программы, которой следует передать управление. Приходящее сообщение будет передано этой программе, как если бы этот текст был введен с консоли. В файле псевдонимов вертикальная черта работает также как в ядре UNIX. Таким образом, строка: listserv: "|/usr/local/bin/listserv -l" пошлет почтовый файл программе listserv, как если бы вы выполнили команду cat mailfile|listserv -l. В действительности так работают серверы подписных листов (LISTSERV). Администратор устанавливает псевдоним, а программа listserv транслирует строку поля Subject или тела сообщения в качестве команды, управляющей работой почтового сервера рассылки. Следует иметь в виду, что эта техника представляет достаточно серьезную угрозу безопасности. По этой причине ее использование должно быть обставлено соответствующими мерами (например, аутентификацией с использованием шифрованных паролей). |
|
Previous:
4.4.14.4 Многоцелевое расширение почты Интернет (MIME)
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.2 Finger
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Finger является простым протоколом (RFC-1288), который служит для получения информации о пользователях узлов Internet. Протокол использует TCP-порт 79. Команда Finger может дать вам данные о списке пользователей, которые работают в данный момент на интересующей вас ЭВМ, о конкретном пользователе (дата последнего сеанса входа в систему и т.д.), о списке загруженных задач, о типах интерфейсов (например, терминалов). Данный протокол обеспечивает интерфейс для удаленной информационной программы пользователя (RUIP - Remote User Information Program). Первоначальная версия такой программы была написана Les Earnest. Окончательная версия протокола была подготовлена Earl Killian из Мессачусетского Технологического Института и Brian Harvey (SAIL). Протокол Finger базируется на TCP. Локальная ЭВМ осуществляет TCP-соединение с удаленным узлом через указанный порт. После этого становится доступной программа RUIP и пользователь может посылать ей свои запросы. Каждый запрос представляет собой строку текста. RUIP, получив запрос, анализирует его и присылает ответ, после чего соединение закрывается. Любые пересылаемые данные должны иметь формат ASCII, не иметь контроля по четности и каждая строка должна завершаться последовательностью CRLF (ASCII 13, за которым следует ASCII 10). Программа RUIP должна воспринимать любые запросы Finger. Такие запросы могут иметь следующий формат: {Q1} ::= [{W}|{W}{S}{U}]{C} где {U} ::= имя_пользователя {H} ::= @hostname | @hostname{H} {H}, является рекурсивным, по этой причине не существует каких-либо ограничений на число лексем типа @hostname в запросе. В примере спецификации {Q2}, число лексем @hostname не может превышать двух. Следует иметь в виду, что в случае запросов "finger user@host Запрос {Q2} требует переадресации запроса другой программе RUIP. Программа RUIP может либо осуществить эту процедуру, либо отказать в переадресации. В случае выполнения запроса она должна это подтвердить: Сообщая, что: ЭВМ <H1> открывает соединение Finger <F1-2> с RUIP на ЭВМ <H2>. <H1> выдает <H2> RUIP запрос <Q1-2> типа {Q2} (например, FOO@HOST1@HOST2). При этом следует извлечь информацию о том, что: ЭВМ <H2> является самой правой ЭВМ в запросе <Q1-2> (например, HOST2) Запрос <Q2-3> является остатком запроса <Q1-2> после удаления правой части "@hostname" (например, FOO@HOST1) Таким образом: <H2> RUIP должна открыть соединение <F2-3> с <H3>, используя <Q2-3>. По большей части вывод RUIP не следует каким-либо жестким регламентациям, так как он предназначен для чтения людьми, а не программами. Главное требование - информативность может ограничиваться только соображениями безопасности. Запрос {C} требует выдачи списка всех работающих пользователей. RUIP должна либо ответить, либо активно отказаться. Если она отвечает, тогда она должна выдать, по крайней мере, полные имена пользователей. Системный администратор может включить в выдачу и другую полезную информацию, такую как:
Запрос {U}{C} является требованием присылки информации о статусе определенного пользователя {U}. Если вы не хотите выдавать такую информацию, тогда следует заблокировать работу Finger. Ответ должен включать в себя полное имя пользователя. Если пользователь активно работает в сети, то присылаемые данные должны включать, по крайней мере, тот же объем информации что и при запросе {C}. Так как это запрос информации об отдельном пользователе, администратор может добавить определенную информации об этом человеке, например:
Информационный файл пользователя может содержать короткое сообщение, которое оставляет пользователь для передачи по запросу Finger. (Это иногда называется "plan" файлом). Это легко реализуется путем поиска программой в корневом каталоге (или в специально выделенном каталоге) пользователя файла с заданным именем. Системному администратору должно быть разрешено включать и выключать эту опцию. При запросе Finger существует возможность запуска определенной программы пользователя. Если такая опция предусмотрена, системному администратору должно быть позволено запрещать эту процедуру. Данная опция, создавая определенные угрозы, практически беспредельно расширяет возможности Finger (см. примеры в конце раздела). В командной строке допустимо имя пользователя или имя, под которым он входит в систему. Если имя неопределенно, реакция системы определяется системным администратором. Лексема /W в запросе типа {Q1} или {Q2} в лучшем случае интерпретируется последней RUIP и означает требование выдачи максимально возможной информации о пользователе, в худшем случае она игнорируется. Продающие автоматы должны реагировать на запрос {C} выдачей списка всех предметов, предлагаемых для продажи в данный момент Продающие автоматы должны откликаться на запросы {U}{C}, сообщая число различных продуктов или отделений для размещения продуктов. Корректная реализация Finger крайне важна. В частности, RUIP должна защищать себя от некорректного ввода. Конкретная реализация программы должна проходить столь же тщательную проверку, как Telnet, FTP или SMTP. Следует учитывать, что Finger раскрывает информацию о пользователях. Лица, ответственные за сетевую безопасность, должны решить разрешать или нет работу Finger, и какую информацию о пользователях следует рассылать. Сетевой администратор должен иметь возможность разрешать и запрещать прохождение запросов {Q2}. Если обработка запросов {Q2} RUIP заблокировано, программа должна отсылать соответствующее сообщение (например, "Finger forwarding service denied"). По умолчанию обработка запросов {Q2} должна быть запрещена. Программа RUIP при отправке данных должна отфильтровывать все символы вне диапазона (ASCII 32 - ASCII 126), за исключением TAB (ASCII 9) и CRLF. Такая мера обезопасит получателя. Примеры реализации запросов. Узел: elbereth.rutgers.edu Командная строка: <CRLF> Login Name TTY Idle When Office Узел: dimacs.rutgers.edu Командная строка: hedrick@math.rutgers.edu@pilot.njin.net Формат применения команды Finger: finger [ опции ] имя... По умолчанию finger отображает информацию обо всех активно работающих пользователях, включая имя-идентификатор, полное имя, имя терминала и т.д. В качестве имени может использоваться имя-идентификатор, фамилия или имя пользователя. Ниже приводится краткий перечень допустимых опций.
Список работающих пользователей хранится в файле /etc/utmp, полный список имен пользователей размещен в файле /etc/passwd, времена и даты входа в систему записаны в файле /var/adm/lastlog, имена и расположение терминалов можно найти в файле /etc/ttytab, для записи информации о планах и проектах используются файлы ~/.plan и ~/.project, соответственно. Ниже приведен пример отклика на команду finger -l (запрос подробной информации, ЭВМ SUN):
On since Aug 10 10:16:35 on ttyp0 from x4u2.desy.de 1 minute 37 seconds Idle Time Mail last read Thu Aug 10 12:06:20 1995
Directory: /u1/SunITEP/semenov Shell: /bin/csh
Directory: /var/spool/uucppublic Shell: В общем случае при обращении к finger может использоваться символьный Интернет-адрес: Finger <имя_адресата>@Internet_адрес. Возможности команды Finger варьируются в широких пределах в зависимости от конкретной реализации. Так команда (PCTCP): finger semenov@vxdesy.desy.de выдаст на экран: [vxdesy.desy.de] Дополнительную информацию о команде finger можно получить:
Цифра после двоеточия - номер порта. Последняя строка говорит о некоторых необычных возможностях Finger. Опция выдачи содержимого файла пользователя и исполнения программы пользователя расширяет возможности Finger почти беспредельно. Так, выдав команду finger help@dir.su.oz.au (Австралия), получим: [extra.ucc.su.OZ.AU] Finger offers these additional services (Finger предлагает некоторые дополнительные возможности):
Usage (использование):
Замечание. Задавая ключевые слова, избегайте применения специальных символов, пробелы относятся к их числу. Выдав команду:
получим: [extra.ucc.su.oz.au] Таким образом, даже с помощью Finger можно организовать доступ к базам данных. Finger не сработает для узлов, не имеющих IP-адресов (например, электронный почтовый адрес). Эта команда всегда позволит руководителю проекта узнать, например, когда последний раз тот или иной участник проекта работал на ЭВМ. :-) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.1 Ping и Traceroute
UP:
4.5 Процедуры Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.3 Удаленный доступ (Telnet)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TELNET позволяет пользователю установить TCP-соединение с сервером и затем передавать коды нажатия клавиш так, как если бы работа проводилась на консоли сервера. TELNET (RFC-854, в некоторых реализациях tn) служит для выполнения удаленного доступа к вычислительным ресурсам и базам данных (например, к базам ядерных данных в Вене, Брукхейвене или STN-international в Карлсруэ). Для входа в базу данных или ЭВМ обычно нужна аутентификация (ввод имени-идентификатора пользователя и его слова-пропуска). В некоторых реализациях допускается использование параметров, которые подключают необходимые эмуляторы терминалов. TELNET предлагает три услуги:
Протокол TELNET позволяет обслуживающей машине рассматривать все удаленные терминалы как стандартные "сетевые виртуальные терминалы" строчного типа, работающие в кодах ASCII, а также обеспечивает возможность согласования более сложных функций (например, локальный или удаленный эхо-контроль, страничный режим, высота и ширина экрана и т. д.). На прикладном уровне над TELNET находится либо программа поддержки реального терминала, либо прикладной процесс в обслуживающей машине, к которому осуществляется доступ с терминала. Формат NTV достаточно прост. Для данных используются 7-битовые ASCII коды. 8-битовые же октеты зарезервированы для командных последовательностей. Telnet взаимодействует с другой ЭВМ через протокол TELNET. Если команда TELNET вводится без аргументов ЭВМ переходит в командный режим, напечатав приглашение telnet>. В этом режиме она воспринимает и исполняет команды, описанные ниже. При вводе TELNET с аргументами программа осуществит связь вашей ЭВМ с удаленным компьютером, имя или адрес которого вы ввели в качестве одного из аргументов. После того как TELNET связь установлена, начинаются переговоры об используемых опциях (см. табл. 4.5.3.1). Каждая из договаривающихся сторон может послать другой один из четырех запросов will, do, wont и dont (см табл. 4.5.3.4). Далее TELNET переходит в режим ввода. В этом режиме любой введенный текст пересылается удаленной ЭВМ. Ввод может производиться посимвольно или построчно. При посимвольном режиме каждый введенный символ пересылается немедленно, при построчном режиме отклик на каждое нажатие клавиши производится локально, а пересылка выполняется лишь при нажатии клавиши <Enter>. Некоторые опции требуют дополнительных данных, такая информация ожет быть получена с помощью субопций (RFC-1091). При этом клиент посылает трехбайтовую последовательность IAC WILL 24, где 24 - код-идентификатор терминала. Получатель может откликнуться последовательностью IAC DO 24, если все в порядке. Сервер в свою очередь посылает последовательность IAC SB 24 1 IAC SE, запрашивая тип терминала клиента. Здесь код 24 означает, что это субопция для опции типа терминала (см. табл. 4.5.3.1), а следующая 1 является командой "пришлите код вашего терминала". Клиент в свою очередь может откликнуться, послав последовательность - IAC SB 24 0 I B M P C IAC SE. Здесь байт 0 имеет значение "мой терминал имеет тип". Список кодов терминалов содержится в RFC-1700. Таблица 4.5.3.1. Коды опций в Telnet
Когда связь с удаленной ЭВМ уже осуществлена, переход в командный режим может быть выполнен с помощью нажатия '^]' (escape). В этом режиме доступны команды:
Значения переменных можно узнать с помощью команды display. Такими переменными могут быть: echo, escape, interrupt, quit, flushoutput, erase, kill, eof, echo. Последняя переменная (в исходном состоянии `^E') в построчном режиме осуществляет переключение между локальным эхо на ввод символа (режим по умолчанию) и подавлением эхо, например при вводе пароля. Переменные процедуры telnet представлены в таблице 4.5.3.2. Практически стандарт TELNET описан во многих RFC документах, которые определяют различные варианты реализации этой команды. Список опций команды telnet приведен в таблице 4.5.3.1 (не все эти возможности доступны в конкретных программных продуктах). Таблица 4.5.3.2. Переменные telnet
Таблица 4.5.3.3. Последовательности символов, используемые совместно с командой send
В таблице 4.5.3.4 представлены наименования и коды команд Telnet, которые используются как клиентом, так и сервером в сочетании с префиксным байтом 0xff (IAC - "интерпретировать как команду"). Если нужно послать код данных, равный 255, посылается два байта с кодами 255. Таблица 4.5.3.4. Коды команд TELNET
Операция прерывание процесса (IP) позволяет прервать, удалить или завершить процесс пользователя (например, выйти из бесконечного цикла). Процедура прерывание вывода (AO) позволяет процессу пользователя продолжаться, но вывод на его рабочую станцию прерывается, при этом очищается буфер от уже записанной, но не отображенной информации. Запрос "Вы здесь?" (AYT) удобен, когда необходимо выяснить выполняется ли пользовательская задача или нет. Операция стереть символ (EC) позволяет пользователю удалить символ из потока данных, применяется для редактирования текста на экране. Операция стереть строку (EL) позволяет пользователю при редактировании удалить целую строку. Команда "go ahead" (GA, "продолжайте") устанавливает полудуплексный режим передачи данных. Каких-либо воздействий на удаленную ЭВМ обычно не производит. В таблице 4.5.3.5 приведен список комбинаций клавиш, нажатие которых вызывает определенный результат. Таблица 4.5.3.5. Управляющие комбинации клавиш
Блок данных процедуры TELNET содержит три байта и называется командой. Формат этого блока показан на рис. 4.5.3.1.
Рис. 4.5.3.1. Формат блока данных Telnet Первый байт в соответствии с таблицей содержит 8 единиц, далее следует байт команды (табл. 4.5.3.4). Третий октет служит для размещения кода опции, он может и отсутствовать. Рассмотрим несколько примеров этих команд. Допустим, вы хотите, чтобы обмен данными производился в виде 8-битовых посылок. Для реализации вашего пожелания достаточно выдать команду: IAC WILL TRANSMIT-BINARY, которая в цифровых кодах выглядит как - (255 251 0). Для прекращения этого (двоичного) режима передачи нужно выдать команду: IAC DON'T TRANSMIT-BINARY (255 254 0). Субкоманды Telnet позволяют управлять откликом при работе с клавиатурой. Обычно отклик-эхо присылается удаленной ЭВМ, реже формируется локально. Для включения отклика можно выдать команду: IAC WILL ECHO (255 251 1) (часто это реализовано по умолчанию). Далее можете поупражняться самостоятельно и проверить какие команды и их опции доступны в используемом вами программном продукте. При работе с Telnet рекомендуется сначала ознакомиться с конкретными возможностями команды с помощью описания (или F10/?). Это позволит вам, например, спасать результаты поиска в файле с указанным вами именем и т.д. Например, для PCTCP такая команда выдаст на экран: Telnet with VT220 and 3270 emulation, escape character is alt-F10 or F10
-------------------------- VT220 emulator commands ------------------------------
---------------------------- 3270 emulator commands ----------------------------
[Press SPACE to return to session, or enter another command (? for Help] Многие telnet-клиенты позволяют также указывать явно номер порта, через который должна быть установлена связь. По умолчанию это порт 23. Обычный пользователь не интересуется, через какой порт он работает. Но иногда желательно реализовывать telnet через разные порты системы, обеспечивающие различные услуги, это бывает полезно и с отладочными целями. Используя команду: telnet XXXXXX.domain <номер порта> можно осуществить связь через порт с заданным номером с узлом XXXXXX.domain. Многие библиотеки используют метод портов для обеспечения доступа к своим ресурсам внешних Inernet-пользователей. Ссылки на RFC-документы по протоколу TELNET смотрите в приложении. Помимо telnet существуют и другие стандартные процедуры, выполняющие схожие задачи. SUN Microsistems разработала и широко использует программный модуль RPC (Remote Procedure Call, RFC-1057), он используется для удаленного вызова программ почти во всех системах, базирующихся на UNIX. RPC может использоваться как на TCP, так и UDP транспортных уровнях. Для удаленного исполнения программ может служить команда REXECD, которая активно используется на IBM-системах в рамках ОС AIX и DOS. Уязвимость протокола Telnet для хакеров привела к тому, что в последнее время эта утилита часто заменяется SSH (Secure Shell) или другими программами, обеспечивающими безопасный удаленный доступ. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.2 Finger
UP:
4.5 Процедуры Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. Введение Управление последовательных линий и модемных пулов при большом числе пользователей может потребовать весьма значительных административных усилий. Так как модемные пулы по определению являются каналами во внешний мир, они требуют особых мер безопасности. Это может быть реализовано путем поддержки единой базы данных пользователей, которая используется для аутентификации (проверке имени и пароля). Эта база данных хранит в себе и конфигурационные данные, характеризующие вид услуг, предоставляемых пользователю (например, SLIP, PPP, telnet, rlogin). Модель клиент/сервер Сервер сетевого доступа NAS (Network Access Server) работает как клиент системы RADIUS (RFC-2138, 2618-2621). Клиент передает информацию о пользователе специально выделенным серверам RADIUS, и далее действует в соответствии с полученным откликом на эти данные. Серверы RADIUS принимают запросы от пользователей, осуществляют аутентификацию и выдают конфигурационную информацию, которая необходима клиенту, чтобы предоставить пользователю запрошенный вид услуг. Сервер RADIUS может выполнять функцию прокси-клиента по отношению к другим серверам RADIUS или прочим аутентификационным серверам. Сетевая безопасность Взаимодействие клиента и сервера RADIUS аутентифицируются с использованием общего секретного ключа (пароля), который никогда не пересылается по сети. Кроме того, каждый пароль пользователя пересылается от клиента к серверу в зашифрованном виде, чтобы исключить его перехват. Гибкие аутентификационные механизмы Сервер RADIUS может поддерживать несколько методов аутентификации пользователя. При получении имени пользователя и его пароля сервер может воспользоваться PPP PAP или CHAP, UNIX login, и другими аутентификационными механизмами. Масштабируемый протокол Все операции подразумевают использование ансамблей атрибут-длина-значение. Новое значение атрибута может быть добавлено без редактирования существующей версии реализации протокола. 1.1. Терминология В этом документе используются следующие термины:
Молчаливое удаление (silently discard)
2. Работа Когда клиент сконфигурирован для использования RADIUS, любой пользователь предоставляет аутентификационные данные клиенту. Это может быть сделано с помощью традиционной процедуры login, когда пользователь вводит свое имя и пароль. В качестве альтернативы может использоваться протокол типаPPP, который имеет специальные пакеты, несущие аутентификационную информацию. Когда клиент получил такую информацию, он может выбрать для аутентификации протокол RADIUS. Для реализации этого клиент формирует запрос доступа (Access-Request), содержащий такие атрибуты как имя пользователя, его пароль, идентификатор клиента и идентификатор порта, к которому должен получить доступ пользователь. При передаче пароля используется метод, базирующийся на алгоритме MD5 (RSA Message Digest Algorithm [1]). Запрос Access-Request направляется по сети серверу RADIUS. Если в пределах заданного временного интервала не поступает отклика, запрос повторяется. Клиент может переадресовать запрос альтернативному серверу, если первичный сервер вышел из строя или недоступен. Когда сервер RADIUS получил запрос, он проверяет корректность клиента-отправителя. Запрос, для которого сервер RADIUS не имеет общего секретного ключа (пароля), молча отбрасывается. Если клиент корректен, сервер RADIUS обращается к базе данных пользователей, чтобы найти пользователя, чье имя соответствует запросу. Пользовательская запись в базе данных содержит список требований, которые должны быть удовлетворены, прежде чем будет позволен доступ. Сюда всегда входит сверка пароля, но можно специфицировать клиента или порт, к которому разрешен доступ пользователя. Сервер RADIUS может посылать запросы к другим серверам, для того чтобы выполнить запрос, в этом случае он выступает в качестве клиента. Если хотя бы какое-то условие не выполнено, сервер посылает отклик "Access-Reject" (отклонение Access-Reject текст комментария. Если все условия выполнены, сервер может послать отклик-приглашение (Access-Challenge). Этот отклик может содержать текстовое сообщение, которое отображается клиентом и предлагает пользователю откликнуться на приглашение. Отклик-приглашение может содержать атрибут состояния (State). Если клиент получает Access-Challenge, он может отобразить текст сообщения и затем предложить пользователю ввести текст отклика. Клиент при этом повторно направляет свой Access-Request с новым идентификатором, с атрибутом пароля пользователя, замененным зашифрованным откликом. Этот запрос включает в себя атрибут состояния, содержащийся в приглашении Access-Challenge (если он там был). Сервер может реагировать на этот новый запрос откликами Access-Accept, Access-Reject, или новым Access-Challenge. Если все условия выполнены, список конфигурационных значений для пользователя укладываются в отклик Access-Accept. Эти значения включают в себя тип услуги (например: SLIP, PPP, Login User) и все параметры, необходимые для обеспечения запрошенного сервиса. Для SLIP и PPP, сюда могут входить такие значения как IP-адрес, маска субсети, MTU, желательный тип компрессии, а также желательные идентификаторы пакетных фильтров. В случае символьного режима это список может включать в себя тип протокола и имя ЭВМ. 2.1. Запрос/Отклик При аутентификации приглашение/отклик, пользователю дается псевдослучайное число и предлагается его зашифровать и вернуть результат. Авторизованные пользователи снабжаются специальными средствами, такими как смарт-карта или программой, которая облегчает вычисление отклика. Пакет Access-Challenge обычно содержит сообщение-ответ, включая приглашение (challenge), которое должно быть отображено для пользователя. Обычно оно имеет форму числа и получается от внешнего сервера, который знает, какого типа аутентификатор должен быть применен для данного авторизованного пользователя и, следовательно, может выбрать псевдослучайное число заданной длины. Пользователь вводит приглашение в свое устройство или программу и вычисляет отклик, который через клиента транспортируется серверу RADIUS посредством второго сообщения Access-Request. Если отклик соответствует ожидаемому значению, сервер присылает сообщение Access-Accept, в противном случае - Access-Reject. Пример: NAS посылает серверу RADIUS пакет Access-Request с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (который может быть фиксированной строкой, как приглашение "challenge", но Access-Challenge с сообщениями состояния (State) и Reply-Message вместе со строкой "Challenge 12345678, enter your response at the prompt", которую отображает NAS. NAS предлагает ввести отклик и посылает серверу новый запрос NEW Access-Request (с новым идентификатором) с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (отклик, введенный пользователем, шифруется) и с тем же самым атрибутом состояния, который прислан с Access-Challenge. Сервер затем присылает назад Access-Accept или Access-Reject в зависимости от того, корректен ли отклик или следует послать еще один Access-Challenge. 2. Работа с PAP и CHAP Для PAP, NAS берет идентификатор PAP и пароль и посылает их в пакете Access-Request в полях имя пользователя и пароль пользователя.. NAS может содержать атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, который предполагает использование услуг PPP. Для CHAP NAS генерирует псевдослучайное приглашение (желательно 16 октетов) и посылает его пользователю, который возвращает CHAP-отклик вместе с идентификатором и именем пользователя CHAP. NAS посылает затем серверу RADIUS пакет Access-Request с именем CHAP-пользователя в качестве User-Name и с CHAP ID и CHAP-откликом в качестве CHAP-Password (атрибут 3). Случайный вызов может быть включен в атрибут CHAP-Challenge или, если он имеет длину 16 октетов, может быть помещен в поле аутентификатор запроса пакета запроса доступа. NAS может включать в себя атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, указывая, что предполагается использование канала PPP. Сервер RADIUS ищет пароль по имени пользователя, шифрует вызов и CHAP-вызов с помощью алгоритма MD5, затем сравнивает результат с CHAP-паролем. Если они совпадают, сервер посылает сообщение Access-Accept, в противном случае - Access-Reject. Если сервер RADIUS не способен выполнить запрошенную аутентификацию, он должен прислать сообщение Access-Reject. Например, CHAP требует, чтобы пароль пользователя должен быть доступен серверу в открытом текстовом виде, чтобы он мог зашифровать CHAP-вызов и сравнить его с CHAP-откликом. Если пароль не доступен серверу RADIUS в таком виде, он должен послать клиенту сообщение Access-Reject. 2.3. Почему UDP? Может возникнуть вопрос, почему RADIUS использует протокол UDP вместо TCP. UDP был выбран по чисто техническим причинам. Существует большое число моментов, которые нужно понять. RADIUS является протоколом, ориентированным на операции и имеющим ряд интересных особенностей:
Клиенты и серверы приходят и уходят. Системы перезагружаются, а сетевое питание выключается и включается... UDP полностью исключает влияние всех этих событий на работу системы. Любой клиент и сервер может открыть UDP обмен однажды и оставлять его в таком состоянии, игнорируя какие-либо сбои в сетевой среде. 2.4. UDP упрощает реализацию сервера. В ранних реализациях RADIUS сервер поддерживал один процесс (single threaded). Это означает, что только один запрос принимался, обрабатывался и отправлялся. Это оказалось неприемлемым для сред, где механизм обеспечения безопасности требует определенного времени (1 или более секунд). Очередь запросов в сервере будет значительной и в средах, где сотни людей требуют аутентификации каждую минуту, время обслуживания запроса становится настолько большой, что начинает нервировать пользователей. Очевидным решением проблемы является многопроцессный сервер. Достичь этого проще всего с помощью UDP. Порождаются отдельные процессы для обслуживания каждого запроса, а эти процессы могут напрямую взаимодействовать с клиентом NAS путем отправки UDP-пакета. Это не панацея. Применение UDP требует организации повторных передач, для чего нужно на сервере запускать соответствующие таймеры. В этом UDP уступает TCP, но это небольшая плата за полученные преимущества. 3. Формат пакета Один пакет RADIUS вкладывается в одну UDP-дейтограмму [2]. При этом порт назначения равен 1812 (десятичное). При формировании отклика коды портов отправителя и получателя меняются местами. Формат пакета RADIUS показан на рис. .1. Разряды пронумерованы в порядке их передачи.
Поле код содержит один октет и идентифицирует тип пакета RADIUS. Если получен пакет с неверным значением поля код, он молча отбрасывается. Стандартизованы следующие значения поля код:
Коды 4 и 5 будут описаны в документе [RFC-2139]. Коды 12 и 13 зарезервированы для возможного использования. Поле идентификатор имеет один октет, и служит для установления соответствия между запросом и откликом. Поле длина имеет два октета. Оно определяет длину пакета, включая поля код, идентификатор, длина, аутентификатор и атрибуты. Октеты за пределом, указанным полем длина, рассматриваются как заполнитель и игнорируются получателем. Если пакет короче, чем указано в поле длина, он должен быть молча выкинут. Минимальная длина равна 20, а максимальная - 4096. Поле аутентификатор имеет 16 октетов. Старший октет пересылается первым. Этот параметр служит для аутентификации отклика от сервера RADIUS, и используется в алгоритме сокрытия пароля. В пакетах Access-Request, значение поля аутентификатор равно 16-октетному случайному числу, называемому аутентификатор запроса. Его значение должно быть непредсказуемым и уникальным на протяжении жизни секретного пароля, совместно используемого клиентом и RADIUS-сервером. Значение аутентификатора запроса в пакете Access-Request должно быть также непредсказуемым, чтобы исключить возможные атаки. Хотя протокол RADIUS не может исключить всех возможных атак, в частности с использованием подключения к линии в реальном масштабе времени, но генерация псевдослучайных аутентификаторов все же обеспечивает относительную безопасность. NAS и сервер RADIUS используют секретный пароль совместно. Этот секретный пароль и аутентификатор запроса пропускаются через хэширование MD5, чтобы получить 16-октетный дайджест, который объединяется посредством операции XOR с паролем, введенным пользователем, результат помещается в атрибут пароля пользователя пакета Access-Request. Значение поля аутентификатор в пакетах Access-Accept, Access-Reject, и Access-Challenge называется аутентификатором отклика (Response Authenticator). Оно представляет собой однопроходную хэш-функцию MD5, вычисленную для потока октетов, включающих в себя: пакет RADIUS, начинающийся с поля код, и включающий поля идентификатор, длина, аутентификатор запроса из пакета Access-Request, и атрибуты отклика, за которыми следует общий секретный пароль. То есть ResponseAuth = MD5(Код+ID+длина+RequestAuth+атрибуты+секретный_пароль) где знак + означает присоединение. Секретный пароль, совместно используемый клиентом и сервером RADIUS, должен быть достаточно большим и непредсказуемым, как хороший пароль. Желательно, чтобы секретный пароль имел, по крайней мере, 16 октетов. Сервер RADIUS должен использовать IP-адрес отправителя UDP-пакета, чтобы решить, какой секретный пароль использовать. Когда используется переадресующий прокси-сервер, он должен быть способен изменять пакет при проходе в том или ином направлении. Когда прокси переадресует запрос, он может добавить атрибут Proxy-State, а при переадресации отклика, он удаляет атрибут Proxy-State. Так как ответы Access-Accept и Access-Reject аутентифицированы по всему своему содержимому, удаление атрибута Proxy-State сделает сигнатуру пакета некорректной. По этой причине прокси должен вычислить ее заново. Атрибуты Многие атрибуты могут быть записаны несколько раз, в этом случае порядок следования атрибутов одного и того же типа должен быть сохранен. Порядок атрибутов различных типов может быть изменен. В данном документе регламентированы атрибуты для пакетов с полем код, равным 1, 2, 3 и 11. Чтобы определить, какие атрибуты допускаются для пакетов с полем код=4 и 5, смотри [9]. 4. Типы пакетов Тип пакета RADIUS определяется полем тип, размещенным в первом октете. 4.1. Запрос доступа Пакеты Access-Request посылаются серверу RADIUS, и передают информацию, которая используется для определения того, позволен ли данному пользователю доступ к специфицированному NAS, и допустимы ли запрошенные услуги. Программная реализация, желающая аутентифицировать пользователя, должна послать пакет RADIUS с кодом поля тип=1 (Access-Request). При получении запроса (Access-Request) доступа от корректного клиента, должен быть передан соответствующий ответ. Запрос доступа (Access-Request) должен содержать атрибут имени пользователя. Он должен включать в себя атрибут NAS-IP-адреса или атрибут NAS-идентификатора (или оба эти атрибута, хотя это и не рекомендуется). Он должен содержать атрибут пароля пользователя (User-Password) или атрибут CHAP-пароля. Желательно, чтобы он содержал атрибут NAS-порта или NAS-Port-Type или оба эти атрибута, если только тип запрошенного доступа не содержал номер порта. Запрос доступа (Access-Request) может содержать дополнительные атрибуты - подсказки серверу, но последний не обязан следовать этим подсказкам. Когда присутствует пароль пользователя (User-Password), он защищается с использованием метода, базирующегося на RSA алгоритме MD5 [1]. Формат пакета Access-Request аналогичен показанному на рис. .1. Только на месте поля аутентификатор размещается поле аутентификатор запроса (Request Authenticator), а в поле код записывается 1. Поле идентификатор должно измениться при изменении содержимого поля атрибуты, и при получении корректного ответа на предыдущий запрос. При повторных передачах поле идентификатор остается неизменным. Значение поля аутентификатор запроса (Request Authenticator) должно изменяться, когда используется новый идентификатор. Поле атрибуты имеет переменную длину и содержит список атрибутов, которые необходимы для заданного типа сервиса, а также любых дополнительных опционных атрибутов. 4.2. Пакеты Access-Accept Пакеты Access-Accept посылаются сервером RADIUS, и предоставляют специфическую конфигурационную информацию, необходимую для предоставления пользователю соответствующего сервиса. Если все значения атрибутов, полученных с запросом Access-Request, приемлемы, тогда реализация RADIUS должна послать пакет с полем код=2 (Access-Accept). При получении сообщения Access-Accept, поле идентификатор соответствует обрабатываему запросу (Access-Request). Кроме того, поле аутентификатор отклика должно содержать корректный отклик на полученный запрос Access-Request. Пакеты неверного формата молча отбрасываются. Формат пакета Access-Accept идентичен показанному на рис. .1. Но здесь вместо поля аутентификатор используется поле аутентификатор отклика, имеющее тот же размер. В поле код при этом записывается число 2. Поле идентификатор является копией одноименного поля в запросе Access-Request, который инициировал сообщение Access-Accept. Значение поля аутентификатор отклика (Response Authenticator) вычисляется на основе значения Access-Request, как это описано выше. Поле атрибуты имеет переменную длину и содержит список из нуля или более атрибутов. 4.3. Сообщение Access-Reject Если какое-либо значение полученного атрибута неприемлемо, тогда сервер RADIUS должен послать пакет с полем код= 3 (Access-Reject). Пакет может содержать один или более атрибутов Reply-Message с текстом, который может быть отображен NAS для пользователя. Поле идентификатор для данного пакета копируется из одноименного поля пакета Access-Request, вызвавшего данный отклик. Значение поля аутентификатор отклика вычисляется на основе содержимого сообщения Access-Request, как это описано выше. 4.4. Сообщение Access-Challenge Если сервер RADIUS хочет послать пользователю вызов, требующий отклика, то сервер должен реагировать на запрос Access-Request посылкой пакета с полем код=11 (Access-Challenge). Поле атрибуты может содержать один или более атрибутов Reply-Message, и может опционно включать атрибут состояния. Никакие другие атрибуты здесь не применимы. При получении Access-Challenge, поле идентификатор соответствует содержимому пакета Access-Request. Кроме того, поле аутентификатор отклика должно содержать корректный отклик на обрабатываемый запрос Access-Request. Некорректные пакеты молча отбрасываются. Если NAS не поддерживает обмен вызов/отклик (challenge/response), он должен обрабатывать сообщение Access-Challenge, как если бы это был запрос Access-Reject. Если сервер NAS поддерживает обмен вызов/отклик, получение корректного сообщения Access-Challenge указывает, что следует послать новый запрос Access-Request. Сервер NAS может отобразить текстовое сообщение для пользователя, если таковое имеется, а затем предложить ему ввести отклик. Затем сервер посылает исходное сообщение Access-Request с новым идентификатором запроса и аутентификатором отклика, с атрибутом пароля пользователя, содержащим зашифрованный отклик пользователя. Кроме того, это сообщение содержит атрибут состояния (State) сообщения Access-Challenge, если таковой имелся. NAS, который поддерживает PAP может переадресовать сообщение Reply-Message клиенту, подключенному по модемному каналу, и принять PAP-отклик, который он может использовать как отклик, введенный пользователем. Если NAS этого сделать не может, он должен воспринимать Access-Challenge, как если бы он получил сообщение Access-Reject. Формат пакета Access-Challenge совпадает с форматом Access-Accept и Access-Request. Поле идентификатор является копией одноименного поля пакета Access-Request, который вызвал посылку Access-Challenge. Значение аутентификатора отклика вычисляется так, как это было описано выше. Поле атрибуты имеет переменную длину, и содержит список из нуля или более атрибутов. 5. Атрибуты Атрибуты RADIUS несут в себе специфическую аутентификационную и конфигурационную информацию для запросов и откликов. Некоторые атрибуты могут быть включены в список более одного раза. Воздействие такого использования зависит от типа атрибута. Конец списка атрибутов определяется кодом, содержащимся в поле пакета длина. Формат записи атрибута показан на рис. .2.
Поле тип имеет один октет. Возможные значения этого поля перечислены в документе RFC-1700 "Assigned Numbers" [3]. Значения 192-223 зарезервированы для экспериментального использования, значения 224-240 выделены для специальных реализаций, а значения 241-255 зарезервированы на будущее. Ниже в таблице 1. представлена спецификация стандартизованных значений атрибутов. Сервер и клиент RADIUS могут игнорировать атрибуты неизвестного типа. Таблица .1. Cпецификация стандартизованных значений атрибутов
Поле длина является однооктетным, оно определяет длину данного атрибута, включая субполя тип, длина и величина. Если атрибут получен в запросе Access-Request, но с неверной длиной, следует послать сообщение Access-Reject. Если атрибут прислан в пакете Access-Accept, Access-Reject или Access-Challenge и имеет некорректную длину, пакет должен рассматриваться как Access-Reject или молча отбрасываться. Поле значение содержит ноль или более октетов и содержит специфическую информацию атрибута. Формат и длина поля значение определяется полями тип и длина. Заметим, что строка в RADIUS не требует завершения символом ASCII NUL, так как имеется поле длины. Поле значение может иметь один из четырех форматов.
5.1. Имя пользователя Этот атрибут указывает имя пользователя, который должен быть аутентифицирован. Он используется в пакетах Access-Request. Формат атрибута показан на рис. .3.
Поле тип=1, длина ³ 3. Поле строка имеет один или более октетов. NAS может ограничить максимальную длину имени пользователя, но рекомендуется, чтобы программа была способна обрабатывать как минимум 63 октета. Применяется несколько форматов имени пользователя:
5.2. Пароль пользователя Этот атрибут указывает на пароль аутентифицируемого пользователя или на вводимые пользователем данные в ответ на Access-Challenge. Этот атрибут используется только в пакетах Access-Request. При передаче пароль шифруется. Пароль сначала дополняется нулями до границы кратной 16 октетам. Затем согласно алгоритму MD5 вычисляется хэш-функция. Это вычисление производится для потока октетов, состоящего из о бщего секретного пароля, за которым следует аутентификатор запроса (Request Authenticator). Для полученного кода и первых 16 октетов пароля производится операция XOR. Результат кладется в первых 16 октетов поля строка атрибута пароля пользователя. Если пароль длиннее 16 символов, вычисляется вторая хэш-функция для потока данных, включающего в себя общий секретный пароль и результат предыдущей операции XOR. Полученный результат и вторые 16 октетов пароля объединяются с помощью операции XOR, а полученный код кладется во вторые 16 октетов поля строка атрибута User-Password. Если необходимо, эта операция повторяется. Следует только иметь в виду, что поле строка не может превышать 128 символов. Данный метод заимствован из книги "Network Security" Кауфмана, Пелмана и Спесинера [4; стр. 109-110]. Более формализовано алгоритм можно описать следующим образом: Берется общий секретный ключ S и псевдослучайный 128-битный аутентификатор запроса RA. Пароль разбивается на 16-октетные блоки p1, p2, ., pi. последний из них дополняется нулями до размера кратного 16 октетам. Далее реализуется алгоритм MD5. Берутся блоки шифрованного текста c(1), c(2), ., c(i), получаются промежуточные значения b1, b2, . bi:
Поле строка будет содержать c(1)+c(2)+...+c(i), где знак + означает присоединение. При получении осуществляется обратный процесс и получается исходная форма пароля. В результате формируется атрибут, где в поле тип записан код 2, в поле длина число в интервале 18-130, а в поле строка - 16-128 октетов зашифрованного пароля. 5.3. Атрибут CHAP-пароль Этот атрибут характеризует значение отклика, полученного через протокол PPP CHAP (Challenge-Handshake Authentication Protocol) от пользователя в ответ на вызов. Атрибут используется только в пакетах Access-Request. Значение CHAP-вызова хранится в атрибуте CHAP-Challenge (60), если таковой имеется, в противном случае - в поле аутентификатор запроса. Формат атрибута CHAP-Password показан на рис. .4.
Поле CHAP ID имеет один октет и содержит идентификатор CHAP из CHAP-отклика пользователя. Поле строка имеет 16 октетов и содержит CHAP-отклик пользователя. 5.4. Атрибут NAS-IP-Address Этот атрибут указывает IP-адрес сервера NAS, который запрашивает аутентификацию пользователя. Атрибут применяется только в пакетах Access-Request. В пакете Access-Request должен присутствовать NAS-IP-адрес или NAS-идентификатор. Формат атрибута NAS-IP-Address представлен на рис. .5.
Поле адрес имеет протяженность 4 октета (IPv4). 5.5. Атрибут NAS-порт Этот атрибут несет в себе номер порта NAS, который аутентифицируется пользователем. Атрибут применяется только в пакетах Access-Request. Заметим, что здесь термин порт определяет физическое соединение с NAS, а не используется в значении, принятом в протоколах TCP или UDP. NAS-порт или NAS-Port-Type (61) или оба эти атрибута должны присутствовать в пакете Access-Request, если NAS использует несколько портов. Формат атрибута NAS-порт представлен на рис. .6.
Диапазон кодов в поле значение составляет 0 - 65535. 5.6. Атрибут тип услуги (Service-Type) Этот атрибут указывает на тип услуг, которые заказал или получит пользователь. Атрибут используется в пакетах Access-Request и Access-Accept. NAS не требует реализации всех типов услуг и должен обрабатывать атрибуты неизвестных или неподдерживаемых видов услуг, как запросы Access-Reject. Формат записи атрибута идентичен формату NAS-порт. Только поле тип=6. Коды поля значение перечислены в таблице .2.. Таблица .2. Коды поля значение
Таково назначение кодов атрибута типа услуг при использовании в сообщениях Access-Accept. Когда они применяются в пакетах Access-Request, они должны рассматриваться как подсказки серверу RADIUS и говорят, что NAS имеет причины полагать, что пользователь предпочтет указанные услуги, но сервер не обязан следовать этим подсказкам.
5.7. Атрибут Framed-Protocol Этот атрибут указывает на необходимость использования пакетного доступа. Атрибут может использоваться пакетами Access-Request и Access-Accept. Формат представления атрибута аналогичен формату атрибута NAS-порт (рис. .6). Поле тип = 7, поле длина = 6. Коды поля значение собраны в таблице .3. Таблица .3. Коды поля значение
5.8. Атрибут Framed-IP-Address Этот атрибут указывает на адрес, который следует сконфигурировать для пользователя. Атрибут может использоваться пакетами Access-Accept. Он может использоваться в пакетах Access-Request в качестве подсказки NAS, указывающей на то, что сервер предпочитает данный адрес. Сервер не обязан следовать этой подсказке. Формат атрибута идентичен представлению атрибута NAS-IP-адрес (рис. .5). Поле тип = 8, поле длина = 6. Поле адрес содержит 4 октета. Значение 0xFFFFFFFF указывает, что NAS следует разрешить пользователю выбрать адрес. Значение 0xFFFFFFFE отмечает, что NAS следует выбрать адрес для пользователя (например, выбрать его из зарезервированного списка, имеющегося в NAS). Другие допустимые значения указывают, что NAS должен использовать этот код в качестве IP-адреса пользователя. 5.9. Атрибут Framed-IP-Netmask Этот атрибут указывает на сетевую IP-маску, которая должна быть сконфигурирована для пользователя, когда он является маршрутизатором сети. Атрибут может использоваться в пакетах Access-Accept. Он может использоваться в пакете Access-Request в качестве подсказки NAS серверу относительно того, какую сетевую маску он предпочитает. Но сервер не обязан следовать этой подсказке. Формат записи атрибута аналогичен формату атрибута NAS-IP-адрес. Поле тип = 9, поле длина = 6. Поле адрес имеет 4 октета и определяет сетевую IP-маску. 5.10. Атрибут Framed-Routing Этот атрибут указывает метод маршрутизация для пользователя, когда пользователем является маршрутизатор сети. Атрибут может использоваться в пакетах Access-Accept. Формат записи атрибута аналогичен показанному на рис. .6 (NAS-порт). Поле тип = 10, поле длина = 10. Допустимые коды и их назначения собраны в таблице .4 Таблица .4. Допустимые коды поля значение и их назначения
5.11. Атрибут Filter-Id Этот атрибут указывает на имя списка фильтра для данного пользователя. Нуль или более идентификаторов фильтра может быть переслано в пакете Access-Accept. Идентификация списка фильтра с помощью имени позволяет использовать фильтр с различными NAS вне зависимости от особенностей использования списка фильтра. Формат записи атрибута соответствует рис. .3. поле тип = 11, поле длина ³ 3. Поле строка здесь имеет один или более октетов и его содержимое зависит от программной реализации. Содержимое должно иметь читабельный формат и не должно влиять на работу протокола. Рекомендуется, чтобы отображаемое сообщение содержало 32-126 ASCII-символов. 5.12. Атрибут Framed-MTU Этот атрибут указывает значение MTU, которое должно быть проставлено для пользователя, когда это не согласуется каким-либо другим образом (например, PPP). Атрибут используется только в пакетах Access-Accept. Формат атрибута аналогичен показанному на рис. 6. Поле тип = 12, а поле длина = 6. Поле значение имеет 4 октета и может принимать значения в интервале 64-65535. 5.13. Атрибут Framed-Compression Этот атрибут указывает на протокол сжатия, который следует использовать при передаче данных. Атрибут используется в пакетах Access-Accept. Атрибут используется в пакетах Access-Request в качестве подсказки серверу о том, какой вид компрессии предпочитает использовать NAS, но сервер не обязан следовать этой рекомендации. Можно использоваться несколько атрибутов данного типа. Окончательное решение о применении того или иного метода компрессии принимает сервер NAS. Формат атрибута аналогичен показанному на рис. 6. Поле тип = 13, а поле длина = 6. Возможные коды поля значение собраны в таблице .5. Таблица .5. Возможные коды поля значение
5.14. Атрибут Login-IP-Host Этот атрибут указывает на систему, с которой соединяется пользователь при наличии атрибута Login-Service. Атрибут используется в пакетах Access-Accept, а также Access-Request в качестве подсказки серверу, какую из ЭВМ предпочитает NAS, но сервер не обязан следовать этой рекомендации. Формат записи атрибута аналогичен показанному на рис. .5. Поле тип = 14, а поле длина = 6. Поле адрес имеет 4 октета. Значение 0xFFFFFFFF указывает на то, что NAS должен позволить пользователю выбор адреса. Значение 0 говорит, что NAS должен сам выбрать ЭВМ, с которой будет соединен пользователь. Любые другие значения указывают адрес, с которым сервер NAS должен соединить пользователя. 5.15. Атрибут Login-Service Этот атрибут указывает на услугу, которая будет использоваться для соединения пользователя с ЭВМ. Атрибут применяются только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 15, а поле длина = 6. Возможные коды поля значение собраны в таблице .6. Таблица .6. Возможные коды поля значение
5.16. Атрибут Login-TCP-Port Этот атрибут указывает порт TCP, с которым следует соединить пользователя при наличии атрибута Login-Service. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 16, а поле длина = 6. Поле значение имеет четыре октета и может содержать величины в диапазоне 0 - 65535. 5.17. Атрибут типа 17 в настоящее время не определен. 5.18. Атрибут Reply-Message Этот атрибут содержит текст, который может быть отображен для пользователя. Если используется в пакете Access-Accept, это сообщение об успешном выполнении. При использовании с Access-Reject, это уведомление о неудаче. Это может быть элемент диалога с пользователем перед очередной попыткой послать запрос доступа (Access-Request). Когда атрибут используется в Access-Challenge, он может содержать приглашение пользователю ввести отклик. Допускается применение нескольких атрибутов Reply-Message, в этом случае они должны отображаться в порядке из записи в пакете. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 18, а поле длина ³ 3. Поле строка содержит один или более октетов. Его содержимое может зависеть от конкретной программной реализации. Содержимое должно быть читабельным и не должно влиять на работу протокола. Рекомендуется, чтобы текст состоял из печатных ASCII символов с кодами 10, 13 и 32 - 126. 5.19. Атрибут Callback-Number Этот атрибут представляет собой телефонный номер, используемый для обратного дозвона. Атрибут может использоваться в пакетах Access-Accept, а также в Access-Request в качестве подсказки серверу о том, что желателен обратный дозвон, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 19, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. 5.20. Атрибут Callback-Id Этот атрибут содержит имя места вызова, которое должно быть интерпретировано сервером NAS. Атрибут может использоваться пакетами Access-Accept. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 20, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. 5.21. Атрибут типа 21 в настоящее время не определен 5.22. Атрибут Framed-Route Этот атрибут содержит маршрутную информацию, которая должна быть сконфигурирована сервером NAS для пользователя. Атрибут используется в пакетах Access-Accept и может присутствовать там несколько раз. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 22, а поле длина ³ 3. Поле строка содержит один или более октетов, а его содержимое зависит от приложения. Текст должен быть читабельным и не должен влиять на работу протокола. Рекомендуется, чтобы сообщение содержало ASCII-символы с кодами в диапазоне 32 - 126. Для IP-маршрутов, атрибут должен содержать префикс места назначения в десятично-точечном представлении (как IP-адрес). Далее опционно может следовать косая черта и число старших бинарных единиц, указывающее на количество разрядов префикса, которые следует использовать. Далее следует пробел, адрес шлюза, еще один пробел и один или более кодов метрики, разделенных пробелами. Например, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". Длина спецификатора может быть опущена, тогда для префикса класса А подразумевается длина в 8 бит, для класса В - 16 и для класса С - 24 бита. Например, "192.168.1.0 192.168.1.1 1". Если адрес шлюза равен "0.0.0.0", тогда в качестве IP-адреса шлюза следует использовать адрес пользователя. 5.23. Атрибут Framed-IPX-Network Этот атрибут содержит сетевое число IPX, конфигурируемое для пользователя. Атрибут используется в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 23, а поле длина = 6. Поле значение имеет 4 октета. Значение 0xFFFFFFFE указывает, что сервер NAS должен выбрать для пользователя сеть IPX (т.е. выбрать одну или более IPX-сетей из имеющегося списка). Остальные значения должны рассматриваться как IPX-сети, предназначенные для подключения. 5.24. Атрибут State Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Challenge и должен быть передан немодифицированным от клиента к серверу в новом отклике Access-Request на исходный вызов, если таковой имеется. Этот атрибут может быть послан сервером клиенту в сообщении Access-Accept, которое содержит также атрибут Termination-Action со значением RADIUS-Request. Если сервер NAS выполняет процедуру Termination-Action путем посылки сообщения Access-Request по завершении текущей сессии, атрибут должен включать в себя исходный код атрибута State из запроса Access-Request. В любом случае клиент не должен его интерпретировать. В пакете может содержаться только один атрибут State. Использование атрибута зависит от конкретной реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 24, а поле длина ³ 3. Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. 5.25. Атрибут Class Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Accept, он должен быть переслан в неизменном виде клиентом серверу, куда планируется доступ, в пакете Accounting-Request. Клиент не должен интерпретировать этот атрибут. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 25, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. 5.26. Атрибут Vendor-Specific Этот атрибут служит для того, чтобы позволить производителям обеспечить поддержку их собственных атрибутов, непригодных для общего применения. Атрибут не должен влиять на работу протокола RADIUS. Серверы, не приспособленные для интерпретации информации, специфической для производителя оборудования или программ, должны игнорировать эти атрибуты (хотя могут и оповещать об этом). Клиенты, которые не получили желательной информации, специфической для изготовителя, должны предпринять попытку работать без этих данных. При этом функциональность может быть сужена (о чем клиент может сообщить пользователю). Формат записи атрибута показан на рис. .7. Поле тип = 26, а поле длина ³ 7.
Старший октет ID изготовителя равен нулю, а младшие три октета представляют собой код изготовителя, как это определено в RFC-1700 (SMI Network Management Private Enterprise Code [2]). Порядок октетов сетевой. Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Строка должна кодироваться в виде последовательности тип производителя / длина / поля значений, специфические для производителя. Пример формата строки показан на рис. .8.
Поле строка предназначено для записи параметров, специфических для данного производителя. 5.27. Атрибут Session-Timeout Этот атрибут устанавливает максимальное число секунд, в течение которых будет предоставляться услуга пользователю до завершения сессии или очередного вызова. Этот атрибут может быть послан сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 27, а поле длина = 6. Поле значение содержит 4 октета, и несет в себе 32-битовое целое число (максимальное число секунд, в течение которых пользователь будет оставаться соединенным с сервером NAS). 5.28. Атрибут Idle-Timeout Этот атрибут устанавливает максимальное число секунд (непрерывный временной отрезок), в течение которых пользователь может оставаться пассивным, прежде чем соединение с сервером будет разорвано или будет получен вызов. Этот атрибут передается сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 28, а поле длина = 6. Поле значение содержит 4 октета и несет в себе 32-битовое целое число без знака, соответствующее максимальному времени пассивности клиента в секундах. По истечении этого времени соединение с сервером разрывается. 5.29. Атрибут Termination-Action Этот атрибут указывает, какие действия должен выполнить сервер NAS, когда процедура будет завершена. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 29, а поле длина = 6. Поле значение имеет 4 октета. Ниже приведены разрешенные коды поля значения.
Если поле значение соответствует RADIUS-Request, по завершении соответствующего сервиса NAS может послать новый запрос Access-Request серверу RADIUS, включив атрибут State, если он имеется. 5.30. Атрибут Called-Station-Id Этот атрибут позволяет NAS посылать в пакетах Access-Request телефонный номер, который вызывает пользователь. При этом используется техника DNIS (Dialed Number Identification) или ей подобная. Заметим, что это может быть не тот телефонный номер, через который пришел вызов. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 30, поле длина ³ 3. Поле строка содержит один или более октетов, содержащих телефонный номер, через который пользователь дозвонился до системы. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. 5.31. Атрибут Calling-Station-Id Этот атрибут позволяет NAS послать в пакете Access-Request телефонный номер, с которого пришел вызов, используя АОН (ANI - Automatic Number Identification) или другую технику. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 31, поле длина ³ 3. Поле строка содержит один или более октетов, где записан номер телефона, с которого позвонил пользователь. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Рекомендуется использование печатных ASCII-символов. 5.32. Атрибут NAS-идентификатор Этот атрибут содержит строку, идентифицирующую запрос Access-Request, посланный сервером NAS. Атрибут используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать атрибут NAS-IP-Address или NAS-Identifier. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 32, а поле длина ³ 3. Поле строка содержит один или более октетов, и должна быть уникальной для NAS в области действия сервера RADIUS. Например, полное имя домена вполне подходит в качестве NAS-идентификатора. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. 5.33. Атрибут Proxy-State Этот атрибут предназначен для посылки прокси-сервером другому серверу при переадресации запроса Access-Request и должен быть возвращен в неизменном виде в сообщениях Access-Accept, Access-Reject или Access-Challenge. Этот атрибут должен быть удален прокси-сервером, до того как отклик будет переадресован серверу NAS. Использование атрибута Proxy-State зависит от реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 33, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. 5.34. Атрибут Login-LAT-Service Этот атрибут указывает на систему, с которой должен быть соединен пользователь посредством LAT (Local Area Transport). Он может использоваться в пакетах Access-Accept, но только когда в качестве услуги специфицирован LAT (локальный доступ). Атрибут может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер не обязан следовать этой рекомендации. Администраторы используют атрибут сервиса, когда имеют дело с кластерными системами, такими как VAX или Alpha-кластер. В такой среде несколько процессоров совместно используют общие ресурсы (диски, принтеры и т.д.), и администраторы конфигурируют каждый из них для обеспечения к каждому из ресурсов. В этом случае каждая ЭВМ в кластере оповещает о предоставляемых услугах через широковещательные сообщения LAT. Продвинутые пользователи часто знают, какие сервис-провайдеры (ЭВМ) обладают большим быстродействием и предпочитают использовать имя узла при установлении LAT-соединения. Некоторые администраторы хотели бы, чтобы определенные пользователи работали с определенными машинами, что представляет собой примитивную форму балансировки нагрузки (хотя LAT имеет собственную систему балансировки). Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 34, а поле длина ³ 3. Поле строка имеет один или более октетов и содержит идентификатор LAT-сервиса. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точка), _ (подчеркивание), числа, буквы верхнего и нижнего регистров, а также расширенный символьный набор ISO Latin-1 [6]. Все сравнения в LAT не зависят от регистра символов. 5.35. Атрибут Login-LAT-Node Этот атрибут указывает на узел, с которым пользователь должен быть соединен автоматически LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда в качестве услуги подключения указан LAT. Он может быть применен в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 35, а поле длина ³ 3. Поле строка имеет один или более октетов и содержит идентификатор узла LAT, с которым следует соединиться пользователю. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), числа, буквы нижнего и верхнего регистров, а также расширяющий символьный набор ISO Latin-1. Все сравнения в LAT не зависят от регистра символов. 5.36. Атрибут Login-LAT-Group Этот атрибут содержит строку, идентифицирующую групповой код LAT, который данный пользователь авторизован использовать. Атрибут может использоваться в пакетах Access-Accept, но только когда специфицирован LAT в качестве Login-Service. Он может быть использован в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. LAT поддерживает 256 различных групповых кодов, которые LAT использует как некую форму прав доступа. LAT преобразует эти групповые коды в 256 битовую карту соответствия (bitmap). Администраторы могут приписать один или более бит группового кода сервис-провайдеру LAT. Он будет воспринимать соединения LAT, которые имеют установленные биты, соответствующие их групповым кодам. Администраторы присваивают битовую маску кодов авторизованных групп каждому пользователю. LAT получает эти маски-карты от операционной системы, и использует их в запросах к сервис-провайдерам. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 36, а поле длина = 34. Поле строка содержит 32-октетную маску-карту. Старший октет передается первым. 5.37. Атрибут Framed-AppleTalk-Link Этот атрибут содержит сетевой номер AppleTalk, который должен быть использован для последовательного канала пользователя, являющимся маршрутизатором сети AppleTalk. Атрибут применяется только в пакетах Access-Accept. Он никогда не используется, когда пользователь не является маршрутизатором. Формат записи атрибута показан на рис. .6. Поле тип = 37, а поле длина =6. Поле значение имеет 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что это ненумерованный последовательный канал. Значения 1-65535 обозначают, что последовательной линии между NAS и пользователем присвоен соответствующий сетевой номер AppleTalk. 5.38. Атрибут Framed-AppleTalk-Network Этот атрибут представляет собой сетевой номер AppleTalk, который сервер NAS должен попытаться присвоить узлу AppleTalk. Атрибут используется только в пакетах Access-Accept. Атрибут никогда не используется, если пользователем является маршрутизатор. Многократное использование атрибута в пакете указывает на то, что NAS может попытаться использовать один из сетевых номеров, приведенных в атрибутах. Формат записи атрибута показан на рис. .6. Поле тип = 38, а поле длина =6. Поле значение содержит 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что NAS должен назначить сеть для пользователя. Значения в интервале 1 - 65535 (включительно) указывает на сеть AppleTalk, адрес которой должен найти сервер NAS для пользователя. 5.39. Атрибут Framed-AppleTalk-Zone Этот атрибут указывает на зону AppleTalk по умолчанию, которая должна использоваться для данного пользователя. Атрибут используется только в пакетах Access-Accept. Кратное использование атрибута в одном пакете не допускается. Формат записи атрибута показан на рис. .3. Поле тип = 39, а поле длина ³ 3. Поле строка содержит в себе имя зоны AppleTalk по умолчанию, которая должна использоваться для данного пользователя. 5.40. Атрибут CHAP-Challenge Этот атрибут содержит сообщение CHAP Challenge, посланное сервером NAS в рамках диалога с пользователем CHAP PPP (Challenge-Handshake Authentication Protocol). Атрибут используется только в пакетах Access-Request. Если значение вызова CHAP содержит 16 октетов, оно может быть помещено в поле аутентификатора запроса, применение данного атрибута тогда уже не нужно. Формат записи атрибута показан на рис. .3. Поле тип = 60, а поле длина ³ 7. Поле строка содержит сообщение CHAP Challenge. 5.41. Атрибут NAS-Port-Type Этот атрибут определяет тип физического порта NAS, где аутентифицируется пользователь. Атрибут может использоваться вместо или в добавление к атрибуту NAS-Port (5). Атрибут используется только в пакетах Access-Request. Атрибут NAS-Port (5) или NAS-Port-Type или оба должны применяться в пакетах Access-Request, если NAS различает порты. Формат записи атрибута показан на рис. .6. Поле тип = 61, а поле длина =6. Поле значение имеет 4 октета. "Виртуальный" (в таблице 7) относится к соединению с NAS через некоторый транспортный протокол. Например, если пользователь осуществил удаленный доступ (telnet) в NAS, для того чтобы аутентифицировать себя как внешнего пользователя, запрос Access-Request может включать атрибут NAS-Port-Type = Virtual в качестве подсказки серверу RADIUS, что пользователь не является физическим портом. Таблица .7. Код поля значение атрибута NAS-Port-Type
5.42. Атрибут Port-Limit Этот атрибут устанавливает максимальное число портов, предлагаемых сервером NAS пользователю. Этот атрибут может быть послан сервером клиенту в пакете Access-Accept. Он предназначен для использования в среде многоканального PPP [7]. Он может также быть послан сервером NAS серверу в качестве подсказки того, что доступно большое число портов. Формат записи атрибута показан на рис. .6. Поле тип = 62, а поле длина = 6. Поле значение имеет 4 октета и содержит 32-битовое целое число без знака, которое определяет максимальное число портов, к которым пользователь может быть подключен сервером NAS. 5.43. Атрибут Login-LAT-Port Этот атрибут указывает порт, с которым должен быть соединен пользователь посредством LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда LAT специфицирован в качестве услуг подключения. Он может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер может не следовать этой рекомендации. Формат записи атрибута показан на рис. .3. Поле тип = 63, а поле длина ³ 3. Поле строка имеет один или более октетов и содержит идентификатор порта LAT, который следует использовать. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), цифры, буквы верхнего и нижнего регистра, а также расширенный набор символов ISO Latin-1. Все сравнения в LAT не зависят от регистра символов. 5.44. Таблица атрибутов В таблице собраны основные характеристики атрибутов, типы пакетов, где они используются, а также возможное число атрибутов в пакете. Таблица .8. Основные характеристики атрибутов
[*] Запрос Access-Request должен содержать пароль пользователя или CHAP-пароль, но не должен содержать и то и другое. Ниже в таблице представлены обозначения, использованные в таблице 8.
6. Примеры Предлагается несколько примеров для иллюстрации потока пакетов и использования типовых атрибутов. 6.1. Удаленный доступ пользователя на указанную ЭВМ (Telnet) Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP пакете серверу RADIUS для пользователя с именем NEMO, подключаемого к порту 3. Code = 1 (Access-Request) User-Password = {16-октетный пароль, дополненный в конце нулями и объединенный операцией XOR с MD5(общий секретный пароль|Request Authenticator)} NAS-IP-Address = 192.168.1.16 Сервер RADIUS аутентифицирует NEMO и посылает запрос Access-Accept в UDP пакете серверу NAS, требуя от него организации удаленного доступа пользователя NEMO к ЭВМ с заданным адресом. Code = 2 (Access-Accept) id (0), приведенного выше Request Authenticator, атрибутов этого отклика и общего секретного пароля } Атрибуты: 6.2. Кадровая аутентификация пользователя посредством CHAP Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP-пакете серверу RADIUS для пользователя с именем VANYA для подключения к порту 20 в рамках протокола PPP. Аутентификация осуществляется посредством CHAP. NAS посылает атрибуты Service-Type и Framed-Protocol в качестве рекомендаций серверу RADIUS воспользоваться PPP, хотя NAS необязательно этому последует. Code = 1 (Access-Request) Request Authenticator = {16-октетное случайное число, используется также в вызове CHAP (CHAP challenge)} Атрибуты: CHAP-Password = {1 октет идентификатора CHAP, за которым следует 16 октетов CHAP-отклика} NAS-IP-Address = 192.168.1.16 Сервер RADIUS аутентифицирует VANYA и посылает запрос Access-Accept в UDP-пакете серверу NAS, сообщая, что он отрывает PPP-сессию и приписывает адрес пользователю из имеющегося у него списка. Code = 2 (Access-Accept) Атрибуты: 6.3. Пользователь с картой вызова-отклика (Challenge-Response) Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request серверу RADIUS для пользователя с именем MANYA, подключаемого к порту 7.
ID = 2 Атрибуты: Сервер RADIUS решает вызвать MANYA, отсылая назад строку вызова и ожидая отклика. Сервер RADIUS посылает запрос Access-Challenge серверу NAS.
Response Authenticator = {16-октетов контрольной суммы MD-5 кода (11), ID (2), Request Authenticator, представленный выше, атрибуты данного отклика и общий секретный пароль} Атрибуты: Пользователь вводит свой отклик, а NAS посылает новый запрос Access-Request с этим откликом и атрибутом State.
Request Authenticator = {Новое 16-октетное число} Атрибуты: User-Name = " MANYA" User-Password = {16 октетов отклика дополненного в конце нулями и объединенного функцией XOR с контрольной суммой MD5 общего секретного пароля и представленного выше аутентификатора запроса (Request Authenticator)} NAS-IP-Address = 192.168.1.16 NAS-Port = 7
Отклик был некорректен, поэтому сервер RADIUS предлагает NAS отклонить попытку входа в систему.
Response Authenticator = {16-октетов контрольной суммы MD-5 кода (3), ID (3), описанного выше Request Authenticator, атрибутов этого отклика (если таковые имеются) и общего секретного пароля} Атрибуты: (отсутствуют, хотя сообщение Reply-Message может быть послано) На практике, с сервером RADIUS связывается база данных, где хранятся имена пользователей и соответствующие им секретные пароли. Конкретный именованный пользователь должен аутентифицироваться только одним способом. Это уменьшает возможности атаки путем согласования использования наименее безопасного метода аутентификации. Если пользователь нуждается в использовании разных аутентификационных методов в различных ситуациях, тогда следует данному пользователю в каждом из этих вариантов выступать под разными именами. Пароли должны храниться в местах с ограниченным доступом. Эти данные должны быть доступны только процессам, которые с ними работают. Ссылки
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.3 Удаленный доступ (Telnet)
UP:
4.5 Процедуры Интернет
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.4 Протокол пересылки файлов FTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FTP довольно необычная процедура, так как поддерживает две логические связи между ЭВМ (Рис 4.5.4.1). Одна связь служит для удаленного доступа и использует протокол Telnet. Другая связь предназначена для обмена данными. Сервер производит операцию passive open для порта 21 и ждет соединения с клиентом. Клиент осуществляет операцию active open для порта 21. Канал остается активным до завершения процедуры FTP. TOS (тип IP-сервиса) соответствует минимуму задержки, так как этот канал используется для ручного ввода команд. Канал для передачи данных (TCP) формируется каждый раз для пересылки файлов. Канал открывается перед началом пересылки и закрывается по коду end_of_file (конец файла). IP-тип сервиса (TOS) в этом случае ориентирован на максимальную пропускную способность. Конечный пользователь взаимодействует с протокольным интерпретатором, в задачи которого входит управление обменом информацией между пользователем и файловой системой, как местной, так и удаленной. Схема взаимодействия различных частей Internet при работе FTP изображена на рис. 4.5.4.1. Сначала по запросу клиента формируется канал управления, который в дальнейшем используется для передачи команд от клиента и откликов от сервера. Информационный канал формируется сервером по команде клиента, он не должен существовать постоянно на протяжении всей FTP-сессии и может формироваться и ликвидироваться по мере необходимости. Канал управления может быть закрыт только после завершения информационного обмена. Для канала управления используется протокол Telnet. После того как управляющий канал сформирован, клиент может посылать по нему команды. Сервер воспринимает, интерпретирует эти команды и передает отклики.
Рис. 4.5.4.1 Схема работы протокола ftp. Возможна и другая схема взаимодействия, когда по инициативе клиента осуществляется файловый обмен между двумя ЭВМ, ни одна из которых не является машиной клиента (см. рис. 4.5.4.2).
Рис. 4.5.4.2. Организация информационного обмена между двумя удаленными машинами На фазе задания режима обмена предоставляются следующие возможности: Команда Block сохраняет структуру логических записей файла. Команда Stream устанавливает режим, при котором не производится пересылки контрольной информации для блоков. Это наиболее быстрый режим обмена, он работает по умолчанию. Команда TYPE может задать режимы обмена IMAGE, ASCII или EBCDIC. Из них ASCII - используется по умолчанию. Режим EBCDIC применяется для обменов между ЭВМ, работающими с набором символов EBCDIC. Режим IMAGE предполагает обмен 8-битными байтами, используется для передачи двоичной (а не текстовой) информации. Более подробный список команд помещен ниже. Структурно информация может передаваться в виде файлов (структура по умолчанию), в виде последовательности записей (применимо для текстовых файлов ASCII или EBCDIC) или постранично (последняя структура не относится к числу рекомендуемых). Для копирования файла из удаленного сервера используется команда GET, для копирования группы файлов - MGET, в последнем случае применяются символы заменители, например, MGET *.txt (или RFC-18*.txt, при этом скопируются файлы с RFC-1800.txt до RFC-1899.txt, если таковые существуют в текущем каталоге). Аналогом команды GET в какой-то степени является команда DIR (ls), только она переносит содержимое каталога, что для некоторых операционных систем эквивалентно. При использовании модификации mget проявляйте осторожность - вы можете заблокировать телекоммуникационный канал длительным копированием. Для записи файла в удаленный сервер применяется команда PUT. При операциях обмена обычно используется текущий каталог локальной ЭВМ. В вашем распоряжении всегда имеется возможность поменять местный каталог с помощью команды LCD или ее аналога. Любая команда обмена выполняется в несколько этапов:
Рассмотрим пример FTP-сессии. Для этого выдадим команду (тексты, набираемые с клавиатуры, выделены курсивом):
FTP Trying...Open FTP command: USER semenov
FTP response: 230 User semenov logged in.
Any unambiguous abbreviation for a command may be used. Available commands are:
version ftp:ns.itep.ru> quit Уход из FTP производится по команде quit. В приведенном примере файловый обмен не производился, но и команда HELP требует переноса информации (также как и dir), так как вам выдается список команд, доступных на удаленном сервере. Из воспроизведенного списка команд, самая опасная mdelete, так как способна стереть целый каталог. Нетекстовые файлы (архивированные, графические и программные) следует пересылать в режиме binary. Для перевода в этот режим используется одноименная команда. Для перехода из одного каталога в другой на удаленном сервере служит команда cd имя_каталога, а для возврата в предшествующий cd .. . Например, cd /pub/msdos. Ссылка на объект, доступный через анонимное FTP, обычно записывается в виде:
ftp://ftp.rpi.edu/pub/communications/internet-cmc.txt Internet-cmc (CMC - computer-mediated communication) -это межкомпьютерный обмен по сети Internet. Ниже приведен список базовых команд FTP. Следует разделять внутренний набор команд FTP, которыми обмениваются клиент и сервер по командному каналу, и набор команд доступный пользователю. Служебные команды содержат три или четыре заглавные буквы. Эти наборы команд перекрываются лишь частично. Служебные команды унифицированы (они выделены в приведенном выше примере FTP-сессии жирным шрифтом, в помещенной ниже таблице эти команды представлены в ее верхней части), пользовательский же набор команд может варьироваться от реализации к реализации. Если выдать команду FTP без аргументов, система обычно откликается приглашением FTP> и вы можете выполнить некоторые из приведенных ниже команд (весь набор становится доступным только после идентификации). Таблица 4.5.4.1
<SP> пробел; все команды завершаются последовательностью <CRLF> возврат каретки + перевод строки. В квадратных скобках записан опционный аргумент. Выполнение любой команды можно прервать с помощью Ctrl-C. Возможная форма обращения к FTP (SunOS 4.1): FTP [ -опции ] [ имя_ЭВМ ] Допустимы следующие опции (модификаторы) команды:
В рамках процедуры FTP доступны следующие команды (приведенный перечень команд является неполным):
В депозитариях можно встретить файлы следующих разновидностей (все виды ниже перечисленных файлов пересылаются в режиме binary, а не ASCII): Таблица 4.5.4.2
При выполнении FTP система возвращает трехразрядные десятичные коды-отклики, которые позволяют судить о корректности обмена и диагностировать процедуру. Выдача кода сопровождается текстом-комментарием. Первая цифра может принимать значения от 1 до 5. Структура кодов показана в таблице 4.5.4.3: Таблица 4.5.4.3. Коды диагностики
Значение кода "y" в вышеприведенной таблице может принимать значения от 0 до 5. Значения кодов "y" приведены ниже:
Далее в тексте встречается выражение "анонимное FTP", это подразумевает следующую процедуру (см. также RFC-1635): ftp> login: anonymous
Следует иметь в виду, что некоторые анонимные FTP-серверы (также как, например, GOPHER-серверы) требуют, чтобы ЭВМ, с которой осуществляется ввод, имела не только IP-адрес, но и зарегистрированное в локальном DNS-сервере имя. Эти FTP-серверы, получив запрос, пытаются выяснить имя ЭВМ, так как они ведут "журнал посещений", и в случае неуспеха прерывают сессию. Таким образом, анонимное FTP может считаться таковым лишь условно, в смысле ненужности быть авторизованным на сервере, чтобы иметь к нему доступ. Конкретные примеры кодов статуса обмена для FTP Таблица 4.5.4.4. Коды откликов
В настоящее время разработаны версии FTP для работы с IPv6 (RFC-2428). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS
UP:
4.5 Процедуры Интернет
|
|
|
|
4.5.4.1 Протокол TFTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
TFTP (Trivial FTP, RFC-1350, -783, RFC-906, STD0033) представляет собой упрощенную версию FTP. TFTP не имеет системы безопасности и идентификации, она в отличии от FTP базируется на протоколе UDP (порт 69), а не TCP. Обычно передача осуществляется блоками по 512 байт с ожиданием подтверждения приема каждого пакета (протокол "стой-и-жди"). TFTP используется при загрузке операционной системы в бездисковые рабочие станции (напр. X-терминалы, см. BOOTP) или для загрузки конфигурационных файлов в маршрутизатор. Возможно и непосредственное исполнение команды TFTP (TFTP имя_ЭВМ), хотя эта процедура и не дает каких-либо серьезных преимуществ перед FTP (кроме скорости обмена). При выполнении команды без параметров машина выдает приглашение TFTP> и вам предоставляется возможность выполнить определенные команды (ЭВМ SUN): connect имя_ЭВМ [ порт ] Задает имя ЭВМ, с которой будет осуществляться обмен, и, если это необходимо порт. Но реального соединения не производится, так как это не предусмотрено протоколом. mode модификация_обмена. В качестве модификаций обмена данными могут использоваться аргументы ASCII или BINARY. По умолчанию используется ASCII. put имя_файла Копирование файла или группы файлов в указанный файл или каталог. Здесь предполагается, что имя удаленной ЭВМ было указано ранее. Если же это не так, возможно одновременное указание имени удаленной ЭВМ и имя файла-адресата: имя_ЭВМ:имя_файла. Имя_ЭВМ становится именем по умолчанию для последующих обменов. Субкоманда GET имеет аналогичную форму обращения. Субкоманда trace позволяет отследить путь пакетов, а команда status сообщит текущее состояние системы. Уход из TFTP по команде exit или quit. Существует пять форматов пакетов tftp:
Рис. 68. Форматы TFTP-сообщений Операции запросов (RRQ и WRQ) требуют присылки пакета-отклика (ACK). Сначала устанавливается связь между клиентом и сервером, для этого посылаются запросы read или write. При этом сообщается имя файла и режим доступа (Mode). Предусмотрено три режима доступа, которые определяются значением поля MODE: NetASCII (американский стандарт для информационных обменов), побайтный (режим binary) и почтовый (данные поступают пользователю, а не заносятся в файл, при этом используется система кодов NetASCII). Предусмотрено шесть типов сообщений об ошибках: 0 - не определен; Если запросы read или write успешно выполнены, сервер использует IP-адрес и номер UDP-порта клиента для идентификации последующих операций. Таким образом, ни при пересылке данных, ни при передаче подтверждений (ACK) не нужно указывать явно имя файла. Блоки данных нумеруются, начиная с 1, подтверждение получения пакета имеет тот же номер. Получение блока с размером менее 512 байт означает конец файла. Получение сигнала об ошибке прерывает обмен. При возникновении тайм-аута производится повторная передача последнего блока данных или подтверждения. При задержке отклика, превышающей значение тайм-аута, возможно удвоение всех последующих блоков. Это происходит в некоторых реализациях программного обеспечения оттого, что из-за тайм-аута происходит повторная пересылка блока, а запоздавший отклик на блок i вызовет посылку блока i+1. Это будет продолжаться вплоть до конца пересылки файла. TFTP-протокол используется также и при реализации электронной почты (посылка файлов почтовой программе). Отсутствие авторизации делает доступность TFTP одной из угроз безопасности. Именно по этой причине во многих инструкциях вы можете найти рекомендацию запретить применение этой утилиты. |
|
Previous:
4.5.4 Протокол пересылки файлов FTP
UP:
4.5 Процедуры Интернет
|
|
|
|
4.5.5 Протокол X-Windows
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Система X-windows была разработана в Массачусетском Технологическом институте (сотрудники этого института внесли существенный вклад и в разработку всего комплекса TCP/IP-протоколов) в качестве многооконного программного интерфейса для ЭВМ с побитовым отображением графической информации. Система предполагала отображение результатов работы нескольких программ одновременно. Сегодня это одна из наиболее популярных систем. Для каждой программы выделялась отдельная область на экране - "окно". С самого начала система предназначалась для работы в различных сетях (TCP, IPX/SPX и т.д.). Система может управлять окнами как на локальной, так и удаленной ЭВМ. Для управления окнами используются специальные сообщения. Для обмена этими сообщениями разработан x-windows протокол. Система X-windows состоит из двух частей Xlib и X-сервера (RFC-1198).
Рис. 4.5.5.1. Схема взаимодействия различных частей X-windows xlib является интерфейсом для любого прикладного процесса и обычно представляет собой программу, написанную на C. Xlib отвечает за обмен информацией между сервером и терминалом пользователя (X-клиент). Под приложениями здесь подразумеваются независимые процессы. Для каждого терминала инсталлируется отдельный X-сервер. Один X-сервер может обслуживать несколько клиентов. X-сервер осуществляет отображение на экране всех окон, в то время как функция клиентов - управление окнами. Для управления окнами используются структуры типа стеков. Прикладная программа-клиент и сервер взаимодействуют друг с другом через системный протокол X-windows (RFC-1013 и RFC-1198). При этом используется четыре вида сообщений:
Форматы таких сообщений представлены на рис. 4.5.5.2.
Рис. 4.5.5.2 Форматы сообщений об ошибках Некоторые X-запросы не нуждаются в откликах (например, связанные с перемещением манипулятора мышь), такие сообщения могут группироваться и посылаться единым потоком (batch stream). Такой подход позволяет пользователю выдать Xlib-запрос и перейти к выполнению других операций, в то время как схема запрос-отклик требует ожидания. Сообщение типа событие посылается прикладной программе только в случае, если она запрашивала такого рода информацию. X-Windows приложения должны установить канал связи между собой, прежде чем они смогут обмениваться сообщениями. Приложение для того, чтобы установить связь с рабочей станцией использует запрос XOpenDisplay из библиотеки Xlib. Xlib формирует структуру дисплея, которая содержит необходимую информацию, определяющую режим обмена прикладная программа <-> рабочая станция. После того как связь установлена прикладная программа и рабочая станция готовы к работе. Если была нажата клавиша мышки (событие - ButtonPress), а не известно, в каком из окон находится ее указатель, прикладная программа выдает в Xlib запрос XQueryPointer. Положение указателя будет прислано в отклике на этот запрос. Данный протокол, строго говоря, не входит в набор TCP/IP хотя, как было сказано, он описан в RFC. Но мне представлялось важным дать в руки операторов сетей информацию, которая позволит им лучше понимать, что "гуляет" по их кабельным сегментам. |
|
Previous:
4.5.4.1 Протокол TFTP
UP:
4.5 Процедуры Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.6 WWW
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Определения и понятия Прежде чем передать что-то, надо это иметь. Люди общаются, используя естественные языки, ЭВМ обмениваются нуликами и единицами. Но даже в привычном для всех нас общении на родном языке иногда возникают проблемы, и тогда мы переспрашиваем партнера (это прием используют и коммуникационные системы). Когда же мы читаем, перед нами возникает последовательность символов из хорошо известного с детства алфавита. Символы эти могут существенно варьироваться по форме своего изображения, но мы их все равно без труда распознаем. Получаемая нами информация поступает не только от общения с людьми, книгами или телевизором. Не мало крайне важных для жизни данных мы получаем о себе и окружающем мире по имеющимся у нас каналам органов чувств. Мы научились сопоставлять и перепроверять эти данные, когда это требуется. Успешное функционирование этих каналов передачи данных и средств их обработки позволяет нам прожить относительно долгую жизнь. Любые же сбои могут повлиять на нашу судьбу самым драматическим образом. Человечество научилось усовершенствовать данные нам природой каналы информационного обмена. Сначала это были примитивные сигнальные системы типа костров на вершинах холмов (пропускная способность 0,5 бит/час). Появление письменности открыло возможность общения уже умерших людей с живыми, обеспечив процесс накопления знаний. Довольно большие объемы информации могли уже передаваться с использованием лошадей и кораблей на практически неограниченные расстояния. Но скорость такого обмена была ничтожна, доставка сообщения занимала часы, дни, а иногда и годы (никакого намека на работу современной почты я здесь не делаю). Гигантским шагом вперед стало изобретение электрического телеграфа, а позднее радио. Сегодня же мы узнаем о землетрясении в 20000 км от нас максимум через час из очередного телевизионного сборника новостей. Люди объясняются в любви с использованием электронной почты и делают покупки, не выходя из дома. На нас обрушилась лавина информации. Диабетик узнает о прелестях сникерса, мужчины маются, слушая информацию о потрясающих особенностях прокладок с крылышками, о несмываемой губной помаде и т.д. и т.д. Мы стали получать слишком много совершенно ненужной информации. Миллионером станет человек, который предложит покупателям телевизор, отфильтровывающий информацию согласно требованиям зрителя. Таким образом, мы уже сталкиваемся с новыми информационными проблемами, хотя нельзя сказать, что мы решили все старые. Сплошь и рядом мы узнаем слишком поздно о своих болезнях, об угрозах стихийных бедствий или об истинных свойствах того или иного политика. Эти же проблемы относятся и к Интернет. По электронной почте вы получаете сообщения от совершенно незнакомых людей, которые утверждают, что очень хотят вашего быстрого обогащения (хотя их цели диаметрально противоположны), или предлагающих вам какие-то товары или услуги, хотя вы их об этом не просили. К Интернет получили доступ десятки миллионов людей. Если в издательствах редакторы, заботясь о доходах и избегая убытков, блокируют доступ графоманов к широким массам читателей, такого механизма в Интернет не существует. Таким образом, программные средства, фильтрующие поток данных на входе вашего почтового или web-сервера, здесь также весьма актуальны. Ниже даются некоторые определения понятий, используемых в разделах о протоколе http, www и информационном поиске. Рассмотрим некоторые свойства информации, например структурированность и ценность. Структурированность - это свойство, которое позволяет принимающей стороне выделить информацию в виде некоторого сигнала, обладающего некоторыми свойствами. Ценность данных выражается через содержательность, полноту, оперативность и достоверность. При обработке и передаче данных важную роль играют знаки и знаковые системы. Знак - это материальный объект, который служит для обозначения другого объекта и используется для передачи информации о последнем. Примерами знаков могут служить ноты, цифры, жесты азбуки глухонемых, знаки регулирования уличного движения и т.д. Одной из разновидностей знака является символ. Разновидностью знаковых систем являются языки, самым сложным из которых является естественный человеческий язык. Все проявления и применения знаков и знаковых систем изучает семиотика. Предметом семиотики является связь знаков друг с другом, с обозначаемыми ими объектами и явлениями, а также с субъектами их использующими для целей коммуникаций. Семиотика содержит в себе три раздела: семантика, синтактика и прагматика. Семантика изучает отношения между знаком и тем, что он обозначает или замещает. Синтактика знаковых систем изучает их структуру и правила соединения знаков.Прагматика изучает законы функционирования знаковой системы, как средства коммуникации субъектов. С прагматикой связаны такие понятия как ценность и цель. World Wide Web (всемирная сеть, WWW или 3W) представляет собой информационную систему, базирующуюся на использовании гипертекста. Разработка этой системы была начата Тимом Бернерс-Ли, которому в 1989 году пришла в голову мысль объединить гипертекст с Интернет. Идея впервые реализована в ЦЕРН (Женева). Доступ к WWW возможен только в рамках протоколов TCP/IP, но для использования 3w необязательно иметь сервер-клиент (browser) на вашей машине. С некоторыми ограничениями возможен доступ и через электронную почту (listserv@info.cern.ch). Если WWW-клиент-сервер не установлен, можно работать в режиме удаленного терминала. Весьма удобным программным интерфейсом для WWW является ms explorer, netscape и некоторые другие. Для подготовки документов в рамках HTML (Hypertext Markup Language) пригоден любой текстовый редактор (например, emacs в UNIX-машинах, ME в MS-DOS или Winword, в последних версиях которого уже допускаются гиперссылки). При подготовке гипертекстов вы можете использовать язык HTML или взять одно из множества доступных программных средств, которые позволяют преобразовать ваш документ в необходимый формат. Документы в гипертексте связываются друг с другом определенным набором слов. Пользователю не нужно знать, где находится тот или иной документ. Часто ссылки на серверы WWW начинаются с сокращения http:// (Hypertext Transfer Protocol). Гипертекст позволяет осуществлять ссылки-разъяснения на статьи, хранящиеся на удаленном сервере. Гипертекст подразумевает не только текстовые объекты (но и графические или звуковые), поэтому термин гиперсреда (hypermedia) более правилен. WWW может проводить поиск ключевых слов и в специфических документах-индексах, в этом случае выдаются указатели на искомые документы. WWW может использовать различные форматы документов и работать с разнообразными структурами информации, обеспечивая доступ к информационной вселенной. На рис. 4.5.6.1 показан рост числа WEB-серверов, базирующихся на разных программных продуктах (www.netcraft.com). В 2000 году скорость регистрации web-серверов достигла 1 в секунду.
Рис. 4.5.6.1. Рост числа web-серверов в период 1995-99 годов На февраль 1999 года число www-серверов равнялось 4.301.512. Что же такое гипертекст? Прежде всего, следует отметить, что гипертекст - это текст, состоящий из ascii-символов. Для обеспечения верстки и организации перекрестных ссылок в гипертексте используются слова-метки. Основу гипертекста составляют HTML-элементы. Такой элемент включает в себя имя, атрибуты, текст или гипертекст. HTML-элемент записывается в документ в виде (более подробное описание смотри в статье о html): <имя_метки> текст </имя_метки> html-документ состоит из одного элемента: <html> .... </html>, который состоит из html-элементов: <head> ... </head> и <body> ... </body>, последние в свою очередь могут содержать различные списки, внутренние и внешние метки и т.д.. Элементы <html>, <head> и <body> для совместимости с более старыми текстами сделаны пока необязательными. В html имеется 6 уровней заголовков (<h1>, .... <h6>), из них первый - главный. В версии HTML+ (и более поздних версиях) предусмотрены операторы позиционирования текста, например, <p align="center">. head-элементы могут содержать в себе: <isindex> говорит о том, что данный документ допускает индексный поиск (база данных). <title> . . . </title> описывает заголовок документа, этот заголовок характеризует содержимое окна. <base href="url"> сообщает имя файла, в котором хранится данный документ. <link rev="relationship" rel="relationship" href="url"> этот элемент позволяет установить связь между документом, содержащим метку (якорь), и документом, указанным в URL (Uniform Resource Locator). Атрибут rel устанавливает связь между HTML-файлом и URL. Атрибут rev (reverse) описывает взаимоотношения между URL и HTML-файлом. Элементы body могут содержать элементы: Текстовые элементы: <p> индицирует конец параграфа и начало нового. <pre> . . . </pre> выделяет текст, который уже был сформатирован ранее (таблицы, программы, стихи, ...). <blockquote> . . . </blockquote> ограничивает часть текста, который должен быть выделен кавычками. Гиперсвязи или якоря <a name="anchor_name"> . . . </a> определяет заданную позицию в документе. <a href="#anchor_name"> . . . </a> описывает ссылку на определенное место текущего документа. <a href="url"> . . . </a> устанавливает связь с другим файлом или ресурсом. <a href="url#anchor_name"> . . . </a> устанавливает связь с заданным местом в другом документе. <a href="url?search_word+search_word"> . . . </a> посылает серверу эталонную строку для поиска. Различные системы поиска могут интерпретировать эту строку по-разному. Для того чтобы читатель незнакомый с гипертекстом, получил некоторое представление о том, как он выглядит, приведу пример: <title> Протоколы и ресурсы Интернет </title> Вам уже ясно, что подготовка гипертекстов "вручную" изнурительная задача и вспомогательные программные средства не повредят, особенно если вы хотите, чтобы ваш текст выглядел привлекательно. Заметим, что управляющие слова-метки могут записываться как строчными, так и прописными буквами (<H1> = <H1>), но они могут восприниматься различными программами просмотра по-разному (могут и игнорироваться вовсе). HTML поддерживает нумерованные (OL), ненумерованные (UL), и описательные списки (DL). Пример нумерованного списка:
<ol>
</ol> Примером описательного списка может служить: <dl> На экране это будет выглядеть примерно так: ИТЭФ Институт Теоретической и Экспериментальной Физики, Москва. ИФВЭ Институт Физики Высоких Энергий, Протвино. <dt> - метка определения, а <dd> - метка данных описания. Как <dt> так и <dd> могут содержать много параграфов, разделенных меткой <p>. Допускается вложение списков друг в друга, например <fsu.html>: <ul> Некоторые символы являются служебными для html и для их отображения на экране требуются определенные ухищрения. Например:
Символ ; (точка с запятой) является составной частью описания. Все предшествующее относилось к описанию представления текстов на экране. Теперь рассмотрим, как можно обозначить смысловые связи и ссылки друг на друга различных частей текста. Собственно именно ради этого и создавалась идеология гипертекстов. Метка, означающая наличие связи, имеет вид <a> и происходит от слова anchor (якорь). В общем виде ссылка имеет следующий формат: <a href="url"> текст </a> URL (universal resource locator) в простейшем случае может быть именем файла. Текст обозначает действительный текст в документе, который может быть подсвечен, выделен другим цветом или помечен цифрой. Этот текст говорит программе просмотра, что в URL можно найти связанную с данным документом информацию или изображение. При использовании программы типа MS IE (или Netscape) для вызова этой информации или изображения на экран достаточно указать мышкой на текст и нажать кнопку. Если URL указывает на объект, находящийся не в вашей сети эта процедура может занять некоторое время. Чтобы вас как-то развлечь, программа показывает вам вращающийся земной шар в верхнем правом углу экрана. Метка <A> может использоваться и для ссылки на определенный раздел документа: <a name="refname"> текст </a>, где refname является меткой в вашем документе. Пусть в файле fsu.html определена следующая ссылка-якорь: <a name="итэф"> ИТЭФ </a> тогда, находясь в пределах этого документа, можно попасть в нужную точку с помощью: <a href=#итэф> У-10 </a> протонный синхротрон. В другом документе может присутствовать встречная ссылка, например: У-10 в <a href="fsu.html#итэф"> ИТЭФ>/a> Теперь, при нажатии кнопки мышки на слове ИТЭФ, программа отобразит fsu.html и отметит позицию со словом ИТЭФ (ссылка name=итэф). Вообще говоря, вы можете ссылаться на метки-якоря в файлах, находящихся на другой машине (на другом конце земли :-) ), приводя полное наименование URL. В общем случае url указывает тип и место расположения ресурса: сервер://host.domain[:port]/path/объект, где в качестве сервера может стоять: FTP, Telnet, HTTP, Gopher, Wais, News. Path описывает проход к каталогу, где лежит объект. Если программа просмотра (Netscape) способна воспроизводить изображения, можно ввести ссылки на файлы, содержащие нужные для пояснения текста картинки, например: <img src="имя_файла.gif"> Обратите внимание, что здесь используется графический стандарт gif (Graphics Interchange Format). Приемлемы также графические форматы tiff, jpeg, rgb и hdf. Читатели, желающие сформировать титульную страницу (home page) своего института, фирмы или проекта, должны изучить предмет более углубленно, обратившись, например по адресу: http://info.cern.ch/hypertext/www/provider/overview.html. После этого недолгого экскурса в гипертекст, который является основой многих поисковых систем, вернемся к проблематике www. Следует заметить, что публично доступные клиент-серверы существуют для сред MS-DOS, VMS, MVS, UNIX, X-windows, Macintosh, NEXT. Это математическое обеспечение доступно через анонимный FTP из депозитария info.cern.ch секции /pub/www (или www.earn.net gnrt/www.html). Графические клиент-серверы доступны для UNIX, Windows, Macintosh, X-windows, Next. Режим удаленного терминала можно реализовать через telnet по адресу info.cern.ch (при этом не требуется иметь авторизацию на какой-либо ЭВМ ЦЕРН). Многие серверы при старте выходят на приглашение login. Обычно для входа в WWW при этом достаточно напечатать WWW. Никакого слова-пропуска не требуется. Программный пакет PCTCP (и некоторые другие) допускает настройку на эмуляцию того или иного терминала, например: tn -x vt100 info.cern.ch, где info.cern.ch - адрес WWW-сервера, который предполагает работу с терминалом VT-100 (или его эмулятором). При работе в строчном режиме (режим меню) вам предлагается возможность выбора одного из пунктов меню. Для этого вы печатаете номер этого пункта и нажимаете клавишу <enter>. Если все меню на экране не помещается, вы можете перемещаться по нему в любом направлении. Пояснения, содержащиеся на экране, позволяют работать c системой даже новичку. WWW-сервер в простом варианте выполняет лишь команды get имя_файла, приходящие от клиент-сервера пользователя. Остальная работа выполняется www-клиентом. Существует достаточно много "удаленных" тематических серверов, например:
Список этот не является исчерпывающим, существуют клиент-серверы и в России. Появились и первые зеркальные www-депозитарии в России (например, xxx.itep.ru ("зеркало" сервера LANL - Лос-Аламос, США), store.in.ru (зеркальный сервер по Linux - Red Hat и RFC) и т.д.. Хотя в вышеприведенной таблице указана тематика серверов, не следует думать, что этим ограничивается содержимое депозитариев. ЦЕРН является базовой организацией для справочных запросов (здесь работают многие авторы этой системы, www-bug@info.cern.ch). Для получения нужного файла по электронной почте следует послать mail по адресу listserv@info.cern.ch с командой send. Команда send присылает документ с данным www-адресом. Но следует иметь в виду ряд ограничений. Гипертекстные документы имеют стандартную ширину в 72 символа. В конце документа обычно имеется список других адресов документов по данной или близкой тематике. Гипертекстный документ имеет связи, которые помещаются в квадратные скобки. Обратите внимание на то, что, несмотря на наличие имени listserv в начале, - это не listserv-сервер. Максимальное число строк, получаемое пользователем, при этом не превышает 1000 (хотя сегодня найдется немного желающих пользоваться такой услугой, если имеется прямой доступ в Интернет). Все запросы мониторируются. При работе с графикой выбор того или иного объекта производится мышкой. Работая со строчным сервером, следует набрать номер строки меню и нажать клавишу <enter>. В WWW доступны некоторые команды (параметры команд помещаются в угловые скобки <>, в квадратных скобках приведены сокращенные названия команд для построчного просмотра; используется полное или сокращенное имя команды.):
Стандартная форма обращения к www имеет вид: www <option> <docaddress <ключевое слово>>, где docaddress - гипертекстный адрес документа, который вы хотите просмотреть; а ключевое слово - объект поиска в индексе, предоставляемом docaddress. По умолчанию на экран вызывается первый документ. В нижней части экрана отображается строка выполнимых команд. Команды могут набираться как строчными, так и заглавными буквами. Имеются следующие возможности (опции):
Для перехода к следующей странице достаточно нажать клавишу <enter>. Ниже приведен пример меню World Wide Web (в настоящее время данный вид доступа представляет скорее исторический интерес): the world-wide web virtual library: subject catalogue this is a distributed subject catalogue. see also arrangement by service type [1], and other
subject catalogues of network information [2]. Цифры в квадратных скобках представляют собой пункты меню. Для выбора одного из них достаточно напечатать его номер (после двоеточия) и нажать клавишу <enter>. Поиск возможен только в случае, когда в меню в нижней части экрана присутствует слово find. Рассмотренная выше версия является устаревшей, но она дает представление о том как работает WEB-сервер. URL (uniform resource locator) идентифицирует ресурс Internet. В общем виде URL имеет вид: access://host/path где access = {FTP, Gopher, Telnet, ...}; host = имя ЭВМ-сервера; path = имя файла, имя каталога, или другая информация о ресурсе. Например, url для анонимного FTP: ftp.rpi.edu/pub/communications/internet-cmc.txt означает:
Если вы не имеете WWW-клиент-сервера типа NetScape (где можно задать HTTP ресурс, который вы хотите получить), HTTP-ресурс может стать доступным для вас через электронную почту. Пошлите через e-mail запрос по адресу listserv@info.cern.ch с текстом в теле сообщения (вариант сегодня достаточно архаичный): www URL и вы получите welcome.html страницу по электронной почте. Вы можете получить доступ к HTTP-документам с помощью telnet. Команда: telnet info.cern.ch вызовет базовую страницу WWW в ЦЕРН. Для того чтобы достичь нужного URL, введите команду: go http://cnidr.org/welcome.html В ЦЕРН WWW-команду возглавляет Tim Berners-Lee. Обнаруженные ошибки или предложения шлите по адресу www-bug@info.cern.ch. Почтовый подписной лист: www-talk@info.cern.ch. Для подписки пошлите запрос по адресу: www-talk-request@info.cern.ch. В ЦЕРН работа WWW успешно дополняется другими информационными системами, например, библиотечной системой ALICE. Группа новостей в USENET: comp.infosystem.www. Особенности гипертекста с его межуровневыми связями приводят к циклам при просмотре меню (возврат осуществляется по тому же маршруту, по какому вы пришли в данную точку). Это снижает эффективность поиска. Отчасти эти недостатки устранены в графическом интерфейсе NetScape. Графические интерфейсы требуют большой пропускной способности от информационных каналов (желательно > 64 Кб/с). Именно NetScape и MS Explorer стали наиболее популярными интерфейсами поисковых информационных систем и источником наибольших загрузок в телекоммуникационных каналах. Этот интерфейс наиболее естественно позволяет работать и с графическими объектами. Публично доступны версии NetScape для Windows, Unix и т.д. Если у вас уже работает WWW-сервер, нет необходимости заводить серверы GOPHER, Archie или WAIS - их услуги обычно доступны через WWW. Сейчас существует несколько разновидностей программ-надстроек типа NetScape, например MS Explorer, LYNX и некоторые другие. Сегодня трудно найти какую-либо фирму, организацию или общественную группу, не представленную в Интернет своей Web-страницей. Эта технология широко используется в сфере рекламы и даже продажи товаров. Следствием этого стала актуальность проблем безопасности для Web-серверов. Большинство этих проблем происходят от несовершенства программ. Несмотря на общеизвестный совет не использовать программы версии 1.0, ошибки и "дыры" встречаются и в более поздних версиях (например, в Apache V.1.1.1 или Netscape Navigator 2.0, MS Internet Explorer 3.0 и т.д.). Хотя функция Web-сервера принципиально проста: найти запрошенный URL и послать его заказчику, реально практически все существующие сервера "обросли" конфигурационными опциями, интерфейсами для различных баз данных, снабжены адаптерами для разных версий HTTP и HTML, скриптами и модулями API. В результате исполняемый модуль WWW-сервера в несколько раз больше, чем для FTP-сервера, что оставляет достаточно пространства для ошибок и возможностей для реализации хакерских замыслов. 4.5.6.1 Программное обеспечение WEB Существует достаточно широкий список программного обеспечения для формирования WEB-сервера. Структура и конфигурация этих серверов варьируется в широких пределах, но есть у них и немало общего. Рассмотрим основные каталоги, которые возникают при установке WEB-сервера. Каталог конфигурации. Здесь содержатся файлы, которые определяют рабочие характеристики сервера. Этот каталог жизненно важен, и необходимо максимально возможно ограничить круг лиц, которым разрешено изменять здесь что-либо. Инструментальный каталог администратора. Этот каталог содержит утилиты, которыми пользуется администратор сервера. Здесь могут располагаться программы управления доступом, генерации криптографических ключей и формирования поисковых индексов. Каталог файла регистрации операций (LOG-файла). Здесь фиксируются все процедуры доступа к серверу, а также все происходящие сбои и ошибки. Каталог CGI. В этом каталоге располагаются CGI-скрипты, которые используются для формирования документов с динамически изменяющимся содержимым, для организации доступа к базам данных и выполнения интерактивных задач. Здесь же могут находиться средства, которые позволяют администратору-программисту добавлять свои собственные функции сервера, расширяя его возможности. Каталог документов (корневой каталог документов). Этот каталог составляет основу иерархического дерева каталогов документов сервера. Каталог может включать субкаталоги типа html, java, icons и т.д. Помимо перечисленных может присутствовать каталог security, где лежат параметры доступа (имена и пароли) авторизованных клиентов сервера. Современные WEB-серверы трудно себе представить без CGI-скриптов (Common Gateway Interface). Эти скрипты позволяют существенно расширить возможности сервера, обеспечить доступ к базам данных, работать с документами, содержимое которых изменяется динамически, организовать игры в реальном масштабе времени, обрабатывать запросы клиентов, посылать сообщения по электронной почте и многое другое. CGI-скрипты обеспечивают интерфейс между WEB-сервером и серверами GOPHER или FTP. Привлекательность CGI-скриптов и легкость их написания, к сожалению, дополняется тем, что совсем не просто написать их безошибочно. CGI-скрипты (ISO 9636) представляют собой небольшие программы, которые являются независимыми от основной программы сервера. Когда удаленный пользователь запрашивает URL, который указывает на CGI-скрипт, сервер исполняет скрипт, передавая информацию о состоянии сессии. CGI-скрипт обрабатывает эти данные и выдает документ, который, вообще говоря, может быть и не только HTML-страницей. Среди информации, которую передает сервер CGI-скрипту, обычно присутствует строка запроса, содержащая данные, которые поступили от удаленного пользователя. Форма строки запроса произвольна. Она может содержать ключевые слова для поиска или SQL-предложение для обращения к серверу базы данных. Строка запроса может быть передана CGI-скрипту двумя способами. В первом случае она прикрепляется к URL. Например: http://www.altavista.com/cgi-bin/query?pg=q&what=web&fmt=.&q=question Все, что следует после знака вопроса, представляет собой строку запроса. В этой версии строка запроса должна следовать требованиям записи URL, т.е. пробелы должны заменяться символом + (ключевым словом в приведенном запросе является question). CGI-скрипт извлекает строку запроса с учетом переменной конфигурации (environment). Альтернативой этому является посылка строки запроса CGI методом HTTP POST. Этот метод обычно используется при заполнении пользователем форм и отправке их удаленному серверу. В этом случае WEB-сервер направляет строку запроса непосредственно на стандартный вход скрипта. Желательно пользоваться хорошо проверенными скриптами, а при написании новых следить за тем, чтобы они ни при каких обстоятельствах не допускали исполнения команд на машине сервера и не производили несанкционированной модификации файлов. Пользователи WEB сервера, которые имеют доступ к документам и файлам поддержки обычно делятся на четыре категории: хозяин, автор, разработчик и администратор. Каждая их этих категорий имеет разные права доступа, показанные в таблице 4.5.6.1. Таблица 4.5.6.1. Возможности различных категорий пользователей WEB-сервера
R - разрешено чтение. W - разрешена запись и уничтожение. Хозяином в данном случае считается администратор узла, где размещен WEB-сервер. Автор занимается подготовкой документов и рисунков. Разработчик имеет сходные функции с автором, но в его обязанности входит также разработка и модификация CGI-скриптов и модулей сервера. Клиент (посетитель) может запускать скрипты и читать любые документы. Приведенная иерархия возможностей для пользователей гарантирует устойчивую работу и безопасность WEB-сервера. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.5 Протокол X-Windows
UP:
4.5 Процедуры Интернет
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.6.1 Гипертекстный протокол HTTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Протокол передачи гипертекста HTTP является протоколом прикладного уровня для распределенных мультимедийных информационных систем. Это объектно-ориентированный протокол, пригодный для решения многих задач, таких как создание серверов имен, распределенных объектно-ориентированных управляющих систем и др.. Структура HTTP позволяет создавать системы, независящие от передаваемой информации. Протокол HTTP использован при построении глобальной информационной системы World-Wide Web (начиная с 1990). Первые версии, такие как HTTP/0.9, представляли собой простые протоколы для передачи данных через Интернет. Версия HTTP/1.0, описанная в RFC-1945 [6], улучшила протокол, разрешив использование сообщений в формате MIME, содержащих метаинформацию о передаваемых данных, и модификаторы для запросов/откликов. Дальнейшее развитие сетей WWW-серверов потребовало новых усовершенствований, которые вряд ли являются последними. Реальные информационные системы требуют больших возможностей, чем простой поиск и доставка данных. Для описания характера, наименования и места расположения информационных ресурсов введены: универсальный идентификатор ресурса URI (Uniform Resource Identifier), универсальный указатель ресурса URL и универсальное имя ресурса URN. Формат сообщений сходен с используемыми в электронной почте и описанный в стандарте MIME (Multipurpose Internet Mail Extensions). HTTP используется также в качестве базового протокола для коммуникации пользовательских агентов с прокси-серверами и другими системами Интернет, в том числе и использующие протоколы SMTP, NNTP, FTP, Gopher и Wais. Последнее обстоятельство способствует интегрированию различных служб Интернет. Ниже описаны базовые понятия и термины протокола HTTP. Прокси Промежуточная программа, которая выполняет функции, как сервера, так и клиента. Такая программа предназначена для обслуживания запросов так, как если бы это делал первичный сервер. Запросы обслуживаются внутри или переадресуются другим серверам. Туннель Промежуточная программа, которая работает как ретранслятор между двумя объектами. Туннель закрывается, когда обе стороны, соединенные им прерывают сессию. Туннель может быть активирован с помощью HTTP-запроса. Время пригодности объекта (expiration time) Время, при котором исходный сервер требует, чтобы объект не посылался более кэшем без перепроверки пригодности. Эвристическое значение времени жизни (heuristic expiration time) Время пригодности, присваиваемое объекту в кэше, если это время не задано явно. Возраст Возраст отклика - время с момента его посылки или проверки его пригодности исходным сервером. Время жизни (freshness lifetime) Продолжительность времени с момента генерации отклика до истечения его пригодности. Свежий Отклик считается свежим, если его возраст не превысил времени его пригодности. Устаревший Отклик считается устаревшим, когда его возраст превысил время жизни. Семантическая прозрачность Кэш по отношению к конкретному отклику функционирует в "семантически прозрачном" режиме, когда его использование не имеет последствий ни для исходного сервера, ни для запрашивающего клиента. Когда кэш семантически прозрачен, клиент получает в точности тот же отклик (за исключением транспортных заголовков), какой он бы получил при непосредственном обращении к исходному серверу. Валидатор Протокольный элемент (например, метка объекта или время last-modified), который используется для выяснения того, является ли запись в кэше эквивалентной копией объекта. Метод Процедура, выполняемая над ресурсом (get, put, head, post, delete, trace и т.д.).
Рис. 4.5.6.1.1. Взаимодействие клиента, кэша и исходного сервера в протоколе HTTP Кэш может находиться в ЭВМ клиента или агента пользователя, но может размещаться на соседнем континенте. Число прокси между клиентом и исходным сервером может варьироваться и ограничивается сверху только здравым смыслом.
Рис. 4.5.6.1.2. Структура ресурса и объекта Протокол HTTP представляет собой протокол запросов-откликов. Клиент посылает запрос серверу в форме, определяющей метод, URI и версию протокола. В конце запроса следует MIME-подобное сообщение, содержащее модификаторы, информацию о клиенте и, возможно, другие данные. Сервер откликается, посылая статусную строку, которая включает в себя версию протокола, код результата (успех/неудача) и MIME-подобное сообщение, в котором содержатся данные о сервере и метаинформация. Большинство HTTP-обменов инициируются пользователем и состоят из запросов ресурсов, имеющихся на определенном сервере. В простейшем случае такой запрос может быть реализован путем соединения пользовательского агента (UA) и базового сервера. Более сложная ситуация возникает, когда присутствует один или более посредников в цепочке обслуживания запроса/отклика. Существует три стандартные формы посредников: прокси, туннель и внешний порт (gateway). Прокси представляет собой агент переадресации, получающий запрос для URI, переписывающий все сообщение или его часть и отправляющий переделанный запрос серверу, указанному URI. Внешний порт (gateway) представляет собой приемник, который работает на уровень выше некоторых других серверов и транслирует, если необходимо, запрос нижележащему протоколу сервера. Туннель действует как соединитель точка-точка и не производит каких-либо видоизменений сообщений. Туннель используется тогда, когда нужно пройти через какую-то систему (например, Firewall) в условиях, когда эта система не понимает (не анализирует) содержимое сообщений.
Запрос --------------------------------------> Рис. 4.5.6.1.3. UA - агент пользователя На рисунке показаны три промежуточные ступени (A, B, и C) между агентом пользователя (UA) и базовым сервером (O). Запрос или отклик, двигаясь по этой цепочке, должен пройти четыре различных соединительных сегмента. Это обстоятельство крайне важно, так как некоторые опции HTTP применимы только для ближайших соединений. Хотя схема линейна, на практике узлы могут участвовать в большом числе других взаимодействий. Например, B может получать запросы от большого числа клиентов помимо A, и переадресовывать запросы к другим серверам кроме C. Любой участник обмена, который не используется в качестве туннеля, может воспользоваться кэшем для запоминания запросов. Буфер может сократить длину цепочки в том случае, если у одного из участников процесса имеется в буфере отклик для конкретного запроса, что может, кроме прочего, заметно снизить требования к пропускной способности канала. Не все запросы могут записываться в кэш, некоторые из них могут содержать модификаторы работы с кэшем. В действительности имеется широкое разнообразие архитектур и конфигураций буферных запоминающих устройств и прокси, разрабатываемых в настоящее время или уже доступных через World Wide Web. Эти системы включают иерархии прокси-серверов национального масштаба, задачей которых является сокращение трансокеанского трафика, системы, которые обслуживают широковещательные и мультикастинговые обмены, организации, распространяющие фрагменты информации с CD-ROM, занесенной в кэши и т. д.. HTTP-системы, используются в корпоративных сетях Интранет с большими пропускными способностями и перемежающимися соединениями. Целью HTTP/1.1 является поддержка широкого разнообразия уже существующих систем и расширение возможностей будущих приложений в отношении надежности и адаптируемости. Коммуникации HTTP обычно реализуются через соединения TCP/IP. Порт по умолчанию имеет номер 80, но и другие номера портов вполне допустимы. Это не исключает использования HTTP поверх любого другого протокола в Интернет, или других сетей. HTTP предполагает надежное соединение; применим любой протокол, который может гарантировать корректную доставку сообщений. В HTTP/1.0, большинство приложений используют новое соединение для каждого обмена запрос/отклик. В HTTP/1.1, соединение может быть использовано для одного или более обменов запрос/отклик, хотя соединение может быть разорвано по самым разным причинам.
4.5.6.1.1. Соглашения по нотации и общая грамматика
Все механизмы, специфицированные в данном документе, описаны с использованием обычного текста и расширенных форм Бахуса-Наура BNF (Backus-Naur Form; см. RFC 822). Пользователи должны быть знакомы с этой нотацией для понимания данной спецификации. Расширение BNF включает в себя следующие конструкции: name = definition Имя правила не требует помещения в угловые скобки. Некоторые базовые правила записываются прописными буквами, например, SP, LWS, HT, CRLF, DIGIT, ALPHA и пр. "literal" Двойные кавычки используются для выделения символьного текста. rule1 | rule2 Элементы, разделенные вертикальной чертой, ("|") являются альтернативными, например, "yes | no" допускает yes или no (да или нет). (rule1 rule2) Элементы, помещенные в круглые скобки, рассматриваются как один элемент. Так, "(elem (foo | bar) elem)" допускают последовательности "elem foo elem" и "elem bar elem". *rule Символ "*", предшествующий элементу, указывает на повторение. Полная форма " [rule] В квадратные скобки заключаются опционные элементы; "[foo bar]" эквивалентно "*1(foo bar)". N rule Специальный повтор: " #rule Конструкция "#" определена подобно "*", для описания списка
элементов. Полная форма имеет вид " ; комментарий Точка с запятой, смещенная вправо от линейки текста, открывает комментарий, который продолжается до конца строки. Это простой способ включения замечаний в текст спецификаций. implied *LWS Грамматика, описанная в данной спецификации, ориентирована на слова. Если не оговорено обратное, строчный пробел (LWS) может быть заключен между любыми двумя соседними словами (лексема или заключенная в кавычки строка), и между смежными лексемами (token) и разделителями (TSpecials) без изменения интерпретации поля. По крайней мере один разграничитель (TSpecials) должен присутствовать между любыми двумя лексемами, так как они иначе будут интерпретироваться как одна. Следующие правила используются практически во всей спецификации для описания основных конструкций разбора (парсинга).
HTTP/1.1 определяет последовательность CR LF, как маркер конца для всех протокольных элементов, за исключением тела элемента. Маркер конца строки в пределах тела объекта определен соответствующим типом среды.
HTTP/1.1 заголовки могут занимать несколько строк, если продолжение строки начинается с пробела или символа горизонтальной табуляции. Все строчные пробелы имеют ту же семантику, что и обычный пробел (SP).
Правило TEXT используется только для содержимого описательных полей и значений, которые не предполагается передавать интерпретатору сообщений. Слова *TEXT могут содержать символы из символьного набора, не совпадающего с ISO 8859-1 [22], только когда они закодированы согласно правилам RFC-1522 [14].
В некоторых протокольных элементах используются шестнадцатеричные цифровые символы.
Многие значения полей заголовков HTTP/1.1 состоят из слов, разделенных LWS или специальными символами. Эти специальные символы должны представлять собой строки, заключенные в кавычки, чтобы использоваться в качестве значения параметра.
Комментарии могут быть включены в некоторые поля HTTP заголовков, при этом текст комментария заключается в скобки. Комментарии допустимы только для полей, содержащих "comment", как часть описания поля. В других полях скобки рассматриваются как элемент содержимого поля.
Строка текста воспринимается как одно слово, если она помещена в двойные кавычки.
Символ обратная косая черта ("\") может использоваться вместо кавычки внутри закавыченного текста или в структурах комментариев.
4.5.6.1.2. Параметры протокола
HTTP использует схему нумерации " Число Версия HTTP-сообщения указывается в поле HTTP-Version в первой строке сообщения.
Заметьте, что числа major и minor должны рассматриваться как независимые целые, так что каждое из них может быть увеличено за пределы одной цифры. Таким образом, HTTP/2.4 является более низкой версией, чем HTTP/2.13, которая в свою очередь ниже, чем HTTP/12.3. Начальные нули должны игнорироваться и не пересылаться Приложения, посылающие запросы или отклики, так как это определено в спецификации, должны включать HTTP-Version "HTTP/1.1". Использование этого номера версии указывает, что посылающее приложение совместимо с этой спецификацией. Версия HTTP приложения является верхней, совместимость с которой гарантируется. Приложения прокси-серверов и сетевых портов должны проявлять осторожность при переадресации сообщений с протокольной версией, отличной от поддерживаемой ими. Так как версия протокола указывает на возможности отправителя, прокси никогда не должны пересылать сообщения с версией больше, чем их собственная; если получено сообщение более высокой версии, прокси/порт должен либо понизить версию запроса, либо послать отклик об ошибке или переключиться в режим туннеля. Запросы с версией ниже, чем у прокси/порта могут быть повышены при переадресации, при этом major часть версии сервера и запроса должны совпадать. Замечание: Преобразование между версиями может включать модификацию полей заголовка. 2.2. Универсальные идентификаторы ресурсов (URI) URI известен под многими именами: WWW адрес, универсальный идентификатор документа (Universal Document Identifiers), универсальный идентификатор ресурса (Universal Resource Identifiers), и, наконец, универсальный локатор ресурса URL (Uniform Resource Locators; тождество URI и URL сомнительно, так как URL является частным случаем URI (примечание переводчика)) и универсальное имя ресурса (URN). Что касается HTTP, универсальный идентификатор ресурса представляет собой форматированную строку символов, которая идентифицирует имя, положение или какие-то еще характеристики ресурса. URI в HTTP может быть представлен в абсолютной или относительной форме по отношению к некоторому известному базовому URI, в зависимости от контекста его использования. Эти две формы отличаются тем, что абсолютный URI всегда начинается с имени схемы, за которым следует двоеточие (например HTTP: или FTP:).
Более детальную информацию о синтаксисе и семантике URL можно найти в RFC-1738 [4] и RFC-1808 [11]. Приведенные выше BNF включают в себя национальные символы, недопустимые в URL, так как это специфицировано в RFC 1738, так как серверам HTTP не запрещено использование любых наборов символов, допустимых в rel_path частях адресов, HTTP-прокси могут получить запросы URI, не определенные в рамках RFC-1738. Протокол HTTP не устанавливает каких-либо ограничений на длину URI. Серверы должны быть способны обрабатывать URI любых ресурсов, имеющих любую длину. Сервер должен выдать отклик 414 (Request-URI Too Long - URI запроса слишком длинен), если URI длиннее, чем может обработать сервер (см. раздел 9.4.15). Замечание: Серверы должны избегать использования URI длиннее 255 байт, так как некоторые старые клиенты или прокси-приложения не могут корректно работать с такими длинами. Схема "HTTP" используется для локализации сетевых ресурсов с помощью протокола HTTP. Далее определены синтаксис и семантика HTTP URL, зависящие от схемы.
Если номер порта не указан, предполагается порт 80. Семантика устроена так, что идентифицированный ресурс размещается на сервере, который ожидает TCP-соединения через порт данной ЭВМ, а Request-URI для ресурса находится в abs_path. Использование IP адресов в URL следует избегать всюду, где это возможно (см. RFC-1900 [24]). Если abs_path в URL отсутствует, он должен считаться равным "/", в случае, если он используется в качестве Request-URI для ресурса (раздел 4.1.2). При сравнении двух URI с целью проверки их идентичности, клиент должен использовать по октетное сравнение с учетом регистра, в котором напечатаны символы. Допускаются следующие исключения:
Символы, отличные от типов "reserved" и "unsafe" устанавливаются равными их эквивалентам в кодировке ""%" HEX HEX". Например, следующие три URI являются эквивалентными: http://abc.com:80/~smith/home.html
3.3. Форматы даты/времени
HTTP приложения допускают три различных формата для представления метки времени и даты: Sun, 06 Nov 1994 08:49:37 GMT ; RFC-822, актуализировано в RFC-1123 Первый формат предпочтительнее, как стандарт Интернет и представляет собой форму фиксированной длины, определенную RFC-1123. Второй формат используется достаточно широко, но базируется на устаревшем документе RFC-850 [12], формат даты не имеет 4 цифр года. Клиенты и серверы HTTP/1.1, которые анализируют дату, должны уметь работать со всеми тремя форматами (для совместимости с HTTP/1.0), хотя они должны сами генерировать время/дату согласно формату RFC-1123. Замечание: Получатели значений даты должны быть готовы принять коды, которые посланы не приложениями HTTP, что случается, когда данные поступают через прокси/порты или по почте в SMTP- или NNTP-форматах. Все марки времени/даты HTTP должны соответствовать времени по Гринвичу (GMT). Это указано в первых двух форматах путем включения строки "GMT" и должно предполагаться во всех прочих случаях.
Замечание: HTTP требования для формата метки даты/времени применимы только для использования в рамках реализации самого протокола. Клиенты и сервера не требуют применения этих форматов для пользовательских презентаций, протоколирования запросов и т.д.. 2.3.2. Интервалы времени в секундах Некоторые поля заголовка HTTP допускают спецификацию значения времени в виде целого числа секунд, представленного в десятичной форме и равного времени с момента получения сообщения. delta-seconds = 1*DIGIT HTTP использует то же определение термина "набор символов", что дано для MIME: Термин "набор символов", используемый в данном документе, относится к методу, который с помощью одной или более таблиц преобразует последовательность октетов в последовательность символов. Заметьте, что не требуется безусловное обратное преобразование, при этом не все символы могут быть доступны и одному и тому же символу может соответствовать более чем одна последовательность октетов. Это определение имеет целью допустить различные виды кодировок символов, от простых однотабличных, таких как US-ASCII, до сложных - таблично переключаемых методов, используемых, например, в ISO 2022. Однако, определение, связанное с набором символов MIME, должно полностью специфицировать схему соответствия октетов и символов. Использование внешних профайлов для определения схемы шифрования не допустимо. Замечание. Здесь "набор символов" ближе к понятию "кодирование символов". Однако так как HTTP и MIME используют один и тот же регистр, важно, чтобы терминология также была идентичной. Наборы символов HTTP идентифицируются лексемами, которые не чувствительны к использованию строчных или прописных букв. Полный набор лексем определен регистром наборов символов IANA [19]. charset = token Несмотря на то, что HTTP позволяет использовать произвольную лексему в качестве значения charset, любая лексема, значение которой определено в рамках регистра набора символов IANA, должна представлять символьный набор, определенный этим регистром. Приложение должно ограничить использование символьных наборов только теми, которые определены регистром IANA. Значения кодировки содержимого указывают на кодовое преобразование, которое было или может быть выполнено над объектом. Кодировки содержимого первоначально применены для того, чтобы иметь возможность архивировать документ или преобразовать его каким-то другим способом без потери идентичности или информации. Часто объект запоминается закодированным, передается и только получателем декодируется. content-coding = token Все значения кодировок содержимого не зависят от того, используются строчные или прописные символы. HTTP/1.1 использует значения кодировок содержимого в полях заголовка Accept-Encoding (раздел 13.3) и Content-Encoding (раздел 13.12). Хотя значение описывает кодирование содержимого, более важным является то, что оно определяет механизм декодирования. Комитет по стандартным числам Интернет IANA (Internet Assigned Numbers Authority) выполняет функции регистра для значений лексем кодирования содержимого, этот регистр хранит следующие лексемы: gzip Формат кодирования, реализуемый программой архивации файлов "gzip" (GNU zip), как описано в RFC 1952 [25]. Этот формат соответствует кодированию Lempel-Ziv (LZ77) с 32 битным CRC. compress Формат кодирования, реализуемый стандартной программой UNIX для архивации файлов "compress". Этот формат соответствует адаптивному методу кодирования Lempel-Ziv-Welch (LZW). Замечание: Использование имен программ для идентификации форматов кодирования не является желательным и будет в будущем заменено. Их использование здесь является следствием исторической практики. Для совместимости с предшествующими реализациями HTTP, приложения должны считать "x-gzip" и "x-compress" эквивалентными "gzip" и "compress" соответственно. deflate Формат "zlib" определен документом RFC 1950 [31] в комбинации с механизмом сжатия "deflate", описанным в RFC 1951 [29]. Новые значения лексем кодирования содержимого должны регистрироваться. Для обеспечения взаимодействия между клиентами и серверами спецификации алгоритмов кодирования содержимого должны быть общедоступны. Значения транспортного кодирования используются для определения кодового преобразования, которому был подвергнут или желательно подвергнуть объект для того, чтобы гарантировать безопасную его транспортировку через сеть. Этот вид преобразования отличен от кодирования содержимого, так как относится к сообщению, а не исходному объекту.
Все значения транспортного кодирования не зависят от того, строчные или прописные буквы здесь использованы. HTTP/1.1 несет значения транспортного кодирования в поле заголовка Transfer-Encoding (раздел 13.40). Транспортные кодировки аналогичны используемым значениям Content-Transfer-Encoding MIME, которые были введены для обеспечения безопасной передачи двоичных данных через 7-битную транспортную среду. Однако безопасная транспортировка имеет другие аспекты в рамках 8-битного протокола передачи сообщений. В HTTP, единственной небезопасной характеристикой тела сообщения является неопределенность его длины (раздел 6.2.2), или желание зашифровать данные при передаче по общему каналу. Блочное кодирование фрагментов модифицирует тело сообщения для того, чтобы передать его в виде последовательности пакетов, каждый со своим индикатором размера, за которым следует опционная завершающая запись (footer), содержащая поля заголовка объекта. Это позволяет передать динамически сформированное содержимое, снабдив его необходимой информацией для получателя, который, в конце концов, сможет восстановить все сообщение.
Блочное кодирование фрагментов завершается пакетом нулевой длины, за которыми следует завершающая запись и пустая строка. Назначение завершающей записи заключается в том, чтобы дать информацию о динамически сформированном объекте; приложения не должны пересылать поля заголовка в завершающей записи, кроме тех, которые специально оговорены, например, такие как Content-MD5 или будущие расширения HTTP для цифровой подписи. Пример процесса такого кодирования представлен в приложении 16.4.6. Все приложения HTTP/1.1 должны быть способны получать и декодировать получаемые фрагменты ("chunked"-кодирование), и должны игнорировать расширения транспортного кодирования, которые они не понимают. Сервер, получающий тело объекта с транспортной кодировкой, которую он не понимает, должен отослать отклик c кодом 501 (Unimplemented - не применимо), и закрыть соединение. Сервер не должен использовать транспортное кодирование при посылке данных клиенту HTTP/1.0. HTTP использует типы среды Интернет (Internet Media Types) в полях заголовка Content-Type (раздел 13.18) и Accept (раздел 13.1) для того, чтобы обеспечить широкий и открытый обмен с самыми разными типа среды.
Параметры могут следовать за type/subtype в форме пар атрибут/значение.
Имена типа, субтипа и атрибутов параметра могут набираться, как строчными, так и прописными буквами. Значения параметров могут быть и чувствительны к используемому регистру, в зависимости от семантики и имени параметра. Строчный пробел (LWS) не должен использоваться ни между типом и субтипом, ни между атрибутом и значением. Агенты пользователя, которые распознают тип среды, должны обрабатывать (или обеспечить обработку с использованием внешнего приложения для работы агента пользователя с типом/субтипом) параметры для типа MIME так, как это описано для данного типа/субтипа, и информировать пользователя о любых возникающих проблемах. Замечание. Некоторые старые приложения HTTP не узнают параметры типа среды. При посылке данных старому HTTP-приложению, программы должны использовать параметры типа среды, только когда они необходимы по описанию типа/субтипа. Значения типа среды регистрируются IANA (Internet Assigned Number Authority). Процесс регистрации типа среды описан в RFC 2048 [17]. Использование незарегистрированных типов среды настоятельно не рекомендуется. 2.7.1. Канонизация и текст по умолчанию Типы среды Интернет регистрируются каноническим образом. Вообще, тело объекта, передаваемого с помощью HTTP сообщений, должно быть представлено соответствующим каноническим способом, прежде чем будет послано, исключение составляет тип "text", как это описано в следующем параграфе. В случае канонической формы субтип среды "text" использует CRLF для завершения строки текста. HTTP ослабляет это требование и позволяет передавать текст, используя просто CR или LF, представляющие разрыв строки. HTTP приложения должны воспринимать CRLF, "голое" CR и LF как завершение строки для текстовой среды полученной через HTTP. Кроме того, если текст представлен в символьном наборе, где нет октетов 13 и 10 для CR и LF соответственно, как это имеет место в случае мультибайтных символьных наборов, HTTP позволяет использовать соответствующие символьные представления для CR и LF. Эта гибкость в отношении разрыва строк относится только к текстовой среде в теле объекта; CR или LF не должны подставляться вместо CRLF в любые управляющие структуры HTTP (такие как поля заголовка). Если тело объекта закодировано с помощью Content-Encoding, исходные данные, прежде чем подвергнуться кодированию должны были иметь форму, указанную выше. Параметр "charset" используется с некоторыми типами среды, чтобы определить символьный набор (раздел 2.4). Когда параметр charset не задан отправителем явно, субтип среды "text" определяется так, что используется символьный набор по умолчанию "ISO-8859-1". Данные с набором символов, отличным от "ISO-8859-1" или его субнабора, должны помечаться соответствующим значением charset. Некоторые программы HTTP/1.0 интерпретируют заголовок Content-Type без параметра charset, неправильно предполагая, что "получатель должен решить сам, какой это набор". Отправители, желающие заблокировать такое поведение, могут включать параметр charset, даже когда charset равен ISO-8859-1 и должны делать так, когда известно, что это не запутает получателя. К сожалению, некоторые старые HTTP/1.0 клиенты не обрабатывают корректно параметр charset. HTTP/1.1 получатели должны учитывать метку charset, присланную отправителем, и те агенты пользователя, которые умеют делать предположение относительно символьного набора, должны использовать символьный набор из поля content-type, если они поддерживают этот набор, а не набор, предпочитаемый получателем. MIME обеспечивает нескольких составных типов - инкапсуляция одного или более объектов в общее тело сообщения. Все составные типы имеют общий синтаксис, как это определено в MIME [7], и должны включать граничный параметр, являющийся частью значения типа среды. Тело сообщения является само протокольным элементом и, следовательно, должно использовать только CRLF для обозначения разрывов строки. В отличии от MIME, завершающая часть любого составного cообщения должна быть пустой. HTTP приложения не должны передавать завершающую часть (даже если исходное составное сообщение содержит такую завершающую часть (эпилог-подпись). В HTTP, составляющие части тела могут содержать поля заголовка, которые существенны для значения этих частей. Рекомендуется, чтобы поле заголовка Content-Location (раздел 13.15) было включено в часть тела каждого вложенного объекта, который может быть идентифицирован URL. Вообще, рекомендуется, чтобы агент пользователя HTTP имел идентичное или схожее поведение с агентом пользователя MIME при получении составного типа. Если приложение получает неузнаваемый составной субтип, оно должно обрабатывать его также как "multipart/mixed". Замечание: Тип "multipart/form-data" специально определен для переноса данных совместимого с методом обработки почтовых запросов, как это описано в RFC 1867 [15]. Лексемы продукта служат для того, чтобы позволить взаимодействующим приложениям идентифицировать себя с помощью имени и версии программного продукта. Большинство полей, использующих лексемы продукта допускают также включение в список субпродуктов, которые образуют существенную часть приложения, их лексемы отделяются пробелом. По договоренности, продукты перечисляются в порядке их важности для идентификации приложения.
Примеры: User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Лексемы продукта должны быть короткими и, кроме того, использование их для оповещения или передачи маловажной информации абсолютно запрещено. Хотя любой символ лексемы может присутствовать в версии продукта, рекомендуется, чтобы эта лексема использовалась только для идентификации версии (то есть, последовательные версии одного и того же продукта должны отличаться только в части версии продукта). 2.9. Значения качества (Quality values) HTTP согласование параметров содержимого (раздел 12) использует короткие числа с плавающей запятой для указания относительной важности (веса) различных согласуемых параметров. Вес нормализуется на истинное число в диапазоне 0 - 1, где 0 равен минимальному, а 1 максимальному значению. Приложения HTTP/1.1 не должны генерировать более трех чисел после запятой. Рекомендуется, чтобы конфигурация пользователя для этих значений удовлетворяла тем же ограничениям. qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] ) "Quality values" (значения качества) является неверным названием, так как эти значения в большей степени отражают относительную деградацию желательного качества. Языковая метка идентифицирует естественный язык. Компьютерные языки в этот перечень не входят. HTTP использует языковые метки в полях Accept-Language и Content-Language. Синтаксис и регистр языковых меток HTTP тот же, что и определенный в RFC 1766 [1]. Языковая метка содержит одну или более частей: первичная языковая метка и последовательность субметок, которая может и отсутствовать:
Пробел не допустим в метке, применение строчных и прописных букв не играет никакой роли. Перечень языковых меток контролируется IANA. Ниже приведены примеры языковых меток: en, en-US, en-cockney, i-cherokee, x-pig-latin где любые две буквы первичной метки представляют собой языковую аббревиатуру ISO 639 и две буквы исходной субметки соответствуют коду страны ISO 3166 (последние три метки не являются зарегистрированными; все кроме последней могут быть зарегистрированы в будущем). Метки объектов служат для сравнения двух или более объектов из одного и того же запрошенного ресурса. HTTP/1.1 использует метки объектов в полях заголовков ETag (раздел 13.20), If-Match (раздел 13.25), If-None-Match (раздел 13.26) и If-Range (раздел 13.27). Метки объекта состоят из строк, заключенных в кавычки, перед ней может размещаться индикатор слабости.
"Сильная метка объекта" (strong entity tag) может принадлежать двум объектам ресурса, если они эквивалентны на октетном уровне. "Слабая метка объекта " (weak entity tag) отмечается префиксом "W/", может относиться к двум объектам ресурса, только если объекты эквивалентны и могут быть взаимозаменяемы. Слабая метка объекта может использоваться для "слабого" сравнения. Метка объекта должна быть уникальной для всех версий всех объектов, сопряженных с конкретным ресурсом. Значение данной метки объекта может использоваться для объектов, полученных в результате запросов для различных URI без использования данных об эквивалентности этих объектов. HTTP/1.1 позволяет клиенту запросить только часть объекта (диапазон). HTTP/1.1 использует структурные единицы, определяющие выделение части объекта, в полях заголовка Range (раздел 13.36) и Content-Range (раздел 13.17). Объект может быть разбит на фрагменты с использованием различных структурных единиц.
Единственной структурной единицей, определенной в HTTP/1.1, является "bytes". HTTP/1.1 реализации могут игнорировать диапазоны, специфицированные с использованием других структурных единиц. HTTP/1.1 сконструирован так, чтобы позволить реализацию приложений, которые не зависят от знания диапазонов.
4.5.6.1.3. HTTP сообщение
Сообщения HTTP включают в себя запросы клиента к серверу и отклики сервера клиенту. HTTP-message = Request | Response ; HTTP/1.1 messages Сообщения запрос (раздел 5) и отклик (раздел 6) используют общий формат сообщений RFC-822 [9] для передачи объектов (поле данных сообщения). Оба типа сообщений состоят из стартовой строки, одного или более полей заголовка (также известные как "заголовки"), пустой строки (то есть, строка, содержащая CRLF), отмечающей конец полей заголовка, а также опционного тела сообщения. generic-message = start-line В интересах надежности, рекомендуется серверам игнорировать любые пустые строки, полученные, когда ожидается Request-Line (строка запроса). Другими словами, если сервер читает протокольный поток в начале сообщения и получает сначала CRLF, он должен игнорировать CRLF. Замечание: Определенные не корректные реализации HTTP/1.0 клиентов генерируют дополнительные CRLF после запроса POST. Клиент HTTP/1.1 не должен посылать CRLF до или после запроса. Поля заголовка HTTP, которые включают в себя поля общего заголовка (раздел 3.5), заголовка запроса (раздел 4.3), заголовка отклика (раздел 6.2), и заголовка объекта (раздел 6.1), следуют тому же общему формату, что дан в разделе 3.1 RFC 822 [9]. Каждое поле заголовка состоит из имени, за которым следует двоеточие (":"), и поля значения. Поля имен безразличны в отношении использования строчных и прописных букв. Поле значения может начинаться с любого числа LWS, хотя один SP предпочтительнее. Поля заголовка могут занимать несколько строк, каждая новая строка должна открываться, по крайней мере, одним SP или HT. Рекомендуется, чтобы приложения следовали общему формату, если они создаются конструкциями HTTP, так как могут существовать некоторые реализации, которые не могут воспринимать ничего кроме общих форматов.
field-content = < OCTET'ы образуют значения поля и состоят из *TEXT или комбинаций лексем, tspecials и закавыченных строк > Порядок, в котором приходят поля заголовка с отличающимися именами, не играет значения. Однако, хорошей практикой считается посылка сначала поля общего заголовка, за которым следует заголовок запроса или отклика, а в заключение поля заголовка объекта. Множественные поля заголовка сообщения с идентичными именами могут присутствовать тогда и только тогда, когда значение поля определяется как список из элементов, разделенных запятыми [то есть, #(значения)]. Должна быть предусмотрена возможность объединять множественные поля заголовка в одну пару "имя_поля: значение_поля", без изменения семантики сообщения, путем добавления каждой последующей пары поле-значение, отделенных друг от друга запятыми. Порядок, в котором следуют поля заголовка с идентичными именами, влияет на последующую интерпретацию значения комбинированного поля, по этой причине прокси-сервер не должен менять порядок значений этих полей при переадресации сообщения. Тело сообщения HTTP (если имеется) используется для переноса тела объекта, сопряженного с запросом или откликом. Тело сообщения отличается от тела объекта, только когда используется транспортное кодирование, как это указано в поле заголовка Transfer-Encoding (раздел 13.40). message-body = entity-body Transfer-Encoding должно использоваться для указания любого транспортного кодирования, реализованного приложением с целью гарантированной неискаженной доставки сообщения. Транспортное кодирование лежит в зоне ответственности сообщения, а не объекта и по этой причине может быть реализовано любым приложением в цепочке запрос/отклик. Присутствие тела сообщения в запросе отмечается с помощью включения полей заголовка Content-Length или Transfer-Encoding в заголовки сообщений-запросов. Тело сообщения может быть включено в запрос, только когда метод запроса допускает наличие тела объекта (раздел 4.1.1). Для сообщений-откликов включение в них тела сообщения зависит от метода запроса и статусного кода отклика (раздел 5.1.1). Все отклики в случае метода запроса HEAD не должны включать тела сообщения, даже если присутствуют поля заголовка объекта, позволяющие предположить его присутствие. Все отклики 1xx (информационные), 204 (никакого содержимого) и 304 (не модифицировано) не должны включать тела сообщения. Все другие отклики включают в себя тело сообщения, хотя оно может иметь и нулевую длину. Когда тело включено в сообщение, его длина определяется следующим образом (в порядке приоритета):
Для совместимости с приложениями HTTP/1.0, запросы HTTP/1.1, содержащие тело запроса, должны включать корректное поле заголовка Content-Length. Если запрос содержит тело сообщения, а поле Content-Length отсутствует, рекомендуется, чтобы сервер реагировал откликом 400 (плохой запрос), если он не может определить длину сообщения, или 411 (необходима длина), если он настаивает на получении корректного поля Content-Length. Все приложения HTTP/1.1, которые получают объект (entity) должны понимать блочное ("chunked") транспортное кодирование (раздел 2.6), таким образом, разрешая использование этого механизма для сообщений, когда длина сообщения не может быть определена заранее. Сообщения не должны включать поле заголовка Content-Length и блочное транспортное кодирование одновременно. Если такое сообщение получено, поле Content-Length должно игнорироваться. Когда в сообщении присутствует поле Content-Length и разрешено наличие тела сообщения, его значение поля должно строго соответствовать числу октетов в теле сообщения. Агенты пользователя HTTP/1.1 должны оповещать пользователя, если получено сообщение некорректной длины. Существует несколько полей заголовка, которые имеют применимость, как для запросов, так и откликов, но которые не используются для передачи объектов. Эти поля заголовков служат только для пересылаемых сообщений.
Имена полей общего заголовка могут быть расширены только при изменении версии протокола. Однако, новые или экспериментальные поля заголовка могут использоваться при условии, если партнеры обмена способны их распознавать, как поля общего заголовка. Не узнанные поля заголовка считаются полями заголовка объекта (entity). Сообщение-запрос от клиента к серверу включает в себя, в пределах первой строки сообщения, метод, который должен быть использован для ресурса, идентификатор ресурса и код версии используемого протокола.
Строка запроса начинается с лексемы метода, за которой следует Request-URI, версия протокола, завершается строка последовательностью CRLF. Элементы разделяются символами SP. Символы CR или LF запрещены кроме завершающей последовательности CRLF.
Лексема Method указывает на метод, который должен быть применен к ресурсу, обозначенному Request-URI. При записи метода использование строчных или прописных букв не безразлично.
Список методов допустимых для ресурса может быть специфицирован полем заголовка Allow (раздел 13.7). Возвращаемый код отклика всегда оповещает клиента, допустим ли метод для ресурса, так как набор допустимых методов может меняться динамически. Серверам рекомендуется возвращать статусный код 405 (Метод не допустим), если метод известен серверу, но не приемлем для запрашиваемого ресурса и 501 (Не применим), если метод не узнан или не приемлем для сервера. Список методов, известных серверу может быть представлен в поле заголовка отклика Public (раздел 13.35). Методы GET и HEAD должны поддерживаться всеми серверами общего назначения. Все другие методы являются опционными; однако, если применены вышеназванные методы, они должны быть применены с той же семантикой, что специфицирована в разделе 8. URI запроса является универсальным идентификатором ресурса (раздел 2.2) и идентифицирует ресурс, который запрашивается. Request-URI = "*" | absoluteURI | abs_path Три опции для Request-URI зависят от природы запроса. Звездочка "*" означает, что запрос приложим не к заданному ресурсу, но к самому серверу, и допустим только, когда используемый метод не обязательно приложим к ресурсу. Примером может служить OPTIONS * HTTP/1.1 Форма абсолютного URI необходима, когда запрос адресован к прокси-серверу. Прокси-серверу посылается запрос переадресации с целью получения отклика. Заметьте, что прокси может переадресовать запрос другому прокси или серверу, указанному абсолютным URI. Для того, чтобы избежать петель запросов прокси-сервер должен быть способен распознавать все имена серверов, включая любые псевдонимы, локальные вариации и численные IP-адреса. Пример строки запроса представлен ниже: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 Для того чтобы разрешить передачу абсолютных URI в запросах будущих версий HTTP, все серверы HTTP/1.1 должны уметь работать с запросами абсолютных форм URI. Наиболее общей формой Request-URI является та, которая используется для идентификации ресурса на исходном сервере или внешнем порту сети. В этом случае абсолютный проход к URI должен быть занесен в abs_path (см. раздел 2.2.1) как Request-URI, а сетевой адрес URI (net_loc) должен быть занесен в поле заголовка Host. Например, клиент, желающий извлечь ресурс из выше приведенного примера непосредственно с базового сервера, установит TCP-соединение через порт 80 с ЭВМ "www.w3.org" и пошлет строки: GET /pub/WWW/TheProject.html HTTP/1.1 за которыми следует остальная часть запроса. Заметьте, что абсолютный проход не может быть пустым; если его нет в исходном URI, он должен быть задан в виде "/" (корневой каталог сервера). Если прокси получает запрос без какого-либо прохода в Request-URI, а метод, специфицирован так, чтобы быть способным поддерживать форму "*" запросов, тогда последний прокси в цепочке запроса должен переадресовать запрос с "*" в качестве финального Request-URI. Например, запрос OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 будет переадресован прокси как OPTIONS * HTTP/1.1 после подключения к порту 8001 ЭВМ "www.ics.uci.edu". Request-URI передается в формате, описанном в разделе 3.2.1. Исходный сервер должен декодировать Request-URI, для того чтобы правильно интерпретировать запрос. Серверам рекомендуется откликаться на некорректный запрос Request-URI соответствующим статусным кодом. В запросах, которые они переадресуют, прокси-серверы не должны переписывать "abs_path" часть Request-URI каким-либо способом, за исключением случая, описанного выше, когда нулевой abs_path заменяется на "*". Замечание: Правило "no rewrite" препятствует прокси изменить смысл запроса, когда исходный сервер некорректно использует незарезервированный URL символ для зарезервированных целей. Следует остерегаться того, что некоторые предшествующие варианты прокси-серверов HTTP/1.1 допускали перезапись Request-URI. 4.2. Ресурс, идентифицируемый запросом Исходному серверу HTTP/1.1 рекомендуется заботиться о точном определении ресурса, идентифицированного Интернет-запросом путем анализа Request-URI и поля заголовка Host. Исходный сервер, который не разделяет ресурсы по запрашиваемого ЭВМ, может игнорировать значение поля заголовка Host. (См. раздел 16.5.1 по поводу других требований по поддержке Host в HTTP/1.1.) Исходный сервер, который различает ресурсы с использованием имени ЭВМ, должен использовать следующие правила для определения ресурса в запросе HTTP/1.1:
Получатели HTTP/1.0-запроса, где отсутствует поле заголовка Host, могут попытаться использовать эвристику (напр., рассмотрение прохода URI на предмет уникальной конкретной ЭВМ) для того, чтобы определить, какой конкретный ресурс запрошен. Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса, с семантикой, эквивалентной параметрам, характеризующими метод языка программирования.
Поля имен заголовка запроса могут быть безопасно расширены в сочетании с изменением версии протокола. Однако новым или экспериментальным полям может быть придана семантика полей заголовка запроса, если все участники обмена способны их распознать. Не узнанные поля заголовка рассматриваются как поля заголовка объекта. После получения и интерпретации сообщения-запроса, сервер реагирует, посылая HTTP сообщение отклик.
Первая строка сообщения-отклика является статусной строкой, состоящей из кода версии протокола, за которым следует числовой статусный код и его текстовое представление, все элементы разделяются символами SP (пробел). Никакие CR или LF не допустимы, за исключением завершающей последовательности CRLF. Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 5.1.1. Статусный код и словесный комментарий Элемент Status-Code представляет собой 3-значный цифровой результирующий код попытки понять и исполнить запрос. Эти коды полностью определены в разделе 9. Словесный комментарий (Reason-Phrase) предназначен для того, чтобы дать краткое описание статусного кода. Статусный код служит для использования автоматами, а словесный комментарий для пользователей. Клиент не обязан рассматривать или отображать словесный комментарий. Первая цифра статусного кода определяет класс отклика. Последние две цифры не имеют четко определенной функции. Существует 5 значений первой цифры:
Индивидуальные значения числовых статусных кодов определены в HTTP/1.1, а набор примеров, соответствующих причинам, представлен ниже. Комментарии причин, предлагаемые здесь, являются лишь рекомендательными - они могут быть заменены местными аналогами без последствий для протокола.
Статусные коды HTTP допускают расширение. HTTP приложения могут не понимать значение всех зарегистрированных статусных кодов, хотя их понимание, очевидно, является желательным. Однако, приложения должны понимать класс любого статусного кода, который задается его первой цифрой, и воспринимать не узнанный отклик как x00. Не узнанный статусный отклик не должен заноситься в буфер. Например, если клиентом получен не распознаваемый статусный код 431, он может предположить, что произошло что-то с запросом и рассматривать отклик так, как если бы он равнялся 400. В таких случаях агентам пользователя рекомендуется предоставлять пользователю объект с откликом, который содержит текст, поясняющий причину создавшейся ситуации. Поля заголовка отклика позволяют серверу передавать дополнительную информацию об отклике, который не может быть помещен в статусную строку. Эти поля заголовка дают информацию о сервере и доступе к ресурсу, идентифицированному Request-URI.
Имена полей заголовка отклика могут быть расширены только в случае изменения версии протокола. Однако новые или экспериментальные поля могут быть введены с учетом семантики полей заголовка отклика, если все участники обмена способны распознавать эти поля. Не узнанные поля заголовка рассматриваются, как поля заголовка объекта (entity-header fields). Сообщения запрос и отклик могут нести в себе объект, если это не запрещено методом запроса или статусным кодом отклика. Объект состоит из полей заголовка объекта и тела объекта, хотя некоторые отклики включают в себя только заголовки объектов. В данном разделе, как отправитель, так и получатель соотносятся к клиенту или серверу, в зависимости от того, кто отправляет и кто получает объект. Поля заголовка объекта определяют опционную метаинформацию о теле объекта или, если тело отсутствует, о ресурсе, идентифицированном в запросе.
extension-header = message-header Механизм расширения заголовка позволяет определить дополнительные полязаголовка объекта без изменения версии протокола, но эти поля не могут считаться заведомо распознаваемыми получателем. Неузнанные поля заголовка рекомендуется получателю игнорировать и переадресовывать прокси-серверам. Тела объекта (если они имеются), пересылаемые HTTP-запросом или откликом, имеют формат и кодировку, определенную полями заголовка объекта.
Тело объекта присутствует в сообщении только когда имеется тело сообщения, как это описано в разделе 3.3. Тело объекта получается из тела сообщения путем декодирования любого транспортного кода (Transfer-Encoding), который может быть применен для обеспечения безопасной и корректной доставки. Когда тело объекта включено в сообщение, тип данных этого тела определяется полями заголовка Content-Type и Content-Encoding. Они определяют два слоя, заданных моделью кодирования: entity-body := Content-Encoding( Content-Type( данные ) ) Content-Encoding может использоваться для индикации любого дополнительного кодирования содержимого поля данных, обычно для целей архивации, которая является особенностью запрашиваемого ресурса. По умолчанию никакого кодирования не используется. Любое HTTP/1.1 сообщение, содержащее тело объекта, должно включать поле заголовка Content-Type, определяющее тип среды для данного тела. Только в случае, когда тип среды не задан полем Content-Type, получатель может попытаться предположить, каким является тип среды, просмотрев содержимое и/или расширения имен URL, использованного для идентификации ресурса. Если тип среды остается неизвестным, получателю следует рассматривать его как "application/octet-stream" (поток октетов). Длина тела объекта равна длине тела сообщения, после того как произведено транспортное декодирование. Раздел 4.4 определяет то, как определяется длина тела сообщения.
4.5.6.1.7. Соединения
Прежде чем установить постоянную связь должно быть реализовано отдельное TCP соединение с тем, чтобы получить URL. Это увеличивает нагрузку HTTP серверов и вызывает перегрузку каналов Интернет. Использование изображений и другой связанной с этим информации часто требует от клиента множественных запросов, направленных определенным серверам за достаточно короткое время. Анализ этих проблем содержится в [30][27], а результаты макетирования представлены в [26]. Постоянное HTTP соединение имеет много преимуществ:
Заметным различием между HTTP/1.1 и более ранними версиями HTTP является постоянное соединение, которое в HTTP/1.1 является вариантом, реализуемым по умолчанию. Поэтому, если не указано обратное, клиент может предполагать, что сервер будет поддерживать постоянное соединение. Постоянное соединение обеспечивает механизм, с помощью которого клиент и сервер могут сигнализировать о закрытии TCP-соединения. Эта система сигнализации использует поле заголовка Connection. Как только поступил сигнал о закрытии канала, клиент не должен посылать какие-либо запросы по этому каналу. HTTP/1.1 сервер может предполагать, что HTTP/1.1 клиент намерен поддерживать постоянное соединение, если только в поле заголовка Connection не записана лексема "close". Если сервер принял решение закрыть связь немедленно после посылки отклика, ему рекомендуется послать заголовок Connection, включающий лексему связи close. Клиент HTTP/1.1 может ожидать, что соединение останется открытым, но примет решение оставлять ли его открытым на основе того, содержит ли отклик сервера заголовок Connection с лексемой close. Если клиент или сервер посылает лексему close в заголовке Connection, этот запрос становится последним для данного соединения. Клиентам и серверам не следует предполагать, что соединение будет оставаться постоянным для версий HTTP, меньше 1.1, если только не получено соответствующее уведомление. Клиенты, которые поддерживают постоянное соединение, могут буферизовать свои запросы (то есть, посылать несколько запросов не дожидаясь отклика для каждого из них). Серверы должны посылать свои отклики на эти запросы в том же порядке, в каком они их получили. Клиенты, которые предполагают постоянство соединения и буферизацию немедленно после установления соединения должны быть готовы совершить повторную попытку установить связь, если первая буферизованная попытка не удалась. Если клиент совершает повторную попытку установления связи, он не должен выполнять буферизацию запросов, пока не получит подтверждения об установления постоянного соединения. Клиенты должны также быть готовы послать повторно свои запросы, если сервер закрывает соединение прежде, чем пришлет соответствующие отклики. Особенно важно то, чтобы прокси-серверы корректно использовали свойства поля заголовка Connection, как это специфицировано в 13.2.1. Прокси-сервер должен сигнализировать о постоянном соединении отдельно своему клиенту и исходному серверу (origin server) или другому прокси, с которым связан. Каждое постоянное соединение устанавливается только для одной транспортной связи. Прокси-сервер не должен устанавливать постоянное соединение с HTTP/1.0 клиентом. 7.1.4. Практические соображения Серверы обычно имеют некоторое значение таймаута, за пределами которого они уже не поддерживают более неактивное соединение. Прокси-серверы могут сделать эту величины больше, так как весьма вероятно, что клиент создаст больше соединений через один и тот же сервер. Использование постоянных соединений не устанавливает никаких требований на величину этого таймаута для клиента или сервера. Когда клиент или сервер хочет прервать связь по таймауту, ему следует послать корректное оповещение о закрытии соединения. Клиенты и серверы должны постоянно следить, не выдала ли противоположная сторона сигнал на закрытие канала и соответственно реагировать на него. Если клиент или сервер не зафиксирует сигнал противоположной стороны, то будут бессмысленно тратиться ресурсы сети. Клиент, сервер или прокси могут закрыть транспортный канал в любое время. Например, клиент может послать новый запрос во время, когда сервер решит закрыть "пассивное" соединение. С точки зрения сервера, состояние которое предлагается закрыть, является пассивным, но с точки зрения клиента идет обработка запроса. Это означает, что клиенты, серверы и прокси должны быть способны восстанавливаться после случаев асинхронного закрытия. Программа клиента должна заново открыть транспортное соединение и повторно передать неисполненный запрос без вмешательства пользователя (см. раздел 1.2), хотя агент пользователя может предложить оператору выбор, сопряженный с повторением запроса. Однако эта повторная попытка не должна повторяться при повторной неудаче. Серверам следует всегда реагировать, по крайней мере, на один запрос при соединении, если это возможно. Серверам не следует закрывать соединение в процессе передачи отклика, если только не имеет место отказ в сети или выключение клиента. Клиенты, которые используют постоянные соединения, должны ограничивать число одновременных связей, которые они поддерживают с конкретным сервером. Однопользовательскому клиенту рекомендуется поддерживать не более двух соединений с любым сервером или прокси. Прокси следует использовать до 2*N соединений с другим сервером или прокси, где N равно числу активных пользователей. Эти рекомендации призваны улучшить время отклика HTTP и исключить перегрузки Интернет и других сетей. 7.2. Требования к передаче сообщений Общие требования:
Клиентам следует запомнить номер версии, по крайней мере, сервера, с которым проводилась работа последним, если клиент HTTP/1.1 получил отклик от сервера HTTP/1.1 (или позднее) и обнаружил разрыв соединения до получения какого-либо статусного кода, клиенту следует повторно попытаться направить запрос без участия пользователя (см. раздел 9.1.2). Если клиент действительно повторяет запрос, то клиент:
Если клиент HTTP/1.1 не получил отклика от сервера HTTP/1.1 (или более поздней версии), ему следует считать, что сервер поддерживает версию HTTP/1.0 или более раннюю и не использует отклик 100 (Continue). Если в этом случае клиент обнаруживает закрытие соединения до получения какого-либо статусного кода от сервера, клиенту следует повторить запрос. Если клиент повторил запрос серверу HTTP/1.0, ему следует использовать следующий алгоритм получения надежного отклика:
Вне зависимости от версии сервера, если получен статус ошибки, то клиент
Клиент HTTP/1.1 (или позднее), который обнаруживает разрыв соединения после получения флага 100 (Continue), но до получения какого-либо статусного кода, должен повторить запрос и не должен ждать отклика 100 (Continue), но может и делать это, если это упрощает реализацию программы. Набор общих методов для HTTP/1.1 определен ниже. Хотя этот набор может быть расширен, нельзя предполагать, что дополнительные методы следуют той же семантике для разных клиентов и серверов. Поле заголовка запроса Host (раздел 13.23) должно присутствовать во всех запросах HTTP/1.1.
8.1. Безопасные и Idempotent методы Программисты должны заботиться о том, чтобы избегать операций, которые могут иметь неожиданное значение для них самих или их соседей по сети Интернет. В частности, установлено соглашение, что методы GET и HEAD никогда не должны выполнять какие либо функции помимо доставки информации. Эти методы должны рассматриваться как вполне безопасные. Это позволяет агентам пользователя представлять другие методы, такие как POST, PUT и DELETE, особым способом, так что пользователь сам будет заботиться о возможности опасных операций, которые могут быть выполнены в результате реализации запроса. Естественно, невозможно гарантировать, что сервер не будет вызывать побочные эффекты, как следствие выполнения запроса GET; в действительности, некоторые динамические ресурсы предусматривают такую возможность. Важным отличием здесь является то, что пользователь не запрашивал побочные эффекты и, следовательно, не может нести ответственность за них. Методы могут также иметь свойство "idempotence", при котором (помимо ошибок и таймаутов) побочный эффект от N > 0 идентичных запросов является таким же, как и от одного запроса. Методы GET, HEAD, PUT и DELETE имеют это свойство. Метод OPTIONS представляет собой запрос информации о коммуникационных опциях, доступных в цепочке запрос/отклик, идентифицированной Request-URI. Этот метод позволяет клиенту определить опции и/или требования, связанные с ресурсами, или возможности сервера, не прибегая к операциям по извлечению и пересылке каких-либо файлов. Если отклик сервера не сигнализирует об ошибке, отклик не должен включать никакой информации об объекте, отличной оттого, что считается коммуникационными опциями (напр., Allow подходит под эту категорию, а Content-Type нет). Отклики на этот метод не должны кэшироваться. Если Request-URI тождественен символу звездочка ("*"), то запрос OPTIONS будет относиться ко всему серверу. Отклик 200 должен включать в себя любые поля заголовка, которые указывают на опционные характеристики используемого сервера (например, Public), включая любые расширения неопределенные в данной спецификации, в дополнение к любым общим используемым полям заголовка. Как описано в разделе 4.1.2, запрос "OPTIONS *" может быть реализован через прокси путем спецификации сервера места назначения в Request-URI без указания прохода. Если Request-URI не равен звездочке, запрос OPTIONS относится только к опциям, которые доступны при обмене с данным ресурсом. Отклик 200 должен включать любые поля заголовка, которые указывают опционные характеристики используемого сервера и применимы к данному ресурсу (напр., Allow), включая любые расширения, не описанные в данной спецификации. Если запрос OPTIONS проходит через прокси, то он должен редактировать отклик и удалять те опции, которые не доступны для реализации через данный прокси-сервер. 8.3 Метод GET Метод GET предполагает извлечение любой информации (в форме объекта), заданной Request-URI. Если Request-URI относится к процессу, генерирующему данные, то в результате в виде объекта будут присланы эти данные, а не исходный текст самого процесса, если только этот текст не является результатом самого процесса. Семантика метода меняется на "условный GET", если сообщение-запрос включает в себя поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Метод условного GET запрашивает, пересылку объекта только при выполнении требований, описанных в соответствующих полях заголовка. Метод условного GET имеет целью уменьшить ненужное использование сети путем разрешения актуализации кэшированых объектов без посылки множественных запросов или пересылки данных, которые уже имеются у клиента. Семантика метода GET меняется на "частичный GET", если сообщение запроса включает в себя поле заголовка Range. Запросы частичного GET, которые предназначены для пересылки лишь части объекта, описаны в разделе 13.36. Метод частичного GET ориентирован на уменьшение ненужного сетевого обмена, допуская пересылку лишь части объекта, которая нужна клиенту, и не пересылая уже имеющихся частей. Отклик на запрос GET буферизуется, тогда и только тогда, когда это согласуется с требованиями буферизации, рассмотренными в разделе 12. Метод HEAD идентичен GET за исключением того, что сервер не должен присылать тело сообщения. Метаинформация, содержащаяся в заголовках отклика на запрос HEAD должна быть идентичной информации посланной в отклик на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, указанном в запросе, без передачи тела самого объекта. Этот метод часто используется для тестирования гипертекстных связей на корректность, доступность и актуальность. Отклик на запрос HEAD может кэшироваться в том смысле, что информация, содержащаяся в отклике, может использоваться для актуализации кэшированных ранее объектов данного ресурса. Если новые значения поля указывают на то, что кэшированный объект отличается от текущего объекта (как это индицируется изменением Content-Length, Content-MD5, ETag или Last-Modified), тогда запись в кэше должна рассматриваться как устаревшая. Метод POST используется при заявке серверу принять вложенный в запрос объект в качестве нового вторичного ресурса, идентифицированного Request-URI в Request-Line. POST создан для обеспечения однородной схемы реализации следующих функций:
Реальная операция, выполняемая методом POST, определяется сервером и обычно зависит от Request-URI. Присланный объект является вторичным по отношению к URI в том же смысле, в каком файл является вторичным по отношению к каталогу, в котором он находится, а статья новостей - вторичной по отношению к группе новостей, куда она помещена, или запись - по отношению к базе данных. Операция, выполняемая методом POST, может не иметь последствий для ресурса, который может быть идентифицирован URI. В этом случае приемлемым откликом является 200 (OK) или 204 (No Content - никакого содержимого), в зависимости от того, включает ли в себя отклик объект, описывающий ресурс. Если ресурс был создан на исходном сервере, отклик должен быть равен 201 (Created - создан) и содержать объект, который описывает статус запроса и относится к новому ресурсу и заголовку Location (см. раздел 13.30). Отклики на этот метод не могут кэшироваться, если только не содержат поля заголовка Cache-Control или Expires. Однако отклик 303 (см. Other) может быть использован для того, чтобы направить агента пользователя для извлечения кэшируемого ресурса. Запросы POST должны подчиняться требованиям, предъявляемым к передаче сообщений, рассмотренным в разделе 7.2. Метод PUT требует, чтобы вложенный объект был запомнен с использованием Request-URI. Если Request-URI относится к уже существующему ресурсу, то вложенный объект следует рассматривать как модифицированную версию объекта на исходном сервере. Если Request-URI не указывает на существующий ресурс и запрашивающий агент пользователя может определить этот URI как новый ресурс, исходный сервер может создать ресурс с этим URI. Если новый ресурс создан, исходный сервер должен информировать об этом агента пользователя, послав код отклик 200 (OK) или 204 (No Content - никакого содержимого) и тем самым, объявляя об успешно выполненном запросе. Если ресурс не может быть создан или модифицирован с помощью Request-URI, должен быть послан соответствующий код отклика, который отражает характер проблемы. Получатель объекта не должен игнорировать любой заголовок Content-* (например, Content-Range), который он не понял или не использовал, а должен в таком случае вернуть код отклика 501 (Not Implemented - не использовано). Если запрос проходит через кэш и Request-URI идентифицирует один или более кэшированных объектов, эти объекты должны рассматриваться как устаревшие. Отклики этого метода не должны кэшироваться. Фундаментальное отличие между запросами POST и PUT отражается в различных значениях Request-URI. URI в запросе POST идентифицирует ресурс, который будет работать со вложенным объектом. Этот ресурс может быть процессом приемки данных, шлюзом к другому протоколу или отдельным объектом, который воспринимает аннотации. Напротив, URI в запросах PUT идентифицируют объекты, заключенные в запросе, - агент пользователя знает, какой URI применить и сервер не должен пытаться посылать запрос другому ресурсу. Если сервер хочет, чтобы запрос был направлен другому URI, он должен послать отклик 301 (Moved Permanently). Агент пользователя может принять свое собственное решение относительно того, следует ли переадресовывать запрос. Один и тот же ресурс может быть идентифицирован многими URI. Например, статья может иметь URI для идентификации "текущей версии", которая отличается от URI, идентифицирующей каждую конкретную версию. В этом случае запрос PUT на общий URI может дать в результате несколько других URI, определенных исходным сервером. HTTP/1.1 не определяет то, как метод PUT воздействует на состояние исходного сервера. Запросы PUT должны подчиняться требованиям передачи сообщения, заданным в разделе 7.2. Метод DELETE требует, чтобы исходный сервер уничтожил ресурс, идентифицируемый Request-URI. Этот метод на исходном сервере может быть отвергнут вмешательством человека (или каким-то иным путем). Клиент не может гарантировать, что операция была выполнена, даже если возвращенный статусный код указывает, что операция завершилась успешно. Однако, сервер не должен сообщать об успехе, если за время отклика он не намерен стереть ресурс или переместить его в недоступное место. Сообщение об успехе должно иметь код 200 (OK), если отклик включает объект, описывающий статус; 202 (Accepted - принято), если операция еще не произведена или 204 (No Content - Никакого содержимого), если отклик OK, но объекта в нем нет. Если запрос проходит через кэш, а Request-URI идентифицирует один или более кэшированных объектов, эти объекты следует считать устаревшими (stale). Отклики на этот метод не кэшируемы. Метод TRACE используется для того, чтобы запустить удаленный цикл сообщения-запроса на прикладном уровне. Конечный получатель запроса должен отослать полученное сообщение назад клиенту в виде тела объекта (код = 200 (OK)). Конечным получателем является либо исходный сервер, либо первый прокси или шлюз для получения значения Max-Forwards (0) в запросе (см. раздел 13.31). Запрос TRACE не должен включать в себя объект. TRACE позволяет клиенту видеть, что получено на другом конце цепи запроса и использовать эти данные для тестирования или диагностики. Значение поля заголовка Via (раздел 13.44) представляет особый интерес, так как оно позволяет отследить всю цепочку запроса. Использование поля заголовка Max-Forwards позволяет клиенту ограничить длину цепи запроса, которая полезна для тестирования цепи прокси, переадресующих сообщения по замкнутому кругу. В случае успеха отклик должен содержать все сообщение-запрос с Content-Type = "message/http". Отклики этого метода не должны кэшироваться. 4.5.6.1.9. Определения статусных кодов Ниже описаны статусные коды, включая то, каким методам они соответствуют, и какая метаинформация должна присутствовать в откликах. Этот класс статусного кода индицирует информационный отклик, состоящий только из статусной строки и опционных заголовков с пустой строкой в конце. Так как HTTP/1.0 не определяет каких-либо статусных кодов 1xx, серверы не должны посылать отклики 1xx клиентам HTTP/1.0 за исключением случаев отладки экспериментальных протокольных версий. 9.1.1. 100 Continue (продолжение) Клиент может продолжать работу, получив этот отклик. Этот промежуточный отклик используется для информирования клиента о том, что начальная часть запроса получена и пока не отклонена сервером. Клиенту следует продолжить отправлять оставшуюся часть запроса, если же запрос уже отправлен, то игнорировать этот отклик. Сервер должен послать окончательный отклик по завершении реализации запроса. 9.1.2. 101 Switching Protocols (Переключающие протоколы) Сервер оповещает клиента о том, что он понял и принял к исполнению запрос. С помощью поля заголовка сообщения Upgrade (раздел 13.41) клиент уведомляется об изменении прикладного протокола для данного соединения. Сервер переходит на протокол, определенный в поле заголовка отклика Upgrade, немедленно после получения пустой строки, завершающей отклик 101. Протокол следует изменять лишь в случае, если он предоставляет существенные преимущества. Например, переключение на новую версию HTTP предоставляет преимущества по отношению к старой версии, а переключение на синхронный протокол реального времени может иметь преимущество, когда ресурс использует это свойство. 9.2. Successful 2xx (Успешная доставка) Этот класс статусного кода индицирует, что запрос клиента благополучно получен, понят и принят к исполнению. Запрос успешно исполнен. Информация, возвращаемая вместе с откликом, зависит от метода, использованного запросом, например: GET - в качестве отклика посылается объект, соответствующий запрошенному ресурсу; Запрос исполнен и в результате создан новый ресурс. Вновь созданный ресурс может быть доступен через URI, присланный в объекте отклика, со значащей частью URL ресурса в поле заголовка Location. Исходный сервер должен создать ресурс до отправки статусного кода 201. Если операция не может быть выполнена немедленно, сервер вместо этого должен откликнуться статусным кодом 202 (Accepted). Запрос был принят для исполнения, но обработка запроса не завершена. Запрос может обрабатываться или нет, так как он был блокирован в процессе исполнения. Не существует механизма повторной посылки статусного кода для асинхронных операций вроде этой. Целью отклика 202 является разрешить серверу принять запрос для некоторого другого процесса (возможно процесса, запускаемого раз в день), не требуя того, чтобы соединение агента пользователя с сервером сохранялось до завершения процесса. Объект, возвращаемый этим откликом должен включать в себя текущий статус запроса и указатель на статус-монитор или некоторую оценку того, когда пользователь может ожидать завершения реализации запроса. 9.2.4. 203 Non-Authoritative Information (Не надежная информация) Присылаемая в ответ метаинформация в заголовке объекта не идентифицируется, как полученная от исходного сервера, ее следует скорее считать косвенной, полученной опосредовано. Например, включение местной аннотационной информации о ресурсе может иметь последствия для мета информации, известной исходному серверу. Использование данного кода отклика не является обязательным и целесообразно лишь в случае, когда отклик мог бы быть равен 200 (OK). 9.2.5. 204 No Content (Никакого содержимого) Сервер исполнил запрос, но нет никакой новой информации для отсылки. Этот отклик первоначально предназначался для разрешения ввода, не вызывая изменения активного документа агента пользователя. Отклик может включать новую метаинформацию в форме заголовков объектов, которая должна быть передана для документа, отображаемого агентом пользователя. Отклик 204 не должен включать тела сообщения и всегда завершается пустой строкой после полей заголовка. 9.2.6. 205 Reset Content (Сброс содержимого) Сервер исполнил запрос и агент пользователя должен вернуть документ к виду, который он имел в момент посылки запроса. Этот отклик первоначально предназначался для обеспечения ввода при выполнении пользователем операции, за которой следует очистка формы, в которую произведен ввод, так что пользователь может начать другую операцию ввода. Отклик не должен включать в себя объект. 9.2.7. 206 Partial Content (Частичное содержимое) Сервер исполнил частично запрос GET для заданного ресурса. Запрос должен включать поле заголовка Range (раздел 13.36), указывающее на желательный интервал (range). Отклик должен включать поле заголовка Content-Range (раздел 13.17), указывающее диапазон данных, включенных в отклик, или множественные байтные интервалы (multipart/byteranges) Content-Type, включающие поля Content-Range для каждой из частей. Если множественные байтные интервалы не используются, поле заголовка Content-Length в отклике должно соответствовать действительному числу октетов в теле сообщения. Кэш, который не поддерживает заголовки Range и Content-Range, не должен кэшировать отклики 206 (Partial). 9.3. Redirection 3xx (Переадресация) Этот класс статусных кодов указывает, что для выполнения запроса, нужны дальнейшие действия агента пользователя. Необходимые действия могут быть выполнены агентом пользователя без взаимодействия с пользователем, тогда и только тогда, когда используемый метод соответствует GET или HEAD. Агент пользователя не должен автоматически переадресовывать запрос более чем 5 раз, так как такая переадресация обычно свидетельствует о зацикливании запроса. 9.3.1. 300 Multiple Choices (Множественный выбор) Запрошенный ресурс соответствует какому-то представлению из имеющегося набора представлений, каждое со своим адресом. Имеется информация (раздел 11), полученная в результате согласования под управлением агента пользователя, так что пользователь (или агент пользователя) может выбрать предпочтительное представление и переадресовать свой запрос по соответствующему адресу. Если это только не был запрос HEAD, отклик должен включать объект, содержащий список характеристик ресурсов и их адресов, из которых пользователь или агент пользователя может выбрать наиболее подходящий. Формат объекта специфицируется типом среды, заданным полем заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может быть выполнен автоматически. Однако, эта спецификация не определяет какого-либо стандарта для такого автоматического выбора. Если сервер имеет предпочтительный вариант представления, ему следует включить соответствующий URL этого представления в поле Location. Агент пользователя может использовать значение поля Location для реализации автоматического выбора. Этот отклик может кэшироваться, если не указано обратного. 9.3.2. 301 Moved Permanently (Постоянно перемещен) Запрошенному ресурсу был приписан новый постоянный URI и любая будущая ссылка на этот ресурс должна делаться с использованием одного из присланных URI. Клиенты с возможностью редактирования связей должны, где возможно, автоматически менять связи для ссылок Request-URI на одну или более новых ссылок, присланных сервером. Этот отклик можно кэшировать, если не указано обратного. Если новый URI является адресом (location), его URL должен быть задан в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI. Если получен статусный код 301 в ответ на запрос, отличный от GET или HEAD, агент пользователя не должен автоматически переадресовывать запрос, если только это не может быть подтверждено пользователем, так как такая переадресация может изменить условия, при которых направлен запрос. Замечание: При автоматической переадресации запроса POST, получив статусный код 301, некоторые существующие агенты пользователя HTTP/1.0 ошибочно меняют его на запрос GET. 9.3.3. 302 Moved Temporarily (Временно перемещен) Запрошенный ресурс размещается временно под различными URI. Так как переадресация может быть случайно изменена, клиент должен продолжать использовать Request-URI для будущих запросов. Этот отклик допускает кэширование, если имеются соответствующие указания в полях заголовка Cache-Control или Expires. Если новый URI является адресом (location), его URL должен задаваться полем Location отклика. Если запрошенный метод не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI. Если в ответ на запрос, отличный от GET или HEAD, получен статусный код 302, агент пользователя не должен автоматически переадресовывать запрос, если это не может быть подтверждено пользователем, так как это может изменить условия, при которых был выдан запрос. Замечание: Когда после получения статусного кода 302 автоматически переадресуется запрос POST, некоторые существующие агенты пользователя HTTP/1.0 ошибочно меняют его на запрос GET. 9.3.4. 303 See Other (смотри другие) Отклик на запрос может быть найден под разными URI. Его следует извлекать с помощью метода GET. Этот метод первоначально создан для того, чтобы позволить переадресацию агента пользователя на выбранный ресурс при запуске скрипта с помощью POST. Новый URI не является заменой ссылки для первоначально запрошенного ресурса. Отклик 303 не кэшируется, но отклик на второй (переадресованный) запрос может кэшироваться. Если новый URI является адресом (location), его URL должно быть задано в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать гипертекстовую ссылку на новый URI. 9.3.5. 304 Not Modified (Не модифицировано) Если клиент выполнил условный запрос GET и получил доступ, а документ не был модифицирован, сервер должен реагировать этим статусным кодом. Отклик не должен содержать тела сообщения. Отклик должен включать поля заголовка:
Если условный GET использовал строгий валидатор кэша (см. раздел 12.8.3), отклик не должен содержать других заголовков объекта. В противном случае (напр., условный GET использовал слабый валидатор), отклик не должен включать в себя другие заголовки. Это предотвращает несогласованности между кэшированными телами объектов и актуализованными заголовками (updated headers). Если отклик 304 указывает на то, что объект не кэширован, тогда кэш должен игнорировать отклик и повторить запрос уже в безусловном режиме. Если кэш использует полученный отклик 304 для актуализации записи в кэше, то кэш должен выполнить актуализацию с учетом новых значений полей, присланных в отклике. Отклик 304 не должен включать в себя тело сообщения и, по этой причине всегда завершается пустой строкой после полей заголовка. 9.3.6. 305 Use Proxy (Используйте прокси) Запрошенный ресурс должен иметь доступ через прокси-сервер, указанный в поле Location. Поле Location задает URL прокси-сервера. Предполагается, что получатель повторит запрос через прокси. 9.4. Client Error 4xx (Ошибка клиента) Класс статус кодов 4xx предназначен для случаев, когда клиент допустил ошибку. За исключением случая отклика на запрос HEAD, серверу следует включить объект, содержащий объяснение ошибочной ситуации, а также указать, является ли ситуация временной или постоянной. Эти статусные коды применимы к любому методу запросов. Агенту пользователя следует отобразить все объекты. Замечание. Если клиент посылает данные, реализация сервера, использующая протокол TCP, должна позаботиться о том, чтобы клиент получил пакет, содержащий отклик, до того как сервер закроет данное соединение. Если клиент продолжает посылку данных серверу после закрытия связи, TCP-уровень сервера должен послать клиенту пакет reset (сброс), который может стереть содержимое входного буфера клиента до того, как оно будет прочитано и интерпретировано приложением HTTP. 9.4.1. 400 Bad Request (Плохой запрос) Запрос может быть не понят сервером из-за ошибочного синтаксиса. Клиенту не следует повторять запрос без модификации. 9.4.2. 401 Unauthorized (Не авторизован) Запрос требует авторизации пользователя. Отклик должен включать в себя поле заголовка WWW-Authenticate (раздел 13.46), содержащее требование (challenge), применимое к запрошенному ресурсу. Клиент может повторить запрос с соответствующим содержимым поля заголовка Authorization (раздел 13.8). Если запрос уже включал допуск в поле Authorization, тогда отклик 401 указывает на то, что данный допуск не работает. Если отклик 401 содержит то же требование, что и предшествующий отклик, а агент пользователя уже пробовал пройти идентификацию по крайней мере хотя бы раз, тогда пользователю следует предоставить объект, содержащийся в отклике, так как он может содержать полезную диагностическую информацию. Идентификация доступа HTTP описана в разделе 10. Этот код зарезервирован для использования в будущем. 9.4.4. 403 Forbidden (Запрещено) Сервер понял запрос, но отказался его исполнить. Авторизация не поможет и повторять запрос не следует. Если метод запроса не HEAD, а сервер желает открыто объявить причину неисполнения запроса, то ему следует описать соображения, по которым запрос отклонен Этот статусный код обычно используется, когда сервер не хочет показывать, почему запрос отклонен, или когда другой отклик не подходит. 9.4.5. 404 Not Found (Не найдено) Сервер не нашел ничего, отвечающего Request-URI. Не приводится никаких данных о том, являются ли эта ситуация временной или постоянной. Если сервер не хочет сделать эту информацию открытой для клиента, вместо этого может использоваться статусный код 403. Статусный код 410 (Gone - Утрачен) следует использовать, если сервер знает за счет некоторого внутреннего механизма конфигурации, что старый ресурс постоянно недоступен и не имеет нового адреса его размещения. 9.4.6. 405 Method Not Allowed (Метод не разрешен) Метод, специфицированный в Request-Line, не разрешен для ресурса, указанного Request-URI. Отклик должен включать заголовок Allow, содержащий список разрешенных методов для запрошенного ресурса. 9.4.7. 406 Not Acceptable (Не приемлемо) Ресурс, идентифицированный запросом, способен только генерировать объекты откликов, которые имеют характеристики, неприемлемые согласно заголовкам accept, присланным в запросе. Если это не запрос HEAD, отклик должен включать объект, содержащий список доступных характеристик объекта и адреса, где пользователь или агент пользователя может выбрать нечто наиболее подходящее. Формат объекта специфицируется типом среды, приведенным в поле заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, оптимальный выбор может быть сделан автоматически. Однако данная спецификация не определяет какого-либо стандарта для такого автоматического выбора. Замечание. HTTP/1.1 серверам разрешено присылать отклики, которые неприемлемы согласно заголовкам accept, присланным в запросе. В некоторых случаях, может оказаться предпочтительнее послать отклик 406. Агенты пользователя могут просматривать заголовки приходящих откликов с тем, чтобы определить, являются ли они приемлемыми. Если отклик не может быть воспринят, агенту пользователя следует временно прервать прием данных и запросить пользователя принять решение о дальнейших действиях. 9.4.8. 407 Proxy Authentication Required (Необходима идентификация прокси) Этот статусный код подобен 401 (Unauthorized), но указывает, что клиент должен сначала авторизоваться на прокси-сервере. Прокси должен прислать в ответ поле заголовка Proxy-Authenticate (раздел 13.33), содержащего требования, реализуемые на прокси для запрошенного ресурса. Клиент может повторить запрос с подходящим полем заголовка Proxy-Authorization (раздел 13.34). Авторизация доступа HTTP описана в разделе 10. 9.4.9. 408 Request Timeout (Таймаут запроса) Клиент не выдал запрос в пределах временного интервала, в течение которого сервер его ожидал. Клиент может повторить запрос без модификаций в любое время. 9.4.10. 409 Conflict (Конфликт) Выполнение запроса не может быть завершено из-за конфликта с текущим состоянием ресурса. Этот статусный код разрешен в ситуациях, где предполагается, что пользователь может разрешить конфликт и повторно послать запрос. Тело отклика должно включать достаточно информации, чтобы пользователь мог понять причину конфликта. В идеале, объект отклика должен был бы включать достаточно информации для пользователя или агента пользователя для того, чтобы уладить конфликт, однако это невозможно и необязательно. Конфликты наиболее вероятно происходят в результате запроса PUT. Если задействована версия и объект операции PUT вызывает изменение ресурса, которые конфликтуют с изменениями внесенными запросом, выполненным ранее, сервер может использовать отклик 409 для того, чтобы указать на невозможность завершить выполнение запроса. В этом случае объект отклика должен содержать список отличий между двумя версиями формата, определенном откликом Content-Type. Запрошенный ресурс не является более доступным на сервере и не известен указатель переадресации. Это условие следует считать постоянным. Клиенты с возможностями редактирования связей должны ликвидировать ссылки на Request-URI после подтверждения пользователем. Если сервер не знает или не имеет возможности определить, является ли данное условие постоянным или временным, следует использовать отклик со статусным кодом 404 (Not Found). Этот отклик можно кэшировать, если не указано обратного. Отклик 410 первоначально предназначался для того, чтобы помочь работе задач в WWW-среде путем сообщения получателю о том, что ресурс заведомо недостижим и владелец сервера хотел бы, чтобы связи с этим ресурсом были удалены. Такое событие является типичным для ограниченного периода времени и для ресурсов, принадлежащих частным лицам, которые не работают более с данным сервером. Не обязательно отмечать все постоянно недоступные ресурсы, как исчезнувшие (Gone) или сохранять такую пометку произвольное время - это оставлено на усмотрение собственника сервера. 9.4.12. 411 Length Required (Необходима длина) Сервер отказывается принять запрос без определенного значения Content-Length. Клиент может повторить запрос, если он добавит корректное значение поля заголовка Content-Length, содержащего длину тела сообщения. 9.4.13. 412 Precondition Failed (Предварительные условия не выполнены) Предварительные условия, заданные в одном или более полях заголовка запроса, воспринимаются как не выполненные, когда это проверено сервером. Этот код отклика позволяет клиенту установить предварительные условия для метаинформации (данные поля заголовка) текущего ресурса и, таким образом, предотвратить возможность использования запрошенного метода для ресурса, отличного от указанного. 9.4.14. 413 Request Entity Too Large (Объект запроса слишком велик) Сервер отказывается обрабатывать запрос, потому что объект запроса больше, чем сервер способен обработать. Сервер может закрыть соединение, чтобы помешать клиенту продолжать посылать запросы. Если условие является временным, серверу следует включить поле заголовка Retry-After, чтобы указать на временность этого условия, что означает возможность повторения запроса некоторое время спустя. 9.4.15. 414 Request-URI Too Long (URI запроса слишком велик) Сервер отказывается обслужить запрос, потому что Request-URI длиннее, чем сервер способен интерпретировать. Это редкое обстоятельство может возникнуть только, когда клиент не корректно преобразует запрос POST в GET с длинной информацией запроса. При этом клиент ныряет в "черную дыру" переадресаций. Примером может служить преадресованный URL префикс, который указывает на свой суффикс, или случай атаки сервера клиентом, который пытается использовать дыры в системе безопасности, имеющиеся у клиентов с фиксированной емкостью буферов для работы с Request-URI. 9.4.16. 415 Unsupported Media Type (Неподдерживаемый тип среды) Сервер отказывается обслужить запрос, потому что объект запроса имеет формат, неподдерживаемый запрашиваемым ресурсом для указанного метода. Статусный код отклика, начинающийся с цифры "5", указывает на случаи, когда сервер опасается, что он ошибся или не может реализовать запрос. За исключением случаев, когда обрабатывается запрос HEAD, серверу следует включить объект, содержащий объяснение создавшейся ошибочной ситуации и указывающей на то, является ли ситуация временной или постоянной. Агенту пользователя следует отобразить пользователю любой объект, включенный в отклик. Эти коды откликов применимы для любых методов запроса. 9.5.1. 500 Internal Server Error (Внутренняя ошибка сервера) Сервер столкнулся с непредвиденными условиями, которые мешают ему исполнить запрос. 9.5.2. 501 Not Implemented (Не применимо) Сервер не поддерживает функцию, которая должна быть реализована в ходе исполнения запроса. Это адекватный отклик, когда сервер не распознает метод запроса и не способен поддерживать его для данного ресурса. 9.5.3. 502 Bad Gateway (Плохой шлюз) Сервер при работе в качестве шлюза или прокси получил неверный отклик от вышестоящего сервера, к которому он обратился, выполняя запрос. 9.5.4. 503 Service Unavailable (Услуга не доступна) Сервер в данный момент не может обработать запрос в связи с временной перегрузкой или другими сложившимися обстоятельствами. Замечание. Существование статусного кода 503 не предполагает, что сервер должен использовать его, когда оказывается перегруженным. Некоторые серверы могут захотеть просто отказаться устанавливать соединение. 9.5.5. 504 Gateway Timeout (Таймаут шлюза) Сервер при работе в качестве внешнего шлюза или прокси-сервера не получил своевременно отклик от вышестоящего сервера, к которому он обратился, пытаясь исполнить запрос. 9.5.6. 505 HTTP Version Not Supported (Версия не поддерживается) Сервер не поддерживает или отказывается поддерживать версию протокола HTTP, которая была использована в сообщении-запросе. Сервер индицирует, что он не способен или не хочет завершать обработку запроса в рамках главной версии клиента, как это описано в разделе 2.1, в отличие от сообщения об ошибке. Отклику следует содержать объект, описывающий, почему эта версия не поддерживается и какие другие протоколы поддерживаются сервером. 4.5.6.1.10. Идентификация доступа HTTP предлагает простой механизм аутентификации с помощью отклика, который может использоваться сервером, чтобы потребовать от клиента прислать запрос, содержащий аутентификационную информацию. Для определения схемы идентификации он использует лексему произвольной длины, не зависящую от применения строчных или прописных символов, за ней следует список пар атрибут-значение. Элементы списка отделяются друг от друга запятыми. Атрибуты представляют собой параметры, которые определяют аутентификацию в рамках выбранной схемы.
Сообщение-отклик 401 (Unauthorized) используется исходным сервером для посылки требования авторизации агенту пользователя. Этот отклик должен включать в себя поле заголовка WWW-Authenticate, содержащее, по крайней мере, одно требование доступа к запрашиваемому ресурсу.
Атрибут области realm (не зависит от применения строчных или прописных букв) необходим для всех схем идентификации (authentication), которые посылают требования. Значение атрибута realm (чувствительно к применению строчных и прописных букв), в комбинации с каноническим корневым URL (см. раздел 4.1.2) сервера доступа, определяет пространство защиты. Эти области позволяют разделить защищенные ресурсы на сервере на ряд защищенных зон, каждая со своей собственной схемой идентификации и/или идентификационной базой данных. Значением атрибута области является строка, обычно присваиваемая исходным сервером, которая может иметь специфическую емантику для каждой схемы идентификации. Агент пользователя, который хочет идентифицировать себя на сервере, после получения отклика 401 или 411 может сделать это, включив в запрос поле заголовка Authorization. Значение поля Authorization состоит из записей, содержащих идентификационную информацию агента пользователя для области (realm) запрошенного ресурса. credentials = basic-credentials Домен, в пределах которого может автоматически использоваться идентификационная информация, определяется зоной защиты. Если предыдущий запрос был авторизован, та же идентификационная информация может быть использована для всех других запросов в пределах зоны защиты и во временных рамках, заданных схемой идентификации, параметрами и/или предпочтениями пользователя. Если не определено обратного схемой авторизации, одна зона защиты не может быть распространена за пределы ее сервера. Если сервер не хочет принимать идентификационную информацию, присланную в запросе, он должен прислать отклик 401 (Unauthorized). Отклик должен включать поле заголовка WWW-Authenticate, содержащее требование (возможно новое), применимое для запрошенного ресурса, и объект, объясняющий причину отказа. Протокол HTTP не ограничивает приложения только этим простым механизмом авторизации (требование-отклик). Может быть применен дополнительный механизм, такой как шифрование на транспортном уровне или использование инкапсуляции сообщений. Однако в данной спецификации эти дополнительные механизмы не определены. Прокси-серверы должны быть полностью прозрачны по отношению авторизации агентов пользователя. То есть, они должны переадресовывать в неприкосновенном виде заголовки WWW-Authenticate и Authorization, согласно правилам описанным в разделе 13.8. HTTP/1.1 позволяет клиенту передать идентификационную информацию в прокси и обратно с использованием заголовков Proxy-Authenticate и Proxy-Authorization. 10.1 Базовая схема идентификации (Authentication) Базовая схема авторизации базируется на модели, в которой агент пользователя должен идентифицировать себя с помощью имени пользователя и пароля, необходимого для каждой области (realm). Значение атрибута realm должно рассматриваться в виде неотображаемой строки символов, которая может сравниваться с другим значение realm на этом сервере. Сервер обслужит запрос только в случае, если убедится в корректности имени и пароля пользователя для данной зоны защиты Request-URI. Не существует каких-либо опционных параметров авторизации. При получении неавторизованного запроса для URI в пределах зоны защиты (protection space), сервер может реагировать посылкой требования в виде: WWW-Authenticate: Basic realm="WallyWorld" где "WallyWorld" - строка присвоенная сервером для идентификации зоны защиты Request-URI. Чтобы получить авторизацию клиент посылает свое имя и пароль, разделенные символом двоеточие (":"), и закодированные согласно base64. basic-credentials = "Basic" SP basic-cookie Идентификационная информация может быть чувствительной к применению строчных или прописных букв. Если агент пользователя хочет послать имя пользователя "Aladdin" и пароль "Сезам открой", он использует следующее поле заголовка: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Смотри раздел 14 по поводу соображений безопасности, связанных с базовой авторизацией. 10.2 Краткое изложение схемы авторизации Краткое изложение идей авторизации для HTTP представлено в документе RFC-2069 [32]. 4.5.6.1.11. Согласование содержимого Большинство HTTP откликов включают в себя объекты, которые содержат информацию для интерпретации человеком-пользователем. Естественно, желательно обеспечить пользователя наилучшим объектом, соответствующим запросу. К сожалению для серверов и кэшей не все пользователи имеют одни и те же предпочтения и не все агенты пользователя в равной степени способны обрабатывать все типы объектов. По этой причине, HTTP имеет несколько механизмов обеспечения согласования содержимого - процесс выбора наилучшего представления для данного отклика, когда доступны несколько возможностей. Замечание. Это не называется "согласование формата " потому, что альтернативные представления могут принадлежать к одному и тому же типу среды, но использовать различные возможности этого типа, например, различные иностранные языки. Любой отклик, содержащий тело объекта может быть предметом согласования, включая отклики об ошибках. Существует два вида согласования содержимого, которые возможны в HTTP: согласование под управлением сервера и под управлением агента пользователя. Эти два сорта согласования могут использоваться по отдельности или в сочетании. Один из методов, называемый прозрачным согласованием, реализуется, когда кэш использует информацию, полученную от исходного сервера в результате согласования под управлением агента пользователя. Эта информация используется для последующих запросов, где осуществляется согласование под управлением сервера. 11.1 Согласование, управляемое сервером Если выбор наилучшего представления для отклика выполнен с использованием некоторого алгоритма на сервере, такая процедура называется согласованием под управлением сервера. Выбор базируется на доступных представлениях отклика (размеры, в пределах которых он может варьироваться, язык, кодировка и т.д.) и на содержимом конкретных полей заголовка в сообщении-запросе или другой информации, имеющей отношение к запросу (например, сетевой адрес клиента). Согласование, управляемое сервером предпочтительнее, когда алгоритм выбора из числа доступных представлений трудно описать агенту пользователя. Согласование под управлением сервера привлекательно тогда, когда сервер хочет послать свои "наилучшие предложения" клиенту вместе с первым откликом (надеясь избежать задержек RTT последующих запросов, если предложение удовлетворит пользователя). Для того чтобы улучшить предложения сервера, агент пользователя может включить в запрос поля заголовка (Accept, Accept-Language, Accept-Encoding, и т.д.), которые описывают его предпочтения для данного запроса. Согласование под управлением сервера имеет следующие недостатки:
HTTP/1.1 включает в себя следующие поля заголовка запроса для активации согласования, управляемого сервером, через описание возможностей агента пользователя и предпочтений самого пользователя: Accept (раздел 13.1), Accept- Charset (раздел 13.2), Accept-Encoding (раздел 13.3), Accept-Language (раздел 13.4) и User-Agent (раздел 13.42). Однако, исходный сервер не ограничен этими рамками и может варьировать отклик, основываясь на свойствах запроса, включая информацию помимо полей заголовка запроса или используя расширения полей заголовка нерассмотренные в данной спецификации. Исходные серверы HTTP/1.1 должны включать соответствующие, управляемом сервером. Поле Vary описывает пределы, в которых может варьироваться отклик (то есть, пределы, в которых исходный сервер выбирает свои "наилучшие предложения" отклика из многообразия редставлений). HTTP/1.1 общедоступный кэш должен распознавать поле заголовка Vary, когда оно включено в отклик и подчиняется требованиям, описанным в разделе 12.6, где рассматриваются взаимодействия между кэшированием и согласованием содержимого. 11.2. Согласование, управляемое агентом (Agent-driven Negotiation) При согласовании, управляемом агентом, выбор наилучшего представления для отклика выполняется агентом пользователя после получения стартового отклика от исходного сервера. Выбор базируется на списке имеющихся представлений отклика, включенном в поля заголовка (эта спецификация резервирует имя поля Alternates, как это описано в приложении 16.6.2.1,) или в тело объекта исходного отклика, при этом каждое представление идентифицируется своим собственным URI. Выбор из числа представлений может быть выполнен автоматически (если агент пользователя способен на это) или вручную пользователем, выбирая вариант из гипертекстного меню. Согласование, управляемое агентом, имеет преимущество тогда, когда отклик варьируется в определенных пределах (таких как тип, язык или кодирование), когда исходный сервер не способен определить возможности агента пользователя, проанализировав запрос, и вообще, когда общедоступные кэши используются для распределения нагрузки серверов и для снижения сетевого трафика. Согласование под управлением агента имеет тот недостаток, что требуется второй запрос для получения наилучшего альтернативного представления. Этот второй запрос эффективен только тогда, когда используется кэширование. Кроме того, эта спецификация не определяет какого-либо механизма поддержки автоматического выбора, хотя она и не препятствует применению любого такого механизма в рамках расширения HTTP/1.1. HTTP/1.1 определяет статусные коды 300 (Multiple Choices - множественный выбор) и 406 (Not Acceptable - Не приемлем) для активации согласования под управлением агента, когда сервер не хочет или не может обеспечить свой механизм согласования. 11.3 Прозрачное согласование (Transparent Negotiation) Прозрачное согласование представляет собой комбинацию управления сервера и агента. Когда кэш получает форму списка возможных представлений откликов (как в согласовании под управлением агента) и кэшу полностью поняты пределы вариации, тогда кэш становится способным выполнить согласование под управлением сервера для исходного сервера при последующих запросах этого ресурса. Прозрачное согласование имеет преимущество распределения работы согласования, которое в противном случае было бы выполнено исходным сервером. При этом удаляется также задержка, сопряженная со вторым запросом при схеме согласования под управлением агента, когда кэш способен правильно прогнозировать отклик. Эта спецификация не определяет какого-либо механизма для прозрачного согласования, хотя она и не препятствует использованию таких механизмов в будущих версиях HTTP/1.1. Выполнение прозрачного согласования кэшем HTTP/1.1 должно включать в отклик поле заголовка Vary (определяя пределы его вариаций), обеспечивая корректную работу со всеми клиентами HTTP/1.1. HTTP обычно используется для распределенных информационных систем, где эксплуатационные характеристики могут быть улучшены за счет применения кэширования откликов. Протокол HTTP/1.1 включает в себя много элементов, предназначенных для оптимизации такого кэширования. Благодаря тому, что эти элементы завязаны с другими аспектами протокола и из-за их взаимодействия друг с другом, полезно описать базовую схему кэширования в HTTP отдельно от детального рассмотрения методов, заголовков, кодов откликов и т.д. Кэширование представляется бесполезным, если оно значительно не улучшит работу. Целью кэширования в HTTP/1.1 является исключение во многих случаях необходимости посылать запросы, а в некоторых других случаях - полные отклики. При этом уменьшается число необходимых RTT для многих операций. Для этих целей используется механизм "истечения срока" (expiration) (см. раздел 12.2). Одновременно снижаются требования к полосе пропускания сети, для чего применяется механизм проверки пригодности (см. раздел 12.3). Требования к рабочим характеристикам, доступности и работе без соединения заставляют нас несколько снизить семантическую прозрачность. Протокол HTTP/1.1 позволяет исходным серверам, кэшам и клиентам снизить прозрачность, когда необходимо. Так как непрозрачность операций может поставить в тупик недостаточно опытных пользователей, а также привести к определенной несовместимости для некоторых серверных приложений (таких как торговля по заказу), протокол рекомендует не убирать прозрачность полностью, а лишь несколько ослабить. Следовательно, протокол HTTP/1.1 обеспечивает следующие важные моменты:
Базовым принципом является возможность для клиентов детектировать любое ослабление семантической прозрачности. Замечание. Разработчики серверов, кэшей или клиентов могут столкнуться с решениями, которые не обсуждались в данной спецификации. Если решение может повлиять на семантическую прозрачность, разработчик может ошибаться относительно прозрачной работы, не проведя детального анализа и не убедившись, что нарушение такой прозрачности дает существенные преимущества. Корректный кэш должен реагировать на запрос откликом новейшей версии, которой он владеет. Разумеется, отклик должен соответствовать запросу (см. разделы 12.5, 12.6, и 12.12) и отвечать одному из следующих условий:
Если кэш не может осуществлять обмен с исходным сервером, он должен реагировать в соответствии с вышеприведенными правилами, если отклик может быть корректно обслужен, в противном случае он должен отослать сигнал ошибки или предупреждения, указывающий, что имел место отказ в системе коммуникаций. Если кэш получает отклик (полный отклик или код 304 (Not Modified)), который уже не является свежим, кэш должен переадресовать его запросившему клиенту без добавления нового предупреждения, и не удаляя существующего заголовка Warning. Кэшу не следует пытаться перепроверить отклик, так как это может привести к бесконечному зацикливанию. Агент пользователя, который получает устаревший отклик без Warning, может отобразить предупреждение для пользователя. Когда кэш присылает опосредованный отклик, который "недостаточно свеж" (с точки зрения условия 2 раздела 12.1), к нему должно быть присоединено предупреждение об этом с использованием заголовка Warning. Это предупреждение позволяет клиентам предпринять соответствующие действия. Предупреждения могут использоваться для других целей, как кэшами так и другими системами. Использование предупреждения, а не статусного кода ошибки, отличает эти отклики от действительных отказов в системе. Предупреждения всегда допускают кэширование, так как они никогда не ослабляют прозрачности отклика. Это означает, что предупреждения могут передаваться HTTP/1.0 кэшам без опасения, что такие кэши просто передадут их как заголовки объектов отклика. Предупреждениям приписаны номера в интервале от 0 до 99. Данная спецификация определяет номера кодов и их значения для каждого из предупреждений, позволяя клиенту или кэшу обеспечить во многих случаях (но не во всех) автоматическую обработку ситуаций. Предупреждения несут в себе помимо кода и текст. Текст может быть написан на любом из естественных языков (предположительно базирующемся на заголовках Accept клиента) и включать в себя опционное указание того, какой набор символов используется. К отклику может быть присоединено несколько предупреждений (исходным сервером или кэшем), включая несколько предупреждений с идентичным кодом. Например, сервер может выдать одно и то же предупреждение на английском и мордовском. Когда к отклику присоединено несколько предупреждений, не будет практичным и разумным отображать их все на экране для пользователя. Эта версия HTTP не специфицирует строгих правил приоритета для принятия решения, какие предупреждения отображать и в каком порядке, но предлагает некоторые эвристические соображения. Заголовок Warning и определенные в настоящий момент предупреждения описаны в разделе 13.45. 12.3 Механизмы управления кэшем Базовым механизмом кэша в HTTP/1.1 (времена таймаутов и валидаторы) являются неявные директивы кэша. В некоторых случаях серверу или клиенту может потребоваться выдать прямую директиву кэшу. Для этих целей используется заголовок Cache-Control. Заголовок Cache-Control позволяет клиенту или серверу передать большое число директив через запросы или отклики. Эти директивы переписывают указания, которые действуют по умолчанию при реализации алгоритма работы кэша. Если возникает явный конфликт между значениями заголовков, то используется наиболее регламентирующее требование (то есть, то, которое наиболее вероятно сохраняет прозрачность семантики). Однако в некоторых случаях директивы Cache-Control сформулированы так, что явно ослабляют семантическую прозрачность (например, "max-stale" или "public"). Директивы Cache-Control подробно описаны в разделе 13.9. 12.4 Прямые предупреждения агента пользователя Многие агенты пользователя позволяют переписывать базовый механизм кэширования. Например, агент пользователя может специфицировать то, какие кэшированные объекты (даже явно старые) не проверять на новизну. Или агент пользователя может всегда добавлять "Cache-Control: max-stale=3600" к каждому запросу. Если пользователь переписал базовый механизм кэширования, агент пользователя должен явно указать всякий раз, когда это важно, что отображаемая информация не отвечает требованиям прозрачности (в частности, если отображаемый объект известен как устаревший). Так как протокол обычно разрешает агенту пользователя определять, является ли отклик устаревшим, такая индикация нужна только тогда, когда это действительно случится. Для такой индикации не нужно диалоговое окно; это может быть иконка (например, изображение гнилой рыбы) или какой-то иной визуальный индикатор. Если пользователь переписал механизм кэширования таким образом, что он непомерно понизил эффективность кэша, агент пользователя должен непрерывно отображать индикацию (например, изображение горящих денег), так чтобы пользователь, беспечно расходующий ресурсы, страдал от заметной задержки откликов на его действия. 12.5 Исключения для правил и предупреждений В некоторых случаях оператор кэша может выбрать такую конфигурацию, которая возвращает устаревшие отклики, даже если клиенты этого не запрашивали. Это решение не должно приниматься легко, но может быть необходимо по причинам доступности или эффективности, особенно когда кэш имеет плохую связь с исходным сервером. Всякий раз, когда кэш возвращает устаревший отклик, он должен пометить его соответствующим образом (используя заголовок Warning). Это позволяет клиентскому программному обеспечению предупредить пользователя о возможных проблемах. Такой подход позволяет также агенту пользователя предпринять шаги для получения "свежего" отклика или информации из первых рук. По этой причине кэшу не следует присылать устаревшие отклики, если клиент запрашивает информацию из первых рук, если только невозможно это сделать по техническим или политическим причинам. 12.6 Работа под управлением клиента Когда основным источником устаревшей информации является исходный сервер (и в меньшей мере промежуточные кэши), клиенту может быть нужно контролировать решение кэша о том, следует ли присылать кэшированный отклик без его проверки. Клиенты выполняют это, используя несколько директив заголовка Cache-Control. Запрос клиента может специфицировать максимальный возраст, который он считает приемлемым для не верифицированного отклика. Клиент может также специфицировать минимальное время, в течение которого отклик еще считается пригодным для использования. Обе эти опции увеличивают ограничения, накладываемые на работу кэша. Клиент может также специфицировать то, что он будет воспринимать устаревшие отклики с возрастом не более заданного. Это ослабляет ограничения, налагаемые на работу кэшей и, таким образом, может привести к нарушению семантической прозрачности, заданной исходным сервером, хотя это может быть необходимо для поддержания автономной работы кэша в условиях плохой коннективности.
12.7. Модель истечения срока годности
Кэширование в HTTP работает наилучшим образом, когда кэши могут полностью исключить запросы к исходному серверу. Другими словами, кэш должен возвращать "свежий" отклик без обращения к серверу. Предполагается, что серверы припишут в явном виде значения времени пригодности (expiration time) откликам в предположении, что объекты вряд ли изменятся семантически значимым образом до истечения этого времени. Это сохраняет семантическую прозрачность при условии, что время жизни выбрано корректно. Механизм времени пригодности (expiration) применим только к откликам, взятым из кэша, а не к откликам, полученным из первых рук и переадресованных запрашивающему клиенту. Если исходный сервер хочет усилить семантическую прозрачность кэша, тогда он может установить время истечения действия в прошлое, чтобы проверялся каждый запрос. Это означает, что всякий запрос изначально будет считаться устаревшим, и кэш будет вынужден проверить его прежде чем использовать для последующих запросов. О более жестких методах вынуждения проверки действенности отклика смотри раздел 13.9.4. Если исходный сервер хочет заставить любой HTTP/1.1 кэш, вне зависимости от его конфигурации проверять каждый запрос, он может использовать директиву Cache-Control "must-revalidate" (см. раздел 13.9). Серверы определяют реальные времена сроков пригодности, используя заголовок Expires, или директиву максимального возраста заголовка Cache-Control. Время пригодности (expiration time) не может использоваться для того, чтобы заставить агента пользователя обновить картинку на дисплее или перезагрузить ресурс; его семантика применима только для механизма кэширования, а такой механизм нуждается только в контроле истечения времени жизни ресурса, когда инициируется новый запрос доступа к этому ресурсу. 12.7.2 Эвристический контроль пригодности Так как исходные сервера не всегда предоставляют значение времени пригодности в явном виде, HTTP кэши присваивают им значения эвристически, используя алгоритмы, которые привлекают для оценки вероятного значения времени пригодности другие заголовки (такие как Last-Modified time). Спецификация HTTP/1.1 не предлагает каких-либо специальных алгоритмов, но налагает предельные ограничения на полученный результат. Так как эвристические значения времени жизни могут подвергнуть риску семантическую прозрачность, они должны использоваться с осторожностью. Предпочтительнее, чтобы исходные серверы задавали время пригодности явно. Для того чтобы узнать является ли запись в кэш свежей, кэшу нужно знать превышает ли его возраст предельное время жизни. То, как вычислить время пригодности, обсуждается в разделе 12.7.4. Этот раздел описывает метод вычисления возраста отклика или записи в кэше. В этом обсуждении используется термин "сейчас" для обозначения "текущего показания часов на ЭВМ, выполняющей вычисление". ЭВМ, которая использует HTTP, и в особенности ЭВМ, работающие в качестве исходных серверов и кэшей, должны использовать NTP [28] или некоторый схожий протокол для синхронизации их часов с использованием общего точного временного стандарта. Следует обратить внимание на то, что HTTP/1.1 требует от исходного сервера посылки в каждом отклике заголовка Date, сообщая время, когда был сгенерирован отклик. Мы используем термин "date_value" для обозначения значения заголовка Date, в форме, приемлемой для арифметических операций. HTTP/1.1 использует заголовок отклика Age для того, чтобы облегчить передачу информации о возрасте объектов между кэшами. Значение заголовка Age равно оценке отправителя времени, прошедшего с момента генерации отклика исходным сервером. В случае кэшированного отклика, который был перепроверен исходным сервером, значение Age базируется на времени перепроверки, а не на времени жизни оригинального отклика. По существу значение Age равно сумме времени, в течение которого отклик был резидентен в каждом из кэшей вдоль пути от исходного сервера, плюс время распространения данных по сети. Мы используем термин "age_value" для значения поля заголовка Age, в удобном для выполнения арифметических операций формате. Возраст отклика может быть вычислен двумя совершенно независимыми способами.
Таким образом, мы имеем два независимых способа вычисления возраста отклика при его получении, допускается их комбинирование, например: corrected_received_age = max(now - date_value, age_value) и, поскольку мы имеем синхронизованные часы, или все узлы вдоль пути поддерживают HTTP/1.1, получается надежный (консервативный) результат. Заметьте, что поправка применяется в каждом кэше HTTP/1.1 вдоль пути так, что, если встретится на пути кэш HTTP/1.0, правильное значение возраста будет получено потому, что его часы почти синхронизованы. Нам не нужна сквозная синхронизация (хотя ее не плохо бы иметь). Из-за задержек, вносимых сетью, значительное время может пройти с момента генерации отклика сервером и получением его следующим кэшем или клиентом. Если не внести поправки на эту задержку, можно получить неправдоподобные значения возраста отклика. Так как запрос, который определяет возвращаемое значение Age, должен быть инициирован до генерации этого значения Age, мы можем сделать поправку на задержки, вносимые сетью путем записи времени, когда послан запрос. Затем, когда получено значение Age, оно должно интерпретироваться относительно времени посылки запроса, а не времени когда был получен отклик. Этот алгоритм выдает результат, который не зависит от величины сетевой задержки. Таким образом, вычисляется: corrected_initial_age = corrected_received_age + (now - request_time) где "request_time" равно времени (согласно местным часам), когда был послан запрос, вызвавший данный отклик. Резюме алгоритма вычисления возраста при получении отклика кэшем: /*
apparent_age = max(0, response_time - date_value); Когда кэш посылает отклик, он должен добавить к corrected_initial_age время, в течение которого отклик оставался резидентно локальным. Он должен ретранслировать этот полный возраст, используя заголовок Age, следующему кэшу-получателю. Заметьте, что клиент не может надежно сказать, что отклик получен из первых рук, но присутствие заголовка Age определенно указывает на то, что это не так. Кроме того, если значение в отклике соответствует более раннему времени, чем местное время запроса клиента, отклик, вероятно, получен не из первых рук (в отсутствие серьезного сбоя часов). 12.4 Вычисление времени жизни (Expiration) Для того, чтобы решить, является ли отклик свежим или устаревшим, нам нужно сравнить его время жизни с возрастом. Возраст вычисляется так, как это описано в разделе 12.3. Этот раздел описывает то, как вычисляется время жизни, и как определяется, истекло ли время жизни отклика. В обсуждении, приведенном ниже, величины могут быть представлены в любой форме, удобной для выполнения арифметических операций. Мы используем термин "expires_value" для обозначения содержимого заголовка Expires. Для обозначения числа секунд, определенного директивой максимального возраста заголовка Cache-Control отклика (см. раздел 13.9), используется термин "max_age_value". Директива максимального возраста имеет приоритет перед Expires, так если max-age присутствует в отклике, вычисление производится просто: freshness_lifetime = max_age_value В противном случае, если в отклике присутствует Expires, то вычисления осуществляются следующим образом: freshness_lifetime = expires_value - date_value Заметьте, ни одно из этих вычислений не зависит от синхронизации и корректной работы местных часов, так как вся исходная информация получается от исходного сервера. Если ни Expires, ни Cache-Control: max-age не определяют максимальный возраст отклика, а отклик не содержит других ограничений на кэширование, кэш может вычислить время жизни, используя эвристику. Если эта величина больше 24 часов, кэш должен присоединить к отклику Warning 13, если такое предупреждение еще не добавлено. Кроме того, если отклик имеет время Last-Modified, эвристическое значение времени жизни должно быть не больше некоторой доли времени, прошедшего со времени модификации. Типичное значение этой доли может составлять 10%. Расчет того, истекло ли время жизни отклика, достаточно прост: response_is_fresh = (freshness_lifetime > current_age) 12.5 Устранение неопределенности значений времени жизни Из-за того, что значения времени жизни часто назначаются оптимистически, может так случиться, что два кэша содержат две "свежих" записи одного и того же ресурса, которые различаются. Если клиент, выполняя извлечение ресурса, получает отклик не из первых рук на запрос, который был свежим в своем собственном кэше, а заголовок Date в его кэше новей, чем Date нового отклика, тогда клиент может игнорировать этот отклик. Если это так, он может повторить запрос с директивой "Cache-Control: max-age=0" (см. раздел 13.9), чтобы усилить контроль со стороны исходного сервера. Если кэш имеет два свежих отклика для одного и того же представления с различными указателями корректности (validator), он должен использовать тот, который имеет современный заголовок Date. Эта ситуация может возникнуть, когда кэш извлекает отклик из других кэшей, или потому, что клиент запросил перезагрузку или повторную проверку корректности заведомо свежего объекта. 12.6 Неопределенность из-за множественных откликов Из-за того, что клиент может получать отклики по большому числу различных маршрутов, так что некоторые отклики проходят через одну последовательность кэшей, а другие, через другую, клиент может получить их не в той последовательности в какой они были посланы исходным сервером. Хотелось бы, чтобы клиент использовал наиболее свежие оклики, даже если срок годности старых еще не истек. Ни метка объекта, ни значение времени жизни не могут определять порядок откликов, так как возможно, что более поздний отклик имеет срок годности, который истекает раньше. Однако, спецификация HTTP/1.1 требует передачи заголовка Date в каждом отклике, а значения Date должны быть кратны одной секунде. Когда клиент пытается перепроверить запись в кэше, а отклик, который он получает, содержит заголовок Date, который оказывается старше, чем у другой уже существующей записи, тогда клиенту следует безусловно повторить запрос и включить Cache-Control: max-age=0 Чтобы заставить некоторые промежуточные кэши сверить свои копии непосредственно с исходным сервером, или Cache-Control: no-cache Чтобы заставить любые промежуточные кэши получит новые копии от исходного сервера. Если значения Date равны, тогда клиент может использовать любой отклик (или может, если он особенно осторожен, затребовать новый отклик). Серверы не должны зависеть от возможности клиентов четкого выбора между откликами, сгенерированными в пределах одной и той же секунды, если их сроки пригодности перекрываются. 12.8 Модель проверки пригодности Когда кэш имеет устаревшую запись, которую бы он хотел использовать в качестве отклика на запрос клиента, он сначала должен произвести сверку с базовым сервером (или возможно промежуточным кэшем, содержащим свежий отклик), чтобы убедиться, что кэшированная запись все еще применима. Мы это называем проверкой пригодности записи кэша ("validating"). Так как мы не хотим пересылки всей записи, если с ней все в порядке, и мы не хотим тратить лишнее время из-за RTT в случае, если запись более не пригодна, протокол HTTP/1.1 поддерживает использование условных методов. Ключевой особенностью протокола для поддержки условных методов являются так называемые "валидаторы" кэша. Когда исходный сервер генерирует полный отклик, он подключает к нему некоторые виды валидаторов, которые хранятся вместе с самой записью в кэше. Когда клиент (агент пользователя или прокси-кэш) выполняет условный запрос ресурса, для которого он имеет запись в кэше, он добавляет соответствующий валидатор к запросу. Сервер сверяет полученный валидатор с текущим валидатором объекта и, если они совпадают, посылается отклик с соответствующим статусным кодом (обычно, 304 (Not Modified)) и без тела объекта. В противном случае он возвращает полный отклик (включая тело объекта). Таким образом, мы избегаем передачи полного отклика, если валидаторы взаимно согласованы. Замечание. Функции сравнения, используемые при решении, согласуются ли между собой валидаторы, определены в разделе 12.8.3. В HTTP/1.1 условный запрос выглядит точно также как и обычный запрос того же самого ресурса, за исключением того, что он несет в себе специальный заголовок (который содержит валидатор), и неявно меняет метод (обычный GET) на условный. Протокол предусматривает как положительное, так и отрицательное значения условий проверки пригодности записей кэша. То есть, можно запросить, чтобы был реализован этот метод тогда и только тогда, когда валидатор подходит, или тогда и только тогда, когда ни один валидатор не подходит. Замечание. Отклик, который не имеет валидатора, может кэшироваться и использоваться до истечения его срока годности, если только это явно не запрещено директивой Cache-Control. Однако, кэш не может выполнить условную доставку ресурса, если он не имеет валидатора для запрашиваемого объекта, что означает отсутствие возможности его актуализации после истечения срока годности. 12.8.1 Даты последней модификации Значение поля заголовка объекта Last-Modified часто используется кэшем в качестве валидатора. Иными словами, запись в кэше рассматривается как пригодная, если объект не был модифицирован с момента, указанного в Last-Modified. 12.8.2 Валидаторы кэша для меток объектов (Entity Tag Cache Validators) Значение поля заголовка объекта ETag (Entity Tag - метка объекта), представляет собой "непрозрачный" валидатор кэша. Это может гарантировать большую надежность при контроле пригодности в ситуациях, когда неудобно запоминать модификации дат, где недостаточно односекундного разрешения для значения даты HTTP или где исходный сервер хочет избежать определенных парадоксов, которые могут возникнуть от использования дат модификации. Метки объекта обсуждаются в разделе 3.10. Заголовки, используемые с метками объектов, рассмотрены в разделах 13.20, 13.25, 13.26 и 13.43. 12.8.3 Слабые и сильные валидаторы Так как исходные серверы и кэши будут сравнивать два валидатора, чтобы решить, представляют ли они один и тот же объект, обычно подразумевается, что, если объект (тело объекта или любой заголовок) изменяется каким-либо образом, то и сопряженный валидатор изменится. Если это так, такой валидатор называется "сильным ". Однако могут встретиться случаи, когда сервер предпочитает изменять валидатор только при семантически существенных изменениях. Валидатор, который не изменяется всякий раз при изменении ресурса, называется "слабым". Метки объекта обычно являются "сильными валидаторами", но протокол предлагает механизм установки "слабой" метки объекта. Можно считать, что сильный валидатор это такой, который изменяется, если меняется хотя бы один бит в объекте, в то время как значение слабого изменяется при вариации значения объекта. Альтернативой можно считать точку зрения, при которой сильный валидатор является частью идентификатора конкретного объекта, в то время как слабый валидатор является частью идентификатора набора семантически эквивалентных объектов. Замечание. Примером сильного валидатора является целое число, которое увеличивается на единицу всякий раз, когда в объект вносится какое-либо изменение. Время модификации объекта при односекундном разрешении может быть лишь слабым валидатором, так как имеется возможность того, что ресурс может быть модифицирован дважды в течение одной и той же секунды. Поддержка слабых валидаторов является опционной. Однако слабый валидатор позволяет более эффективно кэшировать эквивалентные объекты. Валидатор используется либо, когда клиент генерирует запрос и включает валидатор в поле заголовка проверки годности, или когда сервер сравнивает два валидатора. Сильные валидаторы могут использоваться в любом контексте. Слабые валидаторы применимы только в контексте, который не зависит от точной эквивалентности объектов. Например, как один, так и другой вид валидаторов применим для условного GET. Однако, только сильный валидатор применим для фрагментированного извлечения ресурсов, так как в противном случае клиент может прервать работу с внутренне противоречивым объектом. Единственной функцией протокола HTTP/1.1, определенной для валидаторов, является сравнение. Существует две функции сравнения валидаторов, в зависимости от того, допускает ли контекст использование слабых валидаторов или нет:
Функция слабого сравнения может быть использована для простых (non-subrange - не фрагментных) GET-запросов. Функция сильного сравнения должна быть использована во всех прочих случаях. Метка объекта является сильной, если она не помечена явно как слабая. В разделе 2.11 рассматривается синтаксис меток объектов. Параметр Last-Modified time, при использовании в качестве валидатора запроса, является неявно (подразумевается) слабым, если не возможно установить, что он сильный, используя следующие правила:
или
Этот метод базируется на том факте, что, если два различных отклика были посланы исходным сервером в пределах одной и той же секунды, но оба имеют одно и то же время Last-Modified, тогда, по крайней мере, один из этих откликов имеет значение Date равное его времени Last-Modified. Произвольный 60-секундный лимит предохраняет против возможности того, что значения Date и Last-Modified сгенерированы с использованием различных часов или в несколько разные моменты времени при подготовке отклика. Конкретная реализация может использовать величину больше 60 секунд, если считается, что 60 секунд слишком мало. Кэш или исходный сервер, получающий условный запрос кэша, отличный от GET-запроса, должен использовать функцию сильного сравнения, чтобы оценить условие. Эти правила позволяют кэшам HTTP/1.1 и клиентам безопасно произвести фрагментный доступ к ресурсам на глубину, которая получена от серверов HTTP/1.0. 12.8.4 Правила того, когда использовать метки объекта и даты последней модификации Мы принимаем набор правил и рекомендаций для исходных серверов, клиентов и кэшей относительно того, когда должны использоваться различные типы валидаторов и для каких целей. Исходный сервер HTTP/1.1:
Другими словами предпочтительным поведением для исходного сервера HTTP/1.1 является посылка сильной метки объекта и значения Last-Modified. Для сохранения легальности сильная метка объекта должна изменяться всякий раз, когда каким-либо образом меняется ассоциированное значение объекта. Слабую метку объекта следует менять всякий раз, когда соответствующий объект изменяется семантически значимым образом. Замечание. Для того, чтобы обеспечить семантически прозрачное кэширование, исходный сервер должен избегать повторного использования специфических, сильных меток для двух разных объектов, или повторного использования специфических, слабых меток для двух семантически разных объектов. Записи в кэш могут существовать сколь угодно долгое время вне зависимости от времени годности. Таким образом, может оказаться неразумным ожидать, что кэш никогда вновь не попытается перепроверить запись, используя валидатор, который он получил в какой-то момент в прошлом. Клиенты HTTP/1.1:
Кэш HTTP/1.1 при получении запроса должен использовать наиболее регламентирующий валидатор, когда проверяется, соответствуют ли друг другу запись в буфере клиента и собственная запись в кэше. Это единственный выход, когда запрос содержит как метку объекта, так и валидатор last-modified-date (If-Modified-Since или If-Unmodified-Since). Базовым принципом всех этих правил является то, что HTTP/1.1 серверы и клиенты должны пересылать как можно больше надежной информации в своих запросах и откликах. HTTP/1.1 системы, принимая эту информацию, используют наиболее консервативное предположение относительно валидаторов, которые они получают. Клиенты HTTP/1.0 и кэши будут игнорировать метки объектов. Вообще, значения времени последней модификации, полученные или используемые этими системами, будут поддерживать прозрачное и эффективное кэширование и, по этой причине, исходные серверы HTTP/1.1 должны присылать значения параметров Last-Modified. В тех редких случаях, когда в качестве валидатора системой HTTP/1.0 используется значение Last-Modified, могут возникнуть серьезные проблемы, и тогда исходные серверы HTTP/1.1 присылать их не должны. Принцип использования меток объектов базируется на том, что только автор услуг знает семантику ресурсов достаточно хорошо, чтобы выбрать подходящий механизм контроля кэширования. Спецификация любой функции сравнения валидаторов более сложна, чем сравнение байтов. Таким образом, для целей проверки пригодности записи в кэше никогда не используется сравнение любых других заголовков кроме Last-Modified, для совместимости с HTTP/1.0. Если только нет специального ограничения директивой Cache-Control (раздел 13.9), система кэширования может всегда запоминать отклик (см. раздел 12.8) в качестве записи в кэш, может прислать его без проверки пригодности, если он является свежим, и может послать его после успешной проверки пригодности. Если нет ни валидатора кэша ни времени пригодности, ассоциированного с этим откликом, мы не ожидаем, что такой отклик будет кэширован, но некоторые кэши могут нарушить это правило (например, когда имеется плохая коннективность или она вообще отсутствует). Клиент обычно может детектировать, что такой отклик был взят из кэша после сравнения заголовка Date с текущим временем. Заметьте, что некоторые кэши HTTP/1.0 нарушают эти правила, даже не присылая предупреждения. Однако, в некоторых случаях может быть неприемлемо для кэша сохранять объект или присылать его в ответ на последующие запросы. Это может быть потому, что автор сервиса полагает необходимой абсолютную семантическую прозрачность по соображениям безопасности или конфиденциальности. Определенные директивы Cache-Control предназначены для того, чтобы сервер мог указать, что некоторые объекты ресурсов или их части не могут кэшироваться ни при каких обстоятельствах. Заметьте, что раздел 13.8 в норме препятствует кэшу запоминать и отсылать отклик на предыдущий запрос, если этот запрос включает в себя заголовок авторизации. Отклик, полученный со статусным кодом 200, 203, 206, 300, 301 или 410, может быть запомнен кэшем и использован в ответе на последующие запросы, если директива не препятствует кэшированию. Однако, кэш, который не поддерживает заголовки Range и Content-Range не должен кэшировать отклики 206 (Partial Content). Отклик, полученный с любым другим статусным кодом, не должен отсылаться в ответ на последующие запросы, если только нет директив Cache-Control или других заголовков, которые напрямую разрешают это. К таким, например, относятся: заголовок Expires (раздел 13.21); "max-age", "must-revalidate", "proxy-revalidate", "public" или "private" директива Cache-Control (раздел 13.9). 12.10 Формирование откликов кэшей Целью кэша HTTP является запоминание информации, полученной в откликах на запросы, для использования в ответ на будущие запросы. Во многих случаях, кэш просто отсылает соответствующие части отклика отправителю запроса. Однако, если кэш содержит объект, базирующийся на предшествующем отклике, он может быть вынужден комбинировать части нового отклика с тем, что хранится в объекте кэша. 12.10.1 Заголовки End-to-end (точка-точка) и Hop-by-hop (шаг-за-шагом) Для целей определения поведения кэшей и некэшурующих прокси-серверов заголовки HTTP делятся на две категории:
Следующие заголовки HTTP/1.1 относятся к категории hop-by-hop:
Все другие заголовки, определенные HTTP/1.1 относятся к категории end-to-end. Заголовки Hop-by-hop, вводимые в будущих версиях HTTP, должны быть перечислены в заголовке Connection, как это описано в разделе 13.10. 12.10.2 Немодифицируемые заголовки Некоторые черты протокола HTTP/1.1, такие как Digest Authentication, зависят от значения определенных заголовков end-to-end. Кэш или некэширующий прокси не должны модифицировать заголовок end-to-end, если только определение этого заголовка не требует или не разрешает этого. Кэш или некэширующий прокси не должны модифицировать любое из следующих полей запроса или отклика или добавлять какие-либо поля, если они еще не существуют:
Кэш или некэширующий прокси не должны модифицировать или добавлять следующие поля в любых запросах и в откликах, которые содержат директиву no-transform Cache-Control:
Кэш или некэширующий прокси могут модифицировать или добавлять эти поля в отклик, который не включает директиву no-transform. Если же он содержит эту директиву, следует добавить предупреждение 14 (Transformation applied), если оно еще не занесено в отклик. Предупреждение. Ненужная модификация заголовков end-to-end может вызвать отказы в авторизации, если в поздних версиях HTTP использован более строгий механизм. Такие механизмы авторизации могут использовать значения полей заголовков не перечисленных здесь. 12.10.3 Комбинирование заголовков Когда кэш делает запрос серверу о пригодности ресурса и сервер выдает отклик 304 (Not Modified), кэш должен подготовить и отправить отклик, чтобы послать клиенту. Кэш использует тело объекта из записи в кэше при формировании отклика. Заголовки end-to-end записанные в кэше, используются для конструирования отклика. Исключение составляют любые end-to-end заголовки, поступившие в рамках отклика 304, они должны заместить соответствующие заголовки из записи в кэше. Если только кэш не решил удалить запись, он должен также заменить end-to-end заголовки своей записи соответствующими заголовками из полученного отклика. Другими словами, набор end-to-end заголовков, полученный вместе откликом переписывает все соответствующие end-to-end заголовки, из записи в кэше. Кэш может добавить к этому набору заголовки предупреждений (см. раздел 13.45). Если имя поля заголовка приходящего отклика соответствует более чем одной записи в кэше, все старые заголовки заменяются. Замечание. Это правило позволяет исходному серверу использовать отклик 304 (Not Modified) для актуализации любого заголовка, связанного с предыдущим откликом для того же объекта, хотя это может не всегда иметь смысл. Это правило не позволяет исходному серверу использовать отклик 304 (not Modified) для того, чтобы полностью стереть заголовок, который был прислан предыдущим откликом. 12.10.4 Комбинирование байтовых фрагментов Отклик может передать только субдиапазон байтов тела объекта, либо потому, что запрос включает в себя один или более спецификаций Range, либо из-за преждевременного обрыва соединения. После нескольких таких передач кэш может получить несколько фрагментов тела объекта. Если кэш запомнил не пустой набор субфрагментов объекта, а входящий отклик передает еще один фрагмент, кэш может комбинировать новый субфрагмент с уже имеющимся набором, если для обоих выполняются следующие условия:
Если любое из условий не выполнено, кэш должен использовать только наиболее поздний частичный отклик и отбросить другую частичную информацию. 12.11. Кэширование согласованных откликов Использование согласования содержимого под управлением сервера (раздел 11), что индицируется присутствием поля заголовка Vary в отклике, изменяет условия и процедуру, при которой кэш может использовать отклик для последующих запросов. Сервер должен использовать поле заголовка Vary (раздел 13.43), чтобы информировать кэш о том, какие пределы для поля заголовка используются при выборе представления кэшируемого отклика. Кэш может использовать выбранное представление для ответов на последующие запросы, только когда они имеют те же или эквивалентные величины полей заголовка, специфицированных в заголовке отклика Vary. Запросы с различными значениями одного или нескольких полей заголовка следует переадресовывать исходному серверу. Если представлению присвоена метка объекта, переадресуемый запрос должен быть условным и содержать метки в поле заголовка If-None-Match всех его кэшированных записей для Request-URI. Это сообщает серверу набор объектов, которые в настоящее время хранятся в кэше, так что, если любая из этих записей соответствует запрашиваемому объекту, сервер может использовать заголовок ETag в своем отклике 304 (Not Modified), чтобы сообщить кэшу, какой объект подходит. Если метка объекта нового отклика соответствует существующей записи, новый отклик должен быть использован для актуализации полей заголовка существующей записи, а результат должен быть прислан клиенту. Поле заголовка Vary может также информировать кэш, что представление было выбрано с использованием критериев помимо взятых из заголовков запросов. В этом случае, кэш не должен использовать отклик в ответ на последующий запрос, если только кэш не передает исходному серверу условный запрос. Сервер при этом возвращает отклик 304 (Not Modified), включая метку объекта или поле Content-Location, которые указывают, какой объект должен быть использован. Если какая-то запись кэша содержит только часть информации для соответствующего объекта, его метка не должна содержаться в заголовке If-None-Match, если только запрос не лежит в диапазоне, который полностью покрывается этим объектом. Если кэш получает позитивный отклик с полем Content-Location, соответствующим записи в кэше для того же Request-URI, с меткой объекта, отличающейся от метки существующего объекта, и датой современнее даты существующего объекта, данная запись не должна использоваться в качестве отклика для будущих запросов и должна быть удалена из кэша. 12.12. Кэши коллективного и индивидуального использования По причинам безопасности и конфиденциальности необходимо делать различие между кэшами совместного и индивидуального использования. Индивидуальные кэши доступны только для одного пользователя. Доступность в этом случае должна определяться соответствующим механизмом, обеспечивающим безопасность. Все другие кэши рассматриваются как коллективные. Другие разделы этой спецификации накладывают определенные ограничения на работу совместно используемых кэшей, для того, чтобы предотвратить потерю конфиденциальности или управления доступом. 12.13. Ошибки и поведение кэша при неполном отклике Кэш, который получает неполный отклик (например, с меньшим числом байтов, чем специфицировано в заголовке Content-Length) может его запомнить. Однако, кэш должен воспринимать эти данные как частичный отклик. Частичные отклики могут компоноваться, как это описано в разделе 12.5.4. Результатом может быть полный или частичный отклик. Кэш не должен возвращать частичный отклик клиенту без явного указания на то, что он частичный, используя статусный код 206 (Partial Content). Кэш не должен возвращать частичный отклик, используя статусный код 200 (OK). Если кэш получает отклик 5xx при попытке перепроверить запись, он может переадресовать этот отклик запрашивающему клиенту или действовать так, как если бы сервер не смог ответить на запрос. В последнем случае он может вернуть отклик, полученный ранее, если только запись в кэше не содержит директиву Cache-Control "must-revalidate" (см. раздел 13.9). 12.14. Побочные эффекты методов GET и HEAD Если исходный сервер напрямую не запрещает кэширование своих откликов, методы приложения GET и HEAD не должны давать каких-либо побочных эффектов, которые вызывали бы некорректное поведение, если эти отклики берутся из кэша. Они все же могут давать побочные эффекты, но кэш не обязан рассматривать такие побочные эффекты, принимая решение о кэшировании. Кэши контролируют лишь прямые указания исходного сервера о запрете кэширования. Обратим внимание только на одно исключение из этого правила: некоторые приложения имеют традиционно используемые GET и HEAD с запросами URL (содержащими "?" в части rel_path) для выполнения операций с ощутимыми побочными эффектами. Кэши не должны обрабатывать отклики от таких URL, как свежие, если только сервер не присылает непосредственно значение времени жизни. Это в частности означает, что отклики от серверов HTTP/1.0 для этих URI не следует брать из кэша. Дополнительную информацию по смежным темам можно найти в разделе 8.1.1. 12.15 Несоответствие после актуализации или стирания Воздействие определенных методов на исходный сервер может вызвать то, что одна или более записей, имеющихся в кэше, становятся неявно непригодными. То есть, хотя они могут оставаться "свежими", они не вполне точно отражают то, что исходный сервер пришлет в ответ на новый запрос. В протоколе HTTP не существует способа гарантировать, что все такие записи в кэше будут помечены как непригодные. Например, запрос, который вызывает изменение в исходном сервере не обязательно проходит через прокси, где в кэше хранится такая запись. Однако несколько правил помогает уменьшить вероятность некорректного поведения системы. В этом разделе, выражение "пометить объект как непригодный" означает, что кэш должен либо удалить все записи, относящиеся к этому объекту из памяти или должен пометить их, как непригодные ("invalid"), что будет вызывать обязательную перепроверку пригодности перед отправкой в виде отклика на последующий запрос. Некоторые методы HTTP могут сделать объект непригодным. Это либо объекты, на которые осуществляется ссылка через Request-URI, или через заголовки отклика Location или Content-Location (если они имеются). Это методы:
12.16. Обязательная пропись (Write-Through Mandatory) Все методы, которые предположительно могут вызвать модификацию ресурсов исходного сервера должны быть прописаны в исходный сервер. В настоящее время сюда входят все методы кроме GET и HEAD. Кэш не должен отвечать на такой запрос от клиента, прежде чем передаст запрос встроенному (inbound) серверу, и получит соответствующего отклик от него. Это не препятствует кэшу послать отклик 100 (Continue), прежде чем встроенный сервер ответит. Альтернатива, известная как "write-back" или "copy-back" кэширование, в HTTP/1.1 не допускается, из-за трудности обеспечения согласованных актуализаций и проблем, связанных с отказами сервера, кэша или сети до осуществления обратной записи (write-back). Если от ресурса получен новый кэшируемый отклик (см. разделы 13.9.2, 12.5, 12.6 и 12.8), в то время как какой-либо отклик для того же ресурса уже записан в кэш, кэшу следует использовать новый отклик для ответа на текущий запрос. Он может ввести его в память кэша и может, если он отвечает всем требованиям, использовать в качестве отклика для будущих запросов. Если он вводит новый отклик в память кэша, он должен следовать правилам из раздела 12.5.3. Замечание. Новый отклик, который имеет значение заголовка Date старше, чем кэшированные уже отклики, не должен заноситься в кэш. Агенты пользователя часто имеют механизмы "исторического" управления, такие как кнопки "Back" и списки предыстории, которые могут использоваться для повторного отображения объекта, извлеченного ранее в процессе сессии. Механизмы предыстории и кэширования различны. В частности механизмы предыстории не должны пытаться показать семантически прозрачный вид текущего состояния ресурса. Скорее, механизм предыстории предназначен для того, чтобы в точности показать, что видел пользователь, когда ресурс был извлечен. По умолчанию время годности не приложимо к механизмам предыстории. Если объект все еще в памяти, механизм предыстории должен его отобразить, даже если время жизни объекта истекло и он объявлен непригодным, если только пользователь не сконфигурировал агента так, чтобы обновлять объекты, срок годности которых истек. Это не запрещает механизму предыстории сообщать пользователю, что рассматриваемый им объект устарел. Замечание. Если механизмы предыстории излишне мешают пользователю просматривать устаревшие ресурсы, то это заставит разработчиков избегать пользоваться контролем времени жизни объектов. Разработчикам следует считать важным, чтобы пользователи не получали сообщений об ошибке или предупреждения, когда они пользуются навигационным управлением (например, таким как клавиша BACK). 4.5.6.1.13. Определения полей заголовка Этот раздел определяет синтаксис и семантику всех стандартных полей заголовков HTTP/1.1. Для полей заголовков объекта, как отправитель, так и получатель могут рассматриваться клиентом или сервером в зависимости от того, кто получает объект. Поле заголовка запроса Accept может использоваться для спецификации определенных типов среды, которые приемлемы для данного ресурса. Заголовки Accept могут использоваться для индикации того, что запрос ограничен в рамках определенного набора типов, как в случае запросов отображения в текущей строке.
accept-extension = ";" token [ "=" ( token | quoted-string ) ] Символ звездочка "*" используется для того, чтобы группировать типы среды в группы с "*/*", указывающим на все типы, и "type/*", указывающим на все субтипы данного типа. Группа сред может включать в себя параметры типа среды, которые применимы. За каждой группой сред может следовать один или более параметров приема (accept-params), начинающихся с "q" параметра для указания фактора относительного качества. Первый "q" параметр (если таковой имеется) отделяет параметры группы сред от параметров приема. Факторы качества позволяют пользователю или агенту пользователя указать относительную степень предпочтения для данной группы сред, используя шкалу значений q от 0 до 1 (раздел 2.9). Значение по умолчанию соответствует q=1. Замечание. Использование имени параметра "q" для разделения параметров типа среды от параметров расширения Accept связано с исторической практикой. Это мешает присвоения параметру типа среды имени "q". Пример Accept: audio/*; q=0.2, audio/basic. Должно интерпретироваться, как "Я предпочитаю audio/basic, но шлите мне любые типы аудио, если это лучшее, что имеется после 80% понижения качества". Если поле заголовка Accept отсутствует, тогда предполагается, что клиент воспринимает все типы среды. Если поле заголовка Accept присутствует и, если сервер не может послать отклик, который является приемлемым, согласно комбинированному значению поля Accept, тогда сервер должен послать отклик 406 (not acceptable). Более сложный пример. Accept: text/plain; q=0.5, text/html, Это будет интерпретироваться следующим образом: "text/html и text/x-c являются предпочтительными типами сред, но, если их нет, тогда следует слать объект text/x-dvi, если он отсутствует, следует присылать объект типа text/plain". Группы сред могут быть заменены другими группами или некоторыми специальными типами среды. Если используется более одного типа среды для данного типа, предпочтение отдается наиболее специфичному типу. Например, Accept: text/*, text/html, text/html;level=1, */* Фактор качества типа среды, ассоциированный с данным типом определен путем нахождения группы сред с наивысшим предпочтением, который подходит для данного типа. Например, Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, в результате будут установлены следующие величины:
Замечание. Агент пользователя может быть создан с набором значений качества по умолчанию для определенных групп среды. Однако, если только агент пользователя не является закрытой системой, которая не может взаимодействовать с другими агентами, этот набор по умолчанию должен быть конфигурируем пользователем. Поле заголовка запроса Accept-Charset может быть использовано для указания того, какой символьный набор приемлем для отклика. Это поле позволяет клиентам, способным распознавать более обширные или специальные наборы символов, сигнализировать об этой возможности серверу, который способен представлять документы в рамках этих символьных наборов. Набор символов ISO-8859-1 может считаться приемлемым для всех агентов пользователя. Accept-Charset = "Accept-Charset" ":" Значения символьных наборов описаны в разделе 2.4. Каждому символьному набору может быть поставлено в соответствие значение качества, которое характеризует степень предпочтения пользователя для данного набора. Значение по умолчанию q=1. Например Accept-Charset: ISO-8859-5, unicode-1-1;q=0.8. Если заголовок Accept-Charset отсутствует, по умолчанию это означает, что приемлем любой символьный набор. Если заголовок Accept-Charset присутствует, и, если сервер не может послать отклик, который приемлем с точки зрения заголовка Accept-Charset, тогда он должен послать сообщение об ошибке со статусным кодом 406 (not acceptable), хотя допускается посылка и отклика "unacceptable". Поле заголовка запроса Accept-Encoding сходно с полем Accept, но регламентирует кодировку содержимого (раздел 13.12), которая приемлема в отклике. Accept-Encoding = "Accept-Encoding" ":" Ниже приведен пример его использования Accept-Encoding: compress, gzip Если заголовок Accept-Encoding в запросе отсутствует, сервер может предполагать, что клиент воспримет любую кодировку информации. Если заголовок Accept-Encoding присутствует и, если сервер не может послать отклик, приемлемый согласно этому заголовку, тогда серверу следует послать сообщение об ошибке со статусным кодом 406 (Not Acceptable). Пустое поле Accept-Encoding указывает на то, что не приемлемо никакое кодирование. Поле заголовка запроса Accept-Language сходно с полем Accept, но регламентирует набор естественных языков, которые предпочтительны в отклике на запрос.
Каждому набору языков может быть поставлено в соответствие значение качества, которое представляет собой оценку предпочтений пользователя для языков, специфицированных в диапазоне. По умолчанию значение качества "q=1". Например, Accept-Language: da, en-gb;q=0.8, en;q=0.7 будет означать: "Я предпочитаю датский, но восприму британский английский и другие типы английского". Список языков согласуется с языковой меткой, если он в точности равен метке или, если он в точности равен префиксу метки, такому как первый символ метки, за которым следует символ "-". Специальный список "*", если он присутствует в поле Accept-Language, согласуется с любой меткой. Замечание. Это использование префикса не предполагает, что языковые метки присвоены языкам таким образом, что, если пользователь понимает язык с определенной меткой, то он поймет все языки, имеющие метки с одним и тем же префиксом. Правило префикса просто позволяет использовать префиксные метки для случаев, когда это справедливо. Фактор качества, присваиваемый языковой метке с помощью поля Accept-Language, равен значению качества самого длинного списка языков в поле. Если в поле отсутствует список языков, фактору качества присваивается значение нуль. Если в запросе отсутствует заголовок Accept-Language, серверу следует предполагать, что все языки приемлемы в равной мере. Если заголовок Accept-Language имеется, тогда все языки, которым присвоен фактор качества больше нуля, приемлемы. Посылка заголовка Accept-Language с полным списком языковых предпочтений пользователя в каждом запросе может восприниматься как нарушение принципов конфиденциальности. Обсуждение этой проблемы смотри в разделе 14.7. Замечание. Так как степень интеллигентности в высшей степени индивидуальна, рекомендуется, чтобы приложения клиента делали выбор языковых предпочтений доступным для пользователя. Если выбор не сделан доступным, тогда поле заголовка Accept-Language не должно присутствовать в запросе. Поле заголовка отклика Accept-Ranges позволяет серверу указать доступность широкодиапазонных запросов к ресурсу: Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges Исходные серверы, которые воспринимают байт-диапазонные запросы, могут послать Accept-Ranges: bytes но делать это необязательно. Клиенты могут выдавать байт-диапазонные запросы, не получив этот заголовок отклика для запрашиваемого ресурса. Серверы, которые не могут работать с какими-либо диапазонными запросами, могут послать Accept-Ranges: none, чтобы посоветовать клиенту, не пытаться посылать такие запросы. Поле заголовка отклика Age передает оценку отправителем времени с момента формирования отклика исходным сервером (или перепроверки его пригодности). Кэшированный отклик является свежим, если его возраст не превышает его времени жизни. Значения Age вычисляются согласно рекомендациям представленным разделе 12.2.3.
Значения Age являются неотрицательным десятичным целым числом, характеризующим возраст записи в секундах. Если кэш получает величину больше, чем наибольшее положительное число, которое он может себе представить или, если вычисление возраста вызвало переполнение, он должен передать заголовок Age со значением 2147483648 (231). Кэши HTTP/1.1 должны посылать заголовки Age в каждом отклике. Кэшам следует использовать арифметический тип чисел не менее 31 бита. Поле заголовка объекта Allow перечисляет набор методов, поддерживаемых ресурсом, идентифицированным Request-URI. Целью этого поля является точное информирование получателя о рабочих методах данного ресурса. Поле заголовка Allow должно быть представлено в отклике 405 (Method Not Allowed). Allow = "Allow" ":" 1#method Пример использования: Allow: GET, HEAD, PUT Это поле не препятствует клиенту испытать другие методы. Однако указания, данные в значение поля заголовка Allow, следует выполнять. Действительный набор методов определяется исходным сервером во время каждого запроса. Поле заголовка Allow может быть прислано запросом PUT, чтобы рекомендовать методы, которые будут поддерживаться новым или модифицированным ресурсом. Серверу не обязательно поддерживает эти методы, но ему следует включить заголовок Allow в отклик, чтобы сообщить действительно поддерживаемые методы. Прокси не должен модифицировать поле заголовка Allow, даже если он не понимает все специфицированные методы, так как агент пользователя может иметь другие средства связи с исходным сервером. Поле заголовка Allow не указывают на то, что методы реализованы на уровне сервера. Серверы могут использовать поле заголовка отклика Public (раздел 13.35), чтобы описать, какие методы реализованы на сервере. Агент пользователя, который хочет авторизовать себя на сервере может сделать это после получения отклика 401, включив в запрос поле заголовка Authorization. Значение поля Authorization состоит из идентификационной информации агента пользователя для области (realm) запрошенных ресурсов. Authorization = "Authorization" ":" credentials Авторизация доступа HTTP описана в разделе 10. Если запрос идентифицирован и область специфицирована, та же самая идентификационная информация может быть использована для других запросов в пределах данной области. Когда кэш коллективного пользования (см. раздел 12.7) получает запрос, содержащий поле Authorization, он не должен присылать соответствующий отклик в качестве ответа на какой-либо другой запрос, если только не выполняется одно из следующих условий:
Поле общего заголовка Cache-Control используется для спецификации директив, которые должны исполняться всеми механизмами кэширования вдоль цепочки запрос/отклик. Директивы определяют поведение, которое, как предполагается, должно предотвратить нежелательную интерференцию откликов или запросов в кэше. Эти директивы обычно переписывают алгоритм кэширования, используемый по умолчанию. Директивы кэша являются однонаправленными, присутствие директивы в запросе не предполагает, что та же директива будет присутствовать и в отклике. Заметьте, что кэши HTTP/1.0 могут не реализовывать управление (Cache-Control), а могут использовать только директиву Pragma: no-cache (см. раздел 13.32). Директивы кэша должны пропускаться через приложения прокси или внешнего шлюза (gateway), вне зависимости от их значения для этого приложения, так как директивы могут быть применимы для всех получателей в цепочке запрос/отклик. Невозможно специфицировать директивы для отдельных кэшей.
Если директива появляется без какого-либо параметра 1#field-name, она воздействует на весь запрос или отклик. Когда такая директива приходит с параметром 1#field-name, она воздействует только на именованное поле или поля и не имеет никакого действия на остальную часть запроса или отклика. Этот механизм поддерживает расширяемость. Реализации будущих версий протокола HTTP могут использовать эти директивы для полей заголовка, неопределенных в HTTP/1.1. Директивы управления кэшем могут быть разделены на следующие категории:
13.9.1. Что допускает кэширование? По умолчанию отклик допускает кэширование, если требования метода запроса, поля заголовка запроса и код статуса отклика указывают на то, что кэширование не запрещено. Раздел 12.4 обобщает эти рекомендации для кэширования. Следующие Cache-Control директивы отклика позволяют исходному серверу переписать стандартные требования по кэшируемости: public Указывает, что отклик может кэшироваться любым кэшем, даже если он в норме не кэшируем или кэшируем только в кэшах индивидуального пользования. (См. также об авторизации в разделе 13.8.) private Указывает, что весь или часть сообщения отклика предназначена для одного пользователя и не должна быть записана кэшем коллективного пользования. Это позволяет исходному серверу заявить о том, что специфицированные части отклика предназначены только для одного пользователя, и он не может отсылаться в ответ на запросы других пользователей. Частный кэш может кэшировать такие отклики. Замечание. Это использование слова частный (private) определяет только возможность кэширования и не гарантирует конфиденциальности для содержимого сообщения. no-cache Указывает, весь или фрагмент сообщения-отклика не должны кэшироваться, где бы то ни было. Это позволяет исходному серверу предотвратить кэширование даже для кэшей, сконфигурированных для рассылки устаревших откликов. Замечание. Большинство кэшей HTTP/1.0 не распознают и не исполняют эту директиву. 13.9.2. Что может быть записано в память кэша? Целью директивы no-store (не запоминать) является предотвращение ненамеренного распространения или записи конфиденциальной информации (например, на backup ленты). Директива no-store применяется для всего сообщения и может быть послана как в отклике, так и в запросе. При посылке в запросе кэш не должен запоминать какую-либо часть этого запроса или присланного в ответ отклика. При посылке в отклике, кэш не должен запоминать какую-либо часть отклика или запроса, его вызвавшего. Эта директива действует как для индивидуальных кэшей, так и кэшей коллективного пользования. "Не должно запоминаться" в данном контексте означает, что кэш не должен заносить отклик в долговременную память и должен сделать все от него зависящее для того, чтобы удалить эту информацию из временной памяти после переадресации этих данных. Даже когда эта директива ассоциирована с откликом, пользователи могут непосредственно запомнить такой отклик вне системы кэширования (например, с помощью диалога "Save As"). Буферы предыстории могут запоминать такие отклики как часть своей нормальной работы. Цель этой директивы обеспечение выполнения определенных требований пользователей и разработчиков, кто связан с проблемами случайного раскрытия информации за счет непредвиденного доступа к структуре данных кэша. При использовании этой директивы можно в некоторых случаях улучшить конфиденциальность, но следует учитывать, что не существует какого-либо надежного механизма для обеспечения конфиденциальности. В частности, некоторые кэши могут не распознавать или не выполнять эту директиву, а коммуникационные сети могут прослушиваться. 13.9.3. Модификации базового механизма контроля времени жизни Время пригодности объекта (entity expiration time) может быть специфицировано исходным сервером с помощью заголовка Expires (см. раздел 13.21). Другой возможностью является применение директивы max-age в отклике. Если отклик включает в себя как заголовок Expires, так и директиву max-age, более высокий приоритет имеет директива max-age, даже если заголовок Expires накладывает более жесткие ограничения. Это правило позволяет исходному серверу обеспечить для заданного отклика большее время жизни в случае объектов кэша HTTP/1.1 (или более поздней версии), чем в HTTP/1.0. Это может быть полезным, если кэш HTTP/1.0 некорректно вычисляет возраст объекта или его время пригодности, например, из-за не синхронности часов. Замечание. Большинство старых кэшей, несовместимых с данной спецификацией, не поддерживают применение директив управления кэшем. Исходный сервер, желающий применить директиву управления кэшем, которая ограничивает, но не запрещает кэширование в системах, следующих регламентациям HTTP/1.1, может использовать то, что директива max-age переписывает значение, определенное Expires. Другие директивы позволяют агенту пользователя модифицировать механизм контроля времени жизни объектов. Эти директивы могут быть специфицированы в запросе max-age. Этот запрос указывает, что клиент желает воспринять отклик, чей возраст не больше времени, заданного в секундах. Если только не включена также директива max-stale, клиент не воспримет устаревший отклик. Запрос min-fresh указывает, что клиент желает воспринять отклик, чье время жизни не меньше, чем его текущий возраст плюс заданное время в секундах. То есть, клиент хочет получит отклик, который будет еще свежим, по крайней мере, заданное число секунд. Запрос max-stale указывает, что клиент желает воспринять отклик, время жизни которого истекло. Если max-stale присвоено конкретное значение, тогда клиент хочет получить отклик, время жизни которого не ранее, чем заданное число секунд тому назад. Если значения max-stale в директиве не указано, тогда клиент готов воспринять отклики любого возраста. Если кэш присылает устаревший отклик, из-за наличия в запросе директивы max-stale, либо потому, что кэш сконфигурирован таким образом, что переписывает время жизни откликов, кэш должен присоединить заголовок предупреждения к отклику, используя Warning 10 (Response is stale - отклик устарел). 13.9.4. Управление перепроверкой пригодности и перезагрузкой Иногда агент пользователя может потребовать, чтобы кэш перепроверил пригодность своих записей с помощью исходного сервера (а не соседнего кэша по пути к исходному серверу), или перезагрузил свой кэш из исходного сервера. Может потребоваться перепроверка End-to-end, если и кэш и исходный сервер имеют завышенные оценки времени жизни кэшированных откликов. Перезагрузка End-to-end может потребоваться, если запись в кэше оказалась по какой-то причине поврежденной. Перепроверка типа End-to-end может быть запрошена в случае, когда клиент не имеет своей локальной копии, этот вариант мы называем "не специфицированная перепроверка end-to-end", или когда клиент имеет локальную копию, такой вариант называется "специфической перепроверкой end-to-end." Клиент может потребовать три вида действий, используя в запросе директивы управления кэшем: End-to-end reload Запрос включает в себя директиву управления кэшем "no-cache" или, для совместимости с клиентами HTTP/1.0, "Pragma: no-cache". В запросе с директивой no-cache может не быть никаких имен полей. Сервер не должен использовать кэшированную копию при ответе на этот запрос. Specific end-to-end revalidation Запрос включает в себя директиву управления кэшем "max-age=0", которая вынуждает каждый кэш вдоль пути к исходному серверу сверить свою собственную запись, если она имеются, с записью следующего кэша или сервера. Исходный запрос включает в себя требования перепроверки для текущего значениея валидатора клиента. Unspecified end-to-end revalidation Запрос включает в себя директиву управления кэшем "max-age=0", которая вынуждает каждый кэш вдоль пути к исходному серверу сверить свою собственную запись, с записью следующего кэша или сервера. Исходный запрос не включает в себя требований перепроверки. Первый кэш по пути (если таковой имеется), который содержит запись данного ресурса, подключает условия перепроверки со своим текущим валидатором. Когда промежуточный кэш вынуждается с помощью директивы max-age=0 перепроверить свои записи, присланный клиентом валидатор может отличаться от того, что записан в данный момент в кэше. В этом случае кэш может воспользоваться в своем запросе любой из валидаторов, не нарушая семантической прозрачности. Однако выбор валидатора может влиять на результат. Наилучшим подходом для промежуточного кэша является использование в запросе своего собственного валидатора. Если сервер присылает отклик 304 (Not Modified), тогда кэш должен отправить свою уже проверенную копию клиенту со статусным кодом 200 (OK). Если сервер присылает отклик с новым объектом и валидатором кэша, промежуточный кэш должен сверить, тем не менее, полученный валидатор с тем, что прислал клиент, используя функцию сильного сравнения. Если валидатор клиента равен присланному сервером, тогда промежуточный кэш просто возвращает код 304 (Not Modified). В противном случае он присылает новый объект со статусным кодом 200 (OK). Если запрос включает в себя директиву no-cache, в нем не должно быть min-fresh, max-stale или max-age. В некоторых случаях, таких как периоды исключительно плохой работы сети, клиент может захотеть возвращать только те отклики, которые в данный момент находятся в памяти, и не перезагружать или перепроверять записи из исходного сервера. Для того чтобы сделать это, клиент может включить в запрос директиву only-if-cached. При получении такой директивы кэшу следует либо реагировать, используя кэшированную запись, которая соответствует остальным требованиям запроса, либо откликаться статусным кодом 504 (Gateway Timeout). Однако если группа кэшей работает как унифицированная система с хорошей внутренней коннективностью, тогда такой запрос может быть переадресован в пределах группы кэшей Так как кэш может быть сконфигурирован так, чтобы игнорировать времена жизни, заданные сервером, а запрос клиента может содержать директиву max-stale, протокол включает в себя механизм, который позволяет серверу требовать перепроверки записей в кэше для любого последующего применения. Когда в отклике, полученном кэшем, содержится директива must-revalidate, этот кэш не должен использовать эту запись для откликов на последующие запросы без сверки ее на исходном сервере. Таким образом, кэш должен выполнить перепроверку end-to-end каждый раз, если согласно значениям Expires или max-age, кэшированный отклик является устаревшим. Директива must-revalidate необходима для поддержания надежной работы для определенных функций протокола. При любых обстоятельствах HTTP/1.1 кэш должен выполнять директиву must-revalidate. В частности, если кэш по какой-либо причине не имеет доступа к исходному серверу, он должен генерировать отклик 504 (Gateway Timeout). Серверы должны посылать директиву must-revalidate, тогда и только тогда, когда неудача запроса перепроверки объекта может вызвать нарушение работы системы, например, не выполнение финансовой операции без оповещения об этом. Получатели не должны осуществлять любые автоматические действия, которые нарушают эту директиву, и не должны посылать непригодную копию объекта, если перепроверка не удалась. Хотя это и не рекомендуется, агенты пользователя, работающие в условиях очень плохой коннективности, могут нарушать эту директиву, но, если это происходит, пользователь должен быть предупрежден в обязательном порядке, что присланный отклик возможно является устаревшим. Предупреждение должно посылаться в случае каждого непроверенного доступа, при этом следует требовать подтверждения от пользователя. Директива proxy-revalidate имеет то же значение, что и must-revalidate, за исключением того, что она не применима для индивидуальных кэшей агентов пользователя. Она может использоваться в отклике на подтвержденный запрос, чтобы разрешить кэшу пользователя запомнить и позднее прислать отклик без перепроверки (так как он был уже подтвержден однажды этим пользователем), в то же время прокси должен требовать перепроверки всякий раз при обслуживании разных пользователей (для того чтобы быть уверенным, что каждый пользователь был авторизован). Заметьте, что такие авторизованные отклики нуждаются также в директиве управления кэшем public для того, чтобы разрешить их кэширование. 13.9.5. Директива No-Transform Разработчики промежуточных кэшей (прокси) выяснили, что полезно преобразовать тип среды для тел определенных объектов. Прокси может, например, преобразовать форматы изображения для того, чтобы сэкономить место в памяти кэша или чтобы уменьшить информационный поток в тихоходном канале. HTTP должен датировать такие преобразования, выполняемые без оповещения. Серьезные операционные проблемы происходят, однако, когда такие преобразования производятся над телами объектов, предназначенных для определенного сорта приложений. Например, использующих медицинские изображения, предназначенные для анализа научных данных, а также тех, которые применяют авторизацию end-to-end, или требуют побитной совместимости с оригиналом. Следовательно, если отклик содержит директиву no-transform, промежуточный кэш или прокси не должны изменять те заголовки, которые перечислены в разделе 12.5.2, так как они могут содержать директиву no-transform. Это предполагает, что кэш или прокси не должны изменять любую часть тела объекта, который имеет такие заголовки. 13.9.6. Расширения управления кэшем Поле заголовка Cache-Control может быть расширено за счет использования одной или более лексем расширения, каждой из которых может быть присвоено определенное значение. Информационные расширения (те которые не требуют изменений в работе кэша) могут быть добавлены без изменения семантики других директив. Поведенческие расширения спроектированы для того, чтобы выполнять функции модификаторов существующих директив управления кэшем. Новые директивы и стандартные директивы устроены так, что приложения, которые не воспринимают новую директиву, по умолчанию исполнят стандартную процедуру. Те же приложения, которые распознают новую директиву, воспринимают ее как модификацию стандартной процедуры. Таким путем расширения директив управления кэшем могут быть сделаны без изменения базового протокола. Этот механизм расширений зависит от того, выполняет ли кэш все директивы управления, определенные для базовой версии HTTP. Предполагается, что кэш реализует определенные расширения и игнорирует все директивы, которые не может распознать. Например, рассмотрим гипотетическую, новую директиву, названную "community", которая действует как модификатор директивы "private". Мы определяем эту новую директиву так, что в дополнение к стандартным возможностям индивидуальных кэшей, кэши, которые обслуживают группу (community), могут кэшировать их отклики. Исходный сервер, желающий позволить группе "UCI" использовать частные отклики на их общем кэше, может решить эту проблему, включив директиву управления кэшем: private, community="UCI". Кэш, получив это поле заголовка, будет действовать корректно, если даже не понимает расширение "community", так как он видит и понимает директиву "private" и, таким образом, по умолчанию обеспечит безопасное функционирование. Не распознанная директива управления должна игнорироваться. Предполагается, что любая директива, в том числе и не узнанная кэшем HTTP/1.1, имеет по умолчанию стандартную директиву-подмену, которая обеспечивает определенный уровень функциональности, когда директива-расширение не распознается. Поле общего заголовка Connection позволяет отправителю специфицировать опции, которые желательны для конкретного соединения. Заголовок Connection имеет следующую грамматику: Connection-header = "Connection" ":"
1#(connection-token) Прокси-серверы HTTP/1.1 должны выполнить разбор поля заголовка Connection, прежде чем выполнить переадресацию, и для каждой лексемы соединения в этом поле убрать любые поля заголовка в сообщении с именами, совпадающими с этими лексемами. Опции Connection отмечаются присутствием лексем соединения в поле заголовка Connection, а не какими-либо дополнительными полями заголовка, так как дополнительное поле заголовка может быть не послано, если нет параметров, ассоциированных с данной опцией соединения. HTTP/1.1 определяет опцию "close" (закрыть) для отправителя, чтобы сигнализировать о том, что соединение будет закрыто после завершения передачи отклика. Например, наличие Connection: close как в полях запроса, так и в полях отклика указывает на то, что соединение не следует рассматривать как "постоянное" (раздел 7.1) после завершения передачи данного запроса/отклика. Приложения HTTP/1.1, которые не поддерживают постоянные соединения, должны содержать опцию соединения "close" в каждом сообщении. Поле заголовка объекта Content-Base может быть использовано для спецификации базового URI, которое позволяет работать с относительными URL в пределах объекта. Это поле заголовка описано как Base в документе RFC 1808, который, как ожидается, будет пересмотрен. Content-Base = "Content-Base" ":" absoluteURI Если поле Content-Base отсутствует, базовый URI объекта определяется его Content-Location (если это Content-Location URI является абсолютным) или URI используется для инициации запроса. Заметьте, однако, что базовый URI содержимого в пределах тела объекта может быть переопределен. 13.12. Кодирование содержимого Поле заголовка объекта Content-Encoding используется в качестве модификатора типа среды. Если это поле присутствует, его значение указывает, что тело объекта закодировано, и какой механизм декодирования следует применить, чтобы получить массив данных, ориентированный на тип среды, указанный в поле Content-Type. Поле Content-Encoding первоначально предназначалось для того чтобы архивировать документ без потери его идентичности с учетом типа среды, на которую он ориентирован. Content-Encoding = "Content-Encoding" ":" 1#content-coding Кодировки содержимого определены в разделе 2.5. Пример его использования приведен ниже Content-Encoding: gzip Content-Encoding (кодирование содержимого) является характеристикой объекта, задаваемой Request-URI. Обычно тело объекта заносится в память в закодированном виде и декодируется перед отображением или другим аналогичным использованием. Если было применено множественное кодирование объекта, кодирование содержимого должно быть перечислено в том порядке, в котором оно было выполнено. Поле заголовка объекта Content-Language описывает естественный язык(и) потенциальных читателей вложенного объекта. Заметьте, что это может быть совсем не эквивалентно всем языкам, использованным в теле объекта. Content-Language = "Content-Language" ":" 1#language-tag Языковые метки определены в разделе 2.10. Первоначальной целью поля Content-Language является предоставление пользователю возможности дифференцировать объекты согласно языковым предпочтениям. Таким образом, если содержимое тела предназначено только для аудитории, говорящей на датском языке, подходящим содержимым поля Content-Language может быть Content-Language: da Если поле Content-Language не задано, по умолчанию считается, что содержимое ориентировано на любую аудиторию. Это может значить, что отправитель не выделяет какой-либо естественный язык конкретно, или что отправитель не знает, какой язык предпочесть. Список языков может быть предложен для текста, который предназначен для многоязыковой аудитории. Например, перевод "Treaty of Waitangi," представленный одновременно в оригинальной версии на маори и на английском, может быть вызван с помощью Content-Language: mi, en Однако только то, что в поле объекта перечислено несколько языков не означает, что объект предназначен для многоязыковой аудитории. Примером может быть языковый курс для начинающих, такой как "A First Lesson in Latin," который предназначен для англо-говорящей аудитории. В этом случае поле Content-Language должно включать только "en". Поле Content-Language может быть применено к любому типу среды - оно не ограничено только текстовыми документами. Содержимое поля заголовка объекта Content-Length указывает длину тела сообщения в октетах (десятичное число), посылаемое получателю, или в случае метода HEAD, размер тела объекта, который мог бы быть послан при запросе GET. Content-Length = "Content-Length" ":" 1*DIGIT Например Content-Length: 3495 Приложениям следует использовать это поле для указания размера сообщения, которое должно быть послано вне зависимости от типа среды. Получатель должен иметь возможность надежно определить положение конца запроса HTTP/1.1, содержащего тело объекта, например, запрос использует Transfer-Encoding chunked или multipart body. Любое значение Content-Length больше или равное нулю допустимо. Раздел 3.4 описывает то, как определить длину тела сообщения, если параметр Content-Length не задан. Замечание. Значение этого поля заметно отличается от соответствующего определения в MIME, где оно является опционным, используемым в типе содержимого "message/external-body". В HTTP его следует посылать всякий раз, когда длина сообщения должна быть известна до начала пересылки. Поле заголовка объекта Content-Location может быть использовано для определения положения ресурса для объекта, вложенного в сообщение. В случае, когда ресурс содержит много объектов, и эти объекты в действительности имеют разные положения, по которым может быть осуществлен доступ, сервер должен предоставить поле Content-Location для конкретного варианта, который должен быть прислан. Кроме того сервер должен предоставить Content-Location для ресурса, соответствующего объекту отклика. Content-Location = "Content-Location" ":" Если поле заголовка Content-Base отсутствует, значение Content-Location определяет также базовый URL для объекта (см. раздел 13.11). Значение Content-Location не является заменой для исходного запрашиваемого URI, это лишь объявление положения ресурса, соответствующего данному конкретному объекту в момент запроса. Будущие запросы могут использовать Content-Location URI, если нужно идентифицировать источник конкретного объекта. Кэш не может предполагать, что объект с полем Content-Location, отличающимся от URI, который использовался для его получения, может использоваться для откликов на последующие запросы к этому Content-Location URI. Однако Content-Location может использоваться для того, чтобы отличить объекты, полученные из одного общего, как это описано в разделе 12.6. Если Content-Location является относительным URI, URI интерпретируется с учетом значения Content-Base URI, присланного в отклике. Если значения Content-Base не предоставлено, относительный URI интерпретируется по отношению к Request-URI. Поле заголовка объекта Content-MD5, как это определено в RFC 1864 [23], является MD5-дайджестом тела объекта для целей обеспечения проверки end-to-end целостности сообщения MIC (message integrity check). Замечание. MIC привлекательна для регистрации случайных модификаций тела объекта при транспортировке, но не является гарантией против преднамеренных действий.)
Поле заголовка Content-MD5 может генерироваться исходным сервером с целью проверки целостности тел объектов. Только исходные серверы могут генерировать поле заголовка Content-MD5. Прокси и внешние шлюзы его генерировать не должны, так как это сделает невозможными проверку целостности end-to-end. Любой получатель тела объекта, включая внешние шлюзы и прокси, могут проверять то, что значение дайджеста в этом поле заголовка согласуется с полученным телом объекта. Дайджест MD5 вычисляется на основе содержимого тела сообщения, с учетом любых кодировок содержимого, но исключая любые транспортные кодировки (Transfer-Encoding), которые могли быть использованы. Если сообщение получено в закодированном виде с использованием Transfer-Encoding, это кодирование должно быть удалено перед проверкой значения Content-MD5 для полученного объекта. Это означает, что дайджест вычисляется для октетов тела объекта в том порядке, в каком они будут пересланы, если не используется транспортное кодирование. HTTP расширяет RFC 1864 с тем, чтобы разрешить вычисление дайджеста для MIME-комбинации типов среды (например, multipart/* и message/rfc822), но это никак не влияет на способ вычисления дайджеста, описанного выше. Замечание. Существует несколько следствий этого. Тело объекта для комбинированных типов может содержать много составных частей, каждая со своими собственными MIME и HTTP заголовками (включая заголовки Content-MD5, Content-Transfer-Encoding и Content-Encoding). Если часть тела имеет заголовок Content-Transfer-Encoding или Content-Encoding, предполагается, что содержимое этой части закодировано и она включается в дайджест Content-MD5 как есть. Поле заголовка Transfer-Encoding не применимо для частей тела объекта. Замечание. Так как определение Content-MD5 является в точности тем же для HTTP и MIME (RFC 1864), существует несколько вариантов, в которых применение Content-MD5 к телам объектов HTTP отличается от случая MIME. Один вариант связан с тем, что HTTP, в отличие от MIME, не использует Content-Transfer-Encoding, а использует Transfer-Encoding и Content-Encoding. Другой - вызван тем, что HTTP чаще, чем MIME, использует двоичный тип содержимого. И, наконец, HTTP позволяет передачу текстовой информации с любым типом разрыва строк, а не только с каноническим CRLF. Преобразование всех разрывов строк к виду CRLF не должно делаться до вычисления или проверки дайджеста: тип оформления разрыва строк при расчете дайджеста должен быть сохранен. Заголовок объекта Content-Range посылается с частью тела объекта и служит для определения того, где в теле объекта должен размещаться данный фрагмент. Он также указывает полный размер тела объекта. Когда сервер присылает клиенту частичный отклик, он должен описать как длину фрагмента, так и полный размер тела объекта.
В отличие от значений спецификаторов байтовых диапазонов (byte-ranges-specifier), byte-content-range-spec может специфицировать только один интервал и должен содержать абсолютные положения, как первого, так и последнего байтов. Некорректной считается спецификация byte-content-range-spec, чье значение last-byte-pos меньше, чем его значение first-byte-pos, или значение длины объекта меньше или равно last-byte-pos. Получатель некорректной спецификации byte-content-range-spec должен игнорировать ее и любой текст, переданный вместе с ней. Примеры спецификации byte-content-range-spec, предполагающей, что объект содержит 1234 байт, приведены ниже:
Когда сообщение HTTP включает в себя содержимое одного фрагмента (например, отклик на запрос одного фрагмента, или на запрос набора фрагментов, которые перекрываются без зазоров), это содержимое передается с заголовком Content-Range, а заголовок Content-Length несет в себе число действительно переданных байт. Например, HTTP/1.1 206 Partial content Когда сообщение HTTP несет в себе содержимое нескольких фрагментов (например, отклик на запрос получения нескольких, не перекрывающихся фрагментов), они передаются как многофрагментное MIME-сообщение. Многофрагментный тип данных MIME используемый для этой цели, определен в этой спецификации как "multipart/byteranges". (Смотри приложение 16.2). Клиент, который не может декодировать сообщение MIME multipart/byteranges, не должен запрашивать несколько байт-фрагментов в одном запросе. Когда клиент запрашивает несколько фрагментов байт в одном запросе, серверу следует присылать их в порядке перечисления. Если сервер игнорирует спецификацию byte-range-spec, из-за того, что она некорректна, сервер должен воспринимать запрос так, как если бы некорректного заголовка Range не существовало вовсе. (В норме это означает посылку отклика с кодом 200, содержащего весь объект). Причиной этого является то, что клиент может прислать такой некорректный запрос, только когда объект меньше чем объект, полученный по предыдущему запросу. Поле заголовка объекта Content-Type указывает тип среды тела объекта, посланного получателю, или, в случае метода HEAD, тип среды, который был бы применен при методе GET. Content-Type = "Content-Type" ":" media-type Типы среды определены в разделе 2.7. Примером поля может служить Content-Type: text/html; charset=ISO-8859-4 Дальнейшее обсуждение методов идентификации типа среды объекта приведено в разделе 6.2.1. Поле общего заголовка Date представляет дату и время формирования сообщения, имеет ту же семантику, что и orig-date в RFC 822. Значение поля равно HTTP-date, как это описано в разделе 2.3.1. Date = "Date" ":" HTTP-date Пример Date: Tue, 15 Nov 1994 08:12:31 GMT Если сообщение получено через непосредственное соединение с агентом пользователя (в случае запросов) или исходным сервером (в случае откликов), дата может считаться текущей датой конца приема. Однако так как дата по определению является важной при оценке характеристик кэшированных откликов, исходный сервер должен включать поле заголовка Date в каждый отклик. Клиентам следует включать поле заголовка Date в сообщения, которые несут тело объекта запросов PUT и POST, но даже здесь это является опционным. Полученному сообщению, которое не имеет поля заголовка Date, следует присвоить дату. Это может сделать один из получателей, если сообщение будет кэшировано им, или внешним шлюзом. Теоретически дата должна представлять момент времени сразу после генерации объекта. На практике поле даты может быть сформировано в любое время в процессе генерации сообщения. Формат поля Date представляет собой абсолютную дату и время так, как это определено для даты HTTP в разделе 2.3. Оно должно быть послано в формате, описанном в документе RFC-1123 [8]. Поле заголовка объекта ETag определяет метку объекта. Заголовки с метками объектов описаны в разделах 13.20, 13.25, 13.26 и 13.43. Метка объекта может использоваться для сравнения с другими объектами того же самого ресурса (см. раздел 12.8.2). ETag = "ETag" ":" entity-tag Поле заголовка объекта Expires содержит дату/время с момента, когда отклик может считаться устаревшим. Устаревшая запись в кэше в норме не должна посылаться кэшем (а также прокси кэшем и кэшем агента пользователя), если только она не будет сначала перепроверена с помощью исходного сервера (или с помощью промежуточного кэша, который содержит свежую копию объекта). Дальнейшее обсуждение модели контроля пригодности записей содержится в разделе 12.2. Присутствие поля Expires не предполагает, что исходный ресурс изменит или удалит объект по истечении указанного времени. Формат абсолютной даты и времени описан в разделе 2.3. Он должен следовать рекомендациям документа RFC1123: Expires = "Expires" ":" HTTP-date Примером реализации формата даты может служить Expires: Thu, 01 Dec 1994 16:00:00 GMT Замечание. Если отклик содержит поле Cache-Control с директивой max-age, то эта директива переписывает значение поля Expires. Клиенты HTTP/1.1 и кэши должны рассматривать некорректные форматы даты, в особенности те, что содержат нули, как относящиеся к прошлому (то есть, как "уже истекшие"). Для того, чтобы пометить отклик, как "уже с истекшим сроком", исходный сервер должен использовать дату Expires, которая равна значению заголовка Date. (Правила вычисления времени истечения пригодности записи смотри в разделе 12.2.4.) Для того, чтобы пометить отклик как "всегда пригодный", исходный сервер должен использовать дату Expires приблизительно на один год позже момента посылки отклика. Серверы HTTP/1.1 не должны посылать отклики с датами в поле Expires, которые устанавливают время жизни более одного года. Присутствие поля заголовка Expires со значением даты, относящейся к будущему, означает, что они могут быть занесены в кэш, если только не указано обратного в поле заголовка Cache-Control (раздел 13.9). Поле заголовка запроса From (если присутствует) должно содержать интернетовский e-mail адрес пользователя. Адрес должен иметь формат, описанный в документе RFC-822 (и дополненный в RFC-1123): From = "From" ":" mailbox Пример: From: webmaster@w3.org Это поле заголовка может быть использовано для целей регистрации процедур и как средство идентификации источников некорректных и нежелательных запросов. Не следует использовать его как ненадежную систему защиты доступа. Это поле предоставляет информацию о том, кто является ответственным за метод, использованный в данном запросе. В частности, агенты-роботы должны содержать этот заголовок, так чтобы с лицом, ответственным за работу робота, можно было связаться, в случае возникновения проблем на принимающем конце. Интернетовский e-mail адрес в этом поле может не совпадать с Интернет-адресом ЭВМ, пославшей запрос. Например, когда запрос прошел через прокси, следует использовать адрес первичного отправителя. Замечание. Клиенту не следует посылать поле заголовка From без одобрения пользователя, так как это может вызвать конфликт с интересами конфиденциальности пользователя или нарушить политику безопасности сети отправителя. Настоятельно рекомендуется, чтобы пользователь мог дезактивировать, активировать и модифицировать значение этого поля в любое время до запроса. Поле заголовка запроса Host специфицирует ЭВМ в Интернет и номер порта запрашиваемого ресурса в виде, полученном из исходного URL, который выдал пользователь или который получен из указанного ресурса (в общем случае из HTTP URL, как это описано в разделе 2.2.2). Значение поля Host должно определять положение в сети исходного сервера или шлюза, заданное исходным URL. Это позволяет исходному серверу или шлюзу различать внутренние URL, такие как корневые "/" URL сервера для ЭВМ, которым поставлен в соответствие один IP адрес. Host = "Host" ":" host [ ":" port ] ; Раздел 2.2.2 Имя "ЭВМ" без последующего номера порта предполагает значение порта по умолчанию для заданного вида сервиса (напр., "80" для HTTP URL). Например, запрос исходного сервера GET /pub/WWW/ HTTP/1.1 Клиент должен включать поле заголовка Host во все сообщения-запросы HTTP/1.1 в Интернет (т.е., в любое сообщение, соответствующее запросу URL, который включает в себя Интернет-адрес ЭВМ, услуги которой запрашиваются). Если поле Host отсутствует, прокси HTTP/1.1 должен добавить его в сообщение-запрос до того, как переадресует запрос дальше в Интернет. Все серверы HTTP/1.1, которые базируются в Интернет, должны откликаться статусным кодом 400 на любое сообщение-запрос HTTP/1.1, в котором отсутствует поле Host. О других требованиях относительно поля Host смотри раздел 4.2 и 16.5.1. Поле заголовка запроса If-Modified-Since используется с методом GET, для того чтобы сделать его условным. Если запрошенный объект не был модифицирован со времени, указанного в этом поле, объект не будет прислан сервером, вместо этого будет послан отклик 304 (not modified) без какого-либо тела сообщения. If-Modified-Since = "If-Modified-Since" ":" HTTP-date Пример поля: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT Метод GET с заголовком If-Modified-Since и без заголовка Range требует, чтобы идентифицированный объект был передан, только в случае его модификации после даты, указанной в заголовке If-Modified-Since. Алгоритм определения этого включает в себя следующие шаги.
Целью этой функции является эффективная актуализация кэшированной информации с минимальными издержками. Заметьте, что поле заголовка запроса Range модифицирует значение If-Modified-Since. Более детально эта проблема рассмотрена в разделе 13.36. Заметьте, что время If-Modified-Since интерпретируются сервером, чьи часы могут быть не синхронизованы с часами клиента. Если клиент использует произвольную дату в заголовке If-Modified-Since вместо даты взятой из заголовка Last-Modified для текущего запроса, тогда клиенту следует остерегаться того, что эта дата интерпретируется согласно представлениям сервера о временной шкале. Клиенту следует учитывать не синхронность часов и проблемы округления, связанные с различным кодированием времени клиентом и сервером. Это предполагает возможность быстрого изменения условий, когда документ изменяется между моментом первого запроса и датой If-Modified-Since последующего запроса, а также возможность трудностей, связанных с относительным сбоем часов, если дата If-Modified-Since получена по часам клиента (без поправки на показания часов сервера). Поправки для различных временных базисов клиента и сервера желательно делать с учетом времени задержки в сети. Поле заголовка запроса If-Match используется с методом, для того чтобы сделать его условным. Клиент, который имеет один или более объектов, полученных ранее из ресурса, может проверить, является ли один из этих объектов текущим, включив список связанных с ним меток в поле заголовка If-Match. Целью этой функции является эффективная актуализация кэшированной информации с минимальными издержками. Она используется также в запросах актуализации с целью предотвращения непреднамеренной модификации не той версии ресурса что нужно. Значение "*" соответствует любому текущему объекту ресурса. If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) Если какая-то метка объекта совпадает с меткой объекта, который прислан в отклике на аналогичный запрос GET (без заголовка If-Match), или если задана "*" и какой-то текущий объект существует для данного ресурса, тогда сервер может реализовать запрошенный метод, как если бы поля заголовка If-Match не существовало. Сервер должен использовать функцию сильного сравнения (см. раздел 2.11) для сопоставления меток объекта в If-Match. Если ни одна из меток не подходит, или если задана "*" и не существует никакого текущего объекта, сервер не должен реализовывать запрошенный метод, а должен прислать отклик 412 (Precondition Failed). Это поведение наиболее полезно, когда клиент хочет помешать актуализующему методу, такому как PUT, модифицировать ресурс, который изменился после последнего доступа к нему клиента. Если запрос без поля заголовка If-Match выдает в результате нечто отличное от статуса 2xx, тогда заголовок If-Match должен игнорироваться. "If-Match: *" означает, что метод должен быть реализован, если представление, выбранное исходным сервером (или кэшем, возможно с привлечением механизма Vary, см. раздел 13.43), существует, и не должен быть реализован, если выбранного представления не существует. Запрос, предназначенный для актуализации ресурса (напр., PUT) может включать в себя поле заголовка If-Match, чтобы сигнализировать о том, что метод запроса не должен быть применен, если объект, соответствующий значению If-Match (одиночная метка объекта), не является более представлением этого ресурса. Это позволяет пользователям указывать, что они не хотят, чтобы запрос прошел успешно, если ресурс был изменен без их уведомления. Примеры: If-Match: "xyzzy" Поле заголовка запроса If-None-Match используется для формирования условных методов. Клиент, который имеет один или более объектов, полученных ранее из ресурса, может проверить, что ни один из этих объектов не является текущим, путем включения списка их ассоциированных меток в поле заголовка If-None-Match. Целью этой функции является эффективная актуализация кэшированной информации с минимальной избыточностью. Она также используется при актуализации запросов с тем, чтобы предотвратить непреднамеренную модификацию ресурса, о существовании которого не было известно. Значение "*" соответствует любому текущему объекту ресурса. If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) Если какая-либо метка объекта соответствует метке объекта, который был прислан в отклике на аналогичный запрос GET (без заголовка If-None-Match) или если задана "*" и существует какой-то текущий объект данного ресурса, тогда сервер не должен реализовывать запрошенный метод. Вместо этого, если методом запроса был GET или HEAD, серверу следует реагировать откликом 304 (Not Modified), включая поля заголовков объекта, ориентированные на кэш (в частности ETag). Для всех других методах запроса сервер должен откликаться статусным кодом 412 (Precondition Failed). По поводу правил того, как определять соответствие двух меток объектов смотри раздел 12.8.3. С запросами GET и HEAD должна использоваться только функция слабого сравнения. Если не подходит ни одна из меток объекта или если задана "*" и не существует ни одного текущего объекта, сервер может выполнить запрошенный метод так, как если бы поля заголовка If-None-Match не существовало. Если запрос без поля заголовка If-None-Match, даст результат отличный от статусного кода 2xx, тогда заголовок If-None-Match должен игнорироваться. "If-None-Match: *" означает, что метод не должен реализовываться, если представление, выбранное исходным сервером (или кэшем, возможно использующим механизм Vary, см. раздел 13.43), существует, и должен быть реализован, если представления не существует. Эта функция может быть полезной для предотвращения конкуренции между операциями PUT. Примеры: If-None-Match: "xyzzy" Если клиент имеет частичную копию объекта в своем кэше и хочет иметь полную свежую копию объекта, он может использовать заголовок запроса Range с условным GET (используя If-Unmodified-Since и/или If-Match.) Однако если условие не выполняется, из-за того, что объект был модифицирован, клиенту следует послать второй запрос, чтобы получить все текущее содержимое тела объекта. Заголовок If-Range позволяет клиенту заблокировать второй запрос. По существу это означает, что "если объект не изменился, следует посылать мне часть, которой у меня нет, в противном случае пришлите мене всю новую версию объекта". If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) Если клиент не имеет метки объекта, но имеет дату Last-Modified, он может использовать эту дату в заголовке If-Range. Сервер может отличить корректную дату HTTP от любой формы метки объекта, рассмотрев не более двух символов. Заголовок If-Range следует использовать только совместно с заголовком Range, и его следует игнорировать, если запрос не содержит в себе этот заголовок, или если сервер не поддерживает операции с фрагментами. Если метка объекта, представленная в заголовке If-Range, соответствует текущей метке, тогда сервер должен обеспечить специфицированный фрагмент объекта, используя отклик 206 (Partial content). Если метка объекта не подходит, сервер должен прислать полный объект со статусным кодом 200 (OK). 13.28. Поле If-Unmodified-Since Поле заголовка запроса If-Unmodified-Since используется для того, чтобы формировать условные методы. Если запрошенный ресурс не был модифицирован с момента, указанного в поле, сервер должен произвести запрошенную операцию, так как если бы заголовок If-Unmodified-Since отсутствовал. Если запрошенный объект был модифицирован после указанного времени, сервер не должен выполнять запрошенную операцию и должен прислать отклик 412 (Precondition Failed). If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date Примером поля может служить: If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT Если запрос завершается чем-то отличным от статусного кода 2xx (т.е., без заголовка If-Unmodified-Since), заголовок If-Unmodified-Since следует игнорировать. Если специфицированная дата некорректна, заголовок также игнорируется. Поле заголовка объекта Last-Modified указывает на дату и время, при которых, по мнению исходного сервера, данный объект был модифицирован. Last-Modified = "Last-Modified" ":" HTTP-date Пример его использования Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT Точное значение этого заголовка зависит от реализации исходного сервера и природы ресурса. Для файлов, это может быть дата последней модификации файловой системы. Для объектов с динамическими встроенными частями это может время последней модификации одной из встроенных компонент. Для шлюзов баз данных это может быть метка последней модификации рекорда. Для виртуальных объектов это может быть время последнего изменения внутреннего состояния. Исходный сервер не должен посылать дату Last-Modified, которая позже, чем время формирования сообщения сервера. В таких случаях, когда последняя модификация объекта указывает некоторое на время в будущем, сервер должен заменить дату на время формирования сообщения. Исходный сервер должен получить значение Last-Modified объекта как можно ближе по времени к моменту генерации значения Date отклика. Это позволяет получателю выполнить точную оценку времени модификации объекта, в особенности, если объект был изменен буквально накануне формирования отклика. Серверы HTTP/1.1 должны посылать поле Last-Modified всякий раз, когда это возможно. Поле заголовка отклика Location используется для переадресации запроса на сервер, отличный от указанного в Request-URI, или для идентификации нового ресурса. В случае отклика 201 (Created), поле Location указывает на новый ресурс, созданный в результате запроса. Для откликов 3xx поле Location должно указывать предпочтительные URL сервера для автоматической переадресации на ресурс. Значение поля включает одинарный абсолютный URL. Location = "Location" ":" absoluteURI Например Location: http://www.w3.org/pub/WWW/People.html Замечание. Поле заголовка Content-Location (раздел 13.15) отличается от поля Location в том, что Content-Location идентифицирует исходное положение объекта, заключенное в запросе. Следовательно, отклик может содержать поля заголовка как Location, так и Content-Location. Требования некоторых методов изложены также в разделе 12.10. Поле заголовка запроса Max-Forwards может использоваться с методом TRACE (раздел 13.31) ,чтобы ограничить число прокси или шлюзов, которые могут переадресовывать запрос. Это может быть полезным, когда клиент пытается отследить путь запроса в случае возникновения различных проблем. Max-Forwards = "Max-Forwards" ":" 1*DIGIT Значение Max-Forwards представляет собой целое десятичное число, которое указывает сколько еще раз запрос можно переадресовать. Каждый прокси или шлюз получатель запроса TRACE, содержащего поле заголовка Max-Forwards, должен проверить и актуализовать его величину прежде, чем переадресовывать запрос. Если полученная величина равна нулю, получателю не следует переадресовывать запрос. Вместо этого, ему следует откликнуться как конечному получателю статусным кодом 200 (OK), содержащим полученное сообщение-запрос в качестве тела отклика (как это описано в разделе 8.8). Если полученное значение больше нуля, тогда переадресованное сообщение должно содержать актуализованное значение поля Max-Forwards (уменьшенное на единицу). Поле заголовка Max-Forwards следует игнорировать для всех других методов определенных в данной спецификации и для всех расширений методов, для которых это не является частью определения метода. Поле общего заголовка Pragma используется для включения специальных директив (зависящих от конкретной реализации), которые могут быть применены ко всем получателям вдоль цепочки запрос/отклик. Все директивы pragma специфицируют с точки зрения протокола опционное поведение. Однако некоторые системы могут требовать, чтобы поведение соответствовало директивам:
Когда в запросе присутствует директива no-cashe, приложение должно переадресовать запрос исходному серверу, даже если имеется кэшированная копия того, что запрошено. Директива pragma имеет ту же семантику, что и директива кэша no-cache (см. раздел 13.9) и определена здесь для обратной совместимости с HTTP/1.0. Клиентам следует включать в запрос оба заголовка, когда посылается запрос no-cache серверу, о котором неизвестно, совместим ли он с HTTP/1.1. Нельзя специфицировать директиву pragma для какого-то отдельного получателя. Однако любая директива pragma неприемлемая для получателя должна им игнорироваться. Клиенты HTTP/1.1 не должны посылать заголовок запроса Pragma. Кэши HTTP/1.1 должны воспринимать "Pragma: no-cache", как если бы клиент послал "Cache-Control: no-cache". Никаких новых директив Pragma в HTTP определено не будет. 13.33. Поле Proxy-Authenticate Поле заголовка отклика Proxy-Authenticate должно быть включено в качестве части отклика 407 (Proxy Authentication Required). Значение поля состоит из вызова, который указывает схему идентификации, и параметров, применимых в прокси для данного Request-URI. Proxy-Authenticate = "Proxy-Authenticate" ":" challenge Процесс авторизованного доступа HTTP описан в разделе 10. В отличие от WWW-Authenticate, поле заголовка Proxy-Authenticate применимо только к текущему соединению и не может быть передано другим клиентам. Однако, промежуточному прокси может быть нужно получить свои собственные авторизационные параметры с помощью запроса у ниже расположенного клиента, который при определенных обстоятельствах может проявить себя как прокси, переадресующий поле заголовка Proxy-Authenticate. 13.34. Поле Proxy-Authorization Поле заголовка запроса Proxy-Authorization позволяет клиенту идентифицировать себя (или его пользователя) прокси, который требует авторизации. Значение поля Proxy-Authorization состоит из автризационных параметров, содержащих идентификационную информацию агента пользователя для прокси и/или области (realm) запрошенного ресурса. Proxy-Authorization = "Proxy-Authorization" ":" credentials Процесс авторизации доступа HTTP описан в разделе 10. В отличие от Authorization, поле заголовка Proxy-Authorization применимо только к следующему внешнему прокси, который требует авторизации с помощью поля Proxy-Authenticate. Когда работает несколько прокси, объединенных в цепочку, поле заголовка Proxy-Authorization используется первым внешним прокси, который предполагает получение авторизационных параметров. Прокси может передать эти параметры из запроса клиента следующему прокси, если существует механизм совместной авторизации при обслуживании данного запроса. Поле заголовка отклика Public содержит список методов, поддерживаемых сервером. Задачей этого поля является информирование получателя о возможностях сервера в отношении необычных методов. Перечисленные методы могут быть, а могут и не быть применимыми к Request-URI. Поле заголовка Allow (раздел 13.7) служит для указания методов, разрешенных для данного URI.
Пример использования: Public: OPTIONS, MGET, MHEAD, GET, HEAD Это поле заголовка применяется для серверов, непосредственно соединенных с клиентом, (т.е., ближайших соседей в цепи соединения). Если отклик проходит через прокси, последний должен либо удалить поле заголовка Public или заменить его полем, характеризующим его собственные возможности.
13.36. Фрагмент Так как все объекты HTTP в процессе передачи представляют собой последовательности байт, концепция фрагментов является существенной для любого объекта HTTP. Однако не все клиенты и серверы нуждаются в поддержке операций с фрагментами. Спецификации байтовых фрагментов в HTTP относятся к последовательностям байт в теле объекта не обязательно то же самое что и тело сообщения. Операция с байтовыми фрагментами может относиться к одному набору байт или к нескольким таким наборам в пределах одного объекта.
Значение first-byte-pos в спецификации byte-range-spec указывает на относительное положение первого байта фрагмента. Значение last-byte-pos определяет относительное положение последнего байта фрагмента. Относительное положение начального байта равно нулю. Если присутствует значение last-byte-pos, оно должно быть больше или равно значению first-byte-pos в спецификации byte-range-spec, в противном случае спецификация byte-range-spec не корректна. Получатель некорректной спецификации byte-range-spec должен ее игнорировать. Если значение last-byte-pos отсутствует, или если значение больше или равно текущей длине тела объекта, значение last-byte-pos берется на единицу меньше текущего значения длины тела объекта в байтах. При выборе last-byte-pos, клиент может ограничить число копируемых байт, если не известна длина объекта. suffix-byte-range-spec = "-" suffix-length Спецификация suffix-byte-range-spec используется для задания суффикса тела объекта с длиной, заданной значением suffix-length. (То есть, эта форма специфицирует последние N байтов тела объекта.) Если объект короче заданной длины суффикса, то в качестве суффикса используется все тело объекта. Примеры значений byte-ranges-specifier (предполагается, что длина тела объекта равна 10000):
bytes=9500-
13.36.2. Запросы получения фрагментов Информационные запросы HTTP, использующие условные или безусловные методы GET могут заказывать один или более субфрагментов объекта, а не целый объект, используя заголовок запроса Range:
Сервер может игнорировать заголовок Range. Однако исходные серверы HTTP/1.1 и промежуточные кэши должны поддерживать по возможности работу с фрагментами, так как Range поддерживает эффективное восстановление в случае частично неудачных пересылок больших объектов. Если сервер поддерживает заголовки Range и специфицированный фрагмент или фрагменты подходят для данного объекта, то:
В некоторых случаях более удобно использовать заголовок If-Range (см. раздел 13.27). Если прокси, который поддерживает фрагменты, получает запрос Range, переадресует запрос внешнему серверу и получает в ответ весь объект, ему следует прислать запрашиваемый фрагмент клиенту. Он должен запомнить весь полученный отклик в своем кэше, если отклик совместим с политикой записи в его кэш. Поле заголовка запроса Referer позволяет клиенту специфицировать (для пользы сервера) адрес (URI) ресурса, из которого был получен Request-URI. Заголовок запроса Referer позволяет серверу генерировать список обратных связей с ресурсами для интереса, ведения дневника, оптимизации кэширования и т.д.. Он позволяет также заставить работать устаревшие или дефектные связи. Поле Referer не должно посылаться, если Request-URI был получен от источника, который не имеет своего собственного URI, такого, например, как ввод с пользовательского терминала.
Пример: Referer: http://www.w3.org/hypertext/DataSources/Overview.html Если значением поля является частичный URI, его следует интерпретировать относительно Request-URI. URI не должен включать фрагментов. Замечание. Так как первоисточник связи может быть конфиденциальной информацией или может раскрывать другой источник частной информации, настоятельно рекомендуется, чтобы пользователь имел возможность решать, посылать поле Referer или нет. Например, клиент-броузер может иметь кнопку-переключатель для открытого или анонимного просмотра, которая управляет активацией/дезактивацией посылки информации Referer и From. Поле заголовка отклика Retry-After может использоваться с кодом статуса 503 (Service Unavailable) с тем, чтобы указать, как еще долго данная услуга предполагается быть недоступной для запрашивающего клиента. Значением этого поля может быть либо дата HTTP либо целое число секунд (в десятичном исчислении) после отправки отклика.
Два примера использования поля Retry-After: Fri, 31 Dec 1999 23:59:59 GMT В последнем примере задержка равна двум минутам. Поле заголовка отклика Server содержит информацию о программном обеспечении, используемым исходным сервером для обработки запросов. Поле может содержать коды многих продуктов (раздел 2.8), комментарии, идентифицирующие сервер, и некоторые важные субпродукты. Коды программных продуктов перечисляются в порядке важности приложений.
Например: Server: CERN/3.0 libwww/2.17 Если отклик переадресуется через прокси, приложение прокси не должно модифицировать заголовок отклика сервера. Вместо этого ему следует включить в отклик поле Via (как это описано в разделе 13.44). Замечание. Раскрытие конкретной версии программного обеспечения сервера может облегчить атаки против программных продуктов, для которых известны уязвимые места. Разработчикам серверов рекомендуется сделать это поле конфигурируемой опцией. 13.40. Поле Transfer-Encoding (Транспортное кодирование) Поле общего заголовка Transfer-Encoding указывает, какой тип преобразования (если таковое использовано) применен к телу сообщения, для того чтобы безопасно осуществить передачу между отправителем и получателем. Это поле отличается от Content-Encoding тем, что транспортное кодирование является параметром сообщения, а не объекта. Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding Транспортное кодирование определено в разделе 2.6. Например: Transfer-Encoding: chunked Многие старые приложения HTTP/1.0 не воспринимают заголовок Transfer-Encoding. 13.41. Заголовок Upgrade (Актуализация) Общий заголовок Upgrade позволяет клиенту специфицировать то, какие дополнительные коммуникационные протоколы он поддерживает и хотел бы использовать, если сервер найдет их подходящими. Сервер должен использовать поле заголовка Upgrade в отклике 101 (Switching Protocols) для указания того, какие протоколы активны.
Например:, Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Поле заголовка Upgrade предназначено для обеспечения простого механизма перехода от протокола HTTP/1.1 к некоторым другим. Это достигается путем разрешения клиенту объявлять о намерении использовать другой протокол, например, более позднюю версию HTTP с большим старшим кодом версии, даже если текущий запрос выполнен с использованием HTTP/1.1. Это облегчает переходы между несовместимыми протоколами за счет разрешения клиенту инициировать запрос в более широко поддерживаемом протоколе, в то же время, указывая серверу, что он предпочел бы использовать протокол "получше", если таковой доступен (где слово "получше" определяется сервером, возможно согласно природы метода и/или запрашиваемого ресурса). Поле заголовка Upgrade воздействует только на переключающий протокол прикладного уровня транспортного слоя существующег соединения. Upgrade не может быть использовано для требования изменения протокола, его восприятие и использование сервером является опционным. Совместимость и природа прикладного уровня коммуникаций после смены протокола зависит исключительно от нового выбранного протокола, хотя первым действием после такой замены должен быть отклик на исходный запрос HTTP, содержащий поле заголовка Upgrade. Поле Upgrade применимо только к текущему соединению. Следовательно, ключевое слово upgrade должно содержаться в поле заголовка Connection (раздел 13.10) всякий раз, когда поле Upgrade присутствует в сообщении HTTP/1.1. Поле заголовка Upgrade не может использоваться для указания смены протокола в другом соединении. Для этой цели более приемлемы отклики переадресации с кодами 301, 302, 303 или 305. Эта спецификация определяет протокол с именем "HTTP" при работе с семейством протоколов для передачи гипертекста (Hypertext Transfer Protocols), как это определено в правилах работы с версиями HTTP раздела 2.1 и для будущих усовершенствований этой спецификации. В качестве имени протокола может использоваться любая лексема, однако она будет работать, только если клиент и сервер ассоциируют это имя с одним и тем же протоколом. 13.42. Поле User-Agent (Агент пользователя) Поле заголовка отклика User-Agent содержит информацию об агенте пользователя, инициировавшем запрос. Это нужно для целей сбора статистических данных, отслеживания нарушений протокола и автоматического распознавания агентов пользователя. Агентам пользователя рекомендуется включать это поле в запросы. Поле может содержать несколько кодов продуктов (раздел 2.8), комментарии, идентифицирующие агента и любые субпродукты, которые образуют существенную часть агента пользователя. Согласно договоренности коды программных продуктов перечисляются в порядке их важности для идентифицируемого приложения.
Например: User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Поле заголовка отклика Vary используется сервером для того, чтобы сигнализировать о том, что отклик выбран из числа имеющихся представлений с помощью механизма согласования под управлением сервера (раздел 11). Имена полей, перечисленные в заголовках Vary, являются такими заголовками запроса. Значение поля Vary указывает на то, что данный набор полей заголовка ограничивает пределы, в которых могут варьироваться представления, или что пределы вариации не специфицированы ("*") и, таким образом, могут модифицироваться в широких пределах для будущих запросов.
Сервер HTTP/1.1 должен включать соответствующее поле заголовка Vary в любой кэшируемый отклик, который является субъектом, управляющим процессом согласования. Такая схема позволяет кэшу правильно интерпретировать будущие запросы к заданному ресурсу и информирует пользователя о согласовании доступа к ресурсу. Серверу следует включить соответствующее поле заголовка Vary в некэшируемый отклик, который является субъектом, управляющим согласованием, так как это может предоставить агенту пользователя полезную информацию о пределах вариации отклика. Набор полей заголовка, перечисленных в поле Vary известен как "выбирающие" заголовки запроса. Когда кэш получает последующий запрос, чей Request-URI специфицирует одну или более записей кэша, включая заголовок Vary, кэш не должен использовать такую запись для формирования отклика на новый запрос. Он это должен делать, если только все заголовки, перечисленные в кэшированном заголовке Vary, присутствуют в новом запросе и все заголовки отбора предшествующих запросов совпадают с соответствующими заголовками нового запроса. Сортирующие заголовки от двух запросов считаются соответствующими, тогда и только тогда, когда сортирующие заголовки первого запроса могут быть преобразованы в сортирующие заголовки второго запроса с помощью добавления или удаления строчных пробелов LWS (Linear White Space) в местах, где это допускается соответствующими правилами BNF (Backus-Naur Form) и/или, комбинируя несколько полей заголовка согласно требованиям на построение сообщения из раздела 3.2. Vary "*" означает, что не специфицированные параметры, возможно отличающиеся от содержащихся в полях заголовка (напр., сетевой адрес клиента), играют роль при выборе представления отклика. Последующие запросы данного ресурса могут быть правильно интерпретированы только исходным сервером, а кэш должен переадресовать запрос (возможно условно), даже когда он имеет свежий кэшированный отклик для данного ресурса. Об использовании заголовка кэшами см. раздел 12.6. Значение поля Vary, состоящее из списка имен полей сигнализирует о том, что представление, выбранное для отклика, базируется на алгоритме выбора, который рассматривает только значения перечисленные в поле заголовка запроса. Кэш может предполагать, что тот же выбор будет сделан для будущих запросов с теми же значениями имен полей, для периода времени, в течение которого отклик остается свежим. Имена полей не ограничены набором стандартных полей заголовков запросов, определенных в данной спецификации. Имена полей могут быть записаны строчными или прописными буквами. Поле общего заголовка Via должно быть использовано шлюзами или прокси для указания промежуточных протоколов и получателей на пути от агента пользователя к серверу, которому адресован запрос, и между исходным сервером и клиентом в случае отклика. Это аналогично полю "Received" документа RFC 822 и предназначено для использования при трассировке переадресаций сообщений, исключения петель запроса и идентификации протокольных возможностей всех отправителей вдоль цепочки запрос/отклик.
Запись "received-protocol" указывает версию протокола в сообщении, полученном сервером или клиентом вдоль цепочки запрос/отклик. Версия received-protocol добавляется к значению поля Via, когда сообщение переадресуется, так что информация о возможностях протоколов предыдущих приложений остается прозрачной для всех получателей. Запись "protocol-name" является опционной, тогда и только тогда, когда это "HTTP". Поле "received-by" обычно соответствует ЭВМ и номеру порта сервера получателя или клиента, который переадресует сообщение. Однако, если настоящее имя ЭВМ считается конфиденциальной информацией, оно может быть заменено псевдонимом. Если номер порта не задан, можно предполагать, что используется значение по умолчанию для данного протокола (received-protocol). Значения поля Via представляет каждый прокси или шлюз, который переадресовывал сообщение. Каждый получатель должен присоединить свою информацию так, что конечный результат оказывается упорядоченным согласно последовательности переадресующих приложений. Комментарии могут быть использованы в поле заголовка Via для идентификации программ получателя прокси или шлюза аналогично полям User-Agent и Server header. Однако, все комментарии в поле Via являются опционными и могут быть удалены любым получателем перед тем, как переадресовать сообщение. Например, сообщение-запрос может быть послано от агента пользователя HTTP/1.0 программе внутреннего прокси с именем "fred", которая использует HTTP/1.1 для того, чтобы переадресовать запрос общедоступному прокси с именем nowhere.com, который завершает процесс переадресации запроса исходному серверу www.ics.uci.edu. Запрос, полученный www.ics.uci.edu будет тогда иметь следующее поле заголовка Via: Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) Прокси и шлюзы, используемые как средства сетевой защиты (firewall) не должны по умолчанию переадресовывать имена ЭВМ и портов в пределах области firewall. Эта информация может передаваться, если это непосредственно позволено. Если это не разрешено, запись "received-by" для ЭВМ в зоне действия firewall должна быть заменена соответствующим псевдонимом. Для организаций, которые имеют жесткие требования к защите конфиденциальности и сокрытию внутренней структуры, прокси может комбинировать субпоследовательность поля заголовка Via с идентичными значениями "received-protocol" в единую запись. Например, Via: 1.0 vanya, 1.1 manya, 1.1 dunya, 1.0 sonya Приложениям не следует комбинировать несколько записей, если они только не находятся под единым административным контролем и имена ЭВМ уже заменены на псевдонимы. Приложения не должны комбинировать записи, которые имеют различные значения "received-protocol". 13.45. Поле Warning (Предупреждение) Поле заголовка отклика Warning используется для переноса дополнительной информации о состоянии отклика, которая может отражать статусный код. Эта информация обычно служит для предупреждения о возможной потере семантической прозрачности из-за операций кэширования. Заголовки Warning посылаются с откликами, используя:
; имя или псевдоним сервера, добавившего заголовок Warning, предназначенный для целей отладки
Отклик может нести в себе более одного заголовка Warning. Запись warn-text производится на естественном языке и с применением символьного набора, приемлемого для принимающего отклик лица. Это решение может базироваться на какой-то имеющейся информации, такой как положение кэша или пользователя, поле запроса Accept-Language, поле отклика Content-Language и т.д. Языком по умолчанию является английский, а символьным набором - ISO-8859-1. Если используется символьный набор отличный от ISO-8859-1, он должен быть закодирован в warn-text с использованием метода, описанного в RFC-1522 [14]. Любой сервер или кэш может добавить заголовки Warning к отклику. Новые заголовки Warning должны добавляться после любых существующих заголовков Warning. Кэш не должен уничтожать какие-либо заголовки, которые он получил в отклике. Однако, если кэш успешно перепроверил запись, ему следует удалить все заголовки Warning, присоединенные ранее, за исключением специальных кодов Warning. Он должен добавить к записи новые заголовки Warning, полученные с откликом перепроверки. Другими словами заголовками Warning являются те, которые были бы получены в отклике на запрос в данный момент. Когда к отклику подключено несколько заголовков Warning, агенту пользователя следует отображать их столько, сколько возможно, для того чтобы они появились в отклике. Если невозможно отобразить все предупреждения, агент пользователя должен следовать следующим эвристическим правилам:
Системы, которые генерируют несколько заголовков Warning, должны упорядочить их с учетом ожидаемого поведения агента пользователя. Далее представлен список определенных в настоящее время кодов предупреждений, каждый из которых сопровождается рекомендуемым текстом на английском языке и описанием его значения. 10 Response is stale (отклик устарел) Должно включаться всякий раз, когда присылаемый отклик является устаревшим. Кэш может добавить это предупреждение к любому отклику, но не может удалить его до тех пор, пока не будет установлено, что отклик является свежим. 11 Revalidation failed (перепроверка пригодности неудачна) Должно включаться, если кэш присылает устаревший отклик, потому что попытка перепроверить его пригодность не удалась, из-за невозможности достичь сервера. Кэш может добавить это предупреждение к любому отклику, но никогда не может удалить его до тех пор, пока не будет успешно проведена перепроверка пригодности отклика. 12 Disconnected operation (работа в отключенном от сети состоянии) Следует включать, если кэш намерено отключен от остальной сети на определенный период времени. 13 Heuristic expiration (эвристическое завершение периода пригодности) Должно включаться, если кэш эвристически выбрал время жизни больше 24 часов, а возраст отклика превышает эту величину. 14 Transformation applied (применено преобразование) Должно добавляться промежуточным кэшем или прокси, если он использует какое-либо преобразование, изменяющее кодировку содержимого (как это специфицировано в заголовке Content-Encoding) или тип среды (как это описано в заголовке Content-Type) отклика, если только этот код предупреждения не присутствует уже в отклике. 99 Разные предупреждения Текст предупреждения включает в себя любую информацию, которая может быть представлена человеку-оператору или может быть занесена в дневник операций. Система, получающая это предупреждение, не должна предпринимать каких-либо действий автоматически. Поле заголовка отклика WWW-Authenticate должно включаться в сообщения откликов со статусным кодом 401 (Unauthorized). Значение поля содержит, по крайней мере, одно требование, которое указывает на схему идентификации и параметры, применимые для Request-URI. WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge Процесс авторизации доступа HTTP описан в разделе 10. Агенты пользователя должны проявлять особую тщательность при разборе значения поля WWW-Authenticate, если оно содержит более одного требования, или если прислан более чем одно поле заголовка WWW-Authenticate, так как содержимое требования может само содержать список параметров идентификации, элементы которого разделены запятыми. Этот раздел предназначен для того, чтобы проинформировать разработчиков приложений, поставщиков информации и пользователей об ограничениях безопасности в HTTP/1.1, как это описано в данном документе. Обсуждение не включает определенные решения данных проблем, но рассматриваются некоторые предложения, которые могут уменьшить риск. Базовая схема идентификации не предоставляет безопасного метода идентификации пользователя, не обеспечивает она и какох-либо средств защиты объектов, которые передаются открытым текстом по используемым физическим сетям. HTTP не мешает внедрению дополнительных схем идентификации и механизмов шифрования или других мер, улучшающих безопасность системы (например, SSL или одноразовых паролей). Наиболее серьезным дефектом базового механизма идентификации является то, что пароль пользователя передается по сети в незашифрованном виде. Так как базовая идентификация предусматривает пересылку паролей открытым текстом, она никогда не должна использоваться (без улучшения) для работы с конфиденциальной информацией. Обычным назначением базовой идентификации является создание информационной (справочной) среды, которая требует от пользователя его имени и пароля, например, для сбора точной статистики использования ресурсов сервера. При таком использовании предполагается, что не существует никакой опасности даже в случае неавторизованного доступа к защищенному документу. Это правильно, если сервер генерирует сам имя и пароль пользователя и не позволяет ему выбрать себе пароль самостоятельно. Опасность возникает, когда наивные пользователи часто используют один и тот же пароль, чтобы избежать необходимости внедрения многопарольной системы защиты. Если сервер позволяет пользователям выбрать их собственный пароль, тогда возникает опасность несанкционированного доступа к документам на сервере и доступа ко всем аккаунтам пользователей, которые выбрали собственные пароли. Если пользователям разрешен выбор собственных паролей, то это означает, что сервер должен держать файлы, содержащие пароли (предположительно в зашифрованном виде). Многие из этих паролей могут принадлежать удаленным пользователям. Собственник или администратор такой системы может помимо своей воли оказаться ответственным за нарушения безопасности сохранения информации. Базовая идентификация уязвима также для атак поддельных серверов. Когда пользователь связывается с ЭВМ, содержащей информацию, защищенную с использованием базовой системой идентификации, может так получиться, что в действительности он соединяется с сервером-злоумышленником, целью которого является получение идентификационных параметров пользователя (например, имени и пароля). Этот тип атак не возможен при использовании идентификации с помощью дайджестов [32]. Разработчики серверов должны учитывать возможности такого рода атак со стороны ложных серверов или CGI-скриптов. В частности, очень опасно для сервера просто прерывать связь со шлюзом, так как этот шлюз может тогда использовать механизм постоянного соединения для выполнения нескольких процедур с клиентом, исполняя роль исходного сервера, так что это незаметно клиенту. 14.2. Предложение выбора схемы идентификации Сервер HTTP/1.1 может прислать несколько требований с откликом 401 (Authenticate) и каждое требование может использовать разную схему. Порядок присылки требований соответствует шкале предпочтений сервера. Сервер должен упорядочит требования так, чтобы наиболее безопасная схема предлагалась первой. Агент пользователя должен выбрать первую понятную ему схему. Когда сервер предлагает выбор схемы идентификации, используя заголовок WWW-Authenticate, безопасность может быть нарушена только за счет того, что злонамеренный пользователь может перехватить набор требований и попытаться идентифицировать себя, используя саму слабую схему идентификации. Таким образом, упорядочение служит более для защиты идентификационных параметров пользователя, чем для защиты информации на сервере. Возможна атака MITM (man-in-the-middle - "человек в середине"), которая заключается в добавлении слабой схемы идентификации к списку выбора в надежде на то, что клиент выберет именно ее и раскроет свой пароль. По этой причине клиент должен всегда использовать наиболее строгую схему идентификации из предлагаемого списка. Еще эффективнее может быть MITM-атака, при которой удаляется весь список предлагаемых схем идентификации, и вставляется вызов, требующий базовой схемы идентификации. По этой причине агенты пользователя, обеспокоенные таким видом атак, могут запомнить самую строгую схему идентификации, которая когда-либо запрашивалась данным сервером, и выдавать предупреждение, которое потребует подтверждения пользователя при использовании более слабой схемы идентификации. Особенно хитроумный способ реализации MITM-атаки является предложение услуг "свободного" кэширования для доверчивых пользователей. 14.3. Злоупотребление служебными (Log) записями сервера Сервер должен оберегать информацию о запросах пользователя, о характере его интересов (такая информация доступна в дневнике операций сервера). Эта информация является, очевидно, конфиденциальной по своей природе и работа с ней во многих странах ограничена законом. Люди, использующие протокол HTTP для получения данных, являются ответственными за то, чтобы эта информация не распространялась без разрешения лиц, кого эта информация касается. 14.4. Передача конфиденциальной информации Подобно любому общему протоколу передачи данных, HTTP не может регулировать содержимое передаваемых данных, не существует методов определения степени конфиденциальности конкретного фрагмента данных в пределах контекста запроса. Следовательно, приложения должны предоставлять как можно больше контроля провайдеру информации. Четыре поля заголовка представляют интерес с этой точки зрения: Server, Via, Referer и From. Раскрытие версии программного обеспечения сервера может привести к большей уязвимости машины сервера к атакам на программы с известными слабостями. Разработчики должны сделать поле заголовка Server конфигурируемой опцией. Прокси, которые служат в качестве сетевого firewall, должны предпринимать специальные предосторожности в отношении передачи информации заголовков, идентифицирующей ЭВМ, за пределы firewall. В частности они должны удалять или замещать любые поля Via, созданные в пределах firewall. Хотя поле Referer может быть очень полезным, его мощь может быть использована во вред, если данные о пользователе не отделены от другой информации, содержащейся в этом поле. Даже когда персональная информация удалена, поле Referer может указывать на URI частных документов, чья публикация нежелательна. Информация, посланная в поле From, может вступать в конфликт с интересами конфиденциальности пользователя или с политикой безопасности его домена, и, следовательно, она не должна пересылаться и модифицироваться без прямого разрешения пользователя. Пользователь должен быть способен установить содержимое этого поля, в противном случае оно будет установлено равным значению по умолчанию. Мы предлагаем, хотя и не требуем, чтобы предоставлялся удобный интерфейс для пользователя, который позволяет активировать и дезактивировать посылку информации полей From и Referer. 14.5. Атаки, основанные на именах файлов и проходов Реализации исходных серверов HTTP должна быть тщательной, чтобы ограничить список присылаемых HTTP документов теми, которые определены для этого администратором сервера. Если сервер HTTP транслирует HTTP URI непосредственно в запросы к файловой системе, сервер должен следить за тем, чтобы не пересылать файлы клиентам HTTP, для этого не предназначенные. Например, UNIX, Microsoft Windows и другие операционные системы используют ".." как компоненту прохода, чтобы указать уровень каталога выше текущего. В такой системе сервер HTTP должен запретить любую подобную в Request-URI, если она позволяет доступ к ресурсу за пределами того, что предполагалось. Аналогично, файлы, предназначенные только для внутреннего использования сервером (такие как файлы управления доступом, конфигурационные файлы и коды скриптов) должны быть защищены от несанкционированного доступа, так как они могут содержать конфиденциальную информацию. Практика показала, что даже незначительные ошибки в реализации сервера HTTP могут привести к рискам безопасности. Клиентам HTTP небезразличнен доступ к некоторым данным (например, к имени пользователя, IP-адресу, почтовому адресу, паролю, ключу шифрования и т.д.). Система должна быть тщательно сконструирована, чтобы предотвратить непреднамеренную утечку информации через протокол HTTP. Мы настоятельно рекомендуем, чтобы был создан удобный интерфейс для обеспечения пользователя возможностями управления распространением такой информации. 14.7. Аспекты конфиденциальности, связанные с заголовками Accept Заголовок запроса Accept может раскрыть информацию о пользователе всем серверам, к которым имеется доступ. В частности, заголовок Accept-Language может раскрыть информацию, которую пользователь, возможно, рассматривает как конфиденциальную. Так, например, понимание определенного языка часто строго коррелируется с принадлежностью к определенной этнической группе. Агентам пользователя, которые предлагают возможность конфигурирования содержимого заголовка Accept-Language, настоятельно рекомендуется посылать сообщение пользователю о том, что в результате может быть потеряна конфиденциальность определенных данных. Подходом, который ограничивает потерю конфиденциальности для агента пользователя, может быть отказ от посылки заголовков Accept-Language по умолчанию. Предполагается при этом каждый раз консультироваться с пользователем относительно возможности посылки этих данных серверу. Пользователь будет принимать решение о посылке Accept-Language, лишь убедившись на основании содержимого заголовка отклика Vary в том, что такая посылка существенно улучшит качество обслуживания. Для многих пользователей, которые размещены не за прокси, сетевой адрес работающего агента пользователя может также использоваться как его идентификатор. В среде, где прокси используются для повышения уровня конфиденциальности, агенты пользователя должны быть достаточно консервативны в предоставлении опционного конфигурирования заголовков доступа конечным пользователям. В качестве крайней меры обеспечения защиты прокси могут фильтровать заголовки доступа для передаваемых запросов. Главной целью агентов пользователя, которые предоставляют высокий уровень конфигурационных возможностей, должно быть предупреждение пользователя о возможной потере конфиденциальности. Клиенты, интенсивно использующие HTTP обмен со службой имен домена (Domain Name Service), обычно предрасположены к атакам, базирующимся на преднамеренном некорректном соответствии IP адресов и DNS имен. Клиенты должны быть осторожны относительно предположений, связанных с ассоциаций IP адресов и DNS имен. В частности, клиенту HTTP следует полагаться на его сервер имен для подтверждения соответствия IP адресов и DNS имен, а не слепо кэшировать результаты предшествующих запросов. Многие платформы могут кэшировать такие запросы локально и это надо использовать, конфигурируя их соответствующим образом. Такие запросы должны кэшироваться, однако только на период, пока не истекло время жизни этой информации. Если клиенты HTTP кэшируют результат DNS-запроса для улучшения рабочих характеристик, они должны отслеживать пригодность этих данных с учетом времени жизни, объявляемого DNS-сервером. Если клиенты HTTP не следуют этому правилу, они могут быть мистифицированы, когда изменится IP-адрес доступного ранее сервера. Так как смена адресов в сетях будет в ближайшее время активно развиваться (Ipv6 !), такого рода атаки становятся все более вероятными. Данное требование улучшает работу клиентов, в том числе с серверами, имеющими идентичные имена. 14.9. Заголовки Location и мистификация Если один сервер поддерживает несколько организаций, которые не доверяют друг другу, тогда он должен проверять значения заголовков Location и Content-Location в откликах, которые формируются под управлением этих организаций. Это следует делать, чтобы быть уверенным, что они не пытаются провести какие-либо операции над ресурсами, доступ к которым для них ограничен.
16. Приложения
В дополнение к определению протокола HTTP/1.1, данный документ является спецификацией для типов среды Интернет "message/http". Ниже приведенный список является официальным для IANA.
version: Номер версии HTTP вложенного сообщения (напр., "1.1"). Если отсутствует, номер версии может быть определен по первой строке тела сообщения. msgtype: Тип сообщения -- "запроса" или "отклика". Если отсутствует, тип может быть определен по первой строке тела сообщения. Соображения кодирования: разрешено только "7bit", "8bit" или "binary" (двоичное). 16.2. Тип среды Интернет "multipart/byteranges" Когда сообщение HTTP содержит несколько фрагментов (ranges) (например, отклик на запрос нескольких не перекрывающихся фрагментов), они пересылаются как многофрагментное сообщение MIME. Тип среды multipart для этих целей носит название "multipart/byteranges". Тип среды multipart/byteranges содержит в себе две или более части, каждая из которых со своими полями Content-Type и Content-Range. Отдельные части разделяются с использованием пограничного параметра MIME.
Соображения кодирования: разрешено только "7bit", "8bit" или "binary".
Хотя этот документ специфицирует требования к генерации HTTP/1.1 сообщений, не все приложения будут корректны. Мы, следовательно, рекомендуем, чтобы рабочие приложения были толерантны (терпимы) к некоторым отклонениям от требований, при условии, что эти отклонения можно однозначно интерпретировать. Клиенту следует быть толерантным при разборе Status-Line, а серверу - при разборе Request-Line. В частности, им следует воспринимать любое число символов SP или HT между полями, хотя требуется только один пробел (SP). Терминатором строки полей заголовков сообщения является CRLF. Однако рекомендуется, чтобы приложение при разборе таких заголовков распознавало в качестве терминатора строки одиночный символ LF и игнорировала предыдущий символ CR. Символьный набор тела объекта должен быть снабжен меткой. Метка не нужна только для набора US-ASCII или ISO-8859-1. Правила разбора и кодирования дат и пр. включают в себя предположение, что HTTP/1.1 клиенты и кэши должны предполагать, что даты, следующие документу RFC-850 и относящиеся ко времени 50 лет в будущем, на самом деле относятся к прошлому (это помогает решить проблему "2000-го года").
Если заголовок HTTP несет в себе некорректное значение даты с временной зоной отличной от GMT, значение должно быть преобразовано в GMT. 16.4. Различие между объектами HTTP и MIME HTTP/1.1 использует много конструкций, определенных для электронной почты Интернет (RFC 822) и MIME (Multipurpose Internet Mail Extensions), для обеспечения пересылки объектов в различных представлениях. MIME [7] обслуживает электронную почту, а HTTP имеет лишь ряд черт, которые отличают его от MIME. Эти отличия тщательно подобраны, чтобы оптимизировать работу в условиях двоичных соединений, с тем чтобы достичь большей свободы в использовании новых типов сред. Прокси и шлюзы должны по возможности исключать такие отличия и обеспечивать соответствующие преобразования там, где это нужно. 16.4.1. Преобразование к канонической форме MIME требует, чтобы почтовый объект Интернет перед посылкой был преобразован в каноническую форму. Раздел 2.7.1 описывает формы, допустимые для подтипов типа среды "text" при пересылке с использованием HTTP. MIME требует, чтобы содержимое типа "text" представляло разрывы строк в виде последовательности символов CRLF и запрещает использование CR или LF отдельно. Для обозначения разрыва строки HTTP позволяет использовать CRLF, одиночный CR и одиночный LF. Всюду где возможно, прокси и шлюзы между средами HTTP и MIME должны преобразовать все разрывы строк для текстовых типов среды, как это описано в разделе 2.7.1. Заметьте однако, что это может вызвать сложности в присутствии кодирования содержимого, а также вследствие того, что HTTP допускает применение символьных наборов, которые не используют октеты 13 и 10 для представления CR и LF, так как для этих целей здесь служат многобайтовые последовательности. 16.4.2. Преобразование форматов даты Для того чтобы упростить сравнение, HTTP/1.1 использует ограниченный набор форматов даты (раздел 2.3.1). Прокси и шлюзы должны позаботиться о преобразовании полей заголовков даты в один из допустимых форматов всякий раз, когда это необходимо (при получении данных от других протоколов). 16.4.3. Введение кодирования содержимого MIME не содержит какого-либо эквивалента полю заголовка Content-Encoding HTTP/1.1.
Так как это поле работает как модификатор типа среды, прокси и шлюзы между HTTP и MIME протоколами должны или
изменить значение поля заголовка Content-Type или декодировать тело объекта, прежде чем переадресовывать
сообщение. Некоторые экспериментальные приложения Content-Type для почты Интернет используют
параметр типа среды ";conversions= 16.4.4. No Content-Transfer-Encoding HTTP не использует поле MIME CTE (Content-Transfer-Encoding). Прокси и шлюзы от MIME к HTTP должны удалять любую не идентичность CTE ("quoted-printable" или "base64") кодирования, прежде чем доставлять сообщение-отклик клиенту HTTP. Прокси и шлюзы от HTTP к MIME ответственны за то, чтобы сообщения имели корректные форматы и кодировки для безопасной транспортировки, (где безопасная транспортировка определяется ограничениями используемого протокола). Такие прокси и шлюзы должны помечать информацию согласно Content-Transfer-Encoding, поступая так, мы улучшаем вероятность безопасной транспортировки с использованием протокола места назначения. 16.4.5. Поля заголовка в многофрагментных телах В MIME, большинство полей заголовка в многофрагментных частях игнорируются, если только имя поля не начинается с "Content-". В HTTP/1.1, многофрагментные части тела могут содержать любые поля заголовков HTTP, которые имеют смысл для этой части. 16.4.6. Введение транспортного кодирования HTTP/1.1 вводит поле заголовка Transfer-Encoding (раздел 13.40). Прокси/шлюзы должны удалять любое транспортное кодирование перед переадресацией сообщения через протокол MIME. Процесс декодирования транспортного кода (раздел 2.6) может быть представлен в виде псевдо-программы: length := 0 append chunk-data to entity-body length := length + chunk-size read chunk-size and CRLF read entity-header while (entity-header not empty) { read entity-header Content-Length := length Remove "chunked" from Transfer-Encoding HTTP не является протоколом, совместимым с MIME (смотри приложение 16.4). Однако HTTP/1.1 сообщения могут включать поле общего заголовка MIME-Version, для того чтобы указать, какая версия протокола MIME была использована для конструирования сообщения. Использование заголовка поля MIME-Version отмечает, сообщение полностью соответствует протоколу MIME. Прокси/шлюзы несут ответственность за полную совместимость (где возможно), когда осуществляется передача HTTP сообщений в среду MIME. MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT HTTP/1.1 использует по умолчанию версию MIME "1.0". Однако разбор сообщений HTTP/1.1 и семантика определяются данным документом, а не спецификацией MIME. 16.5. Изменения по отношению HTTP/1.0 Этот раздел обобщает основные отличия между версиями HTTP/1.0 и HTTP/1.1. 16.5.1. Изменения с целью упрощения распределенных WWW-сервером и экономии IP адресов Требование того, чтобы клиенты и серверы воспринимали абсолютные URI (раздел 4.1.2) и поддерживали заголовки Host, откликались кодами ошибки при отсутствии заголовка Host (раздел 13.23) в запросе HTTP/1.1, являются наиболее важными изменениями, внесенными данной спецификацией. Более старые HTTP/1.0 клиенты предполагают однозначное соответствие IP адресов и серверов. Изменения, описанные выше, позволяют Интернет поддерживать несколько WWW узлов с помощью одного IP-адреса. Высокая скорость роста WWW-сети, большое число уже существующих серверов делают крайне важным, чтобы реализации HTTP (включая усовершенствования существующих HTTP/1.0 приложений) корректно следовали перечисленным ниже требованиям:
Это приложение документирует протокольные элементы, используемые некоторыми существующими реализациями HTTP, но не вполне корректно совместимыми с большинством HTTP/1.1 приложений.
16.6.1. Дополнительные методы запросов Метод PATCH подобен PUT, за исключением того, что объект содержит список отличий между оригинальной версией ресурса, идентифицированного Request-URI, и желательной версией ресурса после операции PATCH. Список отличий записывается в формате, определенном типом среды объекта (например, "application/diff"), и должен включать достаточную информацию, чтобы позволить серверу выполнить изменения по преобразованию ресурса из исходной версии в заказанную. Если запрос проходит через кэш и Request-URI идентифицирует объект в кэше, этот объект должен быть удален из кэша. Отклики для этого метода не кэшируются. Реальный метод определения того, как разместится скорректированный ресурс и что случится с его предшественником, определяется исключительно исходным сервером. Если оригинальная версия ресурса, который предполагается скорректировать, включает в себя поле заголовка Content-Version, объект запроса должен включать поле заголовка Derived-From, соответствующее значению оригинального поля заголовка Content-Version. Приложениям рекомендуется использовать эти поля для работы с версиями с целью разрешения соответствующих конфликтов. Запросы PATCH должны подчиняться требованиям к передаче сообщений, установленным в разделе 7.2. Кэши, которые реализуют PATCH, должны объявить кэшированные отклики недействительными, как это описано в разделе 12.10 для PUT. Метод LINK устанавливает один или более связей между ресурсами, идентифицированными Request-URI, и другими существующими ресурсами. Отличие между LINK и другими методами, допускающими установление связей между ресурсами, заключается в том, что метод LINK не позволяет послать в запросе любое тело сообщения и не вызывает непосредственно создания новых ресурсов. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют LINK, должны объявить кэшированные отклики непригодными, как это определено в разделе 12.10 для PUT. Метод UNLINK удаляет одну или более связей между ресурсами, идентифицированными Request-URI. Эти связи могут быть установлены с использованием метода LINK или каким-либо другим методом, поддерживающим заголовок Link. Удаление связи с ресурсом не подразумевает, что ресурс перестает существовать или становится недоступным. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют UNLINK, должны объявить кэшированные отклики непригодными, как это определено в разделе 12.10 для PUT.
16.6.2. Определения дополнительных полей заголовка Поле заголовка отклика Alternates было предложено в качестве средства исходного сервера для информирования клиента о других доступных представлениях запрошенного ресурса. При этом выдается информация об их специфических атрибутах, все это образует более надежное основание агенту пользователя для выбора представления, которое лучше соответствует желаниям пользователя (описано как согласование под управлением агента пользователя в разделе 11). Поле заголовка Alternates является ортогональным по отношению к полю заголовка Vary, вместе с тем они могут сосуществовать в сообщении без последствий для интерпретации отклика или доступных представлений. Ожидается, что поле Alternates предоставит заметное улучшение по сравнению с согласованием под управлением сервера, предоставляемым полем Vary для ресурсов, которые варьируются в общих пределах подобно типу и языку. Поле заголовка Alternates будет определено в будущей спецификации. 16.6.2.2. Поле Content-Version Поле заголовка объекта Content-Version определяет метку версии, ассоциированную с отображением объекта. Вместе с полем Derived-From, 16.6.2.3, это позволяет группе людей вести разработку в интерактивном режиме. Content-Version = "Content-Version" ":" quoted-string. Примеры использования поля Content-Version: Content-Version: "2.1.2"Content-Version: "Fred 19950116-12:26:48" Content-Version: "2.5a4-omega7" Поле заголовка объекта Derived-From может использоваться для индикации метки версии ресурса, из которого был извлечен объект до модификации, выполненной отправителем. Это поле используется для того, чтобы помочь управлять процессом эволюции ресурса, в частности, когда изменения выполняются в параллель многими субъектами. Derived-From = "Derived-From" ":" quoted-string. Пример использования поля: Derived-From: "2.1.1". Поле Derived-From необходимо для запросов PUT и PATCH, если посланный объект был перед этим извлечен из того же URI и заголовок Content-Version был включен в объект, когда он последний раз извлекался. Поле заголовка объекта Link предоставляет средства для описания взаимоотношений между ресурсами. Объект может включать много значений поля Link. Связи на уровне метаинформации обычно указывают на отношения типа структуры иерархии и пути прохода. Поле Link семантически эквивалентно элементу в HTML[5].
Запись значений отношения не зависит от использования строчных или прописных букв и может быть расширена в рамках синтаксиса имен sgml. Параметр заголовка может быть использован для пометки места назначения связи, такой как используется при идентификации в рамках меню для пользователя. Параметр типа якорь может использоваться для индикации источника якоря, отличного от всего текущего ресурса, такого как фрагмент данного ресурса. Примеры использования: Link: Первый пример указывает, что глава 2 предшествует данному ресурсу с точки зрения логического прохода. Второй указывает, что лицо, ответственное за данный ресурс, имеет приведенный адрес электронной почты. Поле заголовка URI использовалось в прошлых версиях данной спецификации как комбинация существующих полей заголовка Location, Content-Location и Vary. Его первоначальной целью являлось включение списка дополнительных URI для ресурса, включая имена и положение зеркал. Однако, стало ясно, что комбинация многих различных функций в пределах одного поля мешает эффективной их реализации. Более того, мы полагаем, что идентификация имени положения зеркал лучше осуществлять через поле заголовка Link. Поле заголовка URI было признано менее удобным, чем эти поля. URI-header = "URI" ":" 1#( "<" URI ">" ) 16.7. Совместимость с предыдущими версиями HTTP/1.1 был специально спроектирован так, чтобы обеспечить совместимость с предыдущими версиями. Следует заметить, что на фазе разработки этой спецификации мы предполагали, что коммерческие HTTP/1.1 серверы будут следовать следующим правилам:
Мы также ожидаем, что клиенты HTTP/1.1:
Для большинства реализаций HTTP/1.0, каждое соединение устанавливается клиентом до посылки запроса и закрывается сервером после посылки отклика. Некоторые реализации используют версию Keep-Alive постоянного соединения, описанную в разделе 16.7.1.1. 16.7.1. Совместимость с постоянными соединениями HTTP/1.0 Некоторые клиенты и серверы могут пожелать быть совместимыми с некоторыми предшествующими реализациями HTTP/1.0 постоянных соединений клиента и сервера. Постоянные соединения в HTTP/1.0 должны согласовываться в явном виде, так как это не является вариантом по умолчанию. Экспериментальные реализации постоянных соединений в HTTP/1.0 не лишены ошибок. Проблема была в том, что некоторые существующие клиенты 1.0 могут посылать Keep-Alive прокси-серверу, которые не понимает Connection, и ошибочно переадресует его ближайшему серверу. Последний установит соединение Keep-Alive, что приведет к повисанию системы, так как прокси будет ждать close для отклика. В результате клиентам HTTP/1.0 должно быть запрещено использование Keep-Alive, когда они работают с прокси. Однако, взаимодействие с прокси является наиболее важным использованием постоянных соединений, по этой причине подобный запрет является не приемлемым. Следовательно, нам нужен какой-то другой механизм для индикации намерения установить постоянное соединение. Этот механизм должен быть безопасным даже при взаимодействии со старыми прокси, которые игнорируют Connection. Постоянные соединения для сообщений HTTP/1.1 работают по умолчанию; мы вводим новое ключевое слово (Connection: close) для декларации непостоянства соединения. Ниже описана оригинальная форма постоянных соединений для HTTP/1.0. Когда HTTP клиент соединяется с исходным сервером, он может послать лексему соединения Keep-Alive в дополнение к лексеме соединения Persist: Connection: Keep-Alive. Сервер HTTP/1.0 откликнется лексемой соединения Keep-Alive и клиент сможет установить постоянное (или Keep-Alive) соединение с HTTP/1.0. Сервер HTTP/1.1 может также установить постоянное соединение с клиентом HTTP/1.0 по получении лексемы соединения Keep-Alive. Однако, постоянное соединение с клиентом HTTP/1.0 не может быть использовано для по-фрагментного кодирования и, следовательно, должно использовать Content-Length для пометки конца каждого сообщения. Клиент не должен посылать лексему соединения Keep-Alive прокси-серверу, так как прокси-сервера HTTP/1.0 не следуют правилам HTTP/1.1 при разборе поля заголовка Connection. 16.7.1.1. Заголовок Keep-Alive Когда лексема соединения Keep-Alive передана в рамках запроса или отклика, поле заголовка Keep-Alive может также присутствовать. Поле заголовка Keep-Alive имеет следующую форму: Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param Заголовок Keep-Alive является опционным и используется, если передается параметр. HTTP/1.1 не определяет каких-либо параметров. Если посылается заголовок Keep-Alive, должна быть передана соответствующая лексема соединения. Заголовок Keep-Alive без лексемы соединения должен игнорироваться. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.6 WWW
UP:
4.5 Процедуры Интернет
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.6.2 Язык HTML
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Язык программирования HTML (Hypertext Markup Language) предназначен для создания гипертекстных документов, формат которых не зависит от ЭВМ или используемой ОС. HTML-документы являются SGML-документами (Standard Generalized Markup Language, [ISO 8879]) с семантикой, пригодной для представления информации от широкого круга доменов. Файлы HTML-документов должны иметь расширение .html или .html. Данный формат пригоден для представления почтовых сообщений, новостей, меню, опций, гипермедийных документов, результатов запросов к базам данных, графических документов и т.д. HTML используется во всемирной информационной системе World Wide Web (WWW) с 1990 года (разработчик Tim Berners-Lee). В настоящее время существует также простой диалект языка SGML - XML (Extensible Markup Language). Смотри http://win.www.citycat.ru/doc/html/xml/wd-xml-lang или www.w3.org/put/www/tr (первоисточник). Предполагается, что этот язык совместим с SGML и HTML (последнее справедливо лишь частично). Любое приложение SGML состоит из нескольких частей:
SGML - это система описания языков разметки (markup). HTML - пример такого языка. Каждый язык разметки, определенный в SGML, называется приложением SGML. HTML 4.0 является приложением SGML, соответствующим международному стандарту international standard ISO 8879:1986 -- Standard Generalized Markup Language SGML (определено в [ISO8879]). Приложение SGML характеризуется:
HTML предоставляет разработчику следующие возможности:
Символьные объекты (entity) представляют собой цифровые или символьные имена символов, которые могут быть включены в документ HTML. Эти объекты нужны в тех случаях, когда прямой их ввод по каким-либо причинам невозможен. Эти объекты начинаются с символа & и завершаются точкой с запятой (;). Элементы в SGML представляют собой структуры или описывают требуемое поведение. Элементы начинаются со стартовой метки (TAG), за которой следует содержание, и завершаются конечной меткой. Стартовая метка обычно записывается как <имя_элемента>, а конечная метка, как </имя_элемента>. Некоторые элементы могут не иметь содержания или конечной метки. "Пустые" элементы не имеют конечной метки. Имена элементов обычно записываются прописными буквами, но HTML использование прописных или строчных букв в именах элементов не регламентировано. Атрибуты. Элементы могут иметь определенные свойства, эти свойства характеризуются атрибутами, которым пользователь может присваивать некоторые значения. Пары атрибут/значение должны быть записаны до появления закрывающей угловой скобки (>) стартовой метки. Если используется несколько атрибутов/значений, они разделяются пробелами. Порядок их записи не играет роли. По умолчанию SGML требует, чтобы значения были помещены в двойные или одинарные кавычки. Для этих же целей могут использоваться символьные объекты " или " для двойной кавычки и ' для одинарной кавычки. Значения могут содержать помимо латинских букв и цифр символы (-) и (.). Имена атрибутов не чувствительны к тому, прописными или строчными буквами они напечатаны (как правило, их имена записываются в HTML строчными буквами). Агент пользователя HTML - любой прибор, который интерпретирует HTML документы. К агентам пользователей относятся визуальные броузеры (текстовые и графические), не визуальные броузеры (звуковые и Брейля), поисковые роботы и т.д.. Агент пользователя должен игнорировать любые не узнанные атрибуты. Пользователь - лицо, взаимодействующее с агентом пользователя, для того чтобы тем или иным способом ознакомиться с документом HTML. URI. Любой ресурс в WWW - HTML документ, изображение, видео-клип, программа и пр. имеют адрес, который может быть представлен в виде универсального идентификатора ресурса (URI). Комментарии в HTML имеют следующий синтаксис: <!-- Комментарий --> dtd-комментарии выделяются двумя черточками (--) в начале и в конце текста. HTML DTD начинается с серии описаний каких-то объектов (entities). Описание объекта представляет собой макрос, который может быть развернут где-либо в DTD(в HTML не применим). Когда макрос вызывается (по имени), он разворачивается в строку. Описание объекта (entity) начинается с ключевого слова <!entity %, за которым следует имя объекта и помещенная в кавычки строка, которая разворачивается. Описание завершается символом >. Развертываемая строка может содержать другие имена объектов. Конкретные значения объекта начинаются с символа "%" и завершается опционно символом ";". Эти объекты будут также развернуты (если требуется рекурсивно). Например: <!entity %fontstyle "tt | i | b | big | small"> Большая часть HTML DTD состоит из описаний элементов и их атрибутов. Ключевое слово <!element> открывает описание элемента, а символ > - завершает. Между ними размещается имя элемента, две черточки после имени указывают на то, что стартовая и конечная метки являются обязательными. Одна черточка после имени элемента и последующая буква О указывают на то, что конечная метка может отсутствовать. Две буквы О означают допустимость отсутствия как стартовой, так и конечной метки. После имени может следовать содержимое элемента, которое называется моделью содержимого. Элементы без содержимого называются пустыми (empty). Пустые элементы описываются ключевым словом "empty". Например, <!element ccc - o empty>. ccc - имя элемента; - О говорит о допустимости отсутствия конечной метки. В сочетании с моделью empty это означает, что конечная метка должна отсутствовать. Модель содержимого описывает то, что может содержать элемент. Определения содержимого могут включать:
Модель содержимого имеет следующий синтаксис.
Ниже приведены примеры HTML DTD: <!element select - - (option+)> Элемент select должен содержать один или более элементов option. <!element dl - - (dt|dd)+> Элемент dl должен содержать один или более dt или dd элементов в любом порядке. <!element option - o (#pcdata) *> Элемент option может содержать только текст и символьные объекты. Описание атрибутов начинается с ключевого слова <!attlist>. Описание атрибута включает в себя:
Рассмотрим описание элемента map с опционным атрибутом. <!attlist map name cdata #implied >, здесь тип допустимого значения задан DATA (тип данных SGML). CDATA - представляет собой текст, который может содержать символьный объекты. Описания атрибутов могут содержать объекты DTD. Например:
Объект %attrs разворачивается в:
Аналогично DTD определяет объект %URL как расширение в строку cdata. <!entity % URL "CDATA" -- термин URL означает атрибут, значение которого равно универсальному указателю ресурса URL (uniform resource locator), см. RFC-1808 и RFC-1738 --> Некоторые атрибуты выполняют роль булевых переменных. Их появление в стартовой метке элемента предполагает, что значение атрибута равно "true" (истинно). Их отсутствие означает, что их значение равно "false" (ложно). В HTML допускается сжатая форма записи булевых атрибутов: <option selected> вместо World Wide Web (WWW) представляет собой всемирную сеть информационных ресурсов. WWW базируется на трех механизмах, которые обеспечивают доступ к этим ресурсам:
Примером URI может служить адрес, где размещено описание языка HTML v4.0: http://www.w3.org/tr/rec-html4/ Этот URI можно воспринимать следующим образом: имеется документ, доступный через протокол HTTP (см. [RFC-2068]), этот документ находится на ЭВМ www.w3.org, проход к нему имеет вид /tr/rec-html4/. Замечание. Большинство читателей знакомо с термином URL (Universal Resource Locator; [RFC-1738]) URL представляет собой подмножество более общей системы имен URI. Следует помнить, что запись URL чувствительна к тому, строчные или прописные буквы используются при его написании (это не относится только к имени ЭВМ). Спецификация URL определяет положение документа в сети, но не позицию внутри документа. По этой причине введено понятие URL-фрагмента, который может указывать на определенную часть документа. URL-фрагмент завершается символом #, за которым следует идентификатор указателя (anchor). Примером такого URL-фрагмента может служить http://store.in.ru/semenov/intro.htm#intr_1, где int_1 - имя метки в тексте документа intro.htm. Для локальной адресации HTML-документов используется относительные URL, которые не имеют секций протокола и ЭВМ. Относительный URL может содержать компоненты относительного прохода к ресурсу (".." означает положение порождающего URL). Документ RFC-1808 определяет алгоритм работы с относительными URL. Относительный URL может быть частью полного URL. Полный URL можно определить следующим образом:
Для связи через электронную почту иногда используется специальная разновидность URL - mailto, которая имеет формат: mailto:e-mail_адрес. В HTML, URI используются для:
Поскольку люди на Земле пока используют различные языки, в которых применяются совершенно не схожие наборы символов, необходимо как-то управлять процессом описания набора символов, используемого в данном документе. Для документов HTML используется универсальный набор символов UCS (Universal Character Set) [ISO10646; cм. также RFC-2070]. Этот набор эквивалентен Unicode 2.0 [unicode]. Агент пользователя может получить, послать или воспроизвести документ в любой кодировке. Это может быть набор ISO-8859-1 ("latin-1"), ISO-8859-5 (кирилица), shift_jis (японская кодировка) и так далее. Пользователь должен позаботиться, чтобы его документ в конечном итоге был приведен в соответствие с Unicode, тогда у него не будет более проблем с национальным шрифтовым набором. Для того чтобы облегчить представление полученного документа, можно проанализировать первые несколько байт документа и в процессе пересылки соответствующим образом задать параметр charset поля "content-type". Например: content-type: text/html; charset= euc-jp В качестве значения параметра charset может быть выбрано стандартное имя из документа [RFC-2045]. Но, к сожалению, отнюдь не все сервера присылают информацию об используемом символьном наборе даже в случае несовпадения с ISO-8859-1. Другим способом решить проблему является включение в заголовок документа соответствующего meta-элемента. Например: <meta http-equiv="content-type" content="text/html; charset=euc-jp"> Здесь крайне важно, чтобы агент пользователя был способен правильно интерпретировать элемент meta-декларации. Если других указаний не распознано, считается, что использован набор ISO-8859-1. Значение типа атрибута "color" служит для описания цвета. Значение этого атрибута может быть шестнадцатеричным числом, перед которым записывается символ #, или одним из 16 имен цветов:
Цвета могут заметно улучшить выразительность и читаемость документов, но следует иметь в виду, что использование стилевых листов более эффективно. Нужно также учитывать, что цвета отображаются на разных рабочих станциях по-разному. HTML-документ состоит из трех частей, строки с информацией о версии, секции заголовка и собственно содержания документа. В первой строке документа должна быть внесена конструкция doctype, описывающая использованную версию HTML. Например: <!doctype html public "-//w3c//dtd html 4.0 draft//en"> Последние две буквы этой декларации характеризуют язык HTML dtd, в данном случае английский ("en"). Агент пользователя может игнорировать эту информацию. Слово draft говорит о том, что использована предварительная версия HTML 4.0. В случае работы с окончательной версией html 4.0 это слово должно быть заменено на strict. Часть документа, следующая после описания версии, должна быть оформлена в виде HTML-элемента. Таким образом, HTML-документ имеет следующую структуру: <!doctype html public -//w3c//dtd html 4.0 draft//en> Рассмотрим возможные варианты HTML-элементов. <!entity % version "version cdata #fixed '%html.version;'"> Стартовая и конечная метки являются опционными. Ниже приведены примеры элементов-заголовков. <!entity % head.content "title & isindex? & base?"> Не следует путать элемент title с атрибутом title, который предоставляет справочную информацию об элементе, для которого установлен. Атрибут title имеет формат: title=cdata. В отличие от элемента title, который характеризует весь документ в целом и может появиться в пределах документа только раз, атрибуту title позволено аннотировать любое число элементов. Агент пользователя может интерпретировать этот атрибут самым различным способом. Визуальные броузеры могут отобразить его текст в качестве совета, аудио агент может воспроизвести текст, говорящий о ресурсах подключенного сервера. Специфическую роль играет атрибут title при использовании для элемента link. В html 4.0 программист может использовать метаданные в своем документе следующим способом:
Если профайл определен для элемента Head, тот же профайл будет присутствовать во всех элементах META и LINK в заголовке документа. Ниже приведены примеры записи элементов meta.
Для META-элемента стартовая метка необходима, а конечная не нужна. Атрибуты, их значения и интерпретация зависят от профайла.
Например, <meta name="interpreter" content="yuri semenov">. Атрибут lang может использоваться с элементом meta для определения языка для значения атрибута content. Этот атрибут позволяет синтезаторам речи корректно выбрать правила произношения. Например: <meta name="interpreter" lang="ru" content="semenov">. Некоторые агенты пользователья используют meta для обновления текущей страницы каждые несколько секунд. При этом страница может обновляться полностью. Например: <meta name="refresh" content="3,http://www.acme.com/intro.html"> Слово content определяет задержку в секундах, за этим числом следует URL, который должен быть загружен по истечении указанного времени. К сожалению не все агенты пользователя поддерживают такую возможность. Атрибут HTTP-equiv может использоваться вместо атрибута name. HTTP-серверы могут работать с именами свойств, заданными атрибутом HTTP-equiv, что позволяет им формировать заголовок HTTP-отклика согласно требованиям RFC-822. Декларация <meta http-equiv="expires" content="Mon, 17 Aug 1998 16:35:08 GMT"> приведет к формированию следующей строки в HTTP-заголовке: expires: Mon, 17 Aug 1998 16:35:08 GMT. Это позволяет определить время доступности свежей копии документа. Одним из важных функция элемента meta является описание ключевых слов для поисковых систем. Например: <meta name="keywords" content="information, retrieval, indexing"> 4. Элементы, используемые в тексте документа <!entity % block "(%blocklevel | %inline)*">
<!element body o o (%block) -(body) +(ins|del)>
Для этого элемента стартовая и конечная метки являются опционными. Здесь применимы следующие атрибуты.
Помимо перечисленных ряд атрибутов могут задаваться извне: id, class, (идентификаторы действуют для всего документа) lang (языковая информация), dir (направление текста/отступ), title, style (текущая стилевая информация), bgcolor (цвет фона), onload, onunload, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (действительные события). Презентация документа определяется стилем (использование атрибутов презентации не желательно). Атрибуты презентации могут применяться только для агентов пользователя, не поддерживающих стили. Ниже представлена иллюстрация представления документа, где фон имеет белый цвет, текст черный, гиперсвязи в исходный момент красные, темные при активации и темно бордовые после первого визита. <html>
<body bgcolor="white" text="black" link="red" alink="fuschia" vlink="maroon"> . текст документа . </body> </html> То же самое с использованием стилевого листа. <html>
</head> <body>
</html> Использование связанного стилевого листа добавляет гибкости при реализации презентации. <html>
</head> <body>
</html> 5. Идентификаторы элементов. ID и атрибуты классов. Определения атрибутов ID = name Этот атрибут присваивает имя элементу, которое действительно в пределах данного документа. Значение ID должно быть уникальным для данного документа. class = cdata-list Этот атрибут присваивает некоторому элементу значение класса или набора классов. Одно и тоже имя класса может быть присвоено любому числу элементов. Значение класса позволяет определить или уточнить функцию данного элемента или группы элементов. Эти атрибуты могут использоваться в следующих случаях:
Предположим, что пишется документ о языке программирования. Документ включает в себя некоторое число отформатированных примеров. В этом случае для форматирования используется элемент pre. Пусть также задан цвет фона = green для всех случаев, когда элемент pre принадлежит классу "example". <head> <!entity % html.content "head, body">
Определение атрибута version = cdata [cn] Применять не рекомендуется. Значение атрибута специфицирует то, какая версия HTML DTD используется в данном документе. Этот атрибут не рекомендован из-за того, что в качестве стандарта принято определение версии в декларации типа документа. После декларации типа документа оставшаяся часть документа содержит элемент HTML. Таким образом, HTML-документ имеет структуру: <!doctype html public "-//w3c//dtd html 4.0//en" 5.2. Группирующие элементы div и span <!element div - - %block>
Атрибуты определенные где-то еще
Элементы div и span в сочетании с атрибутами id и class предлагают обобщенный механизм структурирования документа. Таким образом, сформировав примеры и классы и используя для них стилевые листы, программист может придать HTML-документу необходимую структуру и форму. Предположим нужно сформировать документ на основе базы данных клиента. Так как HTML не имеет элементов, идентифицирующих такие объекты как "клиент", "телефонный номер" и т.д., для решения стоящей задачи воспользуемся элементами div и span. В приведенном примере каждое имя клиента принадлежит классу client-last-name. Присвоим также уникальные идентификаторы каждому клиенту (client-stepanov, client-ivanov). <div id="client-stepanov" class="client"> <div id="client-ivanov" class="client"> Позднее может быть легко добавлена стилевая информация для тонкой настройки представления записей этой базы данных. span является строчным элементом и его зона ответственности - параграф. span не может быть использован для группирования элементов блочного уровня. div, напротив, предназначен для работы с блочными элементами. div элемент, за которым следует незакрытый p-элемент, завершает параграф. Агент пользователя помещает разрыв строки до и после div-элемента, например строка: <p>aaaaaa<div>bbbbbb</div><div>ccccc<p>ccccc</div> ccccc Агент пользователя развернет ее как:aaaaaabbbbbbccccc ccccc 5.3. Элементы заголовков h1, h2, h3, h4, h5, h6 <!entity % heading "h1, h2, h3, h4, h5, h6">
Элементы заголовка кратко описывают тему раздела, который они открывают. Содержимое заголовка может использоваться агентом пользователя, например, для автоматического формирования оглавления документа. Визуальные броузеры отображают заголовки более высокого уровня буквами более крупного кегля. Ниже приведен пример использования div-элемента для установления связи заголовка со следующей за ним секцией документа. Это позволяет определить стиль раздела с помощью стилевых листов. <div class="section" id="forest-elephants" > В этом разделе обсуждаются менее известные лесные слоны. . далее следует продолжение текста . Структура может быть улучшена с помощью стилевой информации, например: <head> <!element address - - ((%inline;) | p) *>
Элемент address служит для введения контактного адреса с автором документа, например: <address> 6. Спецификация языка содержимого документа. Атрибут lang lang = language-code Специфицирует базовый язык, на котором написан документ. Значением этого атрибута является код языка (см. RFC-1766). В пределах кода языка пробелы использоваться не должны. Значение этого кода по умолчанию "unknown". Код языка состоит из базового кода и субкода. language-code = primary-code *( "-" subcode ) Атрибуты, определенные где-либо еще.
Ниже приведено несколько примеров кодов языка. "en":english
Две первые буквы базового кода зарезервированы ISO-639.
Любые две буквы субкода воспринимаются как код страны ISO3166. 7. Наследование языковых кодов Элемент наследует информацию языкового кода согласно следующим приоритетам (сверху вниз):
В ниже приведенном примере базовый язык документа является французским. Один параграф декларирован как испанский, после чего базовый язык восстанавливается. Следующий параграф включает встроенную фразу на японском, после чего следует снова текст на французском. <html lang="fr"> 8. Спецификация направления текста. Атрибут dir Описание атрибута dir = ltr | rtl Специфицирует направление размещения текста, возможные значения: ltr: слева направо Последнее значение атрибута может быть нужно для случая арабского или еврейского текстов. Агент пользователя не может использовать атрибут lang для определения направления текста. Пробел Спецификация SGML делает различие между начальным символом (перевод строки) и концом записи (возврат каретки). Но существует большое разнообразие использования этих символов в различных системах и агент пользователя должен быть способен корректно обрабатывать все варианты. Аналогично меняется от скрипта к скрипту представление о том, что такое разделитель слов. В латинских текстах это пробел (десятичный код 32), в японском и китайском пробел игнорируется, а в тайском используется нуль-сепаратор. Что же касается самого HTML, здесь функции сепаратора выполняет код пробела. Набор символов документа включает в себя широкое разнообразие символов пробела. Многие из них являются типографскими элементами, которые служат для формирования зазоров между словами или буквами. В HTML, определены только следующие символы пробела:
Разрыв строки также является пробелом. Заметьте, что 
 и 
 определенные в [ISO10646] для разделения строк и параграфов, соответственно, не являются разрывами строк в HTML. Пример текста: <p>
</li>
</li> </ul> текст может быть переписан с пропуском конечных меток и размещен иначе с использованием меньшего числа пробелов. <p>this example shows a paragraph and a list
Элемент pre используется для уже сформатированных фрагментов текста, где важны пробелы. Элементы фраз: em, strong, dfn, code, samp, kbd,
var, cite, acronym
Элементы фраз добавляют структурную информацию к текстовым фрагментам. Элементы фраз имеют следующие значения:
EM и strong весьма привлекательны для подчеркивания важности фрагмента текста. Приведенный ниже пример позволяет проиллюстрировать использование некоторых элементов фраз. "More information can be found in <cite>[ISO-0000]</cite> Элемент acronym позволяет упростить работу программ проверки правописания и звуковых синтезаторов речи. Текст элемента acronym позволяет описать сам акроним: <acronym title="world wide web">www</acronym> Представление элементов фраз зависит от агента пользователя. Визуальные броузеры отмечают фрагменты текста EM курсивом, а фрагменты strong - полужирным шрифтом. HTML не выделяет аббревиатур и акронимов, по этой причине в текстах, ориентированных на звуковое воспроизведение, следует позаботиться о создании специальных словарей, подключенных к тексту с помощью элементов link в заголовке документа. 9.2. Цитирование. Элементы q и blockquote <!element blockquote - - %block>
Определения атрибутов cite=url Значение этого атрибута равно url, который указывает на первоисточник или сообщение. Аргумент указывает на источник цитаты, заключенной в кавычки. Элемент q служит для использования с короткими цитатами в пределах абзаца, а blockquote предназначен для более длинных. Например: <blockquote cite=http://www.mycom.com/tolkien/twotpwers.html> 9.3. Верхние и нижние индексы. Элементы sub и sup <!element (sub|sup) - - (%inline) *>
Например, французское "mlle dupont" можно представить в HTML как: m<sup>lle</sup> dupont Любой текст обычно представляется в виде последовательности параграфов. Для определения границ параграфа в HTML используется элемент p. Текст параграфа будет использоваться как единое целое при ряде процедур. <! element p - o (%inline) *>
P-элемент отмечает границы параграфа и не может содержать элементов блочного уровня, включая другие Р-элементы. Конечная метка может быть опущена, при этом любой элемент блочного уровня будет являться начальной меткой и конечной меткой Р-элемента. Например: <p>Это первый параграф.</p> Этот же текст можно переписать эквивалентным образом: <p>Это первый параграф. Аналогично параграф может быть сформирован с помощью блочных элементов: <div> Пустой параграф является дурным стилем и должен игнорироваться агентом пользователя. Агент пользователя определяет способ отображения параграфа. Параграфы могут иметь абзацы, а могут отделяться друг от друга пустой строкой. Обычно в процессе отображения строки разрываются по пробелам между словами, но можно ввести принудительные разрывы строк с помощью элемента BR.
Для визуального агента пользователя атрибут clear может использоваться для позиционирования плавающих объектов (напр. обтекание текстом изображений). Этот атрибут используется в случае отсутствия стилей. Помимо принудительного разрыва строки существует элемент, запрещающий разрыв строки между двумя словами. Например entity ( ,  ) действует как пробел, где агент пользователя не должен разрывать строку. В HTML существует два вида дефисов: мягкий и твердый. Твердый рассматривается как обычный символ, а мягкий воспринимается агентом пользователя как место, где можно разорвать строку. Твердый дефис обозначается символом "-" (-,-), а мягкий - именованным символом ­ (­,­). 9.6. Предварительно сформатированный текст. Элемент pre. <!entity % pre.exclusion "img|big|small|sub|sup|font">
Определения атрибутов width = integer Этот атрибут дает информацию агенту пользователя о желательной ширине форматируемого блока. Агент пользователя может использовать эту информацию для выбора шрифта или отступа. Желательная ширина выражается в числе символов. Элемент pre сообщает визуальному агенту пользователя, что данный фрагмент текста уже сформатирован. Агент пользователя при этом должен сохранить все пробелы, использовать шрифт с фиксированной шириной букв, блокировать автоматический перенос и разрыв строк. Перед и после такого фрагмента обычно вводятся пустые строки (требование SGML). В DTD-фрагменте, приведенном выше, в первой строке содержится список элементов, которые не должны присутствовать в PRE-декларации. Рассмотрим фрагмент из поэмы Шелли "to a skylark". <pre>
and singing still dost soar, and soaring ever singest. Этот стих будет представлен агентом пользователя без изменений формата. Не рекомендуется использовать горизонтальную табуляцию в предварительно отформатированных текстах, агент пользователя не сможет воспроизвести формат фрагмента без искажений. 10. Пометка изменений документа. Элементы ins и del.
Определение атрибутов cite = URL Значение этого атрибута равно URL, которое указывает на документ-первоисточник. Атрибут служит для пояснения причины изменения документа. datetime = cdata Значение этого атрибута определяет дату и время внесения изменения в документ. Формат этого значения должен соответствовать требованиям документа ISO-8601. Элементы ins и del используются для выделения фрагментов документа, которые были добавлены или удалены из предшествующей версии документа. ISO-8601 допускает много опций и вариаций в представлении дат и времени. Но основным форматом HTML следует считать следующий: yyyy-mm-ddthh:mm:sstzd
В качестве tzd (код временной зоны) можно использовать следующие:
Символ t указывает на начало строки символов времени. 12. Неупорядоченные (ul) и упорядоченные (ol) списки <!entity % ulstyle "disc|square|circle">
Определение атрибутов type = style-information Этот атрибут определяет стиль элемента списка. start = integer Работает только для ol. Устанавливает начальное значение счетчика элементов упорядоченного списка, значение по умолчанию равно единице. value = integer Работает только для LI. Устанавливает текущее значение номера элемента списка. compact Не рекомендуется использовать. При использовании требует от агента пользователя отображать список в возможно более компактном виде. Упорядоченные и не упорядоченные списки во многом схожи. Оба типа представляют собой последовательность элементов, описанных элементом LI (конечная метка этого элемента обычно опускается). Ниже приведены примеры списков. <ul>
Списки могут быть вложенными. <ul>
В упорядоченных списках невозможно продолжать нумерацию с предыдущего списка или убрать нумерацию, но можно установить счетчик принудительно с помощью атрибута value. Например: <ol> 12.1. Списки, форматируемые визуальным агентом пользователя Для OL и UL атрибут type определяет опцию отображения визуальным агентом пользователя. Для элемента UL возможны значения атрибута type: disc, square и circle. Значение по умолчанию зависит от уровня вложения текущего списка. Агент пользователя попытается представить "disc" в виде небольшого заполненного кружочка, "circle" - в виде незаполненного кружочка, а "square" - в виде квадратика. Для элемента ol возможные значения атрибута type представлены в таблице.
12.2. Списки определений. Элементы dl, dt и dd <!element dl - - (dt|dd)+>
<!element dd - o %block>
Список определений отличается слабо от других списков, он состоит из двух частей: начальная этикетка (label) и описание. Этикетка инициируется элементом DT и может содержать только помеченный текст. Описание начинается с элемента DD и может содержать данные блочного уровня. Например: <dl>
Представление списка определений зависит от агента пользователя. Агент пользователя может отобразить представленный список в виде: daniel <!element (dir|menu) - - (li)+ - (%blocklevel)>
Элемент DIR предназначен для формирования многоколоночного текста каталога. Элемент Menu предназначен для работы с одноколонными текстами каталогов. Оба элемента имеют структуру, аналогичную UL. Рекомендуется использовать UL вместо DIR и Menu. Модель таблиц в HTML позволяет пользователям создавать достаточно сложные структуры таблиц. В этой модели ряды и колонки можно объединять в группы. При печати больших таблиц заголовки и нижние комментарии могут дублироваться для каждой части. В HTML таблицы имеют следующую структуру
<!element table - - (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
Определение атрибутов align = left | center | right Этот атрибут определяет положение таблицы в документе. Возможные значения:
width = length Этот атрибут определяет желательную ширину всей таблицы для агента пользователя. В отсутствии этого атрибута размер таблицы определяется агентом пользователя. cols = integer Этот атрибут задает число колонок в таблице. Если он задан, агент пользователя разворачивает таблицу по мере получения данных. 14.2. Вычисление числа рядов и колонок в таблице Число рядов в таблице равно числу tr-элементов в ее содержимом. Агенты пользователя должны игнорировать ряды с номерами за пределами этого числа. Существует несколько путей определения числа колонок.
Агент пользователя может предположить, что число колонок в примере, приведенном ниже равно трем. <table cols= "3"> Если число колонок в таблице не задано атрибутом COLS, то визуальный агент пользователя будет ждать прихода всей информации о таблице, прежде чем приступит к ее отображению. Таким образом, атрибут cols позволяет отображать таблицу ряд за рядом по мере поступления данных. Ориентация таблиц определяется атрибутом dir элемента table. Для таблиц, ориентированных слева направо (ориентация по умолчанию), первая колонка расположена слева, а первый ряд сверху. Возможна ориентация таблицы справа налево. Для того чтобы специфицировать таблицу с нумерацией колонок справа налево нужно установить значение атрибута dir. <table dir="rtl"> 14.4. Надписи и таблица. Элемент caption <!element caption - - (%inline;) +>
Определение атрибута align = top|bottom|left|right Этот атрибут определяет положение подписи по отношению к таблице. Возможные значения:
Надпись, если она присутствует, должна описывать природу таблицы. Элемент caption должен располагаться непосредственно после начальной метки table. Например: <table cols="3"> 14.5. Группы рядов. Элементы thead, tfoot и tbody <!element thead - o (tr+)>
Таблица должна содержать хотя бы одну группу рядов. Каждая группа рядов делится на три секции: заголовок, собственно таблица и подпись под таблицей. Заголовок и подпись являются опционными. Элемент thead определяет заголовок, tfoot - подпись под таблицей, а элемент tbody - тело таблицы. thead, tfoot и tbody, если они присутствуют, должны содержать один или более рядов. Ниже приведен пример использования элементов thead, tfoot и tbody. <table>
<tfoot>
<tbody>
<tbody>
</table> tfoot в рамках определения table должен появляться до tbody, так чтобы агент пользователя мог осуществлять разбор подписи до получения всех данных таблицы. 14.6. Опционные метки групп рядов Когда таблица содержит только одно тело и не имеет заголовка и нижней подписи, начальная и конечная метки tbody могут быть опущены. Когда блок таблицы содержит заголовок, начальная и конечная метки элемента thead являются необходимыми. Конечная метка может быть опущена, когда далее следует стартовая метка tfoot или tbody. когда блок таблицы содержит нижняя подпись, необходима начальная метка элемента tfoot. Конечная метка может быть опущена, когда далее следуют начальная метка thead или tbody. 14.7. Группы колонок. Элементы colgroup и col <!element colgroup - o (col*) >
Определения атрибутов span = integer Атрибут в случае своего присутствия определяет число колонок в группе по умолчанию. Агент пользователя должен игнорировать этот атрибут, если текущая группа содержит один или более элементов col. Значение атрибута по умолчанию равно единице. width = length Атрибут определяет значение ширины колонки по умолчанию для текущей группы колонок. Кроме того, для стандартных значений пикселя и процента этот атрибут может иметь специальную форму "0*", которая означает, что ширина каждой колонки в группе должна иметь минимальную ширину для размещения имеющегося текста. Таблица должна иметь как минимум одну группу колонок. В отсутствии определения группы считается, что таблица имеет одну группу колонок, включающую в себя все колонки таблицы. Атрибут width элемента colgroup определяет ширину по умолчанию каждой из колонок в группе. Формат "0*", требующий минимальной ширины, может быть отменен элементом col. Таблица в приведенном ниже примере имеет две группы колонок. Первая группа содержит 10 колонок, а вторая - 5 колонок. Значение ширины колонки по умолчанию для каждой из колонок в первой группе равно 50 пикселей. Для второй группы ширина колонки определяется минимально возможным значением. <table> <!element col - o empty>
Определение атрибута width = length Этот атрибут задает значение по умолчанию для ширины колонок в группе. Атрибут может также принимать значение "0*" (смотри выше) и "i*", где i - целое. Это называется относительной шириной. Когда агент пользователя выделяет место для таблицы, он сначала определяет габариты, а уже затем делит выделенное пространство, определяя относительные ширины рядов и колонок. Число i при этом определяет относительную долю, выделяемую данной колонке. Значение "*" эквивалентно "1*". Каждая группа колонок может содержать нуль или более элементов col. Элемент col не определяет группу колонок в том смысле, как это делает colgroup, он предоставляет способ задать значения атрибутов для всех колонок группы. Атрибут span элемента col имеет следующее значение. В отсутствии декларации span каждый элемент col представляет одну колонку. Если атрибут span имеет значение n>0, текущий элемент col действует на n колонок таблицы. Если атрибут span равен нулю, текущий элемент col имеет воздействие на все оставшиеся колонки таблицы, начиная с текущей. Что же касается colgroup, атрибут width для col воздействует на ширины колонок, к которым относится этот элемент. Если элемент cal действует на несколько колонок, тогда его атрибут width специфицирует ширину каждой колонки в его зоне ответственности. Ниже приведен пример таблицы, имеющей две группы колонок. Первая группа содержит три колонки, вторая - две колонки. Доступное место по горизонтали определяется следующим образом. Сначала агент пользователя выделяет 30 пикселей для первой колонки. Затем будет выделено минимально возможное место для второй колонки. Оставшееся место по горизонтали будет поделено на 6 равных частей. Колонка 3 получит 2 такие порции, колонка 4 - одну, а колонка 5 получит 3. <table>
<tr> ... </table> Мы установили значение атрибута align во второй группе колонок равным "center". Все ячейки в каждой колонке этой группы наследуют это значение. Но оно может быть изменено. В действительности последний элемент col делает это, специфицируя то, что все колонки, которыми он управляет, будут выровнены по символу ":". 14.9. Ряды таблицы. Элемент tr <!element tr - o (th|td)+>
Элементы TR действуют как контейнеры рядов ячеек таблицы. Ниже приведен пример таблицы, которая имеет три ряда, каждый из которых открывается элементом TR. <table> 14.10. Ячейки таблицы. Элементы th и td <!element (th|td) - o %block>
Определения атрибутов axis = cdata Атрибут определяет сокращенное имя заголовка ячейки. Имя ячейки по умолчанию - ее содержимое. axes = cdata-list Значение этого атрибута представляет собой список имен axis, разделенных запятыми. Эти имена представляют собой заголовки рядов и колонок, принадлежащих данной ячейке. В отсутствии этого атрибута агент пользователя идентифицирует эти имена сам. rowspan = integer Этот атрибут специфицирует число рядов в текущей ячейке. Значение этого атрибута по умолчанию равно 1. Значение нуль означает, что ячейка включает в себя все ряды, начиная с текущего, до конца таблицы. colspan = integer Этот атрибут специфицирует число колонок в текущей ячейке. Значение этого атрибута по умолчанию равно 1. Значение нуль означает, что ячейка включает в себя все колонки, начиная с текущей, до конца таблицы. nowrap Использование не рекомендуется. В случае присутствия этот булев атрибут указывает агенту пользователя заблокировать автоматический разрыв слов при выкладке их в ячейку. Вместо этого атрибута рекомендуется использовать стилевой лист. Элемент TH запоминает заголовок, в то время как TD - данные. Это позволяет агенту пользователя обрабатывать заголовки и данные по-разному даже в отсутствии стилевого листа. Ячейки могут быть пустыми (не содержать данных). Ниже приведен пример таблицы с четырьмя колонками, имеющими заголовки. <table> Агент пользователя представит верхнюю часть данной таблицы в виде: Cups of coffee consumed by each senator
Для того чтобы сделать таблицу более выразительной, можно ввести атрибут border в элемент table. <table border="border"> Тогда агент пользователя отобразит начало данной таблицы следующим образом: Cups of coffee consumed by each senator
Ячейки с этикетками Атрибуты axis и exes предоставляют возможность снабжать ячейки таблицы этикетками (labels). Синтезаторы речи могут использовать эти этикетки для идентификации содержимого и положения каждой ячейки. Программное обеспечение может рассматривать эти этикетки как имена полей базы данных при занесении содержимого таблицы в банк данных. Ниже представлен пример таблицы, где значение атрибута axis представляет собой фамилию сенатора. <table border="border"> 14.11. Ячейки, которые занимают несколько рядов или колонок Ячейки могут охватывать несколько рядов или колонок. Число рядов или колонок в ячейке определяется атрибутами rowspan и colspan для соответственно TH или TD-элементов. В таблице, которая была описана, ячейка в ряду 4 вторая колонка должна занимать три колонки, включая текущий ряд. <table border="border"> Эта таблица будет развернута визуальным агентом пользователя как: Caps of coffee consumed by each senator
Этот пример иллюстрирует как описания ячеек, которые распространяются более чем на один ряд или колонку, влияет на определение последующих ячеек. Рассмотрим следующее описание таблицы. <table border="border"> Таблица может быть представлена в виде:
Версия HTML 4.0 включает в себя механизмы контроля горизонтального и вертикального выравнивания, стилями границ таблицы и полями ячеек. 14.12. Горизонтальное и вертикальное выравнивание <!entity % cellhalign "align (left|center|right|justify|char) #implied Определения атрибутов align = left|center|right|justify|char Этот атрибут определяет способ выравнивания текста в ячейке. Возможны следующие значения:
valign = top|middle|bottom|baseline Этот атрибут определяет вертикальное позиционирование текста в ячейке таблицы. Возможны следующие значения:
Этот атрибут определяет символ в тексте, который будет выполнять роль оси для выравнивания. Значением по умолчанию является точка для английского языка и запятая - для французского (бывает полезно для колонок цифр с долями целого). charoff = length Если этот атрибут присутствует, он определяет смещение текста относительно символа выравнивания (рассматривается первый такой символ). Если в строке такого символа нет, то она должна быть сдвинута горизонтально в конец относительно позиции выравнивания. Рассмотрим пример таблицы с выравниванием по символу точка. <table border="border"> Отформатированная таблица будет выглядеть как:
Следующие атрибуты влияют на рамки таблицы и внутренние линии. frame = void|above|below|hsides|lhs|rhs|vsides|box|border Эти атрибуты определяют, какая из сторон рамки, окружающей таблицу, будет видимой.
rules = none|groups|rows|cols|all Этот атрибут определяет, какие линии появится между ячейками в пределах таблицы. Возможные значения:
border = cdata Эти атрибуты определяют ширину рамки вокруг таблицы в пикселях. В приведенном ниже примере таблица имеет рамку в 5 пикселей и присутствует с правой и левой сторон таблицы. Разделительные линии имеются между всеми колонками. <table border="5" frame=vsides" rules="cols"> Следующие установки должны выполняться агентом пользователя для совместимости. Установка border="0" подразумевает frame="void" и, если не специфицировано иного, rules="none". Другие установки border подразумевают frame="border" и, если не оговорено иное, rules="all". Значение "border" в стартовой метке элемента table должно интерпретироваться как значение атрибута frame. Это предполагает, что rules="all" и ненулевое значение атрибута border. Так, например: <frame border="2"> у <frame border="2" frame="border"
rules="all"> 14.14 Поля ячейки Два атрибута регулируют зазор между и внутри ячеек. cellspacing = length Этот атрибут определяет то, какое расстояние должно быть оставлено между рамкой таблицы и начальным или конечным краем ячейки для каждого ряда или колонки, а также между ячейками в таблице. cellpadding = length Этот атрибут определяет расстояние между границей ячейки и его содержимым. Во всех последующих таблицах атрибут cellspacing определяет, что ячейки разделяются друг от друга и от рамки таблицы расстоянием в 20 пикселей. Атрибут cellpadding определяет, что верхняя и нижняя граница ячейки отстоит от его содержимого на 10% доступного пространства по вертикали (всего 20%). Аналогично поля ячейки в горизонтальном направлении составляют 10% от горизонтального размера ячейки. <table><tr cellpadding="20"> <tr>data1 <td cellpadding="20%">data2 <td>data3 </table> Ниже приведены примеры, где проиллюстрировано взаимодействие различных элементов. Пример 1. <table border="border">
Таблица может быть отображена следующим образом. A test table with merged cells
Пример 2 иллюстрирует группировку рядов и колонок. Пример взят из "developing international software", by nadine kano. Code-page support in Microsoft Window
15. Информация о пути. Элемент base <!element base - o empty> Описание атрибута href = url Этот атрибут задает абсолютный url, который используется как базовый при определении относительных url. В HTML проходы всегда задаются с помощью URL. Относительные URL получаются на основе базового URL, который может быть получен различными путями. Элемент base позволяет описать базовый URL явно. Например: <html> Относительный URL "../gee/foo/html" будет в этом случае получен в виде: http://www.barre.fr/gee/foo.html HTML-связь представляет собой соединение одного WWW-ресурса с другим. Определение связей и якорей В HTML любая связь имеет два конца и направление. Связь начинается в источнике и завершается в месте назначения. Любое описание связи определяет оба эти конца. Один конец задается местом описания связи, другой - атрибутом этой связи. Связь соответствует какому-то WWW-ресурсу (HTML-документу, изображению, видео-клипу, текущему документу, звуковому файлу и т.д.). Конец связи может быть также задан якорем. Якорь - это именованный указатель на определенную часть документа. Связь устанавливает соответствие между источником и местом назначения. Но помимо этого связь может определять тип информации. Связи могут носить самый разный характер, например, указания "next" или "previous" также задают определенные связи. Связи могут использоваться пользователем и для определения порядка печати документов. Атрибут rel определяет, что связь имеет начало в текущем документе. Атрибут rev указывает, что описанная связь имеет в качестве места назначения текущий документ. В HTML имеется два элемента, определяющие связь, это link и a. Link может появиться в секции head HTML-документа. Этот элемент определяет взаимоотношение между зоной текущего документа и другим ресурсом. Элемент A может появиться в теле документа, он устанавливает связь между зоной текущего документа и другим ресурсом. Элемент a в отличие от link может иметь содержимое (текст, изображения и т.д.). Другим важным отличием этих двух элементов является то, что А интерпретируется агентом пользователя как указание "извлечь ресурс, находящийся на другом конце связи". Извлеченный ресурс может обрабатываться агентом пользователя разными способами: Открыть новый документ в том же окне, открыть документ в другом окне, запустить новую программу и т.д. Атрибут title может быть установлен в элементах для выдачи дополнительной информации о природе связи. 15.2. Элементы, определяющие якоря Существует два способа специфицировать якоря в HTML-документах.
Так как документы могут быть написаны на разных языках, link и a поддерживают атрибуты lang, dir и charset. <!element a - - (%inline)* -(a)>
Описания атрибутов name = cdata Этот атрибут указывает на то, что элемент использован для описания якоря. Значение этого атрибута является уникальным именем якоря. Это имя действительно в пределах данного документа. Атрибут name работает в том же пространстве имен, что и атрибут ID. href = url Этот атрибут указывает на то, что элемент использован для описания связи. Значение атрибута равно положению одного из концов связи (другой конец задан положением этого элемента). rel = cdata Этот атрибут указывает на то, что источником связи является текущая позиция в документе. Значение Href в этом случае определяет место назначения связи. Значение rel специфицирует тип связи. Этот атрибут может включать в себя список типов связей, разделенных пробелами. rev = cdata Этот атрибут указывает на то, что место назначения связи соответствует текущей позиции в документе. Значение Href в этом случае определяет положение источника. Значение rev специфицирует тип связи. Этот атрибут может включать в себя список типов связей, разделенных пробелами. charset = cdata Этот атрибут специфицирует перекодировку символов для данной связи. Значение этого атрибута должно быть именем "charset" описанным в RFC-2045. Значение по умолчанию этого атрибута равно "ISO-8859-1". Ниже приведен пример использования А-элемента. <a href=http://www.3w.org/>w3c web site</a> Эта ссылка указывает на базовую страницу консорциума WWW. Когда пользователь активирует эту связь, агент пользователя обратится к указанному ресурсу и откроет HTML-документ. Агент пользователя представляет ссылки в документе так, чтобы выделить их из текста (например, подчеркивает их). Чтобы сообщить агенту пользователя в явном виде, какой набор символов следует использовать при отображении, следует установить соответствующее значение атрибута charset. <a href =http://www.w3.org/ charset="ISO-8859-1">w3c web site</a> Ниже приведен пример, иллюстрирующий описание якоря с именем "anchor-one" в файле "one.html". . текст до якоря . <a name="anchor-oner">this is the location of anchor one.</a> Это определение присваивает якорь зоне документа, содержащей текст "This is the location of anchor one". Определив якорь, мы можем установить с ним связь из того же или постороннего документа. URL, который указывает на якорь, завершаются символом #, за которым следует имя якоря. Ниже приведены примеры такого URL.
Таким образом, связь, определенная в файле "two.html", который находится в том же каталоге, что и "one.html" имеет ссылку на якорь в виде: <a href="./one.html#anchor-one" anchor one</a> Элемент А в следующем примере определяет якорь и связь в одно и то же время. <a name="anchor-two"
href="html://wwwsomecompany.com/people/ian/vocation/family.png"> Этот пример содержит связь с www-ресурсом другого типа (png-изображение). Активация связи должна извлечь это изображение из сети и отобразить его. Автор может сформировать связи, которые не ведут к какому-либо документу, а реализуют отправку e-mail сообщения по некоторому адресу. Когда такая связь активизируется, агент пользователя вызывает почтовую программу. Для реализации таких связей введено значение mailto атрибута Href. <a href="mailto:semenov@ns.itep.ru"> yury semenov</a> Когда пользователь активизирует эту связь, агент пользователя открывает почтовую программу и заносит в поле "to:" значение "semenov@ns.itep.ru". Связи и якоря, описанные элементом А не допускают вложения. Например, ниже приведенная запись недопустима. <a name="outer-anchor" href="next-outer.html"> an outer anchor and link <a name="inner-anchor" href="next-inner.html">an inner anchor and link.</a></a> Атрибут id может использоваться для размещения якоря в области начальной метки любого элемента. Ниже приведен пример использования id для размещения якоря в элементе Н2. Якорь подвязан здесь посредством А-элемента. <h2 id="section2">section two</h2> Атрибуты ID и name работают в общем пространстве имен (см. ISO10646). Это означает, что они не могут описать якоря с идентичными именами в пределах одного документа. <!element link - o empty>
Этот элемент, который должен использоваться в Head-секции документа (любое число раз), определяет связь, независящую от среды. Хотя Link не имеет содержимого, он предоставляет информацию, обрабатываемую агентами пользователя. Ниже в предлагаемом примере показано как в секции head документа могут появиться несколько определений Link. Атрибуты rel и rev определяют, откуда связь начинается и где кончается. <html> Атрибуты rel и rev определяют начало и конец связи, но их значение или значения задают также природу связи. Если для элемента А атрибуты rel и rev не являются обязательными для link, хотя бы один из них присутствовать должен. Агент пользователя может интерпретировать эти атрибуты множеством путей, например, через меню или "клавишу next". Ниже перечислены некоторые типы связей.
15.9. Связи с поисковыми системами Элемент Link может использоваться для решения задач поиска документов по ключевым словам и другим признакам, например, язык или представления документа в виде, допускающем печать. Ниже приведен пример, где сообщается поисковой системе о месте нахождения печатной копии руководства. <head>
А в этом примере мы заставляем поисковую систему найти первую страницу собрания документов. <head>
16. Элемент object <!entity % oalign
"(texttop|middltextmiddle|baseline|textbottom|left|center|right)">
Определения атрибутов codebase = url Этот атрибут специфицирует базовый проход для определения относительного URL, описанного classid. Если атрибут не задан, значением по умолчанию является базовый URL данного документа. classid = URL Этот атрибут специфицирует положение механизма отображения через url. codetype = cdata Этот атрибут специфицирует internet media type данных, ожидаемых механизмом отображения, определенным classid. Атрибут является опционным, но рекомендуемым, когда имеется classid, так как это позволяет агенту пользователя избежать загрузки информации для неподдерживаемого типа среды. Если явно величина не задана, его значение по умолчанию соответствует значению атрибута type. data = URL Этот атрибут специфицирует положение данных, которые должны быть отображены. type = cdata Этот атрибут специфицирует Internet media type для данных, заданных атрибутом data. Атрибут является опционным, но рекомендуемым, когда задан атрибут data, так как это позволяет агенту пользователя избежать загрузки информации с типом, неподдерживаемым средой. declare Если присутствует, этот булев атрибут делает текущее определение object лишь декларацией. standby = cdata Этот атрибут специфицирует сообщение, которое агент пользователя может отобразить при загрузке объектных приложений и данных. align = texttop|middle|textmiddle|baseline|textbottom|left|center|right Не рекомендуется к использованию. Этот атрибут специфицирует положение объекта по отношению к окружающему контексту. Большинство агентов пользователей снабжены механизмом для отображения базовых типов информации, таких как текст, картинки в GIF-формате, цвета, шрифты и т.д. В HTML элемент object определяет положение механизма отображения и положение данных, необходимых для механизма отображения. Агент пользователя интерпретирует элемент object согласно следующим правилам. Агент пользователя должен сначала попробовать механизм отображения, заданный атрибутом элемента. Если агент пользователя не может поддержать этот механизм по какой-либо причине, он должен попытаться работать с содержимым элемента. Важным следствием конструкции элемента object является то, что он предлагает механизм для описания альтернативного механизма отображения различных объектов. Каждая декларация object может предлагать альтернативный механизм отображения. Если агент пользователя не может воспользоваться имеющимся механизмом, он может обратиться к тексту, который может представлять собой другой элемент object. В ниже приведенном примере использовано несколько деклараций object для иллюстрации альтернативных способов отображения. Агент пользователя сначала попробует отобразить первый элемент object, а далее будет пытаться воспользоваться: аплетом eath, написанным на языке python, mpeg анимацией, изображением земли в формате GIF и, наконец, альтернативным текстом. <object title="the earth as seen from space"
Самая внешняя декларация специфицирует аплет, который не требует данных или начальных параметров. Вторая декларация специфицирует MPEG-анимацию и не определяет механизм отображения, предполагая, что с этой работой справится агент пользователя. Здесь установлен атрибут type, таким образом, что в случае если агент пользователя не может отобразить MPEG, он может не копировать "theearth.mpeg" из сети. Третья декларация специфицирует позицию GIF-файла и предлагает альтернативный текст на случай, когда другие механизмы не приведут к успеху. Отображаемая информация может извлекаться двумя путями: из текущей строки илиb из внешнего источника. Первый способ дает большее быстродействие, но требует много места. 16.1. Инициализация объекта. Элемент param.
Определения атрибутов name = cdata
value = cdata Этот атрибут специфицирует значение параметра исполнения, заданного атрибутом name. Значение этого параметра не имеет какого-либо смысла для HTML, он определяется рассматриваемым объектом. valuetype=data|ref|object Этот атрибут специфицирует тип значения, определенного атрибутом value. Возможны значения:
type = cdata Этот атрибут специфицирует internet media type ресурса, определенного атрибутом value, только в случае, когда атрибут valuetype = "ref". Этот атрибут, таким образом, специфицирует для агента пользователя тип значений, которые будут обнаружены в URL, определенном атрибутом value. Элемент param специфицирует набор значений, которые могут требоваться механизму отображения. В начале декларации object может появиться любое число элементов param. Синтаксис имен и значений предполагается понятным механизму отображения. Имена и значения передаются механизму отображения, как стандартный ввод. Рассмотрим пример. Здесь предполагается, что механизм отображения может воспринять два параметра, которые определяют начальную высоту и ширину (часов). Задаем эти начальные параметры равными 40х40 пикселей. <object classid="http://www.miamachina.it/ahalogclock.py"> Этот агент пользователя не может исполнять приложения, написанные на языке python. </object> Так как значение по умолчанию valurtype для элемента param равно "data", мы можем заменить вышеприведенную декларацию следующей: <param name="height" value="40"> или <param name="height" value="40" data> В следующем исходные данные исполнения для параметра механизма отображения "init_values" заданы как внешний ресурс (GIF-файл). Значение атрибута valuetype установлено равным "ref", а атрибут value равен URL. <object classid="html://www.gifstuff.com/gifappli"
standby="loading elvis."> Здесь установлен также атрибут standby так, что агент пользователя может отобразить сообщение в процессе загрузки механизма отображения. Механизмы отображения локализуются с помощью URL. Первая секция абсолютного URL характеризует протокол, используемый для передачи данных, которые указаны в URL. Для HTML-документов протокол обозначается как HTTP. Но возможны и другие варианты, например, в случае использования механизма отображения java вы можете использовать URL, начинающиеся со слова Java, а для аплетов activex - "clsid". В предлагаемом примере в HTML-документ введен Java-аплет. <object classid="java:program.start"> Некоторые схемы отображения требуют дополнительной информации для идентификации их применения и должны сообщить, где можно найти эту информацию. Проход к этой информации для механизма отображения может быть указан с помощью атрибута codebase. <object codetype="application/octet-strim" classid="java:program.start"> В следующем примере с помощью атрибута classid через URL, который начинается с протокольной информации "clsid", специфицирован механизм activex. <object classid="clsid:663c8fef-1ef9-11cf-a3db-080036f12502" Для декларирования механизма отображения так, чтобы он не запускался в процессе прочтения агентом пользователя, нужно в элементе object установить булеву переменную declare. В то же время вы должны идентифицировать декларацию с помощью атрибута id в элементе object. В предлагаемом ниже примере декларируется object, который активируется через внешнюю связь. Таким образом, объект можно активировать с помощью мышки, выбрав соответствующий фрагмент текста.
.далее в документе . click to see a neat <a href="#earth_declaration"> animation of the earth! </a> Последующий пример иллюстрирует то, как можно специфицировать значения исполнительных параметров, которые являются объектами. В этом примере мы посылаем текст гипотетическому механизму его отображения. Механизм отображения распознает параметр, названный "font". Значение этого параметра само является объектом, который управляет использованием определенного шрифта. Взаимоотношение этого объекта и механизма отображения устанавливается путем присвоения id "tribune" декларации объекта шрифта и обращением к нему из элемента param.
. здесь отображается текст из файла kublakhan.txt . <object classid=http://foo.bar.com/poem_viewer
<p>you're missing a really cool poem viewer . </object> Агент пользователя, который не поддерживает атрибут declare, должен пытаться отображать содержимое декларации object. Выравнивание объектов Атрибут align для данного элемента применять не рекомендуется, предпочтительнее использование стилевых листов.
Определение атрибутов src = URL Этот атрибут специфицирует положение (указатель на) ресурса, содержащего изображение. Общепринятые форматы: GIF, JPG, PNG. align = bottomiddle|top|left|right Применение не рекомендуется. Атрибуты определяют положение изображения по отношению к окружающему тексту. Элемент IMG вводит изображение в текущий документ в точке его описания. Но тем не менее, рекомендуется вводить рисунок в текст с помощью элемента object. Рассмотрим, как семейное фото может быть включено в документ. <img src="html://www.somecompany.com/people/ian/vocation/family.png"
Это же может быть сделано с помощью object следующим образом. <object data=http://www.somecompany.com/people/ian/vocation/family.png
</object> Атрибут alt специфицирует текст, который будет выведен в случае, когда изображение не может быть отображено по какой-либо причине. 18. Введение аплетов. Элемент applet <!element applet - - (param | %inline) *>
Описания атрибутов codebase = URL Этот атрибут специфицирует базовый URL для аплета. Если этот атрибут отсутствует, в качестве базового URL рассматривается текущий документ. code = cdata Этот атрибут специфицирует имя ресурса, который содержит откомпилированный субкласс аплета. Значение атрибута должно представлять собой относительный URL по отношению к базовому URL. name = cdata Этот атрибут специфицирует имя аплета, которое позволяет аплетам найти друг друга в пределах страницы. width = length Этот атрибут специфицирует исходную ширину для области отображения аплета (без учета размера окна или области диалоговых обменов, которые вызывают аплет). height = length Этот атрибут специфицирует исходную высоту для области отображения аплета. align = top|middle|bottom|left|right Этот атрибут специфицирует положение объекта по отношению к окружающему тексту. archive = cdata Этот атрибут специфицирует имена одного или нескольких архивов, разделенные запятыми, содержащие классы и другие ресурсы, которые будут предварительно загружены. Классы загружаются с помощью вызова appletclassloader с данным codebase. Предзагрузка ресурсов может значительно улучшить работу аплета. object = cdata Этот атрибут присваивает имя ресурсу, который содержит последовательное представление аплета. Аплет приводится к стандартному виду. Используется метод start(). Этот элемент, поддерживаемый всеми java-броузерами, позволяет разработчикам встраивать Java-аплеты в HTML-документы. Содержимое аплетов используется агентом пользователя как альтернатива, если он не поддерживает данный элемент. При прочих условиях его содержимое должно игнорироваться. Ниже приведен пример Java-аплета. <applet code="bubbles.class" width="500"
height="500"> Эту запись можно переписать в другой форме. <object codetype="application/octet-stream"
java-аплет, который рисует движущиеся пузыри. Исходные данные можно передать аплету через элемент param <applet code="audioitem" width="15" height="15"> Вариант, базирующийся на object, представлен ниже. <object codetype="application/octet-stream" 19. Введение HTML-документа в другой HTML-документ Иногда возникает необходимость не связи с другим HTML-документом, а полного его включения в текст. Для решения такой задачи рекомендуется использовать элемент object с атрибутом data. Ниже следующая строка включит содержимое file_to_include.html в позицию документа, где размещен элемент object. <object data="file_to_include.html"> Содержание object отображается только в случае, когда атрибут data не может быть загружен. При использовании операций включения следует проявлять осторожность, так как файл может содержать элементы, которые вызовут непредсказуемые действия. Для введения определенного текста в документ можно также использовать элемент Iframe. 20. Введение карты изображения в html-документ Использование карты изображения позволяет разработчику специфицировать активные зоны изображения и поставить им в соответствие определенные операции. Карта изображения создается путем установления связи между объектом и определенными областями изображения. Существует два типа карт изображения:
Предпочтительной считается карта изображения клиента. Предусматривается возможность использования карты изображения несколькими элементами. 20.1. Карты изображения клиента Ниже описаны атрибуты элементов A и AREA, которые позволяют разработчику специфицировать ряд геометрических областей и ассоциировать их с определенными URL. Описания атрибутов shape = default|rect|circle|poly Этот атрибут специфицирует форму области. Возможные значения:
coords = length-list Этот атрибут специфицирует положение и форму области на экране. Число и порядок значений зависит от определенной формы. Возможны комбинации:
Начало координат размещено в верхнем левом углу объекта. Значения координат выражаются в пикселях или в процентах. Для элемента object описан также булев атрибут shapes, который определяет то, что объект является картой изображения. Ниже представлен пример с картой изображения клиента. <object data=:navbar.gif" shapes> Если элемент object содержит атрибут shapes, агент пользователя должен анализировать содержимое элемента с целью поиска якорей. Если две или более областей перекрываются, область, определенная первой, имеет приоритет. 20.2. Карты изображения клиента с map и area Элементы map и area предоставляют альтернативный механизм для карт изображения клиента. <!element map - - (area)*>
<!attrlist area
Определение атрибута
Несколько элементов (object, img и input) имеют атрибут usemap = URL для спецификации карты изображения клиента описанной элементами map и area. Рассмотрим пример, представленный выше, переписанный в терминах MAP и AREA. <object data=:navbar1.gif" usemap="#map></object>
Атрибут alt специфицирует альтернативный текст на случай, когда карта изображения не может быть отображена. map не совместима с версией HTML 2.0. Карты изображения сервера Карты изображения сервера могут представлять интерес в случае, когда карта изображения слишком сложна для стороны клиента. Такая карта может быть создана с помощью элемента img. Для того чтобы сделать это, нужно установить булев атрибут ismap в описании элемента IMG. Соответствующие области должны быть описаны с помощью атрибута usemap. Когда пользователь активирует область карты изображения, соответствующие координаты посылаются непосредственно серверу, где помещен документ. Координаты на экране выражаются в пикселях. Агент пользователя берет новый URL из URL, описанного атрибутом HREF, присоединив к нему символ "?", за которым следуют координаты х и у, разделенные запятой. Например, в предыдущем примере, если пользователь кликнет в области x=10, y=27, то будет получен URL=/cgibin/navbar.map?10,27. В следующем примере первая активная область определяет связь со стороны клиента. Вторая - определяет связь со стороны сервера, но не определяет ее форму и размер (это осуществляется значением по умолчанию атрибута shape). Так как области этих связей перекрываются, первая имеет более высокий приоритет. Таким образом, кликнув мышкой где-либо в прямоугольной области, мы пошлем соответствующие координаты серверу. <object data="game.gif" shapes>
21. Визуальное представление изображений, объектов и аплетов Применение атрибутов элементов img и object для целей управления отображением не рекомендуется, предпочтение, как и раньше здесь отдается стилевым листам. Атрибуты height и width дают агенту пользователя информацию о размере изображения или объекта, что позволяет зарезервировать для него место, а тем временем продолжить отображение документа. Оба атрибута могут иметь значение типа length. Агент пользователя может изменить масштаб, если это необходимо. Атрибуты vspace и hspace специфицируют размер полей вокруг изображения или объекта. Значения по умолчанию этих атрибутов не определено, оно должно быть мало, но не равно нулю. 22. Как специфицировать альтернативный текст? Описание атрибутаalt = cdata Для агента пользователя, который не может отображать изображения, формы или аплеты, этот атрибут позволяет ввести альтернативный текст. Язык этого текста задается атрибутом lang. Атрибут alt является обязательным для элемента area и опционным для img, applet и input. Стилевые листы являются главным инструментом при разработке дизайна HTML-страниц. Они дают разработчику возможность преобразовать текст в изображение, отображать таблицы, писать программы и делать многое другое. HTML 4.0 поддерживает следующие возможности:
HTML-документ может содержать стилевые рекомендации внутри, но можно их импортировать и извне. Синтаксис стилевых правил определяется языком стилевых листов CSS (Cascading Style Sheets), который не является частью HTML. Так как агент пользователя должен осуществлять разбор стилевых инструкций, пользователь обязан декларировать, какой стилевой язык он использует. Можно использовать элемент META для установки стилевого языка по умолчанию. Так для установления в качестве стилевого языка по умолчанию CSS, в head документа нужно включить следующую декларацию. <meta http-equiv="content-style-type" content="text/css"> Стилевой язык может быть задан также в http-заголовках. Например: content-style-type: text/css Если использовано несколько деклараций стилевого языка, работает самая последняя декларация. Если нет явной декларации стилевого языка, по умолчанию устанавливается CSS. HTML-элементы и атрибуты определяют начало стилевого листа. Конец стилевого листа определяется открытым разграничителем конечной метки, за которым следует начальный символ имени SGML [a-za-z]. Агент пользователя должен иметь соответствующий хандлер стилевого листа. Одним из строчных стилевых атрибутов является style = Cdata. Этот атрибут специфицирует стилевую информацию для текущего элемента. Ниже приведен пример задания цвета и размера шрифта в тексте параграфа. <p type="text/css" style="font-size: 12pt; color: fuschia">aren't style sheet wonderful? Декларация типа имя: значение является конструкцией языка CSS. Если стиль планируется использовать повторно в нескольких элементах, более корректным будет применение элемента style, а не атрибута style, который носит одноразовый характер. 23.1. Стилевая информация заголовка. Элемент style <!element style - - cdata -- стилевая информация --
Описание атрибутов type = cdata Этот атрибут специфицирует язык стилевого листа (заменяет значение по умолчанию). Стилевой язык специфицируется также как и тип среды Интернет (internet media type) (т.е. "text/css"). media cdata-list Этот атрибут специфицирует среду для стилевой информации. Это может быть одна среда или перечень, где отдельные элементы списка разделены запятыми. Возможные типы сред:
Элемент style позволяет разработчику установить стилевые правила в заголовке документа. HTML допускает любое число элементов style в секции head документа. Агент пользователя, который не поддерживает стилевые листы или специфический стилевой язык, используемый элементом style, должен прятать содержимое элемента style. Управление средой особенно интересно, когда применяются внешние стилевые листы, так как агент пользователя может сэкономить время, копируя через сеть только те стилевые листы, которые используются на данном устройстве вывода. Следующая декларация CSS style устанавливает рамку вокруг каждого Н1 элемента в документе и центрирует ее на странице. <head>
Для спецификации того, что этот стиль информации должен применяться только для Н1-элементов определенного класса, модифицируем эту запись следующим образом. <head>
<body>
И наконец, для того чтобы ограничить зону действия стилевой информации одним случаем Н1, установим атрибут ID. <head>
<body>
В следующем примере использован элемент span для определения шрифтового стиля первых нескольких слов. <head>
<body>
В следующем примере используется div и атрибут class для выравнивания последовательности параграфов. Эта стилевая информация может быть использована повторно, например, для форматирования резюме научных статей путем установки атрибута class в соответствующем месте документа. <head>
<body>
</body> HTML позволяет разработчику конструировать документы, структура которых не зависит от специфических свойств среды. В результате пользователь может просматривать этот документ с использованием самых разных агентов пользователя: на персональной ЭВМ, рабочей станции, Х-терминале, специально приспособленном телефонном аппарате и т.д.. Атрибут media специфицирует среду вывода для формирования стилевых правил. Установив атрибут media, разработчик может позволить агенту пользователя избежать копирования через сеть стилевых листов, не используемых в данном документе. Ниже предлагается пример деклараций для элемента Н1. При отображении на экране текст будет голубым и выровненным по центру, при печати текст будет выровнен по центру. Предусмотрена возможность вывода и на речевой синтезатор. <head>
h1 { text-align: center } </style> <style type="text/acss" media="speach"> h1 { cue-before: url(bell.aiff); cue-after: url(dong.wav)} </style> </head> Предыдущий пример может быть переписан для случая применения внешних стилевых листов (вместо элемента style) в сочетании с атрибутом media. Агент пользователя на основе атрибута media принимает решение о копировании из сети тех или иных стилевых листов. <head>
Стилевые листы могут быть определены отдельно от документа. Это позволяет использовать такие стилевые листы во многих документах. Кроме того, стиль может быть изменен без модификации самого документа. Любой стиль обычно представляет собой иерархию стилевых листов. Некоторые из них используются вне зависимости от выбора пользователя. Для выбора внешних стилевых листов используется элемент Link. При этом необходимо установить следующие атрибуты:
Сначала специфицируются постоянные (persistent) внешние стилевые листы (например, из файла mystyle.css). <link href="mystyle/css" rel="stylesheet"> Установка атрибута title превращает постоянный стилевой лист в лист по умолчанию. Агенты пользователя должны предоставлять возможность применения именованных стилей на базе атрибута title. <link href="mystyle/css" title="compact" rel="stylesheet"> Добавление ключевого слова "alternate" к атрибуту rel делает стилевой лист альтернативным. <link href="mystyle/css" title="medium" rel="alternate stylesheet"> Все альтернативные стили, имеющие один и тот же заголовок (title), будут использоваться, когда пользователь (через агента пользователя) активирует этот стиль. Стилевые листы с разными заголовками в этом случае не будут применены. Однако, стилевые листы, которые не имеют атрибута title, применяются всегда (за исключением случая, когда пользователь отключает все стилевые листы). Агент пользователя должен обеспечить средства выбора стилей для пользователей. Значение атрибута title предоставляет имя, которое может использоваться при выборе стиля. В предлагаемом примере определено два альтернативных стиля, названных "compact". Если пользователь выберет стиль "compact", будут применены оба внешних стилевых листа, а также стилевой лист "common.css" (применяется всегда, так как атрибут title не установлен). Если пользователь выберет стиль "big print", агент пользователя применит файлы "bigprint.css" и "common.css". <link rel="alternate stylesheet" title="compact" href="small-base.css"> Ниже предлагается вариант с элементами link и style. <link rel=stylesheet href="corporate.css">
23.4. Установка именованного стиля по умолчанию Для установки в документе именованного стиля по умолчанию используется элемент meta. Например (установка стилевого листа "compact" в качестве стиля по умолчанию): <meta http-equiv="default-style" content="compact" Стилевой лист по умолчанию может быть установлен в HTML-заголовке. default-style: "compact" Если имеется две или более деклараций стилевого листа по умолчанию, то работает последняя декларация. Если явной декларации стиля по умолчанию нет, то берется первый элемент link, где есть title и где имеется атрибут rel="stylesheet". При отображении документа с использованием стилевых листов выполняются определенные правила наследования свойств (тип шрифта, цвет и т.д.). Если то или иное свойство не может быть наследовано, используется значение по умолчанию. Некоторые стилевые языки поддерживают синтаксис, который позволяет разработчику спрятать содержимое элементов style от агентов пользователя, которые их не поддерживают, с тем, чтобы они не пытались отобразить эти фрагменты, как текст. Например (случай с CSS): <style type="text/css"> Иногда бывает удобно, конфигурируя WEB-сервер, установить стилевые листы, которые воздействуют на группу WWW-страниц. HTTP Link-заголовок имеет то же воздействие, что и элемент Link с теми же атрибутами и значениями. Заголовки с несколькими Link работают также как и несколько элементов Link, в соответствии с их порядком записи. link: rel=stylesheet href="corporate.css" cоответствует <link rel="stylesheet" href="corporate.css"> Можно описать несколько альтернативных стилей, используя несколько Link-заголовков, а затем с помощью атрибута Rel определить стиль по умолчанию. link: rel="stylesheet" title="compact" href="compact.css" Для задания цвета фона может использоваться атрибут bgcolor = color (хотя это и не рекомендуется). Применение стилевых листов для решения этой задачи предпочтительнее. Другой проблемой форматирования является выравнивание текста. Для этой цели служит атрибут Align = left|center|right|justify. Здесь справедливы те же замечания, что и в случае атрибута bgcolor. Ниже предлагается пример решения задачи выравнивания с использованием стилевого листа. <head> Следует иметь в виду, что приведенный текст отцентрирует все заголовки Н1. Можно ограничить зону действия данного стиля, установив атрибут ID. <head> Аналогично для выравнивания по правому и левому полям с использование атрибута align: <p align="justify"> ..далее следует текст.. То же с использованием стилевого листа: <head> Для двойного выравнивания последовательности параграфов можно группировать их с помощью элемента div. <div align="justify"> Решение той же задачи с использованием каскадирования стилевых листов: <head> Для выравнивания всего документа с использованием каскадирования стилевых листов можно записать: <head> Элемент center работает также как и элемент div с атрибутом align="center". Использование center не рекомендуется. Изображения и объекты могут быть привязаны к тексту, а могут обтекаться текстом, прижимаясь к одной из сторон документа и деформируя его поля. Плавающие объекты начинаются с новой строки. Для управления положением плавающего объекта используется атрибут align. Например: <img align="left" src=http://foo.com/animage.gif> Существует атрибут для элемента br, который управляет обтеканием объекта текстом. Это clear= none|left|right|all, который определяет то, где должна появиться следующая строка в процессе отображения.
Рассмотрим вариант, когда текст размещается справа от изображения, и посмотрим, что будет после прерывания строки с помощью BR.
Если атрибут clear="none", следующая строка начнется сразу под уже имеющимся текстом.
Если же clear = "left" или all, то мы получим: Используя стилевые листы, мы можем потребовать, чтобы все разрывы строк обрабатывались аналогичным образом. Для реализации этого можно записать: <style type="text/css"> Для того чтобы такая схема размещения текста сработала только раз, следует воспользоваться атрибутом ID. <head> 23.7. Элементы управления шрифтами: tt, i, b, big, small, strike, s и u <!entity % font
Ниже приведены примеры управления шрифтами. <b>bold</b> Броузер отобразит при этом на экране: bold, italic, bold italic , teletype text, big, small text. Использование стилевых листов позволяет получить значительно большее многообразие шрифтов. Например, нижеприведенный текст даст распечатку голубым курсивом: <head> <p id="mypar"> . далее следует текст, печатаемый голубыми буквами курсивом. 23.8. Элементы модификаторов шрифтов: font и basefont <!element font - - (%inline)* -- локальное изменение шрифта -->
<!element basefont - o empty>
С этими элементами могут использоваться атрибуты (все они не рекомендуются к использованию): size = cdata Атрибут определяет размер шрифта (1-7). color = color Атрибут определяет цвет шрифта. face = cdata-list Атрибут определяет список шрифтов, которые агент пользователя должен рассматривать в порядке приоритета. Элемент font изменяет размер и цвет шрифта для текста, в нем содержащегося. Элемент basefont устанавливает базовый размер шрифта (с помощью атрибута size). Размер шрифта, заданного font является относительным по отношению к размеру, определенному basefont. Если basefont не задан, значением по умолчанию считается 4. Ниже приведены примеры задания шрифтов с помощью font (данная форма определения размера шрифта не рекомендуется). <p> <font size=1> size=1</font> Агент пользователя при этом отобразит следующее size=1 size=2 size=3 size=4 size=5 size=6 size=7 <!element hr - o empty>
Определение атрибутов noshade Этот булев атрибут требует, чтобы агент пользователя пользовался одноцветным способом отображения линии. size = length (Не рекомендуется) Этот атрибут определяет высоту линии. width = length (Не рекомендуется) Этот атрибут определяет ширину линии (по умолчанию 100%), то есть линия пресекает весь экран. Пример использования элемента hr. <hr width="50%" align="center"> Обычный документ имеет одну секцию заголовка и одну секцию тела документа. Документ с рамками имеет заголовок (head), frameset (набор рамок) и, опционно, тело документа. Секция frameset специфицирует раскладку объектов в основном окне агента пользователя. Секция body предлагает альтернативу для случая агентов пользователя, которые не поддерживают frameset. <!element frameset - - ((frameset|frame) + & noframes?)>
Определения атрибутов rows = length-list Этот атрибут специфицирует выкладку горизонтальных рамок. Значение представляет собой список длин, разделенных запятыми. Если атрибут не задан, значение по умолчанию равно 100%. cols = length-list Этот атрибут специфицирует выкладку вертикальных рамок. Значение представляет собой список длин, разделенных запятыми. Если атрибут не задан, значение по умолчанию равно 100%. Все рамки предполагаются прямоугольными. Установка атрибута rows определяет число рамок по горизонтали, а атрибут cols задает число рамок по вертикали. Таким образом, задается сетка рамок. Если атрибут rows не задан, каждая колонка занимает всю длину страницы. Если атрибут cols не задан, каждый ряд занимает всю ширину страницы. Если не заданы оба атрибута, на странице присутствует одна рамка, занимающая всю страницу. Размер может задаваться в пикселях (абсолютно), в процентах от размеров экрана или в относительных длинах в форме i*, где i - целое число. Когда заданы оба атрибута, агент пользователя сначала выделяет размеры, заданные абсолютно, затем оставшуюся часть делит в соответствии с определенными долями. Значение * эквивалентно 1*. Отображение страницы осуществляется слева направо и сверху вниз. Пример (экран делится на две равные части, верхнюю и нижнюю): <frameset rows="50%, 50%"> В следующем примере создается три колонки: вторая имеет фиксированную ширину в 250 пикселей (что удобно для картинки известного размера). Первая получает 25% оставшегося пространства, а третья - 75%. <frameset cols="1*,250,3*"> В следующем примере создается решетка 2х3 <frameset rows="30%,70%" cols="33%,34%,33%"> В следующем примере предполагается, что высота окна равна 1000 пикселей. Для первой рамки выделяется 30% общей высоты (300 пикселей). Для второй рамки выделено точно 400 пикселей. Это оставляет 300 пикселей на две оставшиеся рамки. Высота четвертой рамки определена как "2*", а третей - *, следовательно, третья получит 100, а четвертая - 200 пикселей. <frameset rows="30%,400,*,2*" > Если при задании абсолютных размеров остается свободное место, или возникает перерасход пространства, агент пользователя пропорционально увеличит или уменьшит размеры рамок. frameset могут вкладываться друг в друга на любом уровне. В приведенном примере внешний frameset делит имеющееся пространство на три равные колонки. Внутренний frameset делит вторую область на два ряда не равной высоты. <frameset rows="33%,33%,34%" >
<!element frame - o empty>
Определения атрибутов name = cdata Атрибут присваивает имя текущей рамке. К этому имени можно адресоваться. src = url Этот атрибут специфицирует положение исходного документа, содержимое которого заключено в рамку. noresize Этот булев атрибут говорит агенту пользователя, что размер окна рамки не может быть изменен. scrolling = auto|yes|no Этот атрибут специфицирует информацию о возможности прокрутки информации в данной рамке. Возможные значения:
frameborder=1|0 Этот атрибут предоставляет агенту пользователя информацию о рамке вокруг текущего окошка. 1 означает, что агент пользователя должен прочертить границу вокруг текущей рамки (значение по умолчанию). 0 означает, что агент пользователя не должен прочерчивать границу вокруг текущей рамки. marginwidth = length Этот атрибут специфицирует правое и левое поля между текстом и границей рамки. Значение должно быть больше одного пикселя. Значение по умолчанию определяет агент пользователя. marginheight = length Этот атрибут специфицирует размер верхнего и нижнего поля между текстом и границей рамки. Значение должно быть больше одного пикселя. Значение по умолчанию определяет агент пользователя. Атрибут SRC определяет источник текста, помещаемого в рамку. Содержимое рамки не может быть записано в том же документе, в котором описана сама рамка. Пример: <html>
</html> В результате будет получена раскладка рамок, показанная ниже не рисунке. Ниже приведенный пример содержит в себе ошибку, так как текст второй рамки включен в описание самой рамки. <html>
<body>
. некоторый текст. <h2><a name="anchor_in_same_document">important section</a></h2> . некоторый текст. </body> </html> Существует атрибут target = cdata, который специфицирует имя рамки, где должна быть размещена информация. Путем присвоения с помощью атрибута name имени рамке разработчик может ссылаться на нее, как на адрес связей. Атрибут target может быть установлен для элементов, создающих связи (А, link), карты изображения (area) и формы (form). Ниже предлагается пример, где target позволяет динамически изменять содержимое рамки: <html>
</html> Затем в init_dynamic.html мы организуем связь с рамкой под именем "dynamic" <html>
you're doing great. now on to
</html> Активирование любой связи приводит к открытию документа в рамке с именем "dynamic", в то время как другие рамки ("fixed") остаются со своим исходным содержимым. 24.3. Установка для связей адресов по умолчания Когда многие связи в документе указывают на один и тот же адрес, имеется возможность специфицировать адрес только один раз, а ссылки обеспечить путем введения атрибута target в нужные элементы. Это делается путем установки атрибута target элемента base. Рассмотрим предыдущий пример с этой точки зрения. <html> now you may advance to <a href="slide2.html">slide 2.</a> Существует несколько методов сделать рамку адресом связи.
Имя рамки должно начинаться с буквы (a-za-z). Агент пользователя должен игнорировать любые другие имена. Существует несколько имен, зарезервированных для специальных целей.
Агенты пользователя, которые не поддерживают рамки, должны отображать секцию body, которая следует за самым внешним frameset документа. Агенты пользователя, которые поддерживают рамки, должны игнорировать эту секцию body. <!element noframes - - (#pcdata, ((body,#pcdata)|
Элемент noframes специфицирует содержимое, которое должно быть отображено, только когда не отображаются рамки. Агенты пользователя могут отображать содержимое только в случае, когда они сконфигурированы с блокировкой поддержки рамок. Предположим, что имеется frameset, определенный в "top.html", который отображает документ "main.html", и оглавление этого документа ("table_of_contents.html"). Тогда содержимое "top.html": <html>
</html> Когда пользователь читает "top.html", а агент пользователя не поддерживает работу с рамками, на экране ничего не появится, если в секции body ("top.html") нет альтернативного текста. Если мы введем "table_of_contents.html" и "main.html" непосредственно в body, задача ассоциации документов будет решена. Но при этом мы можем заставить агента пользователя, который поддерживает рамки, скопировать один и тот же документ дважды. Более экономно включить оглавление в начало "main.html", в элемент noframes: <html> Элемент noframes может использоваться в frameset-секции документа. Например: <!doctype html public "-//w3c//dtd HTML 4.0 frameset//en"
Описание атрибутов longdesc = uri Этот атрибут специфицирует связь с длинным описанием рамки. Это описание должно быть дополнением короткого описания, данного в атрибуте title. name = cdata Этот атрибут присваивает имя текущей рамке. Это имя может использоваться в последующих ссылках. width = length Ширина рамки. height = length Высота рамки. Элемент Iframe позволяет разработчику ввести рамку в блок текста. Эта процедура схожа с введением одного HTML-документа в другой с помощью элемента object. Информация, которая должна быть введена, определяется атрибутом src этого элемента. Содержимое элемента Iframe отображается только агентами пользователя, которые не поддерживают рамки. Пример, когда рамка вводится внутрь текста, приведен ниже. <iframe src="foo.html" width="400" height="500" Размеры этих рамок не могут быть изменены. HTML-форма представляет собой часть документа, содержащая обычный текст, разметку (markup) и специальные элементы управления, называемые controls. controls служат для приема и обработки текста, вводимого пользователем. Форма - это аналог стандартного бланка, заполняемого пользователем. Заполненная форма может быть послана по почте другому пользователю, или передана программе для последующей обработки. Каждый control (графа бланка) должен иметь имя, а его значение определяется его типом. Ниже приведен пример формы, где используются метки и различного типа кнопки: <form action="http://somesite.com/prog/adduser"
method="post"> Каждый control имеет исходное и текущее значение, каждое из которых представляет собой символьную строку. Исходное значение может быть определено с помощью соответствующего атрибута. Кнопки Разработчики могут создавать три типа кнопок:
Разработчик создает кнопку с помощью элемента button или input. Следует иметь в виду, что элемент button предоставляет более широкие возможности, чем input. Переключатели Переключатели (chekbox; и радио-кнопки) представляют собой двухпозиционные приборы, которые могут находиться в состоянии on/off (вкл/выкл). Пользователь может переводить этот переключатель из одного состояния в другое. Переключатель находится в состоянии "on", когда установлен соответствующий атрибут управляющего элемента. Несколько переключателей могут относиться к одному и тому же control, позволяя, например, выбрать одно из нескольких значений определенного параметра. Для формирования переключателя используется элемент input. Радио-кнопки Радио-кнопки схожи с переключателями. Но здесь при наличии нескольких кнопок, относящихся к одному имени control, перевод одной кнопки в состояние "on" переводит все другие кнопки с тем же именем в состояние "off". Для создания радио-кнопок используется элемент input. Меню Меню предоставляет пользователю выбор из нескольких возможностей. Для формирования меню используется элемент select, в сочетании с элементами optgroup и option. Ввод текста Разработчик может создать два типа controls, которые позволяют вводить текст. Элемент input создает однострочный control для ввода, а textarea предназначен для многострочного ввода. В обоих случаях введенный текст становится текущим значением control. Выбор файла Этот тип control позволяет пользователю выбрать файлы, так что их содержимое будет введено в форму. Для обеспечения выбора файла используется элемент input. Скрытые элементы управления control Разработчик может создать control, которые не отображаются на экране, но величины которых заносятся в форму. Для формирования скрытого control используется элемент input. Объектные control Разработчик может ввести в форму общие объекты, так что соответствующие величины будут заноситься в форму. Для работы с объектными control используется элемент object. Элементы, используемые для создания controls, обычно вводятся в элемент FORM, но могут появляться и вне декларации FORM, когда они используются для построения интерфейса пользователя.
Определение атрибутов action = url Этот атрибут специфицирует агента, который осуществляет обработку формы. Например, возможным значением атрибута может быть HTTP URI (для передачи формы программе) или mailto URI (для пересылки формы по электронной почте). method = get|post Этот атрибут специфицирует http-метод, который будет использоваться для представления данных. Возможные значения: "get" (по умолчанию) и "post". Метод post вводит пары имя/значение в тело формы. enctype = content-type Этот атрибут специфицирует тип содержимого (internet media type), используемого при передаче формы серверу (когда метод = "post"). Значение по умолчанию атрибута равно "application/x-www-form-urlencoded". Значение "multipart/form-data" должно использоваться в сочетании с type="file" элемента input. accept-charset = charset list Этот атрибут специфицирует список кодировок символов для входных данных, которые должны быть приняты сервером, обрабатывающим эти формы. Значения атрибута представляют собой список значений символьных комбинаций, разделенных пробелами или запятыми. Сервер должен интерпретировать этот список и воспринимать любой односимвольный код. Значение этого атрибута по умолчанию равно "unknown". Агент пользователя может интерпретировать это значение как символьную комбинацию, которая была использована для передачи документа, содержащего этот элемент form. accept = content-type-list Этот атрибут специфицирует список типов содержимого (в качестве разделителей используются занятые), которые сможет корректно воспринять и обработать сервер форм. Элемент form работает как контейнер для controls. Он специфицирует:
Ниже приведен пример, который показывает форму, которая должна быть обработана программой "adduser". Форма посылается программе с помощью метода http "post". <form action="http://somesite.com/prog/adduser"
method="post"> Следующий пример показывает, как послать форму по заданному электронному адресу: <form action="mailto:kligor.t@gee.whiz.com" method="post"> <!entity % inputtype
Определение атрибутов Этот атрибут специфицирует тип создаваемого control. Значение по умолчанию "text". Этот атрибут присваивает имя control. Этот атрибут специфицирует начальное значение control. Этот атрибут сообщает агенту пользователя исходную ширину control. Ширина задается в пикселях, за исключением случая, когда тип атрибута "text" или "password". В этом варианте ширина измеряется числом символов. maxlength = number Когда тип атрибута "text" или "password", этот атрибут специфицирует максимальное число символов, которое предлагается ввести пользователю. Это число может превзойти указанный размер, тогда агент пользователя должен предложить механизм скроллинга. checked. Когда тип атрибута "radio" или "checkbox", этот булев атрибут указывает, что кнопка нажата. Агент пользователя должен игнорировать этот атрибут для всех других видов control. src = url Когда тип атрибута "image", этот атрибут специфицирует положение изображения, которое будет использовано для украшения кнопки. Атрибут type элемента input определяет то, какой управляющий элемент создан.
Нижеследующий фрагмент HTML представляет собой пример простой формы, которая позволяет пользователю ввести свою фамилию имя, электронный адрес и т.д. <form action="http://somesite.com/prog/adduser"
method="post">
Следующий пример представляет собой анкету, предложенную выше, дополненную кнопками submit и reset. Кнопки содержат изображения, для чего использован элемент img. <form action="http://somesite.com/prog/adduser"
method="post"> Внешне данная форма будет выглядеть для пользователя следующим образом:
<!element isindex - o empty>
Элемент использовать не рекомендуется, вместо него лучше применять элемент input. Описание атрибута Атрибут специфицирует строку приглашения для ввода. Служит для ввода одной строки пользователем. Например: <isindex prompt="enter your name: "> Та же задача решается с использованием элемента input следующим образом (рекомендуемый вариант): <form action="." method="post"> <!element button - - (%flow;)* -(a|%formctrl;|form|fieldset) -- клавиша -->
Описание атрибутов name = cdata Этот атрибут присваивает имя кнопке. Этот атрибут присваивает значение кнопке. Этот атрибут декларирует тип кнопки. Когда атрибут не задан, поведение кнопки не определено. Возможные значения:
Элемент button с типом "submit", содержащий изображение (т.е. элемент img), очень похож на элемент input с типом "image". Но их поведение на фазе отображения различно. В этом контексте элемент input предполагает плоское изображение, а button - объемное (кнопка нажимается и отбрасывает тень). Ниже приведен пример использования элементов input и button: <form action="http://somesite.com/prog/adduser"
method="post"><p> Если используется button с элементом img, рекомендуется применение img-элемента с атрибутом alt, чтобы обеспечить совместимость с агентами пользователя, не поддерживающими графику. Недопустимо использование карты изображения с img в элементе button: <button> Элемент button с типом "reset" очень похож на элемент input с типом "reset". <!element select - - (optgroup|option)+ -- селектор опции -->
Определение атрибутов name = cdataЭтот атрибут присваивает имя control. Если элемент select представлен в виде окна с полосой прокрутки, этот атрибут специфицирует число рядов в списке, которые должны быть видны одновременно. Визуальный агент пользователя не должен представлять элемент select в качестве окна; он может использовать и другой механизм, например, выпадающее меню. multiple Этот булев атрибут позволяет обеспечить множественный выбор. При отсутствии этого атрибута допускается только один выбор. Элемент select создает список вариантов, из которых может выбирать пользователь. Каждый элемент select должен предложить как минимум один вариант. Каждый вариант специфицируется с помощью элемента option.
Описание атрибутов элемента option selected Этот булев атрибут определяет то, что данная опция является уже выбранной (pre-selected). value = cdata Этот атрибут специфицирует исходное значение control. Если атрибут не установлен, исходное значение определяется содержимым элемента option. label = text Этот атрибут позволяет разработчику специфицировать более короткую метку, чем содержимое элемента option. Если атрибут задан, агент пользователя должен использовать в качестве метки опции значение атрибута, а не содержимое элемента option. Элемент select помогает создать меню, с помощью которого осуществляется выбор опции. Ниже приведен пример создания такого меню. <form action="http://somesite.com/prog/component-select"
method="post"> Атрибут size определяет, что в окне должно быть видно 4 опции. Реальное число опций равно 7, по этой причине выбор остальных опций возможен с помощью механизма скролинга. Элемент optgroup позволяет разработчику логически сгруппировать опции. Это особенно удобно, когда пользователь должен сделать выбор из длинного списка опций. В HTML 4.0 все элементы optgroup должны быть специфицированы в пределах элемента select (т.е., группы не могут вкладываться друг в друга). В ниже приведенном примере показано использование элемента optgroup: <form action="http://somesite.com/prog/someprog"
method="post">
Определение атрибута label = text [cs] Этот атрибут специфицирует метку опции для группы опций. Когда форма передается на обработку, каждый из выборов группируется с именем "component-select".
Определение атрибутов name = cdata [ci] Этот атрибут присваивает имя control. rows = number [cn] Этот атрибут специфицирует номер видимой строки текста. Пользователь может ввести больше строк, чем это число, по этой причине агент пользователя должен предоставить средства для скролирования текста, чтобы обеспечить доступ к строкам за пределами видимости окна. cols = number [cn] Этот атрибут специфицирует видимую ширину строки (в символах). Пользователь может иметь возможность ввести более длинные строки, так что агент пользователя должен обеспечить средства для скролирования текста по горизонтали. Агент пользователя может разрывать строки, чтобы их сделать видимыми по всей длине без горизонтального скролинга. Пример использования элемента textarea для создания текстовой области размером 20 строк по 80 колонок. В исходный момент зона содержит только две строки. <form action="http://somesite.com/prog/text-read"
method="post"> <!element label - - (%inline;)* -(label) -- form field label text -->
Определение атрибута for = idref [cs] Этот атрибут устанавливает соответствие между меткой и control. При наличии этого атрибута его значение должно совпадать с атрибутом id другого control того же документа. При отсутствии этого атрибута метка ставится в соответствие содержимому элемента. Элемент label может использоваться для привязки информации к другим элементам control (за исключением других элементов label). Ниже приведены два примера использования элемента label. <form action="..." method="post"> Для установления неявной связи между меткой и другим control контрольный элемент должен находиться внутри содержимого элемента label. В этом случае label может содержать только один контрольный элемент. В примере две метки неявно поставлены в соответствие двум вводимым текстам: <form action="..." method="post"> 25.9. Элементы fieldset и legend <!-- #pcdata служит для решения проблемы смешанных данных, согласно спецификации здесь допустимы только whitespace! -->
<!attlist legend
Определение атрибута элемента legend Не рекомендуется к применению. Этот атрибут специфицирует положение легенды по отношению к набору полей. Возможные значения:
Элемент fieldset позволяет разработчику тематически группировать управляющие элементы. Группирование облегчает пользователю понимание их функций и в то же время упрощает графическому агенту пользователя их размещение. Элемент legend позволяет разработчику поставить в соответствие надпись, поясняющую назначение полей, и fieldset. Ниже представлен пример использования этих элементов. <form action="..." method="post"> Обратите внимание на то, что в этом примере можно улучшить представление формы путем выравнивания элементов в пределах каждого fieldset (с помощью стилевых листов), добавив цвета, подобрав шрифты и используя скрипты. Активный элемент HTML-документа должен быть выделен. Существует несколько способов выделения элемента:
Описание атрибута tabindex = integer Этот атрибут специфицирует положение текущего элемента по порядку, значение может быть положительным или отрицательным. Элементы, которые могут быть выделены, должны обрабатываться агентом пользователя согласно следующим правилам:
Атрибут tabindex поддерживается элементами a, area, object, input, select, textarea и button. Ниже предлагается пример. <!doctype html public "-//w3c//dtd html 4.0//en" Ключи доступа accesskey = cdata Этот атрибут присваивает ключ доступа элементу. Ключ доступа представляет собой одиночный символ в текущей кодировке агента пользователя. Нажатие клавиши, соответствующей ключу доступа, приводит к выбору элемента.Действия, которые будут выполнены при выборе, зависят от элемента. Атрибут accesskey поддерживается элементами: label и legend. В приведенном примере клавиша "u" ставится в соответствие элементу управления input. <form action="..." method="post"> В ниже приведенном примере ключ доступа поставлен в соответствие связи, описанной элементом А. Нажатие клавиши доступа (c) приводит к вызову другого элемента. <p><a accesskey="c" В системе MS Windows для активации ключа доступа одновременно с ним следует нажать клавишу alt. Атрибут disabled Когда этот булев атрибут установлен для control формы, он блокирует данный вид контроля для ввода пользователя. Атрибут disabled поддерживается элементами input, textarea, select, option, object, label и button. Блокированный элемент не может быть выделен, он игнорируется при обходе элементов и значения блокированного элемента не передается вместе с формой. В ниже предлагаемом примере блокированный элемент input не может воспринять ввод пользователя и передать его с формой. <input disabled name="fred" value="stone"> Изменить значение атрибута динамически можно только с помощью скрипта. Атрибут readonly Этот булев атрибут при установке запрещает изменение control. Элементы, предназначенные только для чтения, могут быть выбраны, но не могут быть изменены пользователем. Значения control в этом случае передается вместе с формой. Атрибут readonly поддерживается элементами input, text, password и textarea. На стороне клиента скрипт представляет собой программу, которая может сопровождать документ HTML или быть непосредственно встроена в него. Программа исполняется на ЭВМ клиента при загрузке документа или при активации определенной связи. Скрипт предлагает разработчику заметно расширить возможности HTML-документа. В частности:
Существует два типа скриптов, которые могут быть подключены к документу:
Определение атрибутов src = URI [ct] Этот атрибут специфицирует местонахождения внешнего скрипта. type = content-type Этот атрибут специфицирует язык скрипта, включенного в элемент. Язык специфицируется в содержимом content-type (напр., "text/javascript"). Разработчик должен выдать значения этого атрибута, так как не существует никакого значения по умолчанию. language = cdata Не рекомендуется к применению. Этот атрибут специфицирует язык скрипта, включенного в элемент. Его содержимое представляет собой идентификатор языка. Но из-за отсутствия стандарта атрибут type предпочтительнее. defer Установка этого булева атрибута сообщает агенту пользователя о том, что скрипт не будет генерировать какого-либо текста документа, что позволяет агенту пользователя продолжить разборку и представление документа. Элемент script размещает скрипт внутри документа. Этот элемент может встретиться в head или body HTML-документа любое число раз. Сам скрипт может находиться в содержательной части элемента script или во внешнем файле. Если атрибут src не установлен, агент пользователя должен интерпретировать содержимое элемента, как скрипт. Если же src содержит URL, то агент пользователя должен игнорировать содержимое элемента и получить скрипт через URL. Разработчик должен идентифицировать язык скрипта. Для того чтобы определить язык всех скриптов в документе, необходимо включить следующую meta-декларацию в head документа: <meta http-equiv="content-script-type" content="type"> где "type" соответствует internet media type, именующему язык скрипта. В отсутствии META-декларации, значение по умолчанию может быть установлено с помощью HTTP-заголовка "content-script-type" content-script-type: type где "type" соответствует internet media type. 27.2. Локальная декларация языка скрипта Можно описать язык скрипта в каждом элементе script независимо с помощью атрибута type. В отсутствии значения языка по умолчанию этот атрибут должен быть обязательно установлен. При наличии значения по умолчанию атрибут type переписывает это значение. Ниже приведен пример, где значение языка скриптов по умолчанию равно "text/tcl". Один скрипт включен в заголовок, он размещен во внешнем файле и написан на языке "text/vbscript". Включен скрипт и в тело script (написан на "text/javascript"). <!doctype html public "-//w3c//dtd html 4.0//en" 27.3. Ссылки на html-документы из скрипта В каждом языке имеется соглашение относительно взаимодействия с HTML-объектами. Содержимым элемента script является скрипт и по этой причине агент пользователя не должен рассматривать его как часть HTML-текста. Текст скрипта начинается сразу после начальной метки и завершается любой меткой, которая начинается с символов "</". Ниже следующий пример не является корректным из-за наличия "</em>" символов внутри элемента script (эта комбинация указывает на окончание скрипта): <scipt type="text/javascript">
Корректная версия записи выглядит как: <scipt type="text/javascript">
В tcl можно это записать как: <scipt type="text/tcl">
Определения атрибутов
onload = script [ct]
onunload = script [ct]
onclick = script [ct]
ondblclick = script
onmousedown = script
onmouseup = script
onmouseover = script
onmousemove = script
onmouseout = script
onfocus = script
onblur = script
onkeypress = script
onkeydown = script
onkeyup = script
onsubmit = script Событие onsubmit происходит, когда форма передана. Этот атрибут используется с элементом form.
onreset = script
onselect = script
onchange = script Имеется возможность установить соответствие между определенными действиями и несколькими событиями, когда пользователь взаимодействует с агентом пользователя. Управляющие элементы, такие как input, select, button, textarea и label реагируют на те или иные события. В следующем примере необходимо ввести имя пользователя в текстовое поле. Когда пользователь пытается покинуть это поле, событие onblur вызывает функцию javascript, которая проверяет корректность введенного имени. <input name="num" Вот пример скрипта vbscript для обработки событий в текстовом поле: <input name="edit1" size="50"> Ниже прведен пример с использованием tcl: <input name="edit1" size="50"> Здесь приведен пример Javascript для демонстрации установки связи между скриптом и событием (в случае нажатия клавиши на мышке): <button type="button" name="mybutton" value="10"> Ниже представлен более интересный хандлер окна: <script type="text/javascript"> На tcl это выглядит как: <script type="text/tcl"> Атрибуты скриптов для событий определяются как cdata. Значение атрибута должно быть заключено в одинарные или двойные кавычки. С учетом ограничений, налагаемых программой лексической разборки, случаи появления (") и "&" в атрибуте хандлера событий должны быть записаны следующим образом: '"' должно быть записано как """ или """ Поэтому ниже представленный пример должен быть записан как: <input name="num" value="0" 28. Динамическая модификация документов Скрипты, которые исполняются в процессе загрузки документа, могут динамически модифицировать его содержимое. Эта возможность зависит от языка, используемого для написания скрипта. Динамическая модификация документов осуществляется следующим образом:
Следующий пример иллюстрирует то, как скрипты могут динамически модифицировать текст. <title>test document</title> Приведенный выше текст дает тот же результат, что и html-текст: <title>test document</title> <!element noscript - - (%block;)+
Элемент noscript позволяет разработчику варьировать содержимое, даже когда скрипт не исполняется. Содержимое элемента noscript должно отображаться соответствующим агентом пользователя в следующих случаях:
Агент пользователя, не поддерживающий скрипты для стороны клиента, должен осуществлять разборку и представление содержимого элемента. В следующем примере агент пользователя, который исполняет script, включит некоторую динамически созданную информацию, в текст документа. Если агент пользователя не поддерживает скрипты, пользователь может, тем не менее, получить эту информацию через сеть. <script type="text/tcl"> Агент пользователя, который не распознает элемент script, вероятно будет разбирать и отображать содержимое элемента, как текст. Некоторые интерпретаторы скриптов, включая те, которые ориентированы на Javascript, VBscript и TCL, позволяют помещать фрагменты текстов скриптов в SGML-комментарии. Тогда агент пользователя, не узнавший элемент script, игнорирует его текст, считая его комментарием, а продвинутый интерпретатор скриптов распознает скрипт, помещенный в комментарий, и исполнит его. Другим решением проблемы является помещение скрипта во внешний документ. 28.2. Комментирование скриптов в javascript Интерпретатор javascript позволяет вводить строку "<!--" в начало элемента script и игнорировать все символы, следующие за ней вплоть до конца строки. javascript интерпретирует "//" как начало комментария, который следует до конца текущей строки. Это необходимо, для того чтобы скрыть строку "-->" от интерпретатора javascript. <script type="text/javascript"> 28.3. Комментирование скриптов в vbscript В vbscript символ одиночной кавычки воспринимается, как начало комментария, который продолжается до конца строки. Это может быть использовано для того, чтобы спрятать "-->" от vbscript. Например: <script type="text/vbscript"> 28.4. Комментирование скриптов в tcl В TCL для начала строки комментария используется символ "#" (действует до конца строки). <script type="text/tcl"> proc square {i} { Некоторые броузеры считают комментарий завершившимся на первом символе ">". Многие разработчики при проверке своих документов полагаются на ограниченное число броузеров, предполагая, что если эти броузеры могут работать с их документами корректно, то они лишены ошибок. К сожалению, это очень неэффективный способ верификации документов, прежде всего из-за того, что многие броузеры приспособлены работать с не вполне корректными документами. Для более тщательной проверки рекомендуется воспользоваться интерпретатором SGML, например, в случае проверки соответствия документа требованиям HTML 4.0 DTD это может быть NSGMLS. Если декларации типа в вашем документе включают URI, и ваш интерпретатор SGML поддерживает этот тип системных идентификаторов, то он получит DTD (Document Type Definition) непосредственно. В противном случае можно воспользоваться каталогом образцов SGML. Предполагается, что DTD спасено в виде файла "strict.dtd", а объекты (entities) записаны в файлы "htmllat1.ent", "htmlsymbol.ent" и "htmlspecial.ent". В любом случае следует проверить то, что ваш интерпретатор SGML может работать с уникодами. Следует иметь в виду, что такая проверка, хотя и полезна и настойчиво рекомендуется, не может гарантировать полного соответствия документа требованиям спецификации HTML 4.0. Это происходит потому, что интерпретатор SGML базируется на определенных SGML DTD, не выражают всех аспектов истинного документа HTML 4.0. Интерпретатор SGML гарантирует, что синтаксис, структура, список элементов и их атрибутов соответствуют рекомендациям стандарта. Но он не может, например, обнаружить ошибки при установке атрибута ширины элемента IMG. Хотя спецификация ограничивает значение атрибута "целым числом пикселей"," DTD определяет только то, что это cdata, что практически допускает любые значения. Только специализированная программа способна выловить все несоответствия с HTML 4.0. Несмотря ни на что, этот тип верификации является рекомендуемым, так как позволяет обнаружить большинство ошибок. Этот каталог включает в себя отвергнутые директивы с тем, чтобы гарантировать, что обрабатывающее программное обеспечение, такое как NSGMLS, использует предпочтительно общедоступные идентификаторы по отношению к системным идентификаторам. Это означает, что пользователи не должны быть подключены к сети при обработке системных идентификаторов, базирующихся на URI. override yes 29.2. sgml декларация html 4.0 Замечание. Набор символов SGML-деклараций документа включает в себя первые 17 плоскостей [ISO10646] (17 раз по 65536). Это ограничение связано с тем, что это число в текущей версии стандарта SGML имеет только 8 цифр. Замечание. Строго говоря, регистрационный номер ISO 177 относится к исходному состоянию ISO 10646 в 1993 году, в то время как в этой спецификации мы базируемся на последней версии ISO 10646. <!sgml "ISO 8879:1986"
function
features
29.4. Определение типа документа DTD (Document Type Definition) <!-- Это строгие DTD HTML 4.0, которые исключают новейшие презентационные атрибуты и элементы. Разработчикам следует пользоваться строгими требованиями DTD всюду, где возможно, но могут быть применены и переходные DTD там, где это требуется для презентационных атрибутов и элементов. HTML 4.0 включает в себя механизм стилевых листов, скриптов, встроенных объектов, улучшенную поддержку размещения текста слева на право и наоборот, усовершенствования в работе с формами, обеспечение доступа для людей с ограниченными возможностями. Проект: $date: 1998/04/02 00:17:00 $ Дальнейшая информация об HTML 4.0 доступна по адресу:
http://www.w3.org/tr/rec-html40-->
FPI для переходного HTML 4.0 dtd соответствует: "-//w3c//DTD HTML 4.0 transitional//en" а его uri: http://www.w3.org/tr/rec-html40/loose.dtd Если вы пишете документ, который включает в себя рамки, используйте fpi: "-//w3c//dtd html 4.0 frameset//en" с uri: http://www.w3.org/tr/rec-html40/frameset.dtd Следующие uri поддерживаются в рамках html 4.0 "http://www.w3.org/tr/rec-html40/strict.dtd" (strict dtd) Эти uri указывают на последние версии каждого из файлов. Для ссылок используйте URI: "http://www.w3.org/tr/1998/rec-html40-19980424/strict.dtd"
-- список кодов типов среды, разделенных запятыми, в соответствие с [rfc-2045] -->
<!entity % head.misc "script|style|meta|link|object" -- повторяющиеся элементы заголовков --> <!entity % heading "h1|h2|h3|h4|h5|h6"> <!entity % list "ul | ol"> <!entity % preformatted "pre"> <!entity % color "cdata" -- цвет в представлении rgb: #rrggbb (hex формат) --> <! -- Здесь представлены имена 16 широко известных цветов с их rgb значениями:
--> <!entity % bodycolors "
<!entity % htmllat1 public "-//w3c//entities latin1//en//html" "http://www.w3.org/tr/1998/rec-html40-19980424/htmllat1.ent"> %htmllat1; <!entity % htmlsymbol public
<!entity % html.reserved "ignore"> <!-- Следующие атрибуты зарезервированы для будущего использования --> <![ %html.reserved; [ <!entity % reserved
<!entity % reserved ""> <!entity % attrs "%coreattrs; %i18n; %events;"> <!--================== Разметка текста (markup) ===================--> <!entity % fontstyle "tt | i | b | big | small"> <!entity % phrase "em | strong | dfn | code | samp | kbd | var | cite | abbr | acronym" > <!entity % special "a | img | object | br | script | map | q | sub | sup | span | bdo"> <!entity % formctrl "input | select | textarea | label | button"> <!-- %inline; охватывает строчные и "text-level" элементы --> <!entity % inline "#pcdata | %fontstyle; | %phrase; | %special; | %formctrl;"> <!element (%fontstyle;|%phrase;) - - (%inline;)*> <!attlist (%fontstyle;|%phrase;)
<!--================ Модели содержимого html ==================--> <!-- HTML имеет две базовые модели содержимого: <!element body o o (%block;|script)+ +(ins|del) -- тело документа -->
<!entity % shape "(rect|circle|poly|default)">
<!--================ Карты изображения стороны клиента ==============-->
<!-- Значения отношений могут использоваться:
<!--===================== Изображения =====================--> <!-- Длина, определенная в DTD, для cellpadding/cellspacing -->
<!-- Чтобы избежать проблем с агентами пользователя, ориентированными исключительно на работу с текстом, сделать изображение понятным и удобным для сетевого поиска для неграфических агентов пользователя, следует предусмотреть альтернативу описания с помощью alt, и избежать применения карт изображения на стороне сервера -->
<!-- usemap указывает на элемент map, который может быть в этом документе или во внешнем документе, хотя последнее и не поддерживается широко --> <!--==================== object ===================--> <!-- object используется для вставления объектов в качестве части html страниц. Элементы param должны предшествовать остальному содержимому. -->
<!--======================= java applet ========================-->
<!--================ Горизонтальная линейка ==================-->
<!--====================== Параграфы =======================-->
<!--======================= Заголовки =======================--> <!--Существует 6 уровней заголовков от H1 (наиболее важный) до H6 (наименее важный). -->
<!--================ Преформатированный текст ================--> <!-- не включает разметку для изображений и изменений в размере шрифтов --> <!--===================== inline quotes ====================-->
<!--===================== block-like quotes ====================--> <!element blockquote - - (%block;|script)+ -- Кавычки для многострочных блоков текста -->
<!--================== Введенный/Стертый текст ====================--> <!-- ins/del are handled by inclusion on body -->
<!--====================== Списки ========================--> <!-- список определений - dt - для термов, dd - для их определений -->
<!-- Стиль нумерации упорядоченных списков (ol) Стиль применяется к номеру по порядку, который по умолчанию равен 1 для первого элемента упорядоченного списка. --> <!entity % olstyle "cdata" -- ограничено перечнем: "(1|a|a|i|i)" -->
<!-- Неупорядоченные списки (ul) bullet styles -->
<!--==================== Формы =======================-->
<!-- Каждая метка не должна содержать более одного поля -->
<!entity % inputtype
<!-- #pcdata служит для решения проблем смешанного содержимого, в спецификации допустим только пробел! -->
<!element button - - (%flow;)* -(a|%formctrl;|form|fieldset) -- кнопка нажатия -->
<!--===================== Таблицы ======================--> <!-- Стандарт таблиц ietf HTML, см. [rfc-1942] --> <!-- Атрибут border устанавливает толщину рамки вокруг таблицы. Единицы измерения по умолчанию пиксели. Атрибут frame специфицирует то, какую часть рамки вокруг таблицы следует отображать. Значение "border" включено для обеспечения обратной совместимости с <table border>, который выдает frame=border и border=implied. Для <table border=1> вы получите border=1 и frame=implied. В этом случае, представляется разумным считать, что frame=border для обратной совместимости с уже существующими броузерами. --> <!entity % tframe
"(void|above|below|hsides|lhs|rhs|vsides|box|border)"> Если rules отсутствуют, то предполагается: "none", если border отсутствует или =0, в противном случае "all" -->
<!-- атрибуты вертикального выравнивания для содержимого --> (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
<!entity % calign "(top|bottom|left|right)">
<!-- Элемент colgroup группирует набор элементов col. Он позволяет сгруппировать несколько семантически зависимых колонок вместе. -->
<!-- Элементы col определяют свойства выравнивания для ячеек в одной или нескольких колонках.
Атрибут span заставляет атрибуты одного элемента col работать для нескольких колонок. -->
<!-- Используйте thead для дублирования заголовков при продолжении таблицы на нескольких страницах, или для статического заголовка для секций tbody со скролированием. Используйте tfoot для дублирования подписи под таблицей при продолжении таблицы на нескольких страницах, или для статического заголовка для секций tbody со скролированием. Используйте секции tbody, когда необходимы разделительные линии между группами строк в таблице. -->
<!-- scope проще, чем осевые атрибуты для обычных таблиц -->
<!--=================== Рамки документа ====================--> <!-- Модель содержимого для HTML-документа зависит от того, следует ли за head элемент frameset или body. Широко распространенное отсутствие начальной метки body делает непрактичным определение модели содержимого без использования помеченной секции. -->
]]>
]]>
<![ %html.frameset; [ <!--================== Заголовок документа ==================-->
<!-- Элемент title не рассматривается как часть текста. Он должен быть отображен, например, как заголовок страницы или окна. У документа должен быть только один заголовок. -->
<!attlist base href %uri; #required -- uri, выполняющий функцию базового идентификатора -- >
<!element script - - %script; -- декларации скрипта -->
<!element noscript - - (%block;)+ -- альтернативный текст для случая отображения без поддержки скриптов --> <!attlist noscript %attrs; -- %coreattrs, %i18n, %events -- > 30. Определение типа документа frameset <!-- Это HTML 4.0 frameset DTD, который должен использоваться для документов с рамками. Этот DTD идентичен переходному DTD HTML 4.0 за исключением модели содержимого "html" элемента: в документах с рамками, элемент "frameset" замещает элемент "body". Дополнительная информация о HTML 4.0 доступна по адресу: <!entity % html.version "-//w3c//dtd HTML 4.0 frameset//en" -- Типовое использование: <!doctype html public "-//w3c//dtd html 4.0 frameset//en"
31. Эталонные символьные объекты в HTML 4.0
Эталонные символьные объекты представляют собой SGML конструкцию, которая соответствует набору символов документа. Эта версия HTML поддерживает несколько наборов эталонных последовательностей символов:
Следующие разделы представляют собой полные списки эталонных символьных объектов. Хотя по соглашению ISO10646 комментарии пишутся большими буквами, мы для целей лучшей читаемости преобразовали их в строчные. 31.2. Эталонные символьные объекты для символов ISO 8859-1 Эталонные символьные объекты в этой секции формируют символы, чьи цифровые эквиваленты должны поддерживаться агентами пользователя HTML 2.0. Таким образом, эталонный символьный объект ÷ более удобная форма, чем ÷ для получения знака деления (/). Чтобы поддержать эти именованные объекты агенты пользователя должны только распознать имя объекта и преобразовать его в символ из таблицы ISO88591. Символ 65533 (FFFD в шестнадцатеричной нотации) является последним допустимым символом в UCS-2. 65534 (fffe в шестнадцатеричной нотации) не имеет какого-либо соответствия и зарезервирован для "неразрывного пробела нулевой ширины" для целей детектирования порядка байт. 65535 (FFFF в шестнадцатеричной нотации) вообще не имеет смысла.
32. Приложение А
Новыми элементами в HTML 4.0 являются: abbr, acronym, bdo, button, col, colgroup, del, fieldset, frame, frameset, iframe, ins, label, legend, noframes, noscript, object, optgroup, param, s (не рекомендуемый), span, tbody, tfoot, thead и q. Не рекомендуемые элементы Следующие элементы являются не рекомендуемыми: applet, basefont, center, dir, font, isindex, menu, strike и u. Устаревшие элементы Следующие элементы являются устаревшими: listing, plaintext, и xmp. Вместо них разработчикам следует использовать элемент pre. Изменения в атрибутах
Изменения в доступе В HTML 4.0 введено много изменений для обеспечения доступа, включая:
Изменения для мета данных Разработчики могут теперь специфицировать профайлы, которые выдают объяснения по поводу мета данных, заданных элементами meta или link. Изменения для текста
Изменения для связей Атрибут ID делает любой элемент якорем назначения связи. Изменения для таблиц Модель таблиц HTML 4.0 выросла из более ранней концепции HTML+ и первоначального проекта HTML 3.0. Предыдущая модель была расширена в ответ на следующие запросы от информационных провайдеров:
Модель таблиц HTML 4.0 удовлетворяет требованиям опционного выравнивания по колонкам, предоставляется больше гибкости при спецификации рамок и разделительных линий в таблицах. Ожидается, однако, что стилевые листы в самом ближайшем будущем возьмут на себя функции формирования и таблиц. Кроме того главной целью является обеспечение обратной совместимости с широко распространенными приложениями таблиц Netscape. Другой целью было упрощение импорта таблиц совместимых с моделью SGML cals. Последний проект делает атрибут выравнивания совместимым с последней версией наиболее популярных броузеров. Для формирования групп колонок с различной шириной и свойствами выравнивания введен новый элемент colgroup, который может работать с одним или более элементов col. Стилевой атрибут включен как средство расширения свойств, связанных с краями внутренней области групп ячеек. Например, стиль линии: точечная, двойная, тонкая/толстая и т.д.; цвет заполнения внутренней области; поля ячейки и шрифты. Атрибуты рамки и разделительных линий модифицированы для исключения конфликтов имен с sgml, а также для блокировки влияния совпадения имен атрибутов align и valign. Эти изменения стимулировались желанием исключить в будущем проблемы, если спецификация будет расширена и разрешит применение атрибутов рамок и разделительных линий другими элементами таблицы. Изменения для изображений, объектов и карт изображений
Изменения для форм Данная спецификация вводит несколько новых атрибутов и элементов, для работы с формами:
Изменения для стилевых листов HTML 4.0 поддерживает больший набор описателей среды, так что разработчики могут писать стилевые листы, ориентированные на определенные внешние устройства. Изменения для рамок HTML 4.0 поддерживает документы со встроенными рамками. Изменения для скриптов Многие элементы имеют атрибуты событий, которые сопряжены со скриптами, исполняемыми при наступлении такого события (напр., при загрузке документа, при нажатии клавиши мышки и т.д.). Изменения для интернационализации HTML 4.0 интегрирует рекомендации RFC-2070 для интернационализации HTML. Однако, эта спецификация и RFC-2070 отличаются в следующих пунктах:
33. Приложение b
Следующие замечания являются информативными, а не нормативными. 33.1. Замечания по поводу некорректных документов Эта спецификация не определяет, как агент пользователя должен обрабатывать случаи ошибок, включая то, как агент пользователя должен себя вести, встретив элемент, атрибут, значение атрибута или объект, не специфицированный в данном документе. Однако, для облегчения экспериментов и взаимосогласованности между различными приложениями разных версий HTML, рекомендуется следующее:
Рекомендуется также, чтобы агенты пользователя обеспечивали информирование пользователя о перечисленных выше случаях. Так как агенты пользователя могут реагировать на ошибки по-разному разработчики и пользователи не должны предполагать какое-то определенное поведение системы при столкновении с ошибкой. Спецификация HTML 2.0 (RFC-1866) предполагает, что многие агенты пользователя HTML 2.0 считают, что документы, не начинающиеся с декларации типа, являются документами HTML 2.0. Как показывает практика, это плохое предположение, данная спецификация не рекомендует такое поведение агентов пользователя. Для целей совместимости разработчики не должны "расширять" HTML за пределы доступных механизмов SGML (напр., расширяя DTD, добавляя новые наборы объектов, и т.д.).
34. Специальные символы в значениях атрибута uri
Хотя URI не содержат не-ASCII значений, разработчики иногда специфицируют их в атрибутах, где должен лежать URI (напр., определенные с помощью %uri в DTD). Например, следующее значение Href нелегально: <a href="http://foo.org/håkon">...</a> Рекомендуется, чтобы агент пользователя воспринял следующее соглашение для обработки не-ASCII символов в следующих случаях:
Эта процедура выдает в результате синтаксически корректный uri (как это определено в RFC-1738, секция 2.2 или RFC-2141, секция 2), это не зависит от метода кодировки символов. Замечание. Некоторые старые агенты пользователя обрабатывают URI в HTML тривиально, используя байты символов в том виде, в котором они записаны в документе. Некоторые старые HTML-документы полагаются на эту практику и прерывают свою работы при перекодировке (transcode). Агенты пользователя, которые хотят работать с этими старыми документами должны при получении URI, содержащего нестандартные символы, сначала использовать преобразование, базирующееся на UTF-8. Только если полученное в результате URI не удается распознать, они должны попробовать сформировать URI, базируясь на байтах символов в кодировке полученного документа. Замечание. То же самое преобразование, базирующееся на UTF-8 должно быть применено к значениям атрибутов имен для элемента A. 34.2. Символ & в значениях атрибута URI URI, который создан при выдаче формы, может быть использован в качестве связи типа якорь (напр., атрибут Href для элемента A). К сожалению использование символа "&" для разделения полей формы противоречит его применению в значениях атрибутов SGML для выделения символьных объектов. Например, для того чтобы использовать URI "http://host/?x=1&y=2" в качестве связующего URI, его следует записать в виде <a Href="http://host/?x=1&y=2"> или <a Href="http://host/?x=1&y=2">. Рекомендуется, чтобы пользователи сервера http, и в частности, пользователи CGI поддерживали применение ";" вместо "&" с целью избавления разработчиков от обхода символов "&". 35. Замечания об использовании sgml Разрывы строк SGML специфицирует то, что разрыв строки сразу после начальной метки должен игнорироваться, также как и разрыв строки непосредственно перед конечной меткой. Это приложимо ко всем HTML-элементам без исключения. Следующие два HTML-примера должны отображаться идентично: <p> Томас смотрит телевизор.</p> Аналогично идентичными должны быть и следующие два примера: <a>my favorite website</a> 36. Спецификация не HTML-данных Текст скрипта и стилевые данные могут появиться в содержимом элемента или в качестве значения атрибута. Замечание. DTD определяет данные скриптов и стилей как Cdata для содержимого элементов и значения атрибутов. Правила SGML не позволяют использование символьных объектов в Cdata элементах, но допускают их в Cdata значений атрибутов. Разработчикам следует обращать особое внимание на случаи обмена данными скриптов и стилей методом вырезания и вставления между элементами и значениями атрибутов. Эта асимметрия означает также, что при кросскодировании (transcoding) из богатого кодового набора символов в более бедный, кодировщик не может просто заменить неконвертируемые символы в скрипте или стилевых данных соответствующим цифровыми кодами. Он должен произвести разборку (анализ) HTML-документа и узнать все о каждом скрипте и стилевом языке для того, чтобы правильно обработать соответствующие данные. Содержимое элемента Когда скрипт или стилевые данные являются содержимым элемента (script и style), данные начинаются немедленно после начальной метки элемента и кончаются на первом etago ("</") разграничителе, за которым следует имя символа ([a-za-z]), это может быть и не конечной меткой элемента. Разработчики должны избегать использования строк "</" в теле элемента. Нелегальный пример: Следующий текст скрипта содержит недопустимую последовательность "</" (в качестве части "</em>") перед конечной меткой script: <script type="text/javascript"> В javascript, этот код может быть представлен корректно, путем сокрытия разграничителя Etago перед начальным символом имени SGML: <script type="text/javascript"> В tcl, можно выполнить это следующим образом: <script type="text/tcl"> В vbscript эта проблема может быть обойдена с помощью функции chr(): "<em>this will work<" & chr(47) & "em>" Значения атрибутов Когда скриптовые или стилевые данные представляют собой значение атрибута, разработчики должны избегать случаев использования одиночных или двойных кавычек в значениях атрибута в соответствии с рекомендациями языка скрипта или описания стиля. Разработчики должны также избегать включения "&", если "&" не означает начало символьного объекта. * '"' should be written as """ or """ Таким образом, например, можно написать: <input name="num" value="0" 37. Особенности sgml с ограниченной поддержкой Системы SGML, соответствующие ISO-8879, должны поддерживать определенное число возможностей, которые не слишком широко поддерживаются агентами пользователя HTML. Разработчикам рекомендуется не использовать все эти возможности. Разработчики должны учитывать, что многие агенты пользователя распознают не все булевы атрибуты. Например, разработчик может захотеть специфицировать: <option selected> Помеченные секции играют роль, схожую с конструкцией #ifdef препроцессоров языка c. <![include[ SGML определяет также использование помеченных секций для содержимого Cdata, в пределах которого "<" не рассматривается как начало метки, напр., <![cdata[ <an> example of <sgml> markup that is Указание на то, что агент пользователя не распознал помеченную секцию, является появление символьной последовательности "]]>", которая будет отображена, когда агент пользователя ошибочно использует первый символ ">" в качестве конечной метки, начинающейся с "<![". Инструкции обработки Инструкции обработки представляют собой механизм выявления платформо зависимых идиом. Команды обработки начинаются с последовательности символов <? и завершаются >. <?instruction > Например: <?> Разработчики должны учитывать то, что многие агенты пользователя отображают (render) инструкции обработки как часть текста документа. Сжатая форма разметки документа (markup) Некоторые конструкции SGML shorttag сокращают объем данных, вводимых с клавиатуры. Хотя эти конструкции технически не вводят неопределенности, они уменьшают ясность документов, особенно когда язык усовершенствуется и добавляются новые элементы. Документы, которые используют их, являются SGML документами, но могут не работать со многими существующими средствами HTML. Конструкции shorttag, о которых идет речь, выглядят следующим образом: * net tags:
40. Заметки по индексному поиску
В глобальном контексте WWW важно знать, какой язык использован при написании документа. Если вы подготовили перевод документа на другие языки, вам следует воспользоваться для ссылки на них элементом Link. Это позволяет индексной поисковой системе предложить пользователям результат на языке, который они предпочитают, вне зависимости от того, как составлен запрос. Например, следующие связи предлагают французскую и немецкую альтернативу поисковой системы. <link rel="alternate" Обеспечение ключевыми словами и описаниями Некоторые системы индексации ищут META-элементы, которые определяют список ключевых слов или фраз, разделенных запятыми, или которые дают краткие описания. Поисковая система может представить эти ключевые слова в качестве результата поиска. Значение атрибута имени, которое ищется атрибутом поиска, не определено спецификацией. Рассмотрим такие примеры, <meta name="keywords" content="vacation, greece, sunshine"> Выделение начала коллекции Собрание документов, где ищутся слова, часто преобразуется в собрание HTML-документов. Для результатов поиска полезно указать начало такого собрания. Вы можете помочь системе поиска. Использовав элемент Link с rel="start" и атрибутом title attribute, как в: <link rel="begin" Роботы с инструкцией индексирования Люди могут удивиться, узнав, что их сайт был индексирован роботом, хотя роботу не было разрешено посещать некоторые критические секции. Многие web-роботы предлагают возможности администраторам сайтов и провайдерам информации ограничить возможности роботов. Это достигается с помощью двух механизмов: файла "robots.txt" и элемента meta в HTML-документах, как это показано ниже.
41. Поисковые роботы
Когда робот посещает сайт, скажем http://www.foobar.com/, он сначала проверяет наличие http://www.foobar.com/robots.txt. Если он нашел этот документ, он анализирует его содержимое и выясняет, разрешен ли допуск к документу. Вы можете указать, что файл robots.txt доступен только для специальных роботов, и запретить доступ к определенным каталогам и файлам. Ниже приведен пример файла robots.txt, который препятствует всем роботам посещение всего сайта. user-agent: * # applies to all robots Робот просто будет искать "/robots.txt" uri на вашем сайте, где сайт определен как HTTP-сервер, работающий на определенной ЭВМ с заданным номером порта. Ниже приведены примеры места положения robots.txt:
Должен быть только один файл "/robots.txt" на сайт. В частности, не следует помещать файл "robots.txt" в пользовательские каталоги, так как робот туда не заглядывает. Если вы хотите, чтобы пользователи создали свои собственные "robots.txt", вы должны их объединить в один общий файл "/robots.txt". Если вы не хотите это делать, пользователи могут вместо этого использовать robots meta tag. Некоторые советы: URI чувствительны к набору строчными или прописными буквами, а строка "/robots.txt" должна быть набрана строчными буквами. Пустые строки не допустимы. Должен быть только одно поле "user-agent" на рекорд. Робот должен либерально интерпретировать это поле. Если значение равно "*", рекорд описывает политику доступа любого робота по умолчанию (робот не соответствует ни одному другому рекорду). Не допускается более одного такого рекорда в файле "/robots.txt". Поле "disallow" специфицирует URI, который не должен посещаться. Это может быть полный проход, частичный проход, любой URI, который начинается с этой величины, не будет доступен. Например, disallow: /help запрещает как /help.html так и /help/index.html, в то время как Пустое значение для "disallow", указывает, что все uri доступны. Хотя бы одно поле "disallow" должно присутствовать в файле robots.txt. Элемент meta позволяет HTML разработчикам сообщить приходящим роботам, можно ли индексировать документы. В ниже приведенном примере робот не должен ни индексировать документ, ни анализировать его связи. <meta name="robots" content="noindex, nofollow"> Список терминов в содержимом включает в себя all, index, nofollow, noindex. Имена и содержимое значений атрибутов не зависит от регистра, использованного при наборе текста. Замечание. В начале 1997 только несколько роботов следовало этим правилам, но ожидается, что ситуация изменится в ближайшее время. Модель таблиц HTML взята из исследований существующих моделей таблиц SGML. Модель выбрана из соображений простоты и возможностей дальнейшего расширения функций, если это потребуется. Важно, что модель таблиц HTML согласуется с большинством существующих средств их создания (напр., с текстовыми редакторами). 43. Динамическое реформатирование Главным соображением при выработке модели таблиц HTML является то, что разработчик не должен заботиться о вариации размера таблиц пользователем или о его выборе шрифтов. Это делает рискованным задание ширины колонки в абсолютных единицах (пикселях). Вместо этого таблицы должны быть способны динамически приспосабливать размер таблицы к размерам имеющегося окна и к выбранным шрифтам. Разработчик может сформулировать пожелания относительно ширин колонок, но агент пользователя может и не следовать этим пожеланиям. Он должен обеспечить размер ячейки, достаточный для размещения самого крупного элемента. Для больших таблиц или для медленных сетевых соединений пользователю важна возможность реализации инкрементного отображения таблицы. Агенты пользователя должны быть способны начать отображение таблицы до того, как будут получены все данные. Ширина окна по умолчанию для большинства агентов пользователя равна 80 символам, а графика для многих HTML страниц сконструирована с учетом этого значения. При специфицировании числа колонок, включая различные механизмы управления шириной колонок, разработчики могут подсказать агенту пользователя как организовать инкрементное отображение таблицы. Для инкрементного отображения броузер должен знать число колонок и их ширину. Ширина таблицы по умолчанию определяется размером текущего окна (ширина="100%"). Это значение может быть изменено путем установки атрибута width в элементе table. По умолчанию, все колонки имеют равные ширины, но вы можете специфицировать ширины колонок с помощью одного или нескольких элементов col. Последний пункт - число колонок. Некоторые люди предлагают ждать, пока первый ряд таблицы будет получен, но это может занять много времени, если ячейки содержат много материала. Имеет смысл, особенно для целей инкрементного отображения таблиц, задать разработчикам число колонок в таблице явно (в элементе table). Разработчикам нужен способ, сообщить агенту пользователя, следует ли использовать инкрементное отображение или изменить размер таблицы с тем, чтобы можно было разместить содержимое ячеек. В режиме двухпроходного определения размеров число колонок определяется при первом проходе. При инкрементном режиме сначала должно быть объявлено число колонок (с помощью элементов col или colgroup). HTML различает структурную разметку, такую как параграфы и цитаты из идиом отображения (rendering idioms) таких как поля, шрифты, цвета, и т.д. Как это различие влияет на таблицы? С чисто теоретической точки зрения выравнивание текста внутри ячеек таблицы и определение границы между ячейками, проблема отображения, а не структуры. На практике полезно использовать обе возможности. Модель таблиц HTML оставляет большую часть управления отображением стилевым листам. Современные издательские системы предоставляют очень богатые возможности управления отображением таблиц. Эти спецификации предлагают разработчику возможность выбора класса стиля границ. Атрибут frame управляет наличием разграничительных линий вокруг таблицы, в то время как атрибут rules определяет выбор разделительных линий внутри таблицы. Стилевой атрибут может быть использован для спецификации информации, управляющей процессом отображения для индивидуальных элементов. Дополнительная информация может быть получена через элемент style в заголовке документа или из подключенного стилевого листа. Таблицы рассматриваются как соединение опционной надписи и последовательность рядов, которые в свою очередь состоят из последовательности ячеек. Модель еще более дифференцирует заголовок и информационные ячейки и позволяет ячейкам занимать несколько рядов и колонок. Эта спецификация (модель таблиц cals) позволяет группировать ряды в секции заголовка, тела и основания. Она упрощает представление информации и может использоваться для повторения верхней и нижней секций при разбиении таблиц на несколько страниц, или для обеспечения фиксированного заголовка над панелью со скролированием текста. Это позволяет отображать нижнюю секцию, не дожидаясь пока вся таблица будет обработана. Модель таблиц HTML включает атрибуты для пометки каждой ячейки с целью высококачественного преобразования текста в голос. Те же самые атрибуты могут использоваться для поддержки автоматического обмена с базами данных и электронными таблицами. 48. Рекомендуемые алгоритмы верстки Если присутствуют элементы col или colgroup, они специфицируют число колонок и таблица может быть отображена с использованием фиксированной раскладки. В противном случае будет применен автоматический алгоритм раскладки, описанный ниже. Если атрибут width не специфицирован, визуальные агенты пользователя должны предполагать значение по умолчанию, равное 100%. Рекомендуется, чтобы агенты пользователя увеличивали ширину таблицы за пределы, специфицированные width в случаях, когда содержимое может не поместиться. Агенты пользователя, которые корректируют значение, заданное width должны делать это в пределах разумного. Агенты пользователя могут выбрать переносы строк, когда горизонтальный скролинг не желателен или не практичен. Для целей раскладки агенты пользователя должны учитывать, что табличные надписи (специфицированные элементом caption) ведут себя подобно ячейкам таблицы. Каждая надпись является ячейкой, которая простирается через все колонки таблицы, если она размещена вверху или внизу таблицы, или через все ряды, если она находится справа или слева от таблицы. 49. Фиксированные алгоритмы верстки Для этого алгоритма предполагается, что число колонок известно. Ширины колонок по умолчанию делаются равными. Разработчики могут поменять эти установки, задав относительные или абсолютные значения колонок с помощью элементов colgroup или col. Значение ширины по умолчанию равно расстоянию от левого до правого поля, но оно может быть скорректировано с помощью атрибута width в элементе table, или определено из абсолютных ширин колонок. Для того чтобы работать со смесью абсолютных и относительных ширин, сначала нужно выделить место для колонок с заданной абсолютной шириной. После этого, оставшееся пространство делится между колонками с учетом их относительных ширин. Сам по себе синтаксис таблицы не гарантирует взаимосогласованности значений атрибутов. Например, число элементов col и colgroup может не совпадать с числом колонок, используемых в таблице. Дополнительные проблемы возникают, когда колонки слишком узки и может произойти переполнение ячейки. Ширина таблицы, как это специфицировано элементами table или col может вызвать переполнение ячейки таблицы. Рекомендуется, чтобы агенты пользователя умели выходить из этого положения, например, путем переноса слов. В случае, когда переполнение ячейки вызывается словом, которое не может быть поделено, агент пользователя может рассмотреть возможность изменения ширин колонок и повторного отображения таблицы. В худшем случае, можно допустить обрубание слов, если вариации ширин колонок и скроллинг оказались невозможными. В любом случае, если содержимое ячейки разделено или обрублено, об этом должно быть сообщено пользователю соответствующим способом. Если число колонок не специфицировано элементами col и colgroup, тогда агент пользователя должен использовать алгоритм автоматической выкладки. Он использует два прохода по данным таблицы и линейно масштабирует размеры таблицы. При первом проходе запрещается разрыв строк и агент пользователя отслеживает минимальные и максимальные ширины для всех ячеек. Максимальная ширина задается самой длинной строкой. Так как разрыв строк запрещен, параграфы рассматриваются, как длинные строки, если не введены переносы строк с помощью элементов BR. Минимальная ширина задается наиболее широким текстовым элементом (словом, изображением, и т.д.) с учетом абзацев маркеров и пр. Другими словами необходимо определить минимальную ширину ячейки, которая необходима в пределах окна для того, чтобы ячейка не переполнилась. Допуская перенос слов, мы минимизируем необходимость горизонтального скролинга или обрубания содержимого ячейки. Этот процесс применим к любым вложенным таблицам. Минимальные и максимальные ширины ячеек для вложенных таблиц используются для определения минимальной и максимальной ширины этих таблиц, и, следовательно, таблиц их прародителей. Алгоритм является линейным и не зависит от глубины вложения. Минимальная и максимальная ширины ячейки используются для определения минимальной и максимальной ширины колонки. Эти значения в свою очередь служат для нахождения минимальной и максимальной ширины таблицы. Следует учитывать, что ячейки могут содержать вложенные таблицы, но это не усложняет программу сколько-нибудь значительно. Следующим шагом является определение ширин колонок в соответствии с доступным пространством (напр., зазором между левым и правым полями). Внешние ограничители таблицы и внутренние разделительные линии должны учитываться при определении ширин колонок. Имеется три варианта:
Если ширина таблицы задана атрибутом width, агент пользователя пытается установить соответствующим образом ширины колонок. Если с помощью элемента col указаны относительные длины колонок, алгоритм может быть модифицирован так, что ширина колонок может превысить минимально объявленное значение для того, чтобы удовлетворить требования относительных ограничений. Элементы col должны рассматриваться только как рекомендации и ширины колонок не должны делаться меньше их минимальной ширины. Аналогично, колонки не должны делаться настолько широкими, что таблица не поместится в отведенное ей окно. Если элемент col специфицирует относительную ширину нуль, ширина колонки должна быть выбрана равной минимальной ширине. Если несколько ячеек в различных рядах одной и той же колонки используют выравнивание, тогда по умолчанию все такие ячейки должны быть выстроены в линию, вне зависимости от того, какой символ был использован для выравнивания. Выбор имен атрибутов. Предпочтительно выбрать значения для атрибута frame, согласующееся с атрибутом rules и параметрами выравнивания. Например: none, top, bottom, topbot, left, right, leftright, all. К сожалению, sgml требует нумеровать значения атрибутов, чтобы обеспечить их уникальность для каждого элемента, вне зависимости от имени атрибута. Это сразу создает проблемы для "none", "left", "right" и "all". Значения для атрибута frame были выбраны для исключения конфликтов с атрибутами rules, align, и valign.
51. Замечания о формах
Инкрементное отображение документов, полученных по сети, создают некоторые проблемы, связанные с формами. Агенты пользователя должны позаботиться о том, чтобы форма не была передана серверу до тех пор, пока не получены все элементы формы. Если формы связаны со скриптами стороны клиента, создаются предпосылки для будущих проблем. Например, хандлер скриптов для данного поля может относиться к полю, которого пока не существует. Данная спецификация определяет набор элементов и атрибутов, достаточно мощных, чтобы выполнить основные требования по генерации форм. Однако остается пространство для дальнейшего совершенствования. Например, следующие проблемы могут найти решение в будущем:
Другим возможным расширением может стать атрибут usemap элемента input для использования в качестве карты изображения на стороне клиента, когда "type=image". Элемент area, соответствующий позиции, где была нажата кнопка мыши, должен будет выдать информацию, передаваемую серверу. Чтобы избежать необходимости модифицировать скрипты сервера, может оказаться разумным расширить возможности area в отношении передачи значений координат x и y для использования их элементом input. Эта спецификация резервирует синтаксис для будущей поддержки скриптовых макро в атрибутах cdata HTML. Целью этого является допущение установки атрибутов, зависящих от свойств объектов, которые были записаны выше на странице. Синтаксис выглядит следующим образом: attribute = "... &{ macro body }; ... " Существующая практика скриптов Тело макро состоит из одного или более записей на языке скриптов. Точка с запятой, следующая за правой фигурной скобкой, всегда необходима, иначе правая фигурная скобка будет рассматриваться как часть текста макро. Обработка Cdata атрибутов производится следующим образом:
Обработка макро имеет место, когда документ загружается, но эта процедура не повторяется, когда документ изменяется в размере или перезакрашивается. Не рекомендуемый пример: Ниже приведены примеры с использованием Javascript. Первый делает фон документа рэндомизованным: <body bgcolor='&{randomrbg};'> Возможно, вы хотите приглушить фон для просмотра в вечернее время: <body bgcolor='&{if(date.gethours > 18)...};'> Следующий пример использует javascript при установке координат для карты изображения на стороне клиента: <map name=foo> Этот пример устанавливает размер изображения, базируясь на свойствах документа: <img src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner"> Вы можете установить URI для связи или изображения с помощью скрипта: <SCRIPT type="text/javascript"> Последний пример показывает, как SGML CDATA атрибуты могут помещаться в одинарные или двойные кавычки. Если вы помещаете строку атрибута в одиночные кавычки, вы можете использовать двойные кавычки в качестве части строки атрибута. Другой подход связан с использованием " для двухкавычечных меток: <IMG src="&{logo(manufacturer("widget"))};" alt="logo"> 53.1. Зарезервированный синтаксис для будущих скриптов Так как не существует гарантии того, что имя адресата рамки уникально, представляется разумным описать существующую практику нахождения имени адресата, заданного в рамке:
Замечание. Следующий алгоритм генерации альтернативного текста может быть заменен рекомендациями W3C Web Accessibility Initiative Group. Для получения дополнительной информации предлагается ссылка [WAIGUIDE]. Когда разработчик не устанавливает атрибут alt для элементов IMG или APPLET, агент пользователя должен предоставить альтернативный текст, который получается следующим способом:
Если разработчик не установил атрибут alt для элемента INPUT, агент пользователя должен получить альтернативный текст следующим образом:
Якоря, встроенные изображения и все другие элементы, которые содержат URI в качестве параметров, могут вызвать повторное обращение к URI в ответ на ввод пользователя. В этом случае, следует рассмотреть соображения безопасности RFC-1738. Широко распространенные методы посылки запросов форм - HTTP и SMTP - обеспечивают ограниченную конфиденциальность. Провайдеры информации, которые запрашивают необходимые данные с помощью форм - точнее с помощью элементов INPUT, type="password" - должны позаботиться о том, чтобы сами пользователи учитывали возможность утечки конфиденциальной информации. 55.1. Соображения безопасности для форм Агент пользователя не должен посылать какой-либо файл, который пользователь не указал явно, как подлежащий пересылке. Таким образом, агенты пользователя HTML должны требовать подтверждения для любых имен файлов по умолчанию, которые могут быть указаны значениями атрибутов элемента INPUT. Эта спецификация не содержит механизма шифрования данных. Раз файл загружен, агент должен обработать и записать его соответствующим образом. 56. Ссылки на литературу и сервера
Информационные ссылки
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.6.1 Гипертекстный протокол HTTP
UP:
4.5 Процедуры Интернет
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.7 Протокол новостей NNTP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Современное общество предъявляет весьма жесткие требования ко времени получения событийной информации. Это могут быть технические новинки, политические новости, уведомления о событиях (произошедших или грядущих) и т.д. Одной из форм оперативной рассылки и получения информации является электронная почта (в частности система LISTSERV). В таких системах помимо воли клиента в его почтовом ящике, как правило, скапливается огромное количество сообщений. Причем в настоящее время здесь нет пока каких-либо механизмов фильтрации. Несколько иное решение предлагает протокол NNTP и сеть рассылки новостей USENET (cм. RFC-0977, Network News Transfer Protocol, B. Kantor, P.Lapsley. and RFC-1036, Standard for interchange of USENET messages, M.R. Horton, R. Adams). В USENET системе сообщение запоминается в базе данных сервера, а не в почтовых ящиках подписчиков. Региональный депозитарий снабжается специальным программным обеспечением, которое позволяет подписчику отбирать статьи, представляющие для него интерес. Система имеет индексацию, облегчающую поиск, и удаление устаревших статей. Для кластеров ЭВМ, объединенных ETHERNET (или другой быстродействующей локальной сетью) представляется целесообразным сконцентрировать функции хранения и распределения новостей в одном узле. При этом клиент может запросить любую статью тогда, когда это ему нужно, и он не обязан предоставлять ресурсы для хранения копий статей. Учитывая то, что даже в небольшой локальной сети обычно достаточно много клиентов-подписчиков такая схема позволяет сэкономить достаточно большой объем дискового пространства. Следует учитывать, что интегральный поток новостей сегодня превышает 300 Мбайт в сутки. Сервер новостей должен размещаться в локальной сети, так как именно в этом случае время доступа минимально. Этот сервер должен заниматься сбором новостей и созданием необходимых индексных файлов. При большом числе ЭВМ такая схема дает значительную экономию дискового пространства. NNTP представляет собой протокол для рассылки, подписки, поиска и доставки новостей на основе надежного протокола поточного типа (например, TCP) с использованием схемы клиент-сервер. NNTP сконструирован так, что статья, записанная в одном из серверов, становится доступной для всех подписчиков-клиентов. Протокол NNTP предполагает применения стандартных сообщений, формат которых следует рекомендациям RFC 850. NNTP-сервер обычно работает в фоновом режиме. В больших сетях, где число клиентов велико, возможно использование нескольких серверов новостей, которые образуют иерархическую систему. При этом клиент сначала пытается подключиться к ближайшему серверу. При неуспехе соединение либо абортируется, либо переадресуется другому серверу. Единицей хранения на сервере является статья. Статьи составляют содержательную часть пересылаемых сообщений. В NNTP предусмотрены команды, которые обеспечивают непосредственный обмен статьями между взаимодействующими узлами (более эффективно, чем это позволяет, например, UUCP). Традиционный метод рассылки новостей предполагает распространение статей от узла к узлу, так что каждый сервер пересылает другому все новости, которые имеет. При этом неизбежно дублирование, связанное с этим увеличение трафика и повышенный расход ресурсов ЭВМ. Но такая схема предельно проста и вполне оправдана, когда обмен новостями происходит один раз в сутки (дубликаты статей могут быть отфильтрованы позднее). При использовании NNTP ЭВМ, обменивающиеся новостями, пользуются интерактивным механизмом в процессе принятия решения о том, какие статьи следует передать. При этом ЭВМ контактирует с одним или несколькими серверами новостей. Процедура начинается с запроса о формировании новых групп новостей, для чего выдается команда NEWGROUPS. Далее клиент делает запрос о наличии новых статей из групп, представляющих интерес (команда NEWNEWS). В ответ сервер высылает список статей, а клиент может запросить их присылку, если он их не имеет. В заключение клиент может сообщить серверу, какие новые статьи он получил в последнее время. Сервер новостей, специфицированный в NNTP, использует поточный обмен (подобный TCP), а также набор команд и откликов, схожий с SMTP. Этот сервер является единственным интерфейсом между программами и базами данных, хранящими новости. Он не выполняет взаимодействия с пользователем или каких-либо операций презентационного уровня. Эти функции передаются программам клиента, которые имеют исчерпывающую информацию о среде. При работе через Интернет в рамках протокола TCP используется порт 119. На команды, посылаемые клиентом, предусмотрены текстовые и статусные отклики. Всякая сессия начинается с процедуры установления соединения между клиентом и сервером по инициативе клиента (например, с использованием протокола TCP). Текст может посылаться только после цифрового статусного отклика. Текст имеет вид последовательности строк, каждая из которых завершается парой символов CR-LF. В конце текста всегда посылается строка, содержащая один символ (.), за которым следует CR-LF (как и в SMTP). Если исходный текст содержит точку в начале строки, то она перед посылкой должна быть задублирована. Таким образом, клиент должен просматривать первые символы каждой полученной строки и, если это одиночная точка, прерывать дальнейший прием текста. Предполагается, что текстовый отклик будет отображен на дисплее пользователя, в то время как командно-статусный отклик интерпретируется программой клиента. Статусный отклик представляет собой реакцию сервера на команду, полученную от клиента. Строки статусного отклика начинаются с 3-значного десятичного кода, достаточного для описания любого отклика. Некоторые коды являются предшественниками последующего текстового отклика. Первая цифра говорит об успехе, ошибке или процессе исполнения команды.
Следующая цифра кода характеризует категорию отклика.
Конкретное значение кодов отклика можно найти только в описании конкретной команды. Ниже приведен список кодов общего назначения, которые могут быть получены в любое время. Некоторые статусные отклики могут иметь параметры (числа или имена). Число и тип параметров фиксировано для каждого конкретного отклика. Параметры отделяются от кода отклика и друг от друга одиночным пробелом. Все цифровые параметры имеют десятичное представление и могут начинаться с нулей. Все строковые параметры начинаются после пробела и завершаются пробелом или символьной парой CR-LF, то есть не могут содержать в себе пробелов. Любой текст, который не является параметром отклика, должен отделяться от последнего параметра, если таковой имеется, пробелом и завершаться пробелом. Не специфицированные коды-отклики могут использоваться для специфических новых команд. Такой код должен относиться к категории x8x (см. таблицу, приведенную выше). Применение не специфицированных откликов для стандартных команд запрещено. Коды категории x9x зарезервированы для отладочных целей. Так как большинство отладочных откликов можно рассматривать как информационные сообщения, для отладочных выдач зарезервирован диапазон кодов 190-199. Ниже приведен список сообщений общего назначения, которые может послать NNTP сервер. Эти отклики не привязаны к каким-то конкретным командам и могут быть присланы в результате сбоя или каких-то других необычных обстоятельств. Вообще говоря, коды 1xx могут игнорироваться; коды 200 или 201 посылаются при начальном подключении к NNTP серверу в зависимости от наличия разрешения пересылки. Код 400 отправляется, когда NNTP сервер прерывает обслуживание, например по запросу оператора, а коды 5xx указывают на то, что процедура не будет выполнена, по какой-то необычной причине.
Команды записываются в этом документе прописными буквами, хотя NNTP сервер игнорирует регистр, в котором они напечатаны. Параметры команд, помещенные в квадратные скобки, являются опционными. Длина команды не должна превышать 512 байт. Команды ARTICLE, BODY, HEAD и STAT Существует две формы команды ARTICLE (и соответственно команд BODY, HEAD, и STAT), каждая из которых использует различные методы спецификации извлекаемой статьи. Когда за командой ARTICLE следует идентификатор сообщения в угольных скобках ("<" и ">"), используется первая форма команды; когда же имеется цифровой параметр или нет параметра совсем, реализуется вторая форма. Текст статьи присылается в виде текстового отклика. Команды HEAD и BODY идентичны команде ARTICLE за исключением того, что они возвращают соответственно только строки заголовка или основной текст статьи. Команда STAT похожа на команду ARTICLE за исключением того, что не присылается никакого текста. Выбирая номер сообщения в пределах группы, команда STAT служит для установки указателя статьи без пересылки какого-либо текста. Возвращаемый отклик содержит идентификатор сообщения. Использование команды STAT для выбора статей по их идентификатору вполне работоспособно, хотя и не слишком эффективно, так как такой отбор не изменяет текущий указатель статьи. ARTICLE <message-id> Команда отображает заголовок, пустую строку и текст заданной статьи. Идентификатор сообщения (message-ID) представляет собой идентификатор, представленный в заголовке статьи. Предполагается, что клиент получит идентификатор сообщения из списка, предоставляемого командой NEWNEWS. Команда не изменяет указателя текущей статьи. ARTICLE [nnn] Отображает заголовок, пустую строку и текст текущей или специфицированной статьи. Опционный параметр nnn представляет собой числовой идентификатор статьи (номер) в текущей группе новостей. Он должен быть выбран из диапазона, который был выдан при выборе группы. Если этого параметра нет, предполагается текущая статья. Эта команда устанавливает указатель текущей статьи, если номер статьи указан корректно. Откликом на команду будет номер текущей статьи, строка-идентификатор сообщения и собственно текст статьи. Присылаемая строка идентификатора сообщения представляет собой последовательность символов, заключенную в угловые скобки, которая извлечена из заголовка статьи (согласно RFC-850). Если идентификаторная строка заголовка в статье отсутствует, в угловых скобках будет записан нуль. Так как поле идентификатора сообщения для каждой статьи уникально, оно может использоваться для поиска и удаления статей-дубликатов. Отклики: 220 n <a> article retrieved - далее следует заголовок и сама статья (n = номер статьи, <a> = message-id) Команда GROUP ggg Обязательный параметр ggg представляет собой имя группы новостей, которая должна быть выбрана. Список доступных групп новостей может быть получен с помощью команды LIST. Отклик на успешный выбор группы возвращает номера первой и последней статьи в группе и оценку общего числа статей в группе. Оценка может быть и не вполне корректной, она равна или превосходит реальное число статей. Когда с помощью данной команды группа выбрана, внутренний указатель статьи устанавливается на первую запись в группе. Если выбрана несуществующая группа, остается в силе выбор предыдущей группы. При наборе имени группы выбранный регистр (строчные или прописные буквы) не играет роли. Отклики: 211 n f l s group selected Команда HELP Команда дает краткое описание команд, которые может воспринять сервер. Отклик на команду имеет текстовую форму и завершается строкой с одиночной точкой в начале. Отклик: 100 help далее следует текст Команда IHAVE <messageid> Команда IHAVE информирует сервер о том, что клиент владеет статьей с идентификационным кодом <messageid>. Если сервер хочет скопировать статью, он пришлет отклик, предлагающий клиенту прислать ее. Если же сервер по какой-либо причине не хочет, чтобы ему прислали копию этой статьи (например, он ее уже имеет), он оповещает клиента об этом в своем отклике. Если запрошена передача статьи, клиент должен выслать полный текст статьи, включая заголовок. Сервер в этом случае пришлет отклик, уведомляющий об успехе или неудаче этой операции. Эта процедура отличается от команды POST в том, что последняя предназначена для пересылки полученных извне статей. Сервер может и не пересылать полученную статью другим серверам, в этом случае будут переданы коды ошибок 436 или 437. Причиной отказа в рассылке может стать неверный код группы, ошибка в заголовке, неприемлемая длина статьи или ограничения дискового пространства. Обычно эти ограничения связаны с конфигурацией программного обеспечения на сервере. Отклики: 235 article transferred ok Так как некоторые серверы новостей не могут немедленно принять решение относительно рассылки конкретной статьи, прием статьи подтверждается (код 235), а позднее она может быть молча выброшена. Такое решение не идеально, возможно оно будет пересмотрено позднее. Команда LAST Внутренний указатель на статью устанавливается на предшествующую запись в текущей группе. Если указатель уже установлен на первую статью, отправляется сообщение об ошибке, а указатель остается неизменным. Отклик содержит текущий номер статьи и ее идентификатор. Отклики: 223 n a article retrieved - выборочно запрашивает текст Команда LIST Присылает список доступных групп новостей. Каждой группе новостей соответствует строка в следующем формате: group last first p где <group> название группы новостей, <last> номер последней известной статьи в данной группе, <first> номер первой статьи в группе, и <p> может быть либо 'y' либо 'n', указывая на наличие или отсутствие разрешения на рассылку соответственно. Поля <first> и <last> являются числовыми. Они могут начинаться с нулей. Если код поля <last> превосходит код поля <first>, в файле данной группы новостей нет ни одной статьи. Обратите внимание на то, что рассылка может быть запрещена клиенту, хотя команда LIST указывает на то, что она разрешена для данной группы новостей. Флаг рассылки существует для каждой группы новостей, так как некоторые группы подвергаются редактированию или обобщению и по этой причине не могут рассылаться. Присылаемая статья сначала по почте пересылается посреднику-редактору, который может осуществить ее рассылку. Это не зависит от права рассылки, предоставленного клиенту NNTP-сервером. Заметьте, что пустой список может быть вполне корректным откликом и означает, что в данный момент на сервере нет новостей.
Команда NEWGROUPS date time [GMT] [<distributions>] Список групп новостей создан с <date и time> будет представлен в том же формате, что и в случае команды LIST. Дата посылается в виде 6 цифр в формате ГГММДД, где ГГ последние две цифры года, MM - номер месяца (с нулем в начале, если требуется) и ДД номер дня в месяце. Дополнение для года берется из предположения о ближайшем тысячелетии, так 86 предполагает 1986, 30 - 2030, 99 - 1999, а 00 - 2000 годы. Время должно характеризоваться также 6 цифрами в формате ЧЧMMСС, где ЧЧ - часы с начала суток в 24-часовом исчислении, MM минуты 00-59, а СС секунды 00-59. Временная зона определяется сервером, в противном случае появляется символьная комбинация "GMT", в этом случае и время и дата привязаны к нулевому меридиану. Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в угловые скобки. Если параметр задан, рассылаемая часть новых групп новостей будет сравниваться с данным списком, и только при совпадении включается в список. Если необходимо использовать более одного такого фильтра, то они разделяются друг от друга запятыми в пределах угловых скобок.
Команда NEWNEWS newsgroups date time [GMT] [<distribution>] Команда формирует список идентификаторов статей для заданной группы новостей, с датой после указанной. Для каждого идентификатора сообщения в списке выделяется одна строка. Список завершается строкой с одиночным символом точки, за которым следует CR-LF. Дата и время задаются в том же формате, что и для команды NEWGROUPS. Для расширения зоны поиска в имени группы новостей можно использовать символ "*". Программа может подставить вместо звездочки любую комбинацию символов. Если вместо имени группы подставлен символ звездочка, поиск будет проведен по всем группам новостей. Если звездочка в имени группы отсутствует, новые статьи будут искаться только в группе, имя которой приведено в качестве параметра запроса. Имя группы должно быть взято из списка доступных групп. Допускается спецификация нескольких групп (имена разделяются запятыми). После последнего имени группы не должно быть запятой. Для отрицания соответствия может использоваться восклицательный знак. Это можно использовать для селективного исключения определенных групп новостей с целью сокращения размера списка. Например, спецификация групп "net.*,mod.*,!mod.map.*" определяет, что следует просмотреть все статьи в группах net.<что-то> и mod.<что-то> за исключением mod.map.<что-то>. Восклицательный знак должен использоваться непосредственно перед первым символом выбранного имени группы новостей. Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в треугольные скобки. Если этот параметр задан, производится отбор статей, соответствующих категориям, приведенным в списке distribution. Заметьте, что пустой список является вполне допустимым откликом и означает отсутствие новых статей.
Команда NEXT Команда перемещает указатель текущей статьи на следующую запись в текущей группе новостей. Если в группе нет больше статей, посылается сообщение об ошибке, а указатель текущей статьи остается не измененным. В качестве отклика на команду возвращается номер текущей статьи и идентификатор сообщения. Никаких текстовых сообщений не посылается. Отклики: 223 n a article retrieved, где n = номер статьи, a = уникальный
идентификатор статьи Команда POST Если рассылка разрешена, в качестве отклика присылается код 340, который указывает, что статью, предназначенную для рассылки, можно присылать. Код отклика 440 указывает, что рассылка запрещена по причинам, зависящим от инсталляции. Если рассылка разрешена, статья должна быть представлена в формате, описанном в RFC-850, и должна включать в себя все необходимые строки заголовка. После передачи заголовка и текста статьи от клиента к серверу последующий отклик будет свидетельствовать об успехе или неудаче доставки. Сервер не осуществляет какой-либо фильтрации текста, и он в неизмененном виде будет рассылаться. Отклики: 240 article posted ok Команда QUIT Сервер подтверждает получение команды QUIT и затем закрывает канал связи с клиентом. Эта команда предоставляет клиенту корректную возможность сообщить NNTP-серверу, что все операции завершены и сессия закончена. Если клиент просто разорвет связь, сервер должен также прекратить попытки взаимодействовать с клиентом.
Команда SLAVE Команда сообщает серверу, что он связывается не с пользователем, а с обслуживающим сервером (slave). Эта команда позволяет разделить случаи соединения сервера с отдельным пользователем и промежуточными обслуживающими серверами. Это может использоваться для предоставления приоритета запросам от таких клиентов, так как они обслуживают многих пользователей. Это может быть также использовано при возникновении проблем с внутренними ресурсами сервера, когда он может разорвать связи с некоторыми клиентами, сохраняя каналы с обслуживающими серверами. В NNTP-серверах, где приоритетное обслуживание не предусмотрено, команда должна все равно распознаваться и подтверждаться ее получение
Ниже приведены примеры (Примеры заимствованы из RFC-0977, Network News Transfer Protocol, B. Kantor, P.Lapsley. (Там их больше)) диалога между клиентом и сервером. Букве C: соответствует клиент, а букве S: - сервер. Пример 1 - относительный доступ с помощью команды NEXT
(Клиент запрашивает список текущих новостей)
(какая-то еще информация)
(Клиент выбирает группу новостей)
(В файле 104 статьи с 10011 по 10125) (Клиент выбирает статью для чтения)
only (article 10110 selected, its message-id is <23445@sdcsvax.ARPA>) (Клиент просматривает заголовок)
(Клиент хочет просмотреть текст статьи)
(Клиент хочет просмотреть следующую статью данной группы)
(Клиент завершает сессию)
Пример 2 - абсолютный доступ к статье с помощью команды ARTICLE
(Здесь 103 статьи с 402 по 504)
Пример 3 - Команда NEWGROUPS
(Клиент запрашивает группы новостей после 3-го апреля 1985)
(Нет статей в этой группе новостей, номера первой и последней статей следует игнорировать)
Пример 4 - рассылка новых статей
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.6.2 Язык HTML
UP:
4.5 Процедуры Интернет
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.7.1 Работа с сервером новостей
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
NETNEWS (или Usenet, RFC-1036) - всемирная система обмена сообщениями, использующая для этого единый формат. Сообщения рассортированы по темам, которые носят названия newsgroups (группы новостей). Эти сообщения имеют огромный суммарный объем и передаются от ЭВМ к ЭВМ. Они могут содержать текстовую или кодированную двоичную информацию. Сообщение имеет несколько строк заголовка, которые определяют, откуда пришло сообщение, через какие узлы поступило и т.д. Основные группы новостей, рассылаемые по всему миру, это: alt, comp, misc, news, rec, sci, soc и talk. Существует много других базовых категорий новостей, например, bionet, biz, vmsnet, которые рассылаются также повсеместно или в рамках какого-то региона или организации (например, ieee), а также коммерческие (например, clari). Последние категории рассылаются только ограниченно. Сообщения многих Bitnet LISTSERV серверов также рассылаются в виде новостей и относятся к категории bit. Наиболее важные группы новостей:
Базовые категории разбиваются на более чем 1200 групп новостей по различным вопросам и темам (от образования для инвалидов до Star Trek и от науки об окружающей среде до политики в странах бывшего Советского Союза). Качество дискуссий в этой среде не гарантируется. Некоторые группы имеют посредников, которые просматривают сообщения перед рассылкой. Usenet была разработана в 1979 году для системы UNIX. В настоящее время в сети новостей работает несколько тысяч узлов, охватывающих практически весь земной шар. Новости доступны как через локальный сервер, так и через телефонные коммутируемые сети. Программы для поддержки локального сервера новостей доступны в Интернет, UUCP, EARN/Bitnet и Fidonet. Если вам доступна только электронная почта, тогда для вас Usenet не доступна. Однако, многие группы новостей подключены к спискам почтовой рассылки и вы можете подписаться на них. Для этого шлите запрос в LISTSERV@AMERICAN.EDU со строкой: GET NETGATE GATELIST. Более того, многие документы, которые появляются в новостях, доступны по электронной почте в mail-server@rtfm.mit.edu. Для получения руководства по применению в поле subject напишите HELP. Команды (базовые), используемые при выборе групп новостей Основные команды
Начало чтения статей
Управление группами новостей
Отклик на статью
Сохранение статей
Ввод Unix-команд
Если Usenet доступен с вашего терминала, используйте один из многих программных пакетов, пригодных для чтения новостей. Эти пакеты используют либо доступ к местному серверу, либо работают на основе протокола доступа к новостям (NNTP Network News Transfer Protocol), осуществляя связь с другими ЭВМ сети. Рекомендуется прочесть брошюру "How to become a USENET site", которая посылается периодически в news.answers newsgroup. Она также доступна через анонимное FTP по адресу rtfm.mit.edu в каталоге /pub/usenet/news.answers/site-setup или по почте в mail-server@rtfm.mit.edu со строкой send usenet/news.answers/site-setup. Существует поддержка Usenet в самых разных операционных системах: Unix, VMS, MS-DOS, OS/2, Macintosh, MVS, а также в различных средах: MS-Windows, X-Windows, Windows-NT, Emacs. Имеются интерфейсы для системы USENET и для электронной почты. Многие, реально почти все, программные продукты обеспечивают следующие возможности:
Выбрав с помощью стрелки группу новостей и нажав клавишу <Enter>, вы получите оглавление статей в группе. Символ "+" указывает на то, что не все сообщения в цепочке были прочитаны. После выбора конкретной статьи вам будет предоставлено ее содержание. Когда вы введете TIN (программа просмотра новостей), вы получите список групп новостей, на которые вы подписались: tin 1.2 PL2 [UNIX] (c) Copyright 1991-93 Iain Lea. Reading newsgroups file... h=help
Приведем краткий перечень возможных команд, для выполнения которых достаточно нажать клавишу-символ, отмеченную правой круглой скобкой.
Если выбрать команду g (goto), то предоставляется возможность ввести имя группы новостей, которая вас интересует. Например, выберем группу comp.inforsystems.gopher: Goto newsgroup [comp.mail.misc]> comp.inforsystems.gopher (получаем новое меню, выбранная тема помечена стрелкой на левом поле) Group Selection (3658)
Нажимаем <Enter>> и входим в раздел comp.infosystems.gopher. Система выдает список имеющихся документов.
Выбираем сначала пункт 4. Там лежит сообщение: Does anyone have a list of sights through which one can access telnet by way of gopher? Thanks for any help. Sincerely, Monty Fuller Посмотрим следующее сообщение (пункт 5): Hi, I would like to invite everybody to visit our WWW shop of British fine tea from Williamson & Magor: Assam, Celebration Blend, Darjeeling, Earl Grey, English Breakfast, Lifeboat. Go to http://www.sswi.com/, and look under "Shopping Mall": Have a nice holiday. Web Master http://www.sswi.com/ (может быть интересно для любителей хорошего чая). В документе 3 найдем полезную информацию об адресе, где лежит список Gopher-серверов: I have found the IRD Gopher sites file to be a very useful tool for searching the Internet. For those of you who want to have a look, here is the download site: http://www.mbmarktcons.com/mbmarkt/irdhome.htm or via FTP from: ftp://ftp.mbmarktcons.com/pub/mbmarkt/ird/Fritz Вернувшись назад в предыдущее меню и выбрав позицию 1838 (comp.infosystems.wais), мы получим другой список документов: comp.infosystems.wais (19T 26A 0K 0H R)
Процесс этот почти беспределен..... Серверы новостей взаимодействуют друг с другом согласно стандартным протоколам, некоторые из которых описаны в Internet RFC. В настоящее время в этом списке имеются: RFC-977 описывает NNTP (Network News Transfer Protocol) RFC-1036 определяет формат статей Usenet. Некоторые группы новостей содержат статьи и дискуссионные материалы по использованию Usenet. Например: news.announce.newusers, news.answers и news.newusers.questions. Многие статьи, которые появляются в этих группах новостей доступны также с помощью анонимного FTP по адресу rtfm.mit.edu или по электронной почте по адресу: mail-server@rtfm.mit.edu. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.7 Протокол новостей NNTP
UP:
4.5 Процедуры Интернет
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
4.5.8 Поиск узлов и людей
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
Previous:
4.5.7.1 Работа с сервером новостей
UP:
4.5 Процедуры Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.8.1 Whois
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
WHOIS обеспечивает каталожную службу для пользователей сети (RFC-0954). Эта служба заключается в поиске e-mail адресов, почтовых адресов и телефонных номеров. WHOIS может поставлять информацию о сетях, о структуре доменов и т.д. Главная база данных, относящихся к сетям, поддерживается Регистрационной службой Интернет (InterNic). В действительности имена при регистрации доменов и при выдаче IP-адресов автоматически вводятся в базу данных. Каждая запись в базе имеет уникальный идентификатор (handle), имя, тип записи и ряд других полей в зависимости от типа записи. База данных поддерживается в каждой сети независимо и взаимодействие между ними не всегда существует. В системах UNIX имеется аналог этой службы - rwho, которая предоставляет даже несколько большую информацию, сообщая дополнительно о том, кто работает в данный момент в каждой из подключенных к сети машин. Сейчас создан новый протокол WHOIS++, в котором учтены прежние недостатки. WHOIS доступно для пользователей Интернет с помощью команды telnet. Возможна посылка запросов и по электронной почте. Обращение к базе данных производится по команде WHOIS (значение параметра заключается в угловые скобки). Обращение к местному клиент-серверу производится по форме: WHOIS <-h имя_сети> идентификатор Где имя_сети - адрес домена, куда вы собираетесь послать запрос (например, whois.internic.net); идентификатор - фамилия человека, название сети или домена, IP-адрес. С идентификатором могут использоваться специальные символы, определяющие тип поиска.
Эти символы могут использоваться и в комбинации. Результат поиска отображается либо в виде полного текста найденной записи, либо в виде списка строк, характеризующих найденные рекорды. В обоих случаях handle следует в скобках за именем. Для получения информации в интерактивном режиме используется telnet по адресу whois.internic.net (или whois.ripe.net). Далее прописные буквы обозначают приемлемые сокращения; опционные параметры помещаются в угловые скобки.
Можно использовать следующие ключевые слова:
Использование базы данных для получения списка лиц для коммерческих целей категорически запрещено (при выявлении расстрел на месте преступления :-)). Пример использования WHOIS. telnet wais.ripe.net RIPE Network Coordination Centre (NCC) Information Services Menu
Enter Selection: 4 (выбираем позицию 4 - WHOIS) Enter search key [q to quit]: msu.su. (Проводим поиск записей, относящихся к домену msu.su). Система выдает: domain: MSU.SU Еще один пример поиска в базе данных WHOIS, здесь задача решается с помощью команды, обращенной к серверу RIPE. Ищется информация об узле itep.ru: whois -h whois.ripe.net itep.ru (ЭВМ SUN): domain: ITEP.RU Существуют и другие программы для поиска информации о клиентах сети Internet (например, knowbot). Обращение к такой программе может быть выполнено, в частности, командой telnet nri.reston.va.us 185 (185 - номер порта). После входа в систему вы можете выдать запрос информации о возможностях системы поиска, напечатав ?, или просто выдав команду query vanja ivanov. Пользователи могут послать запрос через e-mail по адресу mailserv@internic.net. Команды записываются в поле subject. Текст сообщения обычно пуст, если subject не содержит команд, то интерпретируется первая строка текста сообщения. Запросы должны начинаться со слова WHOIS. Например: WHOIS \!EARN (\ представляет собой символ esc). Служба WHOIS документирована в RFC-1400. С любыми вопросами следует обращаться по адресу action@internic.net. Исчерпывающую информацию о WHOIS можно получить через анонимное FTP по адресам: nic.merit.edu /documents или sipb.mit.edu /pub/whois/whois-servers.list. Для этих же целей можно воспользоваться WWW: www.earn.net gnrt/whois.html или gopher: phantom.bsu.edu :4320/7whois%20rs.internic.net (число после двоеточия - номер порта). К материалам о WHOIS имеется доступ и с помощью telnet: rs.internic.net. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.8 Поиск узлов и людей
UP:
4.5.8 Поиск узлов и людей
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.8.2 FRED
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
FRED - система поиска информации о пользователях ЭВМ, сходная с WHOIS. Пользователи в архивах Интернет ("белые страницы", OSI X.500) идентифицируются уникальным образом, например: "@c=RU@o=Institute for Theoretical and Experimental Physics@cn=Director" Так как в системе WHOIS пользователи идентифицируются короткими ключами, содержащими, например, три символа, система FRED использует в процессе своей работы список цифровых псевдонимов. Доступ к системе осуществляется, напимер, командой: telnet wp.psi.net. В качестве имени-идентификатора нужно ввести слово FRED. После этого появляется приглашение FRED> и вы можете приступать к работе. Система имеет удобную систему команд, основная из которых whois имеет несколько модификаций:
whois "semenov" -area "@c=RU@o=Institute for Theoretical and Experimental Physics команда используется, когда название "area" (место) известно.
Сначала FRED считывает файл fredrc в системном каталоге ISODE (обычно /usr/etc/). Затем FRED читает файл .fredrc в каталоге пользователя. В этих файлах, если они присутствуют, содержатся описания предпочтений пользователя. После этого система выдает приглашение для ввода команд поиска. Команда INTR, выданная на базовом уровне, не вызывает никаких последствий, выдача ее дважды подряд вызовет завершение работы FRED (аналог QUIT). На других уровнях работы FRED команда INTR прерывает выполнение процедуры. Приведем перечень служебных команд.
Список системных переменных FRED представлен в таблице:
Вообще говоря синтаксис команды whois (FRED) аналогичен тому, что используется в системе WHOIS: входное_поле тип_записи признак_области_поиска управление_выводом Эти четыре компоненты могут встречаться в любом порядке и только входное_поле должно присутствовать обязательно. Это поле характеризует то, что вы желаете найти. Поле тип_записи говорит о том, какой вид записи в банке данных вас интересует. Поле признак_области_поиска может содержать ключи: -org (сокращение от "организация"); -unit или -locality, за которыми следует имя. Поле управление_выводом может содержать следующие ключи:
FRED имеет некоторые преимущества перед WHOIS и, возможно, вы предпочтете именно эту систему. Введем команду вызова сервера: telnet nic.switch.ch После установления связи сервер выдаст на экран: SWITCH (Swiss Academic and Research Network) SunOS UNIX (nic) (ttyp9) login: dua SWITCHdirectory main menu (choose desired service)
Выберем пункт 1 (с другими видами сервиса читателям предлагается познакомиться самостоятельно): SWITCHdirectory User Interfaces
Выбираем пункт 2 и получаем: invoking interface "fred", please wait....
CERN CH-1211 Geneve 23 FAX: +41 22 767 6555 Mailbox information: X.400: /S=postmaster/O=CERN/PRMD=CERN/ADMD=ARCOM/C=CH/ High Energy Physics research 20 imprecise matches for '*', select from them [y/n] ? y После ряда ответов на вопросы (Y/N) получаем: 7 matches found.
Теперь посмотрим, что имеется в Германии (код=DE), для этого введем команду: whois -org * -geo @c=DE. 100 matches found. (найдено 100 записей)
Список, разумеется, напечатан в сокращенном виде. fred> q (до свидания FRED!). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.8.1 Whois
UP:
4.5.8 Поиск узлов и людей
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.8.3 X500
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
X.500 представляет собой протокол OSI для распределенных каталогов (индексов-оглавлений), разработанный CCITT. X.500 - протокол для работы с каталогами. X.500 предлагает распределенный каталог пользователей сети Интернет. X.500 поддерживает систему просмотра, а также добавления, модификации и удаления объектов в базе данных о людях (почтовый адрес, номер телефона, электронный адрес и пр.). Основным полем при поиске является фамилия, название организации, отдела, страны. Треугольные скобки служат для выделения имени параметра, а вертикальная черта - для указания значения параметра. Каждая секция каталога содержит часть глобальной базы данных и является доступной через сервер (именуемый Directory System Agent - DSA). Каждая база данных поддерживается локально. Для пользователя же доступна вся база данных. Хотя информация, доступная через X.500, относится к людям и организациям, данная база пригодна для хранения и другой информации, например, о ресурсах сети, приложениях или оборудовании. Каждый вход в базу (объект хранения, запись) в X.500 описывает один объект (человека, конкретный ресурс сети, или организацию) и носит название Distinguished Name (неповторимый идентификатор). Это имя включает в себя следующие поля: фамилия, имя, организация, e-mail для людей. Информация в каталоге X.500 (Directory Information Base - DIB) организована иерархически и носит название информационное дерево каталога (Directory Information Tree - DIT). На верхнем уровне - корневая запись (the World), затем следует уровень страны, уровень организации и, наконец, человека (ресурса и т.д.). X.500 доступна через локальный сервер, интерактивно через telnet или через электронную почту (или X.25). Возможен доступ и с помощью WWW или GOPHER. Таблица 4.5.8.3.1
Локальный клиент-серверы (Directory User Agent - DUA) имеются в общедоступном и коммерческом вариантах. Для получения более полного списка DUA, их описаний и места расположения рекомендуется обратиться к RFC 1292 / FYI 11 - "A Catalog of Available X.500 Implementations". Существует три варианта интерфейсов для доступа к X.500 в интерактивном режиме:
Сервер de (directory enquiries) рекомендуется в силу своей простоты для начинающих пользователей. Выход из de по команде q. Приведем перечень команд X.500.
После выдачи команды de пользователь должен заполнить четыре поля запроса (поиск не зависит от строчных или заглавных букв):
Чтобы осуществить поиск с использованием электронной почты, следует послать запрос по адресу directory@uninett.no со словом find в поле Subject. В тексте сообщения размещается запрос (один на один e-mail) в форме: find <фамилия> <:название организации <;название страны>> | <;название страны> Если название организации и страны опущены, то берутся значения по умолчанию, которые извлекаются из вашего электронного адреса. Результат поиска будет прислан по электронной почте. Для получения файла help напечатайте help вместо find. Хотя использование e-mail кажется архаичным, в некоторых случаях не слишком экстренных оно оправдано. Вы посылаете запрос и не ждете отклика в интерактивном режиме. Примеры использования X.500. Введем команду: telnet nic.switch.ch и система свяжется с сервером: Trying 130.59.1.40 ... (IP-адрес сервера) SWITCHdirectory User Interfaces
Снова вводим 1 (WHOIS-сервер) и получаем на экране: invoking interface "de", please wait....
At any prompt:
Simple query mode selected Поищем "любые организации, известные в России", введя * в ответ на вопрос организации. Получаем: Department name, <CR> to search, * to list, ? for help Russian Federation Не много, но все же..... (пример относится к 1994 году) Печатаем 2 и получаем: Russian Federation
Для получения дополнительной информации рекомендуется прочесть RFC-1292 (доступные реализации X.500), RFC-1308 (Введение в службу каталогов, использующую протокол X.500) и RFC-1309 (технический обзор по протоколу X.500). Рекомендации по использованию X.500 можно получить, послав команду GET ITU-5233 по адресу itudoc@itu.ch. (объем документа весьма велик!). Их других источников можно упомянуть: FTP nic.merit.edu documents/fyi/fyi_13.txt (fyi_11.txt, fyi_14.txt). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.8.2 FRED
UP:
4.5.8 Поиск узлов и людей
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.8.4 Система поиска NETFIND
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
NETFIND представляет собой прикладную программу для работы со справочниками и каталогами. Получив имя человека и некоторые данные о том, где он работает, NETFIND пытается найти его номер телефона, электронный адрес, используя базу данных доменов seed. NETFIND ищет информацию о людях с помощью Интернет-протоколов SMTP и finger. Netfind работает на ЭВМ SUN OS 4.0 или более новых. Могут быть найдены только лица, имеющие доступ к Интернет. Существует возможность работы с NETFIND через электронную почту. Доступ через telnet возможна по адресам (login: netfind):
Место работы искомого человека может быть описано ключевыми словами. NETFIND просматривает свою базу данных seed, чтобы найти домен, отвечающий критериям отбора. Список таких доменов отображается и вам предлагается выбрать из них 1-3. Если обнаружено более 100 доменов, NETFIND выдаст имена некоторых из них и предложит повторить поиск с более жесткими условиями. Можно использовать часть названия организации или домена в качестве эталона в процессе поиска. При использовании более чем одного эталона можно применить знак логической операции AND. По завершении поиска или при прерывании его с помощью ^C NETFIND выдает полученный результат. Предлагаются не только данные о домене или организации, но и даты последних входов искомого человека в систему. Обращение к NETFIND имеет формат: netfind <опции> фамилия (имя) место работы (ключевые слова) где допустимы следующие опции:
Существуют следующие классы/буквы:
Обычным пользователям наиболее интересны буквы f, m, и n. По умолчанию работают именно эти функции. -d команда инвертирует текущее значение опции, поэтому использование этих трех команд под знаком -d, заблокирует их работу. В качестве имени можно применить фамилию, имя или ID. При выдаче имени домена или ЭВМ можно выдавать эту информацию без разделительных точек, например, cs colorado edu. NETFIND для входа не требует каких-либо слов-паролей, кроме NETFIND. Воспользуемся услугами сервера nic.uakom.sk:
UAKOM UMB
Help choices: (Справочное меню)
Система выдает запрошенную справочную информацию (ниже приведен сокращенный перевод): По имени и приблизительному описанию места работы Netfind пытается найти информацию о данном лице. В качестве имени может быть введена фамилия или имя. Одновременно могут быть выданы ключевые слова: место работы, имя домена, город или страна. Найдя домен, Netfind отображает список доменов и просит вас выбрать от одного до трех из них, где следует провести поиск. Поиск проходит в два этапа. На первом - Netfind выполняет поиск в каждом из выбранных доменов. На втором этапе проводится более детальное исследование с помощью finger. Имеется возможность прервать поиск с помощью ^C. По завершении знакомства со справочной информации система возвращается к базовому меню. На этот раз выбираем пункт 2 (Поиск). Система выдает предупреждение:
Предлагается ввести имя и ключевые слова. Enter person and keys (blank to exit) --> Burov DESY Germany
Enter selection (e.g., 2 0 1)--> 2 0 1 Mail for Sergei Bourov is forwarded to burov@x4u2.desy.de Поиск завершился успехом - найден адрес, куда пересылается почта для Бурова, далее на экран выводится следующий текст: NOTE: this is a domain mail forwarding arrangement to an outside domain, possibly indicating that "burov" has moved to another department or institution. Hence, mail should be addressed to "burov@x4u2.desy.de" (почта должна посылаться Бурову по адресу). ( 1) SMTP_Finger_Search: checking host x4u2.desy.de SYSTEM: x4u2.desy.de
Directory: /home/dice/burov Shell: /bin/zsh FINGER SUMMARY (результат исследования с помощью Finger): - Remote user queries (finger) were not supported on host(s) searched in the domain 'dsyibm.desy.de'. При удаленном доступе к NETFIND имеется служба HELP. В секции каталога DOC обычно имеется также файл "часто задаваемые вопросы" (frequently asked questions - FAQ). Большую пользу может оказать статья "Experience with a Semantically Cognizant Internet White Pages Directory Tool", написанная M.F.Schwartz и P.G.Tsirigotis, Journal of Internetworking Research and Experience, март 1991, стр. 23-50. Существует список адресов подписчиков NETFIND. Для включения вас в этот список необходимо послать запрос по адресу netfind-users-request@cs.colorado.edu, где в тексте сообщения (не в строке subject!) написать: subscribe netfind-users. Исчерпывающую информацию о NETFIND можно найти посредством: FTP ftp.cs.colorado.edu /pub/cs/distribs/netfind |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.8.3 X500
UP:
4.5.8 Поиск узлов и людей
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||
|
4.5.9 Серверы подписки (LISTSERV)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||
|
LISTSERV - система обслуживания и управления списками адресов электронной почты. Она работает в рамках SUN/UNIX, LINUX и др., в интернациональной сети NJE (EARN/Bitnet) и Интернет. Она позволяет группам пользователей, объединенных общим интересом общаться между собой, обеспечивая эффективное использование ресурсов сети. Система дает возможность пользователю найти интересующую его группу, присоединиться к ней и активно участвовать в ее функционировании. LISTSERV управляет почтовым трафиком, осуществляет поиск архивов и файлов. Спектр тем ничем не ограничен, число рубрик превышает 3000. Доступ к LISTSERV может получить всякий пользователь, кто может посылать электронные сообщения по адресам EARN/Bitnet (в соответствии со стандартом RFC-822) и имеет пригодный к использованию адрес. Отличие от обычной электронной почты заключается в том, здесь вы можете обратиться не только к тем партнерам, адреса которых вы знаете, но и к тем о существовании которых и не подозреваете. Однажды по работе мне потребовалась информация по ультрафиолетовой дозиметрии, я послал запрос в один из серверов и в течение суток получил 6 ответов из США, Канады и Новой Зеландии (среди них Stephan Straus stephen@unicaat.yorku.ca, Martin Brown brauwnma@ucs.oust.edu). Неизвестные мне доселе люди снабдили меня необходимыми данными, указали адреса, где можно найти дополнительную информацию, прислали списки библиографии. Обратите внимание, чтобы однозначно определить, кого я имею в виду, достаточно указать электронный адрес. Для того, чтобы наладить контакт с LISTSERV нужно послать запрос по адресу: LISTSERV@host-id, где host-id NJE-адрес ЭВМ (например, TAUNIVM.BITNET) или имя INTERNET-домена (в этом случае, VM.TAU.AC.IL). Серверу LISTSERV можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Возможно взаимодействие с LISTSERV и в интерактивном режиме. Для облегчения связи с сервером необходимо определить узловую ЭВМ в сети EARN/Bitnet. Пользователи вне сети EARN/Bitnet могут посылать свои запросы по адресу LISTSERV.NET. Заметьте, что если этот узел еще не определен для вашей сети, вы можете попробовать работать на LISTSERV%LISTSERV.BITNET@CUNYVM.CUNY.EDU. Вы можете также использовать специальный LISTSERV-адрес, чтобы послать e-mail в любой LISTSERV-список. Например, если вы хотите послать электронное сообщение в список BITFTP-L для того, чтобы получить копию программы BITFTP, вы можете сделать это, послав сообщение по адресу BITFTP-L@LISTSERV.NET. Ваше сообщение будет автоматически переадресовано по реальному адресу (в данном случае BITFTP-L@EARNCC.BITNET), когда оно попадет в узел LISTSERV. Существует (на конец 1994 года) более 250 узлов в более чем 30 странах мира, где работают серверы LISTSERV. Вот некоторые из них:
Ниже описаны наиболее часто используемые команды. Для получения полного списка команд извлеките LISTSERV User Guide из списка DOC FILELIST по адресу LISTSERV@EARNCC.BITNET. Команды имеют следующий формат: заглавные буквы указывают на возможное сокращение, угловые скобки выделяют опционный параметр, а вертикальная черта отмечает значение этого параметра. Существует стандартный набор параметров ключевых слов, которые могут использоваться совместно с командами в качестве параметров. Важными ключевыми словами являются: PW=пароль - это ключевое слово служит для описания слова-пароля. Если вы завели слово-пароль для данного LISTSERV-сервера, вы должны в дальнейшем записывать в командном тексте строку PW=, чтобы ваши команды были выполнены. Эта функция создана, чтобы блокировать возможность исполнения команд, используя ваш электронный адрес. Если вы зарегистрировали ваш пароль в сервере LISTSERV, вы обязаны включать PW= во все команды, где это требуется по описанию. F=формат - это ключевое слово управляет форматом файла (или внутренней структурой файла), в котором он будет вам послан. Если вы не являетесь членом EARN/Bitnet, то LISTSERV будет всегда использовать формат MAIL. В противном случае формат файла зависит от информации, которая содержится в BITEARN NODES файле вашей ЭВМ. BITEARN NODES файл - это специальный файл описания сетей, используемый в EARN/Bitnet сетях. Любой пользователь может затребовать формат, отличный от описанного по умолчанию, посредством F=командное_ключевое_слово в командах, где это требуется опционно. Допустимы следующие форматы файлов: XXE UUe MIME/text MIME/Appl MAIL Первичной задачей LISTSERV является обслуживание списков электронных адресов (списки для рассылки). Эти списки используются, чтобы пересылать сообщения подписчикам. Таким образом, создаются форумы для обмена идеями и информацией по темам, интересующим подписчиков. Пользователю достаточно помнить только один адрес (адрес сервера), чтобы взаимодействовать с большим числом лиц, имеющим сходные интересы. Обсуждения или дебаты при этом могут иметь всемирный характер. В рамках LISTSERV почтового списка могут использоваться следующие команды, которые служат для поиска нужного списка и адреса соответствующего сервера, для подписки или ее отмены и т.д. SUBscribe имя_списка <полное_имя> Эта команда служит для включения подписчика в список для рассылки. Вы можете использовать эту команду для изменения имени (но не электронного адреса), под которым вы уже известны в списке. имя_списка - это наименование списка, на который вы хотите подписаться. Например, EARN User Group список, находящийся в узле IRLEARN, имеет имя EARN-UG. Не следует путать имя списка с адресом сервера (EARN-UG@IRLEARN). Опционный параметр полное_имя позволяет вам выдать имя, под которым вы хотите фигурировать в списке (это может быть псевдоним). При посылке этой команды в LISTSERV по e-mail полное имя будет взято из поля From:. При посылке этой команды в сервер, где вы уже подписаны, это будет воспринято, как требование об изменении полного имени. Запрос о присоединении к подписному листу может быть обработан тремя путями: подписка может быть OPEN, CLOSED или BY-OWNER. Если это OPEN, вы будете автоматически добавлены в список и получите подтверждение этого. Если это CLOSED, вы будете вычеркнуты из списка рассылки. Если вас там не было, вы получите уведомление о том, что запрос не выполнен. Если же это BY-OWNER, ваш запрос будет переадресован собственнику списка, кто и решит добавлять вас к списку или нет. Адрес, куда будет переправлен ваш запрос, вам будет прислан. Для того, чтобы быть исключенным из списка посылайте команду: UNSubscribe имя_списка | * <(NETWIDE> Наличие круглой скобки только слева не является опечаткой. Для того, чтобы ликвидировать подписку по всем спискам LISTSERV, можете использовать "*" вместо имени списка. Если вы хотите, чтобы ваш запрос был передан всем серверам сети, используйте команду (NETWIDE. Эта версия команды рекомендуется при смене вашего электронного адреса или при длительном отпуске. Для получения списка имеющихся списков в сервере LISTSERV используйте команду List. List <option> <F=формат> Параметр option может принимать следующие значения: Short Отображается резюме всех списков, контролируемых LISTSERV, по одной строке на список. Эта версия реализуется по умолчанию; Long (детально) пересылает вам файл (называемый node-name LISTS), содержащий исчерпывающие описания всех списков, поддерживаемых сервером. Global <эталон> Выдается полный список всех известных почтовых списков LISTSERV на текущий момент. Этот файл имеет имя LISTSERV LISTS и содержит имена, заголовки и e-mail адреса этих списков. Это очень большой файл, поэтому следует проверить, есть ли у вас достаточно места на диске, прежде чем использовать опцию Global. Опционный параметр эталон может использоваться для того, чтобы выбрать имя списка, заголовок или список адресов. Для получения листинга почтовых списков используется команда REView. Формат команды: REView имя_списка <(> <option> Листинг будет вам переслан в виде файла с именем list-name LIST (или list-name node-name). Почтовый список состоит из двух частей: управляющая секция и подписная секция. Управляющая секция содержит параметры списка, которые включают в себя информацию о том, кто решает вопросы включения в список или его пересмотра, а также архивации. Подписная секция содержит e-mail адреса и имена всех членов списка. REView-команда позволяет вам получить листинг любой или обеих этих секций (по умолчанию - обеих) для любого из списков. Следует иметь в виду, что по решению владельца списка командой REView может выдаваться только список членов этого списка. В этом случае вам не будет позволено просматривать список e-mail адресов, если вы не член списка. Члены списка могут ограничить доступ к своему e-mail адресу по команде REView, если они установили опцию CANCEL. имя_списка - имя LISTSERV-списка, который вы хотите просмотреть. К важным опциям команды REView относятся: Short Получаемая информация ограничивается управляющей секцией (только параметры списка). Countries Выдается перечень членов списка упорядоченный с учетом национальной принадлежности. LOCal Если список имеет пару (соединен с другим списком того же имени, обслуживаемым другим сервером), вы получите полный листинг в отклик на команду REView. Опция LOCal может использоваться для подавления распространения действия команды REView на другие серверы. В этом случае вы получите листинг только от сервера, куда вы послали запрос. При подключении к какому-либо списку, вам будет поставлен в соответствие перечень параметров по умолчанию. Эти параметры могут быть вами изменены для любого из списков, где вы являетесь подписчиком. Команда Query позволяет просмотреть текущие значения параметров (опций) для любого списка. Формат команды: Query имя_списка | * Параметр имя_списка представляет собой наименование списка, на который вы подписались. Если вы используете символ "*" вместо имени списка, вы получите информацию о ваших личных параметрах для всех списков, на которые вы подписаны. Для изменения параметров вашей подписки используется команда SET. Она имеет формат: SET имя_списка | * options После выполнения команды SET сервер пришлет вам подтверждение успешного изменения параметра по электронной почте. Важными опциями команды SET являются: Mail | DIGests | INDex | NOMail Эти опции варьируют способ, которым вы получаете сообщения. Mail означает, что вы хотите получать сообщения по электронной почте (значение по умолчанию). DIGests и INDex доступны только в случае, если они разрешены собственником списка. DIGests сохраняет все сообщения посланные в список в течении определенного времени. Вместо того, чтобы получать сообщения одно за другим вы получите их единым кластером в определенный день недели или месяца. Обратите внимание, DIGests не редактирует почту и вы получите все сообщения. INDex передаст вам только дату, время, предмет, число строк, имя отправителя и адреса всех сообщений, посланных в список. Текст сообщений передан не будет. Вы можете выбрать и извлечь заинтересовавшие вас сообщения. NoMail означает, что вам не будут пересылаться сообщения. Это полезно при длительной командировке или отпуске. Вернувшись, вы можете послать команду SET c опцией Mail и возобновить присылку сообщений. Предусмотрена возможность изменения формата заголовков почтовых сообщений. SHORThdr | FULLhdr | IETFhdr | DUALhdr Все почтовые сообщения состоят из секции заголовка и тела сообщения. Заголовок содержит информацию об отправителе, получателе, дате и времени отправки. Перечисленные выше опции команды SET указывают на тип заголовка почтового сообщения, который вы хотите иметь. SHORThdr означает, что заголовок сообщения будет содержать только самую существенную информацию (например, Date:, To:, From:, Subject:, и Replay-to: поля). Этот вариант работает по умолчанию. Вы можете изменить это, используя опцию FULLhdr, которая означает, что все (даже не существенные) поля заголовка будут присутствовать в почтовом сообщении. Опция IETFhdr означает, что LISTSERV не изменит заголовок, за исключением того, что добавит в заголовок Received: (а также Message-id: и Sender:, если их там не было). Эта опция введена для обеспечения совместимости с SMTP. Наконец DUALhdr очень похожа на SHORThdr за исключением того, что LISTSERV введет заголовок в начало тела сообщения. Следовательно, когда сообщение получено и читается получателем с этой опцией, оно начнется с этой информации (например, первые три строки сообщения могут содержать To:. From:, и Subject). Эта опция удобна для таких почтовых пакетов на PC, где эта информация не отображается. CONCEAL | NOCONCEAL указывает на то, хотите вы или нет, чтобы ваше имя и почтовый адрес появлялся в ответ на команду REView, выданную одним из подписчиков списка. По умолчанию работает NONCONCEAL. Обратите внимание, что полный список подписчиков доступен владельцу списка и администратору LISTSERV, вне зависимости от установки этой опции. Для возобновления вашей подписки необходимо выдать команду COMFIRM. Формат команды: CONFIRM имя_списка Некоторые подписные листы требуют регулярного подтверждения подписки (обычно раз в год). Система автоматически напоминает пользователям, что они должны подтвердить свою подписку, т.е. они должны послать команду CONFIRM в течение заданного числа дней. В противном случае клиент будет вычеркнут из списка. Эта команда должна быть послана с того же адреса, по которому было послано напоминание. LISTSERV присылает подтверждение получения команды CONFIRM. LISTSERV может работать также и как файл-сервер. Поэтому сервер может запоминать файлы и обеспечивать к ним доступ по запросам. Эти файлы запоминаются в рамках иерархической системы filelists. Как и предполагает его название filelist представляет собой специальный файл, который содержит список файлов. Каждая запись в filelist описывает файл, который можно затребовать, давая информацию о его имени, размере, а также коде доступа (File Access Code), который описывает, кто имеет доступ к нему. Эти файлы сами могут быть списками файлов. Таким образом, эта файловая система имеет древовидную структуру. На LISTSERV существует два вида файлов-списков. Первый тип содержит файлы, которые помещены туда специально хозяином списка или его администратором. Это могут быть документы, карты, диаграммы или даже программы. Файлы-списки второго вида ассоциированы со списком адресов LISTSERV. Это списки файлов-списков, они состоят из серии файлов, каждый из которых хранит (обычно до месяца) копию сообщения, которое было ранее разослано. При желании в течение определенного времени эти файлы могут быть скопированы любым подписчиком. LISTSERV может компоновать один или более файлов в пакет и в таком виде рассылать подписчикам. Это могут быть, например, файлы, необходимые для генерации определенной программы. Пакет декларируется в LISTSERV-filelist через файл, который именуется packet-name $PACKEGE. В нем хранятся описания всех файлов, которые представляют собой пакеты. Любой файл, представляющий собой пакет, может быть извлечен из хранилища с помощью запроса: packet-name PACKAGE. Обратите внимание, что в этом случае символ $ в имени опущен. Таким образом, одна команда позволяет извлечь из депозитария сразу несколько файлов, входящих в пакет. Некоторые команды позволяют пользователю манипулировать файлами, которые хранятся в депозитарии LISTSERV. Сюда входят команды подписки и извлечения файлов. При посылке команд файл-серверу вы должны адресовать их именно серверу, а не какому-либо почтовому списку. Используйте команду INDex для получения списка файлов из определенного filelist. Формат команды: INDex <список_файлов> <F=формат> Параметр список_файлов определяет имя списка, который вас интересует. Если не указано ни какого имени, вам будет прислан индекс корневого списка файлов (именуемого LISTSERV FILELIST). Команда GET используется для извлечения какого-то определенного файла или пакета файлов из списка файлов, если вам разрешено это делать. Формат команды: GET имя_файла тип_файла <список_файлов> <F=формат> Параметры имя_файла и тип_файла описывают файл или пакет файлов, который вы хотите получить. Параметр список_файлов определяет список файлов или пакетов, где лежит искомый файл. Если этот параметр не указан, LISTSERV будет определять его путем поиска в собственном индексе, что задержит выполнение запроса. Для подписки на файлы или пакеты из определенного списка следует использовать команду AFD (Automatic File Distribution). Формат команды: AFD options Каждый раз, когда данный список или конкретный файл актуализуется (изменяется), вам будет выслана сервером его копия. Число файлов или пакетов, на которые вы подписаны, не лимитировано. Вы можете в любой момент просмотреть перечень подписки и ликвидировать ее частично или полностью. Параметр options команды AFD может принимать одно из следующих значений: ADD имя_файла тип_файла <список_файлов> <текст> <F=формат> <PW=password> Опция ADD позволяет вам подписаться на файл или пакет, имя_файла и тип_файла характеризует при этом имя и тип файла, на который вы подписались. Если вы хотите, чтобы автоматически в начало каждого присылаемого файла или пакета добавлялся некоторый текст, используйте параметр текст. Если вы пропускаете параметр список_файлов, то параметр текст должен быть помещен в кавычки. DELete filename filetype <filelist> <PW=password> Эта опция служит для аннулирования подписки, имена могут содержать символы * (wildcard). Опция List показывает файлы или пакеты, на которые вы в данный момент подписаны. Формат опции: List <(FORMAT> Если вы включите опцию (FORMAT, то будет отображен и формат, в котором вам будет присылаться файлы или пакеты. Еще одна команда, которая позволяет осуществить подписку на файлы и пакеты, носит название FUI (File Update Information). Ее формат: FUI options Эта команда аналогична AFD за исключением того, что вы в данном случае получаете сообщение об изменении файла или пакета, а не его новую копию. Эта команда допускает следующие опции: ADD имя_файла тип_файла <список_файлов> <PW=пароль> Аналог ADD для команды AFD за исключением параметров формат и текст. Опция DELete является полным аналогом одноименной опции команды AFD: Для получения информации об актуализации файлов или пакетов удобна команда Query File. Параметр список_файлов может быть опущен. Формат команды: Query File имя_файла тип_файла <список_файлов> <(FLags> Вы можете задать параметр (Flags, который позволит администрации LISTSERV получить дополнительную техническую информацию о файле, полезную при описании проблем, с которыми вы столкнулись. Команда PW позволяет вам добавить, изменить или ликвидировать ваше персональное слово-пароль. Команда имеет следующий формат: PW options Слово-пароль блокирует возможность несанкционированного использования вашего электронного адреса. Настоятельно рекомендуется воспользоваться этой возможностью. Запрос на регистрацию слова-пароля может быть воспринят в любое время, аналогично оно может быть изменено и аннулировано также, когда вы захотите. Слово-пароль может включать в себя от одного до 8 алфавитно-цифровых символов. Среди опций этой команды могут быть: ADD new-password Добавляет новое слово-пароль. Если вы зарегистрировали свое слово-пароль, вы обязаны впредь его использовать всюду (вводить командное ключевое слово PW=), где это требуется опционно. CHange old-password new-password Изменяет ваше старое слово-пароль на новое. DELete old-password Удаляет ваше слово-пароль из сервера, если вы уже имели его. После этого вы уже не обязаны вводить впредь командное ключевое слово PW=. Функции LISTSERV DATABASE LISTSERV позволяет пользователям извлекать старые почтовые сообщения, которые рассылались по списку какое-то время назад. Каждый почтовый список имеет ассоциированную базу данных (обычно называемую notebook или база данных list archive), в которую производится запись рассылаемых сообщений. Такая возможность зависит от хозяина списка и присутствует не всегда. Практически каждый сервер имеет базу данных по узловым ЭВМ сети EARN/Bitnet, которая называется BITEARN. Эта база доступна для всех пользователей. Базовые серверы имеют также базы данных по всем узловым ЭВМ LISTSERV (база имеет название PEERS). Для того, чтобы определить, какие базы данных доступны на данном сервере выдайте команду DATABASE LIST. Для выполнения поиска в базе данных вы можете послать e-mail в LISTSERV c соответствующим запросом в базу данных. Кроме того, пользователи EARN/Bitnet на VM или VMS системах имеют интерактивный доступ к базам данных через программу LDBASE. Для получения более детальной информации пошлите команду Info DATABASE на ближайший сервер. LISTSERV может выдать пользователю много и другой информации: статистика запросов, справочные и конфигурационные файлы и пр. При запросе этой информации следует адресоваться к серверам, а не к какому-либо списку. К числу команд, помогающих извлечь вспомогательную информацию, относится HELP. В ответ на эту команду вы получите по электронной почте описание наиболее употребимых команд LISTSERV, а также имя сервер-почтмейстера и его электронный адрес. Для получения help-файла из LISTSERV можно выдать команду Info, которая имеет формат: INFO <тема> <F=формат> Опция тема должна характеризовать тематику файла, который вы получите в ответ. Если вы пошлете запрос в ближайший (или любой) LISTSERV без указания темы, то получите список возможных тем запросов. Допустим вы хотите подписаться на список EARNEWS, который находится в узле FRMOP11. Ваше полное имя Yuri A. Semenov. Пошлите следующую команду по адресу LISTSERV@FRMOP11.BITNET: SUBSCRIBE EARNEWS Yuri A. Semenov Если вы хотите покинуть INFO-MAC список, где вы были подписчиком ранее, в узле CEARN, выдайте команду: UNSUBSCRIBE INFO-MAC которая должна быть послана серверу LISTSERV в CEARN, который управляет списком INFO_MAC. Для того чтобы покинуть все списки LISTSERV, пошлите команду в ближайший сервер LISTSERV: UNSUBSCRIBE * (NETWIDE Если вы хотите получить полный список всех списков рассылки, которые в своем названии содержат слово Europe. Пошлите следующую команду ближайшему серверу LISTSERV: LIST GLOBAL EUROPE Вы хотите прекратить получение сообщений из всех списков SEARN, где вы состоите подписчиком. Пошлите серверу LISTSERV в SEARN команду: SET * NOMAIL Предположим, что вы получили сообщение от сервера LISTSERV в IRLEARN с просьбой подтвердить вашу подписку на список EARN-UG и вы согласны это сделать. Пошлите серверу команду: CONFIRM EARN-UG Если вы хотите получить листинг файлов в DOC FILELIST, то следует послать команду INDEX DOC в LISTSERV-сервер EARNCC, где расположен этот список. Эта команда эквивалентна команде GET DOC FILELIST. Допустим, вы хотите получить файл PCPROG ZIP из списка файлов в формате XXE. Пошлите команду серверу, где размещен этот файл: GET PCPROG ZIP F=XXE Предположим, что вы хотите извлечь все файлы, которые образуют пакет под названием PROGRAM (как видно из файла с названием PROGRAM $PACKAGE) из списка файлов SAMPLE. Пошлите команду: GET PROGRAM PACKAGE SAMPLE Если вы хотите подписаться на файл под названием BUDGET MEMO в списке файлов EXPENSES с помощью AFD, тогда воспользуйтесь командой: AFD ADD BUDGET MEMO EXPENSES Чтобы подписаться на файл с названием VM EMAIL в DOC FILELIST с помощью FUI, вам следует послать следующую команду в LISTSERV узла EARNCC: FUI ADD VM EMAIL DOC Ниже приведен пример реализации LIST-сервера, который использован для обмена информацией о московском опорном магистрали (LIST-сервер "FBONE-OP"). LIST-сервер "FBONE-OP" - система обслуживания и управления списком адресов электронной почты. Она позволяет группам ученых, пользующихся услугами южной части московской оптоволоконной магистрали, общаться между собой. Доступ к серверу может получить всякий пользователь, который имеет доступ к электронной почте. Система реализована на версии Majordomo. Это разработка Brent Chapman'а, версия 1.93. В описании, приведенном ниже параметры, которые помещены в ] являются опционными. Если вы задаете эти параметры, не помещайте их в [ ]. Для того, чтобы наладить контакт с сервером нужно послать запрос по адресу: FBONE-OP-REQUEST@ITEP.RU. Серверу можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Ниже описаны наиболее часто используемые команды. Команды имеют следующий формат: прописные буквы указывают на возможное сокращение, угловые скобки выделяют опционный параметр, а вертикальная черта отмечает значение этого параметра. Существует стандартный набор параметров ключевых слов, которые могут использоваться совместно с командами в качестве параметров. При работе с LIST-сервером помимо уже описанных (subscribe, unsubscribe, get и index) могут использоваться следующие команды: which [<address>] Определить, на какой из списков вы подписаны (или адресат <address>). who [<list>] Определить список подписчиков <list>. info [<list>] Выдать общую вводную информацию для указанного списка <list>. lists Отображает список списков, которые обслуживаются Majordomo-сервером. end Блокирует дальнейшую обработку команд (полезно, если вы используете "подпись" в вашей почтовой программе). Команды должны записываться в тело почтового сообщения (а не в поле Subject) FBONE-OP@ITEP.Ru или FBONE-OP-REQUEST@ITEP.Ru. В ответ на запрос subscribe вы получите отклик вида: Received: by ns.itep.ru id AA03442 (5.67a8/IDA-1.5 for semenov); Sun, 26 Feb 1995 12:29:44 +0300 Параметр <list> является опционным, если запрос послан по адресу "<list>-request@ITEP.Ru". В ответ на запрос who сервер выдаст: From maillist Sun Feb 26 15:46:16 1995 Received: by ns.itep.ru id AA07983 При работе c подписными листами следует прежде всего думать о партнерах по списку. Это занятые люди, поэтому для всеобщего внимания следует выносить лаконичные сообщения, представляющие всеобщий интерес. Частные сообщения лучше посылать только тому, или тем, адресатам, которым это важно знать. Детальная документация по LISTSERV и связанных с ним услуг доступна в DOC FILELIST по адресу LISTSERV@EARNCC.BITNET. Сюда входит LISTSERV User Guide, который доступен в обычном и postscript форматах. Для получения списка доступной документации используйте команду INDex. Существует несколько списков для обсуждения технических вопросов LISTSERV. Они не предназначены для обычных пользователей, но и не закрыты для них. Это: LSTSRV-L технический форум LISTSERV. |
|||||||||||||||||||||
|
Previous:
4.5.8.4 Система поиска NETFIND
UP:
4.5.8 Поиск узлов и людей
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.10 Электронная почта
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Электронная почта - наиболее популярный и быстро развивающийся вид общения. Широко используются протоколы электронной почты UUCP (unix-to-unix copy protocol, RFC-976) и SMTP (simple mail transfer protocol; RFC-821, -822, -1351, -1352). Один из протоколов (RFC-822) определяет формат почтовых сообщений, второй (RFC-821) управляет их пересылкой. Имея механизмы промежуточного хранения почты (spooling) и механизмы повышения надежности доставки, протокол smtp базируется на TCP-протоколе в качестве транспортного и допускает использование различных транспортных сред. Он может доставлять сообщения даже в сети, не поддерживающие протоколы TCP/IP. Протокол SMTP обеспечивает как транспортировку сообщений одному получателю, так и размножение нескольких копий сообщения для передачи по разным адресам. Обычно в любом узле Интернет имеется почтовый сервер (MX), который принимает все сообщения и устанавливает их в очередь. Далее производится раскладка сообщений по почтовым ящикам ЭВМ пользователей. Если какая-то ЭВМ не включена, сервер попытается доставить почту позднее (например, через 30 мин). После заданного числа неудачных попыток или по истечении определенного времени (> 4-5 дней) сообщение может быть утрачено. При этом отправитель должен получить уведомление об этом. Над SMTP располагается почтовая служба конкретных вычислительных систем (например, POP3(RFC-1460), IMAP (RFC-2060), sendmail (UNIX), pine, elm (надстройка над sendmail), mush, mh и т.д.). Схема пересылки электронных почтовых сообщений (RFC-821) показана на рис. 4.5.10.1. Существует множество реализаций электронной почты. Имеются версии практически для всех ЭВМ, операционных систем и сред. Адреса электронной почты уникальны и однозначно определяют адресата, обладая иногда даже некоторой избыточностью. Символьные адреса электронной почты вполне соответствуют IP-нотации. Электронный почтовый адрес содержит две части, местную и доменную, например, vanja.ivanov@itep.ru (vanya.ivanov - местная). Доменная часть обычно совпадает с символьным IP-именем домена. Если между отправителем и приемником имеется непосредственная связь, адрес имеет вид имя_пользователя@имя_ЭВМ. Когда приемник находится на ЭВМ, которая не поддерживает SMTP и передача происходит через промежуточный почтовый сервер, то адрес может иметь вид, например, ivanov%имя_удаленной_ЭВМ@имя_сервера (благодаря быстрому развитию Интернет в мире и даже в России такая схема используется сейчас крайне редко). Местная часть адреса определяется пользователем и часто совпадет с его именем или фамилией. Электронный адрес несравненно компактнее традиционных почтовых адресов, которые мы пишем на конвертах. Да и сами возможности электронной почты несравненно богаче почты традиционной. По этой причине можно утверждать, что традиционная почта постепенно будет в ближайшем будущем вытеснена ее электронным аналогом. Схема взаимодействия различных объектов электронной почты показана на рис. 4.5.10.1
Рис. 4.5.10.1. Схема пересылки электронных почтовых сообщений Со временем можно ожидать, что электронные адреса станут универсальными, но это произойдет не скоро. Для этого нужно чтобы транспорт и другие службы научились работать с такими адресами. Электронные (IP) адреса удобнее для ЭВМ, чем традиционные, а принимая во внимание, что применение вычислительной техники повсеместно, вывод напрашивается сам собой. То что удобно для ЭВМ, удобно в конечном итоге для всех. Любое почтовое сообщение можно разделить на три части: "конверт" (RFC-821), заголовки (RFC-822) и собственно текст. Конверт используется почтовым сервером и содержит две команды (тексты после двоеточия приведены в качестве примера): MAIL From: <semenov@cl.itep.ru> Существует девять полей заголовка, используемые почтовой программой пользователя: Received, From, To, Date, Subject, Message-Id, X-Phone, X-Mailer, Reply-To. Каждое из этих полей содержит имя, за которым после двоеточия следует его значение. Документ RFC-822 определяет формат и интерпретацию полей заголовка. Заголовки, начинающиеся с X- являются полями, определяемые пользователем. При вызове почты (командой mail или mailx) на экране будет распечатан служебный текст, который зависит от конкретной реализации mail, но практически непременным атрибутом любой версии будет являться полное число полученных вами почтовых сообщений (если таковые были). Это могут быть и сообщения, оставленные вами там после предшествующего чтения почты. Непрочитанные вами сообщения так или иначе помечаются (например, символом U на левом поле строки-описания сообщения или N для новых). Далее следует аннотация сообщения, по одной строке на сообщение. Аннотация обычно содержит номер сообщения (нумерация всегда начинается с 1), имя и адрес отправителя, дата и время отправки. После этого следуют (в некоторых реализациях) два числа, разделенных косой чертой ("/"). Они характеризуют размер сообщения в строках и полное число символов. В заключение следует, если еще есть место, предмет сообщения (Subject:). Ниже приведен пример текста такого аннотационного сообщения (SUN): Mail version SMI 4.1-OWV3 Mon Sep 23 07:17:24 PDT 1991 Type ? for help. Не ленитесь заполнять поле Subject, иначе при большой почте ваш адресат может пропустить ваше сообщение. Среди наиболее значимых для пользователя полей заголовка можно выделить: адрес и имя отправителя (From:), дата отправки (Date:), адрес получателя (To:), адреса и время прохождения промежуточных узлов, списки лиц (Cc:), кому кроме вас послано это сообщение, предмет сообщения (Subject:), некоторая служебная информация и т.д. Число строк заголовка зависит от программы, реализующей функцию почты и от параметров, определенных пользователем, например, путем задания значений системных переменных. Практически все пакеты электронной почты имеют возможность переадресовать сообщение другому адресату (Forward); отправить ответ (Replay) пославшему вам сообщение человеку (в этом случае в заголовке появится поле Replay-To); стереть сообщение не читая; в случае смены места работы или длительной командировки установить постоянную переадресацию (на ЭВМ SUN для этого нужно указать адрес нового почтового ящика в файле .forward); записать сообщение в файл (Save имя_файла) или отпечатать его на принтере. Команда обращение к почтовому серверу обычно имеет вид: mail местный_адрес@имя_домена, (все что записано после команды mail, является электронным адресом адресата). Например, если вы посылаете сообщение автору, то команда приобретает вид: mail semenov@itep.ru. Использование промежуточного почтового сервера (mail gateway) несколько усложнит запись электронного адреса (это бывает нужно, например, когда кто-то вне Internet хочет послать сообщение клиенту Internet): semenov%cl.itep.ru@имя_промежуточного_почтового_сервера При этом предполагается, что промежуточный почтовый сервер возьмет местную часть адреса, заменит символ "%" на традиционный "@" и перешлет полученное сообщение по данному адресу. Встречаются нотации (хотя сегодня их уже смело можно назвать устаревшими), когда адрес имеет вид: идентификатор_пользователя%имя_домена При возникновении проблем рекомендуется обращаться к администратору вашей локальной сети. Если вы любопытны и хотите посмотреть, какие служебные команды выдаются при отправке электронного сообщения, воспользуйтесь командой (в качестве адресата (xxxxxxxx) выберите своего друга, коллегу или знакомого, которому вам нужно что-то сообщить): mail -v xxxxxxxx@cernvm.cern.ch (обращение к почтовой программе пользователя)
xxxxxxxx@cernvm.cern.ch... Connecting to dxmint.cern.ch (TCP)... Именно модификация команды mail -v обеспечивает вывод сообщений, отпечатанных ниже строки "Privet...". Для посылки почтового сообщения используется только пять команд: HELO, MAIL, RCPT, DATA и QUIT. Строчки, начинающиеся с >>>, являются командами, которые посланы SMTP-клиентом (xxxxxxx@ns.itep.ru). Строки же, которые начинаются с трехзначной цифры, представляют собой коды-отклики SMTP-сервера (в данном случае он имеет имя dxmint.cern.ch), тексты же, следующие после кода-отклика необязательны и могут отсутствовать. Процедура отправки сообщения начинается с того, что клиент выполняет операцию active open для TCP-порта 25. Далее клиент идентифицирует себя командой HELO, выдавая в качестве параметра адрес своего домена. Команда MAIL идентифицирует отправителя, команда RCPT - получателя. Число команд RCPT всегда равно числу получателей. Команда DATA служит для передачи сообщения, а QUIT - для завершения этой процедуры и ликвидации TCP-канала. Посмотрим как выглядит посланное выше сообщение после того, как я его переадресовал себе по адресу semenov@itep.ru: From xxxxxxxx@crnvma.cern.ch Sat Jul 29 12:15:13 1995 Текст, выделенный курсивом, представляет собой то, что пришло в CERN. "Накладные расходы" даже здесь значительны, ведь собственно текст состоит из одного слова, следующего после надписи "Original message". Переадресация же увеличивает издержки еще больше. При описании DNS говорилось о существовании MX-записей, которые являются одной из разновидностей ресурсных рекордов. MX-записи могут использоваться для доставки почтовых сообщений адресатам, не имеющим прямого доступа к Интернет (RFC-974). Еще одним применением MX-записей является предоставление альтернативного получателя почтовых сообщений в случае, когда ЭВМ-получатель вышла из строя. Для выяснение конкретной конфигурации почтовых серверов можно воспользоваться командой host: host -a -v -t mx cernvm.cern.ch (команда выданная с терминала, ниже следует отклик на эту команду) Trying domain "itep.ru"
For authoritative answers, see:
Additional information:
.................................. MX-записи с наименьшим предпочтением (код предпочтения следует сразу за MX) указывают, что сначала следует попытаться переслать сообщение ЭВМ dxmint.cern.ch. Следующий уровень предпочтения соответствует адресу relay.EU.net. Здесь же вы найдете CNAME-запись (канонические имена DNS). Кроме списка альтернативных почтовых серверов эта команда выдает информацию о списке серверов имен (DNS-серверов). В приведенном примере их четыре, они помечены символами NS и обслуживают домен cern.ch (см. первую колонку). В нижней части полученной таблицы вы можете найти IP-адреса приведенных MX- и NS-серверов (помечены символом A). Пояснения расшифровки содержимого других колонок можно найти выше, в описании DNS-системы (раздел 1.13 ). При подготовке текста сообщения вы можете сначала воспользоваться традиционным редактором. Текст будет тогда размещен в файле и при отправке вы можете использовать, например, команду send имя_файла (в системе VMS) или командой GET ввести содержимое файла в текст сообщения (с помощью команды ~r имя_файла в UNIX). Чаще текст сообщения печатается в реальном масштабе времени, непосредственно перед отправкой. В этом случае сигналом конца ввода будет Ctrl-D или символ "." (точка) в начале очередной строки (или Ctrl-Z в VAX/VMS). Если по какой-либо причине вы передумали и не хотите отправлять уже набранное сообщение, процедуру можно прервать, нажав Ctrl-C. При необходимости посылки одного и того же текста нескольким пользователям можно воспользоваться командой: mail (или mailx) адрес_1 адрес_2 и т.д. В этом случае сообщение будет послано по всем перечисленным адресам. Формат этой операции заметно варьируется для разных ЭВМ и программных пакетов. Вместо адресов могут использоваться псевдонимы, что несколько облегчает задачу. Для хранения псевдонимов (alias) служит специальный служебный файл. За описанием работы с псевдонимами вынужден отослать вас к описанию почтового пакета, с которым вы работаете. На последней строке будет напечатан символ &, который указывает, что система ждет ввода команды (просмотр почты). Уход из mail производится по команде q (quit). В ответ на & вы можете ввести следующие команды (набор команд и их синтаксис может варьироваться от ЭВМ к ЭВМ и от реализации к реализации, см. табл. 4.5.10.1). При работе в Unix в процессе печатания текста сообщения вы можете выдать почтовой программе определенные команды. Такие команды начинаются с символа "~" (тильда). Ниже приведен список таких команд, текст набранный курсивом, означает, что вместо него должны быть впечатаны имена, адреса и т.д. Многоточие показывает, что может быть введено более одного имени, адреса и пр. Таблица 4.5.10.1. Внутренние команды почтовой программы UNIX
Если вы напечатаете ~f (без указания номера сообщения), в текст текущего сообщения будет внесено содержимое сообщения, которое вы читали последним. Стандартной формой использования ~f является, например, ~f 5, где 5 - номер сообщения. ~m делает тоже самое, но каждая строка сдвигается на один tab вправо. В UNIX многие команды имеют разные функции, если они напечатаны строчными или прописными буквами, смотри, например, команды r и R в таблице 4.5.10.2. Не безразлично в UNIX и применение строчных и прописных символов в именах файлов, что бывает существенно, в частности, при работе с FTP-сервером. Важной командой является SET, которая позволяет изменять системные переменные. Формат использования: SET переменная=значение (Например, SET EDITOR=/bin/edMe=/bin/eda). Уже сегодня можно переслать поздравительную цветную открытку вашим знакомым. Возможна по такой схеме пересылка и звуковых писем, лишь бы у вашего адресата была звуковая карта в ЭВМ. Ведутся работы и над протоколами видео-писем (NETBLT). Тот факт, что электронная почта является наиболее популярным видом сервиса, делает ее объектом непрерывных доработок и усовершенствований. Так в документах RFC-1425, -1426, -1427 предлагается вариант расширения возможностей SMTP (ESMTP). Эта модификация сохраняет совместимость со старыми версиями. Клиент, желающий воспользоваться расширенными возможностями, посылает команду EHLO вместо HELO. Если сервер поддерживает ESMTP, он выдаст код-отклик 250. Этот вид отклика является многострочным, что позволяет серверу сообщить о видах сервиса, которые он поддерживает. Например: 250-8BITMIME (RFC-1426) Таблица 4.5.10.2. Команды, выполняемые почтовой программой
Ключевое слово 8BITMIME говорит о том, что клиент может добавить ключевое слово BODY к команде MAIL FROM и определить тип символов, используемых в сообщении (ASCII или 8-битные). Ключевое слово XADR указывает на то, что любые ключевые слова, начинающиеся с X, относятся к местным модификациям SMTP. Документ RFC-1522 определяет способ, как можно включить не ASCII-символы в заголовок почтового сообщения. Например: =?набор_символов ?кодировка ?закодированный_текст ?= набор_символов - спецификация набора символов: us-ascii или ISO-8859-X, где X - одиночная цифра, например ISO-8859-1. Поле кодировка содержит один символ, характеризующий метод кодировки. В настоящее время описаны два метода: 1. Q - набор печатных символов; символы, коды которых имеют неравный нулю 8-ой бит, отображается тремя символами: знаком равенства (=), за которым следует два шестнадцатеричных числа (например =AD). Так пробел будет иметь кодировку =20. 2. B - 64-символьный набор (Base64, латинские буквы, 10 цифр, а также символы + и /). Набор кодов Base64 приведен в таблице:
Интересным дополнением к традиционной электронной почте является ее расширение MIME (Multipurpose Internet Mail Extensions, RFC-1521). MIME не требует каких-либо переделок в почтовых серверах, это расширение определяет пять новых полей-заголовков (расширение RFC-822):
Поле заголовка Content-Transfer-Encoding используется пять видов кодировки (третий вид полей в приведенном выше списке):
Только первые три типа согласуются с требованиями RFC-821. MIME позволяет снять с электронной почты привычные ограничения и предоставляет возможность пересылать любую информацию. Техника приложений (Attachment) позволяет пересылать через электронную почту любые файлы без какого-либо специального преобразования, выполняемого пользователем. При этом необходимо только, чтобы и приемник и передатчик поддерживали это расширение электронной почты. В MIME предусмотрены следующие типы и субтипы содержимого почтового сообщения:
Текст электронного сообщения не передает всех оттенков мыслей и эмоций отправителя, что может вызвать неверное восприятие. Для решения этой проблемы хотя бы частично используются символьные обозначения эмоций. Таблица таких обозначений приведена ниже. Чтобы легче воспринять и запомнить их, посмотрите на страницу, где напечатана таблица, справа.
В последнее время большинство почтовых серверов реализуется в среде UNIX, где функцию почтового демона (фонового процесса) выполняет программа sendmail. Эта программа осуществляет переадресацию сообщений от пользователя пользователю и от сервера серверу. Программа эта имеет большие возможности, но ее конфигурирование и использование представляет немалые трудности. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.9 Серверы подписки (LISTSERV)
UP:
4.5.8 Поиск узлов и людей
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.11 Gopher
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
GOPHER (RFC-1436) представляет собой систему для поиска и доставки документов, хранящихся в распределенных хранилищах-депозитариях. Система разработана в университете штата Миннесота (на гербе этого штата изображен хомяк, по-английски gopher). Программа Gopher предлагает пользователю последовательность меню, из которых он может выбрать интересующую его тему или статью. Объектом поиска может быть текст или двоичный файл (во многих депозитариях даже текстовые файлы хранятся в архивированном, а следовательно, двоичном виде), графический или звуковой образ. Gopher кроме того предлагает шлюзы в другие поисковые системы WWW, Wais, Archie, Whois, а также в сетевые утилиты типа telnet или FTP. Gopher может предложить больше удобств для работы с оглавлением файлов (directory), чем FTP. Для доступа в глобальную сеть Gopher использует модель клиент-сервер. Система Gopher в настоящее время устарела, многие ее серверы интегрированы в сеть WEB. Но gopher явился прототипом современных интерфейсов WWW и именно делает его интересным. Для реализации доступа пользователь должен работать в рамках протоколов TCP/IP и иметь на своей машине программу-клиент одной из версий gopher. Существуют версии Gopher на IBM/PC (MS-DOS), VMS, UNIX, X-Windows и т.д. Многие версии публично доступны с помощью анонимного FTP в различных депозитариях, например, boombox.micro.umn.edu секция /pub/gopher. При постановке программы-клиента необходимо среди прочего указать адрес сервера-gopher. Для России можно использовать серверы (при равных условиях предпочтительнее серверы, отстоящие на меньшее число шагов; многие серверы gopher в настоящее время уже закрыты):
При выдаче команды Gopher система свяжет вас с сервером, указанным вами при постановке программы. Можно связаться с любым другим сервером, выдав команду: Gopher <имя_сервера>, где <имя_сервера> имя Gopher-сервера, выбранного вами. Большинство программ-клиентов позволяют пользователю делать "закладки" (bookmarks), которые содержат информацию о месте хранения объекта и пути доступа к нему. Закладки сохраняются и при выходе из Gopher, что облегчает продолжение поиска или нахождение объекта, найденного ранее. Набор функций программы-клиента зависит от ее конкретной реализации и от программного обеспечения ЭВМ, на которой она работает. Gopher обеспечивает простой и удобный интерфейс (лучше чем в обычном www с использованием меню, но хуже чем в MS internet explorer или netscape), позволяя работать с мышкой и предельно упрощая копирование найденных файлов. Обычно gopher имеет также автоматическую систему поиска объектов по ключевым словам в более чем 500 меню. Это крайне важно, так как пользователь не может знать все адреса серверов. Система носит имя Veronica (Very Easy Rodent-Oriented Net-wide Indexed Computerized Archives). Ключевое слово может быть набрано строчными или заглавными буквами. Veronica-сервер возвращает результат поиска в виде gopher-меню, где содержатся записи, в текстах которых присутствуют искомые ключевые слова. Доступ к Veronica возможен либо из базового меню или из из рубрики Other gopher servers... Для того чтобы ваш сервер стал известен окружающему миру, он должен быть зарегистрирован в сервере университета Миннесоты (США) или в любом другом уже зарегистрированном сервере. Объекты в меню обычно снабжаются символами-признаками, которые позволяют судить о типе объекта. Так, например, "<?>" означает полнотекстный индексный поиск, "/" - subdirectory, "<picture>" - указывает, что здесь хранится изображение, отсутствие какого-либо символа означает, что это текстовый файл. Если вы располагаете рабочей версией gopher, вызов программы можно выполнить командой Gopher или, например, gopher gopher.micro.umn.edu 70. В последнем случае обращение будет произведено к конкретному серверу, имя которого указано в качестве параметра команды. Число 70 указывает на номер порта (стандартное значение для gopher). Ниже приводится пример меню gopher: Internet gopher information client v2.0.12 information about gopher 1. about gopher. 14. big ann arbor gopher conference picture.gif <Picture> Press ? for Help, q to Quit, u to go up a menu Page: 1/1 Выбор пункта из меню может выть выполнен мышкой, путем печатания номера соответствующей строки и последующего нажатия клавиши <Enter>, или путем движения курсора с помощью клавишей стрелок с последующим нажатием клавиши <Enter>. В приведенном выше примере курсор указывает на пункт меню с номером 12. Если в такой ситуации нажать клавишу <Enter>, обращение произойдет именно сюда. Звуковые и графические файлы имеют формат uuencode. Существует возможность доступа к GopherMail-серверам, которые пересылают заказчику текст базового меню. GopherMail включат в себя следующие возможности (что-то вроде игры в шахматы по переписке):
Вы можете задать предельные размеры сообщения и меню, включив в текст сообщения команды, например: Split=25K Для работы с Gopher через электронную почту вы можете выбрать ближайший GopherMail-сервер из предлагаемого списка:
Если вы хотите узнать больше о GOPHER можете подписаться на новости о GOPHER по адресу: gopher-news-request@boombox.micro.umn.edu. Если для вас доступен NEWS-server, то секция GOPHER имеет там имя omp.infosystem.gopher. В сложных случаях за справками можно обратиться к разработчикам GOPHER по адресу: gopher@boombox.micro.umn.edu. При проблемах с VERONICA можно написать письмо ее разработчикам Steve Foster и Fred Barrie в университет Невады по адресу: gophadm@futique.scs.unr.edu. Но не злоупотребляйте этим, у них есть и свои заботы. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.10 Электронная почта
UP:
4.5.8 Поиск узлов и людей
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.12 WAIS
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
WAIS (Wide Area Information Server) распределенная система поиска информации. Поиск производится по базам данных, содержащим текстовые документы (но допустимы также графические, звуковые или видео документы). Тематика баз данных и поиска произвольны. Базы данных могут иметь любую структуру, но пользователю не нужно знать языка управления этими базами. WAIS использует естественный управляющий язык. WAIS доступен в Интернет. Для пользователей, имеющих доступ только к электронной почте, предназначен интерфейс, размещенный по адресу waismail@quake.think.com. В сети Интернет существует много серверов WAIS. Список депозитариев серверов достаточно широк, начать можно с анонимного FTP по адресу Think.com секция /wais, файл wais-sources.tar.Z (файл архивирован и пересылка должна осуществляться в режиме BINARY). В настоящее время многие WAIS-сервера интегрированы в сети WEB. Доступ к WAIS-клиентам возможен и напрямую с помощью команды TELNET по адресам:
Существуют клиент-серверы WAIS для систем MS-DOS, VMS, MVS, OS/2, UNIX и Macintosh, а также для GNU Emacs, NeXT, X-Windows, MS-Windows, Sunview и т.д. Эти продукты несколько отличаются друг от друга, но обычно процедура содержит следующие шаги:
Ниже приводится таблица команд WAIS
Имеется возможность доступа к ресурсам системы WAIS и через электронную почту. Запрос посылается по адресу waismail@quake.think.com, строка Subject игнорируется. Далее (в теле сообщения) могут следовать команды (вертикальная черта (|) указывает на выбор параметров):
где: source-name имя источника, как оно было найдено в оглавлении сервера (с или без расширения .SRC). Если нужно провести поиск по нескольким источникам, их имена заключаются в двойные кавычки. keywords ключевые слова, по которым проводится поиск. Можно сформулировать несколько запросов в одном e-mail. Если имя источника не будет узнано, вы получите список имен возможных источников. retrieve docid Извлечение копии документа из базы данных. docid является DocID (идентификатор найденного документа). Если вы посылаете несколько запросов, они должны быть разделены пустыми строками. docid должен строго соответствовать имени документа, полученного вами в результате запроса-поиска (включая пробелы, если они имелись). Могут копироваться не только текстовые документы. Такие документы будут пересланы в формате UUENCODE. DocID: docid То же, что и retrieve. Эта форма идентична по форме ответу на поисковый запрос. Процедура делает возможным использовать replay в e-mail для копирования найденных документов. Примеры использования WAIS telnet quake.think.com (в качестве пароля предлагается напечатать ваш почтовый адрес). TERM = (vt100) ibmpc (нужно ввести тип терминала, с которым вы работаете) Starting up. This may take awhile...
Keywords: <space> selects, w for keywords, arrows move, <return> searches, q quits, ? for Help Слово Free на правом поле означает бесплатный доступ. Сразу после вывода на экран оказывается подсвеченной позиция <001> (номера позиций проставлены на левом поле). В квадратных скобках приведены адреса серверов, доступ к которым может быть предоставлен, сразу за ним следует наименование базы данных или документа. Используя стрелки <вверх> и <вниз>, можно подсветить нужную вам позицию. После нажатия клавиши <Enter> (или на некоторых клавиатурах RETURN) позиция будет выбрана и вам будет предложена возможность ввести ключевые слова для последующего поиска. Выберем для примера aarnet-resource-guide.src. Enter keywords with spaces between them; <return> to search; ^C to cancel
<space> selects, arrows move, w for keywords, s for sources, ? for help (ниже следует текст документа) Charles Sturt University
Description: The Division of Information Technology offers computing services for teaching, research and university administration and is a centrally funded support service of the University. The University has a Facom 340S, VAX 6320 and 6310 systems (VMS), a HP935 (HP-UX), and a SUN 4/75S, as well as a range of workstation-level Unix hosts. Numerous PC and Mac Networks are spread through the faculties and divisions. ISDN links between the three campuses of CSU bring the ethernet/fibre "backbones" on each individual campus into a single university-wide TCPIP/LAT Network. Network Access: Systems are generally available via AARNet and Austpac.
Возможна и несколько другая форма доступа к WAIS (например, из ЭВМ SUN): ns> telnet info.funet.fi
Select service (gopher/www/wais/archie/exit) ? wais (выбран WAIS)
Российского пользователя не остановит и плата за ресурс, если она составляет $0.00. Выберем позицию agricultural-market-new, а в качестве ключевого слова введем price (кого не интересуют цены на продукты питания?): Keywords: price
<space> selects, arrows move, w for keywords, s for sources, ? for help Выбираем позицию <3>. Ниже следует текст, выданный в результате на экран. Retrieving: Re: AM LS753 SUPRIOR VIDEO "Re: SUP%RIOR Trade and demand moderate to good. Cattle offered from 16 States, Mexico and Canada. Prices based on net weights after a 1-3 percent shrink or equivalent with a 4-10 cent slide on calves and 3-8 cent slide on yearlings. Offerings included 31 percent feeder steers and differs over 600 lbs and 69 percent feeders under 600 lbs. ************************************************************ Feeder Steers Medium and Large 1
Press any key to continue, 'q' to quit. (таблица напечатана с сокращениями) Если вы выдали более одного ключевого слова, тогда все документы, содержащие любое из перечисленных слов будут включены в список найденных. Если нужно узнать о WAIS больше (библиография, утилиты, исходные тексты), обращайтесь к Barbara Lincoln Brooks из WAIS inc. Библиография доступна по адресу ftp.wais.com в секции /pub/wais-inc-doc. Общую информацию по WAIS можно найти через FTP по адресу: quake.think.com /wais/doc или sunsite.unc.edu /pub/docs/about-the-net/libsoft/wais.txt. Для любителей доступа через WWW: www.wais.com или www.earn.net. Те же, кто для целей поиска предпочитает gopher, могут воспользоваться сервером: gopher-gw.micro.umn.edu. Можно узнать кое-что о WAIS и через telnet: quake.think.com Login: wais. Программы доступны по адресам (FTP): ftp.cnidr.org ftp.wais.com quake.think.com sunsite.unc.edu По вопросам получения бесплатного программного обеспечения обращайтесь по адресу: freewais@cnidr.org. Подписной почтовый лист имеет адрес: wais-discussion@wais.com. Для подписки посылайте запрос по адресу (формат запросов описан в разделе LISTSERV): wais-discussion-request@wais.com. Группа новостей в USENET (FAQ): comp.infosystems.wais; полезную информацию можно получить и через анонимное FTP по адресу rtfm.mit.edu в каталоге /pub/usenet/news.answers/wais-faq. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.11 Gopher
UP:
4.5.8 Поиск узлов и людей
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.13 Система поиска файлов Archie
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
ARCHIE - информационная система с наиболее эффективной системой поиска. Система разработана Аланом Эмтейджем, Питером Дойчем и Билом Хееланом из университетского вычислительного центра McGill, Канада. ARCHIE осуществляет поиск по более чем 1000 депозитариям мира допускающим анонимный доступ и содержащим более 2100000 файлов. ARCHIE работает под Windows, MS-DOS, Macintosh, Unix в рамках сети INTERNET. Рекомендуется следовать следующим правилам (в последнее время система стала менее популярна, ее функции взяли на себя поисковые сервера):
Базы данных ARCHIE располагаются по адресам:
*) Число шагов величина непостоянная и может изменяться со временем, сильно зависит от используемого маршрута. Имеется возможность доступа к ARCHIE через локальный клиент-сервер, через команду telnet или с помощью электронной почты. В настоящее время доступна версия сервера 3.0. Команды, помеченные ниже (+) работают только с версией 3.0, помеченные же (*), работают только с предшествующими версиями. Для определения версии, с которой вы работаете, выдайте команду version. Локальные серверы работают быстрее и надежнее. В публичном доступе имеются версии для MS-DOS, OS/2, VMS, NeXT, Unix, X-windows и Macintosh. Клиент-серверы доступны через анонимный FTP в каталогах /pub/archie/clients ли /archie/clients, обычно это строчные варианты. Существует и графическая версия (xarchie) для X-windows. Стандартное обращение к ARCHIE имеет форму: ARCHIE <-options> последовательность символов | образ где options могут быть:
Например, команда (SUN): archie -L выдаст на экран: Known archie servers: archie.ans.net (USA [NY]) Следующая группа options определяет разновидность поиска.
Результатом поиска может стать список FTP-адресов файлов или каталогов, соответствующих критериям отбора, указывается размер файлов, дата последней модификации и имя каталога, где этот файл лежит. Для интерактивного попадания в ARCHIE-сервер используется команда telnet, в ответ на login следует ввести archie. Для того чтобы покинуть ARCHIE-сервер используются команды: exit, quit, bye. Кроме того, существуют следующие команды:
Используются следующие переменные: compress(+) метод_архивации Задает метод архивации (none или compress), используется до отправки почты командой mail. По умолчанию none. encode(+) метод_кодирования Определяет метод кодирования (none или uuencode), используется при отправке по почте. Эта переменная игнорируется, если компрессии нет. По умолчанию none. mailo email <,email2...> Определяет e-mail адрес, куда будет послан результат, при выдаче команды без аргумента. maxhits number Определяет максимальное число отобранных объектов командой prog (0-1000). По умолчанию эта переменная равна 1000. search search-value Определяет вид проводимого поиска: prog string | prog string | pattern. search-values равны:
term terminal-type <number-of-rows<number-of-columns>> Сообщает ARCHIE, какой терминал используется. Доступ через электронную почту Пользователи могут получить доступ к ARCHIE через электронную почту, послав запрос по адресу archie@archie.ac.il. Команды посылаются в теле сообщения. Командные строки начинаются всегда с первой колонки. Поле subject рассматривается как строка самого сообщения. При этом допустимы следующие команды:
К числу специальных символов относится:
Если вы послали команду list \.de$ по электронной почте или с помощью Telnet, вы получите следующий отклик:
и т.д. Если вы пошлете команду whatis compression по почте или посредством Telnet, вы получите следующий результат:
В ответ на команду find AMPS, вы получите:
Last updated 00:02 3 Jan 1995
Last updated 01:17 11 Dec 1994
Last updated 01:31 11 Dec 1994
Last updated 17:53 13 Dec 1994 Location: /pub/msdos/.1/.util
Last updated 17:50 3 Jan 1995 Это лишь фрагмент выдачи реально она много длиннее. Видно, что один и тот же документ найден в нескольких депозитариях. Если у вас есть вопросы об ARCHIE, пишите Archie Group, Bunyip Information Systems Inc. по адресу info@bunyip.com. В случае обнаружения ошибок, а также с комментариями следует обращаться по адресу archie-admin@bunyip.com. По вопросам, связанным с конкретными серверами можно обратиться по адресу archie-admin@address.of.archie.server, например, archie-admin@archie.ac.il. Список адресов для рассылки информации находится по адресу: archie-people@bunyip.com; для включения в подписной лист можно послать запрос по адресу: archie-people-request@bunyip.com. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.12 WAIS
UP:
4.5.8 Поиск узлов и людей
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.14 Современные поисковые системы
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||
|
Развитие Интернет начиналось как средство общения и удаленного доступа (электронная почта, telnet, FTP). Но постепенно эта сеть превратилась в средство массовой информации, отличающееся тем, что операторы сети сами могут быть источниками информации и определяют, в свою очередь то, какую информацию они хотят получить. Среди первых поисковых систем были archie, gopher и wais. Эти относительно простые системы казались тогда чудом. Использование этих систем показало их недостаточность и определенные врожденные недостатки: ограниченность зоны поиска и отсутствие управления этим процессом. Поиск проводился по ограниченному списку серверов и никогда не было известно, насколько исчерпывающую информацию получил клиент. Первые WWW-системы работали в режиме меню (Mosaic появилась несколько позже) и обход дерева поиска производился вручную. Структура гиперсвязей могла иметь циклические пути, как, например, на рис. 4.5.14.1. Число входящих и исходящих гиперсвязей для любого узла дерева может быть произвольным.
Рис. 4.5.14.1. Пример дерева гиперсвязей Связь, помеченная буквой А может явиться причиной образования цикла при обходе дерева. Исключить такие связи невозможно, так как они носят принципиально смысловой характер. По этой причине любая автоматизированная программа обхода дерева связей должна учитывать такую возможность и исключать циклы обхода. Задача непроста даже в случае поиска нужного текста в пределах одного достаточно большого по емкости диска, когда вы заранее не знаете или не помните в каком субкаталоге или в каком файле содержится искомый текст. Для облегчения ручного поиска на серверах FTP в начале каждого субкаталога размещается индексный файл. Для решения этой задачи в большинстве операционных систем имеются специальные утилиты (например, grep для UNIX). Но даже они требуют достаточно много времени, если, например, дисковое пространство лежит в пределах нескольких гигабайт, а каталог весьма разветвлен. В полнотекстных базах данных для ускорения поиска используется индексация по совокупности слов, составляющих текст. Хотя индексация также является весьма времяемкой процедурой, но производить ее, как правило, приходится только один раз. Проблема здесь заключается в том, что объем индексного файла оказывается сравным (а в некоторых случаях превосходит) с исходным индексируемым файлом. Первоначально каждому документу ставился в соответствие индексный файл, в настоящее время индекс готовится для тематической группы документов или для поисковой системы в целом. Такая схема индексации экономит место в памяти и ускоряет поиск. Для документов очень большого размера может использоваться отдельный индекс, а в поисковой системе иерархический набор индексов. Индексированием называется процесс перевода с естественного языка на информационно-поисковый язык. В частности, под индексированием понимается отнесение документа в зависимости от содержимого к определенной рубрике некоторой классификации. Индексирование можно свести к проблеме распознавания образов. Классификация определяет разбиение пространства предметных областей на непересекающиеся классы. Каждый класс характеризуется набором признаков и специфических для него терминов (ключевых слов), выражающих основные понятия и отношения между ними. Слова в любом тексте в информационном отношении весьма неравнозначны. И дело не только в том, что текст содержит много вспомогательных элементов предлогов или артиклей (напр., в англоязычных текстах). Часто для сокращения объема индексных регистров и ускорения самого процесса индексации вводятся так называемые стоп-листы. В эти стоп-листы вносятся слова, которые не несут смысловой нагрузки (например, предлоги или некоторые вводные слова). Но при использовании стоп-листов необходима определенная осторожность. Например, занеся в стоп-лист, неопределенный артикль английского языка "а", можно заблокировать нахождение ссылки на "витамин А". Немалое влияние оказывает изменяемость слов из-за склонения или спряжения. Последнее делает необходимым лингвистический разбор текста перед индексацией. Хорошо известно, что смысл слова может меняться в зависимости от контекста, что также усложняет проблему поиска. Практически все современные информационные системы для создания и обновления индексных файлов используют специальные программные средства. Существующие поисковые системы успешно работают с HTML-документами, с обычными ASCII-текстами и новостями usenet. Трудности возникают для текстов Winword и даже для текстов Postscript. Связано это с тем, что такие тексты содержат большое количество управляющих символов и текстов. Трудно (практически невозможно) осуществлять поиск для текстов, которые представлены в графической форме. К сожалению, к их числу относятся и математические формулы, которые в HTML имеют формат рисунков (это уже недостаток самого языка). Так что можно без преувеличения сказать, что в этой крайне важной области, имеющей немалые успехи, мы находимся лишь в начале пути. Ведь море информации, уже загруженной в Интернет, требует эффективных средств навигации. Ведь оттого, что информации в сети много, мало толку, если мы не можем быстро найти то, что нужно. И в этом, я полагаю, убедились многие читатели, получив на свой запрос список из нескольких тысяч документов. Во многих случаях это эквивалентно списку нулевой длины, так как заказчик в обоих случая не получает того, что хотел. Встроенная в язык HTML метка <meta> создана для предоставления информации о содержании документа для поисковых роботов, броузеров и других приложений. Структура метки: <meta http-equiv=response content=description name=description URL=url>. Параметр http-equiv=response ставит в соответствие элементу заголовок HTTP ответа. Значение параметра http-equiv интерпретируется приложением, обрабатывающим HTML документ. Значение параметра content определяется значением, содержащимся в http-equiv. Современная поисковая система содержит в себе несколько подсистем.
Следует иметь в виду, что работа web-агентов и системы поиска напрямую независимы. WEB-агенты (роботы) работают постоянно, вне зависимости от поступающих запросов. Их задача - выявление новых информационных серверов, новых документов или новых версий уже существующих документов. Под документом здесь подразумевается HTML-, текстовый или nntp-документ. WEB-агенты имеют некоторый базовый список зарегистрированных серверов, с которых начинается просмотр. Этот список постоянно расширяется. При просмотре документов очередного сервера выявляются URL и по ним производится дополнительный поиск. Таким образом, WEB-агенты осуществляют обход дерева ссылок. Каждый новый или обновленный документ передается системе обработки. Роботы могут в качестве побочного продукта выявлять разорванные гиперсвязи, способствовать построению зеркальных серверов. Обычно работа роботов приветствуется, ведь благодаря ним сервер может обрести новых клиентов, ради которых и создавался сервер. Но при определенных обстоятельствах может возникнуть желание ограничить неконтролируемый доступ роботов к серверам узла. Одной из причин может быть постоянное обновление информации каких-то серверов, другой причиной может стать то, что для доставки документов используются скрипты CGI. Динамические вариации документа могут привести к бесконечному разрастанию индекса. Для управления роботами имеются разные возможности. Можно закрыть определенные каталоги или сервера с помощью специальной фильтрации по IP-адресам, можно потребовать идентификации с помощью имени и пароля, можно, наконец, спрятать часть сети за Firewall. Но существует другой, достаточно гибкий способ управления поведением роботов. Этот метод предполагает, что робот следует некоторым неформальным правилам поведения. Большинство из этих правил важны для самого робота (например, обхождение так называемых "черных дыр", где он может застрять), часть имеет нейтральный характер (игнорирование каталогов, где лежит информация, имеющая исключительно локальный характер, или страниц, которые находятся в состоянии формирования), некоторые запреты призваны ограничить загрузку локального сервера. Когда воспитанный робот заходит в ЭВМ, он проверяет наличие в корневом каталоге файла robots.txt. Обнаружив его, робот копирует этот файл и следует изложенным в нем рекомендациям. Содержимое файла robots.txt в простейшем случае может выглядеть, например, следующим образом. # robots.txt for http://store.in.ru
Файл содержит обычный текст, который легко редактировать, после символа # следуют комментарии. Допускается две директивы. user-agent: - определяет имя робота, к которому обращены следующие далее инструкции, если не имеется в виду какой-то конкретный робот и инструкции должны выполняться всеми роботами, в поле параметра записывается символ *. disallow - указывает имя каталога, посещение которого роботу запрещено. Нужно учитывать, что не все роботы, как и люди, следуют правилам, и не слишком на это полагаться (см. http://info.webcrawler.com/mak/projects/ robots.html). Автор исходного текста может заметно помочь поисковой системе, выбрав умело заголовок и подзаголовок, профессионально пользуясь терминологией и перечислив ключевые слова в подзаголовках. Исследования показали, что автор (а иногда и просто посторонний эксперт) справляется с этой задачей быстрее и лучше, чем вычислительная машина. Но такое пожелание вряд ли станет руководством к действию для всех без исключения авторов. Ведь многие из них, давая своему тексту образный заголовок, рассчитывают (и не без успеха) привлечь к данному тексту внимание читателей. Но машинные системы поиска не воспринимают (во всяком случае, пока) образного языка. Например, в одном лабораторном проекте, разработанном для лексического разбора выражений, состоящих из существительных с определяющим прилагательным, и по своей теме связанных с компьютерной тематикой, система была не способна определить во фразе "иерархическая компьютерная архитектура" то, что прилагательное "иерархическая" относится к слову "архитектура", а не к "компьютерная" (Vickery & Vickery 1992). То есть система была не способна отличать образное использование слова в выражении от его буквального значения. В свою очередь специалисты, занятые в области поисковых и информационных систем, способны заметно облегчить работу авторам, снабдив их необходимыми современными тезаурусами, где перечисляются нормативные значения базовых терминов в той или иной научно-технической области, а также устойчивых словосочетаний. Параллельно могут быть решены проблемы синонимов. В настоящее время, несмотря на впечатляющий прогресс в области вычислительной техники, степень соответствия документа определенным критериям запроса надежнее всего может определить человек. Но темп появления электронных документов в сети достигает ошеломляющего уровня (частично это связано с преобразованием в электронную форму старых документов и книг методом
сканирования). Написание рефератов для последующего их использование поисковыми системами достаточно изнурительное занятие, требующее к тому же достаточно высокой профессиональной подготовки. Именно по этой причине уже достаточно давно предпринимаются попытки перепоручить этот процесс ЭВМ. Для этого нужно выработать критерии оценки важности отдельных слов и фраз, составляющих
текст. Оценку значимости предложений выработал Г.Лун. Он предложил оценивать предложения текста в соответствии с параметром: Vпр =
Автоматическая система выявления ключевых слов обычно использует статистический частотный анализ (методика В. Пурто). Пусть f - частота, с которой встречаются различные слова в тексте, а u - относительное значение полезности (важности). Тогда зависимость f(u) апроксимируется формулой
Одним из известных путей облегчения процедуры поиска является группирование документов по определенной достаточно узкой тематике в кластеры. В этом случае запрос с ключевым словом, фигурирующем в заголовке кластера, приведет к тому, что все документы кластера будут включены в список найденных. Кластерный метод наряду с очевидными преимуществами (прежде всего заметное ускорение поиска) имеет столь же явные недостатки. Документы, сгруппированные по одному признаку, могут быть случайно включены в перечень документов, отвечающих запросу, по той причине, что одно из ключевых слов кластера соответствует запросу. В результате в перечне найденных документов вы можете с удивлением обнаружить тексты, не имеющие никакого отношения к интересующей вас теме. Некоторые поисковые системы предоставляют возможность нахождения документов, где определенные ключевые слова находятся на определенном расстоянии друг от друга (proximity search). Наиболее эффективным инструментом при поиске можно считать возможность использования в запросе булевых логических операторов AND, OR и NOT. Объединение ключевых слов с помощью логических операторов может сузить или расширить зону поиска. Проблема соответствия (релевантности) документа определенному запросу совсем не проста. Индексные файлы, содержащие информацию о WEB-сайтах, занимают около 200 Гигабайт дискового пространства, поиск по содержимому которых производится за время, меньшее одной секунды (на самом деле, реальный поиск производится в более чем в десять раз меньшем объеме). Такой объем содержащейся информации делает Altavista неоценимым помощником в поиске нужных документов и серьезным конкурентом для остальных компаний, содержащих поисковые серверы. Поисковая система Altavista работает на самых мощных компьютерах, произведенных компанией Digital Equipment Corporation - это 16 серверов Alphaserver 8400 5/440, объединенных в сетевой кластер. Каждый из серверов имеет 8 Гбайт оперативной памяти (может иметь до 28 Гбайт), содержит 12 (до 14) процессоров Digital Alfa с тактовой частотой 437 МГц, в качестве жестких дисков используются высокоскоростные и надежные дисковые системы RAID с общим объемом 300 Гбайт. Для обеспечения связи с Интернет используются каналы с суммарной пропускной способностью 100 Мбит/с через шлюз DEC Palo Alto - что является самым мощным корпоративным шлюзом в Интернет. Пример широко известной поисковой системы alta vista, где задействовано большое число суперЭВМ, показывает, что дальнейшее движение по такому пути вряд ли можно считать разумным, хотя прогресс в вычислительной технике может и опровергнуть это утверждение. Тем не менее, даже в случае фантастических достижений в области создания еще более мощных ЭВМ, можно утверждать, что распределенные поисковые системы могут оказаться эффективнее. Во-первых, местный администратор быстрее может найти общий язык с авторами текстов, которые могут точнее выбрать набор ключевых слов. Во-вторых, распределенная система способна распараллелить обработку одного и того же информационного запроса. Распределенная система памяти и процессоров может, в конце концов, стать более адекватной потокам запросов к информации, содержащейся на том или ином сервере. Способствовать этому может также создание тематических серверов поиска, где концентрируется информация по относительно узкой области знаний. Для таких серверов возможен отбор документов экспертами, они же могут определить списки ключевых слов для многих документов. Здесь возможна автоматическая предварительная процедура фильтрации документов по наличию определенного набора ключевых слов. Способствует этому и существование тематических журналов, где сконцентрированы статьи по определенной тематике. В случаях, когда поисковая система выдает заказчику большой список документов, отвечающих критериям его запроса, бывает важно, чтобы они были упорядочены согласно их степени соответствия (наличие ключевых слов в заголовке, большая частота использования ключевых слов в тексте документа и т.д.). Но простые критерии здесь не всегда срабатывают, так объемный документ имеет больше шансов попасть в список результата поиска, так как в нем много слов и с большой вероятностью там встречается ключевое слово. По этому критерию Британская энциклопедия должна попасть в результирующий список любого запроса. Для компенсации искажений, вносимых длиной документов, используется нормализация весов индексных терминов. Нормализация представляет собой способ уменьшения абсолютного значения веса индексных терминов, обнаруженных в документе. Одним из наиболее распространенных методов, решающих данную проблему, является косинусная нормализация. При использовании этого метода нормализации вес каждого индексного термина делится на Евклидову длину вектора оцениваемого
документа. Евклидова длина вектора определяется формулой:
В работах Букштейна, Свенсона и Хартера было показано, что распределение функциональных слов в отличие от специфических слов с хорошей точностью описывается распределением Пуассона. То есть, если ищется распределение функционального слова w в некотором множестве
документов, тогда вероятность f(n) того, что слово w будет встречено в тексте n раз представляется функцией:
Для представления документов используется векторная модель, где любой документ характеризуется бинарным вектором x = x 1,x2,., xn, где значения xi = 0 или 1, в зависимости от того, присутствует в тексте i-ый индексный термин или нет. Рассматриваются два взаимно исключающих события: w1 - документ удовлетворяет запросу Для каждого документа необходимо вычислить условные вероятности P(w1|x) и P(w2|x) для определения, какие документы удовлетворяют запросу, а какие нет. Непосредственно получить значения этих вероятностей нельзя, поэтому необходимо найти другой альтернативный подход для их определения с помощью известных нам величин. По формуле Байеса для дискретного распределения условных вероятностей:
В приведенной формуле P(w1) - первоначальная вероятность соответствия (i = 1) или несоответствия (i = 2) запросу, величина P(x|wi) пропорциональна вероятности соответствия или несоответствия запросу для данного x; в недискретном случае она представляет собой функцию плотности распределения и обозначается как P(x|wi). Окончательно:
Для определения релевантности документа используется вполне очевидное правило: Если
В противном случае считается, что документ не удовлетворяет запросу. При равенстве значений вероятности решение о релевантности документа принимается произвольно. Правило [1] основано на том, что при его использовании просто минимизируется средняя вероятность ошибки принятия нерелевантного документа за релевантный и наоборот. То есть, для любого документа x вероятность ошибки
Таким образом, для минимизации средней вероятности ошибки необходимо минимизировать функцию Не углубляясь в теорию вероятностного нахождения релевантных документов, укажем еще одно правило, которое можно использовать вместо [1]:
В формуле [2] коэффициенты lij стоимостной функции определяют потери, вносимые при ожидании события wi , когда на самом деле произошло событие wj . Для практической реализации вероятностного поиска вводится упрощающее предположение относительно P(x|wi). Принимается, что значения xi
вектора x являются статистически независимыми. Данное утверждение математически представляется в виде:
Определим переменные:
Вероятностные функции, используемые для подстановки в правило [1] имеют вид:
Подставляя значения
Функция G(x) представляет собой ничто иное, как весовую функцию, в которой коэффициенты Сi представляют собой веса присутствующих в документе индексных терминов. Константа С одинакова для всех документов x, но, конечно, различна для разных запросов и может рассматриваться в качестве порогового значения для поисковой функции. Единственными параметрами, которые могут меняться для данного запроса являются параметры стоимостной функции, вариации которых позволяют получать в ответе большее или меньшее число документов. Теперь рассмотрим коэффициенты Сi функции G(x) с использованием следующей терминологии: Таблица 4.5.14.1.
N - полное число документов в системе. Таблица представляет результаты запроса, направленного системе поиска. Представленная таблица должна существовать для каждого из индексных терминов. Если мы обладаем всей информацией о релевантных и нерелевантных документах в коллекции документов, то применимы следующие оценки:
Коэффициент при xi показывает, до какой степени можно провести дискриминацию по i-тому термину в рассматриваемой коллекции документов. В действительности, N может рассматриваться не только как полное количество документов во всей коллекции, но и в некотором ее подмножестве. Все приведенные формулы были выведены при условии, что индексные термины являются статистически независимыми. В общем случае это, конечно, не так. В теории вероятностного поиска моделируется зависимость между различными индексными формулами, в связи с чем, вид функции G(x) несколько меняется. Многие системы поиска информации основаны на словарях и тезаурусах для корректировки запросов и представления индексируемых документов, чтобы увеличить шансы найти необходимый документ. На практике, большинство словарей составляется вручную. Словари создаются с помощью одного из двух основных способов:
В первом случае связываются слова, являющиеся взаимозаменяемыми, то есть, в словарях и тезаурусах они принадлежат одному и тому же классу. То есть, можно выбрать по одному слову из каждого класса и совокупность выбранных слов может быть использована для создания контролируемого словаря. Выбирая слова из созданного контролируемого словаря можно проводить индексацию документов или создавать поисковые запросы. Во втором случае для создания тезауруса используются семантические связи между словами для построения, например, иерархической структуры связей. Создание такого типа словарей является достаточно сложным и трудоемким процессом. Однако, были предложены способы и для автоматического создания словарей. В то время как созданные вручную словари опираются на семантику (т.е. распознают синонимы, являются более обширными, используют более тонкие взаимосвязи), автоматически созданные тезаурусы, в основном, основаны на синтаксическом и статистическом анализе. Но, так как, использование синтаксиса не приводит к серьезному увеличению эффективности работы систем, то значительно большее внимание уделяется статистическим методам. Основное допущение, используемое для автоматического создания классов ключевых слов, заключается в следующем. Если ключевые слова a и b могут быть взаимозаменяемы в том смысле, что мы готовы принять документ, содержащий ключевое слово b вместо ключевого слова a и наоборот, то данное обстоятельство имеет место из-за того, что слова a и b имеют одинаковое значение или ссылаются на одинаковые темы. Основываясь на описанном принципе нетрудно видеть, что создание классификации слов может быть автоматизировано. Можно определить два основных приближения для использования классификации ключевых слов:
Для простейшей поисковой стратегии, использующей только что описанные дескрипторы, независимо от того, являются ли они ключевыми словами или названиями классов, созданных на основе группы ключевых слов, "расширенное" представление документов и запросов с помощью любого из вышеописанных способов может существенно повысить число соответствий между документами и запросами и, следовательно, увеличить значение параметра recall. Правда, последнее обстоятельство не является определяющим, так как значение имеет только совокупность параметров (recall, precision), а одно лишь увеличение параметра recall может привести лишь к увеличению объема выдаваемых в ответ на запрос различных документов. В отчетах об экспериментальных работах по использованию автоматической классификации ключевых слов, проведенных уже упоминавшимся ранее Спарком Джонсом, сообщается, что использование автоматической классификации приводит к увеличению эффективности работы системы по сравнению с системой, использующей неклассифицированные ключевые слова. Работа Минкера и др. не подтвердила выводы Спарка Джонса и, фактически, показала, что в некоторых случаях использование классификации ключевых слов приводит к существенному ухудшению работы системы в целом. Д. Сальтон в своем отзыве о работе Минкера определил, что целесообразность использования классификации ключевых слов для улучшения эффективности работы поисковых систем еще полностью не определена и является объектом дальнейших экспериментальных исследований. Действительно, при работе в Интернет с поисковыми системами, использующими классификацию ключевых слов, (такими как lycos и excite) заметно существенное увеличение документов, не представляющих ничего общего с запросом, но, тем не менее, имеющих довольно высокий ранг и, следовательно, по мнению поисковой системы, наиболее точно соответствующих заданному запросу. Для дальнейшего увеличения эффективности системы используется так называемая кластеризация документов. Существуют две основные области применения методов классификации в системах поиска и локализации информации. Это - кластеризация (классификация) ключевых слов и кластеризация документов. Под кластеризацией документов понимается создание групп документов, таких, что документы, принадлежащие одной группе, оказываются, в некоторой степени, связанными друг с другом. Другими словами, документы принадлежат одной группе потому, что ожидается, что эти документы будут находиться вместе в результате обработки запроса. Логическая организация документов достигается, в основном, двумя следующими способами. Первый - путем непосредственной классификации документов и второй - посредством промежуточного вычисления некоторой величины соответствия между различными документами. Было теоретически доказано, что первый метод является очень сложным для практической реализации, так что любые экспериментальные результаты не могут считаться достаточно надежными. Второй способ классификации заслуживает подробного внимания, и, по сути, является единственным реальным подходом к решению проблемы. На практике почти невозможно сопоставить каждый из документов каждому из запросов из-за слишком больших затрат машинного времени на проведение таких операций. Было предложено много различных способов для уменьшения количества необходимых для выполнения запроса операций сравнения. Наиболее многообещающим было предложение использовать группы взаимосвязанных документов, используя процедуры автоматического определения соответствия документов. Проводя сравнения запроса всего лишь с одним документом, являющимся представителем группы (заранее определенным) и, таким образом, определяя группу документов, в которой и происходит дальнейший поиск, существенно уменьшается затрачиваемое на обработку запроса машинное время. Однако, Дж. Сальтон полагал, что, хотя использование кластеризации документов и уменьшает время поиска, но неизбежно снижает эффективность поисковой системы. Точка зрения других исследователей несколько отличается от мнения Дж. Сальтона, так, в работе Jardine, N. и Van Rijsbergen, c.j., "The Use of Hierarchic Clustering in Information Retrieval", Information Storage and Retrieval, 7, 217-240 (1971) делаются выводы о достаточно высоком потенциале методов кластеризации для увеличения эффективности работы поисковых систем. Для построения систем поиска информации с использованием кластеров необходимо использовать методы для определения степени взаимосвязи между объектами. На основе определенных взаимосвязей можно построить систему кластеров. Взаимосвязь между документами определяется понятиями "степень сходства", "степень различия" и "степень соответствия". Значение степени сходства и степени соответствия между документами увеличивается по мере увеличения количества совпадающих параметров. В рассмотрении могут участвовать совершенно разные параметры. Некоторыми исследователями отмечалось, что различие в производительности поисковых систем при использовании различных способов определения степени ассоциации является несущественным, при условии, что функции, используемые для ее определения, являются соответствующим образом нормализованными. Интуитивно, такой вывод можно понять, так как большинство методов определения взаимосвязи между документами используют одни и те же параметры (использующие, в большинстве, статистический анализ текстовых документов). Данное предположение подтверждается в работах И. Лермана, где показано, что многие из способов определения степени соответствия являются монотонными по отношению друг к другу. В теории поиска информации используется пять основных способов определения степени соответствия. Документы и запросы представляются, в основном, с помощью индексных терминов или ключевых слов, поэтому для облегчения описания моделей обозначим посредством
Самая простая из моделей для определения степени соответствия - это так называемый простой коэффициент соответствия:
В следующей таблице показаны другие подходы к определению степени соответствия, использующие коэффициенты, учитывающие размеры множеств Таблица 4.5.14.2
Приведенные коэффициенты, по сути, представляют собой нормализованные варианты простого коэффициента соответствия. Скажем несколько слов о функциях, определяющих степень различия между документами. Причины использования в системах поиска информации функций, определяющих степень различия между документами, вместо степени соответствия являются чисто техническими. Добавим, что любая функция
оценки степени различия между документами d может быть преобразована в функцию, определяющую степень соответствия s следующим образом:
Если P - множество объектов, предназначенных для кластеризации, то функция D определения степени различия документов - это функция, ставящая в соответствие
Четвертое свойство неявно отображает тот факт, что функция определения степени различия между документами является, в некоторой степени, функцией, определяющей "расстояние" между двумя объектами и, следовательно, логично предположить, что должна удовлетворять неравенству треугольника. Данное свойство выполняется практически для всех функций определения степени различия. Пример функции, удовлетворяющей свойствам 1 - 4:
Наконец, представим функцию определения степени различия в альтернативной форме: Используя векторное представление документов, для
Скажем несколько слов о вероятностном подходе для функций, определяющих степень соответствия. Степень соответствия между объектами определяется по тому, насколько их распределения вероятности отличаются от статистически независимого. Для определения степени соответствия используется ожидаемая взаимная мера информации. Для двух дискретных распределений
вероятности
Если xi и xj - независимы, тогда
Функция
Та степень взаимосвязи, которая существует между индексными терминами i и j вычисляется затем функцией
Были предложены и другие функции, похожие на описанную выше функцию
Как и в случае автоматической классификации документов, использование вероятностных методов при формировании кластеров содержит в себе достаточно высокий потенциал и представляет крайне интересную область для исследований. Итак, для формирования кластеров необходимо использовать некую функцию соответствия для определения степени связи между парами документов из коллекции. Постулируем теперь основную идею, на которой, собственно говоря, и построена вся теория кластерного представления коллекции документов. Гипотеза, приведшая к появлению кластерных методов, называется Гипотезой Кластеров и может быть сформулирована следующим образом: "Связанные между собой документы имеют тенденцию быть релевантными одним и тем же запросам". Базисом, на котором построены все системы автоматического поиска информации, является то, что документы, релевантные запросу, отличаются от нерелевантных документов. Гипотеза кластеров указывает на целесообразность разделения документов на группы до обработки поисковых запросов. Естественно, она ничего не говорит о том, каким образом должно проводиться это разделение. Проводился ряд исследований по поводу применения кластерных методов в поисковых системах. Некоторые отчеты приведены в работах Б. Литофски, Д. Крауча, Н. Привеса и Д. Смита, а также М. Фритше. Кластерные методы, выбираемые для использования в экспериментальных поисковых системах должны удовлетворять некоторым определенным требованиям. Это:
Основной вывод из вышесказанного состоит в том, что любой кластерный метод, не удовлетворяющий приведенным условиям, не может производить сколько-нибудь значащие экспериментальные результаты. Надо сказать что, к сожалению, далеко не все работающие кластерные методы удовлетворяют приведенным требованиям. В основном, это происходит из-за значительных различий между реализованными методами кластеризации от теоретически разработанных ад-хок алгоритмов. Другим критерием выбора является эффективность процесса создания кластеров с точки зрения производительности и требований к объему необходимого дискового пространства. Необходимость учета данного критерия находится, естественно, в сильной зависимости от конкретных условий и требований. Возможно, использование процедур фильтрации базы данных таким образом, что из базы данных будет удаляться информация об индексных терминах, встречающихся в более чем, скажем 80% проиндексированных документов. Таким образом, список стоп-слов будет динамически изменяющимся. Как уже говорилось, использование списка стоп-слов может приводить к 30% уменьшению размеров индексных файлов. Для построения кластеров обычно используется два основных подхода:
В первом случае кластеры можно представить с помощью графов, построенных с учетом значений функции соответствия для каждой пары документов. Рассмотрим некоторое множество объектов, которые должны быть кластеризованы. Для каждой пары объектов из данного множества вычисляется значение функции соответствия, показывающее насколько эти объекты сходны. Если полученное значение оказывается больше величины заранее определенного порогового значения, то объекты считаются связанными. Вычислив значения функции соответствия для каждой пары объектов, строится граф, по сути, представляющий собой кластер. То есть определение кластера строится в терминах графического представления. Список литературы
|
||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.13 Система поиска файлов Archie
UP:
4.5.8 Поиск узлов и людей
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.15 Диалог в локальных сетях и в Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Команды Talk (для SUN), Phone (для VAX/VMS) и другие служат для переговоров двух человек, работающих на одной и той же ЭВМ с удаленных терминалов в реальном масштабе времени. Хотя эти команды и не используют протоколы TCP/IP, они весьма удобны при работе, в частности при отладке новых телекоммуникационных каналов. Вызов осуществляется в соответствии с форматами: Talk bobyshev@ns.itep.ru или Phone <ID>, где <ID> - имя партнера (его ID, используемое при входе в ЭВМ), с которым вы хотите поговорить. При использовании этих процедур экран делится на две части по вертикали, верхняя часть предназначена для печати текста вызывающего, нижняя часть для его партнера. Существует версия и Internet-Phone, которая обеспечивает голосовую двухстороннюю связь между пользователями сети. Этот вид услуг примыкает скорее к разновидностям сервиса, описанным в следующей главе. Для обеспечения работы такого канала связи достаточно ЭВМ PC-486SX с частотой 25МГц, памятью 8Мбайт и стандартной аудио-картой. Программы, поддерживающие этот вид сервиса, работают в рамках Windows, Winsock 1.1. При этом вы займете полосу канала шириной 7.7Кбит/c. При установке звуковой VC-платы c сжатием аудио-информации можно ограничить требования на полосу до уровня 6.72Кбит/c. Следует ожидать появления программ и на других платформах и в других средах. Общедоступное программное обеспечение для работы с аудио-версией Phone можно получить через анонимное FTP по адресу ftp.volcaltec.com (используйте ID-пользователя=ftp). Разговаривать можно только с одним партнером одновременно. Возможно совмещение разговора с другими процедурами Internet, что особенно привлекательно при диагностике и отладке каналов и сетевых программ. Internet-Phone контактирует с IRC (Internet Relay Chat, смотри подробнее в следующей главе), что позволяет получить необходимую справочную информацию. Используя возможности IRC, можно выбрать мышкой нужного вам партнера и начать беседовать с ним, если он конечно сидит у ЭВМ, которая оснащена необходимым аппаратным и программным обеспечением. В рамках этого вида сервиса вы можете обсудить какой-то документ, отображенный на экране терминалов, отмечая нужные места с помощью манипуляторов мышь. Это дает возможность согласовать в реальном масштабе времени текст документа, обсудить элементы конструкции или схемы, не тратя деньги на командировку или на дорогостоящее оборудование для видеоконференций. Бесплатно поболтать с вашим приятелем в Рио-де-Жанейро - это ли не мечта многих россиян? Если же специального оборудования в вашем распоряжении нет, можно воспользоваться текстовой версией Talk или Phone. Обращение к Talk имеет форму: talk имя_пользователя [ ttyname ] Если вы хотите поговорить с кем-то на вашей ЭВМ, достаточно в качестве параметра ввести имя_пользователя (login ID). Если же ваш партнер работает на другой машине, имя адресата может иметь вид: host!пользователь или host.пользователь, или host:пользователь, или пользователь@host, где host - это имя ЭВМ, на которой работает ваш партнер. Последняя форма используется чаще. При необходимости переговорить с человеком, работающем на определенном терминале, следует ввести имя этого терминала (ttyname). При получении запроса Talk выдает на экран следующее сообщение: Message from TalkDaemon@his_machineattime... Пользователь, желающий участвовать в диалоге, должен ответить: talk ваше_имя@ваша_ЭВМ Когда связь установлена, оба участника диалога могут печатать текст одновременно с отображением обоих текстов в верхней и нижней частях экрана. Нажатие комбинации СTRL-L переписывает заново содержание экрана. Для завершения диалога следует нажать CTRL-Y. Имя ЭВМ адресата можно найти в файле /etc/hosts, а имя терминала в файле /etc/utmp. В процессе общения с использованием терминала возникает проблема - "пальцы не поспевают за мыслью". Традиция англоязычного общения выработала некоторые общепринятые сокращения часто используемых слов и выражений, которые могут облегчить диалог: Таблица 4.5.15.1. Общепринятые сокращения, используемые при диалоге
IRC - (Internet Relay Chat, RFC-1459) представляет собой систему переговоров в реальном времени. Она аналогична команде talk, которая используется на многих ЭВМ в Интернет. IRC делает все, что может talk, но позволяет также переговариваться более чем двум лицам одновременно. IRC предоставляет и много других удобных услуг. Когда вы печатаете текст в IRC, все что вы напечатали будет немедленно передано другим пользователям, кто подключен к разговору. Причем они при желании могут вам ответить в реальном масштабе времени. Темы обсуждений в IRC варьируются в широких пределах. Обычно разговор идет по-английски, но существуют каналы для немецкого, японского, финского и других языков (русский язык здесь не является исключением, какой-же русский откажет себе в удовольствии поболтать, особенно в рабочее время). Клиенты и серверы для IRC доступны через анонимное FTP по адресу: cs.bu.edu. Некоторые узлы позволяют доступ к IRC через telnet, например, wbrt.wb.psu.edu и irc.demon.co.uk. В обоих узлах вход в систему осуществляется (login) как IRC. В таблице 4.5.15.2 приведены основные команды IRC. Таблица 4.5.15.2. Основные команды IRC
Многие серверы системы IRC для соединения друг с другом используют древовидную схему. Некоторые серверы, взаимодействуя друг с другом, передают информацию о существовании других серверов, пользователей или других ресурсов. Фундаментальной для IRC является концепция канала. Все пользователи, когда они в системе IRC, находятся на одном канале. Сначала вы входите в нулевой канал. Вы не можете послать сообщение, пока вы не вошли в канал и не задали параметры этого канала. Число каналов не ограничено. Когда вы находитесь в системе IRC и нуждаетесь в помощи, выдайте команду /help. При возникновении проблем можно контактировать с Кристофером Девисом (Christopher Davis, ckd@eff.org) или с Еленой Роуз (Helen Rose, hrose@eff.org). Можно запросить помощь у оператора каналов IRC, например, #twilight_zone и #eu-opers. Различные документы по IRC и архивы списков рассылки IRC доступны через анонимное FTP по адресу ftp.kei.com, cs.bu.edu irc/support/alt-irc-faq или dorm.rutgers.edu pub/Internet.documents/irc.basic.guide. Группа новостей: alt.irc, alt.irc.recovery. Имеется возможность доступа к материалам по IRC и через WWW: www.kei.com irc.html; eru.dd.chalmers.se home/f88jl/Irc; mistral.enst.fr ~pioch/IRC; alpha.acast.nova.edu IRC; www.infosystems.com cgi-bin/www2irc. RELAY RELAY представляет собой систему серверов в глобальной сети Bitnet/EARN, которая ретранслирует интерактивные сообщения от одного пользователя к другим, кто подписан на данный "канал" системы RELAY. Пользователь, подписанный на ближайший RELAY, виртуально подписан на всю систему RELAY. Большинство узлов RELAY отключаются в часы пик. Только некоторые из них работают 24 часа в сутки. Каждый RELAY-сервер обслуживает ограниченное число узлов, называемых сферой обслуживания. RELAY - это программа, которая позволяет нескольким людям общаться через сеть в реальном масштабе времени. Для того чтобы начать, вы должны подписаться на RELAY, для чего поместить ваш ID в текущий список пользователей. Взаимодействие с RELAY осуществляется также, как с обычным пользователем. Команды RELAY начинаются с символа /, все что не начинается с / считается сообщением и пересылается всем текущим пользователям. RELAY доступна по следующим адресам EARN/Bitnet. В скобках приведено условное имя RELAY-ЭВМ.
Система RELAY доступна пользователям сетей EARN/Bitnet через интерактивный обмен (SEND-команда в VMS/JNET, или PHONE в VAX/VMS). Все ЭВМ-серверы RELAY - это IBM VM/CMS системы, но вам не нужно быть пользователем VM, для того чтобы использовать RELAY. Если вы не в сети EARN/Bitnet, доступ к системе RELAY для вас закрыт. CHART доступен на любом NETSERV. При регистрации клиенту посылаются файлы RELAY INFO и RELAY USERGUIDE, которые содержат подробное описание RELAY. Краткое руководство по применению RELAY доступно из списка файлов документов EARN. Пошлите e-mail по адресу LISTSERV@EARNCC.BITNET. В теле сообщения напечатайте: GET RELAY MEMO. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.14 Современные поисковые системы
UP:
4.5.8 Поиск узлов и людей
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.16 Некоторые другие процедуры Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
NFS NFS (network file system, sun microsystems, RFC-1094) обеспечивает прозрачный доступ к удаленным файлам так, что с точки зрения программиста эти файлы выглядят, как местные. При этом даже в написании имен файлов никак не проявляется их истинное местонахождение. NFS является частью операционной системы. Различие работы с местными и удаленными файлами проявляется лишь на системном уровне. Пользователь может почувствовать различие лишь по времени выполнения соответствующих операций обмена. nfs поддерживает операции по созданию, переименованию, копированию и стиранию файлов или каталогов и т.д. Основой системы NFS является вызов удаленных процедур RPC, схема взаимодействия "клиент-сервер". NFS-сервер получает запросы от клиента в виде UDP-дейтограмм через порт 2049 (Рис. 4.5.16.1).
Рис. 4.5.16.1. Схема реализации nfs-системы клиент-сервер RPC (Remote Procedure Call, RFC-1057) процедура, разработанная SUN microsystem, в настоящее время используется практически во всех системах, базирующихся на UNIX. RPC - это программа, которая реализует вызов удаленных подпрограмм, способствуя построению распределенных программ. Она позволяет программе, называемой клиентом, послать сообщение серверу. Далее программа-клиент ожидает сообщения-отклика. RPC работает совместно с универсальной системой представления внешней информации XDP (External Data Representation). Сообщение запрос содержит параметры, которые определяют, что должно быть сделано на удаленной ЭВМ. В свою очередь отклик несет в себе информацию о результатах выполнения запроса. RPC может работать как на TCP, так и UDP транспортных уровнях. Использование RPC-техники упрощает программирование, так как не требует написания сетевых программ. Если используется протокол UDP, все что связано с обработкой тайм-аутов, повторных пересылок и пр. спрятано в внутри системных RPC-модулей. Формат RPC-запроса для UDP-версии показан на рис. 4.5.16.2.
Рис. 4.5.16.2. Формат RPC-запроса Поле идентификатор процедуры устанавливается программой-клиента, пакет-отклик использует тот же идентификатор, что позволяет контролировать их соответствие. Каждый новый RPC-запрос имеет новый идентификатор. В настоящее время номер версии rpc равен 2. Следующие три поля содержат переменные: номер программы, номер версии и номер процедуры, которые определяют тип запрашиваемой клиентом процедуры. В поле идентификатор клиента может быть записан цифровой код клиента, идентификатор группы или вообще ничего. Поле верификатор используется при пересылке зашифрованных сообщений. Формат параметров процедуры зависит от типа этой процедуры. Размер поля параметров равен длине UDP-дейтограммы минус сумма длин остальных полей, включая верификатор. В случае работы с TCP-сегментами, где длина пакета не определена, между TCP-заголовком и XID вводится 4-x октетное поле длины RPC-сообщения. Формат RPC-отклика для UDP-версии (Рис. 4.5.16.3):
Рис. 4.5.16.3. Формат RPC-отклика Поле отклик, содержащее 1, указывает на то, что данное сообщение представляет собой отклик на поступивший ранее запрос. Поле статус содержит 0 в случае, если запрос воспринят. Запрос игнорируется при конфликте кодов RPC-версии или неудачной идентификации клиента. Поле флаг результата принимает значение 0 при успешной обработке запроса. Ненулевое значение этого поля указывает на ошибку. Для записи параметров RPC-запросов, откликов, параметров и результатов выполнения процедуры используется внешнее представление данных (XDR - External Data Representation, RFC-1014). Отправитель, формируя RPC-сообщение, использует XDR-формат, а получатель преобразует данные из этого формата в традиционное представление. Существует два базовых вида отклика: MSG_ACCEPTED (сообщение принято) и MSG_DENIED (не принято). Факт приема сообщения не означает выполнение запрошенных процедур, поэтому клиенту выдается дополнительная информация о результатах взаимодействия его запроса с удаленной системой. RPC может найти применение при построении больших распределенных информационных систем, баз данных и систем управления. XDR позволяет программисту избежать написания специальных программ преобразования. Например, в разных ЭВМ используются различные форматы представления чисел с плавающей запятой. XDP берет на себя согласование форматов и делает написание прикладных программ машинно-независимым. Программы RPC-сервера используют большое число портов с нестандартизованными номерами. Для управления использованием этих портов имеется специальная программа (portmapper), которая имеет номер 100000, номер версии -2 и сама пользуется портом номер 111. Распределение номеров портов можно посмотреть с помощью программы: /usr/etc/rpcinfo -p
Отсюда видно, что некоторые программы имеют несколько версий, а каждая комбинация номера программы, версии и протокола имеет свой собственный номер порта. В таблице 4.5.16.1 приведены ссылки на некоторые RPC-программы, используемые с NFS. Таблица 4.5.16.1. Коды программ, используемых в NFS
Монтировщик вызывается NFS-клиентом для обеспечения доступа к файловой системе сервера. Взаимодействие с файловой системой производится с помощью указателей файлов (handle), которые для версии 2 требуют 32 байт, а для версии 3 - 64 байт. Хотя NFS с самого начала была сориентирована на применение UDP (что было оправдано для локальных сетей), в настоящее время она в равной мере использует и TCP. Это позволяет NFS работать уже в масштабе всего Интернет. Третья версия NFS предполагает увеличение числа байт на одну команду READ или WRITE с 8192 до 65535 (ограничение, связанное с размером IP-дейтограммы). Увеличена в третьей версии и предельная длина файлов, которая задается уже 64-, а не 32-битным числом. RLOGIN (RFC-1281) - процедура удаленного доступа, реализованная в 4BSD UNIX. RLOGIN позволяет администратору сети определить список ЭВМ, авторизация и доступ к которым является общими. Пользователь может организовать групповой доступ к разным ЭВМ, где он авторизован, сохраняя для себя возможность общения с любой из машин, не вводя каждый раз пароль. Одной из реализаций RLOGIN является RSH. RSH включает в себя интерпретатор команд. Форма обращения имеет вид: RSH имя_ЭВМ команда. RLOGIN позволяет взаимодействовать как с внутренними, так и с внешними ресурсами сети и с этой точки зрения предоставляет большие возможности чем Telnet.REXECD представляет собой резидентную управляющую программу (демон), которая позволяет исполнять команды на удаленной ЭВМ в рамках TCP/IP сетей. Команда, выданная одной ЭВМ, может быть выполнена на другой ЭВМ, при этом автоматически, если необходимо, осуществляется процедура авторизации. REXECD использует TCP в качестве транспортной среды. Существуют реализации для сред UNIX, AIX и DOS. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.15 Диалог в локальных сетях и в Интернет
UP:
4.5.8 Поиск узлов и людей
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
4.5.17 Сетевое моделирование
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||
|
Ни один проект крупной сети со сложной топологией в настоящее время не обходится без исчерпывающего моделирования будущей сети (речь, разумеется, идет не о России). Программы, выполняющие эту задачу, достаточно сложны и дороги. Целью моделирования является определение оптимальной топологии, адекватный выбор сетевого оборудования, определение рабочих характеристик сети и возможных этапов будущего развития. Ведь сеть, слишком точно оптимизированная для решений задач текущего момента, может потребовать серьезных переделок в будущем. На модели можно опробовать влияние всплесков широковещательных запросов или реализовать режим коллапса (для Ethernet), что вряд ли кто-то может себе позволить в работающей сети. В процессе моделирования выясняются следующие параметры:
Перечисленные задачи предъявляют различные требования к программам. В одних случаях достаточно провести моделирование на физическом (MAC) уровне, в других нужен уже уровень транспортных протоколов (например, UDP и TCP), а для наиболее сложных задач нужно воспроизвести поведение прикладных программ. Все это должно учитываться при выборе или разработке моделирующей программы. Ведь нужно учесть, что ваша машина должна в той или иной мере воспроизвести действия всех машин в моделируемой сети. Таким образом, машина эта должна быть достаточно быстродействующей и, несмотря на это, моделирование одной секунды работы сети может занять при определенных условиях не один час. Результаты моделирования должны иметь точность 10-20%, так как этого достаточно для большинства целей и не требует слишком много машинного времени. Следует иметь в виду, что для моделирования поведение реальной сети, надо знать все ее рабочие параметры: длины кабеля от концентратора до конкретной ЭВМ, задержки используемых кабелей, задержки концентраторов (этот параметр часто отсутствует в документации и его придется брать из документации на сетевой протокол, например из IEEE 802.3). Параметры могут быть определены и прямым измерением. Чем точнее вы воспроизводите поведение сети, тем больше машинного времени это потребует. Кроме того, вам предстоит сделать некоторые предположения относительно распределения загрузки для конкретных ЭВМ и других сетевых элементов, задержек в переключателях, мостах, времени обработки запросов в серверах. Здесь нужно учитывать и характер решаемых на ЭВМ задач. www/ftp-сервер или обычная персональная рабочая станция создают различные сетевые трафики. Определенное влияние на результат могут оказывать и используемые ОС. В случае моделирования реальной сети можно произвести соответствующие измерения, что иногда тоже не слишком просто. Учитывая сложность моделирования на одной ординарной ЭВМ, следует ограничиваться моделированием не более чем одной минуты для каждого из наборов параметров (этого времени достаточно для копирования практически любого файла через локальную сеть). Исключение может составлять моделирование внешнего трафика, но в этом случае весь локальный трафик должен рассматриваться как фоновый. 4.5.17.1 Аналитическое моделирование Определение характеристик сети до того, как она будет введена в эксплуатацию, имеет первостепенное значение. Это позволяет отрегулировать характеристики локальной сети на стадии проектирования. Решение этой проблемы возможно путем аналитического или статистического моделирования. Аналитическая модель сети представляет собой совокупность математических соотношений, связывающих между собой входные и выходные характеристики сети. При выводе таких соотношений приходится пренебрегать какими-то малосущественными деталями или обстоятельствами. Телекоммуникационная сеть при некотором упрощении может быть представлена в виде совокупности процессоров (узлов), соединенных каналами связи. Сообщение, пришедшее в узел, ждет некоторое время до того, как оно будет обработано. При этом может образоваться очередь таких сообщений, ожидающих обработки. Время передачи или полное время задержки сообщения d равно: D = Tp + S + W, где Tp, S и W, соответственно, время распространения, время обслуживания и время ожидания. Одной из задач аналитического моделирование является определение среднего значения D. При больших загрузках основной вклад дает ожидание обслуживания W. Для описания очередей в дальнейшем будет использована нотация Д. Дж. Кенделла: A/B/C/K/m/z, где А - процесс прибытия: В - процесс обслуживания; С - число серверов (узлов); К - максимальный размер очереди (по умолчанию -
D - постоянная вероятность; Наиболее распространенными схемами работы буферов являются FIFO (First-In-First-Out), LIFO (Last-In-First-Out) и FIRO (First-In-Random-Out). Например, запись M/M/2 означает очередь, для которой времена прихода и обслуживания имеют экспоненциальное распределение, имеется два сервера, длина очереди и число клиентов могут быть сколь угодно большими, а буфер работает по схеме FIFO. Среднее значение длины очереди Q при заданной средней входной частоте сообщений l и среднем времени ожидания W определяется на основе теоремы Литла (1961):
Для варианта очереди M/G/1 входной процесс характеризуется распределением Пуассона со скоростью поступления сообщений l. Вероятность поступления k сообщений на вход за время t равно:
Пусть N - число клиентов в системе, Q - число клиентов в очереди и пусть вероятность того, что входящий клиент обнаружит j других клиентов, равна: Пj = P[n=j], j=0,1,2,.
Тогда среднее время ожидания w:
s - среднеквадратичное отклонение для распределения времени обслуживания.Для варианта очереди M/G/1 H(t) = P[xё t] = 1 - e-mt (H - функция распределения времени обслуживания). Откуда следует s 2 = t 2.
Для варианта очереди m/d/1 время обслуживания постоянно, а среднее время ожидания составляет:
Аналитическая модель для сетей Ethernet (CSMA-CD) разработана Лэмом (S.S.Lam: "A Carrier Sense Multiple Access Protocol for Local Networks," Computer Networks, vol. 4, n. 1, pp. 21-32, January 1980). Здесь предполагается, что сеть состоит из бесконечного числа станций, соединенных каналами с доменным доступом. То есть станция может начать передачу только в начале какого-то временного домена. Распределение сообщений подчиняется закону Пуассона с постоянной скоростью следования l. Среднее значение времени ожидания для таких сетей составляет:
где е - основание натурального логарифма, t - задержка распространения сигнала в сети.
Рассмотрим вариант сети Ethernet на основе концентратора-переключателя с числом каналов N. При этом будет предполагаться, что сообщения на входе всех узлов имеют пуассоновское распределение со средней интенсивностью l i, распределение сообщений по длине произвольно. Сообщения отправляются в том же порядке, в котором они прибыли. Трафик в сети предполагается симметричным. Очередь имеет модель M/G/1. Среднее время ожидания в этом случае равно:
где
Среднее время распространения сообщения в сети равно
4.5.17.2 Симуляционное моделирование Симуляционное (статистическое) моделирование служит для анализа системы с целью выявления критических элементов сети. Этот тип моделирование используется также для предсказания будущих характеристик системы. Такое моделирование может осуществляться с использованием специализированных языков симулирования и требует априорного знания относительно статистических свойств системы в целом и составляющих ее элементов. Процесс моделирования включат в себя формирование модели, отладку моделирующей программы и проверку корректности выбранной модели. Последний этап обычно включает в себя сравнение расчетных результатов с экспериментальными данными, полученными для реальной сети. При статистическом моделировании необходимо задать ряд временных характеристик, например:
Полный список таких временных характеристик включает в себя значительно больше величин. В процессе моделирования рассчитываются следующие параметры:
Разумеется, реальный перечень вычисляемых параметров может быть существенно шире и определяется конкретными целями расчетов. Рассмотрим частную задачу определения среднего числа связей между процессорами (узлами). Предполагается, что полное число узлов равно N, а схема соединения узлов соответствует изображенной на рис. 4.5.7.1.
Рис. 4.5.7.1. Среднее расстояние от произвольного узла до всех остальных узлов равно D(N+1)/3, где D - расстояние между соседними узлами (предполагается константой). Возможны разные подходы к моделированию. Классический подход заключается в воспроизведении событий в сети как можно точнее и поэтапное моделирование последствий этих событий. В реальной жизни события могут происходить одновременно в различных точках сети. По этой причине для моделирования идеально подошел бы многопроцессорный компьютер, где можно воспроизводить любое число процессов одновременно. В любом случае необходимо выбрать некоторый постоянный временной интервал и считать, что события произошли одновременно, если расстояние между ними меньше этого интервала. Для сетей типа ethernet таким временным интервалом может быть бит-тайм (для 10-мегагбитного ethernet это 100нс). Понятно, что это уже отступление от реальности (ведь задержки в сетевом кабеле не кратны этому времени), но не слишком значительное. Надо сказать, что такого рода предположений при моделировании приходится делать много. По этой причине крайне важно сравнивать результаты моделирования с данными, полученными для реальной сети. Если отличия лежат в пределах 10-20%, можно считать, что сделанные предположения не увели программу слишком далеко от жизни и ею можно пользоваться для расчетов. Рассмотренный выше подход пригоден для моделирования сетевого коллапса, так как скорость расчетов здесь зависит от числа узлов и почти не зависит от сетевой загрузки. Другим подходом может стать метод, где для каждого логического сегмента (зоны столкновений) сначала моделируется очередь событий. При этом в каждой рабочей станции моделируется последовательность пакетов, ожидающих отправки. Эта очередь может время от времени модифицироваться, например, при получении ЭВМ пакета извне и необходимости послать на него отклик. После того как такая очередь для каждого сетевого объекта (сюда помимо ЭВМ входят мосты, переключатели и маршрутизаторы) построена, запускается программа отправки пакетов. При этом выбирается самый первый по времени пакет (ожидающий дольше других) и проверяются для него условия начала передачи (отсутствие несущей на входе сетевого интерфейса в данный момент и в течение 9,6 мксек до рассматриваемого момента - 96 тайм-битов). Если условия отправки выполнены, он "посылается" в сеть. Вычисляются моменты достижения им всех узлов данного логического сегмента, проверяются условия его столкновения с другими пакетами. Следует заметить, в этом подходе снимаются ограничения "дискретности" временной шкалы, использованной в предыдущем "классическом" подходе. Этот подход позволяет заметно ускорить расчеты при большом числе узлов, но малой загрузке сети. Проблемы реализации данной концепции моделирования связаны с обслуживанием довольно сложного списка, описывающего очередь пакетов, ожидающих отправки. В структуру этого списка включается и описание ситуации в сети на данный временной период. Дополнительные трудности сопряжены с поведением мостов, переключателей и маршрутизаторов, так как они могут вставлять в очередь дополнительные элементы, требующие немедленного обслуживания. Аналогичные вставки в очередь будут вызывать полученные станцией пакеты ICMP или TCP, требующие откликов. Причем такое вставление в очередь асинхронно по отношению к процедуре "отправки" пакетов. Очередь для всей локальной сети может быть единой, тогда пакеты разных логических сегментов должны быть помечены определенными флагами. При переходе из сегмента в сегмент флаг будет меняться. Возможно и построение независимых очередей для каждого из логических сетевых сегментов. Данный метод был использован студентом ТСС МФТИ Алексеем Овчаровым в его магитрской диссертации (2000 год) для определения свойств фрагмента сети в условиях, близких к предельным (загрузка на уровне 70-100%). Такие режимы трудно реализовать на практике без серьезного ущерба клиентам сети. Результаты расчета представлены на рис. 4.5.7.2.
Целью моделирования является определение зависимости пропускной способности сети и вероятности потери пакета от загрузки, числа узлов в сети, длины пакета и размера области столкновений. Исходные данные о структуре и параметрах сети берутся из базы данных. Ряд параметров сети задаются конфигурационным файлом (профайлом). Сюда могут записываться емкость буфера интерфейса и драйвера, время задержки обработки запроса (хотя в общем случае эта величина может также иметь распределение) и т.д.. К таким параметрам относятся также: MTU, MSS, TTL, window, некоторые значения таймаутов и т.д. Сеть разбивается на логические сегменты (зоны столкновений), в каждой из которых работает независимая синхронизация процессов (хотя эти процессы и влияют друг на друга через мосты, переключатели и маршрутизаторы). Полное моделирование сети с учетом рабочих приложений предполагает использование следующих распределений:
Последние два пункта существенным образом коррелированы с первым, так как используемые протоколы зависят от приложения, а активность узла может определяться, например длиной пересылаемого файла. По этой причине при полномасштабном моделировании сначала определяется, что собирается делать рабочая станция или сервер, (с учетом распределения по приложениям определяется характер задачи: FTP, MS explorer и т.д.). После этого разыгрываются параметры задания (длина файла, удаленность объекта и пр.), а уже на основе этого формируется фрагмент очереди пакетов. Задача первого этапа: проверка пропускной способности при вариации загрузки и длин пакетов, подсчет числа столкновений, проверка влияния размера буфера сетевого интерфейса на пропускную способность (влияние размера буфера переключателей по пути до адресата). Исходные данные для первого этапа:
Структура описания каждого из узлов включает в себя (формируется с учетом будущего расширения):
Формат описания топологии сети (список)
Процесс посылки пакета включает в себя (в соответствии с требованиями документа IEEE 802.3):
Попытка начала передачи предполагает проверку:
Процесс приема предполагает:
Центральный менеджер осуществляет:
Вариант 1 (равномерное распределение по времени) Для каждого узла устанавливается определенная средняя частота посылки пакетов. Время посылки предполагается случайным. Средняя частота может быть задана равной для всех узлов. Так как минимальный размер пакета равен 64 байт (51.2 мксек=512 бит-тактов), максимальная частота посылки пакетов составляет ~19.5 кГц. Минимальный средний период посылки пакетов определяется в бит-тактах и должен быть больше 512 бит-тактов. Понятно, что пока узел осуществляет передачу, он не может пытаться передать новый пакет (многозадачные, многопользовательские системы с несколькими сетевыми интерфейсами пока рассматривать не будем). По этой причине частота посылки пакетов однозначно определяется паузой между концом предыдущего пакета и началом нового (d). Среднее значение периода посылки пакетов равно Тпакета+96(бит-тактов)+d (значение d величина статистическая). Для каждого узла задается значение d (сначала равное для всех узлов). Если предположить равномерное распределение вероятности (передача пакета может начаться в любой бит-такт с равной вероятностью). При определении того, пытаться ли начинать передачу в данный бит-такт будет проверка условия: rndm<1/d (выполнение условия предполагает попытку начала передачи). Если вероятность прихода n пакетов на время t распределена по закону Пуассона:
Результатами моделирования могут являться (фиксируются отдельно для каждого набора входных параметров):
|
||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5.16 Некоторые другие процедуры Интернет
UP:
4.5.8 Поиск узлов и людей
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5 Процедуры Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Данный раздел наиболее динамично развивающаяся часть Интернет-технологий. Одни виды услуг устаревают и выходят из употребления (Gopher, WAIS, MOSAIC), другие появляются вновь (поисковые машины, например Alta Vista, NetScape, MSExplorer и др.). В последнее время несравненно большее внимание стали уделять сетевой безопасности, системам поиска и диагностическим аспектам работы с сетями. Безопасность вышла на первые позиции из-за внедрения Интернет в область финансов и бизнеса. Последнее время активно развивается технология мультимедиа (интеграция с кабельным телевидением), сфера развлечений (игровые серверы) и информационно-поисковые системы на основе техники WWW. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.5.1 Ping и Traceroute
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
При работе в Интернет время от времени возникают ситуации, когда нужно определить, работоспособен ли тот или иной канал или узел, а в случае работы с динамическими протоколами маршрутизации выяснить, по какому из каналов вы в данный момент работаете. Используется эта процедура и для оценки вероятности потери пакетов в заданных сегментах сети или каналах. Для решения этих задач удобна программа Ping. Ping - это процедура, которая базируется на ICMP- и UDP-протоколах пересылки дейтограмм и служит для трассировки маршрутов и проверки работоспособности каналов и узлов (в некоторых программных пакетах эта команда имеет имена trace, hopcheck, tracert или traceroute). Для решения поставленной задачи PING использует отклики протокола ICMP. Применяется PING и при
отладке сетевых продуктов. Трассировка может выполняться, например, посредством команды ping -q Usage:
Команда трассировки маршрута ИТЭФ - сервер научно-исследовательской станции США Мак-Мурдо в Антарктиде (запись в файл route.txt): ping -q mcmurdo-gw.mcmurdo.gov > route.txt Содержимое файла route.txt будет иметь вид:
Фантастика, мы пересекли туда и обратно Европу, два океана и США с востока на запад, побывали в Антарктиде и все это менее чем за полторы секунды. Ping позволяет не только проверить работоспособность канала, но измерить ряд его характеристик, включая надежность (например, версия ping для SUN): PING -s cernvm.cern.ch 100 64 (пакеты по 100 байт посылаются 64 раза) 108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=63. time=628. Ms ---- PING Statistics ---- 64 packets transmitted, 63 packets received, 1% packet loss (процент потерянных пакетов) round-trip (ms) min/avg/max = 600/626/702 Для получения большей точности следует послать большее число пакетов. В последней строке приведены результаты измерения RTT, где представлены минимальное/среднее/максимальное значения. Наибольшее число модификаций имеет BSD-версия ping, если на вашей ЭВМ нет этой удобной программы, можно воспользоваться общедоступной версией по адресу: ftp.uu.net /unix/bsd-sources/sbin/ping (см. также приложения). Сходную информацию позволяет получить и программа traceroute (использует непосредственно IP-пакеты):
traceroute -n cernvm.cern.ch При написании программ, использующих протокол ICMP, полезно воспользоваться отладочной опцией PING, которая позволяет получить на экране шестнадцатеричный образ посылаемого и получаемого пакетов:
Dump of outgoing packet Выдачи ради экономии места сильно сокращены. Тексты пакетов начинаются с кодов IP-версии (=4) и длины заголовка (=5), далее следует байт TOS=0, два байта длины пакета (01 1С) и т.д. в соответствии с требованиями IP-протокола. ping -d 300 ns.itep.ru (команда получения текста пакета-отклика на запрос) В принципе, процедуру Ping и Traceroute можно реализовать и с привлечением протоколов UDP и TCP. Рассмотрим следующую модель реализации Traceroute Посылаем последовательно по адресу IP(URL) IP-пакеты со значением TTL=1, 2,... и т.д. Если до Для данной методики реализации traceroute не существенно, какой протокол использовать, UDP, ICMP или TCP. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.5 Процедуры Интернет
UP:
4.5 Процедуры Интернет
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Открытый торговый протокол Интернет IOTP (Internet Open Trading Protocol; D. Burdett, RFC-2801, смотри также RFC-2935) создает базу коммерции через Интернет. Протокол не зависит от используемой платежной системы и т.д.. IOTP способен обрабатывать ситуации, когда продавец выступает в качестве покупателя, обеспечивает оформление и отслеживание доставки товаров и прохождения платежей, или совмещает некоторые или все перечисленные функции. IOTP поддерживает:
1.1. Коммерция в Интернет Рост Интернет и прогресс в электронной коммерции привносят огромные изменения в сферу бизнеса, политики, управления и в само общество. Методы, которые используются партнерами в торговле, обогатились и необратимо изменились. Наиболее заметные изменения характера торговли включают в себя:
1.2. Преимущества IOTP Разработки программ для электронной коммерции будут более привлекательны, если они окажутся совместимыми для разных разработчиков. Однако IOTP призван, прежде всего, решить проблему коммуникаций между различными решениями. Виды платежей IOTP предлагает стандартные рамки для инкапсуляции платежных протоколов. Это означает, что средства платежей смогут лучше взаимодействовать, если они встроены в программы, следующие протоколу IOTP. В результате базовые виды электронных платежей смогут найти более широкое распространение на большем разнообразии рабочих платформ. Продавцы Существует несколько преимуществ для торговцев:
Банки и финансовые организации Существует несколько преимуществ для банков и финансовых организаций:
- предоставление услуг клиентам продавцов
Покупатели Для покупателей также имеется несколько преимуществ:
1.3. Основы IOTP Протокол описывает содержимое, формат и последовательность сообщений, которые пересылаются между партнерами электронной торговли - покупателями, торговцами и банками или финансовыми организациями. Протокол спроектирован так, чтобы обеспечить его применимость при любых схемах электронных платежей, так как он реализует весь процесс продажи, где передача денег всего лишь один шаг из многих. Схемы платежей которые поддерживает IOTP включают MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton и т.д.. Каждая схема содержит некоторый обмен сообщениями, который является характерным именно для нее. Эти схемно-зависимые части протокола помещены в приложения к данному документу. Документ не предписывает участникам, какое следует использовать программное обеспечение или процесс. Он определяет только необходимые рамки в пределах которых реализуется торговая операция. 2. Введение Открытый торговый протокол Интернет определяет некоторое число различных операций IOTP:
Эти операции считаются базовыми, позднее могут быть определены другие операции IOTP. Каждая из перечисленных выше операций IOTP включает в себя:
2.1. Торговые роли Торговые роли идентифицируют различные обязанности, которые может выполнять организации в процессе торговли. В IOTP используется пять торговых ролей, которые проиллюстрированы на рис. .1.
Рис. .1. Торговые роли в IOTP Определены следующие роли:
Роли могут выполняться одной организацией или различными организациями. Например:
Заметим, что в этой спецификации, если не указано обратного, когда используются слова Покупатель (Consumer), Продавец (Merchant), Кассир (Payment Handler), Агент доставки (Delivery Handler) или обслуживание потребителя (Customer Care Provider), подрузамевается торговая роль (Trading Role), а не конкретная организация. Любая конкретная организация может выполнять множество ролей. Например компания, которая продает товары или услуги через Интернет, может выполнять роь продавца при продаже товара или услуги и роль потребителя, когда компания покупает товары или услуги сама. 2.2. Торговый обмен Протокол Интернет для торговли (The Internet Open Trading Protocols) идентифицируют четыре торговых обмена, которые включают обмен данными между торговыми ролями. Среди них:
Операции IOTP состоят из различных комбинаций этих торговых обменов. Например, операция покупки IOTP включает в себя обмены Предложения, Оплаты и Доставки. А операция обмена ценностями IOTP состоит из предложения и двух обменов оплаты. Торговые обмены (Trading Exchanges) состоят из торговых компонентов, которые передаются между различными торговыми ролями. Где возможно, число круговых задержек в операциях IOTP минимизируется путем объединения компонентов нескольких торговых обменов в комбинированные сообщения IOTP. Например, операция покупки IOTP объединяет компонент организации доставки и компонент предложения, для того чтобы избежать лишних запросов и откликов Потребителя. Ниже каждый торговый обмен IOTP описан более детально. Для простоты описания они рассматриваются как независимые процедуры. 2.2.1. Предложение Целью обмена Предложения является обеспечение Покупателя информацией о сделке с тем чтобы он мог решить, продолжать ли ему эту сделку. Это продемонстрировано ниже на рис. .2.
Рис. .2. Предложение Предложение использует следующие торговые компоненты, которые пересылается между покупателем и продавцом.
Точное содержание информации, выданной Продавцом Покупателю, варьируется в зависимости от типа операции IOTP. Например:
Информация, предоставляемая покупателем продавцу, предоставляется различными способами, например, она может быть получена.
2.2.2. Платежный обмен Целью платежного обмена (Payment Exchange) является оплата, производимая покупателем еассиру или наоборот, используя вид и протокол платежа, выбранные покупателем. Второй целью является опционное обеспечение покупателя платежной распиской (Payment Receipt), которая может использоваться для связи платежа с его причиной, как это описано в обмене предложения (Offer Exchange). Обмены платежа могут реализовываться различными способами. Наиболее общий случай, где сделка зависит от типа и платежного протокола, показан на диаграмме рис. .3. Возможны и более простые платежные обмены.
Рис. .3. Платежный обмен Платежный обмен использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и кассир:
Пример платежного обмена представленного выше, является наиболее общим случаем. Возможны и более простые варианты. Например, если сумма платежа не зависит от выбранного типа платежа и платежного протокола, тогда информация, генерируемая на этапе 3, может быть послана покупателю одновременно с формированием компонента список типов платежей (Brand List) на этапе 1. Эти и другие вариации описаны в разделе базовые торговые операции IOTP (смотри раздел 9.1.8). 2.2.3. Обмен доставки Целью обмена доставки является обеспечить физическую или сетевую доставку купленного товара или услуги покупателю. Второй целью служит передача покупателю "декларации о доставке", предоставляя дополнительную информацию о доставке, такую как номера накладной или номер трайлера, с помощью которого будет доставлен груз. Результат доставки может быть также подтвержден с помощью электронной подписи. Обмен сообщениями показан на диаграмме ниже.
Рис. .4. Обмен доставки Обмен доставки использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и агент доставки:
2.2.4. Аутентификационный обмен Целью аутентификационного обмена является допущение одной организации, например, финансовому учреждению, иметь возможность проверить, что другая организация, например Покупатель, является тем, за кого себя выдает. В аутентификационный обмен вовлечены:
Это проиллюстрировано на диаграмме ниже.
Рис. .5. Обмен аутентификации Обмен аутентификации использует следующие торговые компоненты, которыми обмениваются между собой две организации:
2.3. Обзор базового уровня IOTP Здесь описываются операции, которые образуют основу IOTP. Главными факторами, определяющими реализацию IOTP, являются роли, которые поддерживает реализованное решение. Роли в пределах IOTP более детально описаны в разделе 2.1. Базовыми ролями являются: продавец, покупатель, кассир, агент доставки и агент обслуживания покупателя. Существует три типа Кассиров:
Ниже приведенная таблица определяет для каждой роли операции IOTP и торговые блоки, которые должны поддерживаться для каждой роли.
В выше приведенной таблице:
Решения IOTP должны поддерживать все операции IOTP и торговые блоки, необходимые, по крайней мере, для одной из ролей (колонка), как это описано в приведенной выше таблице для решений, которые считаются поддерживающими IOTP. 3. Структура протокола В предыдущем разделе дано введение, которое объясняет:
Ниже описано:
3.1. Обзор Структура сообщения IOTP и его отношения с торговыми блоками и компонентами проиллюстрировано на диаграмме ниже.
Рис. .6. Структура сообщения IOTP На диаграмме определена концепция блока ссылок операции (Transaction Reference Block). Такой блок содержит среди прочего уникальный идентификатор операции IOTP. Кроме того, каждому блоку и компоненту присваивается ID-атрибут (смотри раздел 3.4), который является уникальным в пределах IOTP. Следовательно, комбинации ID-атрибута и глобального уникального идентификатора в блоке ссылок операции достаточно, для однозначной идентификации любого торгового блока или компонента. 3.1.2. Операции IOTP Предопределенный набор сообщений IOTP, которыми обмениваются торговые роли, составляют операцию IOTP. Это проиллюстрировано ниже на диаграмме.
Рис. .7. Функциональная схема операция IOTP На приведенной выше диаграмме Интернет рассматривается в качестве транспортного механизма. Но это не всегда так. Сообщения IOTP могут транспортироваться с использованием различных механизмов. В этой версии IOTP специфицированы следующие операции IOTP (смотри раздел 9):
3.2. Сообщение IOTP Как было описано выше, сообщения IOTP представляют собой [XML] документы, которыми обмениваются торговые роли, участвующие в сделке. XML-определение сообщения IOTP выглядит следующим образом. <!ELEMENT IotpMessage
) > Содержимое: TransRefBlkсодержит информацию, которая характеризует сообщение IOTP в пределах операции IOTP (смотри раздел 3.3)
Атрибуты:
3.2.1. XML Document Prolog Сообщение IOTP является корневым элементом XML-документа. Оно, следовательно, должно предшествоваться соответствующим прологом документа XML. Например: <?XML Version='1.0'?> 3.3. Блок ссылок операции (Transaction Reference Block) Блок ссылок транзакции содержит информацию, которая идентифицирует IOTP-транзакцию и сообщение IOTP. Блок ссылок операции включает в себя:
Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом: <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > Атрибуты:
Cодержимое:
3.3.1. Идентификационная компонента транзакции Идентификационная компонента транзакции содержит информацию, которая однозначно задает транзакцию IOTP. Ее определение представлено ниже: <!ELEMENT TransId EMPTY >
Атрибуты:
Значение IotpTransType управляется процедурой, описанной в разделе 12 IANA Considerations, которая позволяет пользователю определить величины IotpTransType. В последних версиях IOTP, этот список будет расширен с целью поддержки различных типов транзакций IOTP. Вероятно, будет поддержан динамический тип (Dynamic), который указывает, что последовательность шагов в транзакции не является стандартной.
Главным назначением этого атрибута является обеспечение альтернативного пути идентификации транзакции путем спецификации времени его запуска. Некоторые системы не могут генерировать временные метки. В этом случае этот атрибут должен содержать значение "NA" (Not Available). 3.3.2. Идентификатор сообщения Компонент Id-сообщения предоставляет контрольную информацию о сообщении IOTP, а также однозначно идентифицирует сообщение в рамках транзакции IOTP. Его определение выглядит следующим образом. <!ELEMENT MsgId EMPTY >
Атрибуты:
3.3.3. Компонент Related To Компонент Related To связывает транзакции IOTP с другими транзакциями или другими событиями с помощью идентификаторов этих событий. Определение этого компонента представлено ниже. <!ELEMENT RelatedTo (PackagedContent) >
RelnKeyWords NMTOKENS #IMPLIED >
Значения RelationshipType управляются процедурами, определенными в разделе 12 IANA Considerations, которые позволяют пользователю определить свои значения атрибута.
Целью атрибута является обеспечение торговых ролей, включенных в транзакцию IOTP, объяснением природы отношений между транзакциями. Следует позаботиться о том, чтобы слова, использованные в атрибуте Relation, правильно указывали "направление" отношений. Например: одна транзакция может быть возвратом денег для другой выполненной ранее транзакции. В этом случае транзакция, которая возвращает деньги, должна содержать слова атрибута Relation, такие как "возврат за", а не "возврат кому" или просто "возврат".
Cодержимое:
3.4. ID-атрибуты IOTP-сообщения, блоки (т.e. блоки ссылок операции и торговые блоки), торговые компоненты (включая ID-компонент транзакции и компонент подписи) и некоторые их дочерние элементы задаются атрибутом "ID" XML, который служит для идентификации этих XML-элементов. Эти элементы используются так, что один элемент может ссылаться на другой. Всем этим атрибутам присваиваются ID. Значения каждого ID-атрибута является уникальным в пределах транзакции IOTP т.e. набор IOTP-сообщений, который имеет тот же самый компонент ID транзакции. Однажды присвоенное значение ID-атрибута элемента никогда не меняется. Это означает, что когда элемент копируется, значение ID-атрибута остается неизменным. Как следствие можно использовать эти идентификаторы для ссылки и нахождения содержимого любого сообщения IOTP, блока или компонента (смотри раздел 3.5). 3.4.1. Определение ID-атрибутов сообщений IOTP ID-атрибут Id-компонента IOTP-сообщения должен быть уникальным в пределах транзакции IOTP. Его определение представлено ниже: IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
Для сообщений, которые содержат торговый блок информационного запроса или блок запроса Ping, префикс делается равным "I" (Inquiry). Для сообщений, которые содержат торговый блок отклика на информационный запрос или блок отклика Ping, префикс равен "Q". Префикс для других торговых ролей в сделке содержится в компоненте Organisation (организации) и прописывается обычно Продавцом. Ниже представлены рекомендуемые значения:
Префиксы должны содержать один символ. NameChar имеет то же значение, что и определение NameChar в [XML].
Короче Id-компонент первого сообщения IOTP, посланного Покупателем будет иметь ID-атрибут "C1", второе - "C2", третье - "C3" и т.д. Цифра имеет то же определение что и в [XML]. 3.4.2. Определения ID-атрибута для блока и компонента ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение: BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
В IOTP, торговые компоненты и торговые блоки копируются из одного сообщения IOTP в другое. I D-атрибут не изменяется, когда существующий торговый блок или компонент копируется в другое сообщение IOTP.
Короче, первый новый блок или компонент добавляется ко второму посылаемому сообщению IOTP, например, первый ID-атрибут - "C2.1", второй - "C2.2", третий - "C2.3" и т.д. Цифра имеет то же определение, что и в [XML]. 3.4.3. Пример использования ID-атрибутов На диаграмме проиллюстрировано, как используются значения ID-атрибутов.
Рис. .8. Пример использования ID-атрибутов 3.5. Элемент References Торговый компонент или один из его дочерних XML элементов может содержать XML-атрибут, который указывает на другой блок (т.e. Блок ссылок транзакции или торговый блок) или торговый компонент (включая идентификатор транзакции и компонент подписи). Эти ссылки элементов используются для многих целей, ниже предлагается несколько примеров:
Элементы Reference всегда содержат значение ID-атрибута блокаили компонента. Идентификация сообщения IOTP, торговогоблока или торгового компонента, на который указывает ссылка элемента, включает в себя наождение XML-элемента, который:
Термин "соответствует" в данной спецификации имеет то же определение, что и в [XML]. Пример "соответствия" ссылки элемента показан ниже.
Рис. .9. Ссылки элемента (Element References) Атрибуты ссылки элемента определены как "NMTOKEN", а не "IDREF" (смотри [XML]). Это сделано потому, что IDREF требует, чтобы элемент XML, на который ссылаются, принадлежал тому же XML-документу. В IOTP это не всегда так. 3.6. Расширение IOTP Базовая версия IOTP определяет минимальный протокол, с которым система, поддерживающая IOTP, должна быть способна работать. По мере разработки новых версий IOTP будут определяться дополнительные типы транзакций IOTP. Кроме того, базовая и будущие версии IOTP будут поддерживать два механизма расширения возможностей IOTP пользователем: o дополнительные XML-элементы 3.6.1. Дополнительные XML-элементы Имена XML элементов и атрибутов используемых в IOTP составляют пространство имен [XML], как это определено атрибутом xmlns элемента IotpMessage. Это позволяет Th IOTP поддерживать включение дополнительных XML-элементов в IOTP-сообщения посредством использования пространства имен XML. Используя XML Namespaces, дополнительные XML-элементы могут быть включены на любом уровне в сообщение IOTP, включая: o новые торговые блоки При этом следуют определенным правилам:
Для того чтобы быть уверенным, что дополнительные элементы XML могут быть обработаны корректно, IOTP резервирует использование специального атрибута, IOTP:Critical, который принимает значение True или False и может появляться в дополнительных элементах, добавляемых к IOTP-сообщению. Целью этого атрибута является допущение IOTP проинформировать приложение, можно ли безопасно продолжить транзакцию. В частности:
Для того чтобы гарантировать то, что документы, содержащие "IOTP:Critical" корректны, этот атрибут объявляется частью DTD для дополнительных элементов в форме:
3.6.2. Opaque Embedded Data Если IOTP должен быть расширен с помощью Opaque Embedded Data, тогда к инкапсулированным данным должен быть применен элемент Packaged Content (смотри раздел 3.7). 3.7. Элемент PackagedContent Элемент PackagedContent поддерживает концепцию потока вложенных данных, преобразованную, чтобы защитититься от неверной интепретации транспортной системой и гарантировать совместимость с XML. Примеры использования этого элемента в IOTP включают: o для инкапсуляции сообщений платежной системы, таких как сообщения SET, В общем, он используется для инкапсуляции одного или более потоков данных. Этот поток данных имеет три стандартизованных атрибута, которые служат для идентификации, декодирования и интерпретации содержимого. Его определение представлено ниже. <!ELEMENT PackagedContent (#PCDATA) > Атрибуты:
<ABCD> Атрибут имени может быть опущен, например, если имеется только один элемент PackagedContent.
Cодержимое:
3.7.1. Packaging HTML PackagedContent может содержать HTML. В этом случае должны выполняться следующие условия:
Если выше приведенные соглашения не реализуются, например, включением внешних ссылок, которые должны быть разрешены, тогда получатель HTML должен быть об этом проинформирован. В качестве руководства разработчику следует иметь в виду, что значения атрибутов Name, относящиеся к элементам PackagedContent, должны допускать извлечение каждого PackagedContent в каталог и отображение HTML непосредственно. 3.7.2. Пакетирование XML Рекомендуется поддержка XML. Когда необходимо отобразить XML, например, чтобы представить содержимое описания заказа Покупателю, разработчики должны следовать новейшим рекомендациям консорциума World Wide Web. 3.8. Идентификация языков IOTP использует идентификацию языка [XML] для того, чтобы специфицировать, какие языки применены в тексте и атрибутах IOTP-сообщения. Для того чтобы определить, какие элементы XML содержат атрибуты xml:lang, нужно придерживаться следующих принципов:
Атрибуты xml:lang, которые следуют этим принципам, включаются в торговые элементы, а их дочерние XML-элементы определены в разделе 7. Отправитель сообщения, обычно Покупатель, может указать свои предпочтения для языка и символьного набора путем спецификации соответствующего списка в Id-компоненте сообщения (смотри раздел 3.3.2). Заметим, что получатель такого сообщения не обязан строго следовать этим предпочтениям, так как он может не иметь необходимых средств для этого. Это также означает, что возможность работать с этими списками не является требованием данной спецификации. Однако возможность реагировать, используя один из объявленных языков или символьных наборов является желательной. 3.9. Безопасные и небезопасные позиции в сети IOTP содержит несколько "сетевых позиций", которые определяют место, куда молгут быть посланы сообщения IOTP-сообщения. Сетевые позиции (Net Locations) бывают двух типов:
Заметим, что должны присутствовать безопасная или небезопасная сетевая позиция (Net Location) или обе обязательно. Если присутствует одна из двух сетевых позиций, только она и может использоваться. Там где представлены оба типа сетевых позиций, допускается использование обоих, в зависимости от предпочтения отправителя сообщения. 3.10. Аннулированные транзакции Любая торговая роль, вовлеченная в транзакцию IOTP может аннулировать эту транзакцию в любой момент. 3.10.1. Аннулирование транзакций Транзакции IOTP аннулируются путем посылки сообщения IOTP, содержащего блок Cancel с соответствующим компонентом Status, другой торговой роли, вовлеченной в торговый обмен. Блок Cancel может быть послан асинхронно по отношению к любому другому сообщению IOTP. В частности он может быть послан до посылки или после получения сообщения от другой торговой роли. Если транзакция IOTP аннулирована во время торгового обмена (т.e. интервал между отправкой блока "запрос" и получением соответствующего ему блока "отклик"), тогда блок Cancel посылается тому же адресату, что и следующее сообщение IOTP в торговом обмене. Если покупатель аннулирует транзакцию после завершения торгового обмена (т.e. блок "отклик" торгового обмена уже получен), но до завершения тразакции IOTP, покупатель посылает блок Cancel с соттветствующим компонентом Status сетевой позиции, идентифицированной SenderNetLocn или SecureSenderNetLocn, содержащимся в компоненте опции протокола (смотри раздел 7.1), который размещен в блоке TPO (смотри раздел 8.1). Это обычно торговая роль Продавца. Покупатель не должен посылать блок Cancel после того как завершилась транзакция IOTP. Аннулирование всей транзакции будет рассматриваться как техническая ошибка. После аннулирования транзакции IOTP, Покупатель должен обратиться в сетевую позицию, специфицированную атрибутом CancelNetLocn, содержащимся в элементе торговой роли для организации, которой был послан блок Cancel. Торговые роли, отличные от Покупателя, могут аннулировать транзакцию в следующих случаях:
Если торговая роль, отличная от Покупателя, аннулирует транзакцию в любое другое время, это должно восприниматься получателем, как ошибка. 3.10.2. Обработка аннулированных транзакций Если блок Cancel получен Покупателем в момент, когда аннулирование разрешено, тогда покупатель должен прервать транзакцию. Если блок Cancel получен торговой ролью, отличной от Покупателя, тогда торговой роли следует ожидать, что Покупатель обратится к сетевойму узлу, специфицированному атрибутом CancelNetLocn, содержащимся в элементе Trading Role. 4. Обработка ошибок IOTP IOTP создан как протокол запросов/откликов, где каждое сообщение состоит из нескольких торговых блоков, которые содержат некоторое. Существует несколько взаимосвязанных соображений при обработке ошибок, ретрансмиссий, дубликатов и тому подобное. Эти факторы приводят к тому, что IOTP вынужден обрабатывать поток сообщений не просто как последовательность запросов и откликов. Кроме того может встретится большое разнообразие ошибок в сообщениях, на транспортном уровне или в торговых блоках или компонентах. Датее будет рассмотрено, как IOTP обрабатывает ошибки, повторные попытки и дубликаты сообщений. Могут произойти различные ошибки:
Глубина ошибки показывает, где произошла ошибка (при транспортировке, при составлении сообщения или на уровне блока/компонента) 4.1. Технические ошибки К техническим ошибкам относятся ошибки, которые не зависят от значения сообщения. Это означает, что они могут влиять на любую попытку передачи. Обычно они обрабатываются стандартным образом с ограниченным числом опций для пользователя. Такие ошибки могут быть: o повторная попытка передачи; Когда связь работает достаточно хорошо, техническая ошибка индицируется компонентом Error (смотри раздел 7.21) в блоке Error (смотри раздел 8.17), посланным партнером, который детектировал ошибку в сообщении IOTP, партнеру, пославшему ошибочное сообщение. Если связь слишком плохая, сообщение, которое было послано, может не достичь адресата. В этом случае может произойти таймаут. Коды ошибок, соответствующие техническим ошибкам записываются в компоненте Error, где перечисляются различные технические ошибки, которые могут случиться. 4.2. Рабочие ошибки Рабочие ошибки могут случиться, когда IOTP-сообщения "технически" вполне корректны. Они связаны с определенным процессом, например, предложение, платеж, доставка или аутентификация, где каждый процесс имеет разный набор возможных рабочих ошибок. Например, "Недостаточно средств" является сообщением об ошибке при платеже, но не имеет никакого значения для доставки, в то время как "Back ordered" возможное сообщение об ошибке доставки, но не имеет смысла для платежа. Рабочие ошибки индицируются компонентом Status (смотри раздел 7.16) "блока отклика" соответствующего типа, например, блока Payment Response или Delivery Response. Это допускает любой дополнительный отклик, связанный с информацией, которая необходима для пояснения возникшей ошибки. Рабочие ошибки должны обычно представляться пользователю так, чтобы он мог решить, что делать дальше. Например, если ошибка связана с недостаточностью платежных средств в предложении, независящим от типа платежа (смотри раздел 9.1.2.2), пользователь может пожелать выбрать другой счет того же типа или другой тип платежа или даже другую платежную систему. Иными словами, если реализация, базирующаяся на IOTP, допускает это и пользователь может перевести дополнительные средства на счет и совершить еще одну попытку. 4.3. Глубина ошибки Три уровня, на которых могут произойти ошибки в IOTP, включают транспортный уровень, уровень сообщения и уровень блока. 4.3.1. Транспортный уровень Этот уровень ошибки указывает фундаментальную проблему в транспортном механизме, через который осуществляется передача в IOTP. Все ошибки транспортного уровня являются техническими и индицируются явно на транспортном уровне, как "No route to destination" из TCP/IP или через таймаут, когда не получено отклика на посланный запрос. Единственно разумным автоматическим действием, когда сталкиваешся с ошибками транспортного уровня, является попытка повторной передачи, а после нескольких попыток информирование пользователя об этом. Неявная индикация ошибки, которая может быть получена, является зависимой от транспортной среды и для принятия решения относительно конкретных действий следует обращаться к документации транспортного приложения IOTP. Таймауты здесь являются функцией как транспорта так и платежной системы, если в запрос инкапсулирована платежная информация. Для выяснения параметров таймаутов и повторных передач рекомендуется обращаться к документации по транспортной и платежной системам. Часто нет способа непосредственно проинформировать партнера об ошибках транспортного уровня, при таких обстоятельствах такие события должны регистрироваться и, если автоматическое восстановление системы не сработало, а в процесс вовлечен человек-пользователь, его следует проинформировать об инциденте. 4.3.2. Уровень сообщения Этот уровень ошибки указывает на фундаментальную техническую проблему с IOTP-сообщением в целом. Например, XML документ некорректно оформлен, сообщение имеет слишком большую длину для получателя, или обнаружена ошибка в блоке ссылок транзакции (смотри раздел 3.3). Все ошибки уровня сообщений являются техническтими ошибками и индицируются компонентами Error (смотри раздел 7.21), послаными партером. Компонент Error включает в себя атрибут Severity (степень угрозы), который указывает, является ли ошибка предупреждениеим и может быть проигнорирована, TransientError и что повторная попытка может разрешить проблему или HardError, что говорит о срыве транзакции. Технические ошибки (смотри раздел 7.21.2; Коды ошибок), которые являются ошибками уровня сообщения, включают:
Заметим, что проверки блока подписи включают проверку, где это возможно, того, что каждый из компонентов подпися вычислен правильно. Если подпись вычислена неправильно, тогда данные, которые покрываются подписью не будут признаны истинными. Процедура проверки подписи описана в разделе 6.2. 4.3.3. Уровень блоков Ошибки блочного уровня указывают на проблему с блоком или одним из его компонентов в сообщении IOTP (помимо блоков ссылок транзакции или подписи). Сообщение передано корректно, структура всего сообщения, включая блоки ссылок транзакции и подписи, вполне разумна, но имеется ошибка, связанная с каким-то другим блоком. Ошибки блочного уровня могут быть:
Технические ошибки далее делятся на:
Если случислась техническая ошибка, связанная с блоком или компонентом, формируется компонент Error для посылки отправителю некорректного сообщения. 4.3.3.1. Проверки атрибутов блочного уровня и элементов Проверки элемента и атрибута блочного уровня производятся только в пределах одного и того же блока. Проверки, которые включают в себя перекрестные сверки с другими блоками, относятся к проверкам согласованности блоков и компонент. Проверки элемента и атрибута блочного уровня включают в себя:
4.3.3.2. Проверки согласованности компонентов и блоков Проверки согласованности компонентов и блоков состоит из:
Если блок проходит проверку атрибутов и элементов блочного уровня и контроль согласованности блоков и компонентов, тогда он обрабатывается IOTP-приложением или какой-то оконечной системой, такой как платежный сервер. 4.3.3.3. Переходные технические ошибки Во время обработки блока могут произойти временные отказы, которые в принципе могут быть преодолены позднее повторной передачей исходного сообщения. В этом случае партнер информируется о переходной ошибке путем посылки компонента Error (смотри раздел 7.21) с атрибутом Severity равным TransientError и атрибутом MinRetrySecs равным некоторому значению, удобному для используемого транспортного механизма и/или платежного протокола (смотри соответствующие приложения транспортного и платежного протокола). Заметим, что переходные технические ошибки могут генерироваться любыми торговыми агентами, вовлеченными в транзакцию. 4.3.3.4. Рабочие ошибки блочного уровня Если в процессе платежа или доставки происходит рабочая ошибка, тогда присылается соответствующий тип блока отклика, содержащий компонент Status (смотри раздел 7.16) с атрибутом ProcessState равным Failed и CompletionCode, указывающим на природу проблемы. Некоторые рабочие ошибки могут быть переходными, при таких обстоятельствах Покупатель может справиться с ситуацией самостоятельно и успешно завершить транзакцию каким-то способом. Например, если на кредитной карточке покупателя недостаточно денег, он может воспользоваться для покупки другой кредитной карточкой. Преодоление переходных рабочих ошибок зависит от CompletionCode. Для понимания имеющихся возможностей смотри определение компонента Status. Заметим, что для рабочих ошибок не формируется компонент или блок Error. 4.4. Idempotency, последовательность обработки и поток сообщений IOTP-сообщения представляют в действительности комбинацию блоков и компонентов, как это описано в 3.1.1 (Структура сообщений IOTP). В будущем при расширении IOTP разнообразие таких комбинаций еще более расширится. Важно, что многократные приемы/передачи одного и того же запроса изменения состояния имеют тот же результат, как и однократная передача/прием этого запроса. Это называется идемпотентностью. Например, покупатель, оплачивая заказ, желает оплатить его только раз. Большинство сетевых транспортных механизмов имеют определенную вероятность доставки одного сообщения несколько раз или не доставить ни разу, что потребует позднее повторной передачи. С другой стороны, запрос состояния можно повторять и при этом каждый раз должно обрабатываться вновь полученное значение. Правильная реализация IOTP может моделироваться по разному различными процессами. 4.5. Последовательность обработки для роли сервера "Роли сервера" - это любые торговые роли, несовпадающие с ролью Покупателя. Они являются "ролями сервера", так как они обычно получают запросы, которые они должны обработать и посылать на них отклики. Однако Роли сервера могут также инициировать транзакции. Более конкретно роли сервера должны быть способны:
4.5.1. Инициализация транзакций Роли сервера могут инициировать большое число различных транзакций. В чатности:
4.5.2. Обработка входных сообщений Обработка входных сообщений включает в себя:
4.5.2.1. Проверка структуры и идентификация сообщений Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика. Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd. Если входное сообщение сформировано правильно, но IotpTransId не может быть идентифицировано, генерируется компонент Error с :
Далее получатель вводит компонент Error в блок ошибки с новым компонентом TransactionId с новым IotpTransId и отправляет его отправителю исходного сообщения. 4.5.2.2. Выявление и обработка дублированных сообщений Если входное сообщение может быть идентифицировано, как корректное, то проверяется, не получалось ли раньше точно такое же сообщение. Под идентичностью здесь подразумевается, что все блоки, компонентя, элементы, значения атрибутов и элементы содержимого тождественны. Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH]. Если получено сообщение, прежде чем его исследовать, нужно проверить, завершилась ли обработка предыдущего. Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее. 4.5.2.3. Обработка недублированных сообщений Если установлено, что сообщение не является дубликатом ранее полученного, тогда оно обрабатывается. Процедура обработки включает в себя:
Этот подход к обработке дублированных входных сообщений означает, что если получены два совершенно идентичных сообщения, будут посланы два идентичнх отклика. Это применимо также к информационным запросам и транзакциям Ping, когда в действительности состояние транзакции или возможность обработки сервером может измениться. Если требуется текущее состояние транзакции или сервера, тогда используется транзакция с новым значением ID-атрибута компонента MsgId. Процесс обработки входного сообщения должен проверить, свободна ли остальная система. Если сервер слишком занят, он должен выдать компонент Error с атрибутом Severity равным Transient Error и кодом ошибки равным SystemBusy, после чего вернуть отправителю входное сообщение, запрашивая тем самым повторную присылку этого сообщения спустя некоторое время. Некоторые серверы могут оказаться перегруженными из-за неожиданного всплеска загрузки. Данный подход позволяет преодолевать ситуации с кратковременными пиковыми нагрузками, запрашивая отправителя переслать сообщение несколько позже. Проверка того, что транзакция не зафиксировала ошибку и не оказалась аннулированной. Предполагается следующий контроль:
Если это имеет место, сообщение игнорируется. Транзакция с серьезной ошибкой или аннулированная транзакция не может быть перезапущена. Если с транзакцией все в порядке, производится поиск ошибок на уровне сообщения. Это включает в себя:
Проверка ошибок уровня блоков включает:
Если сообщение содержит какие-то инкапсулированные данные, то, если возможно, они проверяются на наличие ошибок. 4.5.2.4. Проверка ошибок в последовательности блоков Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции IOTP" следует интерпретировать как "содержится в сообщении IOTP, где TransRef Block включает в себя IotpTransId, который указывает на данную танзакцию". Так, например, "Если ошибка или аннулированный блок относится к транзакции IOTP, которая не распознана, тогда..." следует интерпретировать как "Если ошибка или аннулированный блок содержатся в сообщении IOTP, TransRefBlock включает в себя IotpTransId, который относится к транзакции IOTP, которая не распознана, тогда...". Ошибки в последовательности прихода блоков зависят от блока. Блоки, где требуется проверка последовательности:
Если сгенерированы какие-либо компоненты Error, то они должны быть собраны в блок Error для посылки отправителю входного сообщения. Заметим, что блоки Error следует отсылать назад отправителю сообщения и ErrorLogNetLocn для торговой роли отправителя, если это специфицировано. Описанная выше проверка последовательности аутентификационных откликов и платежных запросов поддерживает повторение запросов Покупателя, если предыдущая операция не прошла, например: o потому что не получен корректный отклик (напр., пароль) на аутентификацию или o не удалось произвести оплату, так как нехватает денег на кредитной карточке. Обработка входного сообщения, лишенного ошибок Если входное сообщение прошло предыдущие проверки, то оно должно быть обработано и послан, если требуется, отклик. Заметим, что:
Если выходное сообщение сгенерировано, оно должно быть запомнено, так чтобы иметь возможность, если потребуется, послать его повторно. Заметим, что выходные сообщения, которые содержат переходные ошибки, не запоминаются, так что они формируются заново, при их повторной посылке. 4.5.3. Аннулирование транзакции Этот процесс используется, чтобы аннулировать транзакцию, Этот процесс служит для аннултрования транзакции работающей на сервере IOTP. Он инициируется некоторым другим процессом, как результат внешнего запроса отдругой системы или сервера, который играет ту же торговую роль. Обработка такого запроса требует:
Аннулирование транзакции на сервере IOTP обычно возникает по деловым причинам. Например продавец может попытаться безуспешно аутентифицироваться несколько раз, после чего решает аннулировать транзакцию. Следовательно процесс, который решаетпроизвести такое действие, должен послать сообщение из процесса/сервера с инструкцией о том, какую транзакцию следует аннулировать. 4.5.4. Повторная посылка сообщений Сервер должен периодически проводить проверки, нет ли транзакций, ожидающих сообщения-отклики и неполчивших их своевременно. Такая задержка может быть связана со следующими факторами:
Если не получено никакого сообщения, оригинальное сообщение должно быть послано повторно. Это должно производиться некоторое число раз в зависимости от надежности используемого транспортного механизма. Если не получено отклика в течении оговоренного времени, транзакция прерывается по таймауту. В этом случае, состояние транзакции устанавливается равным Failed, и выдается код завершения:
4.6. Последовательность обработки для роли клиента "Роль клиента" в IOTP является торговой ролью Покупателя. Компания или организация, которая является Продавцом может, например, взять на себя роль покупателя, делая покупки или или выполняя отзыв электронного платежа. В частности Покупатель должен быть способен:
4.6.1. Операции инициализации Роль Покупателя может инициировать большое число различных транзакций. В частности:
4.6.2. Обработка входных сообщений Обработка входных сообщений для роли покупателя происхотит также как и для IOTP-сервера (смотри раздел 4.5.2) за исключением проверки ошибок в последовательности блоков (для IOTP-сервера смотри раздел 4.5.2.4). Описание обработки входных сообщений для сервера IOTP включает соображения многопроцессности и многозадачности. Для роли покупателя - в частности при работе на изолированной рабочей системе использование много процессности оставляется на усмотрение разработчика. 4.6.2.1. Поиск ошибки в последовательности блоков Последовательность обработки блоков для роли покупателя та же, что и для IOTP-сервера (смотри раздел 4.5.2.4) за исключением того, что роль покупателя подставляется вместо роли сервера IOTP:
Для других блоков роль покупателя может получать уведомление об ошибках в порядке прихода блоков и может зависеть от типа блоков. Блоки, где важна последовательность проверки перечислены ниже:
4.6.3. Аннулирование операции Этот процесс аннулирует текущую транзакцию системы покупателя в результате внешнего запроса пользователя или другой системы или сервера, исполняющего роль покупателя. Обработка запроса делается также как для сервера IOTP (смотри раздел 4.5.3). 4.6.4. Повторная передача сообщений Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4). 5. Соображения безопасности Здесь рассматриваются следующие проблемы:
5.1. Принятие решения о применении электронной подписи Использование электронной подписи в IOTP является исключительно опционным. IOTP может успешно работать вообще без цифровых подписей. В конце концов, использовать ли цифровую подпись, решает продавец или другая торговая роль, покупатель же решает обеспечивает ли приемлемый уровень риска вариан без электронной подписи. Если продавцы выяснят, что транзакции без подписей не приемлемы, то они имеют следующий выбор: o начать использовать подписи, Перечень некоторых причин использования цифровых подписей представлен ниже:
Ниже приводится список некоторых причин, почему электронная подпись может не использоваться:
5.2. Симметричная и асимметричная криптография Преимущество использования симметричных ключей заключается в искдючении инфраструктуры, сопряженной с обслуживанием открытых ключей. В этом случае Продавец, Кассир и Агент доставки должны договориться об использовании общего секретного ключа. Однако неудобства симметричной криптографии заключается в том, что покупатель не может надежно идентифицировать Продавца, Кассира и Агента доставки с которыми он имеет дело. Это существенно понижает доверие системе покупателя. Однако следует заметить, что даже в случае использования асимметричной криптографии Покупатель не нуждается в цифровых сертификатах, так как целостность транзакции определяется кассиром, проверяющим подпись отклика предложения, скопированную с платежного запроса. Заметим, что в одной транзакции может использоваться симметричная, асимметричная криптография или обе ее разновидности. 5.3. Конфиденциальность данных Конфиденциальность информации обеспечивается путем пересылки IOTP-сообщений между торговыми ролями, используя секретный канал, такой как [SSL/TLS]. Использование безопасного канала в IOTP является опционным. 5.4. Безопасность платежного протокола IOTP сконструирован так, чтобы быть нечувствительным к используемому платежному протоколу. IOTP способствует безопасности, используя цифровые подписи для установления однозначного соответствия запроса и отклика и для аутентификации отправителя сообщений. Например IOTP связывает вместе: предложение, платеж и доставку. 6. Цифровые подписи и IOTP IOTP может успешно работать без использования цифровых подписей в открытой сетевой среде, но это менее безопасно - смотри 5. Ниже рассматривается использование цифровых подписей для решения различных задач. 6.1. Как IOTP использует цифровые подписи? В IOTP цифровые подписи используются как:
Цифровые сертификаты могут быть связаны с цифровой подписью, если используется асимметричная криптография.Однако если используется симметричная криптография, цифровой сертификат заменяется некоторым идентификатором используемого секретного ключа. Способ, с помощью которого формируются компоненты подписи для одного или нескольких элементов, проиллюстрирован ниже на рис. .10.
Рис. .10. Дайджесты подписи Классическим примером того, как одна цифровая подпись подтверждает другую в IOTP, является случай когда Продавец сначала подписывет предложение, формируя подпись отклика предложения, которое позднее подтверждается кассиром с помощью подписи платежной расписки. Таким путем платеж в транзакции IOTP связывается с предложением продавца. Заметим, что один Manifest может соответствовать многим элементам подписи "Value", где каждый элемент значения содержит цифровую подпись того же самого Manifest. Это, в частности, позволяет продавцу согласовать применение различных секретных ключей с кассиром и агентом доставки. Детальные описания компонента подписи содержится в разделе 7.19. 6.1.1. Пример подписи IOTP Пример использования подписи проиллюстрирован ниже на рис. .11, где показано как взаимодействуют различные компоненты и элементы друг с другом. Для целей иллюстрации была использована базовая торговая транзакция. Применение элементов и атрибутов аналогично для всех типов транзакций IOTP. Элемент Manifest в компоненте подписи содержит дайджесты TransRefBlock (не покаазан); ID-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).
Рис. .11. Пример использование подписи при покупке 6.1.2. Элементы OriginatorInfo и RecipientInfo Атрибут OriginatorRef элемента OriginatorInfo в компоненте подписи содержит ссылку на элемент (смотри раздел 3.5), которая указывает на комполнент организации, сгенерировавшей подпись. В данном примере это продавец. Заметим, что значение элемента атрибута с атрибутом типа, устанавленным равным типу подписи IOTP, должно соответствовать торговой роли организации, которая его подписала. Если это не так, возникает ошибка. Корректные значения представлены ниже в таблице.
Атрибут RecipientRefs элемента RecipientInfo в компоненте подписи содержит ссылки элементов на компоненты организации, которая должна использовать подпись, чтобы проверить:
Заметим, что, если используется симметричная криптография, отдельные элементы RecipientInfo и Value для каждого набора общих секретных ключей размещаются в компоненте Signature. В противном случае, если используется асимметричная криптография, атрибут RecpientRefs одного элемента RecipientInfo может относиться к нескольким компонентам Organisation, если они все используют один и тот же сертификат. 6.1.3. Использование подписей для подтверждения корректного завершения операций Проверка успешного завершения операции осуществляется с помощью подписи данных сообщений-откликов. В частности:
6.2. Проверка корректности вычисления подписи Проверка корректности вычисления электронной подписи является частью проверки ошибок уровня сообщения (смотри раздел 4.3.2). Прежде чем торговая роль сможет проверить подпись, она должна идентифицировать, какой из элементов подписи следует проверить. При этом производятся следующие действия:
6.3. Проверка платежа или доставки Далее описываются процессы, необходимые для кассира или агента доставки, чтобы проверить возможность выполнения платежа или доставки. Это может включать проверку подписей, если она специфицирована продавцом. При этом осуществляются следующие шаги:
В данном разделе используются следующие термины:
6.3.1. Проверка того, что блок запроса послан правильной организацией Проверка того, послан ли блок запроса правильной организации, варьируется в зависимости от того платеж это или доставка. 6.3.1.1. Платеж Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя ID плетежного компонента для идентификации организации, выбранной Покупателем, проверяет, что это та самая организация. Метод доступа к данным для решения поставленных задач проиллюстрирован на рис. .12.
Далее выполняются следующие процедуры:
6.3.1.2. Доставка Способ доступа к данным Агента доставки при проверке того, может ли он выполнить доставку показан на рис. .13. Start Процедура включает в себя следующие шаги:
6.3.2. Проверка компонентов Correct, присутствующих в блоке запроса Далее проверяется то, что в блоке платежного запроса (смотри раздел 8.7) или запроса доставки (смотри раздел 8.10) присутствуют правильные компоненты. Если компоненты отсутствуют, то это ошибка. 6.3.3. Проверка авторизованности операции Предыдущие шаги идентифицировали операционную организацию и проверяли наличие всех необходимых компонент. На данном этапе проверяется, что операционная организация авторизована для выполнения данной процедуры. Операционная организация идентифицирует Продавца, проверяет, что с ним имеется соглашение, которое допускает выполнение операции, и что любые ограничения этого соглашения выполнены, тогда, если требуются подписи, проверяется, что они подтверждают корректные данные. Эти шаги включают в себя:
6.3.3.1. Проверка корректности дайджестов подписи Все компоненты Signature, содержащиеся в IOTP-сообщении должны включать элементы Digest, которые относятся к:
Необходима проверка того, что каждый компонент подписи содержит элементы дайджеста, которые относятся к корректным данным. Элементы Digest, которые должны присутствовать, зависят от торговой роли организации, генерирующей цифровую подпись:
7. Торговые компоненты Далее рассматриваются торговые компоненты, используемые в IOTP. Торговые компоненты являются дочерними XML-элементами, что показано на диаграмме рис. .14.
Рис. .14. Торговые компоненты Перечень торговых компонентов представлен ниже в порядке их вероятности использования:
Заметим, что следующие компоненты в других секциях этой спецификации:
7.1. Компонент протокольных опций Опции протокола представляют собой опции, которые работают с транзакциями IOTP в целом. Определение компонента протокольных опций представлено ниже. <!ELEMENT ProtocolOptions EMPTY > Атрибуты:
Этот компонент используется для облегчения выбора транзакции из списка подобных, например из базы данных транзакций IOTP, которые были запомнены Покупателем, Продавцом и т.д..
Это сетевая позиция, куда получатель блока TPO должен послать блок выбора TPO, если это требуется. Содержимое атрибута зависит от транспортного механизма.
Содержимое этого атрибута зависит от транспортного механизма.
Содержимое этого аптрибута зависит от транспортного механизма. Должен присутствовать либо SenderNetLocn, либо SecureSenderNetLocn или оба эти атрибута. 7.2. Компонент запроса аутентификации Этот торговый компонент содержит параметр данных, которые используются при аутентификации одной торговой роли у другой. Его определение представлено ниже. <!ELEMENT AuthReq (Algorithm, PackagedContent*)> Если требуется, алгоритм может использовать данные вызова, содержащиеся в элементах Packaged Content из компонента запроса аутентификации. Формат Packaged Content является зависимым от алгоритма. Атрибуты:
Cодержимое:
Алгоритмы, которые могут использоваться, идентифицированы атрибутом Name элемента Algorithm. 7.3. Компонент отклика аутентификации Компонент отклика аутентификации содержит результаты аутентификационного запроса. Используется алгоритм, содержащийся в компоненте запроса аутентификации (смотри раздел 7.2) и выборанный из блока запроса аутентификации (смотри раздел 8.4). В зависимости от выбранного алгоритма, результаты его применения будут содержаться в компоненте подписи, которая подтверждает отклик аутентификации, или в элементах Packaged Content компонента отклика аутентификации. Его определение представлено ниже. <!ELEMENT AuthResp (PackagedContent*) > Атрибуты:
Cодержимое:
Например, для заданной схемы платежа он может содержать данные, зависящие от этой схемы. 7.4. Компонент запроса информации торговой роли Этот торговый компонент содержит список торговых ролей (смотри раздел 2.1), информация для которых запрошена. Результатом запроса торговой роли является набор компонентов Organisation (смотри раздел 7.6), которые описывают каждую из запрошенных торговых ролей. Его определение приведено ниже. <!ELEMENT TradingRoleInfoReq EMPTY> Атрибуты:
7.5. Компонент заказа Компонент Order содержит информацию о заказе. Его определение представлено ниже. <!ELEMENT Order (PackagedContent*) >
Атрибуты:
Cодержимое:
7.5.1. Содержимое описания заказа Элемент Packaged Content будет в норме необходим, однако он может быть опущен там, где достаточная информация о покупке может быть получена из атрибута ShortDesc. Если необходимо полное описание заказа, могут использоваться несколько элементов Packaged Content. Хотя сумма и валюта вероятно присутствуют в элементах Packaged Content описания заказа, они содержатся в торговых компонентах, связанных с платежом (список видов платежа, выбор вида платежа и платеж). Это означает, что важно, чтобы сумма, которая действительно дожна быть уплачена, была четко отображена для Покупателя. Для совместимости разные реализации должны поддерживать как минимум Plain Text, HTML и XML, что облегчит отображение. 7.5.2. Временные метки OkFrom и OkTo Заметим, что:
Продавец в контексте Интернет-коммерции в исходный момент с анонимными покупателями выявляет условия предложения на WEB-странице. Для того чтобы получить товар или услуги покупатель должен согласиться с этими условиями. Если предложение ограничено временными рамками, рекомендуется, чтобы продавцы взаимодействовали с покупателями и сообщали им условия заказа в понятной для них форме:
Заметим также, что даты OkFrom и OkTo могут также присутствовать в элементах Packaged Content описания заказа, эти даты содержатся в компоненте Order. Важно, чтобы даты OkFrom и OkTo использовались в формате, приемлемом для покупателя. 7.6. Компонент Organisation Компонент Organisation предоставляет информацию об индивидууме или организации. Он может быть использован для различных целей, например:
Заметим, что компоненты Organisation, которые должны присутствовать в сообщении IOTP, зависят от выполняемой транзакции. Смотри раздел 9. Ниже представлено определение компонента. <!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
Атрибуты:
Атрибут используется для упрощения выбора отдельной организации из списка, например из базы данных организаций, вовлеченных в транзакции, которая записана Покупателем.
Смотри раздел 10. Содержимое этого атрибута должно соответствовать [RFC1738]. Cодержимое:
7.6.1. ID организаций ID организаций используются одной из торговых ролей для идентификации торговой роли. Для того чтобы избежать путаницы, это означает, что эти ID должны быть глобально уникальными. На практике это достигается следующим образом:
В частности, содержимое ID организации определяется следующим образом: OrgId ::= NonConsumerOrgId | ConsumerOrgId
Заметим, что NonConsumerOrgId не может начинаться с ConsumerOrgIdPrefix. Допускается использование строчных и прописных символов. Ниже приведены примеры Id организации:
7.6.2. Элемент торговая роль Этот элемент идентифицирует торговую роль человека или организации в данной транзакции IOTP. Заметим, что организация может иметь более чем одну торговую роль и несколько ролей может присутствовать в одном элементе Organisation. Определение элемента представлено ниже: <!ELEMENT TradingRole EMPTY >
ErrorLogNetLocn CDATA #IMPLIED> Атрибуты:
Этот атрибут:
Содержимое этого атрибута зависит от транспортного механизма.
Этот атрибут:
Содержимое атрибута зависит от транспортного механизма.
Этот атрибут:
Содержимое этого атрибута зависит от транспортного механизма. Атрибут ErrorLogNetLocn может использоваться для посылки сообщений об ошибках программной компании или другой оргаанизации, ответственной за решение проблем с программами, которые посылают входные сообщения. Смотри раздел 7.21.1. 7.6.3. Элемент контактной информации Этот элемент содержит информацию, которая может быть использована для контакта с организацией или частным лицом. Все атрибуты являются опционными, однако по крайней мере один из элементов контактной информации должен присутствовать. Его определения представлено ниже. <!ELEMENT ContactInfo EMPTY >
Атрибуты:
Содержимое этого атрибута должно согласовываться с документом [RFC1738]. 7.6.4. Элемент личного имени Этот элемент содержит имя частного лица. Все поля являются опционными, однако GivenName (имя) или FamilyName (фамилия) должны присутствоать. Его опредление представлено ниже. <!ELEMENT PersonName EMPTY >
Атрибуты:
7.6.5. Элемен почтового адреса Этот элемент содержит адрес, который может быть использован, например, для физической доставки товаров, услуг или писем. Его определение предлагается ниже. <!ELEMENT PostalAddress EMPTY >
LegalLocation (True | False) 'False' > Атрибуты:
7.7. Компонент списка видов платежей Компоненты списка видов платежа содержатся в блоке опций торгового протокола (смотри раздел 8.1) транзакции IOTP. Они содержат список:
Определение компонента списка видов платежа представлено ниже. <!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)> <!ATTLIST BrandList ID ID #REQUIRED xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED PayDirection (Debit | Credit) #REQUIRED> Атрибуты:
Cодержимое:
Отношения между элементами, которые образуют содержание списка видов платежа проиллюстрированы на рис. .15.
Примеры списков видов платежа содержатся в главе 11.2. 7.7.1. Элемент Brand Элемент Brand описывает вид платежа, который может быть использован при оплате покупки. Один или более таких элементов образуют компонент списка видов платежа, который имеет атрибут PayDirection, установленный равным Debit. Только один элемент вида платежа может содержаться в компоненте списка видов платежа (Brand List), который имеет атрибут PayDirection = Credit. <!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED> Атрибуты:
Так как значения BrandId управляются процедурами IANA, допускается определение значений самим пользователем.
Содержимое этого атрибута должно соответствовать документу [RFC1738].
Cодержимое:
Пример элементов вида платежа имеется в разделе 11.2. 7.7.2. Элемент протокола вида платежа Элемент протокола вида платежа содержит информацию, которая является специфической для применения определенного протокола к некоторому виду платежей. Его определение предложено ниже. <!ELEMENT ProtocolBrand (PackagedContent*) > <!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #REQUIRED > Атрибуты:
Значения ProtocolId должно быть уникальным в пределах элемента Brand, в противном случае происходит ошибка.
Корректные значения этого атрибута описаны в приложении для платежных протоколов, идентифицированных ProtocolId, которые определяют, как платежный протокол работает с IOTP. Cодержимое:
7.7.3. Элемент Protocol Amount Элемент Protocol Amount связывает вид платежа с:
Его определение представлено ниже: <!ELEMENT ProtocolAmount (PackagedContent*) > Атрибуты:
Cодержимое:
Примеры элементов Protocol Amount приведены в секции 11.2. 7.7.4. Элемент валютной суммы Элемент валютной суммы содержит в себе:
Один или более таких элементов заключены в каждом компоненте списка видов платежа. Его определение приведено ниже: <!ELEMENT CurrencyAmount EMPTY > Атрибуты:
Так как значения CurrCodeType управляются процедурой, описанной в секции 12, допускается определение пользователем собственных значений CurrCodeType. Примеры элементов Currency Amount представлены в разделе 11.2. 7.7.5. Элемент платежного протокола Элемент платежного протокола специфицирует детали для платежного протокола и для Кассира, которые могут использоваться для жанного видв платежа. Один или более таких элементов содержится в каждом списке видов платежа. <!ELEMENT PayProtocol (PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED> Атрибуты:
Значения ProtocolId определены схемой/методом платежа владельцев в документе, который описывает, как инкапсулировать платежный протокол в IOTP.
Содержимое этого атрибута зависит от транспортного механизма (и должно быть согласованос документом [RFC1738].
Содержимое этого атрибута должно согласовываться с регламентациями документа [RFC1738]. Смотри раздел 3.9. ContentSoftwareIdСмотри раздел 14. Словарь. Cодержимое:
Примеры элементов платежного протокола содержатся в разделе 11.2. 7.8. Компонент выбора вида платежа Компонент выбора вида платежа идентифицирует выбор вида платежа, платежный протокол и кассира. Этот элемент используется:
В базовой версии IOTP, целостность компонентов выбора вида платежа не гарантируется. Однако модификация компонентов выбора вида платежа может привести лишь к отказу обслуживания, если сам платежный протокол безопасен и контролирует модификацию или дублирование сообщений и может противостоять любым другим атакам. Определение компонента выбора вида платежа представлено ниже. <!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?, BrandSelCurrencyAmountInfo?) > <!ATTLIST BrandSelection ID ID #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED Атрибуты:
Cодержимое:
Используются следующие правила:
Пример компонента выбора вида платежа включен в раздел 11.2. 7.8.1. Информационный элемент выбора вида платежа Информационный элемент выбора вида платежа cсодержит любую дополнительную информацию, которая может быть необходима для какого-то конкретного вида платежа. Смотри приложение IOTP для платежных методов, где описано применние этого элемента. <!ELEMENT BrandSelBrandInfo (PackagedContent+) > Атрибуты:
Cодержимое:
7.8.2. Элемент Amount Info протокола выбора вида платежа Элемент Amount Info протокола выбора вида платежа содержит любую дополнительную информацию, зависящую от платежного протокола, которая может быть необходима для конкретного вида платежа или плптежного протокола. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента. <!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)> Атрибуты:
Cодержимое:
7.8.3. Информационный элемент валютной суммы выбора вида платежа (Brand Selection Currency Amount Info) Информационный элемент валютной суммы выбора вида платежа содержит любую дополнительную информацию, зависящую от вида платежа и валюты, которая может быть необходима при конкретном виде платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента. <!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)> Атрибуты:
Cодержимое:
7.9. Компонент платежа (Payment) Компонент платежа содержит информацию, используемую для управления процедурой выполнения платежа. Он предоставляет информацию о:
Его определение выглядит следующим образом. <!ELEMENT Payment EMPTY > OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED BrandListRef NMTOKEN #REQUIRED SignedPayReceipt (True | False) #REQUIRED StartAfterRefs NMTOKENS #IMPLIED> Атрибуты: ID Идентификатор, который однозначно идентифицирует платежный
компонент в транзакции IOTP. OkFrom Дата и время в формате [UTC], после которого кассир может
воспринимать на обработку блок платежного запроса (смотри раздел 8.7), содержащий компонент платежа. OkTo Дата и время в формате [UTC], до которого Кассир может воспринимать на обработку блок платежного
запроса, содержащий компонент платежа. BrandListRef Ссылка элемента (смотри раздел 3.5) компонента списка видов
платежа (смотри раздел 7.7) в рамках торгового блока TPO транзакции IOTP. Список видов платежа идентифицирует
альтернативные способы осуществления платежа. SignedPayReceipt Указывает, должен ли быть подписан блок платежного отклика (смотри раздел 8.9), сгенерированный Кассиром. StartAfter Содержит ссылки элемента (смотри раздел 3.5) других платежных компонентов, которые описывают платежи, которые должны быть проведены до того, как будет произведен данный платеж. Если атрибут StartAfter отсутствует, тогда никаких зависимостей нет и платеж может быть проведен немедленно. 7.10. Компонент платежной схемы Компонент платежной схемы содержит информацию платежного протокола для специфической платежной
схемы, реализуемой между партнерами, вовлеченными в платеж, например [SET]-сообщение. Определение компонента
представлено ниже. <!ELEMENT PaySchemeData (PackagedContent+) > PaymentRef NMTOKEN #IMPLIED ConsumerPaymentId CDATA #IMPLIED PaymentHandlerPayId CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED> Атрибуты: ID Идентификатор, который однозначно определяет компонент схемы
оплаты транзакции IOTP. PaymentRef Ссылка элемента (смотри раздел 3.5) компонента платежа (смотри
раздел 7.9), с которым связан компонент схемы платежа. Атрибут необходим, если только компонент схемы платежа не
является частью запроса состояния транзакции (смотри раздел 9.2.1). ConsumerPaymentId Идентификатор, специфицированный Покупателем, который в случае возвращения Кассиром в другом компоненте схемы платежа (или другим способом) позволит Покупателю определить, о каком платеже идет речь. PaymentHandlerPayId Идентификатор, специфицированный Кассиром, который в случае возвращения Покупателем в другом компоненте схемы платежа (или другим способом) позволит Кассиру определить, о каком платеже идет речь. Атрибут необходим для каждого компонента схемы платежа, вне зависимости от того, что содержится в блоке платежного запроса. ContentSoftwareId Смотри раздел 14. Словарь. Cодержимое: PackagedContent Содержит протокольную информацию о схеме платежа в виде
элементов Packaged Content (смотри раздел 3.7). Определение содержимого смотри в приложение по схемам платежа. Заметим, что: 7.11. Компонент платежной расписки Плптежная расписка представляет собой запись о платеже, которая показывает, какая сумма заплачена
или получена. Она отдичается от расписки о покупке, тем что здесь нет записи о том, что куплено. Обычно в компоенте
платежной расписки содержатся данные, которые описывают: Если использованный платежный метод сконфигироирован соответствующим образом, то компонент
платежной расписки должен содержать сообщения платежного протокола или ссылки на сообщения, которые подтверждают
выполнение платежа. Точное определение содержимого платежной расписки зависит от метода платежа. Информация,
содержащаяся в компоненте платежной расписки, должна отображаться или каким-либо другим способом доводиться до
сведения Покупателя. Если компонент платежной расписки содержит сообщения платежного протокола, тогда они должны быть
обработаны программой метода платежа,чтобы преобразовать их в формат понятный Покупателю. Определение компонента платежной расписки. <!ELEMENT PayReceipt (PackagedContent*)> <!ATTLIST PayReceipt ID ID #REQUIRED PaymentRef NMTOKEN #REQUIRED PayReceiptNameRefs NMTOKENS #IMPLIED ContentSoftwareId CDATA #IMPLIED> Атрибуты: ID Идентификатор, который однозначно определяет компонент
платежной расписки транзакции IOTP. PaymentRef Содержит ссылку элемента (смотри раздел 3.5) на компонент платежа (смотри раздел 7.9), к которому относится данная расписка. PayReceiptNameRefs Опционно содержит список значений атрибутов Name элементов Packaged Content, которые образуют расписку. Элементы Packaged Content могут содержать: о компоненты данных платежной схемы, обмен которыми производится между Кассиром и Покупателем в процессе платежа и/или o сам компоент платежной расписки. Заметим, что: o каждый компонент схемы определяет в своем приложении имена элементов Packaged Content, которые должны быть перечислены в этом атрибуте (если они нужны). о Если компонент платежной схемы содержит элементы Packaged Content, с именами которые совпадают с именем в PayReceiptNameRefs, тогда на такие компоненты платежной схемы должны ссылаться дайджесты в компоненте подписи платежного отклика (если используется такая подпись). Программа клиента должна спасать все компоненты, на которые имеются ссылки, с тем чтобы платежная расписка могла быть
воспроизведена, если это потребуется. ContentSoftwareId Смотри раздел 14. Словарь. Cодержимое: PackagedContent Опционно содержит информацию платежной расписки (платежную
схему) в виде элементов Packaged Content (смотри раздел 3.7). Определение его содержимого смотри в прилжении
платежной схемы. Заметим, что: о значения атрибута Name каждого элемента packaged content определены приложением платежного протокола; о значение Name должно быть уникальным для каждого платежа, как и для всех схем платежа или компонентов платежной расписки с идентичным значением атрибута PaymentRef. Заметим, что должны присутствоать либо атрибут PayReceiptNameRefs, либо элемент
PackagedContent или оба. 7.12. Компоент Payment Note Компонент Payment Note (платежное заывление) содержит дополнительную, несвязанную с
платежом информацию, которую Кассир хочет предоставит покупателю. Например, если был произведен отзыв сделки или
осуществлен депозит, тогда он может содержать информацию о балансе по завершении перевода. Данные должны
дублировать информацию, содержащуюся в компоненте платежной расписки. Информация, содержащаяся в компоненте Payment Note должна быть отображена или
представлена каким-то иным способом покупателю. Для совместимости компонент Payment Note должен поддерживать
как минимум содержимое типа "Plain Text", HTML и XML. Его определение представлено ниже. <!ELEMENT PaymentNote (PackagedContent+) > Атрибуты: ID Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP. ContentSoftwareId Смотри раздел 14. Словарь. Cодержимое: PackagedContent Содержит дополнительную, не связанную с платежом информацию,
которую кассир хочет довести до сведения покупателя в виде одного или более элементов Packaged Content (смотри
раздел 3.7). 7.13. Компонент доставки Компонент доставки содержит информацию, необходимую для доставки товаров или услуг. Его
определение приведено ниже. <!ELEMENT Delivery (DeliveryData?, PackagedContent*) > xml:lang NMTOKEN #REQUIRED DelivExch (True | False) #REQUIRED DelivAndPayResp (True | False) #REQUIRED ActionOrgRef NMTOKEN #IMPLIED> Атрибуты: ID Идентификатор, который однозначно определяет компонент доставки транзакции. xml:lang Определяет язык, используемый атрибутами и дочерними элементами
этого компонента, если только атрибут дочернего элемента xml:lang не перепишет это значение. Смотри раздел 3.8. DelivExch Индицирует факт наличия в транзакции сообщений, ассоциированных с
обменом доставки. Корректные значения: Если DelivExch = true, должен присутствовать элемент DeliveryData. Если DelivExch =
false, он может отстутствовать. DelivAndPayResp Индицирует то, чтоблок отклика доставки (смотри раздел 8.11) и блок отклика плптежа (смотри раздел 8.9)
находся в одном и том же сообщении IOTP. Корректные значения: Атрибут DelivAndPayResp не должен иметь значение "истинно", если DelivExch = "ложно". На практике комбинирование блока отклика доставкии блока отклика платежа имеет смысл только в
случае, когда Продавец, Кассир и Агент доставки принадлежат одной организации, так как:
Cодержимое:
7.13.1. Элемент Delivery Data Элемент DeliveryData содержит информацию о том, куда и как должны доставляться товары или услуги. Его определение представлено ниже. <!ELEMENT DeliveryData (PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED> Атрибуты:
Значения DelivMethod управляются процедурой, описанной в разделе 12, что допускает определение новых кодов пользователем.
Безопасный запрос доставки предполагает использование безопасного канала, такого как [SSL/TLS] для того чтобы взаимодействовать с кассиром. Содержимое этого атрибута зависит от транспортного механизма и должно соответствовать регламентациям документа [RFC1738]. Смотри также раздел 3.9.
Cодержимое:
7.14. Информационный компонент доставки Покупателя Информационный компонент доставки покупателя используется покупателем для спецификации идентификатора, который может быть использован им для идентификации доставки. Его определение приведено ниже: <!ELEMENT ConsumerDeliveryData EMPTY> Атрибуты:
7.15. Компонент Delivery Note Компонент Delivery Note (накладная)содержит инструкции о доставке товаров или услу, или саму информацию о доставке. Это информация, которую частное лицо или организация, получающие накладную, могут использовать, когда осуществляется доставка. Для совместимости компонент Delivery Note должен поддерживать Plain Text, HTML и XML. Его определение представлено ниже. <!ELEMENT DeliveryNote (PackagedContent+) >
Атрибуты:
Cодержимое:
Если содержимым сообщения доставки является сообщение Mime, тогда Delivery Note может запустить приложение, которое вызываеть реальный процесс доставки. 7.16. Компонент Status Компонент Status содержит информацию состояния бизнес-процесса (успех или неудача) (смотри раздел 4.2). Его определение приведено ниже. <!ELEMENT Status EMPTY >
ProcessState (NotYetStarted | InProgress | CompletedOk | Failed | ProcessError) #REQUIRED Атрибуты:
"Непределено" означает, что тип документального обмена не может быть идентифицирован. Это может быть вызвано ошибкой исходного входного обмена сообщениями. Значения StatusType управляется процедурой, описанной в секции 12 (IANA), и допускающей определение новых значений пользователем.
Заметим, что этот код сообщает об обработке блока запроса. Далее, после посылки блока отклика, сопряженного с процессом, может осуществляться асинхронная обработка.
CompletionCode может иметь до 14 символов.
Этот атрибут должен отсутствовать в сообщении информационного запроса, когда Покупателю сервис-провайдером IOTP не был дан код ссылки. Этот атрибут может быть использован внутри блока информационного отклика (смотри раздел 8.13), для того чтобы предоставить код ссылки для транзакции, которя ранее была недоступна. Например, код упаковки может быть не присвоен в момент получения отклика доставки. Однако, если покупатель поздее выдаст запрос состояния транзакции, Агент доставки может проставить код упаковки в атрибут сообщения информационного отклика и послать его Покупателю.
7.16.1. Коды завершения предложения Код завершения является единственно необходимым, если атрибут ProcessState = Failed (неудача). Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, возможно ли восстановление процесса. Рекомендуется, чтобы там, где это необходимо для дальнейшего разъяснения, использовался атрибут StatusDesc.
Восстановление может осуществить Покупатель, повторно предложив блок отклика аутентификации с правильными данными.
Восстановление возможно, если последнее сообщение от другой торговой роли получено снова.
7.16.2. Коды завершения платежа CompletionCode необходим, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, когда возможно восстановление. Рекомендуется, чтобы атрибут StatusDesc использовался индивидуальными платежными схемами для предоставления дальнейших пояснений, там где это уместно.
Ниже приведены опции восстановления.
Если оплата не зависит от вида платежа, тогда покупатель решить проблему путем выбора другой валюты, если она имеется, или заменой вида платежа. Заметим, что это может потребовать замены кассира.
Если оплата не зависит от вида платежа, тогда восстановление для некоторых видов кода завершения возможно для покупателя, который может выбрать другой вид платежа или новый платежный инструмент для того же вида платежа. Заметим, что это может потребовать замены кассира. Здесь применимы следующие коды: BrandNotSupp, PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument и Unspecified. Восстановление прооцедуры платежа при покупках, зависящих от вида платежа возможно только в случае, если компонент выбора вида платежа, посланный продавцом покупателю, не изменился. На практике это означает, что должны использоваться тот же элемент вида платежа, платежный протокол и сумма. Единтвенно что можно изменить - это платежный инструмент. Любые другие изменения будут неприемлемы. 7.16.3. Коды завершения доставки Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode для доставки. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
Восстановление при неудаче или в случае частично завершенной доствки невозможно. Покупатель для получения текущего состояния транзакции должен использовать информационный запрос (смотри раздел 9.2.1). 7.16.4. Коды завершения аутентификации Код завершения необходим только в случае, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения атрибута CompletionCode, которые можно использовать. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
7.16.5. Неопределенные коды завершения Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
7.16.6. Коды завершения информационного запроса транзакции Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
7.17. Компонент данных торговой роли Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию. Компоненты торговой роли определяют: o организацию, которая сформировала компонент и Они являются первыми сформированными и включенными в блок "отклик" и затем скопированных в соответствующий блок "запрос". Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе. Его определение представлено ниже. <!ELEMENT TradingRoleData (PackagedContent+) > Атрибуты:
Cодержимое:
7.17.1. Кто получает компонент данных о торговой роли Ниже описаны правила, которые определяют, что следует делать с компонентами данных торговой роли.
7.18. Компонент типа информационного запроса Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже. <!ELEMENT InquiryType EMPTY > Атрибуты:
7.19. Компонент Signature (подпись) Определения структур XML для подписей и сертификатов описаны в документе "Digital Signatures for the Internet Open Trading Protocol" Kent Davidson и Yoshiaki Kawatsura, опубликованном одновременно с этим документом - смотри [IOTPDSIG]. В будущем ожидается, что новые версии IOTP зафиксируют какой-то метод цифровой подписи XML в к ачестве стандарта. Каждый компонент подписи цифровым образом подтвержжает один или более блоков или компонентов, включая компоненты подписи. Компонент подпись:
Заметим, что может быть много элементов Value, которые содержат подписи элемента Manifest. Компонент Signature может иметь один из четырех типов:
Для общего объяснения подписей смотри раздел 6. 7.19.1. Использование элементов подписи и атрибутов IOTP Определения элементов и атрибутов содержится в [IOTPDSIG]. Ниже представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP. Элемент SIGNATURE Элемент MANIFEST Опционный атрибут LocatorHrefBase содержит текст, который должен быть включен до текста, содержащегося в атрибуте LocatorHREF всех элементов Digest в пределах элемента Manifest. Целью элемента Manifest является сокращение значения атрибута LocatorHREF, так как первая часть атрибутов LocatorHREF в подписи идентична. Обычно в IOTP он будет содержать все символы атрибута LocatorHref вплоть до ("#") (смотри текст ниже). Элементы ALGORITHM и PARAMETER
Рекомендуется, чтобы использовался также следующий алгоритм подписи:
Кроме того могут использоваться другие специфические алгоритмы схем платежа. В этом случае значение атрибута name, которое надлежит использовать, специфицировано в приложении по платежным схемам. Один алгоритм может использовать другие алгоритмы через посредство элемента Parameter, например: <Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash"> Элемент DIGEST Атрибут LocatorHREF идентифицирует элемент IOTP, который подписан цифровым образом. Он состоит из:
Прежде чем анализировать структуру атрибута LocatorHREF, он должен быть объединен со значением атрибута LocatorHrefBase элемента Manifest (смотри непосредственно выше). Элемен атрибут Должен существовать один и только один элемент атрибута, который содержит атрибут Type со значением типа подписи и содержимым равным одному из: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest или PingResponse; в зависимости от типа подписи. Значения содержимого элемента атрибута управляются процедурой, определенной в разделе 12 (IANA), и допускающей определение значений пользователем. Атрибут Critical должен быть установлен равным true. Элемент ORIGINATORINFO Атрибут OriginatorRef элемента OriginatorInfo должен всегда присутствовать и содержать ссылку элемента (смотри раздел 3.5) на компонент Organisation организации, которая сформировала компонент Signature. Элемент RECIPIENTINFO Атрибут RecipientRefs содержит список ссылок (смотри раздел 3.5), указывающих на организации, которые должны будут проверить подлинность подписи. 7.19.2. Компонент подписи отклика предложения Элемент Manifest подписи, который имеет тип OfferResponse должен содержать элементы дайджеста для следующих компонентов:
Подпись отклика предложения должна также содержать элементы дайджеста для компонентов, которые описывают каждую из организаций, которая может или будет нуждаться в верификации подписи. Это включает в себя:
7.19.3. Компонент подписи платежной расписки Элемент Manifest компонента подписи платежной расписки должен содержать элеиенты Digest для следующих компонентов:
7.19.4. Компонент подписи отклика доставки Элемент Manifest компонента отклика доставки должен содержать элементы Digest для следующих компоентов:
7.19.5. Компонент подписи запроса аутентификации Элемент Manifest компонента подписи запроса аутентификации должен содержать элементы Digest для следующих компонентов:
7.19.6. Компонент подписи отклика аутентификации Элемент Manifest компонента подписи отклика аутентификации должен содержать элементы Digest для следующих компонентов:
7.19.7. Компонент подписи информационного запроса Если информационный запрос подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest компонента типа информационного запроса и, если присутствует, компонент схемы платежа. 7.19.8. Компонент подписи Если информационный отклик подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest блока торгового отклика и компонент Status. 7.19.9. Компонент подписи запроса Ping Если запрос Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation. 7.19.10. Компонент подписи отклика Ping Если отклик Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation. 7.20. Компонент Certificate Определения структур XML для подписей и сертификатов описаны в работе "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Смотри также начало раздела 7.19. Компонент Certificate содержит цифровой сертификат. Они используются только, когда, например, использована асиметричная криптография и верифицирующий получатель подписи не получил еще общедоступного ключа (Public Key). Структура сертификата определена в [IOTPDSIG]. 7.20.1. Использование в IOTP атрибутов и элементов подписи Подробные определения упомянутых выше элементов и атрибутов содержатся в [IOTPDSIG]. Далее представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP. Компонент CERTIFICATE Элемент VALUE 7.21. Компонент Error Компонент Error содержит информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, которое было получено одной из торговых ролей, вовлеченных в сделку. Для ясности ниже приведены две фразы, которые определяют использование компонента Error:
Определение компонента Error представлено ниже. <!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
Атрибуты:
Если атрибут Severity не равен TransientError, тогда значение этого атрибута игнорируется.
Cодержимое:
Если Severity ошибки не равно TransientError, может быть, если требуется, специфицировано более одного ErrorLocation, в зависимости от природы ошибки (смотри раздел 7.21.2) и от конкретной реализации программы.
7.21.1. Общие принципы обработки ошибок Если об ошибке уведомляют более чем один компонент Error в сообщении, следует выполнять обработку компонента Error с наивысшим значением атрибута severity. В этом контексте, HardError имеет выше уровень "серьезности" (severity), чем TransientError, который имеет серьезность выше, чем Warning. 7.21.1.1. Severity = предупреждение Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = Warning, тогда, если сообщение об ошибке не содержит другого компонента ошибки с атрибутом Severity выше, чем Warning, сообщение должно включать торговые блоки и компоненты, которые следовало бы включить, если бы сообщения об ошибке отсутствовало. Если сообщение получено с компонентом Error, где Severity = Warning, тогда:
Если предполагается продолжить транзакцию, тогда, если нет других компонентов Error с более высоким уровнем серьезности, следует проверить, что наличиствуют торговые блоки и компоненты, необходимые для продолжения транзакции. Если они не сформированы, то вырабатывается сообщение с компонентом Error и Severity = HardError. 7.21.1.2. Severity = переходная ошибка Если приложение генерирует сообщение с компонентом Error, где атрибут Severity = TransientError, тогда в сообщение должен быть только один компонент Error. Кроме того, должен присутствовать атрибут MinRetrySecs. Если сообщение, уведомляющее об ошибке получено с компонентом Error, где Severity = TransientError тогда:
7.21.1.3. Severity = Hard Error Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = HardError, тогда в сообщении должен быть только один компонент Error. Если получено сообщение с компонентом Error, где атрибут Severity = HardError, транзакция прерывается. 7.21.2. Коды ошибок Ниже следующая таблица содержит допустимые значения атрибута ErrorCode компонента Error. Первое предложение описания содержит текст, который должен использоваться для описания ошибки при отображении. Индивидуальные реализации могут транслировать его на альтернативные языки по своему усмотрению. ErrorCode не должен быть длиннее 14 символов.
Для плохо сформатированного XML, следует попытаться извлечь блок ссылок транзакции, с тем чтобы корректно сформировать отклик Error.
В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного элемента.
В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного атрибута.
В этом случае следует создать элементы ErrorLocation, которые определяют все несогласованные атрибуты или элементы.
Если транспортный механизм сервера/системы (например, HTTP) занят, следует использовать транспортные ошибки. Этот код нужно использовать в связи с серверами/системами IOTP или другими аналогичными системами, с которыми связан IOTP.
7.21.3. Элемент положения ошибки Элемент Error Location указывает элемент и опционно атрибут в сообщении, с которым ассоциируется ошибка. Он содержит ссылку на сообщение IOTP, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка. <!ELEMENT ErrorLocation EMPTY >
AttName NMTOKEN #IMPLIED> Атрибуты:
Заметим, что следует включать как можно больше атрибутов. Например, если атрибут в дочернем элементе торгового компонента содержит неверное значение, тогда должны присутствовать все атрибуты ErrorLocation. 8. Торговые блоки Торговые блоки являются дочерними элементами IOTP-сообщения верхнего уровня, которое послано в форме [XML]-документа от одного партнера торговой операции к другому. Каждый трговый блок состоит из одного или более торговых компонентов (смотри раздел 7). Это проиллюстрировано на диаграмме.
Торговые блоки определены как часть определения сообщения IOTP (смотри раздел 3.1.1). Определение элемента сообщения IOTP представлено ниже: <!ELEMENT IotpMessage
Далее в данном разделе определены торговые блоки данной версии IOTP. Это:
Блок ссылок транзакции определен в разделе 3.3. 8.1. Блок опций торгового протокола Торговый блок TPO содержит опции, которые применяются в транзакции IOTP. Определение торгового блока TPO представлено ниже. <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )> Атрибуты:
Cодержимое:
Блок TPO должен содержать:
8.2. Блок выбора TPO Блок выбора TPO содержит результаты выбора, сделанного из списка, содержащегося в блоке протокольных опций (смотри раздел 8.1). Определение блока выбора TPO предлагается ниже. <!ELEMENT TpoSelectionBlk (BrandSelection+) > Атрибуты:
Cодержимое:
Блок выбора TPO должен содержать по одному компоненту выбора вида платежа для каждого списка видов платежа блока TPO. 8.3. Блок отклика Offer Блок отклика Offer содержит подробности о товарах, услугах, сумме, инструкций доставки или финансовых операциях, которые должны быть осуществлоены. Его определение дано ниже. <!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)> Атрибуты:
Cодержимое:
Компонент Order должен присутствовать, если только атрибут ProcessState компонента Status не равен Failed.
Блок отклика Offer должен содержать:
8.4. Блок запроса аутентификации Блок запроса аутентификации содержит данные, которые используются одной из торговых ролей для получения информации и опционно для аутентификации другой торговой роли. Этот блок содержит:
Его определение предагается ниже. <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)> Атрибуты:
Cодержимое:
Если присутствует один компонент запроса аутентификации, тогда именно он и должен использоваться. Если присутствует несколько компонентов запроса аутентификации, тогда получатель должен выбрать один компонент, основываясь на своих предпочтениях и возможностях программного обеспечения. Если нет ни одного компонента запроса аутентификации, это означает, что блок аутентификационного запроса запрашивает присылку компонентов Organisation, как это специфицировано в компоненте информационного запроса торговой роли.
В аутентификационном блоке должен быть по крайней мере один компонент (аутентификационного запроса или информационного запроса торговой роли), в противном случае имеет место ошибка. 8.5. Блок отклика аутентификации Блок отклика аутентификации содержит отклик, который является результатом обработки блока запроса аутентификации. Его определение представлено ниже. <!ELEMENT AuthRespBlk (AuthResp?, Org*) > Атрибуты:
Cодержимое:
Компоненты, присутствующие в блоке отклика аутентификации должны согласовываться с требованиями соответствующего блока аутентификационного запроса, в противном случае имеет место ошибка. 8.6. Блок состояния аутентификации Блок состояния аутентификации индицирует успех или неудачу верификации блока отклика аутентификации аутентификатором. Его определение представлено ниже. <!ELEMENT AuthStatusBlk (Status) > Атрибуты:
Cодержимое:
8.7. Блок платежного запроса Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже. <!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection, Атрибуты:
Cодержимое:
Блок платежного запроса должен содержать:
8.8. Блок платежного обмена Блок платежного обмена содержит специфические данные о платежной схеме, которыми обмениваются две торговые роли в рамках сделки. Его определение представлено ниже. <!ELEMENT PayExchBlk (PaySchemeData+)> Атрибуты:
Cодержимое:
8.9. Блок платежного отклика Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже. <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?, Атрибуты:
Cодержимое:
8.10. Блок запроса доставки Блок запроса доставки содержит подробности о товарах или услугах, которые должны быть предоставлены вместе с подписью, которая позволяет удостовериться, что доставка была авторизована. Его определение приведено ниже. <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery, Атрибуты:
Cодержимое:
Блок запроса доставки содержит:
8.11. Блок отклика доставки Блок отклика доставки содержит Delivery Note, содержащую подробности о том как будут доставляться товары. Его определение представлено ниже. Заметим, что в блоке отклика Delivery элемент состояния доставки с DeliveryStatusCode равным NotYetStarted или InProgress является нелегальным. <!ELEMENT DeliveryRespBlk (Status, DeliveryNote)> Атрибуты:
Cодержимое:
8.12. Торговый блок информационного запроса Торговый блок информационного запроса содержит компоненттип запроса и опционно платежной схемы. <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) > Атрибуты:
Cодержимое:
8.13. Торговый блок информационного отклика Торговый блок информационного отклика содержит компонент Status и опционно компонент Payment Scheme. Его целью является осуществление запроса о текущем состоянии транзакции или сервера. <!ELEMENT InquiryRespBlk (Status, PaySchemeData?)> Атрибуты:
Cодержимое:
8.14. Блок запроса Ping Блок запроса Ping используется, чтобы определить, работает ли сервер и является ли криптография совместимой. Определение блока запроса Ping предложено ниже. <!ELEMENT PingReqBlk (Org*)> Атрибуты:
Cодержимое: OrgОпционные компоненты Organisation (смотри раздел 7.6). Если нет ни одного компонента Organisation, тогда запрос Ping является анонимным и служит для проверки, работает ли сейчас сервер. Однако, если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping хочет проверить, могут ли быть обработаны цифровые подписи. В этом случае отправитель включает:
Эти компоненты используются для формирования подписи блока отклика Ping. 8.15. Блок отклика Ping Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping. Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation. <!ELEMENT PingRespBlk (Org+)> Атрибуты:
Cодержимое:
Компоненты Organisation отправителя отклика Ping всегда содержат кроме того компоненты Organisation, посланные в запросе Ping. Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping. 8.16. Блок подписи Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20. Определение блока Signature представлено ниже: <!ELEMENT IotpSignatures (Signature+, Certificate*) > Атрибуты:
Cодержимое:
Содержимое блока Signature зависит от торгового блока, который содержится в том же сообщении, что и блок Signature. 8.16.1. Блок подписи в отклике предложении Блок подписи, который содержится в том же сообщении, что и блок отклика Offer, несет в себе только компонент подписи отклика Offer (смотри раздел 7.19.2). 8.16.2. Блок подписи в платежном запросе Блок Signature, который содержится в том же сообщении, что и блок платежного запроса, содержит в себе:
8.16.3. Блок подписи в платежном отклике Блок подписи, который содержится в том же сообщении, что и блок платежного отклика, содержит только компонент подписи платежной расписки (смотри раздел 7.19.3), сформированной на этом этапе (шаге). 8.16.4. Блок подписи в запросе доставки Блок подписи, который содержится в том же сообщении, что и блок запроса доставки, содержит:
8.16.5. Блок подписи в отклике доставки Блок Signature, который содержится в том же сообщении, что и блок отклика доставки, содержит только компонент подписи отклика Delivery (смотри раздел 7.19.4), сформированный на этом шаге. 8.17. Блок ошибки Торговый блок Error содержит один или более компонентов Error (смотри раздел 7.21), которые несет в себе информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, полученном одной из торговых ролей, вовлеченных в сделку. Ниже представлены две фразы, которые используются в описании торгового блока Error:
Торговый блок Error может содержаться в любом сообщении, уведомляющем об ошибке. Реакция на такое сообщение зависит от серьезности (severity) ошибки. Разъяснения различных значений серьезности ошибки (и сопряженных с ними действий) дано в определении компонента Error. Несмотря на то что торговый блок Error может уведомлять о многих различных ошибках, используя несколько компонентов Error, разработчики приложений могут и не поддерживать такую возможность. Структура торгового блока Error представлена ниже. <!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) > Атрибуты:
Cодержимое:
8.18. Блок Cancel Блок Cancel используется одной торговой ролью чтобы информировать остальных о том, что транзакция аннулируется. Пример использования включает в себя:
Его определение имеет вид. <!ELEMENT CancelBlk (Status) > Атрибуты:
Cодержимое:
9. Транзакции IOTP Базовая версия протокола IOTP поддерживает три типа транзакций. Среди них:
- Депозит
- Транзакция запроса состояния и Хотя транзакции аутентификации могут выполняться сами по себе, опционно любая платежная операция может предшествоваться аутентификацией. Остальная часть данного раздела поделена на две части, где описывается:
9.1. Транзакции аутентификации и платежа Транзакции, имеющие отношение к аутентификации и платежу состоят из шести документальных обменов, которые объединяются в последовательности, чтобы реализовать определенную транзакцию. Вообще имеется теснаое но не точное соответствие между документальным и торговым обменами. Главное отличие заключается в том, что некоторые документальные обмены включают в себя часть или все два торговых обменов одновременно для того чтобы минимизировать число IOTP-сообщений, посылаемых через Интернет. Эти шесть документальных обменов включают в себя:
Эти документальные обмены скомбинированы вместе в различные последовательности, чтобы реализовать каждую из транзакций. Способ, которым они могут комбинироваться проиллюстрирован на рис. .17.
Рис. .17. Блок-диаграмма обмена сообщениями платежа и аутентификации Допустимые комбинации документального обмена зависят от конкретного типа транзакции IOTP. Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2). 9.1.1. Документальный обмен аутентификации Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 2.2.4). Он включает в себя:
Аутентификация состоит из:
Документальный обмен аутентификации предполагает также:
Запрос аутентификации может быть подписан цифровым образом, что позволяет аутентифицируемому, проверить доверительные параметры (credentials) аутентификатора. IOTP-сообщения, которые используются в таком обмене представлены на рис. .18.
Рис. .18. Документальный обмен аутентификации 9.1.1.1. Принципы обработки сообщений При получении ссобщения-запроса TPO & Authentication (смотри ниже), аутентифицируемый может:
Получив сообщение-отклик Authentication (смотри ниже), аутентификатор должен в ответ послать сообщение состояния аутентификации, содержащее блок Status с компонентом Status, где StatusType = Authentication и:
Получив сообщение состояния аутентификации (смотри ниже), аутентифицируемый должен проверить компонент Status в блоке состояния. Если он указывает на:
Если аутентификатор получает от Покупателя сообщение IOTP, содержащее блок Cancel, тогда аутентифицируемый может обратиться к сетевому узлу CancelNetLocn, специифицированному элементом торговой роли в компоненте Organisation для аутентификатора, указанного в блоке опций торгового протокола. 9.1.1.2. Сообщение запроса аутентификации и TPO Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:
Каждый из них описан ниже. Блок опций торгового протокола Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:
Блок запроса аутентификации Блок запроса аутентификации (смотри раздел 8.4) должен содержать следующие торговые компоненты:
Блок подписи (Запрос аутентификации) Если запрос аутентификации был снабжен цифровой подписью, то должен быть включен блок Signature. Он содержит дайджесты следующих XML-элементов:
9.1.1.3. Сообщение-отклик аутентификации IOTP Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:
Блок отклика AUTHENTICATION
Блок SIGNATURE (Отклик аутентификации) Если элемент Algorithm (смотри раздел 12) компонента запроса аутентификации содержащийся в блоке запроса аутентификации, указывает, что отклик аутентификации должен содержать цифровую подпись, тогда блок Signature должен быть включен в то же сообщение, где размещается блок отклика аутентификации. Компонент Signature содержит элементы дайджестов для следующиз XML-элементов:
Не следует предполагать, что все торговые роли могут поддерживать цифровую подпись данных. В частности не нужно думать, что эта опция поддерживается Покупателем. 9.1.1.4. Сообщение состояния аутентификации Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:
Блок состоояния аутентификации Блок состоояния аутентификации (смотри раздел 8.6) должен содержать следующие торговые компоненты:
Блок SIGNATURE (состояние аутентификации) Если блок состояния аутентификации подписан цифровым образом, тогда блок Signature должен включать то что содержать дайджесты следующих XML-элементов:
- компонент Status (смотри раздел 7.16). Если за документальным обменом аутентификации следует документальный обмен предложения (Offer) (смотри раздел 9.1.2), тогда блок состояния аутентификации и блок подписи (состояние аутентификации) могут объединяться с:
9.1.2. Обмен документами предложения Обмен документами предложения oвстречается в двух формах:
Каждый из этих типов документального обмена предложения может следовать за бокументальным обменом аутентификации (смотри раздел 9.1.1). 9.1.2.1. Документальный обмен предложения, зависящего от вида платежа В документальном обмене предложения, зависящего от вида платежа блоки TPO отклика Offer посылаются отдельно продавцом покупателю, т.e.:
Это проиллюстрировано на диаграмме ниже (рис. .19).
. продолжение ... Покупатель идентифицирует документальный обмен предложения, зависимого от вида платежа, с помощью отсутствия блока отклика Offer в первом сообщении IOTP. Обработка сообщений Получив сообщение TPO (смотри ниже), Покупатель может:
Получив сообщение выбора TPO (смотри ниже), Продавец может:
Получив сообщение отклика Offer (смотри ниже), Покупатель может:
Если продавец получает сообщение IOTP, содержащее блок Cancel, покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation продавца. Если покупатель получает сообщение, содержащее блок Cancel, тогда информация, содержащаяся в сообщении должна быть доведена до сведения покупателя. 9.1.2.2. Документальный обмен предложения, независимого от вида платежа В документальном обмене предложения, независящего от вида платежа, блоки TPO и отклика Offer посылаются вместе от продавца к покупателю, т.e. имеется одно сообщение IOTP, которое содержит блоки TPO и отклика Offer. Обмен сообщениями проиллюстрирован на рис. .20 ниже:
Рис. .20. Обмен для предложения, независимого от вида платежа Заметим, что документальный обмен предложения, независимого от видов платежа происходит, когда продавец предлагает покупателю лишь один вид платежа, протокол и вид валюты. Это может произойти и при нескольких предлагаемых видах платежа, если имеется один Кассир и все виды платежа используют один и тот же набор протоколов. Заметим, что блоки TPO и отклика Offer могут быть посланы в одном IOTP-сообщении (смотри документальный обмен предложения, зависимого от вида платежа), даже если блок отклика Offer не изменяется. Однако это увеличивает число сообщений в транзакции и следовательно может увеличить время отклика. Приложения, поддерживающие торговую роль Покупателя, должны проверять наличие блока отклика Offer в первом сообщении IOTP с тем чтобы определить, является ли обмен зависимым от вида платежа. Принципы обработки сообщений Получив сообщение TPO и отклика Offer (смотри ниже), Покупатель может:
Если продавец поличает сообщение, содержащее блок Cancel, тогда Покупатель вероятно направится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation для Продавца. 9.1.2.3. Сообщение TPO Сообщение используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), в это сообщение входит блок опций торгового протокола (смотри раздел 8.1), который описан ниже. Блок TPO (TRADING PROTOCOL OPTIONS) Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:
Если транзакция IOTP включает доставку, тогда блок TPO должен содержать:
Блоки подписи и состояния аутентификации Если за документальным обменом Offer следует обмен аутентификации, тогда сообщение TPO может также содержать:
Для получения подробностей смотри раздел 9.1.1.4 (сообщение о состоянии аутентификации). 9.1.2.4. Сообщение IOTP выбора TPO Сообщение выбора TPO используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок выбора TPO (смотри раздел 8.1), который описан ниже. Блок выбора TPO (смотри раздел 8.2) содержит:
9.1.2.5. Сообщение отклик на предложение IOTP Сообщение отклика Offer используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение состоит из:
Блок отклика предложения (блок отклика OFFER) Блок отклика Offer (смотри раздел 8.3) содержит следующие компоненты:
Блок подписи (отклик предложения) Если блок состояния аутентификации снабжен цифровой подписью, тогда должен быть включен блок Signature, который содержит компонент подписи (смотри раздел 7.19) с элементами дайджестов для следующих XML-элементов: Если отклик Offer снабжен цифровой подписью, тогда должен быть включен блок Signature, который содержит компонент подписи (смотри раздел 7.19) с элементами дайджестов для следующих XML-элементов:
9.1.2.6. Сообщение TPO и отклика Offer Сообщение TPO и отклика Offer используется только в документальном обмене предложения, независящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:
Блок TPO (TRADING PROTOCOL OPTIONS) Это тот же самый блок опций торгового протокола, что описан в IOTP-сообщении TPO (смотри раздел 9.1.2.3). Блок отклика OFFER Это тот же самый блок отклика Offer, что и в сообщении отклика Offer (смотри раздел 9.1.2.5). Если до документального обмена Offer имел место обмен аутентификации, тогда сообщение TPO и отклика Offer может содержать (смотри раздел 8.6). Блок подписи тот же самый блок Signature, что и в сообщении отклика Offer (смотри раздел 9.1.2.5), со следующими добавлениями:
9.1.3. Обмен документами при платеже Документальный обмен платежа является непосредственной реализацией последней части платежного обмена (смотри раздел 2.2.2) после того как вид платежа выбран покупателем. Платежный обмен состоит из:
IOTP-сообщения, которые используются при платежном обмене показаны на рис. .21.
Рис. .21. Обмен платежными документами 9.1.3.1. Принципы обработки сообщений Получив сообщение платежного запроса, кассир должен проверить, авторизован ли данный платеж (смотри раздел 6). Он может затем:
Получив платежное ообщение, Покупатель может:
Получив платежное ообщение, кассир может:
Получив платежное ообщение-отклик, Покупатель может:
Если покупатель получает сообщение, содержащее блок Cancel, тогда информация из сообщения IOTP должна быть доведена до сведения покупателя и не должны предприниматься никакие другие действия. Если кассир получает сообщение, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира, здесь он сможет предпринять некоторые дальнейшие действия. Если продавец получает сообщение, содержащее блок Cancel, тогда покупатель должен завершить операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца, здесь он сможет предпринять некоторые дальнейшие действия. 9.1.3.2. Сообщение платежного запроса Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение может содержать:
Блок платежного запроса (смотри раздел 8.7) состоит из:
Заметим, что:
Блок подписи (запрос платежа) Если предшествующий документальный обмен предложения содержал цифровую подпись(смотри раздел 9.1.2.5), или подпись была включена в предыдущий платежный отклик (смотри раздел 9.1.3.4), тогда они должны обе быть скопированы в блок подписи сообщения платежного запроса. 9.1.3.3. Сообщение платежного обмена IOTP Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок платежного обмена. Блок платежного обмена (смотри раздел 8.8) включает в себя:
9.1.3.4. Платежное сообщение отклика Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:
Платежный блок отклика (смотри раздел 8.9) включает в себя:
Блок подписи (платежный отклик) Если предоставлена подписанная платежная расписка, что индицируется атрибутом SignedPayReceipt= True компонента Payment, тогда блок Signature должен содержать компонент Signature, который содержит элементы дайджеста следующих видов:
9.1.4. Обмен документами при доставке Документальный обмен доставки является непосредственной реализацией торгового обмена доставки (смотри раздел 2.2.3). Он состоит из следующих шагов:
Схема обмена сообщениями представлена на рис. .22.
Рис. .22. Обмен документами при доставке 9.1.4.1. Принципы обработки сообщений Получив сообщение-запрос доставки, агент доставки должен проверить авторизацию выполнения такой операции (смотри раздел 6). Далее он может:
Получив сообщение-отклик доставки, покупатель может считать, что транзакция завершена. Если покупатель получает сообщение, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и дальнейшая работа прервана. 9.1.4.2. Сообщение запроса доставки IOTP Сообщение запроса доставки IOTP состоит из:
Блок запроса доставки (смотри раздел 8.10) содержит:
Блок подписи (запрос доставки) Если предыдущиц документальный обмен Offer содержит подпись отклика Offer илт платежный обмен содержит подпись платежного отклика, тогда тогда они должны быть скопированы в блок подписи. 9.1.4.3. Сообщение-отклик доставки Сообщение-отклик доставки содержит блок отклика доставки и опционно блок подписи. Блок отклика доставки содержит:
Блок подписи (отклик доставки) Блок подписи должен содержать один компонент подписи, который содержит элементы дайджеста, которые относятся к:
9.1.5. Обмен документами в процессе платежа и доставки Документальный обмен платежа и доставки представляет собой комбинацию последней части торгового обмена платежа (смотри раздел 2.2.2) и обмена доставки (смотри раздел 2.2.3). Он состоит из:
IOTP-сообщения, которые вовлечены в этот процесс, показаны на рис. .23.
Рис. .23. Документальный обмен платежа и доставки Блоки отклика доставки и платежного отклика могут быть обхединены в одном сообщении только если кассир имеет необходимую информацию, чтобы послать блок отклика доставки. Это вероятно так, если роли продавца, кассира и агента доставки совмещены. Атрибут DelivAndPayResp компонента доставки (смотри раздел 7.13), содержащийся в блоке отклика Offer (смотри раздел 8.3), делается равным True, если блоки отклика доставки и платежного отклика объединены в одном сообщении, и равен False, если блоки отклика доставки и платежного отклика посланы в разных IOTP-сообщениях. 9.1.5.1. Принципы обработки сообщений Получив сообщение платежного запроса или платежного обмена, кассир должен выполнить некоторые действия по документальному платежному обмену (смотри раздел 9.1.3.1). Получив сообщение платежного обмена, покупатель также должен выполнить некоторые действия по платежному документальному обмену (смотри раздел 9.1.3.1). По получении сообщения платежного отклика и отклика доставки транзакция завершена. Если покупатель получает сообщение IOTP, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и более никаких действий не предпринимается. Если кассир получает сообщение IOTP, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира. Если продавец получает сообщение IOTP, содержащее блок Cancel, тогда покупатель должен прервать операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца. Здесь он может предпринять какие-то дальнейшие действия. 9.1.5.2. Сообщение платежного запроса IOTP Содержимое этого сообщения то же, что и для запроса при платежном документальном обмене (смотри раздел 9.1.3.2). 9.1.5.3. Сообщение платежного обмена IOTP Содержимое этого сообщения то же, что и для платежного документального обмена (смотри раздел 9.1.3.3). 9.1.5.4. Сообщение платежного отклика и отклика доставки Содержимое этого сообщения включает в себя:
Содержимое блока платежного отклика то же, что и в платежном отклике при платежном документальном обмене (смотри раздел 9.1.3.4). Блок SIGNATURE (отклик PAYMENT) Содержимое этого блока то же, что и в блоке Signature (платежный отклик) при платежном документальном обменее (смотри раздел 9.1.3.4). Содержимое блока отклика доставки то же, что и в блоке отклика доставки при платежном документальном обменее (смотри раздел 9.1.4.3). 9.1.6. Базовая транзакция аутентификации Базовая транзакция аутентификации может иметь место в любое время между торговыми ролями, вовлеченными в сделку IOTP. Это означает, что она может иметь место:
Базовая транзакция IOTP аутентификации предполагает обмен аутентификационными документами (смотри раздел 9.1.1) как это показано на рис. .24.
Рис. .24. Базовая транзакция аутентификации Пример, использующий базовую транзакцию аутентификации, включает в себя следующие процедуры:
9.1.7. Базовая транзакция депозита Базовая транзакция депозита поддерживает операции по размещению депозита электронных средств в финансовой орнганизации. Финансовая организация в этой операции выполняет роль продавца (депозита электронных средств), который предлагает эту услугу за определенное вознаграждение, которое может поступить, например, с некоторого счета клиента в другом банке. Базовая транзакция депозита включает в себя следующие документальные обмены:
Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на рис. .25.
Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям. Заметим, что:
9.1.8. Базовая транзакция покупки Базовая транзакция покупки поддерживает покупку товаров или услуг с применением любых платежных методов. Она включает в себя следующие документальные обмены:
Способы, какими эти документальные обмена могут комбинироваться показаны на рис. .26.
Чтобы определить, какие комбинации документальных обменов встречаются в каждой из транзакций смотри раздел 9.1.12. 9.1.9. Базовая транзакция возврата денег Процесс возврата денег обычно состоит из:
Базовая транзакция возврата денег поддерживает субнабор возможностей перчисленных выше, в частности поддерживает:
Способы того, как эти документальные обмены взаимодействуют, показаны на рис. .27.
Базовая транзакция возврата денег без документального обмена аутентификации может использоваться:
9.1.10. Базовая транзакция отзыва платежа Базовая транзакция отзыва поддерживает возврат электронных средств из финансовой организации. Финансовая организация в рамках технологии IOTP имеет в этой транзакции, роль Продавца - за выполнение этой операции она может получить определенную оплату. Базовая транзакция отмены сделки включает в себя следующие документальные обмены:
Способы, какими эти документальные обмены могут комбинироваться показаны на рис. .28.
Заметим, что:
9.1.11. Базовая транзакция обмена ценностями Базовая транзакция обмена ценностями использует документальный обмен платежа, чтобы поддержать обмен ценностями в одной валюте с помощью одного метода оплаты и с привлечением той же или (обычно) другой валюты с помощью того же или иного платежного метода (встречный платеж). Примеры реализации такой процедуры включают в себя:
Базовый обмен ценностями использует следующие документальные обмены:
Способы, которыми эти документальные обмены комбинируются друг с другом изображены на рис. .29.
Базовая транзакция обмена ценностями осуществляется в двух вариантах:
В выше приведенном примере фигурирует роль продавца, хотя организацией, выполняющей обмен ценностями может быть банк или какая-то другая финансовая организация. Это потому, что банк выполняет здесь роль продавца, направляя покупателю предложение, которое он может принять или отвергнуть. Блоки TPO и отклика Offer могут быть объединены в одном сообщении, только если содержимое блока отклика Offer не изменяется в результате выбора вида платежа и платежного протокола для обмена ценностями. Использование подписей, чтобы гарантировать целостность обмена ценностями проиллюстрирована на диаграмме рис. .30.
9.1.12. Допустимые комбинации документальных обменов Диаграмма на рис. .31. иллюстрирует информационные условия в различных IOTP-сообщениях, которые могут быть использованы покупателем, чтобы определить допустима или нет конкретная комбинация документальных обменов.
1) Если первое сообщение IOTP транзакции содержит запрос аутентификации, то:
2) В противном случае (отсутствие запроса аутентификации в первом сообщении IOTP):
3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:
Ниже представлена таблица типов транзакций, которые могут удовлетворять условиям перечисленным выше.
9.1.13. Комбинирование аутентификации с другими транзакциями Имеется возможность запустить независимую транзакцию аутентификации в любой момент времени, даже в параллель с другой транзакцией IOTP. Обычно она используется:
В общих чертах базовый процесс состоит из:
Покупатель, например, может:
Кассир может аутентифицировать покупателя после получения платежного запроса и до посылки следующего сообщения, относящегося к платежу. агент доставки может аутентифицировать покупателя после получения запроса доставки и до посылки отклика доставки. Некоторые платежные методы могут выполнять аутентификацию в ходе платежного обмена. В этом случае информация, необходимая для выполнения аутентификации будет включаться в компоненты платежной схемы. В этом примере приложение IOTP не будет уверено, что аутентификация состоялась, так как компоненты платежной схемы, которые содержат аутентификационную информацию, не отличимы о других компонентов платежной схемы. 9.2. Инфраструктурные транзакции Инфраструктурные транзакции разработаны, для поддержки запросов, прошла ли транзакция успешно или работает ли корректно некоторая торговая роль. Существует два типа таких транзакций:
9.2.1. Базовая транзакция запроса состояния транзакции IOTP Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:
Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:
Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются. Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:
Базовыми требованиями являются:
Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:
Рабочие ошибки в исходных сообщениях Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним. Технические ошибки в исходных сообщениях Возврат блока информационного отклика, содержащего компонент Status. Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка. Технические ошибки в блоке информационного запроса Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса. Сообщения информационого запроса транзакции На рис. .32 рассмотрен процесс реализации базовой транзакции информационого запроса.
Рис. .32. Базовая транзакция статусного запроса Блок ссылок транзакции Торговая роль, делающая информационный запрос, должна использовать Id-компонент (смотри раздел 3.3.1), где атрибуты IotpTransId и TransTimeStamp имеют те же значения, что и в Id-компоненте исходной транзакции, объекта запроса. Атрибут IotpTransID в этом компоненте выполняет роль ключа при запросе записей, которые ведет торговая роль. Значение ID-атрибута Id-компонента должно быть отличным от любых других в исходной транзакции (смотри раздел 3.4.1). Если требуются текущие статусные данные, компонент MsgId, и конкретный ID-атрибут для компонента MsgId должен отличаться от любых других в сообщениях, посланных торговой роли. Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты:
Блок подписи (информационный запрос) Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен, чтобы определить, авторизован ли этот запрос. Если присутствует блок подписи информационного запроса (смотри раздел 8.12), то он содержит следующие компоненты:
Блоки информационного отклика должны формироваться, только если транзакция авторизована. Цифровые подписи информационного запроса ставятся только в том случае, если получатель ожидает получение подписанных запросов. В данной версии IOTP это требует предварительного согласования. Это означает, что:
С другой стороны, если исходная транзакция, к которой относится запрос, реализована через безопасный канал (напр., [SSL]), тогда разумно предположить, что, если отправитель информационного запроса знает Id-компонент исходного сообщения (включая, например, временную метку), то запрос является подлинным. Блок отклика INQUIRY (смотри раздел 8.13) содержит следующие компоненты:
Блок SIGNATURE (отклик информационного запроса) Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен получателем на предмет корректности информационного отклика. Если блок подписи информационного отклика присутствует (смотри раздел 8.13), он содержит следующие компоненты:
Цифровые подписи информационного отклика могут использоваться, только если получатель ожидает прихода подписанных откликов. В данной версии IOTP tэто предполагает предварительное согласование применение цифровых подписей. Это означает, что:
9.2.2. Базовая транзакция Ping Целью базовой транзакции IOTP Ping является проверка коннективности между торговыми ролями, принимающими участие в транзакции. Это позволяет приложению IOTP сделать следующее:
Например, эта транзакция может быть использована продавцом, чтобы определить, функционирует ли кассир или агент доставки, прежде чем запускать транзакцию, требующую участия этих торговых ролей. Торговыми блоками, используемыми транзакцией Ping, являются:
Сообщения PING На рис. .33 отображен обмен сообщениями прибазовой транзакции Ping.
Рис. .33. Базовые сообщения транзакции Ping Верификация того, что подписи могут обрабатываться, осуществляется отправителем блока запроса Ping путем включения:
Получатель запроса Ping таким образом:
Заметим, что запрос Ping:
Все приложения IOTP должны присылать отклики Ping отправителю запросов Ping, сразу по получении. Базовый запрос IOTP Ping может также содержать опционный блок подписи. Приложение IOTP может, например, использовать блок подписи для проверки того, способен ли получатель этого запроса формировать и верифицировать цифровые подписи. Для каждой транзакции Ping, каждая роль IOTP может устанавливать различные транспортные сессии. Любая торговая роль IOTP может посылать запрос Ping любой другой торговой роли. Сообщение Ping имеет свой собственный IotpTransId, который отличается от соответствующего параметра других транзакций. Блок ссылок транзакции IotpTransId транзакции Ping должен быть уникальным и отличать данную транзакцию от любых других. Блок запроса PING Если транзакция Ping является анонимной, тогда в блок запроса Ping включается компонент no Organisation (смотри раздел 8.7). Если транзакция Ping не анонимна, то блок запроса Ping содержит компоненты Organisation для:
Если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping сформировал блок подписи. Блок подписи должен быть верифицирован торговой ролью, которая получила этот запрос Ping. Блок подписи запроса Ping (смотри раздел 8.16) содержит следующие компоненты:
Блок отклика PING Блок отклика PING (смотри раздел 8.15) содержит следующие компоненты:
Если транзакция Ping не является анонимной, тогда отклик Ping дополнительно содержит:
Блок SIGNATURE (отклик PING) Блок подписи отклика Ping (смотри раздел 8.16) содержит следующие компоненты:
10. Получение логотипов Ниже описано, как извлекать логотипы для отображения их программой IOTP, используя атрибут Logo Net Locations, содержащийся в элементе вида платежа (смотри раздел 7.7.1) и компоненте Organisation (смотри раздел 7.6). Полный адрес логотипа определяется следующим образом: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif" Где:
Logo_size и Logo_color_depth специфицирует разработчик программы IOTP, которая извлекает логотип, в зависимости от размера и цвета, который желательно иметь. 10.1. Размер Logo Имеется пять стандартных рамеров логотипа. Размеры в пикселях соответствуют в таблице значениям размера логотипа.
10.2. Насыщенность цвета логотипа Существует три стандартных значения насыщенности цвета. Насыщенность цвета (включая число бит на пиксель) и соответствующее значение для Logo_Color_Depth представленны ниже в таблице.
Заметим, что если насыщенность цвета логотипа пропущена, тогда извлекается логотип с 256 цветами. 10.3. Примеры логотипа для сетевой позиции Если логотип сетевой позиции равен "ftp://logos.xzpay.com", тогда:
Организации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif". 11. Виды платежа 11.1. Определения и выбор вида платежа Одной из ключевых черт IOTP является возможность для продавца предложить список видов платежа, чтобы покупатель мог сделать выбор. Ниже рассматриваются:
11.1.1. Определение платежного инструмента Платежный инструмент является средством, с помощью которого покупатель платит за товар или услуги, предлагаемые продавцом. Это может быть, например:
Большинство платежных инструментов имеют номер, обычно это номер счета, по которому можно идентифицировать платежный инструмент. 11.1.2. Определение вида платежа Вид платежа часто представляет собой марку, которая идентифицирует конкретный тип платежного инструмента. Список видов платежа представляет собой опции, которые предоставляются продавцом покупателю и из которых покупатель делает свой выбор. Каждый вид платежа может иметь разных кассиров. Среди примеров вида платежа:
11.1.3. Определение двойственного вид платежа (Dual Brand) Двойственный вид платежа (Dual Brand) означает, что отдельный платежный инструмент может использоваться так, как если бы это были два отдельных вида платежа. Например, может существовать одна японская карта "UC" (MasterCard), которую можно использовать как UC-карту или как обычную MasterCard. Виды платежа через UC-карту и MasterCard могут иметь своих собственных, отличных друг от друга Кассиров. Это означает, что:
Двойственные виды платежа не требуют какого-то специального обслуживания продавцом и, следовательно, не нужно как-то выделять эти виды платежа в DTD. Это происходит потому, что в той части, которая касается продавца, каждый вид платежа в двойственном виде платежа рассматривается как независимый. Только покупатель должен находить соответствие между предлагаемым видом оплаты и имеющимся двойственным платежным инструментом. 11.1.4. Определение стимулирующего вида оплаты Поощрительный вид оплаты предполагает, что если покупатель им воспользуется, то он получит какие-то дополнительные выгоды. Эти выгоды могут быть получены двумя путями:
Заметим, что:
11.1.5. Идентификация льготных видов платежа Имеется две проблемы, которые нужно решить при идентификации поощрительных видов платежа:
11.1.5.1. Идентификация поощрительных видов платежа Продавцом/Кассиром Правильная идентификация того, что покупатель воспользовался поощрительным видом платежа, крайне важно, так как покупатель может объявить, что он имеет право на скидку, которая действует для поощрительного вида платежа, в то время как в действительности это не так. Здесь возможны два подхода:
Заметим, что:
IOTP не предоставляет продавцу информации о платежном инструменте (напр., карте или номере счета). Эти данные посылаются кассиру в качестве части инкапсулированного платежного протокола. Это означает, что:
Проверка кассиром, является ли платеж льготным, возможна, если кассир совмещает функции и эмитента карты. 11.1.5.2. Выбор Покупателем льготных видов платежа Существует два способа, как покупатель может выбрать правильно льготный вид платежа:
В последнем случае, код покупателя должен совпадать с кодом из списка продавца, в противном случае соответствие не будет зарегистрировано. Способы, которыми программа IOTP покупателя может получить такой код, включают:
11.1.5.3. Рекомендации для Id видов платежа в программе покупателя Новые Id видов платежа выдаются в соответствии с процедурой, заданной IANA (смотри раздел 12). Рекомендуется, чтобы разработчики приложений IOTP покупателя (напр., платежных программ) обеспечивали предварительную загрузку текущего набора идентификаторов вида платежа и предлагали средства пополнения этого списка. 11.2. Примеры видов платежаДанный пример содержит три образца XML для компонента списка видов платежа:
11.2.1. Простой пример, базирующийся на кредитной карте Этот простой пример включает в себя:
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h' 11.2.2. Список платежей с помощью кредитной карты, включая льготные платежи Пример списка видов платежей с помощью кредитной карты представлен ниже. Он включает в себя:
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase ladies coat' PayDirection='Debit'> 11.2.3. Пример выбора вида платежа Для оплаты через 'British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид: <BrandSelection ID='C1.2' BrandListRef='M1.3' BrandRef='M1.5' ProtocolAmountRef='M1.7' 11.2.4. Список видов платежа, базирующихся на комплексных электронных деньгах Ниже представлен достаточно сложный пример, который включает в себя:
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Company report on XYZ Co' 12. Соображения IANA 12.1. Коды контролируемые IANA Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434. Типы элементов и имена атрибутов, к которым эта процедура применяется, приведены ниже в таблице вместе с исходными величинами, разрешенными для этих атрибутов. Заметим, что:
За исключением алгоритмов, которые начинаются с "pay:", новые значения выделяются после просмотра торгового почтового списка IETF и с привлечением "специального эксперта". Элемент Algorithm обычно определяется в пределах пространства имен [DSIG]. Со временем эта процедура может измениться.
Новые значения BrandId должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.
Если CurrCodeType = "ISO4217-A", тогда код валюты является буквенным, определенным в [ISO4217]. Если CurrCodeType = "IOTP", тогда новые значения должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления. Код типа валюты IOTP, сконструирован так, чтобы позволять поддержку "новых" псевдовалют, таких как loyalty или frequent flyer points. На момент написания этого документа ни один из таких кодов не был лпределен.
Новые значения атрибута CurrCodeType выделяются после публикования через подписной лист IETF и рассмотрения экспертами.
Новые значения атрибута Delivery Method выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется данный метод доставки.
Если атрибут Content имеет форму "MIME:mimetype", тогда управление новыми значениями для "mimetype" определено в [MIME]. В противном случае, новые значения атрибута Content выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется новый атрибут в элементе Packaged Content.
Новые значения атрибута RelationshipType выделяются после публикования через подписной лист табочей группы IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как осуществляется метод доставки.
Документ, описывающий новые значения атрибута Status Type, может быть объединен с документами, описывающими новые торговые роли и типы подписей (смотри ниже).
Документ, описывающий новые значения атрибута Trading Role может быть объединен с документами, описывающими новые значения Status Types (смотри выше) и типы подписей (смотри ниже).
Документ, описывающий новые значения типа подписи, может быть объединен с документами, описывающими новые типы Status и торговые роли (смотри выше). 12.2. Коды, неконтролируемые IANA Помимо формального выбора и регистрации кодов, как это описано выше, для разработчиков существует необходимость экспериментировать с новыми кодами IOTP. По этой причине могут использоваться "коды определенные пользователем", что не требует регистрациив IANA. Определение кода, задаваемого пользователем, выглядит следующим образом: user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
Рекомендуется использование имен доменов (смотри [DNS]), для того чтобы сделать коды, определенные пользователем, уникальными, хотя этот метод и не является совершенно надежным. 13. Определения типов данных протокола IOTP Этот раздел содержит XML DTD для IOTP. <!-- <!-- <!ELEMENT MsgId EMPTY>
SenderTradingRoleRef NMTOKEN #IMPLIED
<!ELEMENT RelatedTo (PackagedContent) > <!ATTLIST RelatedTo ID ID #REQUIRED
<!--
*********************** * Торговые компоненты * *********************** --> <!-- PROTOCOL OPTIONS COMPONENT --> <!ELEMENT ProtocolOptions EMPTY > <!ATTLIST ProtocolOptions ID ID #REQUIRED
SuccessNetLocn CDATA #REQUIRED> <!-- AUTHENTICATION DATA COMPONENT -->
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT TradingRole EMPTY> ><!ATTLIST TradingRole ID ID#REQUIRED
<!ELEMENT ContactInfo EMPTY> <!ATTLIST ContactInfo xml:lang NMTOKEN #IMPLIED
<!ELEMENT PersonName EMPTY >
<!ELEMENT PostalAddress EMPTY>
LegalLocation (True | False) 'False' >
(Debit | Credit) #REQUIRE>
ContentSoftwareId CDATA #IMPLIED>
ContentSoftwareId CDATA #IMPLIED>
CurrCode CDATA #REQUIRED>
ContentSoftwareId CDATA #IMPLIED >
ProtocolAmountRef NMTOKEN #REQUIRED
StartAfterRefs NMTOKENS #IMPLIED>
<!ELEMENT PayReceipt (PackagedContent*) >
<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT DeliveryData (PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED>
ContentSoftwareId CDATA #IMPLIED >
<!-- TRADING ROLE DATA COMPONENT -->
ProcessReference CDATA #IMPLIED >
<!ELEMENT ErrorLocation EMPTY >
AttName NMTOKEN #IMPLIED> <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )> <!ATTLIST TpoBlk ID ID #REQUIRED > <!-- TPO SELECTION BLOCK --> <!ELEMENT TpoSelectionBlk (BrandSelection+)> <!ATTLIST TpoSelectionBlk ID ID #REQUIRED> <!-- OFFER RESPONSE BLOCK --> <!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)> <!ATTLIST OfferRespBlk ID ID #REQUIRED > <!-- AUTHENTICATION REQUEST BLOCK --> <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)> <!ATTLIST AuthReqBlk ID ID #REQUIRED> <!-- AUTHENTICATION RESPONSE BLOCK --> <!-- AUTHENTICATION STATUS BLOCK --> <!-- PAYMENT REQUEST BLOCK --> <!-- PAYMENT EXCHANGE BLOCK --> <!-- PAYMENT RESPONSE BLOCK --> <!-- DELIVERY RESPONSE BLOCK --> <!-- INQUIRY REQUEST BLOCK --> <!-- INQUIRY RESPONSE BLOCK --> <!-- PING REQUEST BLOCK --> <!-- PING RESPONSE BLOCK --> <!-- ERROR BLOCK --> <!-- CANCEL BLOCK --> <!-- <!ELEMENT Signature (Manifest, Value+) > <!ELEMENT Manifest ( Algorithm+, <!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED> <!ELEMENT Algorithm (Parameter*)> <!ELEMENT Digest (Locator, Value)> <!ELEMENT Attribute ( ANY ) > <!ELEMENT OriginatorInfo ANY > <!ELEMENT RecipientInfo ANY > <!ELEMENT KeyIdentifier EMPTY> <!ELEMENT Parameter ANY > <!ATTLIST Certificate ID ID #IMPLIEDtype NMTOKEN #REQUIRED> <!ELEMENT IssuerAndSerialNumber EMPTY > <!ELEMENT Locator EMPTY> 14. Словарь В этом разделе содержится словарь некоторых терминов, используемых в данной спецификации.
15. Ссылки
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.6 Электронная торговля в Интернет
UP:
4.5.8 Поиск узлов и людей
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.6.2 SET и другие системы осуществления платежей
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Идеальная платежная система должна отвечать следующим требованиям:
Ни одна из существующих платежных систем не отвечает всем этим требованиям в полной мере. Существует много платежных схем, например: А. Электронные монеты Разумеется, могут существовать и методы, сочетающие в себе любые комбинации этих схем. Эти методы должны работать не только с традиционными деньгами, но с их заменителями, акциями, облигациями, золотыми слитками, товарами и услугами. Во всех моделях помимо основных участников - продавца и покупателя , необходим посредник. Назовем его банкиром (кассиром) . Теперь рассмотрим названные выше платежные модели более подробно. Модель электронных монет Эта схема моделирует традиционную денежную систему. Банкир формирует цифровые сертификаты, называемые монетами, и приобретаемые участниками сделок. Эти сертификаты могут быть банкиром выкуплены. Клиенты используют эти сертификаты (монеты) для расчетов как обычные деньги. Эту модель достаточно трудно реализовать из-за проблемы повторного использования сертификатов для покупок. Есть у этой модели и преимущества, например, плательщик не должен иметь контакт с банкиром в реальном масштабе времени в момент платежа, да и уровень конфиденциальности здесь вполне приемлем. Модель электронных чеков Данная модель с хорошей точностью воспроизводит практику применения обычных чеков. Клиент заполняет электронный чек, который представляет собой платежное поручение. Этот чек подписывается электронным образом и передается партнеру (например, продавцу), который предъявляет его банкиру. Банкир проверяет корректность чека, наличие необходимых средств на счете клиента, заполнившего чек, и, если все в порядке, переводит средства на счет продавца. Преимуществом этой модели является простота, легкость разрешения любых споров, а также отсутствие требование выполнения всех операций в реальном масштабе времени. Уровень конфиденциальности здесь также вполне разумен. Модель электронных переводов Данная модель простейшая из описанных. Плательщик выдает платежное поручение банкиру, снабжая его электронной подписью. Банкир верифицирует платежное поручение, проверяет наличие средств и, если все в порядке, осуществляет перевод денег. Операция со стороны плательщика выполняется в реальном масштабе времени. Эта модель прозрачна, получатель перевода не должен быть доступен в реальном масштабе времени. Схема хороша для начисления зарплаты, но совершенно не приемлема для торговли через Интернет. Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты.
Не менее важную роль имеет конфиденциальность любых финансовых операций.
Это не следует рассматривать как исчерпывающий список требований к безопасности и конфиденциальности. 4.6.2.1. Протокол микроплатежей MPTP (Micro Payment Transfer Protocol) Разработчики технологии WWW, HTML и XML (группа W3C; http://www.w3.org/TR/WD-mptp-951122) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром ("PayWord and MicroMint - Two Simple Micropayment Schemes", R.L. Rivest and A.Shamir; http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно. Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line. Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк. При разработке протокола принимались во внимание следующие риски.
Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М). Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной. Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина. Схема PayWord является кредитной и практически реализует схему электронных монет. Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид: СП = [B, ID, AП, PKП, E, IП]SKB где B - идентификатор (имя) брокера; ID - идентификатор покупателя; AП - адрес доставки; PKП - общедоступный ключ покупателя; Е - время истечения действия сертификата (брокер может обновлять его, например, раз в месяц); IП - дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB - секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером. Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии). Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день. Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, ., wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению: wi = H(wi+1) для i= n-1, n-2,.,0. Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H - представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера. i-платеж (для i = 1, 2, .) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, ., wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца. Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж. В некоторых платежных схемах обязательство выполняет функцию электронной кредитной карты или чека. 4.6.2.2. MicroMint MicroMint (при вольной интерпретации это выражение можно перевести как микромонетный двор) представляет собой еще одну платежную систему, базирующуюся на модели электронных монет. Здесь не используется общедоступный ключ шифрования. Электронные монеты в этой схеме формируются брокером, который продает их пользователям. Пользователи передают эти монеты продавцам в качестве оплаты товаров или услуг. Продавцы возвращают эти монеты брокеру, который осуществляет перевод реальных денег на счет продавца. Электронная монета представляет собой последовательность бит, которая может быть легко проверена, но которую достаточно трудно сформировать. Алгоритм MicroMint устроен так, что формирование большого числа монет стоит дешевле (из расчета на одну монету), чем формирование одной или нескольких. Брокер формирует партию монет, например раз в месяц. При этом действие прежней партии монет истекает, и они не могут более использоваться. Продавцы возвращают полученные монеты в конце каждого дня. Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х1,х2) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш-функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений. k-кратным столкновением называется набор строк х1, х2, ., хk для которых H(x1)=H(x2)=.=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, ., хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие. H(x1)=H(x2)=.=H(xk)=y Если в ходе вычисления хэш-функций просматривать результат, то можно выявить определенное число k-кратных столкновений, что во много раз увеличивает производительность генерации электронных монет. Еще большего выигрыша в скорости можно достичь, применяя специфические аппаратные реализации. Предположим, что брокер хочет иметь чистый доход размером в 1 млн. долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов. Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA - программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу. При продаже монет клиенту брокер запоминает, какому клиенту какие монеты проданы, что позволяет в будущем проконтролировать попытки злоупотреблений. Неиспользованные монеты ликвидируются в конце месяца. Ограничение времени действия монет создает определенные трудности для клиента. Но за то это ограничивает требуемые объемы баз данных, хранящих информацию о выпущенных и использованных уже монетах. Монетная система по своей природе предполагает определенное доверие между плательщиком и получателем платежа. Получатель может присвоить монету и заявить, что она уже была использована, а плательщик может предъявить претензии получателю (банку или продавцу), утверждая, что повторного использования не было, а монета просто присвоена. В сущности, это является общим свойством любых монет и сертификатов на предъявителя. Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, ., хk). Это может осуществляться автоматически программой WEB-броузера. Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется. Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри "PayWord and Micromint: Two simple micropayment schemes" Ronald L. Riverst и Adi Shamir, 7 мая 1996). Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет. Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств.
Возможность кражи монет в ходе пересылки блокируется с помощью шифрования, что легко осуществить, так как взаимоотношения между клиентами продавцами и брокерами являются долгосрочными и доверительными. Схема MicroMint не является анонимной, поэтому брокер легко может детектировать попытки повторного использования монет. Обнаружить мелкого злоумышленника трудно, но из-за низкой цены монет это не может вызвать проблем. Генерация монет, специфических для клиента или продавца делают кражу бесполезной. Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно. Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, ., хk)=h(U), где h - хэш-функция, формирующая 16-битовый код. Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты. При малых же группах брокер будет вынужден производить слишком большую вычислительную работу. Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, ., хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),., yk=(xk) удовлетворяют условию yi+1 - yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,.,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным. Существуют алгоритмы, которые позволяют сократить вычислительные издержки при массовой генерации монет сразу на несколько месяцев. Другие системы для осуществления небольших платежей, например, NetBill предлагают дополнительные возможности (например, заказы товара и шифрование информации о покупке), но они относительно дороже. 4.6.2.3. Безопасный протокол электронных платежей SET Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions; см. http://www.visa.com/cgi-bin/vee/sf/standard.html http://www.citynet.net/personal/till/set1.htm), разработанный совместно компаниями Visa, MasterCard, Netscape (http://www.netscape.com) и Microsoft (см. также достаточно полное англоязычное описание протокола по адресу ftp://saturn.itep.ru/../set_bk1.pdf и т.д. "SET - Secure Electronic Transaction Specification"). Полная документация по SET имеет объем около 970 страниц. Данная статья является изложением базовых принципов и понятий. В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет. В РФ в настоящее время разработано и разрабатывается большое число различных платежных программ, некоторые из них достаточно совершенны. Здесь следует иметь в виду, что если российские торговые компании и банки не хотят оказаться в изоляции, если они не будут учитывать складывающиеся тенденции и стандарты, шансов конкурировать на международном, а вскоре и на отечественном рынке у них не будет. Для этого нужно снять ряд юридических ограничений, действующих в РФ и блокирующих развитие электронной торговли (это касается прежде всего алгоритмов RSA, электронной подписи и т.д.). На базовом уровне SET осуществляет следующие функции:
На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:
Окончательная версия протокола SET была выпущена в мае 1997 года. Протокол работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (issuer - эмитент), продавцом (merchant) и банком, где помещен счет продавца (acquirer). Помимо этих функциональных субъектов в процессе обычно (опционно) участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники. Основной целью сертификатов является подтверждение того, что присланный общедоступный ключ прибыл от настоящего отправителя, а не от самозванца. Практика электронной торговли позволяет выделить семь этапов сделки.
Порядок следования этапов при определенных условиях может несколько варьироваться. Спецификация SET определяет функции и технику реализации этапов 5, 6, 7 и 9. Таким образом, работа протокола SET инициализируется владельцем карты. Владельцем карты может быть как частное лицо, так и корпоративный клиент, работающие на своих рабочих станциях. Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии. Напрашивается вопрос, почему для финансовых операций не использовать протокол SSL, который весьма широко распространен? SSL позволяет безопасно передавать продавцу номер кредитной карточки покупателя, но не способен реализовать многие другие операции, например, проверить этот номер на правильность, проконтролировать, позволено ли данному клиенту пользоваться данной карточкой и т.д.. Конечно, не трудно создать CGI-скрипты, которые решат некоторые из этих проблем, но это не может заменить контроля в реальном масштабе времени, необходимого для некоторых операций. Нельзя утверждать, что в рамках протокола SSL нельзя решить и эти проблемы, но для этого нужно создать достаточно большое число специализированных программ, которые в существующих пакетах пока отсутствуют. Кроме того, нужно думать и о безопасности на стороне сервера. Продавец, получив номер кредитной карточки, может занести его в базу данных. А где гарантия (для покупателя), что эта база данных достаточно хорошо защищена? Таким образом, даже передача номера кредитной карточки посредством SSL не самая лучшая идея. Тем более такая схема позволяет осуществлять подбор номеров кредитных карт. А заботиться об удобствах воров не самое полезное занятие. Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры - код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму. Каждая цифра номера умножается на его "вес". Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы). Схема взаимодействия субъектов в протоколе SET показана на рис. 4.6.2.1 (взаимодействия с центром сертификации не показаны). Протокол SET помогает реализовать следующие процедуры.
Рис. 4.6.2.1. Схема взаимодействия субъектов протокола SET
Итак, видно, что каждый шаг реализации протокола SET сопровождается аутентификацией. Это препятствует какому-то внешнему субъекту стать посредником и видоизменять сообщения. Для нормальной работы протокола SET все участники должны зарегистрироваться и снабдить партнеров своим общедоступным ключом. Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец. Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование. В вышеприведенном описании предполагалось, что все субъекты процедуры уже владеют соответствующими ключами. На практике до начала такого обмена все участники должны зарегистрироваться (пройти процедуру аутентификации через соответствующий центр), обменяться общедоступными ключами. Общедоступный ключ сопровождается электронной подписью отправителя (X.509v3). Схема регистрации владельца карты в центре сертификации (СА) показана на рис. 4.6.2.2. Процесс регистрации проходит через 7 состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.
Рис. 4.6.2.2. Регистрация владельца карты в центре сертификации Сертификаты владельцев карт являются электронным представлением самих платежных карт. Так как они подписаны цифровым образом, их не сможет модифицировать третья сторона. Сертификат владельца карты не содержит номера счета и срока ее действия. Вместо этого там закодирована с привлечением хэш технологии информация о счете и секретный код, известный только программе владельца карты. Если номер счета, срок его действия и секретный код известны, корректность сертификата может быть проверена, но извлечь эту информацию из сертификата, даже зная часть перечисленных параметров практически невозможно. В рамках протокола SET владелец карты передает информацию о счете и секретный код расчетному центру, где эта информация верифицируется. Сертификат посылается владельцу карты только в случае, когда это одобряется финансовой организацией, выпустившей эту карту. Запрос сертификата указывает на то, что владелец карты намерен выполнить какую-то коммерческую операцию. Полученный сертификат передается продавцу в рамках запроса покупки вместе с платежными инструкциями. Получив сертификат владельца карты, продавец может быть уверен, что счет владельца карты существует и действует, что подтверждено эмитентом карты или его агентом. В рамках SET сертификаты владельцев карты опционны и оставлены на усмотрение платежной системы. Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы (brand). Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче). Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже. Сертификаты продавца индицируют поддержку определенной платежной системы. Так как сертификаты продавца снабжены цифровой подписью, они не могут быть модифицированы третьей стороной. Эти сертификаты одобряются банком продавца и предоставляют гарантию того, что продавец имеет официальное соглашение со своим банком. Для работы в среде SET продавец должен иметь как минимум пару сертификатов для каждой разновидности, поддерживаемой им платежной системы. Схема процедуры регистрации продавца показана на рис. 4.6.2.3 и содержит в себе 5 этапов.
Рис. 4.6.2.3. Регистрация продавца. Продавец должен зарегистрироваться в СА до того, как он получит платежные инструкции от владельца карты или будет участвовать в транзакциях с расчетным центром. Перед посылкой запроса СА продавец должен получить его общедоступный ключ. Продавец должен также скопировать регистрационную форму в своем банке и идентифицировать получателя в запросе регистрации, посылаемом в СА. Регистрационная процедура начинается с посылки СА запроса сертификата СА, содержащего его общедоступный ключ и соответствующую регистрационную форму. СА идентифицирует банк продавца и выбирает подходящую регистрационную форму. В отклик СА вкладывается эта форма и его сертификат, содержащий общедоступный ключ. Этот сертификат продавец в дальнейшем использует в регистрационном процессе. Раз программа продавца имеет копию СА-сертификата, продавец может воспринимать платежные инструкции и обрабатывать транзакции SET. Прежде чем запрос сертификата будет обработан, продавец должен установить связь со своим банком (получателем). Продавцу нужны две пары общедоступных/секретных ключей - для ключевого обмена и для цифровой подписи. Эти ключи формируются программой продавца. Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА. Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу. После этого СА проверяет информацию регистрационного запроса, используя известные данные о продавце. Для этого производится обмен между СА и банком продавца (получателем). После успешной верификации этих данных СА формирует и цифровым образом подписывает сертификат продавца. Время действия сертификата определяется политикой СА. Но это время не должно быть больше длительности контракта между продавцом и его банком. Сертификат шифруется сгенерированным новым симметричным ключом, который в свою очередь шифруется общедоступным ключом продавца. Полученный код образует цифровой конверт отклика. Сообщение-отклик посылается продавцу. Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца. SET может работать в режиме, когда участники не имеют сертификатов и не прошли аутентификацию. Такой режим сопоставим с использованием SSL для пересылки номера карточки продавцу, и не может рассматриваться как удовлетворительный. В рамках протокола используются следующие значения символов-префиксов участников сделки:
Рассмотрим диаграмму конечных состояний протокола SET (см. рис. 4.6.2.4).
Рис. 4.6.2.4. Диаграмма реализации протокола SET Начальным состоянием покупателя является shopping. Когда решение о покупке принято, программой клиента посылается запрос PReq и система переходит в состояние заказано. Запрос PReq включает в себя инструкцию OI (Order Instruction) и платежную инструкцию PI. Отклик PRes держателю карты может быть прислан немедленно или с некоторой задержкой. Полученная в отклике информация зависит от состояния протокольной машины (принят заказ, транзакция авторизована и т.д.). Продавец посылает запрос авторизации платежному серверу, но флаг CaptureNow не устанавливается равным "истинно", так как запрос оплаты (capture request) будет обработан позже. В состоянии авторизовано допускается частичный пересмотр условий сделки, при этом система может вернуться в состояние заказано или остаться в состоянии авторизовано. Продавец теперь имеет платежное обязательство от эмитента карты, но он должен обработать запрос покупки, для того чтобы получить соответствующую оплату. Запрос CapReq переводит транзакцию в состояние приобретено (Captured - сделка оплачена) и заказ обрабатывается. Если поступит запрос отмены сделки, система возвращается в состояние авторизовано. Далее владелец карты может запросить кредит. В этом случае обрабатывается запрос кредита, переводя транзакцию из состояния покупка осуществлена (sale processed) в состояние кредит выдан (credit issued). Запрос покупки (Sale Request) используется, когда продавец знает, что заказанный товар на складе и может быть поставлен немедленно при наличии авторизации. Этот запрос используется также в случае заказа товара или услуг, доставляемых через Интернет. Когда расчетный центр (Payment Gateway) обрабатывает запрос, происходит переход транзакции в состояние покупка осуществлена. С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен. Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes). Когда продавец не может выполнить заказ в полном объеме сразу, он поставляет имеющиеся в наличии товары, а нехватающие заказывает дополнительно. Продавец может предложить клиенту различные схемы оплаты, например, осуществить оплату заказа в несколько этапов, или в случае предоставления Интернет услуг оплата может происходить на регулярной основе раз в месяц без участия самого держателя кредитной карты. Протокол SET позволяет расчетному центру (Payment Gateway) определять, будет ли продавец получать номер счета владельца карты. Если эмитент карты решает не выдавать эту информацию, продавцу должен быть предоставлен какой-то другой механизм для возвращения сдачи в рамках текущей транзакции. Для этих целей в рамках транзакции предусмотрено несколько полей:
Рассмотрим более подробно функции субъектов протокола SET.
Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует. Хэш описания заказа включается в запрос покупки (PReq). В SET под владельцем платежной карты подразумевается программа, работающая на рабочей станции клиента-покупателя. Эта программа обеспечивает доступ к серверам продавцов, если требуется, поддерживает диалог между покупателем и продавцом, и реализует платежный процесс. При этом посылается заказ, получается отклик на этот заказ, осуществляются, если требуется, дополнительные информационные запросы и получаются данные о ходе реализации транзакции. Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются. Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer - банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты). Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard). Сертификаты расчетного центра (РЦ) пересылаются банку продавца (получателю) и служат для обработки сообщений авторизации и платежей. Ключ шифрования расчетного центра, который получает владелец карты из сертификата РЦ, используется для защиты информации о счетах владельца карты. Сам банк продавца (получатель) должен иметь сертификаты для того, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от продавцов. Банк продавца получает свои сертификаты из платежной системы (brand). Эмитент карт должен владеть сертификатами, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от владельцев карт. Эмитент получает сертификаты также из платежной системы. Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений (ISO 8583). Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.
Каждая платежная система обеспечивает поддержку CRL в пределах зоны своей ответственности. Архитектура SET использует концепцию BrandCRLidentifier (BCI). BCI подписывается цифровым образом представителем платежной системы. Протокол SET предполагает использование пар общедоступный/секретный ключ платежными центрами и продавцами обязательным и рекомендательным для владельцев карточек. SET использует стандарты PKCS (Public Key Cryptography Standards). Разработчики программ и систем должны обращать особое внимание на способы хранения секретных ключей. Настоятельно рекомендуется применение аппаратных средств для генерации ключей и шифрования. В настоящее время такие модули предлагаются и для обычных рабочих станций. Особые меры безопасности должны быть приняты для центров сертификации, так как именно они выступают гарантами корректности и безопасности применения общедоступных ключей участников транзакций. Информация о счете владельца карты для продавца шифруется его общедоступным ключом. Доступ продавца к этой информации является опционным, (см. замечания выше). При выборе данной опции должны быть приняты меры для обеспечения конфиденциального хранения этих данных на сервере продавца. Как минимум эта информация должна храниться в зашифрованном виде и к ней должен быть ограниченный доступ. Так как сертификаты, CRL и BCP используются достаточно часто при обработке сообщений SET, должен быть создан безопасный кэш для их хранения. Так как объем транспортируемых протокольных структур весьма велик, для сокращения трафика используется механизм оттисков (thumbprints). Оттиск представляет собой хэш сертификата, CRL или BCI. Точнее это хэш SHA-1 одного из перечисленных объектов, снабженный цифровой подписью. Цифровой конверт сообщения (MessageWrapper). MessageWrapper является информационной структурой верхнего уровня (ASN.1/DER) протокола SET. Эта структура размещается в самом начале сообщения и часто не шифруется. Она определяет тип MessageWrapper, информационные поля цифрового конверта представлены в таблице 4.6.2.1. Таблица 4.6.2.1. Поля MessageWrapper
Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений. При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа. При описании протокола используется нотация представленная в таблице 4.6.2.2. Таблица 4.6.2.2. Нотация протокола SET
Таблица 4.6.2.3. Операторы, используемые протоколом SET
OAEP - Bellare-Rogaway Optimal Asymmetric Encryption Padding В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит. Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Если BL представляет конечную длину блока данных, тогда длина строки заполнителя состоит из 8 -(||BL||mod 8) октетов. Каждый из байтов заполнителя содержит код 8 -(||BL||mod 8). Когда длина заполнителя равна одному октету, код октета равен 01. При длине строки в два байта код строки заполнителя будет равна 0202, а при трех байтах - 030303. Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 - для DES. По этой причине алгоритм CDMF называется алгоритмом маскирования, а не шифрования. Транспортировка ключа CDMF осуществляется в рамках SET-сообщений также как и ключей DES. SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP. Общая схема процесса шифрования и дешифрования, представляемая с привлечением общепринятых персонажей Алисы (отправитель шифрованного сообщения) и Боба (получатель) представлена в таблице ниже.
В протоколе SET часто используются так называемые двойные подписи. Для того чтобы понять их назначение, рассмотрим следующий пример. Пусть Боб хочет послать Алисе предложение купить некоторый товар и авторизационные параметры своего счета в банке, чтобы она могла выполнить оплату товара в случае, если предложение ее устроило. Предположим также, что Боб не хочет, чтобы банк узнал условия предложения, а Алиса получила данные о его счете в банке. Кроме того, Боб хочет, чтобы денежный перевод производился лишь в случае принятия его предложения Алисой. Для решения такой задачи сообщения Алисе и распоряжение банку подвергаются процедуре двойной подписи. Для реализации двойной подписи формируются дайджесты обоих сообщений, после чего они объединяются. Вычисляется дайджест сообщения-результата, после чего этот дайджест шифруется секретным ключом отправителя (Боба). Подписант должен добавить дайджест другого сообщения, для того чтобы получатель мог проверить корректность двойной подписи. Получатель любого из указанных выше сообщений может проверить их аутентичность, путем вычисления дайджеста самого сообщения с последующим добавлением к нему дайджеста другого сообщения (присланного отправителем) и вычислением дайджеста результата. Если вычисленный таким образом дайджест совпадет с дешифрованной двойной подписью, получатель может быть уверен в аутентичности сообщения. При этом ни одна из сторон не может оспаривать корректность действий другой стороны (будет оплачено именно то предложение, которое было послано клиенту). Если Алиса принимает предложение Боба, она может послать сообщение в банк, указав свое согласие на оплату предложения Боба и включив в это сообщение дайджест предложения, вычисляет дайджест всего такого сообщения. Можно было бы включить само предложение, но, во-первых, в этом случае было бы раскрыто его содержимое, а во-вторых, предложение обычно во много раз больше по объему, чем дайджест. Получатель проверяет соответствие этого дайджеста дешифрованной двойной подписи, что позволяет ему судить об аутентичности сообщения. Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения. В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца). Важным принципом при анализе работы программ SET является идемпотентность - реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа "шторма запросов", оно может не реагировать на эти запросы. XID является статистически уникальным идентификатором платежной транзакции и позволяет идентифицировать все относящиеся к ней сообщения. Его длина составляет 20 байт. BrandID представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product. Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ. Cert-PE представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq. Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers. Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7.
Тип SignedData из PKCS #7 проиллюстрирован на рис. 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.
Рис. 4.6.2.5. SignedData Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest. Тип EnvelopedData из PKCS #7 проиллюстрирован на рис. 4.6.2.6.
Рис. 4.6.2.6. EnvelopedData В пределах EnvelopedData допускается наличие нескольких EnvelopedData и только одно RecepientInfo. Тип EncryptedData из PKCS #7 проиллюстрирован на рис. 4.6.2.7.
Рис. 4.6.2.7. EncryptedData Тип DigestedData из PKCS #7 проиллюстрирован на рис. 4.6.2.8.
Рис. 4.6.2.8. DigestedData Обработка сообщений Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице 4.6.2.4. Таблица 4.6.2.4. Отправление сообщения
Процедура обработки входящего сообщения рассмотрена в таблице 4.6.2.5. Таблица 4.6.2.5. Прием и обработка входного сообщения
Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:
На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 4.6.2.6. Таблица 4.6.2.6. Верификация сертификатов
4.6.2.1.1. Оттиски (Thumbprints) Оттиски определяются путем вычисления хэш функции SHA-1, следуя кодировке DER ASN.1 структур:
Оттиск является тем же самым хэшем, который используется для подписи, верификации, CRL или BCI. Оттиски посылаются в сообщениях-запросах SET и могут игнорироваться получателем. Отправитель не обязан посылать все оттиски для всех сертификатов, CRL и BCI, имеющимся в его кэше, а только те, которые имеют отношение к конкретной паре сообщений запрос/отклик. Например, программа продавца не обязана посылать оттиски для всех держателей карт или всем платежным системам. Процедура отправки оттиска представлена в таблице 4.6.2.7. Таблица 4.6.2.7. Посылка оттиска
Получатель проверяет то, что отправитель владеет всеми сертификатами, CRL и BCI, необходимыми для завершения обработки сообщения. Получатель может проигнорировать оттиски и послать эту информацию запросившему. Обработка оттисков получателем представлена в таблице 4.6.23.8. Таблица 4.6.2.8. Обработка оттисков получателем
Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.
Другие варианты инкапсуляции осуществляются сходным образом. Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования - RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9. Таблица 4.6.2.9. Процедура асимметричного шифрования
Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t. Он предполагает быстрое симметричное шифрование открытого текста сообщения и последующее шифрование секретного ключа с использование общедоступного ключа получателя. Процедура такого шифрования представлена в таблице 4.6.2.10. Таблица 4.6.2.10. Асимметричное шифрование с гарантией целостности
Оператор симметричного шифрования EK(k,t) шифрует открытый текст группы t с привлечением ключа k. Для целей шифрования здесь могут использоваться алгоритмы DES или CDMF. Процедура симметричного шифрования представлена в таблице 4.6.2.11. Таблица 4.6.2.11. Процедура симметричного шифрования
Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s. Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования. Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента > content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo. Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7. В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста. Процедура цифровой подписи представлена в таблице 4.6.2.12. Таблица 4.6.2.12. Процедура формирования цифровой подписи
Оператор ключевого хэширования HMAC(t,k) соответствует 160-битовому хэшу HMAC-SHA-1 для группы t при использовании секретного ключа k. Эта функция нужна для сокрытия номера счета в сертификате владельца карты. Секретный ключ известен только владельцу карты и эмитенту. Процедура ключевого хэширования представлена в таблице 4.6.2.13. Таблица 4.6.2.13. Процедура ключевого хэширования
Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t. Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP. Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора. Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14. Таблица 4.6.2.14. Процедура вычисления дайджеста сообщения.
Оператор связи L(t1,t2) соответствует последовательности t1 и DigestedData. Компонент связи DigestedData содержит дайджест сообщения для группы t2 и может быть представлен посредством DD(t2). Оператор связи не является симметричным и не может связать t2 с t1. Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7. Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными. Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15. Таблица 4.6.2.15. Описание алгоритма OAEP
Алгоритм работа OAEP показан на рисунке 4.6.2.9. В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.
Рис. 4.6.2.9. Диаграмма работы OAEP Обработка ошибок Каждому сообщению-запросу должно соответствовать сообщение-отклик. Сообщения об ошибках могут соответствовать как запросам, так и откликам. Сообщение об ошибке указывает, что приславший его не смог разобрать формат полученного запроса или отклика, или при обработке потерпели неудачу верификационные тесты. Не следует путать отрицательный отклик с сообщением об ошибке. Сообщение об ошибке посылается при невозможности обработать входное сообщение. Сообщение Error не посылается, например, при непрохождении аутентификации. Причиной сигнала ошибки может быть искажение пакета при транспортировке по локальной сети или через Интернет, нелегальные значения полей сообщения или протокольные искажения. Для выявления сообщений-дубликатов достаточно использовать открытый текст, содержащийся в цифровом конверте сообщения. Реакция получателя на сообщение-дубликат зависит от свойств идемпотентности конкретного типа сообщения, от числа дубликатов, частоты их поступления и от того, кто является их отправителем. Поврежденным сообщением считается такое, которое не может быть обработано. В норме такие сообщения не должны приходить, так как имеется контроль корректности пакетов на транспортном уровне и при обнаружении любых повреждений сообщение должно быть переслано повторно. Но если такое "невозможное событие" все-таки произойдет, будет послано сообщение Error, содержащие код типа ошибки и идентификатор сообщения, ее вызвавшего. Приложение никогда не посылает сообщение Error в ответ на другое сообщение Error . Сообщения, которые не являются протокольными для SET, просто игнорируются. Если тэг типа сообщения равен 999 (указывая, что это сообщение об ошибке), приложение SET не должно ни при каких обстоятельствах посылать на него отклик. Когда приложение сталкивается с ошибкой, оно формирует Error-сообщение в следующей последовательности.
Для сообщения Error определены следующие поля
Таблица 4.6.2.16. ErrorCode
Так как сообщения Error могут посылаться, в том числе и в ответ на отклик, возникает проблема при работе с протоколами, базирующимися на алгоритмах запрос-отклик (например, HTTP). В этом случае сообщение об ошибке может посылаться в качестве запроса, на который необязательна посылка отклика. На нижележащем протокольном уровне при этом может происходить таймаут. Работа с сертификатами В работе с сертификатами участвуют девять субъектов. Иерархия этих субъектов представлена на рис. 4.6.2.10. Верхнюю позицию в иерархии занимает корневой центр сертификации. Корневой сертификат следует требованиям документа X.509 (версия 3) с некоторыми расширениями, вводимыми протоколом SET. Прежде чем система будет развернута, должны быть проделаны следующие операции:
С1 рассылается при развертывании системы и является самоподписываемым. Корневой сертификат SET доставляется приложению с помощью протокола запроса сертификата и платежного протокола. Начальное значение корневого сертификата, его общедоступный ключ или хэш общедоступного ключа могут быть доставлены и программой приложения SET. Как только приложением получен новый корневой сертификат, оно проверяет через расширение HashedRootKey связь с предыдущим корневым сертификатом. Когда приходит время заменить корневой сертификат R1, производятся следующие операции:
Новый корневой сертификат рассылается с использованием SET-сообщений или методик HTTP, FTP или SMTP. Приложение SET проверяет подпись, используя R2, вычисляет хэш R2 и сравнивает его с H2, полученным из расширения в С1.
Рис. 4.6.2.10. Иерархия субъектов сертификации Из списка этих субъектов один является опционным, это GCA (Геополитический центр сертификации - Geo-Political Certificate Authority). Проверка сертификатов производится строго в соответствии с данной иерархической схемой. Доступ к корневому центру сертификации производится крайне редко, только в случае получения нового сертификата платежной системы или при обновлении корневого сертификата. При взаимодействии с ним привлекается в максимально возможной мере аппаратный контроль. Если произойдет раскрытие секретного ключа платежной системы, то RCA сформирует и разошлет новый список отмененных сертификатов CRL (Certificate Revocation List). BCA являются независимыми для каждой платежной системы и реализуются практически теми же мерами безопасности, как и RCA. Эти центры служат для формирования и рассылки геополитических и/или сертификатов владельцев карты, продавцов или платежных центров, размещенных ниже по иерархии. Они также ответственны за обновление и рассылку списков CRL и BCI, содержащие все CRL платежной системы. Геополитические центры сертификации (являются опционными) позволяют платежным системам перераспределять ответственность между отдельными географическими и политическими регионами. Эти центры ответственны за формирование и рассылку соответствующих региональных CRL. Центры сертификации владельцев карт (ССА) формируют по запросу и отсылают сертификаты владельцам платежных карт. Запрос сертификата может быть послан через WEB или по электронной почте. ССА поддерживают взаимоотношения с эмитентами карт для сертификации счетов владельцев карт. ССА также занимаются рассылкой CRL, сформированных RCA, BCA, GCA и центров сертификации платежных центров. Функции CCA может выполнять центр платежной системы, эмитента карты или какой-то иной субъект, который отвечает требованиям конкретной платежной системы. Центр МСА ответственен за рассылку сертификатов продавцам. Получатели (Acquirers) проверяют и одобряют запросы сертификатов продавца до их выдачи центром MCA. Центр PCA служит для выдачи сертификатов для платежных центров. Их функции, также как и в случае CCA, могут выполняться центрами платежной системы, получателя и т.д. Любой центр сертификации выполняет следующие функции:
Формирование сертификатов осуществляется различными методами, зависящими от типа объекта. Для владельцев карты формируются только сертификаты подписи, для продавцов и платежных центров формируются сертификаты подписи и шифрования. Сертификаты для владельцев карт формируются центрами CCA. Выпуск сертификата держателя карты включает в себя следующие обмены между держателем карты и CCA (см. также рис. 4.6.2.2).
Для продавцов сертификаты формируются в центрах MCA. Перед выпуском сертификата продавца запрос верифицируется банком продавца (получатель - acquirer) или центром управления платежной системы. Сертификат получается продавцом в результате последовательности следующих операций.
Сертификаты платежного центра формируются и присылаются центром PCA. Процедура генерации сертификата сходна с вариантом продавца. Банк продавца верифицирует запрос сертификата платежного центра и авторизует генерацию сертификата в РСА. Сертификаты центров сертификации формируются вышестоящими по иерархии узлами. Обновление любых сертификатов производится периодически и следует тем же алгоритмам, что и формирование совершенно нового сертификата. Регистрационная форма при обновлении сертификата может содержать существенно меньше информации. Аннулирование сертификата может производиться по разным причинам, например, из-за реального или кажущегося раскрытия секретного ключа, из-за изменения регистрационной информации или по причине истечения срока пригодности. При аннулировании идентификатор и некоторые другие характеристики сертификата заносятся немедленно в список CRL. Последний сразу подлежит рассылке всем субъектам, которые могут использовать этот сертификат. При выполнении любой операции в рамках протокола SET производится проверка всех сертификатов, образующих иерархическую цепочку (см. рис. 4.6.2.11), начиная от конечного объекта (ЕЕ) до корневого (Root). Стрелки означают, чей сертификат использовался для подписи. Таким образом, каждый сертификат связан с сертификатом подписи субъекта его сформировавшего.
Рис. 4.6.2.11. Иерархия проверок Основной протокол Далее рассматривается протокол и обработка откликов владельца карты, продавца или платежного центра (конечный объект - EE), а также получение подписей и/или сертификатов Х.509 шифрования данных от СА (Certificate Authority). Протокол определяет процедуры получения первого сертификата или обновления предшествующего. Прежде чем запросить сертификат владелец карты должен выполнить следующее:
Продавец должен иметь следующее, прежде чем посылать запрос сертификата:
Расчетный центр должен обзавестись следующим, прежде чем посылать запрос сертификата:
После того как приложение запущено, стартуют сертификационные обмены между владельцем карты и CCA, между продавцом и MCA, а также между платежным центром и PCA. В результате участники получают необходимые сертификаты подписи и шифрования. Так взаимодействие владельца карты и ССА предполагает следующие обмены:
Функционирование приложения продавца и платежного центра имеет свою специфику:
Схемы таких обменов для получения нового или обновления старого сертификатов представлены на рис. 4.6.2.12 и 4.6.2.13. Логика обменов для получения сертификата владельцем карты при начальной регистрации была показана на рис 4.6.2.12.
Рис. 4.6.2.12. Схема обмена сообщениями при получении сертификата между владельцем карты и ССА Если ЕЕ уже имеет регистрационную информацию, обмены CardCInitReq/Res и RegFormReq/Res могут быть опущены. При работе через WWW используется во всех случаях полный перечень обменов. После того как приложение SET инициализировано, владелец карты посылает ССА сообщение CardCInitReq, указывающее через оттиски на сертификаты, CRL и BrandCRLIdentifier, которые содержаться в его кэше сертификатов. ССА реагирует посылкой сообщения CardCInitRes, содержащего любые сертификаты, CRL и BrandCRLIdentifier, которые потребуются владельцу карты для верификации подписи, а также сертификат шифрования, используемый для последующих сообщений. Приложение SET формирует сообщение CardCInitReq следующим образом.
Структура сообщения CardCInitReq охарактеризована в таблице 4.6.2.17. Таблица 4.6.2.17. Структура сообщения CardCInitReq
ССА, получив CardCInitReq, выполнит следующие операции:
После того как ССА обработает CardCInitReq, он выполнит следующие шаги, для того чтобы сформировать CardCInitRes. Как и в случае SignedData, сертификаты и CRL, нужные для верификации подписи, включаются в CardCInitRes вне данных, которые должны быть подписаны. Последовательность действий представлена ниже в таблице.
Формат отклика CardCInitRes представлен в таблице ниже.
Приложение владельца карты обрабатывает сообщение CardCInitRes в следующей последовательности:
Если приложение владельца карты успешно обработало отклик CardCInitRes, оно может сформировать и послать сообщение RegFormReq. Это сообщение шифруется приложением владельца карты с использованием сертификата, полученного от ССА в CardCInitRes. Последовательность формирования и посылки RegFormReq представлена ниже в таблице.
Структура сообщения RegFormReq представлена в таблице 4.6.2.18. Таблица 4.6.2.18. Структура RegFormReq
Поля данных PANOnly
Таблица 4.6.2.19. Значения кодов RequestType
* указывает на значения, зарезервированные для будущего использования Когда центр ССА получает ReqFormReq, он выполняет следующие шаги для проверки корректности сообщения.
После верификации RegFormReq CCA генерирует RegFormRes следующим образом. Если верификация запроса прошла успешно, присылается регистрационная форма, уведомление о политике, URL платежной системы и логотип карты. В случае неудачи сообщается причина и опционно URL и адрес e-mail, откуда может быть получена более детальная информация. Процедура формирования RegFormRes описана ниже.
Структура сообщения RegFormRes представлена в таблице 4.6.2.20. Таблица 4.6.2.20. Структура RegFormRes
Таблица 4.6.2.21. Структура поля RegFormOrReferral
Приложение владельца карты обрабатывает сообщение RegFormRes следующим образом:
Пары сообщений Me-AqCInitReq/Res используются продавцом или расчетным центром для получения регистрационной формы сертификата. Продавец или расчетный центр запускают сертификатный протокол путем посылки запроса Me-AqCInitReq. Это сообщение содержит банковскую информацию продавца или расчетного центра, тип запрашиваемого сертификата, а также сертификаты, CRL и BrandCRLIdentifier, которые хранятся в надежном сертификатном кэше. Если MCА или РСА имеют регистрационные формы на подходящем языке для указанного банка, она присылается в сообщении Me-AqCInitRes вместе с любыми сертификатами, CRL и BrandCRLIdentifier, которые могут потребоваться продавцу или расчетному центру для проверки цифровой подписи. Если MCА или РСА не имеют подходящей регистрационной формы и/или имеют дополнительную информацию относительно отклонения поступившего запроса, эти данные также заносятся в Me-AqCInitRes. Схема работы протокола сертификатов для данного случая показана на рис. 4.6.2.13.
Рис. 4.6.2.13. Схема обмена сообщениями при получении сертификата между продавцом и MCA или между платежным центром и PCA При получении Me-AqCInitRes программа конечного пользователя (ЕЕ) может послать сообщение CertReq, содержащее заполненную форму. Процедура формирования Me-AqCInitReq включает в себя следующие операции:
Формат сообщения Me-AqCInitReq представлен в таблице 4.6.2.22. Таблица 4.6.2.22. Формат Me-AqCInitReq
Формат поля IDData описан в таблице 4.6.2.23. Таблица 4.6.2.23. Формат IDData
Таблица 4.6.2.24. Значения RequestType для продавца и платежного центра
Получив Me-AqCInitReq, СА производит его обработку следующим образом:
Проверив корректность Me-AqCInitReq, CA формирует Me-AqCInitRes. Эта операция включает в себя следующие шаги:
MCA и PCA используют один и тот же шаблон регистрационной формы, идентичный ССА (см. табл. 4.6.2.25) Таблица 4.6.2.25. Шаблон регистрационной формы MCA и PCA
Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes следующим образом:
Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq. Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме. Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме. Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме. Запрос сертификата (CertReq) содержит в себе:
Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа. Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq. ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, AcctInfo всегда содержит аутентификационные данные, которые могут быть, а могут и не быть затребованы СА. Me-AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField. EncX используется лишь при наличии AcctInfo. Если ЕЕ является владельцем карты, продавцом или расчетным центром и намерен послать AcctInfo, то CertReq формируется с привлечением методики EncX следующим образом.
Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:
Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26: Таблица 4.6.2.26. Формат CertReq
Таблица 4.6.2.27. Формат PANData0
Таблица 4.6.2.28. Формат AcctData
СА проверяет CertReq (EncX) следующим образом.
Если верификация не прошла, СА подготавливает и отсылает сообщение CertRes c соответствующим статусом. Если обнаружены ошибки в CertReq, СА отметит эти ошибки в CertRes и приложение ЕЕ должно будет послать повторно CertReq. При полном успехе система перейдет к аутентификации в финансовом учреждении. Здесь, прежде чем формировать сертификат, проверяется запрос CertReq. Методика этой проверки зависит от типа платежной системы (Brand) и находится за пределами спецификации SET. В зависимости от результатов проверки CertReq, CertRes будет содержать сертификат или статусный код (при неуспехе). Сообщение CertRes будет подписано и в зависимости от характера данных, уложенных в него, зашифровано. Если CertRes уведомляет владельца карты об успехе, то сообщение шифруется с использованием обычного симметричного алгоритма, поддерживаемого приложениями СА и владельца карты. Если сообщение CertRes предназначено для продавца или расчетного центра или возвращает владельцу карты статусные данные, то оно подписывается, но не шифруется. Если CertReq аутентичен и корректен, а СА сформировал сертификат, используя представленный ключ, то будет возвращен CertRes с завершенным статусом. Если CertRes предназначен для владельца карты и содержит ключ (в CaBackKeyData) для шифрования CertRes, СA сформирует CertRes как SignedData. Осуществляется это следующим образом.
Если СА возвращает статус в CertRes, в него для передачи данных продавцу, владельцу карты или расчетному центру включается сообщение EEMessage. Подписанное сообщение CertRes формируется следующим образом:
Формат CertRes в этом случае имеет вид представленный в таблице 4.6.2.29. Таблица 4.6.2.29. Формат CertRes
Таблица 4.6.2.30. Статусные коды для запросов сертификата
Конечный пользователь ЕЕ проверяет новый сертификат следующим образом:
Информационные сертификатные запросы и обработка статуса Если сертификат не возвращен немедленно в CertRes, EE может попросить прислать ему информацию о состоянии его запроса путем присылки CertReq в центр СА. Запрос CertInqRes возвращает сертификат, если он готов, или предоставляет информацию о том, когда сертификат будет прислан. Такие запросы могут посылать владелец карты, продавец или расчетный центр. Адресуются эти запросы CA, CCA, MCA или PCA (источникам сертификатов). Если CertStatusCode из CertRes равен "Certificate Request in Progress" или "Certificate Request Pending". EE формирует CertInqReq для получения сертификата следующим образом:
Формат сообщения представлен в таблице ниже. Таблица 4.6.2.31. Формат CertInqReq
Центр СА обрабатывает CertInqReq следующим образом:
После обработки CertInqReq СА формирует CertInqRes. Этот отклик имеет ту же структуру и формат, что и CertRes. Обработка CertInqRes происходит аналогично. Реальный формат сертификатов определяется документом Х.509. Характеристики различных полей такого сертификата представлены в таблице 4.6.2.32. Таблица 4.6.2.32. Поля формата сертификата Х.509
Для определения позиций необходимы следующие идентификаторы объектов OID (указаны в скобках) в сертификатах SET:
Ниже представлены формальные определения атрибутов (at), которые заключают в себе уникальные имена (Subject Distinguished Name) для каждого объекта SET, указанного в расширении типа сертификата (CertificateType). OID имен (ASN.1) id-at-countryNameOBJECT IDENTIFIER ::= { id-at 6 } Владелец карты Продавец commonName=<Опционный уникальный идентификатор>
Уникальный ID владельца карты в сертификате представляет собой хэшированный номер его счета. PAN маскируется с использованием общего секретного ключа (PANSecret), который состоит из комбинации CardSecret владельца карты и Nonce-CCA сертификационного центра. Вычисление хэша производится с привлечением алгоритма HMAC-SHA1 (RFC-2105). Функция HMAC-SHA1 определяется в терминах ключа K и текста, который кэшируется следующим образом: Hash(KÅ opad|hash((KÅipad)|text)), где Å - оператор исключающее ИЛИ, а оператор | - обозначает объединение кодов. K, text, ipad и opad определяются в SET следующим образом:
K дополняется нулями до 64 байт. Результат вычисления HMAC кодируется в представлении base64, после чего производится в поле сертификата commonName. Профайлы сертификатов В таблице 4.6.2.33 представлен полный список сертификатов необходимых SET. Таблица 4.6.2.33. Типы сертификатов
ССА, MCA и PCA при совмещении функций не обязательно требуют наличия трех отдельных сертификатов. Сертификат подписи может содержать два или три различных типов сертификата. Разные СА не обязательно требуют различных сертификатов для подписи сертификатов и CRL. Поле KeyUsage может содержать:
В таблице 4.6.2.34 представлены обязательные расширения сертификата конечного пользователя (ЕЕ). Таблица 4.6.2.34. Обязательные расширения сертификата ЕЕ.
Х - обязательный Таблица 4.6.2.35. Обязательные расширения сертификатов СА
Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию:
В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509). Таблица 4.6.2.36. Формат полей CRL и ограничения для их значений
Следующие СA должны поддерживать CRL в рамках SET:
Расширение CRLNumber содержит одно целое число. Центр СА, подписывающий CRL, должен инкрементировать это число каждый раз при выпуске нового CRL. При получении нового CRL должны проводиться следующие проверки: 1. Сначала проверяется подпись:
3. IssuerDN и устаревший certSerialNumber сравниваются с проверяемым сертификатом Следующие проверки производятся для того, чтобы выяснить, не входит ли данный сертификат в список CRL:
Существующие CRL от одного и того же IssuerDN могут быть удалены, когда успешно прошел проверку CRL с более высоким значением CRLNumber. BrandCRLIdentifier BrandCRLIdentifier (BCI) представляет собой структуру, определенную SET и используемую для идентификации всех рабочих CRL заданной области ответственности сертификационного центра платежной системы. BrandCRLIdentifier содержит в себе следующую информацию:
Подпись BCI производится с привлечением секретного ключа, соответствующего сертификату CRLSign. BCI пересылаются владельцам карт и продавцам в виде сообщений-откликов. Запросы и отклики сертификатов Запрос сертификата посылается клиентом вышестоящему центру сертификации (СА). Последний формирует сертификат и отсылает его отправителю запроса в подписанном сообщении отклике. Различные объекты ответственны за подпись разных сертификатов, как это показано ниже.
Сообщения запросы от СA форматируются согласно CertificationRequest, специфицированному в PKCS#4 версии 1.0. CertificationRequest содержит общедоступный ключ, DN субъекта и атрибуты, которые должен сертифицировать подписывающий СА. Сообщение-запрос сертификата включает в себя информацию, которая должна присутствовать в расширениях сертификата. Эта информация содержится в атрибутах запроса PKCS#10. В таблице 4.6.2.37 показаны атрибуты, которые необходимы или опционны в CertificationRequest. Таблица 4.6.2.37. Атрибуты CertificationRequest
Х - обязательный При получении CertificationRequest СА должен проверить запрос и сформировать отклик в соответствии со следующей процедурой:
Рассылка CRL CRL представляет собой механизм, определенный Х.509, и предназначенный для публикации и рассылки списков выведенных из употребления сертификатов, срок действия которых еще не истек. Когда корневой СА актуализует свой CRL, он посылает его каждому центру сертификации платежной системы. Когда нижерасположенный центр сертификации актуализует свой CRL, он рассылает его своим СА платежных систем. CRL рассылаются в секции SignedData сообщений CRLNotification согласно следующему алгоритму.
CRL-Notification-сообщение содержит следующие поля:
При получении сообщения CRL Notification СА платежной системы проверяет и анализирует его следующим образом:
CA платежной системы формирует отклик CRL Notification согласно следующему алгоритму:
Сообщение-отклик CRLNotification содержит следующие поля.
При получении отклика CRLNotification СА проверяет то, что дата и оттиск соответствуют значениям из запроса. Если соответствия нет, посылается сообщение об ошибке, а запрос CRLNotification посылается повторно. Получение BCI BrandCRLIdentifier (BCI) является списком текущих CRL, соответствующим всем СА из зоны ответственности платежной системы (Brand). Центр сертификации платежной системы отвечает за поддержку, корректность и актуальность BCI. Каждый CA из зоны ответственности платежной системы отвечает за обновление и осуществление доступа к BCI и соответствующим спискам CRL. Эту информацию они выдают в виде откликов на запросы ЕЕ или нижестоящих СА. Центр сертификации каждой платежной системы формирует и поддерживает свой BCI и реализует механизм для рассылки этой информации. СА, например, расчетного центра должен организовать ежедневное обновление этих данных. Центр сертификации платежной системы рассылает информацию о новых CRL в виде сообщений BCI Distribution. Это сообщение является подписанным, содержащим текущую дату, BCI, соответствующие сертификаты и CRL. Сообщение BCI Distribution не формируется ежедневно, а лишь по мере необходимости. Алгоритм формирования этого сообщения представлен ниже.
Сообщение BCI Distribution содержит в себе следующие поля:
Обработка пришедшего сообщения BCIDistribution соответствующим СА производится согласно алгоритму, приведенному ниже:
Структуры данных Сообщения SET включают в себя несколько структур данных, которые содержат информационные элементы, переносимые из одного сообщения в другое. Информационные поля сообщения с протокольной точки зрения непрозрачны. TransID TransID предоставляет всю информацию для уникально определенной транзакции и характеристики транзакции, частью которой является данное сообщение. В частности TransID позволяет участнику процесса связать каждое сообщение с определенной транзакцией. Структура данных в TransID представлена ниже в таблице.
TransID предоставляет несколько идентификаторов для транзакций. LID-C, LID-M и PaySysID являются идентификаторами, которые присваиваются владельцем карты, продавцом и/или платежной системой. LID-M часто используется для хранения номера заказа продавца для данной транзакции. PreqData предоставляет дату запуска транзакции. XID представляет собой идентификатор транзакции, который обычно формируется системой продавца, если только нет PInitRes, в последнем случае он формируется системой владельца карты. XID представляет собой псевдослучайный 20 байтовый код, который должен быть уникальным. В таблице 4.6.2.38 рассмотрено, когда формируется и используется поле TransID в сообщениях SET. Таблица 4.6.2.38. Условия формирования и использование поля TransID
Примечания:
Алгоритм формирования TransID представлен ниже:
Обработка TransID зависит от типа сообщения. Платежная инструкция Платежная инструкция (PI) является одной из важнейших информационных структур SET. Она используется для передачи информации, необходимой для авторизации операции платежа владельца карты расчетному центру. Данная операция служит для инициализации транзакции с привлечением традиционной платежной карты. Данные шифруются владельцем карты и посылаются через продавца получателю (банку продавца - Acquirer). Эта информация не может быть прочитана продавцом. Имеется три разновидности PI. Первые два формируются владельцем карты, третье - расчетным центром.
Платежная инструкция имеет структуру представленную в таблице 4.6.2.39. Таблица 4.6.2.39. Структура PI
Таблица 4.6.2.40. Структура PIHead
Прикладные данные в этом сообщении состоят из PIData, от которых PANData отличается более сильной криптографической обработкой. PANData - это информация платежной карты. PIData включает в себя все прочие данные о покупке, идентификацию транзакции и переменные криптографической поддержки. Таблица 4.6.2.41. Структура InstallRecurData
Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту. AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken. Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42. Таблица 4.6.2.42. Структура AuthToken
AuthToken формируется следующим образом:
Обработка AuthToken выполняется в следующем порядке:
AcqCardMsg является полем, которое предоставляет механизм для посылки банком продавца сообщения владельцу карты, не информируя об этом продавца (туннелирование). Это поле может быть использовано после того, как расчетный центр получит сообщение AuthReq от продавца. Структура данных AcqCardMsg представлена в таблице 4.6.2.43. Таблица 4.6.2.43. Структура AcqCardMsg
Для AcqCardCode определены следующие значения:
CapToken предоставляет данные, необходимые расчетному центру для платежной транзакции на фазе авторизации. Структура данных CapToken представлена в таблице 4.6.2.44. Таблица 4.6.2.44. Структура CapToken
Алгоритм формирования CapToken показан ниже:
Обработка CapToken производится следующим образом:
PANData содержит информацию, идентифицирующую определенный счет платежной карты. Структура данных PANData представлена в таблице 4.6.2.45. Таблица 4.6.2.45. Структура PANData
Формирование PANData осуществляется согласно алгоритму, рассмотренному ниже.
PANToken подобно PANData содержит информацию, идентифицирующую определенную платежную карту. PANToken используется, когда для сокрытия данных PANSecret не нужен. Структура PANToken показана в таблице 4.6.2.46. Таблица 4.6.2.46. Структура PANToken
Формирование PANToken осуществляется достаточно просто:
Структура SaleDetail SaleDetail соединяет в себе данные, относящиеся к текущей транзакции. Эта структура формируется как часть установления процесса между продавцом и расчетным центром. Для AuthReq, CredReq и CapReq формирование продавцом SaleDetail является опционным. Структура данных в SaleDetail показана в таблице 4.6.2.47. Таблица 4.6.2.47. Структура SaleDetail
PayRecurInd может принимать следующие значения:
Структура коммерческих данных карты представлена в таблице 4.6.2.48. Таблица 4.6.2.48. Структура коммерческих данных карты
Структура данных MarketAutoCap представлена в таблице 4.6.2.49. Таблица 4.6.2.49. Структура MarketAutoCap
Структура данных MarketHotelCap представлена в таблице 4.6.2.50. Таблица 4.6.2.50. Структура MarketHotelCap
Структура данных MarketTransportCap представлена в таблице 4.6.2.51. Таблица 4.6.2.51. Структура MarketTransportCap
Структура данных, указывающих место (Location), представлена в таблице ниже.
Структура данных RRTags представлена в таблице 4.6.2.52. Таблица 4.6.2.52. Структура RRTags
Формирование RRTags производится следующим образом
Целью BatchStatus является предоставление данных о состоянии платежной линии между расчетным центром и продавцом или для согласования объемов платежей продавца в расчетный центр. Структура данных BatchStatus представлена в таблице 4.6.2.53. Таблица 4.6.2.53. Структура BatchStatus
Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54. Таблица 4.6.2.54. Структура TransactionDetail
Суммы в платежных сообщениях SET характеризуются тремя полями: валюта, сумма и amtExp10. Эти поля содержат ASCII-строки, формат которых охарактеризован в таблице ниже.
Для того чтобы представить сумму US $2.87 в поле PurchAmt, в поля currency, amount и amtExp10 заносятся коды 840, 250 и -2. Поля Date Даты в SET обычно указываются в форме строк, характеризующих календарную дату и время UTC в формате: YYYYMMDDHHMM[SS[.f]f]f]]]Z где Z литерал буквы Z в верхнем регистре. Таким образом, строка должна состоять из четырех цифр, характеризующих год, по две цифры, определяющие месяц, день, час (24-часовое представление) и минуту. После минут опционно могут присутствовать две цифры секунд. Если поле секунд присутствует, далее могут опционно быть прописаны доли секунды. Запись может иметь, например, форму: 20011003102853.33Z, что означает 2001 год, 03 октября, 10 часов 28 минут 53,33 секунды. Полночь отмечается датой, следующего дня. Поток платежных сообщений Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система. Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes. На рис. 4.6.2.14 показан типичный пример обмена сообщениями при реализации протокола покупки.
Рис. 4.6.2.14. Диаграмма обмена для протокола покупки На рис. 4.6.2.15 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.
Рис. 4.6.2.15. Опции обмена сообщениями при покупке
Рис. 4.6.2.15а. (продолжение) Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке. Обработка запросов/откликов инициализации платежа Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос PInitReq посылает владелец карты, отклик PInitRes ему присылает продавец. Задачей этого обмена является получение владельцем карты сертификатов и CRL. Без такого обмена данная информация может быть получена и каким-то другим образом, например с CD-ROM. Эти сообщения посылаются после инициализации процесса SET. Сообщение-запрос PInitReq идентифицирует платежную систему карты (Brand), предоставляет локальный идентификатор владельца карты для данной транзакции, посылает переменную вызова для определения пригодности (свежести) сообщения-отклика. В этом сообщении передается также набор оттисков, который идентифицирует соответствующие сертификаты и CRL, уже имеющиеся у владельца карты, чтобы их не нужно было посылать еще раз. Сообщение-отклик PInitRes содержит запрошенные данные, включая сертификаты и CRL. Присылается продавцом также дата, XID и вызов владельца карты, добавляется, кроме того, и вызов продавца. Алгоритм формирования владельцем карты сообщения PInitReq приведен в таблице ниже.
Сообщение PInitReq, задавая естественный язык владельца карты, определяет ID и контекст транзакции, а также спецификацию платежной системы. Кроме того, предоставляются оттиски, где записаны сертификаты и криптографические вызовы, гарантирующие новизну отклика. Структура PInitReq представлена в таблице 4.6.2.55. Таблица 4.6.2.55. Структура PInitReq
Алгоритм обработки PInitReq продавцом представлен ниже.
Формирование продавцом отклика PInitRes осуществляется следующим образом.
Информационная структура PInitRes представлена ниже в таблице 4.6.2.56. Таблица 4.6.2.56. Структура PInitRes
При получении владельцем карты сообщения PInitRes он обрабатывает его следующим образом.
Запросы инициализации покупки (PInitReq) несут в себе достаточно информации о владельце карты для программы продавца, чтобы выбрать сертификат платежного центра. Следует иметь в виду, что эти запросы не шифруются и соответствующие расширения не должны нести в себе конфиденциальной информации. Отклик на запрос инициализации (PInitRes) содержит копии данных из запроса PInitReq, а также сертификаты продавца и расчетного центра. Отклик подписывается продавцом, что позволяет владельцу карты быть уверенным в том, что посланная им в запросе информация дошла до продавца неискаженной (за счет просмотра копий). Отклик PInitRes также не шифруется. Обработка заказа-покупки Обмен запрос-отклик (PReq/PRes) представляет собой реализацию покупки, выполняемой владельцем карты у продавца. Данные сообщения составляют ядро протокола купли-продажи. На долю владельца карты выпадает функция платежа. Реализация запроса покупки проходит через 5 этапов (см. рис. 4.6.2.16).
Рис. 4.6.2.16. Обработка запроса покупки Прежде чем послать запрос покупки покупатель (владелец карты) должен заполнить форму заказа, одобрить условия сделки и выбрать платежную карту. Для того чтобы послать запрос продавцу, владелец карты должен иметь копию ключей расчетного центра. Обработка заказа начинается, когда программа владельца карты запрашивает копию сертификата расчетного центра. В этом сообщении содержится информация о выборе платежной системы. Когда продавец получает запрос, он присваивает транзакции уникальный идентификатор. После этого продавец пересылает свой сертификат и сертификат расчетного центра вместе с этим идентификатором владельцу карты. Программа владельца карты верифицирует полученные сертификаты и запоминает их для использования в последующей обработке заказов. Приложение владельца карты формирует данные заказа OI (Order Information) и платежные инструкции PI. OI и PI снабжаются идентификатором транзакции, для того чтобы расчетный центр мог связать их вместе при авторизации запроса продавца. Заметим, что OI не содержит таких данных как описание товара или условий поставки. Эта информация получается на фазе сделки, предшествующей операциям SET (например, в рамках протокола IOTP). Программное обеспечение владельца карты генерирует двойную цифровую подпись для OI и PI путем вычисления дайджеста для обоих модулей данных, объединения этих дайджестов, вычисления дайджеста результата и осуществления подписи этого сообщения с привлечением секретного ключа владельца карты. Дайджесты OI и PI посылаются вместе с этим сообщением. Далее программа формирует симметричный ключ и использует его для шифрования дважды подписанных PI. Затем программа шифрует номер счета владельца карты и симметричный ключ с привлечением общедоступного ключа расчетного центра. Результат составляет цифровой конверт сообщения, которое передается продавцу. Когда программа продавца получает заказ, она верифицирует сертификат подписи владельца карты, используя общедоступный ключ владельца карты и дайджест PI (заключенный в OI), проверяет цифровую подпись, чтобы убедиться в не искаженности заказа и в том, что сообщение подписано секретным ключом владельца карты. Заметим, что продавцу не обязательно выполнять авторизацию до посылки отклика владельцу карты. Последний может позднее определить, была ли выполнена авторизация, послав информационный статусный запрос. После обработки OI продавец генерирует отклик и снабжает его цифровой подписью. Этот отклик содержит в себе сертификат подписи продавца и указывает на факт получения заказа от владельца карты. Если отклик авторизации указывает на одобрение транзакции, продавец поставляет товар или услугу, указанные в заказе. Когда приложение владельца карты получает отклик на запрос покупки от продавца, сначала верифицируется сертификат подписи. Далее проверяется цифровая подпись продавца. При благоприятном исходе этих проверок выдается соответствующее сообщение и производится запись в базу данных. Состояние выполнения заказа владелец карты может выяснить путем посылки информационных статусных запросов. Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes. Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись. PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами:
Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).
Когда расчетный центр готов шифровать данные для конечного пользователя (ЕЕ), его сертификат содержит список симметричных алгоритмов шифрования, которые он поддерживает, в порядке их предпочтения. Конечный пользователь, который хочет иметь шифрованные данные, выбирает первый алгоритм из списка, который он способен использовать. Ключ для этого алгоритма передается расчетному центру в сообщении PReq. Реализация PReqDualSigned рассмотрена ниже.
Сообщение запроса покупки PReq содержит инструкцию заказа OI для продавца и платежную инструкцию для передачи транзитом в зашифрованном виде через продавца в расчетный центр. Аутентичность и целостность сообщений достигается за счет использования двойной подписи, если владелец карты имеет сертификат (PReqDualSigned). Если владелец карты не имеет сертификата, для тех же целей применяются хэши в ОАЕР-конверте (PReqUnsigned). Структура данных в случае PreqDualSigned показана в таблице 4.6.2.57. Таблица 4.6.2.57. Структура PReqDualSigned
Структура данных в случае PReqUnsigned показана в таблице 4.6.2.58. Таблица 4.6.2.58. Структура PReqUnsigned
Структура данных сообщения PReq для PReqDualSigned и PreqUnsigned показана в таблице 4.6.2.59. Таблица 4.6.2.59. Структура PReq для PReqDualSigned и PreqUnsigned
При получении PReq продавец производит следующие действия.
После обработки PReq продавец формирует отклик PRes согласно следующему алгоритму:
Для каждой авторизации, которую провел продавец и которая не отменена, формируется PresPayload:
Формирование поля Results производится согласно следующему алгоритму:
Структура данных сообщения PRes, формируемого продавцом, представлена в таблице 4.6.2.60. Таблица 4.6.2.60. Структура PRes, формируемая продавцом
Структура данных PResPayload представлена в таблице 4.6.2.61 Таблица 4.6.2.61. Структура PResPayload
Коды завершения (completionCode) могут принимать следующие значения (см. табл. 4.6.2.62). Таблица 4.6.2.62. Коды завершения операции
Владелец карты обрабатывает полученный отклик PRes следующим образом.
Обработка информационных запросов Пара сообщений InqReq/InqRes позволяет владельцу карты получать информацию о состоянии транзакции. Информационный запрос может быть послан в любое время после запроса PReq, адресованного продавцу. Запросы InqReq могут посылаться многократно. Отклик InqRes имеет тот же формат, что и PRes. Продавец должен проверять, что сертификат, сопровождающий InqRes, соответствует сертификату, использованному с PRes. Это препятствует запросам одного владельца карты о состоянии транзакций других покупок. Владелец карты без сертификатов не подписывает информационные запросы, что означает возможность нарушения целостности сообщения. Владелец карты формирует запрос InqReq следующим образом.
Структура данных запроса InqReq представлена в таблице 4.6.2.63. Таблица 4.6.2.63. Структура InqReq
Когда продавец получает InqReq, он обрабатывает это сообщение следующим образом:
Авторизация платежей продавца осуществляется согласно схеме, показанной на рис. 4.6.2.17.
Рис. 4.6.2.17. Авторизация платежей Процесс авторизации проходит через три состояния. Во время обработки заказа от владельца карты продавец авторизует транзакцию. Программа продавца формирует и цифровым образом подписывает авторизационный запрос, который включает в себя сумму платежа, подлежащую авторизации, идентификатор транзакции из OI и некоторые другие данные. Запрос затем шифруется с использованием нового случайного симметричного ключа, который в свою очередь шифруется общедоступным ключом расчетного центра. Это тот самый ключ, который использовал владелец карты для шифрования цифрового конверта с платежными инструкциями. Запрос авторизации и платежные инструкции владельца карты передаются в расчетный центр. Когда расчетный центр получает авторизационный запрос, он дешифрует цифровой конверт запроса и извлекает из него симметричный ключ. Этот ключ используется для дешифрования текста запроса. Далее верифицируется сертификат подписи продавца срок его действия, а также цифровая подпись. После этого расчетный центр дешифрует цифровой конверт платежных инструкций (PI), откуда извлекается симметричный ключ и информация о счете клиента. Ключ используется для дешифрования PI. Используя общедоступный ключ владельца карты и дайджест OI (включенный в PI), проверяется цифровую подпись, чтобы убедиться, что PI не модифицированы и что они подписаны с использованием секретного ключа владельца карты. Расчетный центр проверяет, что идентификатор транзакции, полученный от продавца, соответствует идентификатору, присланному в PI. При успешном завершении этих проверок расчетный центр формирует и отсылает через финансовую сеть авторизационный запрос эмитенту карты. При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса. Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель). Отклик шифруется с помощью вновь сформированного секретного симметричного ключа, который в свою очередь шифруется общедоступным ключом продавца. После шифрования отклик посылается продавцу. Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись. Продавец запоминает авторизационный отклик и платежный маркер для последующего использования при обработке платежных запросов. Далее продавец может осуществлять доставку товаров или услуг, оговоренных в заказе. Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты. Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа. В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.
Процедура формирования AuthTags показана в таблице ниже.
Схема формирования поля данных AuthReq показана ниже.
Структура данных сообщения AuthReq представлена в таблице 4.6.2.64. Таблица 4.6.2.64. Структура AuthReq
Структура данных AuthReqPayload представлена в таблице 4.6.2.65. Таблица 4.6.2.65. Структура AuthReqPayload
Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.
Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.
Расчетный центр формирует AuthResPayload следующим образом.
Структура полей AuthRes представлена в таблице 4.6.2.66. Таблица 4.6.2.66. Структура полей AuthRes
Структура AuthResPayload представлена ниже в таблице 4.6.2.67. Таблица 4.6.2.67. Структура AuthResPayload
Список возможных значений кода AuthCode приведен ниже
Обработка продавцом отклика AuthRes производится следующим образом.
Алгоритм обработки AuthResPayload представлен ниже.
Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение. Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode. Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0). При этом код отклика не переписывается. Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode. Программа расчетного центра обрабатывает все последующие сообщения для транзакций, как если бы транзакция была одобрена, при условии посылки продавцом корректного кода ApprovalCode. Запрос авторизации несет в себе необходимую информацию от продавца к расчетному центру для формирования сообщения-запроса авторизации, которое может быть обработано банком продавца. Отклик на запрос авторизации несет в себе информацию от расчетного центра, относящуюся к обработке запроса авторизации. Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture). Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE. Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках. Запрос/отклик платежа (CapReq/CapRes) Пара сообщений CapReq/CapRes предоставляет механизм выполнения платежа. Обмен этими сообщениями происходит между продавцом и расчетным центром. Транзакция обработки платежных запросов проходит через три состояния (см. рис. 4.6.2.18).
Рис. 4.6.2.18. Обработка платежных запросов После завершения обработки заказа владельца карты продавец осуществляет запрос платежа. Между запросами авторизации и запросом платежа может быть достаточно большая задержка. Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов. Когда расчетный центр получает запрос платежа, он дешифрует цифровой конверт, извлекает из него симметричный ключ и дешифрует с его помощью текст платежного запроса. Далее посредством общедоступного ключа продавца верифицируется его цифровая подпись. Расчетный центр дешифрует платежный маркер (если таковой имеется) и использует платежный запрос и маркер для формирования клирингового запроса, который направляется эмитенту карты через платежную систему кредитной карты. После этого расчетный центр генерирует платежный отклик, снабженный цифровой подписью. Этот отклик содержит в себе копию сертификата подписи расчетного центра. Отклик шифруется с использованием нового симметричного ключа и переправляется продавцу. Когда продавец получает платежный отклик из расчетного центра (РЦ), он дешифрует цифровой конверт, извлекает из него симметричный ключ и с его помощью дешифрует полученный текст отклика. Далее верифицируется сертификат подписи расчетного центра и цифровая подпись РЦ. Продавец запоминает платежный отклик для последующего использования при контроле платежей, поступающих из его банка. Пары запросов CapReq/CapRes предоставляют механизм завершения ранее авторизованного денежного платежа. Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.
Генерация CapPayload осуществляется согласно алгоритму.
Формат сообщения CapReq представлен в таблице 4.6.2.68 Таблица 4.6.2.68. Формат CapReq
Структура данных CapPayload представлена в таблице 4.6.2.69. Таблица 4.6.2.69. Структура CapPayload
Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.
Расчетный центр обрабатывает CapPayLoad следующим образом.
Расчетный центр формирует отклик CapRes согласно следующему алгоритму.
Генерация CapResPayload осуществляется следующим образом.
Структура сообщения-отклика CapRes показана в таблице 4.6.2.70. Таблица 4.6.2.70. Структура CapRes
Структура данных CapResPayload представлена в таблице 4.6.2.71. Таблица 4.6.2.71. Структура CapResPayload
Продавец обрабатывает отклик CapRes следующим образом.
В таблице ниже представлены допустимые значения CapCode.
Сообщения отзыва платежа и кредита синтактически идентичны и выполняют сходную функцию. Алгоритм формирования информационной структуры CapRevOrCredReqData продавцом представлен ниже.
Структура данных CapRevOrCredReqData описана в таблице 4.6.2.72. Таблица 4.6.2.72. Структура CapRevOrCredReqData
Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.
Расчетный центр формирует CapRevOrCredResData с помощью следующей последовательности операций.
Структура данных CapRevOrCredResData имеет формат, описанный в таблице 4.6.2.73. Таблица 4.6.2.73. Структура CapRevOrCredResData
Структура данных CapRevOrCredResPayload представлена в таблице 4.6.2.74. Таблица 4.6.2.74. Структура CapRevOrCredResPayload
Допустимые значения кода CapRevOrCredCode представлены ниже
Обработка продавцом CapRevOrCredResData осуществляется следующим образом.
Пара сообщений CapRevReq/CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75. Таблица 4.6.2.75. Структура CapRevReq
Структура отклика показана ниже CapRevRes.
Пары сообщений CredReq/CredRes используются для возвращения кредита по оплаченным ранее транзакциям. Они могут применяться вместо CapRevReq/Res, когда записи о конкретной транзакции у продавца и в расчетном центре оказались удаленными или устаревшими. Такая последовательность сообщений используется продавцом, который может послать запрос CredReq в любое время после согласования номера счета с банком продавца. Формирование запроса CredReq осуществляется в следующей последовательности.
Структура запроса CredReq показана в таблице 4.6.2.76. Таблица 4.6.2.76. Структура CredReq
Расчетный центр обрабатывает полученный CredReq следующим образом.
Формирование CredRes осуществляется в следующей последовательности.
Формат отклика CredRes представлен ниже.
Продавец обрабатывает CredRes за два шага:
Сообщения CredRevReq/CredRevRes обеспечивают для продавца механизм отзыва предоставленного ранее кредита. Формирование запроса CredRevReq осуществляется следующим образом.
Структура запроса CredRevReq показана в таблице 4.6.2.77. Таблица 4.6.2.77. Структура CredRevReq
Расчетный центр обрабатывает запрос CredRevReq следующим образом.
Формирование отклика CredRevRes осуществляется в следующей последовательности.
Отклик CredRevRes имеет достаточно простой формат:
Продавец обрабатывает полученный отклик следующим образом
Обработка запроса сертификата расчетного центра включает в себя два сообщения, запрос от продавца к расчетному центру и отклик последнего, направляемый продавцу. В запросе продавец просит расчетный центр прислать ему сертификат, который необходим для последующего шифрования сообщений от продавца к расчетному центру. Сертификат присылается в сообщении-отклике. Генерация запроса PCertReq выполняется в следующей последовательности.
Формат сообщения-запроса PCertReq представлен в таблице 4.6.2.78.
Таблица 4.6.2.78. Структура сообщения PCertReq Расчетный центр обрабатывает PCertReq следующим образом
Формирование PCertRes осуществляется в следующей последовательности
Структура сообщения-отклика PCertRes представлена в таблице 4.6.2.79. Таблица 4.6.2.79. Структура PCertRes
Продавец обрабатывает PCertRes следующим образом.
Стандартизованы следующие значения PcertCode, собранные в таблице 4.6.2.80. Таблица 4.6.2.80. Значения PCertCode
Управление платежными линиями (Batch) Продавец посылает запросы управления платежными линиями расчетному центру для того, чтобы осуществлять контроль над последовательностями платежей расчетных транзакций. Операция управления платежной линией включает в себя обмен двумя сообщениями BatchAdminReq (запрос продавца в расчетный центр) и BatchAdminRes (отклик расчетного центра). Запрос может включать в себя инструкции открыть, очистить или закрыть платежную линию, а также передать или запросить информацию о состоянии платежной линии. Отклик несет в себе информацию о состоянии или запрошенные данные. Платежная линия формируется расчетным центром, когда продавец открывает ее для накопления транзакций и сумм. Все транзакции, которые проплачиваются, объединяются в специфическую группу (платежную линию - batch) или группу по умолчанию, если не определена специальная платежная линия (группа платежей). Следует учитывать, что в группу платежей могут входить операции, выполненные в рамках различных платежных систем. Поддержка групп платежей позволяет продавцу и расчетному центру улаживать проблемы, связанные с различными несогласованностями. Если продавец контролирует содержимое групп платежей, каждая платежная линия открывается прежде, чем транзакции ассоциируются с ней путем включения BatchID и BatchSequenceNum в платежные транзакции. Продавец может также закрыть платежную линию в соответствии с требованиями бизнеса. Транзакции не ассоциируются с платежной линией после ее закрытия. Продавец может также иметь возможность удалить все транзакции из открытой платежной линии. Очистка платежной линии не означает ее закрытия. Если содержанием платежных линий управляет расчетный центр, продавец не должен вставлять BatchID и BatchSequenceNum в платежные транзакции. Открытие и закрытие платежной линии контролируется в этом случае расчетным центром, который может включать BatchID и BatchSequenceNum в возвращаемую структуру SaleDetail. Продавец при этом не может удалять транзакции из группы или закрывать платежные линии, определенные идентификаторами BatchID, сформированными расчетным центром. Продавец может запросить статусную информацию для любой платежной линии, которая имеет известный BatchID. Расчетный центр возвращает BatchStatus для запрошенной платежной линии. Продавец может запросить BatchStatus для определенных платежных систем или итоговый баланс для конкретной платежной линии. Если продавец управляет содержимым платежной линии, тогда он может предоставлять информацию BatchStatus расчетному центру для любого BatchID. Расчетный центр проверяет данные, предоставленные продавцом в BatchStatus путем сверки с информацией, накопленной у него. При этом продавец получит отклик, в котором будет отражено соответствие этих сумм. Если продавец предоставляет информацию о транзакции расчетному центру, последний выдает состояние серии платежей в отклике BatchAdminRes, который следует за BatchAdminReq. Продавец формирует запрос BatchAdminReq в следующем порядке.
Структура запроса BatchAdminReq представлена в таблице 4.6.2.81. Таблица 4.6.2.81. Структура BatchAdminReq
Расчетный центр обрабатывает запрос BatchAdminReq следующим образом.
Формирование отклика BatchAdminRes осуществляется согласно следующему алгоритму.
Структура отклика BatchAdminRes представлена в таблице 4.6.2.82. Таблица 4.6.2.82. Структура BatchAdminRes
В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID
Продавец получает и обрабатывает BatchAdminRes следующим образом.
Для реализации протокола SET в конкретных приложениях можно использовать утилиту Wallet (http://www.microsoft.com/commerce/wallet/) фирмы Microsoft (Microsoft Commerce Server). Следует учитывать, что, так как система SET является достаточно сложной и дорогостоящей, а продавец должен платить за каждую операцию с кредитной карточкой, то через систему SET проходят платежи, превышающие 10$. Для осуществления более мелких платежей используются другие схемы (например, First Virtual, CyberCoin, DigiCash (http://www.digicash.nl) или Millicent - http://www.millicent.digital.com/). Схема First Virtual (http://www.fv.com) предназначена для продажи дешевых программных продуктов или услуг. Она предполагает регистрацию клиента, при которой он сообщает номер своей кредитной карточки и получает регистрационный номер (PIN). При покупке клиент вводит свой индивидуальный номер и, если он верен, немедленно получает доступ к нужному ему продукту. Позднее First Virtual связывается с клиентом по электронной почте, уведомляет о цене покупки, предоставляя ему одобрить или нет снятие соответствующей суммы с его кредитной карточки. Эта система зиждется на полном доверии и честности обеих сторон. Система CyberCash (http://www.cybercash.com) базируется на схеме, сходной с SET. Здесь также используется специальное программное обеспечение со стороны клиента и продавца. Клиент при регистрации получает бесплатно программу CyberCash Wallet и заполняет идентификационную и платежную информацию. Данная информация в зашифрованном виде будет храниться на ЭВМ клиента. Эти данные посылаются при нажатии клиентом клавиши "оплатить". Система предоставляет клиенту ряд дополнительных услуг, например просмотр баланса последних операций. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0
UP:
4.5.8 Поиск узлов и людей
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.6.4 Смарт-карты EMV
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Спецификация карты ICC (Integrated Circuit Card) В основу данной спецификации легли разработки компаний Europay, MasterCard и Visa (EMV) в марте, 1998 года. Следует принимать во внимание, что данная технология будет использоваться не только для финансовых операций. Планируется ее применения для проездных билетов и контроля доступа к ЭВМ. В перспективе можно предположить, что эта техника будет использоваться для идентификации личности, например, вместо паспорта.
Рис. 4.6.4.1. Расположение контактов на лицевой стороне карты
Рис. 4.6.4.2. Положение контактов (все контакты имеют размер 1,7х2,0 мм) Всего на карте 8 контактов. На рис. 4.6.4.1 обязательные контакты представлены закрашенными прямоугольниками. Контакты C4 и С8 не используются и могут отсутствовать, контакт же С6 используется для программирования на фазе изготовления. Сопротивление для этого контакта по отношению к любым другим контактом должно превышать 10 Мом при напряжении 5 В. Таблица 4.6.4.1.
VCC - напряжение питания 5 ╠ 0,5В при токе 50 мА при любых частотах работы микросхемы. В таблице 4.6.4.2 представлены параметры входных информационных сигналов VIH- Высокий уровень входного сигнала Таблица 4.6.4.2
Если передача не осуществляется, состояние драйвера ICC должно соответствовать режиму приема. В таблице 4.6.4.3 представлены параметры выходных информационных сигналов Таблица 4.6.4.3
В таблице 4.6.4.4 перечислены требования на параметры тактовых импульсов. ICC может работать корректно при скважности тактовых импульсов в диапазоне (44-56)% и значении тактовой частоты от 1 до 5 МГц. Таблица 4.6.4.4
В таблице 5 представлены характеристики сигнала сброса (RST). Таблица 4.6.4.5
ICC выдерживает уровни сигнала на шине RST от -0,3В до Vcc+0,3В. ICC откликается на сигнал сброса асинхронно. Микросхема может также противостоять импульсам тока через цепь питания до 100 мА длительностью 400 нсек и с интегральным зарядом 40 нАсек. Любая транзакция для карты начинается с ее вставления в интерфейсное устройство IFD (Interface Device) и активации контактов карты. Далее следует сброс микросхемы ICC в исходное состояние и установление связи между ICC и IFD. Только после этого начинает реализовываться конкретная транзакция. Любая транзакция завершается дезактивацией контактов и удалением ICC из интерфейсного устройства. После вставления карты в IFD терминал проверяет, что все сигнальные контакты находятся в состоянии L (низкий логический уровень - VOL). IFD контролирует корректность положения ICC с точностью ╠0,5мм. Если карта позиционирована правильно, производится активация контактов в соответствии с порядком, представленном на рис. 4.6.4.3.
Рис. 4.6.4.3. Последовательность активации контактов ICC Через некоторое время после подачи на ICC напряжения питания Vcc начинают поступать тактовые импульсы. В исходный момент времени (сразу после вставления карты уровень сигналов на шине I/O является низким (L). Далее уровень этой шины может быть неопределенным (обозначено на рисунке серым прямоугольником), но после прихода 200 тактов этот уровень становится высоким (H). При этом уровень на шине RST остается низким (L). Терминал IFD устанавливает свой драйвер I/O в режим приема не позднее поступления 200-го такта. После этого выполняется процедура сброса (Reset). ICC откликается на команду RESET асинхронно. Время, когда на ICC начинают поступать тактовые импульсы, называется T0. Терминал поддерживает в это время уровень шины RST в низком состоянии.
Рис. 4.6.4.4. Диаграмма реализации "холодного" сброса После прихода 40000-45000 тактов после Т0 шина RST переходит в состояние H. Этот момент времени называется T1. Начало отклика на Reset со стороны ICC наступает спустя 400-40000 тактов после T1 (время t1). Если за это время отклик со стороны ICC не поступает, терминал в пределах 50 мсек деактивирует контакты микросхемы на карте. Диаграмма холодного сброса ICC показана на рис. 4.6.4.4. Команда сброса может поступать и в процессе обычной работы - так называемый "теплый" сброс. Временная диаграмма такого сброса показана на рис. 4.6.4.5.
Рис. 4.6.4.5. Временная диаграмма "теплого" сброса Следует учитывать, что при теплом сбросе напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. После перехода шины RST в состояние L (момент времени T0') на шине I/O не позднее чем через 200 тактов должен установиться уровень H. В момент Т1' шина RST переходит в состояние H, после чего завершается процедура сброса аналогично "холодному" варианту. Процедура деактивации контактов ICC показана на рис. 4.6.4.6. В момент начала этой процедуры напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. Сигналом к началу процесса является переход шины RST в низкое состояние. Через некоторое время состояние шины I/O должно стать низким, прекращается подача тактовых импульсов, после чего с небольшой задержкой напряжение питания Vcc становится равным нулю и процедура в пределах 100 мсек завершается. При гальваническом отключении контактов Vcc должно быть не более 0,4 В. По завершении процедуры карта может быть извлечена из интерфейсного устройства.
Рис. 4.6.4.6. Временная диаграмма дезактивации контактов ICC Исходная длительность такта на шине I/O определяется как: t = 372/f секунд,где f частота в Гц. В общем случае t определяется как: t = F/(Df) ,где f частота в Гц, F и D параметры, которые могут варьироваться, но обычно F=372, а D=1. f лежит в пределах (1-5) МГц.
Рис. 4.6.4.7. Диаграмма передачи символов по шине I/O Перед началом передачи символа шина I/O должна находиться в состоянии H. Для передачи любого символа требуется 10 бит (смотри рисунок 4.6.4.7). Стартовый бит должен иметь уровень L и номер 1. Последний бит представляет собой бит четности (нечет). Стартовый бит детектируется путем стробирования шины I/O. Время стробирования составляет 0,2 t. Время между началами передачи последовательных символов составляет t(10╠0,2) плюс время выдержки. Во время выдержки ICC и терминал должны находиться в режиме приема. (H). Определены два протокола: символьный (Т=0) и блочный (Т=1). ICC поддерживает один из этих протоколов, терминалы поддерживают оба. Тип протокола определяется значением символа TD1. При отсутствии в ATR TD1 рабочим считается протокол Т=0. Физический уровень обмена должен согласовываться с обоими протоколами. Минимальный интервал между лидирующими битами двух последовательных символов, посылаемых ICC, равно 12t. Максимальный интервал между стартовыми битами двух последовательных символов (Work Waiting Time) не должно превышать (960хDxWI) t (параметры D и WI пересылаются с помощью символов TA1 и TC2, соответственно). Если это время будет превышено, терминал не позднее, чем спустя 960t должен начать процесс дезактивации. В режиме T=0, если ICC или терминал детектировали при передаче/приеме символа ошибку четности, шина I/O переводится в состояние L, чтобы передающая сторона узнала об ошибке. На транспортном уровне терминала TTL (Terminal Transport Layer) данные всегда передаются через шину I/O так, что старший байт следует первым. Будет ли первым старший бит, определяется символом TS, возвращаемым в ответ на команду сброс ATR. Такой отклик может содержать строку символов. При отклике на сброс минимальное время между стартовыми битами последовательных символов составляет 9600t. ICC передает все символы отклика в пределах 19200 t. Это время измеряется между стартовым битом первого символа TS и после 12 t от начала последнего символа. Число символов в отклике зависит от транспортного протокола и поддерживаемых управляющих параметров. ICC может опционно поддерживать более одного транспортного протокола, но одним из таких протоколов должен быть Т=0 или Т1. Символы, присылаемые в рамках ATR, представлены в таблице 4.6.4.6. Таблица 4.6.4.6. Базовый ATR для T=0
Если поддерживается только протокол типа T=1 (блочный асинхронный транспортный протокол), то используемые символы отклика ATR содержатся в таблице 4.6.4.7. Следует иметь в виду, что ICC может поддерживать более одного транспортного протокола. Таблица 4.6.4.7. Базовый ATR для T=1
Интерфейсы могут поддерживать отклики, не описанные в данной спецификации. Максимальное число символов в отклике, включая TS, не должно превышать 32. TS служит для синхронизации терминала и для определения логической схемы интерпретации последующих символов. Инверсная логическая схема предполагает, что логической единице на шине I/O соответствует уровень L, а старший бит данных передается первым. Прямая схема предполагает, что логической единице на шине I/O соответствует уровень H, а первым передается младший бит. Первые четыре бита LHHL используются для синхронизации. ICC может прислать ATR, содержащий TS, который имеет одно из следующих значений: T0 - символ формата. Старший полубайт (b5-b8) используется для определения того, присутствуют ли последующие символы TA1-TD1. Если биты b5-b8 установлены в состояние логической единицы, TA1-TD1 присутствуют. Младший полубайт (b1-b4) содержит число опционных исторических байтов (0-15). Смотри таблицу 4.6.4.8. Таблица 4.6.4.8
Символы интерфейса TA1-TC3 передают информацию, которая используется при обмене между терминалом и ICC. Они определяют значения параметров F, D, I, P и N, а также IFSC, BWI (Block Waiting time Integer) и CWI (Character Waiting time Integer). Информация, содержащаяся в TA1, TB1, TC1, TA2 и TB2 будут применяться для всех последующих обменов вне зависимости от используемого протокола. TA1 служит для передачи значений FI и DI, где FI используется для задания значения F (параметр, определяющий тактовую частоту). DI служит для задания значения D, используемого для настройки частоты следования бит. По умолчанию FI=1 и DI=1, что означает F=372, а D=1. Если ТА1 присутствует в ATR (b5 в T0 равен 1) и TA2 прислан с b5=0, то терминал воспринимает ATR, если TA1=11, и немедленно реализует указанные F и D. ТВ1 несет в себе значения PI1 и II, где PI1 специфицировано в битах b1-b5 и используется для программирования значения напряжения P, необходимого ICC. PI0=0 означает, что VPP не подключено к ICC. II специфицируется в битах b6 и b7 и служит для определения максимального тока, потребляемого ICC. Этот параметр не используется, если PI1 = 0. TC1 несет в себе величину N, которая используется для задания дополнительной выдержки (guardtime) между символами. Это время будет добавлено к минимальной выдержке. N может принимать значения 0-255 t. TD1 указывает, должны ли быть переданы еще интерфейсные байты, и содержит информацию о типе протокола. Старший полубайт используется для индикации наличия символов TA2 - TD2. Биты b5-b8 принимают значение логической единицы, если указанные выше символы присутствуют. Младший полубайт указывает протокол, который будет использован для последующих обменов. ATR не содержит TD1, если используется только Т=0. Для T=1 TD1=81 указывает на наличие TD2. Наличие или отсутствие TA2 говорит о работе ICC в специфическом или согласованном режиме, соответственно. Базовый отклик ATR не содержит ТА2. ТВ2 передает PI2, который используется для определения величины программируемого напряжения Р, необходимого ICC. Если этот символ присутствует, значение, указанное в PI1 (ТВ1), заменяется на новое. По умолчанию ТВ2 отсутствует. ТС2 специфичен для протокола типа Т=0 и несет в себе значение WI (Waiting time Integer), которое используется для определения максимального интервала между началом передачи любого символа, посланного ICC, и началом предыдущего символа, поступившего от ICC или терминала. Время выдержки вычисляется по формуле 960xDxWI. По умолчанию ТС2 отсутствует, а WI=10. Терминал воспринимает ATR, содержащий ТС2=0А. Он отвергает ATR, несущий в себе ТС2=00 или ТС2>0А. TD2 указывает, будут ли еще переданы какие-либо интерфейсные байты, а также определяет тип протокола, используемого далее. Старший полубайт используется для указания наличия символов ТА3 - TD3. Биты b5-b8 устанавливаются в единичное состояние при наличии ТА3 - TD3. Младший полубайт указывает тип протокола, применяемый в последующих обменах. При Т=1 он равняется 1. По умолчанию при Т=0 ATR не содержит TD2, в противном случае ATR содержит TD2=31 (T=1). ТА3 несет в себе информацию о размере поля данных для ICC (IFSI) и специфицирует длину информационного поля INF блоков, которые могут быть получены картой. Этот символ характеризует длину IFSC в байтах и может содержать коды в интервале 0х01-0хFE. Значения 0х00 и 0хFF зарезервированы на будущее. По умолчанию ATR содержит ТА3 со значение в диапазоне 0х10-0хFE, если Т=1, IFSC лежит в интервале 16-254 байта. Если ТА3 содержит недопустимый код, ATR терминалом отвергается. ТВ3 характеризует значения CWI и BWI, используемые для вычисления CWT и BWT, соответственно. ТВ3 имеет две части. Младший полубайт (b1-b4) используется для определения значения CWI, а старший полубайт (b5-b8) - BWI. По умолчанию ATR несет в себе ТВ3, при этом младший полубайт содержит код 0-5, а старший - 0-4, если Т=1, указывая, что CWI=0-5, а BWI=0-4. Формат ТВ3 показан в таблице 4.6.4.9. Таблица 4.6.4.9
XXX лежит в интервале 000-100, а YYY - 000-101 Терминал отвергает ATR, не содержащий ТВ3 или указывающий на значения BWI больше 4 и/или CWI больше 5, или 2CWI<(N+1). TC3 индицирует тип блока кода детектирования ошибки. Тип кода определяется битом b1 (b2-b8 - не используются). По умолчанию ATR не содержит ТС3. Терминал воспринимает ATR с ТС3=00, и отбрасывает любые-другие ATR, содержащие другие значения ТС3. ТСК (контрольный символ) имеет значение, которое позволяет проверить целостность данных, пересылаемых в ATR. Значение TCK таково, что исключающее ИЛИ всех байтов от Т0 до ТСК включительно должно давать код 0. По умолчанию ATR не содержит ТСК, если используется только Т=0, во всех других случаях ТСК должен присутствовать. Терминал воспринимает ATR ICC без TCK, если только Т=0. Во всех остальных случаях терминал отвергнет ATR без, или с некорректным ТСК. Если ТСК некорректно, терминал инициирует последовательность дезактивации не позднее 480 t после начала ТСК. Если терминал отверг холодный АТR, он не отвергает карту немедленно, а инициирует "теплый" сброс в пределах 4800t. Если терминал отверг теплый ATR, он в пределах 4800 t запускает процедуру дезактивации. Если во время отклика на холодный или теплый сброс интервал между двумя последовательными символами превысит 9600t, терминал прерывает сессию путем инициализации дезактивации спустя 14400t после стартового бита последнего полученного символа. Если отклик на холодный или теплый сброс не завершился в пределах 19200t , терминал спустя 24000t (от начала TS) запускает процедуру дезактивации карты. Если терминал обнаруживает ошибку по четности при передаче символа ATR, он прерывает сессию карты и спустя 4800t инициирует процедуру дезактивации. 4.6.4.1. Команды Команды всегда инициируются прикладным уровнем терминала TAL (Terminal Application Layer), который посылает инструкции ICC через транспортный уровень TTL (Terminal Transport Layer). Команда содержит последовательность из 5 байт: CLA, INS, P1, P2 и P3.
Эти 5 байт вместе с байтами данных образуют командный блок протокольной информации C-TPDU для Т=0. Получив команду, ICC откликается отправкой процедурного или статусных байтов. Процедурный байт указывает TTL, какая операция является следующей. Отклик терминала на процедурный байт представлен в таблице 4.6.4.10. Таблица 4.6.4.10. Отклик терминала на процедурный байт
Во всех случаях после реализации операции TTL ждет прихода процедурного байта или статусного сообщения. Командное сообщение, посылаемое от прикладного уровня, и сообщение-отклик ICC называются APDU (Application Protocol Data Unit). Формат APDU показан на рисунке 4.6.4.8.
Рис. 4.6.4.8. Структура командного APDU. Все поля заголовка имеют по одному байту. Поле данных содержит Lc байт.
Если параметры Р1 и Р2 не используются, коды полей должны равняться 00. Формат отклика APDU аналогичен показанному на 4.6.4.8. Поле данных имеет переменную длину и, вообще говоря, может отсутствовать. Однобайтовые поля SW1 и SW2 должны присутствовать обязательно. SW1 характеризует состояние обработки команды, а SW2 - является квалификатором обработки команды. Кодировка команд для полей CLA и INS представлена в таблице 4.6.4.11. Таблица 4.6.4.11. Кодирование командного байта
Статусные байты SW1 и SW2 указывают TTL, что обработка команды завершена. Значения этих байт интерпретируются в зависимости от обрабатываемой команды. Коды и значения полей SW1 и SW2 представлены в таблице 4.6.4.12. Таблица 4.6.4.12. Кодирование статусных байтов SW1, SW2
Таблица 4.6.4.12А. Сводные данные по командам/откликам
Блочный протокол Т=1 предполагает передачу блоков данных между TAL (Terminal Application Layer) и ICC. Эти блоки несут в себе команды, R-APDU (Response Application Protocol Data Unit) и управляющую информацию. Структура блока показана на рисунке 4.6.4.10. Поля заголовка и эпилога (хвостовика) являются обязательными. Биты b1-b3 NAD указывают на адрес отправителя (SAD), а b5-b7 - адрес получателя (DAD). В настоящее время адресация узлов не поддерживается и по этой причине в поле NAD следует записывать код 00. Биты b4 и b8 равны нулю. Код PCB определяет тип блока. Существует три типа блоков: информационные (I-блок), готовности приема (R-блок, подтверждение) и управляющие (S-блок).
Рис. 4.6.4.9. Структура блока Кодирование PCB зависит от его типа, оно представлено в таблицах 4.6.4.13-15. Таблица 4.6.4.13. Кодирование PCB I-блоков
Таблица 4.6.4.14. Кодирование PCB R-блоков
Таблица 4.6.4.15. Кодирование PCB S-блоков
Поле LEN определяет размер информационного поля и может равняться 0-254. R-блоки не имеют поля данных. Блоки I- и S-типов нумеруются по модулю 2, их число может равняться 0 или 1 (первый блок имеет номер 0). Счетчик нумерации сбрасывается в 0 после ресинхронизации. Поле EDC представляет собой объединение всех байт блока, начиная с NAD и кончая последним байтом поля INF (если это поле присутствует), с помощью операции исключающее ИЛИ. Максимальный размер поля данных ICC (IFSC) блока определяется параметром ТА3, присылаемым ICC в отклике на сброс. IFSI может принимать значения 10-FE, что означает для IFSC диапазон 16-254 байта. Максимальный размер поля данных терминала (IFSD) составляет 254 байта. Время ожидания блока BWT (Block Waiting Time) в общем случае вычисляется согласно следующей формуле. Реально BWT может лежать в диапазоне (971-15371)t.
Когда отправитель намерен передать объем данных больше, чем это определено параметрами IFSC или IFSD, он должен разбить эту последовательность байтов на несколько I-блоков. Передача этих блоков осуществляется с привлечением механизма цепочек. Для объединения I-блоков в цепочку используется бит b6 в PCB (смотри табл. 4.6.4.13). Если b6=0, то это последний блок в цепочке. Если же b6=1, далее следует как минимум еще один блок. Получение любого I-блок с b6=1 должно быть подтверждено R-блоком. Последний блок цепочки, посланный терминалом, подтверждается I-блоком, если получен безошибочно, или R-блоком, при обнаружении ошибки. В случае ICC получение последнего блока цепочки подтверждается R-блоком при обнаружении ошибки. Если ошибки не было, терминал просто посылает очередной I-блок, если должна обрабатываться очередная команда. Передача цепочки возможна в одно и тоже время только в одном направлении. Когда терминал является получателем, он воспринимает цепочки I-блоков, передаваемых ICC, если длина блоков ≤ IFSD. Если получателем является ICC, карта воспринимает цепочку I-блоков, посланных терминалом и имеющих длину LEN=IFSC, за исключением последнего блока, длина которого может лежать в диапазоне (1-IFSC). Если длина блока > IFSC, ICC такой блок отвергает, послав R-блок с битами b4-b1 в PCB, равными 2. 4.6.4.2. Элементы данных и файлы Приложение в ICC содержит набор информационных элементов. Терминал может получить доступ к этим элементам после успешного выбора приложения. Информационным элементам присваиваются имена, они имеют определенное описание содержимого, формат и кодирование. Информационный объект состоит из метки (tag), кода длины и значения. Метка однозначно идентифицирует объект в рамках данного приложения. Поле длина определяет число байт в поле значение. Объекты могут объединяться, образуя составные объекты. Определенное число простых или составных объектов могут образовывать записи. Присвоение меток регламентируется документами ISO/IEC 8825 и ISO/IEC 7816. Записи, содержащие информационные объекты, хранятся в файлах ICC. Структура файла и метод доступа зависят от назначения файла. Организация файлов определяется приложениями платежной системы PSA (Payment System Application). Проход к набору PSA в ICC разрешается с помощью выбора среды платежной системы PSE (Payment System Environment). Когда PSE присутствует, файлы, относящиеся к PSA, доступны для терминала через древовидную структуру каталога. Каждая ветвь этого дерева является файлом определения приложения ADF (Application Definition File) или файлом определения каталога DDF (Directory Definition File). ADF является входной точкой одного или нескольких прикладных первичных файлов AEF (Application Elementary File). ADF со стороны терминала воспринимается как файл, содержащий информационные объекты, которые инкапсулированы в FCI (File Control Information). Информационные файлы состоят из последовательности пронумерованных записей. Каждому файлу присваивается короткий идентификатор SFI (принимает значения 1-10), с помощью которого можно обращаться к файлу. Чтение каталога осуществляется с помощью команды READ RECORD. Когда PSE присутствует, ICC поддерживает структуру каталога для списка приложений в пределах PSE (определяется эмитентом карты). Каждому приложению присваивается идентификатор AID (Application Identifier; ISO/IEC 7816-5). К любому ADF или DDF в карте обращение производится посредством имени DF (Dedicated File). DF для ADF соответствует AID и для данной карты должно быть уникальным. Формат записи каталога PSE показан на рисунке 4.6.4.11.
Рис. 4.6.4.11. Формат записи каталога PSE Содержимое полей элемент каталога характеризуется в таблицах 4.6.4.16 и 4.6.4.17. Таблица 4.6.4.16. Формат элемента каталога DDF
Таблица 4.6.4.17. Формат элемента каталога ADF
Понятно, что в области, где используются карты ICC, наиболее важными являются аспекты безопасности. 4.6.4.3. Соображения безопасности
Статическая аутентификация выполняется терминалом, использующим цифровую подпись, которая базируется на методике общедоступных ключей. Эта техника позволяет подтвердить легитимность некоторых важных данных, записанных в ICC и идентифицируемых с помощью AFL (Application File Locator). Статическая аутентификация требует существования сертификационного сервера (или центра), который имеет надежную защиту и способен подписывать общедоступные ключи эмитента карты. Каждый терминал должен содержать общедоступный ключ центра сертификации для каждого приложения, распознаваемого терминалом. Взаимодействие клиента, центра сертификации и эмитента карты показано на рисунке 4.6.4.12.
Рис. 4.6.4.12. Диаграмма статической аутентификации данных Карта ICC, которая поддерживает статическую аутентификацию данных, должна содержать следующие информационные элементы.
Для поддержки статической аутентификации ICC должна содержать статические прикладные данные, подписанные секретным ключом эмитента. Общедоступный ключ эмитента записывается в ICC вместе с сертификатом общедоступного ключа. Модуль общедоступного ключа сертификационного ключа имеет NCA байт, где NCA ≤ 248, показатель степени этого ключа равен 2, 3 или 216+1. Общедоступный ключ эмитента имеет модуль ключа, содержащий NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части. Одна часть, состоящая из NCC -36 старших байт модуля (левые цифры общедоступного ключа эмитента), и вторая часть с оставшимися NЭ - (NCC - 36) младшими байтами. Показатель степени общедоступного ключа эмитента должен быть равен 2, 3 или 216+1. Вся необходимая информация, необходимая для статической аутентификации записывается в ICC (смотри таблицу 4.6.4.18 и 4.6.4.19). За исключением RID (Registered Application Provider Identifier), который может быть получен из AID (Application Identifier), эта информация может быть получена посредством команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу. Таблица 4.6.4.18. Данные, сопряженные с общедоступным ключом эмитента, которые должны быть подписаны центром сертификации.
Таблица 4.6.4.19. Статическая прикладная информация, подписываемая эмитентом
Таблица 4.6.4.20. Информационные объекты, необходимые для аутентификации статических данных
Терминал считывает индекс общедоступного ключа сертификационного центра. Используя этот индекс и RID, терминал идентифицирует и извлекает из своей памяти модуль и показатель общедоступного ключа сертификационного центра, а также сопутствующую информацию, определяет алгоритм обработки. Если какой-то из перечисленных компонентов отсутствует, аутентификация не состоится. Если сертификат общедоступного ключа эмитента имеет длину отличную от модуля общедоступного ключа сертификационного центра, то аутентификация не пройдет. Для того чтобы получить данные, представленные в таблице 4.6.4.21, используется сертификат общедоступного ключа эмитента и общедоступный ключ центра сертификации. Если хвостовик восстановленных данных сообщения не равен BC, аутентификация не удалась. Таблица 4.6.4.21. Формат восстановленных данных сертификата общедоступного ключа эмитента
Проводится проверка заголовка восстановленных данных и, если он не равен 0х6А, аутентификация аннулируется. Проверяется поле формат сертификата и, если его код не равен 0х02, аутентификация отвергается. Далее объединяются слева направо, начиная со второго и кончая десятым, информационные элементы, представленные в таблице 4.6.4.21 (от поля формат сертификата до общедоступного ключа эмитента или левых цифр этого ключа), к результату добавляется хвостовик общедоступного ключа эмитента (если он имеется) и показатель этого ключа. Результат данного объединения подвергается хэшированию согласно заданному алгоритму. Полученный результат сравнивается со значением поля результат хэширования (см. табл. 4.6.4.21). Если совпадения нет, аутентификация не состоялась. Проверяется, что идентификационный номер эмитента соответствует левым цифрам 3-8 PAN. При несоответствии аутентификация отвергается. Проверяется, не закончился ли срок действия сертификата. Если срок истек, аутентификации не происходит. Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации, серийного номера сертификата является корректным, в противном случае аутентификация не проходит. Если не распознан индикатор алгоритма общедоступного ключа эмитента, аутентификация также не пройдет. Если все предыдущие проверки прошли успешно, то производится объединение левых цифр общедоступного ключа эмитента и его остатка (если таковой имеется) с целью получения модуля общедоступного ключа эмитента, после чего процесс переходит в следующую фазу проверок подписанных статических прикладных данных. Если подписанные статические прикладные данные имеют длину, отличную от длины модуля общедоступного ключа эмитента, аутентификация не состоится. Для того чтобы получить данные, представленные в таблице 4.6.4.22, берутся подписанные статические прикладные данные и общедоступный ключ эмитента. Если хвостовик восстановленных данных окажется не равным BC, аутентификация отвергается. Таблица 4.6.4.22. Формат восстановленных данных из подписанных статических прикладных данных.
Проверяется заголовок восстановленных данных и, если он не равен 0х6A, аутентификация не проходит. Проверяется формат подписанных данных и, если его код не равен 0х03, аутентификация не проходит. Объединяются информационные элементы, начиная со второго по пятый (см. табл. 4.6.4.22), добавляются данные, подлежащие аутентификации, после чего вычисляется хэш. Полученный результат сравнивается со значением поля результата хэширования. При несовпадении аутентификация терпит неудачу. Если все предшествующие проверки прошли успешно, данные считаются аутентифицированными. 4.6.4.4. Динамическая аутентификация данных Динамическая аутентификация данных выполняется терминалом, с использованием цифровой подписи, базирующейся на технике общедоступного ключа, и имеет целью аутентифицировать ICC и подтвердить легитимность динамической информации, записанной на ICC. Динамическая аутентификация требует наличия центра аутентификации, который подписывает общедоступные ключи эмитента. Каждый терминал должен иметь общедоступные ключи сертификационного центра для каждого приложения, распознаваемого терминалом. Схема аутентификации динамических данных показана на рис. 4.6.4.12.
Рис. 4.6.4.12. Схема динамической аутентификации данных ICC, которая поддерживает аутентификацию динамических данных, должна содержать следующие информационные элементы.
ICC, которые поддерживают аутентификацию динамических прикладных данных, должны сформировать следующий информационный элемент. Подписанные динамические прикладные данные. Этот информационный элемент переменной длины формируется ICC с помощью секретного ключа, который соответствует общедоступному ключу, аутентифицированному в сертификате общедоступного ключа ICC. Чтобы поддерживать аутентификацию динамических данных, каждый терминал должен запоминать большое число общедоступных ключей сертификационного центра, и ставить им в соответствие информацию, которая должна использоваться с этими ключами. Терминал способен найти любой такой ключ, заданный RID и индексом общедоступного ключа сертификационного центра, полученных от ICC. ICC, поддерживающая аутентификацию динамических данных должна иметь пару ключей, один из которых является секретным, служащим для цифровой подписи, другой - общедоступный для верификации. Общедоступный ключ ICC запоминается ИС картой в сертификате общедоступного ключа, сформированном эмитентом карты. Общедоступный ключ эмитента сертифицирован центром сертификации. Как следствие для верификации подписи ICC терминал должен сначала верифицировать два сертификата, для того чтобы получить и аутентифицировать общедоступный ключ ICC, который далее служит для проверки корректности динамической подписи ICC. Процедура цифровой подписи использует данные, представленные в таблицах 4.6.4.23 и 4.6.4.24. Модуль общедоступного ключа сертификационного центра содержит NCC байт, где NCC ≤ 248. Показатель общедоступного ключа сертификационного центра равен 2, 3 или 216+1. Модуль общедоступного ключа эмитента содержит NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части, одна состоит из NCC - 36 старших байт модуля (левые цифры), а вторая часть содержит остальные NЭ - (NCC - 36) младших байт модуля (остаток общедоступного ключа эмитента). Показатель общедоступного ключа эмитента равен 2, 3 или 216+1. Модуль общедоступного ключа ICC содержит NIC байт, где NIC ≤ 128 и NIC < NЭ. Если NIC > (NЭ - 42), модуль общедоступного ключа ICC делится на две части, одна - состоит из NЭ - 42 старших байт модуля (левые цифры общедоступного ключа ICC) и остальных NIC - (NЭ - 42) младших байт модуля (остаток общедоступного ключа ICC). Показатель общедоступного ключа ICC равен 2, 3 или 216+1. Для осуществления аутентификации динамических данных терминал сначала извлекает и аутентифицирует общедоступный ключ ICC (аутентификация общедоступного ключа ICC). Вся информация, необходимая для аутентификации общедоступного ключа ICC представлена в таблице 4.6.4.25 и хранится в памяти ICC. За исключением RID, который может быть получен из AID, эта информация извлекается с помощью команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу. Таблица 4.6.4.23. Данные общедоступного ключа эмитента, которые должны быть подписаны сертификационным центром.
Таблица 4.6.4.24. Данные общедоступного ключа ICC, которые должны быть подписаны эмитентом карты
Таблица 4.6.4.25. Информационные объекты, необходимые для аутентификации общедоступного ключа
Терминал считывает индекс общедоступного ключа центра сертификации. Используя этот индекс и RID, терминал может идентифицировать и извлечь из памяти модуль и показатель общедоступного ключа сертификационного центра и сопряженную с ним информацию. Если терминал не сможет найти нужные данные, сертификация не состоится. Если сертификат общедоступного ключа эмитента имеет длину отличную от длины модуля общедоступного ключа сертификационного центра, аутентификация динамических данных не проходит. Для того чтобы получить восстановленные данные, представленные в таблице 4.6.4.26, используется сертификат общедоступного ключа эмитента и общедоступный ключ центра сертификации. Если хвостовик восстановленных данных не равен 0хBC, аутентификация динамических данных не проходит. Проверяется заголовок восстановленных данных и, если он не равен 0х6А, аутентификация отвергается. Проверяется код формата сертификата и, если он не равен 0х02, аутентификация отвергается. Объединяются слева направо информационные элементы со второго по десятый (см. табл. 4.6.4.26), добавляется остаток общедоступного ключа эмитента (если он имеется) и показатель этого ключа. Для полученной строки применяется соответствующий алгоритм хэширования. Сравнивается вычисленный хэш и восстановленное значение поля результата хэширования. При несовпадении аутентификация не проходит. Таблица 4.6.4.26. Формат восстановленных данных из сертификата общедоступного ключа эмитента.
Проверяется то, что идентификационный номер эмитента соответствуют 3-8 цифрам PAN. Если соответствия нет, аутентификация отвергается. Проверяется срок действия сертификата и, если он истек, аутентификация отвергается. Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации и серийного номера сертификата корректно. Если индикатор алгоритма общедоступного ключа эмитента не распознан, аутентификация не проходит. Если все вышеперечисленные проверки прошли успешно, осуществляется объединение левых цифр общедоступного ключа эмитента и остатка этого ключа (если он имеется). Это делается для получения модуля общедоступного ключа эмитента. После данной процедуры система переходит к извлечению общедоступного ключа ICC. Если сертификат общедоступного ключа ICC имеет длину, отличную от длины модуля общедоступного ключа эмитента, авторизация не проходит. Для того чтобы получить данные, специфицированные в таблице 4.6.4.27, используется сертификат общедоступного ключа ICC и общедоступный ключ эмитента. Если хвостовик восстановленных данных не равен 0хВС, аутентификация не проходит. Если при проверке код заголовка восстановленных данных не равен 0х6А, аутентификация не проходит. Если код формата сертификата не равен 0х04, аутентификация также не проходит. Таблица 4.6.4.27. Формат восстановленных данных из сертификата общедоступного ключа ICC.
Объединяются слева направо поля из таблицы 4.6.4.27, начиная со второго до десятого, добавляется остаток общедоступного ключа ICC (если имеется), показатель общедоступного ключа ICC и данные, подлежащие аутентификации. Это объединение хэшируется согласно указанному алгоритму. Результат сравнивается со значением поля результат хэширования. При несовпадении аутентификация не проходит. Восстановленный PAN должен быть равен PAN приложения (ICC). После этого проверяется срок пригодности сертификата. Если все выше перечисленные проверки оказались успешными, система переходит к последующим тестам. После получения общедоступного ключа ICC терминал выдает команду INTERNAL AUTHENTICATE для объединения информационных элементов DDOL (Dynamic Data Authentication Data Object List). ICC может нести в себе DDOL, но терминал имеет значение DDOL по умолчанию, специфицированное платежной системой на случай отсутствия этих данных в ICC. DDOL должен содержать непредсказуемое число, формируемое терминалом (тэг 0х9F37, четыре двоичных байта). ICC генерирует цифровую подпись для данных, специфицированных в таблице 4.6.4.28 с использованием секретного ключа (SIC) ICC. Результат называется подписанными динамическими данными приложения. Таблица 4.6.4.28. Динамические данные приложения, которые должны быть подписаны
Длина динамических данных ICC LDD удовлетворяет условию 0 ≤ LDD ≤ NIC - 25. 3-9 самых левых байтов динамических данных ICC включают в себя 1 байт длины динамического числа ICC, за которым следует 2-8 байт значения этого числа (тэг 9F4C, 2-8 двоичных байтов). Динамическое число ICC формируется ICC. Кроме данных, перечисленных в таблице 4.6.4.28, для аутентификации динамических данных необходимы информационные объекты: Подписанные динамические данные приложения (NIC байтов; тэг 9F4B) и DDOL (тэг 9F49). Если подписанные динамические данные приложения имеют длину отличную от длины модуля общедоступного ключа ICC, аутентификация не проходит. Чтобы получить восстановленные данные, описанные в таблице 4.6.4.29 для подписанных динамических данных приложения используется общедоступный ключ ICC. Если хвостовик восстановленных данных не равен 0хBC, аутентификация не проходит. Таблица 4.6.4.29. Формат данных, полученных из подписанных динамических данных приложения
Далее проверяется заголовок восстановленных данных, если его код не равен 0х6А, аутентификация не проходит. Проверяется код формата подписанных данных и, если он не равен 0х05, аутентификация не проходит. Производится объединение слева направо шести информационных элементов из таблицы 4.6.4.29 (начиная с поля формата подписанных данных). Производится хэширование этого объединения, после чего полученный результат сравнивается со значением поля результата хэширования и, если совпадения нет, аутентификация не проходит. Если все предыдущие шаги оказались успешными, аутентификация динамических данных завершается успехом. 4.6.4.5. Безопасный обмен сообщениями Целью безопасного обмена сообщениями является обеспечение конфиденциальности, целостность данных и аутентификация отправителя. Принято два формата сообщений. Формат 1 следует спецификации ISO/IEC 7816-4, где поле данных кодируется согласно BER-TLV и правилам ASN.1/ISO 8825. Этот формат задается младшим полубайтом класса команды равным 0xC. Формат предполагает также, что заголовок команды включается в вычисление MAC (Message Authentication Code). Формат 2 не использует кодирования BER-TLV. В этом случае информационные объекты, содержащиеся в поле данных и их длины должны быть известны отправителю команды и выбранному приложению. Согласно спецификации ISO/IEC 7816-4 этот формат задается младшим полубайтом байта класса, который должен быть равен 0х4. Поле данных команды в случае формата 1 состоит из следующих TLV (Tag Length Value) информационных объектов, как это показано на рисунке 4.6.4.13.
Рис. 4.6.4.13. Формат 1 поля данных команды для безопасного обмена сообщениями Данные команды, если имеются, должны быть подписаны. Если поле данных закодировано согласно BER-TLV, оно либо не должно принадлежать контекстному классу (тэг лежит вне диапазона 80-BF), либо иметь четный тэг. Вторым информационным объектом является MAC. Его тэг равен 0х8Е, а его длина лежит в диапазоне 4-8 байт. В случае формата 2 МАС не кодируется BER-TLV и всегда является последним элементом информационного поля, а его длина лежит в пределах 4-8 байт. Вычисление s байтов МАС (4≤s≤8) осуществляется согласно ISO/IEC9797 с использованием 64-битового блочного шифра ALG в режиме CBC. Процедура формирования МАС начинается с получения ключа сессии из мастерного ключа МАС ICC. Ключ сессии KS для безопасного обмена сообщениями получается из уникальных мастерных ключей MK с привлечением непредсказуемых данных R, так что KS := F(KS)[R]. Единственным требованием к функции F является то, что число возможных ее значений достаточно велико и равномерно распределено. При использовании формата 1 сообщение состоит из заголовка команды APDU (Application Protocol Data Unite = CLA INS P1 P2) и командной информации (если таковая имеется). В случае формата 2 сообщение формируется согласно спецификации используемой платежной схемы. Но оно всегда содержит заголовок команды APDU. Если МАС специфицирован, как имеющий длину менее 8 байтов, он получается из старших (левых) байтов 8-байтного результата его вычисления. Формат зашифрованных командных данных показан на рисунке 4.6.4.14.
Рис. 4.6.4.14. Формат 1 для зашифрованных командных данных Тэг, согласно спецификации ISO/IEC 7816-6 определяется характером исходных (незашифрованных данных). Четный тэг используется, если объект должен быть включен в вычисление МАС; во всех остальных случаях тэг должен быть нечетным. В случае формата 2 поле данных команды шифруется как целое, исключение составляет MAC, если он присутствует (см. рис. 4.6.4.15)
Рис. 4.6.4.15. Формат 2 поля данных команды Процедура шифрования начинается с получения ключа сессии, который вычисляется на основе мастерного ключа шифрования ICC (см. выше). Шифрование производится с использованием 64-битного блочного шифра ALG в режиме СВС (симметричная схема). Для увеличения безопасности может использоваться PIN (Personal Identification Number). Верификация PIN осуществляется терминалом с использованием асимметричного алгоритма (общедоступный и секретный ключи). Более полное описание технологии EMV вы можете найти по адресу (английская версия): ftp://saturn.itep.ru/~emvcard.pdf Не исключено, что конкуренцию EMV-картам в торговле через Интернет составят виртуальные кредитные карты, применение которых упомянуто во введении. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8
UP:
4.5.8 Поиск узлов и людей
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
CyberCash Inc. представляет собой компанию, базирующуюся в штате Вирджиния и основанную в августе 1994. Целью компании является посредничество в сфере платежей через Интернет. CyberCash выполняет функцию посредника, через которого осуществляются финансовые операции между покупателем, продавцом и их банками. Важно то, что до начала операции участники могут не иметь никаких отношений друг с другом. CyberCash является третьей стороной, которая гарантирует надежную проводку платежа от одного партнера к другому. 1.1. Обзор системы Система CyberCash предназначена для обеспечения нескольких платежных услуг в Интернет. Чтобы получить доступ к услугам CyberCash, клиенту нужен только персональная ЭВМ, имеющая доступ к сети. Соответственно, продавцы и банкиры должны лишь незначительно изменить свои операционные процедуры, чтобы реализовать транзакции CyberCash. Вначале покупатель должен загрузить общедоступное программное обеспечение CyberCash из Интернет. Эта программа устанавливает соединение между покупателями, продавцами и их банками. Доступ к системе CyberCash еще проще, кнопки CyberCash "PAY" могут быть вставлены в популярные программы реального времени, позволяя клиенту войти в систему CyberCash, когда он пожелает осуществить оплату товара или услуги. Покупатель может не иметь до этого каких-либо отношений с CyberCash. Клиент идентифицирует свою личность через сеть. Транзакции используют информацию, введенную клиентом в свою ЭВМ, никакого ручного ввода данных для аутентификации не требуется. Покупатель лишь запускает платежную процедуру для каждой транзакции путем выбора одной из опций. Безопасность транзакций обеспечивается криптографически. Конфиденциальная информация о покупателе по каналам связи (например, продавцу) не пересылается.
Рис. .1. Схема взаимодействия субъектов сделки 1.2. Соображения безопасности В системе CyberCash особое внимание уделяется вопросам безопасности. Система использует самые современные технологии шифрования и способна адаптировать любые новые схемы шифрования, которые появятся в будущем. 1.2.1. Аутентификация и идентификация личности Аутентификация сообщений базируется на применении общедоступного ключа, как это делается в алгоритме RSA. Сервер CyberCash содержит записи общедоступных ключей для "персон" покупателя и продавца. Таким образом, можно аутентифицировать любую информацию подписанную покупателем или продавцом, вне зависимости от пути, которым эта информация попала на сервер. Соответствующий секретный ключ, который необходим для формирования цифровых подписей, хранится покупателем и продавцом и никогда не раскрывается. В программе клиента секретный ключ хранится в зашифрованном виде, защищенный парольной фразой. В то время как истинная идентичность покупателя или продавца определяется парой ключей (общедоступный/секретный), для человека эти ключи запомнить слишком сложно (более 100 шестнадцатеричных цифр). Поэтому, пользовательский интерфейс использует короткие алфавитно-цифровые идентификаторы, выбранные пользователем, для того чтобы специфицировать себя. CyberCash добавляет контрольные цифры к запрошенному ADDS ID, с тем чтобы минимизировать вероятность неверного выбора персоны. IDU персоны является общедоступной информацией. Владение ID персоны без соответствующего секретного ключа в данной системе не предоставляет каких-либо преимуществ. Отдельные лица или организации могут образовать одного или несколько CyberCash клиентов. Таким образом, отдельному лицу может соответствовать несколько несвязанных друг с другом CyberCash-клиентов, а разным лицам может соответствовать общий CyberCash-клиент. Этот подход предоставляет уровень конфиденциальности, согласующийся с Интернет и с требованиями финансовых операций. Однако, персона, желающая воспользоваться кредитной карточкой для покупки в рамках системы CyberCash должна сначала идентифицировать себя, как это требует организация, выпустившая эту карту. Контроль над персоной CyberCash доступен только субъекту, владеющему секретным ключом данной персоны. В то же время, для каждой CyberCash-персоны предусмотрена аварийная парольная фраза блокировки. По получении этой парольной фразы, даже в случае использования небезопасного канала, такого как телефон или обычная электронная почта, CyberCash отложит любые операции для данной CyberCash-персоны. Эта парольная фраза может быть записана отдельно и храниться менее строго по сравнению с секретным ключом, так как она не может быть использована для передачи денег. Это обеспечивает некоторую защиту против потери секретного ключа или пароля, с помощью которого он был зашифрован. 1.2.2. Конфиденциальность Сообщения шифрования работают со стандартом DES (Digital Encryption Standard), обычно используемым в настоящее время при осуществлении электронных платежей. Планируется применение супершифрования (т.e., более чем одноуровневое шифрование) особо чувствительной информации, такой как PIN-коды, и обрабатывать их так, что они никогда не появляются в виде простого текста, за исключением короткого времени перед поступлением на специальное оборудование внутри сервера перед перекодировкой с помощью нового ключа. Обработка платежа через кредитную карточку посредством системы CyberCash организована так, что продавец никогда не узнает номер кредитной карточки покупателя, если только банк не решит выдать ему эту информацию. Кроме того, сервер не хранит у себя в памяти эту информацию постоянно. Номер кредитной карточки присутствует там только во время непосредственного выполнения платежной операции. 1.3. Работа с кредитной картой При использовании системы CyberCash для транзакций с применением кредитной карточки, покупателю, решившему произвести покупку, достаточно кликнуть на клавише CyberCash "PAY" панели продавца. Продавец посылает покупателю счет, который содержит информацию о покупке, отображаемую на экране дисплея покупателя. (Смотри описание сообщения PR1). Покупатель добавляет номер своей кредитной карточки и другую информацию путем выбора соответствующих пунктов из списка кредитных карт, зарегистрированных на его CyberCash-персону. Вся эта информация снабжается электронной подписью покупателя, реализуемой посредством программы СyberCash, шифруется, и передается продавцу вместе с хэш-кодом счета. (Смотри описание сообщения CH1.) При получении этого сообщения, продавец добавляет туда информацию авторизации, которая шифруется, снабжается электронной подписью продавца и пересылается серверу CyberCash. (Смотри описание сообщений CM1 & CM2). Сервер CyberCash может аутентифицировать все подписи для подтверждения того, что покупатель и продавец согласились с корректностью счета и правильностью суммы стоимости сделки. Сервер CyberCash переадресует соответствующую информацию в банк, сопровождая ее запросом на производство платежа в пользу продавца, включая его авторизацию. Банк дешифрует и обрабатывает полученную информацию, после чего осуществляет соответствующую операцию с кредитной карточкой. Отклик банка передается серверу CyberCash, который присылает продавцу электронную квитанцию (смотри описание сообщения CM6) часть которой продавец переадресует покупателю (смотри описание сообщения CH2). На этом транзакция завершается. 2. Формат заголовка общего сообщения Версия 0.8 внешнего формата для кодирования сообщений CyberCash описана ниже. Сообщения CyberCash представляют собой стилизованные документы для передачи финансовой информации по Интернет. В то время как существует множество схем передачи данных по Интернет (HTTP, SMTP и прочие), каждая из них привязывается к определенному механизму передачи. Так как сообщения CyberCash могут передаваться через любую из названных сред (да и через некоторые не названные), должна быть обеспечена независимость от механизма обмена. 2.1. Формат сообщения Сообщения CyberCash состоят из следующих компонентов:
В CyberCash сообщении запрещены нулевые символы (значение нуль) или символы, характеризуемые восемью битами. "Двоичные" значения, которые могут содержать такие коды, представляются с помощью base64, описанного в документе RFC-1521. 2.2. Детали формата Заголовок содержит одну строку, которая выглядит следующим образом $$-CyberCash-0.8-$$ Он содержит в себе несколько полей, разделенных символом минус "-"
Номера версии начинаются с 0.7. ".z" опускается, если z = 0. 0.7 и 0.8 являются тестовыми и начальными версиями поставки системы для кредитных карт. 0.9 и 1.0 представляют собой улучшенные версии этой системы. Строка "Extra" используется в безопасной среде так чтобы один компонент мог что-то сообщить другому без существенных издержек. Например, Firewall-сервер может записать здесь "HTTP" или "SMTP", прежде чем переадресовывать сообщение базовому серверу в пределах периметра Firewall. 2.3. Части тела Части тела сообщения (как открытые, так и скрытые) состоят из пар атрибут-значение в формате, который напоминает формат стандартного заголовка почтового сообщения (RFC-822). Однако здесь имеются некоторые трудности. Имена атрибутов начинаются с и в основном состоят из букв и лишь иногда содержат в конце дефис, за которым следует число. Такое завершающее число используется, когда имеется индексированный вектор значений. Имена атрибутов часто называют метками (label). Если метка завершается ":", тогда производится обработка согласно требованиям документа RFC-822. Когда важно наличие завершающего пробела (SP, TAB, LF), все лидирующие пробелы на последующих строках удаляются. Такие строки укорачиваются до 64 символов, не считая завершающего символа. Однако если метка завершается ";", это указывает на поле произвольной формы, где символы начала новой строки и любые лидирующие пробелы после начального пробела, который отмечает продолжение строки, являются существенными. Такие строки не должны разрываться за исключением того, что для исключения проблем обработки, они принудительно ограничиваются 200 символами. Пустые строки игнорируются и не означают изменения режима обработки строк. Другим способом решения проблемы может быть следующее: после обнаружения начальной последовательности $$ в стартовой строке, вы можете обрабатывать любые последующие строки в соответствии с первым символом. Если он является алфавитно-цифровым, это новая метка, которая должна завершаться символами ":" или ";", а это указывает на новую пару метка-значение. Если он является пробелом (SP, TAB, LF или CR), это указывает на продолжение предыдущей строки метки. (Как конкретно обрабатывается продолжение, зависит от завершающего символа метки). Если это "$", то строка должна быть оконечной строкой сообщения. Если это #, тогда это строка комментария и должна игнорироваться. Другие начальные символы не определены. На данный момент программные продукты CyberCash не поддерживают комментариев. 2.4. Открытая часть Открытая часть сообщения включает любые текстовые данные, связанные с финансовой транзакцией, а также информацию, необходимую CyberCash и другим, для того чтобы дешифровать скрытую часть. Она всегда включает поле транзакции, которое представляет собой номер транзакции, сформированный источником запроса, это поле копируется в отклик. Открытая часть всегда включает поле даты, которое представляет собой местную дату и время, переносимые без изменений в соответствующие поля отклика. Во всех случаях кроме начальной регистрации открытая часть содержит ID персоны источника запроса. В сообщениях, подготовленных для сервера, существует киберключ (cyberkey:) поле, которое идентифицирует, какой из общедоступных ключей сервера был использован для шифрования ключа сессии. 2.5. Скрытая часть Скрытая часть сообщения состоит из одного блока символов, представленных в кодировке base64 (смотри RFC-1521). Данные в закрытой секции всегда сначала шифруются, а затем кодируются. Скрытая часть сообщения выделяется метками "opaque" или "merchant-opaque" в зависимости оттого, клиент или продавец зашифровал эти данные. Для сообщений, приходящих на сервер, скрытые данные шифруются согласно алгоритму DES CBC с помощью случайного ключа транзакции, при этом ключ DES шифруется посредством алгоритма RSA с привлечением одного из общедоступных ключей сервера. Зашифрованный с помощью RSA ключ DES размещается в первой части поля, закодированного с помощью base64. Соответствующий исходящий отклик сервера может быть зашифрован с помощью DES с применением ключа транзакции. В этом случае достаточно открытых данных, чтобы идентифицировать транзакцию, а покупатель и продавец имеют ключ транзакции, полученный вместе с входным сообщением. Подпись необязательна в скрытой части сообщения отклика. Знание ключа транзакции является достаточным для аутентификации. Для формирования отклика необходимо знать секретный ключ сервера, чтобы заполучить ключ транзакции. Предполагается, что если кто-то исказил скрытую часть отклика, вероятность того, что это будет незамечено пренебрежимо мала. Кто-то может повредить открытую часть сообщения, но это не окажет никакого воздействие, так как все сообщение будет просто отвергнуто. 2.6. Завершающая часть Завершающая секция служит для выделения конца сообщения. Она содержит несколько полей разделенных "-".
Контрольная сумма передачи вычисляется согласно алгоритму MD5. Номер версии в начальной строке содержит исключительно печатные символы и размещается после второго $$ этой строки и до первого $$ завершающей строки. Заметим, что все пробелы (SP, TAB, LF и CR) не включаются в этот хэш. Терминаторы меток (: или ;) включаются туда, также как любые строки #-комментариев. Заметим также, что опционная символьная строка "Extra" в начальной $-строке в хэш не включается. Основной идеей является обеспечение корректности передачи, избегая зависимости от шлюзов (gateways) или любой обработки, которая может изменить завершающую строку или преобразовать символы табуляции, пробелы или символы разрыва строки. 2.7. Примеры сообщений Простое сообщение от клиента: $$-CyberCash-0.8-$$ GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG Сообщение от продавца: $$-CyberCash-a.b.c-extra-$$ labelx: multiple line C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y 3. Подписи и хэши Входные сообщения-запросы CyberCash обычно имеют подпись всех полей. Эта подпись передается в пределах скрытой части сообщения. Она позволяет серверу аутентифицировать источник сообщения. Сообщения от продавца клиенту, инициализирующие процедуру покупки, имеют поля подписанные продавцом. Эти поля и эта подпись включаются клиентом в скрытую часть сообщения продавцу, так что когда все передается серверу, он может проверить, что клиент получил именно ту информацию, которую ему передал продавец. 3.1. Цифровые подписи Цифровые подписи являются средством аутентификации. В сообщениях CyberCash, они вычисляются с привлечением хэша данных, подлежащих аутентификации, после чего хэш шифруется посредством секретного ключа RSA. Любой, кто владеет соответствующим общедоступным ключом, может дешифровать хэш и сравнить его с хэшем сообщения. Если они совпадают, вы можете быть уверены, что подпись была сформирована хозяином секретного ключа, соответствующего общедоступному ключу, которым вы воспользовались, и что сообщение не было искажено при транспортировке. В системе CyberCash, клиенты, продавцы и сервер имеют пары ключей (общедоступный/секретный). Сохраняя в тайне свой секретный ключ и регистрируя на сервере свой общедоступный ключ (для продавца или клиента), можно обеспечить высокое качество аутентификации с помощью подписи определенных частей сообщения. Цифровая подпись RSA имеет размер практически равный длине используемого модуля. Например, если модуль содержит 768 бит, то двоичная электронная подпись будет содержать столько же бит, что равно 96 байт. В представлении base64 это займет 128 байт. 3.2. Хэш-коды Хэши, используемые в сообщениях CyberCash представляют собой дайджесты сообщений. То есть, некоторое компактное отображение сообщения, которое изменяется неузнаваемо при любых искажениях исходного сообщения. Таким образом, относительно небольшой хэш может использоваться для контроля целостности достаточно большого сообщения. Если вы уверены в аутентичности хэша, и получили сообщение, которое соответствует этому хэшу, вы можете тогда быть уверены, что это оригинальное сообщение. Хэш вычисляется с использованием алгоритма MD5 (смотри RFC-1321) для комбинированного сообщения. Комбинированное сообщение составляется из меток и значений, специфицированных в списке для конкретного хэша. Так как хэш чувствителен к порядку поступающих данных, существенно, чтобы пары метка-значение были сгруппированы в правильной последовательности. До хэширования из текста комбинированного сообщения удаляются все пробелы (SP, TAB, LF и CR) и все коды меньше 32 и больше 127. Таким образом, все формы обозначения начала новой строки, пустые строки, завершающие пробелы и прочее, удаляются. Хэши MD5 имеют по 16 байт. Это означает, что кодировка base64 такого хэша занимает 24 символа (последние два будут всегда заполнителями). 4. Форматы специальных сообщений Далее описывается формат сообщений CyberCash версии 0.8. Предполагается, что читатель знаком с такими терминами как "получатель" (acquirer), "PAN" (первичный номер счета), и т.д., определенными в документе ISO 8583, и назначение валюты (currency designations), как это определено в ISO 4217. Некоторые несущественные поля для упрощения удалены. В последующих примерах сообщений подписи, хэши и шифрованные секции не имеют никакого реального смысла. 4.1. Регистрация персоны и нахождение приложения Первым шагом, который должен сделать клиент, чтобы использовать CyberCash, является регистрация персоны с помощью своего приложения. Это делается с помощью сообщения R1, описанного ниже. Сервер CyberCash откликается сообщением R2. Когда приложение покупателя узнает, что оно устарело, оно может воспользоваться запросом GA1, посылаемым серверу, и получить в отклике GA2 подписанную версию самого себя. 4.1.1. R1 - регистрация Описание: Это исходное сообщение, посылаемое для формирования новой персоны CyberCash. ######################################################### $$-CyberCash-0.8-$$ 4.1.2 R2 - отклик регистрации Это сообщение предоставляет отклик об успехе или неудаче R1. ##################################################################### $$-CyberCash-0.8-$$ transaction: 12312313 date: 19950121100505.nnn opaque: r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8 dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w== $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ ##################################################################### Скрытый ключ. Тот же самый, что и ключ сессии для R1 в случае той же транзакции и того же соединения (ID может отсутствовать). ##################################################################### Содержимое скрытой секции: type: registration-response server-date: 19950121100506.nnn requested-id: MyRequestedCCID response-id: CyberCashHandle >email: myemail@myemailhost.com response-code: success/failure/etc. pubkey: 0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94 swseverity: fatal/warning [отсутствует, если все в порядке] swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя [присутствует только, если имеется SWSeverity]. message; Произвольный текст уведомления об успехе или неудаче. Этот текст должен быть отображен для владельца приложения CyberCash... В принципе текст включает в себя: duplicate-id (дублированный ID), bad-signature (ошибочная подпись) или ill-formed-registration (некорректная регистрация). Объяснение:
4.1.3. GA1 - get-application (получение приложения) Используется CyberApp, чтобы получить обновленную версию. ##################################################################### Объяснение: Может не существовать персоны покупателя и поэтому ID может отсутствовать. Может не быть пары ключей покупателя (общедоступный/секретный) и поэтому не быть подписи. swversion является обязательным, так что сервер мог сказать, что следует возвратить. 4.1.4. GA2 - отклик получения приложения (get-application-response) Возвращает в случае успеха URL копии современного приложения CyberApp или флаг неудачи. ##################################################################### $$-CyberCash-0.8-$$ ##################################################################### type: get-application-response В качестве хэша приложения используется MD5. 4.2. Привязка кредитных карт (Binding Credit Cards) Система CyberCash сконструирована так, чтобы предоставить организации, выпустившей кредитную карту, возможность определить, может ли она использоваться через CyberCash. Покупатель, после регистрации персоны в CyberCash, как это описано выше, может связать каждую кредитную карту по своему желанию с персоной в системе CyberCash. Это делается с помощью сообщения BC1, посылаемого покупателем своему серверу CyberCash, и отклика BC4, приходящего от сервера. 4.2.1. BC1 - подключение кредитной карты (Bind-Credit-card) Это начальное сообщение в процессе установления соответствия между кредитной картой и персоной CyberCash. ##################################################################### $$-CyberCash-0.8-$$ ##################################################################### Содержимое скрытой секции: type: bind-credit-card Объяснение: salt необходимо из-за того, что хэш, запомненный сервером, является менее информативным. Сервер лишь запоминает префикс номера кредитной карты и хэш комбинации номера кредитной карты и salt. Если бы он хэшировал лишь номер кредитной карты, появилась бы возможность выяснить номер кредитной карты путем простого перебора всех возможных номеров. Запись номеров кредитных карт в файлы сервера могут сделать систему весьма уязвимой. 4.2.2. BC4 - отклик подключения кредитной карты (bind-credit-card-response) Отмечает, что процесс подключения кредитной карты завершился. Присылает флаг успеха или неудачи. Пример сообщения: $$-CyberCash-0.8-$$ ##################################################################### Содержимое скрытой секции: type: bind-credit-card-response Все строки card* могут быть спасены в виде единого блока для последующего предоставления в CH.1. card-expiration-date, card-number, card-salt и card-type должны присутствовать всегда. В зависимости от причины неудачи не все поля могут быть представлены в сообщении отклике. 4.3. Сообщения покупателя о покупке, содержащие данные о кредитной карте Вообще, подключение CyberCash к покупке с помощью кредитной карты происходит после того как пользователь определит, что же он, в конце концов, покупает. Когда клиент нажимает клавишу CyberCash "payment", продавец посылает покупателю сообщение PR1 в виде тела типа MIME риложение/cybercash. Если покупатель желает продолжить процедуру, он отвечает продавцу сообщением CH1. Продавец реагирует, послав отклик CH2. В паузе между посылкой CH1 и получением CH2, продавец обычно контактирует с сервером CyberCash посредством сообщений CM*. 4.3.1. PR1 - запрос платежа (payment-request) Это сообщение является первым, которое определено CyberCash в процессе торговой сделки со стороны продавца. Собственно покупка произведена, так как мы собираемся ее оплатить. ##################################################################### $$-CyberCash-0.8-$$ Покупка 4 пар "Rocket Shoes" по цене $39.95 каждая. Общая цена: 164.80 Доставить по адресу: Wily Coyote 1234 South St. Somewhere, VA 12345 Скрытая секция здесь отсутствует. Это сообщение подписывается продавцом, но покупатель не может непосредственно проверить эту подпись. Когда платеж произведен, Покупатель подписывает хэш (полученный непосредственно покупателем) платежа. Если соответствия не будет, CyberCash блокирует платежную операцию. accepts: Программа клиента распознает только одно слово имени карты из поля accepts сообщения PR1. Например, MasterCard url-pay-to указывает, куда следует послать CH1. url-fail и url-success несут информацию о том, где броузер должен искать данные в случае успеха или неудачи. 4.3.2. CH1 - платеж через кредитную карту (credit-card-payment) Это сообщение осуществляет представление кредитной карты для выполнения платежа.
#################################################################### $$-CyberCash-0.8-$$ ##################################################################### meO38aULnoP09VhTS2E56tnuZBRRlGfbwqaleZ9zNnv7YjExJKBFxuaqYTUDEj427HHh 4.3.3. CH2 - отклик оплаты с помощью карты (charge-card-response) Отклик покупателю на CH1-попытку оплатить покупку с помощью кредитной карты. Индицирует успех или неудачу. ##################################################################### $$-CyberCash-0.8-$$ a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh ##################################################################### server-date: 19950121100706.nnn Свободный комментарий причины неудачи или успеха. Этот текст должен быть отображен для покупателя приложением CyberCash. Закрытая секция является опционной, так как сообщение CH1 продавцу может не пройти, из-за неверного идентификатора заказа (order-id), даты, ошибочного идентификатора продавца (merchant-ccid) и т.д.. Таким образом, сервер не может быть вовлечен, так как в данной ситуации не существует безопасного механизма генерации закрытой секции сообщения. Если транзакция осуществляет эту процедуру посредством сервера (через CM*), тогда код отклика на верхнем уровне должен быть зеркальным по отношению к коду-отклику сервера, посланного продавцу. Заметим, что могут быть два сообщения, одно от продавца и одно от сервера. 4.4. Сообщения продавца о покупке, связанные с кредитной картой Продавец представляет покупки через кредитную карту, делает корректировки и выражает предпочтения через последовательность CM*. Вообще, цикл, сопряженный с кредитной картой включает авторизацию для покупки, включение покупки в перечень на оплату и собственно осуществление оплаты. Имеется возможность удалить определенную позицию из перечня или аннулировать всю сделку (смотри раздел 5.1.). Авторизации всегда осуществляется клиентом через отклики-сообщения CM1 или CM2. Если приобретение выполняется получателем (acquirer) или каким-то другим объектом между сервером CyberCash и получателем, это делается посредством сообщений CM3 или CM2 в зависимости от соглашения между продавцом и объектом, осуществляющим приобретение. Возвраты обрабатываются с помощью сообщений CM5. Сообщение CM4 служит для возврата покупки или возврата до оплаты сделки. CM6 является форматом сообщения, используемого для откликов на все другие CM*-сообщения. Последовательности MM* были также применены для оплат, осуществляемых продавцом, как описано в разделе 3.4.7 Современные система оплаты предполагают, что продавец знает номер кредитной карточки. Таким образом, чтобы работать с этими системами, предусмотрены специальные обходные сообщения, которые позволяют снабдить продавца нужной информацией, в противном случае CyberCash делает все, чтобы скрыть номер кредитной карты от продавца. Смотри разделы 3.4.8 и 3.4.9. Это делает получение такой информации контролируемым. Многие современные продавцы работают в режиме "terminal capture", где авторизации получаются продавцом. 4.4.1. CM1 - auth-only (аутентификация) Это сообщение используется продавцом для выполнения операции авторизации кредитной карты покупателя. ##################################################################### $$-CyberCash-0.8-$$ EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb Содержимое скрытой секции продавца: type: auth-only a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5 ##################################################################### Ключ продавца закрытой части генерируется из общедоступного ключа CyberCash, на который указывает merchant-cyberkey. Закрытую часть сообщения покупателя (Opaque) - смотри CH1. ##################################################################### Содержимое закрытой части и подпись: (в точности как в CH1) swversion: 0.8win amount: usd 10.00 card*: [from successful BC4 (includes card-expiration-date, card-number, and card-salt)] Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что закрытая часть сообщения покупателя не была повреждена или заменена. 4.4.2. CM2 - auth-capture Осуществляет авторизацию и вводит сумму оплаты сделки. Сообщение аналогично CM1, хотя и имеет другой код типа. ##################################################################### 4.4.3. Сообщение CM3 - post-auth-capture Сообщение аналогично CM1 за исключением того, что оно имеет другой тип и снабжено полем кода авторизации (которое включено в подпись). ##################################################################### $$-CyberCash-0.8-$$ merchant-transaction: 123123 EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb 6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf ##################################################################### type: post-auth-capture a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh vxyEF1ZHn5Rgmtms3H3t/+UB6RAvZQA1AdddjvlS0H75N1x83FyJuh8V9Ok6t4EUQQZ6 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK ##################################################################### Подпись продавца гарантирует целостность большей части сообщения. Проверка подписи покупателя гарантирует, что закрытая секция сообщения не была повреждена или заменена. 4.4.4. Сообщение об удалении CM4 Аннулирует возврат денег, если сообщение получено до окончательного расчета. Сообщение аналогично сообщению CM1 за исключением того, что оно имеет другой код типа и снабжено полем номера ссылки возврата (retrieval-reference-number field) (которое включается в подпись). ##################################################################### $$-CyberCash-0.8-$$ EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb type: void 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf= swversion: 0.8win 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK 4.4.5. CM5 - возврат Возврат полученного ранее платежа. В реальности оплата отрицательной суммы. Сообщение совпадает с CM1 за исключением поля тип. ##################################################################### 4.4.6. CM6 - отклик на операцию оплаты (charge-action-response) Это квитанция, предоставляемая продавцу в качестве уведомления о выполнении платежной операции. Индицирует успех, неудачу или предоставляет какую-то иную информацию. ##################################################################### $$-CyberCash-0.8-$$ EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb type: charge-action-response 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC Содержимое скрытой секции (покупателя):
4.4.7. Последовательности сообщений MM* Последовательности сообщений CM* представляют собой первичную систему покупок с помощью кредитных карт CyberCash для безопасной обработки денежных оплат клиентами системы. Однако продавцы, которые авторизованы их банком для получения оплаты товаров и услуг, могут также получать оплату по телефону, по почте или наличными. Чтобы исключить для продавца необходимость иметь вторую параллельную систему обработки этих платежей, определены последовательности сообщений MM1 - MM6, которые служат для организации таких менее безопасных транзакций. Сообщения MM* очень похожи на последовательность сообщений CM*, но закрытая секция покупателя на самом деле подписана продавцом, при этом не требуется какого-либо дополнительного CyberCash ID покупателя или ссылки на его кредитную карту. 4.4.8. CD1 - запрос данных о кредитной карте Используется продавцом для получения номера карты и т.д., если нужна информация для разрешения сомнений. ##################################################################### EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC swversion: 0.8win 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK Продавцу может быть нужно знать, какая карта используется, и некоторую другую информацию, для того чтобы разрешить определенные проблемы, возникающие при транзакции. Вся эта информация содержится в исходном сообщении CH1, вложенном в CM1 для реализации транзакции. Если продавец сохраняет CM1 и другую информацию транзакции, то он может послать это CD1-сообщение серверу. Пароль является дополнительным уровнем безопасности, он предназначен для ручного ввода со стороны продавца, чтобы авторизовать какую-то необычную операцию. Сервер запоминает хэш CCID продавца и пароля. 4.4.9. CD2 - отклик на данные кредитной карты Отклик на CD1 с указанием на успешный или нет прием данных о кредитной карте. ##################################################################### $$-CyberCash-0.8-$$ t731/86R72ZLrqHLIf0VG6m3ybvs+dG6K705L8LFKEXgCti0NGjK83CwDsUdiso7U1JP type: card-data-response IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy Сообщение в норме возвращает выбранные поля из дешифрованной закрытой части CH1, в том формате, в каком они были посланы серверу в CD1. 4.5. Прикладные сообщения и уведомления об ошибках Оказалось необходимо ввести в систему CyberCash сообщения номера утилиты, статуса запроса, и специального уведомления об ошибке. Желательно иметь возможность проверять коннективность, с некоторой точностью синхронизовать часы и определять версии протокола и приложения клиента. Это сделано с помощью сообщения P1, посылаемого клиентом серверу и отклика P2, возвращаемого сервером клиенту. Клиенты должны быть способны определить состояние предшествующих транзакций, когда клиент или продавец закрэшился во время сессии или произошла потеря информации в ходе или по завершении транзакции. Определены два сообщения-запроса о транзакции TQ1 и TQ2. Один из них осуществляет запрос, а второй аннулирует транзакцию, если она не завершена. Откликом на оба эти запроса является сообщение TQ3, посылаемое сервером. Так как система работает в режиме запрос-отклик, имеется две ситуации, когда необходимы специальные сообщения об ошибках. Если запрос оказался не интерпретируемым или имеет неизвестный код типа, посылается уведомление об ошибке UNK1. Если отклик оказался не интерпретируемым или имеет неизвестный код типа или имела место какая-то другая ошибка, которая должна быть зафиксирована в журнале событий сервера CyberCash. Клиент или продавец направляют серверу диагностические сообщения DL1 или DL2. 4.5.1. P1 - ping Простая проверка доступности сервера со стороны клиента. Здесь для минимизации избыточности не используется никаких криптографических методов. ##################################################################### id является опционным, так как персона может быть еще не установлена. 4.5.2. P2 - отклик на ping Отклик на ping P1. Для минимизации избыточности здесь не используется никаких криптографических методов. ##################################################################### $$-CyberCash-0.8-$$ $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 4.5.3. TQ1 - запрос транзакции Запрос клиента серверу о состоянии транзакции. ##################################################################### $$-CyberCash-0.8-$$ VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl ##################################################################### type: transaction-query jJfFsKvOxLaV87gxu7lIPet3wIDwh1H2F61reYC9jmUrS6WAtUVFG9aCNuTEBoMixF0X begin-transaction и end-transaction могут совпадать. 4.5.4. TQ2 - аннулирование транзакции Запрос клиента серверу в связи с аннулированием транзакции. ##################################################################### $$-CyberCash-0.8-$$ VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl kD7DEav2uLQIYMtP9gbhYaBUpB2a5whNwnK2eXbbyTCf56F6dl3DIVf7D8Z4WxbY2YZn Запрос аннулирования транзакции (TQ.2) определен для взаимодействия клиента с сервером. Этот запрос позволяет клиенту запросить состояние операции и предотвратить операцию, если она еще не осуществлена. 4.5.5. TQ3 - отклик транзакции (transaction-response) Отклики, генерируемые TQ1 или TQ2 ##################################################################### $$-CyberCash-0.8-$$ eFXRL+H0J5q318M21wRdtcbhu9WCyLysQkeF9oIcjtbstymx343bbt0EAtU1gcJaUKJZ type: transaction-response transaction-1: old-transaction-number Оплата отчета (Report-fee) представляет собой уведомление о том, что данный отчет имеет цену и его предоставление зависит от оплаты. Транзакции с заданным номером может соответствовать несколько транзакций (аутентификация, оплата и т.д.). Термины
4.5.6. UNK1 - неизвестная ошибка Это отклик, который посылается, когда запрос так плох, что вы не можете определить его тип или этот тип не известен. Отклик посылается Продавцом Клиенту или Сервером Продавцу, или Сервером Клиенту. ##################################################################### $$-CyberCash-0.8-$$ 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G Это сообщение посылается в качестве отклика, когда не удается найти или понять тип сообщения. Оно всегда имеет в начале поля типа и unknown-error-message. Любые поля запроса, которые удается распознать, копируются с префиксами "x-" в сообщение UNK1, посылаемое в качестве отклика. Таким образом, если появляется x-opaque, это означает, что в исходном запросе было поле opaque и т.д. Так как покупатель инициирует обмен с продавцом и сервером, а продавец запускает обмен с сервером, это сообщение будет послано только покупателю продавцом или сервером покупателю или продавцу. Оно должно быть записано для отладочных целей. Вам может быть нужно отслеживать отказы обслуживания посредством сообщений UNK1. 4.5.7. DL1 - диагностическая запись Клиентская диагностическая запись о плохом сообщении от продавца или сервера. ##################################################################### $$-CyberCash-0.8-$$ 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G ##################################################################### 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 4.5.8. DL2 - диагностические журнальные записи продавца (merchant-diagnostic-log) Диагностическая запись продавца о плохом сообщении от сервера. ##################################################################### $$-CyberCash-0.8-$$ 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G type: merchant-diagnostic-log 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 Приложение продавца не ждет отклика на это сообщение. Дешифрованное исходное сообщение будет размещено в закрытой части, если только дешифрование произошло успешно. Если шифрование осуществить не удалось, будет послано не дешифрованное сообщение. 4.6. Таблица описанных сообщений C = Приложение Покупателя, M = Приложение Продавца, S = Сервер CyberCash
5. Дальнейшие разработки Список возможностей, которые доступны в системе CyberCash, расширяется. В настоящее время реализована универсальная система расчетов, включающая эффективную пересылку небольших сумм денег, планируются различные дальнейшие улучшения. 5.1. Процесс авторизации кредитной карты и расчета Существует шесть шагов обработки кредитной карты, как это описано ниже. Первые четыре присутствуют всегда, если транзакция завершена. Пятый и шестой являются опционными.
Четвертый шаг (settlement) реализуется исключительно в банковской среде. CyberCash 0.8 формирует сообщения для реализации шагов 1, 1&2, 2, 5 и 6. это справедливо для систем работы с кредитными картами, где данные о сделке накапливаются в банке или в системе продавец-банк. CyberCash 0.8 поддерживает такие системы. Другие системы работы с кредитными картами требуют того, чтобы все данные о сделке хранились у продавца. Такие системы часто называются "терминальными покупками" ("terminal capture"). Это делает операции 2, 5 и 6 внутренними для продавца, но требует сообщений для выполнения операции 3. Такие сообщения о денежных расчетах будут включены в будущие версии CyberCash для приложений продавца и сервера. 6. Соображения безопасности Система CyberCash для работы с кредитными картами версии 0.8 предоставляет достаточную защиту платежных сообщений, как это описано в разделах 1.2, 2.2.4 и 2.2.5. Система не обеспечивает достаточной защиты от нечестного продавца (здесь вне конкуренции протокол SET). Следует не выпускать из внимания ЭВМ, на которых работают различные части системы, в противном случае нельзя добиться приемлемого уровня безопасности.
Ссылки
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.6.2 SET и другие системы осуществления платежей
UP:
4.5.8 Поиск узлов и людей
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
|
4.6 Электронная торговля в Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||
Бурное развитие Интернет во всем мире и в РФ открыло ряд направлений бизнеса: предоставление услуг Интернет, электронная почта, IP-телефония и т.д. На подходе сфера сетевых развлечений и виртуальной реальности, этому способствует впечатляющий прогресс в разработке мультимедиа стандартов и протоколов MPEG-4 и MPEG-7. Банки давно использовали специализированные сети для расчетов, в последнее время они стали осваивать возможности общедоступных сетей. Реклама через Интернет стала высокодоходной деятельностью даже в России. Особое положение в этом ряду занимает электронная коммерция через Интернет. Более года назад был разработан торговый протокол IOTP, который перекрывает почти неограниченный спектр услуг, начиная от торговых сделок и оплаты, вплоть до доставки и послепродажного обслуживания, разработан целый спектр платежных протоколов, что сняло последние технические проблемы на пути внедрения торговли через сети Интернет. Одной из проблем была слабая защищенность транспортировки данных по каналам Интернет. Нельзя сказать, что в этой сфере решены все проблемы, но, тем не менее, за последние годы достигнуты впечатляющие успехи. В основном это связано с разработкой эффективных алгоритмов и программ шифрования (симметричных и асимметричных), аутентификации, электронной подписи, сертификации и безопасных каналов (например, TSL). Электронная торговля бурно развивается, прежде всего, в США, но и в России с несколькими миллионами пользователей Интернет у этого вида бизнеса неплохие шансы уже сегодня. В разделе 15, написанном Сергеем Джужей (выпускником кафедры ТСС МФТИ), приведены примеры практического воплощения подобных проектов. В "МК" за 11-12-2001 появилась заметка "Космонавты сходили по магазинам прямо на орбите", где сообщалось о покупках сделанных космонавтами В. Дежуровым и М. Тюриным с борта международной космической станции. Покупки были осуществлены с помощью виртуальной платежной карты VISA. Понятно, что торговля в космосе не станет в ближайшее время бурно развивающимся бизнесом, это лишь говорит о впечатляющих возможностях новых технологий. В перспективе для торговли через Интернет нет никаких ограничений. Но есть ряд областей, где именно этот вид торговли находится вне конкуренции. Это, прежде всего сфера сетевых развлечений, коммерческой информации, дистанционного обучения, платных консультаций, а также продажа небольших программ, например, антивирусных, программ защиты от SPAM и т.д. В этом случае Интернет позволяет понизить цену для покупателя и издержки для продавца. С протокольной точки зрения здесь есть две задачи: обеспечение необходимого, масштабируемого уровня сервиса и гарантирование достаточно высокой безопасности для всех участников. При этом предполагается, что транспортные проблемы решает стэк протоколов Интернет. Основы электронной коммерции были заложены с появлением кредитных карт. Но настоящий бум возник после широкого внедрения Интернет, когда появилась возможность доступа к этой сети с домашней ЭВМ. Сейчас вряд ли кто-либо из клиентов Интернет в России покупает ЭВМ или даже бытовую технику, не просмотрев соответствующую информацию в сети и не выбрав поставщика с наилучшим предложением. Электронная торговля возникла из рекламы через Интернет. Сначала фирма создавала свой WEB-сервер, где были представлены товары или услуги с указанием их расценок. Позднее через форму HTML стало возможным сделать заказ. Так появились первые Интернет-магазины. Оплата на первом этапе производилась исключительно через кредитные карточки. Но скоро выяснилось, что существуют области, где кредитные карты не оптимальны (речь идет о покупках с ценами, сопоставимыми с одним центом, а себестоимость операции с кредитной картой относительно высока), да и безопасность первых систем оплаты оставляла желать лучшего. Так появились самые разнообразные схемы платежей. За рубежом через Интернет покупаются не только билеты на самолет или в театр, но даже автомобили. Просмотрев предложения в сети, изучив на дисплее интерьер салона и технические параметры, выбрав и оплатив покупку, клиент находит следующим утром ключи от авто в своем почтовом ящике, а саму машину на парковке у дома. Для россиянина это звучит как сказка. Разные торговые системы базируются на удаленном доступе типа telnet (SSH) или на технологии WEB-серверов (SSL). Многим знакома компания, торгующая книгами amazon.com. Появились аналогичные предложения по книгам, CD, видеокассетам и другим мелочам и в России. Прогресс этой ветви бизнеса сдерживается отсутствием развитой системы электронных платежей, да и российская банковская система совершенно не отвечает своему основному назначению. По сложившейся традиции российский банкир считает деньги вкладчика своими, и в соответствии с этой концепцией строит свою финансовую политику. Скажу прямо, я не доверю российскому банкиру и рубля, солидный швейцарский, немецкий или американский банк другое дело. А ведь банковское дело не может существовать без доверия. Основные проблемы торговли через Интернет Проблема доверия не так проста и за рубежом, но уже по иной причине. Программное обеспечение, обслуживающее электронную торговлю и банковские операции, может иметь случайные или преднамеренные ошибки. Достаточно вспомнить банковскую программу, которая при начислении процентов по вкладам всегда округляла результат до цента в меньшую сторону, а разницу (доли цента) переводила на счет автора программы, что при большом числе операций составило многие тысячи долларов. С этой точки зрения желательно, чтобы тексты программ были общедоступны. Но такие программы достаточно сложны, создание их требует больших инвестиций, и по этой причине их тексты обычно составляют коммерческую тайну. А человек должен доверить свои с таким трудом заработанные деньги этой программе. Согласитесь, что это психологически не так просто. По этой причине верификация и сертификация таких программ выступает на лидирующие позиции. Эти и многие другие обстоятельства, безусловно, тормозят развитие электронной торговли, но остановить прогресс в этой области даже они не в силах. Электронная коммерция базируется на определенном уровне доверия, риска и надежности, так как получение товара или услуги разнесено по времени с получением денег или платежного документа. Для того чтобы сделка состоялась, партнеры должны быть уверены, что вероятность риска находится на приемлемо низком уровне, а возможная потеря по недобросовестной сделке должна перекрываться прибылью от остальных сделок. На этом принципе существует Интернет-торговля дешевыми товарами - ковриками для мыши или небольшими программами (цена товара или услуги не более 10-30 долларов США). Впрочем, и это относится не к РФ, где царствует предоплата, так как продавец не без основания считает, что вероятность недобросовестности клиента достаточно велика. Все это создает большие неудобства для честных покупателей и ограничивает объемы продаж. Все действующие системы Интернет-магазинов в РФ базируются на доставке и наличной оплате или на различных схемах предоплаты. Не трудно видеть, что эта жуликоватость наносит в конечном итоге ущерб развитию экономики, от которого страдают все граждане. Мне представляется даже, что постепенное внедрение электронной торговли позволит постепенно поменять жизненную философию широкого слоя вовлеченного в этот процесс населения, я уже не говорю о характере самого бизнеса. Так как современный бизнес повсеместно базируется на использовании вычислительной техники (ЭВМ, электронные кассовые аппараты, банкоматы и пр.), внедрение электронной коммерции является естественным процессом. Любая современная торговая фирма имеет уже работающую систему склад-магазин, учитывающую наличие запасов, объемы продаж по конкретным позициям, что повышает эффективность и позволяет проконтролировать действенность рекламы. А это еще одно приложение Интернет. Вместо широковещательного навязывания всем детских подгузников можно перейти к адресной рекламе. Я страдаю от спама (нелегальная рассылка различных коммерческих, а часто и откровенно мошеннических предложений), но готов получать время от времени информацию о результатах испытаний различных компонентов вычислительной техники и сетевого оборудования (позитивным примером такого рода рекламы можно считать сервер www.tolly.com ). Рекламный бизнес через Интернет в США только в 1995 году принес 55 миллионов долларов, сейчас эти объемы превзойдены более чем на порядок.Интернет с его TCP/IP транспортом не может считаться безопасным. По этой причине разработки последних лет были ориентированы на решение этой проблемы. Разработаны протоколы STT (Secure Transaction Technology), SSL, TLS, L2TP, SHTTP, SEPP (Secure Electronic Payment Protocol) и, наконец, SET (Secure Electronic Transactions), предусмотрены специальные меры и в новом протоколе IPv6. Большинство WEB-серверов используют OS UNIX, где администратор системы (root) имеет привилегии, открывающие ему доступ ко всем каталогам и файлам. Это создает еще один источник угроз. С начала 90-х годов началось развитие электронных платежных средств на основе кредитных карт со встроенными микропроцессорами (Integrated Circuit Card Specifications for Payment Systems). Такие карты обеспечивают более высокий уровень безопасности, так как могут предложить надежную аутентификацию самой карты и ее владельца. Процессор может использовать записанные в нем индивидуальные ключи шифрования, известные только банку эмитенту карты и/или ее пользователю. Карта имеет 8 внешних контактов (см. раздел 4.5). Стандарт на такие карты описан в документе ISO 7816 (Identification cards - Integrated circuit(s) cards with contacts). Этот стандарт базируется на нескольких более общих стандартах, имеющих отношения к идентификационным картам, - ISO 7810, ISO 7811, ISO 7812 и ISO 7813. Смарт-карта содержит ИС (20х20мм), где на одном кристалле интегрирован 8-битовый процессор, выполняющий все логические и вычислительные операции (10МГц); ROM - память, ориентированная только на чтение, запись в которую производит изготовитель ИС и где хранится операционная система и прикладные программы (16K); EEPROM - ROM с возможностью электрической перезаписи, которая предназначена для записи и хранения балансовых данных и индивидуальной информации владельца карты (8K); RAM> - оперативная память (512 байт); система ввода-вывода (приведенные цифры относятся к карте Mondex). Себестоимость смарт-карты составляет около 5$. Можно быть уверенным, что приведенные цифры к моменту публикации устареют. Карта является объектом, с которой злоумышленник может экспериментировать неограниченно долго с привлечением любой техники. Изготовление карты и запись в нее информации производится различными участниками. Разработано ряд дополнительных мер для поднятия уровня безопасности. Код программ в ROM является невидимым, тестовые контакты после контроля содержимого карты дезактивируются. Содержимое программ, занесенных в ROM, закрыто и известно только разработчикам. Запись в EEPROM осуществляется с помощью нескольких команд в строго определенном порядке. Как команды, так и их порядок известны только разработчику и производителю карты. Более того, содержимое EEPROM контролируется с помощью специального хэш-кода. Содержимое EEPROM защищено от воздействия UV-излучения и любых других видов электромагнитного излучения. Ключи шифрования заносятся на карту в процессе персонализации и не могут быть считаны потом. Никакие тексты каких-либо программ никогда не публикуются. Считается, что спецификация для смарт-карт в части безопасности будет в будущем пересмотрена. Объединение лидеров в этой области - Europay, MasterCard и VISA разработало спецификацию EMV (по первым буквам фирм участниц; декабрь 1993 года, в 1995-96 опубликованы улучшенные версии). Серьезным ограничением в этой области является отсутствие единого международного стандарта. За последние годы разработано много различных систем выполнения платежей: ASH, Achex, BankNet, BidPay, BillPoint, BIPS, CAFE, Cartio, CashBox, CyberCash, DebitNet, DigiCash, DigiGold, eCash, E-gold, EMV, Gmoney, HashCash, iBill, IPAY, iPIN, Kagi, MagnaCash, Mondex, PayCash, PayPal, PayWord, PCPay, PocketPass, MicroMint, Millicent, NetCard, NetCash, NetCheque, NetPay, NetChex, Qpass, QuickCommerce, SOX, SET, TeleCheck, Transfer, WebCharge, WebMoney, WiSP, WorldPay, Ziplock и т.д. (смотри, http://ganges.cs.tcd.ie/mepeirce/Project/oninternet.html), которые обеспечивают расчеты в широком диапазоне требований по надежности и безопасности. Каждому уровню цен, товаров или услуг должен соответствовать определенный вид электронных платежей. Первой безопасной сетевой системой платежей была First Virtual (1995 г). Приведенный перечень систем платежей является достаточно случайным и неполным. Из этого списка ряд систем работают в РФ (например, WebMoney Transfer и PayCash). Разработано и используется уже десятки таких систем, которые прокладывают дорогу чисто электронным деньгам. Область использования наличных бумажных и металлических денег постепенно сужается и со временем этот традиционный вид платежей уйдет в историю (см., например, статью "Будущее денег" http://www.businessweek.com/1995/24/b3428001.htm ). Для РФ новые платежные системы, работающие без кредитных карт, особенно привлекательны, так как число граждан России, имеющих такие карты, незначительно. Внедрение электронных денег, решая многие проблемы, ставит ряд новых.
Список таких вопросов можно существенно расширить. Электронные деньги существенно меняют и функции банков, более того некоторые операции банков могут выполняться другими структурами, например, сетевыми сервис-провайдерами или компаниями-разработчиками программного обеспечения. Так, например, MicroSoft через десятки миллионов пользователей Windows может легко захватить заметный сегмент в сфере предоставления кредитов в виде электронных денег. Интернет здесь может использоваться как при покупке через сеть, так и при оплате традиционной (очной) покупки. Схемы взаимодействия участников сделки могут быть весьма замысловатыми, ведь покупатель может быть в одной стране, продавец - в другой, банк покупателя - в третьей, а банк продавца - в четвертой. Учитывая, что в сделке, кроме того, могут участвовать компания, осуществляющая доставку покупки, и фирма, выполняющая обслуживание товара, например мобильного телефона, ситуация еще более осложняется. Понятно, что необходимо определенное юридическое обеспечение подобного рода операций, но уже это выходит за рамки данной книги. Электронная коммерция поменяет современную жизнь также, как Интернет изменил среду общения и доступ к информации. В торговле основную прибыль всегда давала информация (знание конъюнктуры рынка, знание производителей и пр.). Современный этап с его взрывным развитием технологий делает этот фактор решающим. Несколько лет назад я наблюдал, как в книжном магазине в Гамбурге продавали одну книгу. Вещь достаточно ординарная, если бы не одно обстоятельство, - эта книга печаталась и переплеталась в присутствии покупателя. Название я ее забыл, но помню, что автором был американец. Уже здесь видны определенные проблемы. Как проконтролировать тираж, чтобы авторские права не пострадали, как и где начислять налоги на эту деятельность? До недавнего времени программы продавались в коробках, произведенных фирмой разработчиком (практически как книги). Новейшей тенденцией является торговля программами (пока дешевыми) через Интернет. Для этого имеются все средства и предпосылки. Но эта схема порождает немало юридических и коммерческих проблем. Здесь и упомянутая проблема налогов (пока в США торговля через Интернет не облагается налогами), и нарушения авторских прав. Ведь нужно определить, кто должен платить налоги, дилер, продавший программу, или фирма разработчик, а это не безразлично, если они расположены в разных странах. Да и взаимоотношения между дилером и разработчиком нужно как-то урегулировать, так как нужен надежный контроль за проданным количеством копий программы. Где здесь место таможни (пока продавались коробки с программами, были сопроводительные бумаги, на которых можно было после оплаты сбора поставить штамп "Таможня дала добро")? Сходные проблемы ждут разработчиков и продавцов компьютерных игр, музыкальных CD и DVD-дисков, а в перспективе очень многих других товаров. Развитию электронной торговли способствуют широко распространенные системы склад-магазин (смотри рис. 2.1 и 2.2). Здесь склад и магазин могут иметь общего хозяина, а могу принадлежать и различным фирмам. Прямого отношения к электронной торговле эти структуры не имеют, но при их создании решались некоторые проблемы и создавались программы, которые могут найти применение в электронной коммерции.
Рис. 2.1. Простейшая схема системы склад-магазин
Рис. 2.2. Продвинутая схема системы склад-магазин В реальной жизни сервер может размещаться на оптовом складе, который обслуживает сеть магазинов, база данных может быть распределенной и т.д., суть от этого не меняется. В любой из этих схем должна быть решена проблема безопасности и надежности передачи информации, а это роднит эти схемы со схемами электронной торговли. В общем случае взаимоотношения между складом и магазином могут быть исключительно коммерческими, что делает эти объекты субъектами, осуществляющими торговые операции. Взаимоотношения с современным банком в любом случае относится к сфере электронной коммерции. Наличие таких структур заметно стимулирует внедрение электронной торговли, так как эта технология предполагает взаимодействие различных систем распределенных баз данных. В общем случае в электронной коммерции могут быть задействованы 5 субъектов - продавец, покупатель, банкир, агент доставки и агент обслуживания. Взаимодействие этих субъектов и документооборот между ними регламентируется протоколом IOTP. Теперь попытаемся проанализировать, в чем заключаются преимущества и недостатки электронной торговли для покупателя и продавца.
По специфике взаимодействия продавца и покупателя выделяются несколько областей бизнеса. К таким областям относятся взаимодействия клиент-клиент P2P (Person-to-Person), продавец-покупатель B2C (Business-to-Consumer) и бизнесмен-бизнесмен B2B (Business-to-Business). Деление это достаточно условно, один и тот же субъект в одних операциях выступает как покупатель в других как продавец. Схема P2P работает при распродаже старых компонентов ЭВМ, книг, кустарных изделий и пр. их владельцами, при обмене и покупке-продаже различных предметов коллекционерами, а также при оказании услуг по ремонту настройке сложного бытового оборудования или, например, в сфере индивидуального обучения. Более перспективной представляется схема B2C>, именно к этому классу относятся практически все Интернет-магазины. В РФ пару лет назад возник бум создания таких структур. Даже ТВ было привлечено к рекламе некоторых из них. Пожалуй, это было несколько преждевременно. Сохранились лишь несколько книжных магазинов, торговля бытовой техникой, произведениями искусства, лекарствами и т.д.. Пытаются выжить некоторые Интернет-аукционы, которые по своей функции являются, чем-то средним между B2C и P2P. Следует обратить внимание, что почти все они не используют сетевых платежных систем. Во многих случаях отсутствие коммерческого успеха связано с тем, что такие магазины не дают сверхприбылей, но требуют получения лицензий и других начальных инвестиций. Сюда относится и отсутствие достаточного платежеспособного спроса у той части населения, которая знакома с технологиями Интернет и имеет к нему доступ, неразвитая кредитная и банковская системы. В РФ более успешной оказалась область В2В, охватывающая оптовую торговлю медикаментами, металлами, нефтепродуктами, стройматериалами и т.д.. Но даже здесь этот бизнес сильно отличается от аналогичной деятельности, скажем, в США. Как уже отмечалось выше, торговля сопряжена не только с оплатой товара и его получением, но с немалым объемом документов (заказы, счета, чеки, накладные, расписки, платежные поручения и т.д.). В настоящее время специально для торговли через Интернет разработан открытый протокол торговли через Интернет IOTP (Internet Open Trading Protocol). |
|||||||||||||||||||||||||
|
Previous:
4.5.17 Сетевое моделирование
UP:
4.5.8 Поиск узлов и людей
|
|
|
|
5.2 Диагностика на базе ICMP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Безусловно SNMP предоставляет наиболее мощные и универсальные возможности диагностики. Но этот протокол не дает решить все проблемы. Не все объекты в Интернет имею активные SNMP-агенты. Как было описано в разделе Ping, протокол ICMP позволяет проверить доступность пути от машины оператора до любой ЭВМ, включенной в Интернет. При этом может быть измерено время пакета в пути и вероятность потери пакета. Проводя такое зондирование периодически и сравнивая результаты для разных моментов времени и разных путей, можно получить важную диагностическую информацию. Время пакета в пути может стать важным параметром для тестирования внешних каналов, ведь задержка может расти из-за потерь пакетов на некоторых этапах. Потеря пакета может произойти как по пути туда, так и по пути обратно. Кроме того, отсутствие отклика может произойти из-за перегрузки буфера или процессора ЭВМ-адресата. В локальных сетях при нормальных условиях потеря может случиться только из-за переполнения буферов в переключателях или ЭВМ (объекты mac-уровня). Если сеть правильно сконфигурирована, реализуются только так называемые "короткие" столкновения, когда столкновение происходит не позднее, чем при передаче 64-го байта. Но если при построении сети допущены ошибки, возможны более поздние столкновения, что становится дополнительной причиной потери пакетов. Тогда может проявиться зависимость вероятности столкновения от длины пакета. Следует учитывать, что если столкновение зафиксировано передающей стороной до завершения посылки пакета, то потери пакета не произойдет, так как передача будет повторена на физическом уровне. Потеря из-за столкновения может произойти только для короткого пакета при слишком больших задержках в логическом сегменте. Понятно, что вероятность столкновений пропорциональна плотности вероятности потока запросов от активных узлов логического сегмента (зоны столкновений). По этой причине, зондируя определенный удаленный логический сегмент можно оценить вариации загрузки. Более информативным может стать сочетание зондирования с помощью пакетов ICMP и контроль втекающих и вытекающих потоков сегмента посредством SNMP-протокола. При использовании процедуры ping (с необходимыми опциями) для зондирования внешних каналов можно выявить как циклы пакетов, так и осцилляции маршрутов. Протокол ICMP при круглосуточном мониторинге позволяет контролировать активность всех узлов локальной сети. Кроме того, такая программа в случае выхода из строя какого-то сегмента позволяет оперативно локализовать неисправный сетевой элемент (см. рис. 5.2.1). Сканирующая программа должна использовать в качестве исходной информации базу данных всех узлов локальной сети, куда должны быть помещены IP- и MAC-адреса всех сетевых узлов, их имена, географическое положение, фамилия хозяина и другая необходимая информация, например, суммарная задержка от какой-то точки в сети до данной рабочей станции. Результаты работы этой диагностической программы заносится в файлы, доступные для диагностического WWW-сервера. Такие данные упрощают поиск причины в случае аварии, так как позволяют проконтролировать активность в сети накануне появления отказа. Если такая программа одновременно измеряет все основные информационные потоки, она поможет выявить самые слабые участки в сети, выявить источники слишком частых широковещательных запросов. Теоретически это позволяет даже динамически реконфигурировать потоки в локальной сети, устраняя узкие места.
Рис. 5.2.1. Схема, поясняющая диагностические возможности протокола ICMP Пусть диагностическая ЭВМ занимает положение в сети, помеченное буквой D. Сканирующая программа, позволяя проверить доступность любой из ЭВМ, может выявить неисправный вход/выход любого из повторителей, хотя сами эти приборы пассивны и на пакеты ICMP откликов не присылают. Это определяется по наличию или отсутствию отклика от хотя бы одной ЭВМ, подключенной к исследуемому входу/выходу. Так, если ни одна ЭВМ сегмента Б не откликается, то можно сделать вывод, что выход 3 повторителя 2 не исправен (предполагается, что хотя бы одна машина сегмента Б включена). Аналогичным образом можно проверить выходы повторителя 1. Если же не откликаются ЭВМ сегментов А и Б, то весьма вероятен отказ моста. Если же ни одна из ЭВМ, показанных на рисунке, не присылает отклика, а известно, что они включены, то не исправен повторитель 1. Конечно, эту задачу можно решить и с помощью стандартной программы PING, но это займет много больше времени. Администраторы, обслуживающие многомашинные сети, размещенные во многих зданиям, безусловно оценят преимущества сканирующей программы. Сканируя всю сеть периодически в течение суток и регистрируя процент потерь пакетов в сети, можно выявить и неисправные сетевые интерфейсы. Такой интерфейс при включении может портить условия распространения пакетов по сегменту. Обнаружив корреляцию между повышением вероятности потерь пакетов и включением определенной ЭВМ, можно сделать именно такой вывод и позднее независимо исследовать именно этот сетевой интерфейс. Протокол ICMP можно использовать и для измерения размера зоны столкновений, что крайне важно для успешной работы локальной сети, ведь превышение предельного размера зоны приводит к резкому росту числа столкновений. Вычислить размер зоны бывает затруднительно, так как для повторителей и концентраторов довольно часто время задержки не указывается. Разумеется, что оно должно быть меньше предельно допустимого, разрешенного документом 802.3, но кто может дать гарантию? Для решения поставленной задачи следует использовать ICMP пакеты минимальной длины. Программа посылает пакеты ICMP и воспринимает отклики, регистрируя долю потерянных пакетов. Для зондирования выбирается самая удаленная рабочая станция или сервер (см. рис. 5.2.2). Программа должна уметь посылать ICMP-пакеты, не дожидаясь отклика. Пакеты посылаются парами с зазором между ними t. Далее варьируем t и добиваемся максимума вероятности потери пакетов. Зазор t, при котором будет достигнут максимум потерь, соответствует реальному значению задержки, характеризующей зону столкновений для данного логического сегмента сети. Периодическая посылка пакетов слишком сильно перегрузит сеть, именно по этой причине следует периодически посылать пары пакетов. При этом период посылки таких пар должен быть достаточно велик, чтобы исключить влияние процессов восстановления после столкновения (> 1сек).
Рис. 5.2.2. Схема зондирования RTT в данном случае равно 2Т+t, где t - время задержки отклика в зондируемой ЭВМ. Зазор между пакетами t должен быть больше t. Если t больше Т, то точность измерения будет невелика. Можно подумать, что при t ё t вероятность столкновения будет равна 100%, но это не так. В этом случае столкновения не будет, ведь интерфейс обнаружит несущую у себя на входе и передачу не начнет. Передача отклика может начаться не ранее 9,6 мксек после завершения первого пакета-зонда (IPG). Если t < 9,6 мксек, передача отклика начнется через 9,6 мксек, если же больше, то через t. На практике 100% потери за счет столкновений будут реализовываться при t < t < Т+t (при t > 9,6 мксек). При t > t+t столкновения не будет, так как до измерительной машины дойдет пакет от исследуемой ЭВМ и передача не начнется из-за обнаружения интерфейсом несущей в кабельном сегменте. Следует иметь в виду, что при детектировании столкновения обе ЭВМ попытаются через некоторое время повторить попытку. Эта попытка вероятнее всего увенчается успехом, ведь они начнут ее не одновременно. Для извлечения нужных данных надо считывать содержимое регистра интерфейса, где записывается число случаев столкновений. Определив диапазон временных зазоров между пакетами-зондами, при которых происходят столкновения со 100% вероятностью, мы получим значение Т. Здесь требуются достаточно точные часы с разрешающей способностью лучше 10 мксек. Если таких часов нет, можно использовать время исполнения команд, предварительно прокалибровав это время при достаточно большом числе их исполнения. Ниже на рисунке 5.2.3 показан результат круглосуточного мониторинга в сети ГНЦ ИТЭФ. Программа позволяет не только отображать такого рода диаграммы но и измеряет относительные потери для различных сегментов сети (написана Сергеем Тимохиным). Предусмотрена возможность вывода списка машин активных в любой заданный интервал времени. По горизонтали отложено время суток 0-24 часа, а по вертикали - число ЭВМ, присылающих отклики на icmp-запросы. Нетрудно видеть, что днем активных ЭВМ больше, чем ночью. :-)
Рис. 5.2.3. Пример круглосуточного мониторинга активности в сети с использованием ICMP-зондирования Другим примером такого мониторинга могут служить программы, контроля внешних каналов ИТЭФ и связей в пределах локальной сети. Смотри страницы: http://saturn.itep.ru/trace/intern/start.htmи http://saturn.itep.ru/trace/extern/start_trace.htm |
|
Previous:
5.1 Сетевая диагностика с применением протокола SNMP
UP:
5 Диагностика локальных сетей и Интернет
|
|
|
|
5.3 Применение 6-го режима сетевого адаптера для целей диагностики
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Использование 6-го режима работы сетевого интерфейса предоставляет необычные возможности администратору и таит в себе немалые угрозы в случае использования его хакером. Как известно практически любая сетевая карта имеет 6 режимов работы. Обычно она работает в 3-ем режиме, воспринимая все пакеты адресованные ей, а также широковещательные и мультикастинг пакеты. В 6-ом же режиме карта пытается принять все пакеты, следующие по сегменту, вне зависимости от адреса места назначения. Если позволяет загрузка и быстродействие сетевого интерфейса, будут восприняты и обработаны все пакеты, следующие по сегменту, к которому подключена ЭВМ, работающая в 6-ом режиме. Именно по этой причине желательно при осуществлении авторизации использовать шифрованный обмен. В противном случае хакер, чья ЭВМ подключена к сетевому сегменту, может получить все пароли, в том числе и привилегированных пользователей. Если шифрование обмена при авторизации недоступно, привилегированные (root) пользователи должны ограничиться работой через консоль. Выполнение привилегированных операций с удаленной ЭВМ не желательно, так как может привести к раскрытию системного пароля. 6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, Accounting database в случае маршрутизаторов CISCO), но 6-й режим предоставляет большую гибкость и возможности. 6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, accounting database в случае маршрутизаторов Cisco), но 6-й режим предоставляет большую гибкость и возможности. К сожалению, данная методика применима лишь к пакетам, проходящим через сегмент, к которому подключена ЭВМ, работающая в 6-ом режиме (см. рис. 5.3.1).
Рис. 5.3.1. Выделенная ЭВМ может полностью отслеживать трафик из зоны сети "C" и лишь транзитный поток пакетов для зон "A" "B" и "D" (например, из зоны А в зону D). Пакеты внутреннего трафика для зон А, В и D не доступны. |
|
Previous:
5.2 Диагностика на базе ICMP
UP:
5 Диагностика локальных сетей и Интернет
|
|
|
|
5.4 Причины циклов пакетов и осцилляции маршрутов
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Для рядового пользователя информация данного раздела не может представлять никакого интереса. Некоторые продвинутые пользователи иногда могут обратить внимание на то, что программа traceroute начинает (вместо нормального отображения пути до цели) выдавать попеременно имена двух соседних узлов. Это может позабавить, если конечно не влияет на решение пользователем его текущих задач. Но в любом случае вмешаться и исправить что-либо он не в силах. О причинах такого поведения сети можно прочесть в разделах, посвященных вопросам маршрутизации. Начнем с локальных сетей. В разделе о мостах 4.1.1.4, там где говорилось об алгоритме "расширяющееся дерево" отмечалась недопустимость того, чтобы две ЭВМ в локальной сети могли соединяться друг с другом различными путями. Здесь подразумевается соединение через систему мостов, повторителей/концентраторов и переключателей. Такого рода соединение через маршрутизаторы допустимо, но и там следует к этому относиться с определенной осторожностью. Рассмотрим фрагмент сети, изображенный на рис. 5.4.1.
Рис. 5.4.1. Пример ошибочной топологии локальной сети Пакеты от машины 1 через концентратор 1 и 2 попадут в концентратор 2, эти же пакеты попадут туда через мост. В результате возникнет встречное кольцевое движение идентичных пакетов. Кроме того, переключатели и мост попытаются разобраться с этим безобразием и начнут посылать широковешательные пакеты, чтобы выяснить с каким из портов на самом деле связаны эти ЭВМ. Они от рождения убеждены, что одна и та же ЭВМ может быть доступна только через один порт. Таким образом, всплески загрузки сети, особенно широковещательной, должны привлекать внимание администратора. В данном примере, если система переключателей и мостов не поддерживает алгоритма "расширяющееся дерево", администратор сам должен разорвать эту кольцевую структуру. Зацикливание пакетов возможно также при использовании внутреннего протокола маршрутизации IGRP, где некорректный выбор параметра вариация приводит к тому, что система при распределении потоков по нескольким направлениям воспринимает путь "назад", как вполне приемлемый. Еще один вариант циклов пакетов возникает при использовании маршрутов по умолчанию (более детально это описано в разделе, посвященном маршрутизации 4.4.11). Так при наличии канала между сетями А и Б внешние маршрутизаторы этих сетей сконфигурированы так, что в сети А пакет адресованный не А, направляется в Б, а в сети Б все пакеты с местом назначения не Б, направляются сети А. Такая конфигурация возможна и она будет работать нормально до тех пор, пока в одной из сетей не появится пакет с ошибочным адресом, не соответствующем ни сети А, ни Б. Такой пакет будет двигаться между сетями А и Б до тех пор пока не выработает свой ресурс по TTL. Похожие проблемы возникают при реализации, например, протокола маршрутизации RIP (см. раздел 4.4.11.1), что сильно замедляет там процедуру установления равновесного маршрута. Протоколы маршрутизации работают с системами, где имеют место огромные задержки. И как всякая система управления с задержанной обратной связью такие системы склонны к осцилляциям. Допустим некоторый узел, оценив метрику нескольких маршрутов, принял решение перейти на новый маршрут. Если он это сделает, об этом окружающие маршрутизаторы узнают с заметной задержкой и соответствующим образом изменят свои оценки метрик фрагментов пути. Когда (снова с задержкой) исходный маршрутизатор получит информацию об этих оценкам, может случится, что старый маршрут окажется предпочтительнее нового, и все начнется сначала. Рассмотренные в данном разделе относительно экзотические явления (кроме примера из локальных сетей, здесь имеет место не экзотика, а стихийное бедствие) встречаются не так часто, но администратор сети должен принимать в расчет и такие возможности. Любой из упомянутых эффектов может сильно ухудшить эксплуатационные параметры сети, а то и вовсе вывести ее из строя. |
|
Previous:
5.3 Применение 6-го режима сетевого адаптера для целей диагностики
UP:
5 Диагностика локальных сетей и Интернет
|
|
|
||||||||||||||||||||||||||||||||||||
|
5.5 Конфигурирование сетевых систем
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||
|
От корректности конфигурации сети зависит ее эффективная работа, надежность и безопасность. К сожалению набор параметров, определяющих конфигурацию, сильно зависит от используемой операционной системы и конкретного сетевого программного обеспечения. Большинство локальных сетей сегодня строятся вокруг серверов, которые работают под ОС UNIX (если не считать одноранговых сетей MS Windows). По этой причине ниже будут описаны конфигурационные файлы именно этой ОС. Название конфигурационных файлов и их назначения приведены в таблице 5.5.1. Таблица 5.5.1. Конфигурационные файлы
Файл /etc/passwd содержит записи аутентификационных параметров пользователей. Каждая запись содержит 7 полей. В первом поле записано имя пользователя (LOGIN ID) в представлении ASCII. Второе поле содержит зашифрованный пароль пользователя. Шифрование осуществляется с добавлением символов, что делает обратную дешифровку невозможной. Причем одно и то же слово при таком методе может быть зашифровано различным способом. Третье поле является числовым номером пользователя (UID). В четвертом поле записывается код группы пользователей, к который принадлежит данный клиент. Пятое поле содержит комментарий администратора. В шестом поле хранится имя базового каталога пользователя. В заключительном поле записывается имя командного интерпретатора, который будет использоваться по умолчанию. В новейших версиях UNIX файл /etc/passwd содержит только "x" во втором поле записи для каждого пользователя, что указывает на использование файла /etc/shadow, где в зашифрованном виде содержатся пароли пользователей. Доступ к этому файлу имеет только администратор. Информация о членах групп пользователей хранится в файле /etc/group/. Файл /usr/lib/aliases используется для создания почтовых ящиков, которым не соответствуют какие-либо аккоунты. Здесь прописываются псевдонимы, которым система пересылает поступающие почтовые сообщения. Строка переадресации в этом файле имеет форму: В первом случае вся почта приходящая alias переадресуется пользователя с указанным именем. Во втором - всем пользователям, имена которых представлены в списке. Если список не умещается в одной строке, перед вводом "возврата каретки" следует напечатать символ "/". В качестве аккоунтов могут использоваться как локальные так и стандартные почтовые адреса. Для особо
длинных списков можно ввести специальную строку в файл /usr/lib/aliases: Наиболее мощной и по этой причине наиболее опасной возможностью файла псевдонимов является переадресация входной почты программе, указанной в псевдониме. Когда первым символом имени аккоунта в псевдониме является вертикальная черта (|), то управление будет передано программе, чье имя следует за этим символом, а входные почтовые сообщения будут передаваться этой программе, например строка: listserv: "|/usr/local/bin/listserv -l" обеспечит пересылку почты программе listserv, как если бы исполнялась команда cat mailfile|listserv -l. Эта техника используется для интерпретации содержимого поля subject или тела сообщения в качестве команд управления подписными листами. Файл named.boot, который служит для инициализации сервера имен, имеет следующую структуру. Строки, начинающиеся с точки с запятой являются комментариями. Строка sortlist определяет порядок, в котором выдаются адреса сервером, если их число в отклике превышает 1. Запись directory, описывает положение информационных файлов (имя проход/каталога). Строка cashe, служит для инициализации кэша сервера имен с использованием файла named.ca. Этот также как и другие файлы должны находиться в каталоге, указанном в записи directory. Записи primary указывают, в каких файлах размещена информация таблиц соответствия имен и IP-адресов. Последняя запись primary содержит информацию для локальной ЭВМ. В записях secondary специфицируется данные, которые должны считываться с первичного сервера и из локальных файлов. В файле named.local содержится локальный интерфейс обратной связи сервера имен. Файл включает в себя только одну запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первого поля записи задает имя зоны. Четвертое поле этой записи содержит имя первичного сервера имен данного субдомена, а следующее поле хранит имя администратора, ответственного за данный субдомен (его почтовый адрес). Запись SOA включает в себя список из 5 чисел, заключенный в скобки.
Файл /etc/hosts.equiv позволяет составить список ЭВМ, объединенных в группу. Пользователь, находящийся в одной из ЭВМ этой группы, может установить связь с другой, не вводя своего пароля. Понятно, что применение этого метода входа, предоставляя некоторые удобства, создает и определенные угрозы с точки зрения сетевой безопасности. Файл .rhosts, который размещается в корневом каталоге пользователя, позволяет ему описать список ЭВМ, куда он имеет доступ. При этом появляется возможность войти из данной ЭВМ в любую из названных машин без ввода пароля. Замечания об использовании файла hosts.equiv в полном объеме справедливы и в данном случае. Если к ЭВМ подключены модемы, необходимо применение так называемого dialup-пароля. Удаленный пользователь помимо своего ID и пароля должен ввести еще и dialup-пароль, который является общим для всех работающих на данной ЭВМ. Если все три параметра аутентификации корректны, доступ будет разрешен. При ошибке в любом из трех компонентов ЭВМ попросит повторить их ввод, не указывая, где совершена ошибка. Файл /etc/dpasswd является исполняемым и может реализовать ряд опций.
|
||||||||||||||||||||||||||||||||||||
|
Previous:
5.4 Причины циклов пакетов и осцилляции маршрутов
UP:
5 Диагностика локальных сетей и Интернет
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
5 Диагностика локальных сетей и Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Читатели неизбежно делятся на две категории: а. Администраторы сети, которые формируют сетевую среду (подавляющее меньшинство). Вторая категория, в силу своего численного превосходства, способна задать столько вопросов, на которые первая, даже будучи столь же многочисленной, не смогла бы ответить. Вопросы бывают простые, например: "Почему не работает электронная почта?" (хотя известно, что вторые сутки за неуплату обесточен весь вычислительный центр). Бывают и сложные: "Как уменьшить задержку отклика, если канал перегружен?" Число компьютерных сетей увеличивается лавинообразно, растет число больших (>10 ЭВМ) и многопротокольных сетей (Novell, DECnet, TCP/IP, AppleTalk и т.д.). По мере увеличения сети усложняется ее обслуживание и диагностика, с чем сталкивается администратор при первом же отказе. Наиболее сложно диагностировать многосегментные сети, где ЭВМ разбросаны по большому числу помещений, далеко отстоящих друг от друга. По этой причине сетевой администратор должен начинать изучать особенности своей сети уже на фазе ее формирования и готовить себя и сеть к будущему ремонту. При возникновении нештатной ситуации администратор должен суметь ответить на ряд вопросов:
Начинать надо с исчерпывающего документирования аппаратной и программной части сети. Администратор всегда должен иметь под рукой схему сети, отвечающую реальному положению на текущий момент, и подробное описание конфигурации программного обеспечения с указанием всех параметров (физические и IP-адреса всех интерфейсов, маски, имена ЭВМ, маршрутизаторов, значения MTU, MSS, TTL и других системных переменных, типовые значения RTT и других параметров сети, измеренных в разных режимах.). В пределах локальной сети поиск неисправности возможен с помощью временного деления ее на части. По мере интеграции сети в Интернет такие простые меры становятся недостаточными или недопустимыми. Но не следует пренебрегать такими простыми средствами, как отсутствие обрыва или закоротки сетевого кабеля. Нужно помнить, что сопротивление сегмента толстого коаксиального кабеля не должно превышать 5 Ом, тонкого - 10 Ом, а скрученные пары не должны иметь сопротивление больше 11,8 Ом (22AWG) и соответственно 18,8 Ом (24AWG) из расчета на 100 м. Следует помнить, что сетевая диагностика является основой сетевой безопасности. Только администратор, знающий все о том, что происходит в сети, может быть уверен в ее безопасности. Ниже будет предполагаться, что сеть на физическом уровне использует стандарт Ethernet, а для межсетевой связи протокол TCP/IP (Интернет). Этим перечнем разнообразие сетевых сред не исчерпывается, но многие приемы и программные диагностические средства с успехом могут использоваться и в других случаях. Большинство из рассматриваемых программ работают в среде UNIX, но существуют их аналоги и для других ОС. Сложные (дорогостоящие, но весьма эффективные) аппаратно-программные диагностические комплексы здесь не рассматриваются. Проблемы маршрутизации и конфигурирования системы также выходят за рамки данного рассмотрения. В Интернет имеется немало общедоступных специализированных диагностических программных продуктов: Etherfind, Tcpdump (lss:os2warez@merlin.itep.ru ftp.ee.lbl.gov/tcpdump.tar.Z, для SUN или BSD 4.4; ftp.ee.lbl.gov.libpcap.tar.Z), netwatch (windom.ucar.edu), snmpman (http://www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp.eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de /windows/util). Программа tcpdump создана в университете Калифорнии и доступна по адресу ftp.ee.lbl.gov. Эта программа переводит интерфейс ЭВМ в режим приема всех пакетов, пересылаемых по данному сетевому сегменту. Такой режим доступен и для многих интерфейсов IBM/PC (например, популярный NE2000 Eagle, mode=6), но tcpdump на этих машинах не работает. Tcpdump написана на СИ, она отбирает и отображает на экране пакеты, посылаемые и получаемые данным интерфейсом. Критерии отбора могут варьироваться, что позволяет проанализировать выполнение различных сетевых процедур. В качестве параметров при обращении к программе могут использоваться наименования протоколов, номера портов и т.д., например, tcpdump TCP port 25. Существует довольно большое число модификаторов программы (опций). К сожалению для рядовых пользователей программа не доступна - требуются системные привилегии. Описание применения программы можно найти по указанному выше адресу, а также в [10]. Другой полезной служебной программой является sock (socket или sockio). Эта программа способна посылать TCP и UDP пакеты, она может работать в четырех режимах.
Такие средства входят также и в комплекты поставки большинства стандартных сетевых пакетов для ОС MS-DOS, UNIX, Windows NT, VMS и других: ping, tracetoute, netstat, arp, snmpi, dig (venera.isi.edu /pub), hosts, nslookup, ifconfig, ripquery. Перечисленные выше диагностические программы являются необходимым инструментом для отладки программ, передающих и принимающих пакеты. Сводный перечень конфигурационных и диагностических команд набора протоколов TCP/IP представлен в таблице 5.1. Таблица 5.1.
Для того чтобы диагностировать ситуацию в сети, необходимо представлять себе взаимодействие различных ее частей в рамках протоколов TCP/IP и иметь некоторое представление о работе Ethernet [4]. Сети, следующие рекомендациям Интернет, имеют локальный сервер имен (DNS, RFC-1912, -1886, -1713, -1706, -1611-12, -1536-37, -1183, -1101, -1034-35; цифры, напечатанные полужирным шрифтом, соответствуют кодам документов, содержащим описания стандартов), служащий для преобразования символьного имени сетевого объекта в его IP-адрес. Обычно эта машина базируется на ОС UNIX. DNS-сервер обслуживает соответствующую базу данных, которая хранит много другой полезной информации. Многие ЭВМ имеют SNMP-резиденты (RFC-1901-7, -1446-5, -1418-20, -1353, -1270, -1157, -1098), обслуживающие управляющую базу данных MIB (RFC-1792, -1748-49, -1743, -1697, -1573, -1565-66, -1513-14, -1230, -1227, -1212-13), содержимое которой поможет также узнать много интересного о состоянии вашей сети. Сама идеология Интернет предполагает богатую диагностику (протокол ICMP, RFC-1256, 1885, -1788, -792). Протокол ICMP используется в наиболее популярной диагностической программе ping входит в поставку практически всех сетевых пакетов). Возможная форма вызова этой программы имеет вид: ping <имя или адрес ЭВМ или другого объекта> [размер пакета] [число посылок] размер пакета задается в байтах (по умолчанию равно 56). Процедура выполнения ping может быть прервана нажатием клавиш ctrl-C. В различных реализациях программа ping имеет много различных опций, которые позволяют измерять статистические характеристики канала (например, потери), определение задержки в канале (RTT), отображение посылаемых пакетов и получаемых откликов, а также определение маршрута до интересующего объекта. Ping используется для определения доступности сервис-провайдера и т.д. Иногда ping является составной частью более мощной диагностической программы (например, netwatch). Ниже приведен пример использования команды tracetoute, которая во многом эквивалентна ping (но базируется непосредственно на IP, используя соответствующие опции): traceroute kirk.Bond.edu.au (посмотрим, как идут пакеты до этого сервера в Австралии) (IP-адрес=131.244.1.1 узнан, зондирование начинается, допустимо не более 30 шагов) traceroute to kirk.Bond.edu.au (131.244.1.1) 30 hops max, 40 byte packets Цель достигнута за 29 шагов! (Путь бывает и длиннее, но редко). Программа traceroute посылает по три пакета с нарастающими значениями TTL, если отклик на пакет не получен печатается символ *. Большие задержки (RTT) в приведенном примере определяются спутниковыми каналами связи (время распространения сигнала до спутника!). Для того чтобы правильно реагировать на нештатные ситуации, надо хорошо представлять себе, как сеть должна работать в нормальных условиях. Для этого надо изучить сеть, ее топологию, внешние связи, конфигурацию программного обеспечения центральных серверов и периферийных ЭВМ. Следует иметь в виду, что изменение конфигурации является обычно привилегией системного администратора и в любых сомнительных случаях нужно обращаться к нему. Неквалифицированные действия при реконфигурировании системы могут иметь катастрофические последствия. Сетевое оборудование, имеющееся в BSD UNIX-системе, описано в документации intro(4), которая доступна через справочную систему man, например: man - 4 intro | grep Ether (Выделенная строка представляет собой команду, введенную с клавиатуры, следующий за ней текст - отклик ЭВМ на эту команду) Для того чтобы получить дополнительную информацию об этих интерфейсах, можно выдать команду dmesg (или просмотреть файл /usr/adm/messages): dmesg | grep le0 Работа сетевого обеспечения базируется на нескольких резидентных программах (демонах): routed и gated (маршрутизация), named (сервер имен), inetd (Интернет услуги). Перечень демонов базовых услуг представлен в таблице 5.2. Таблица 5.2. Основные TCP/IP демоны
Конфигурация inetd определяется содержимым файла /etc/inetd.conf. Для ознакомления с содержимым файла достаточно с клавиатуры ввести команду: head -16 /etc/inetd.conf
ftp stream tcp nowait root /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd -lio Строки, начинающиеся с символа #, являются комментариями. В данном примере представлена одна информативная строка (их может быть много больше), характеризующая файловый обмен. Каждая строка в этом файле начинается с имени ресурса (в приведенном примере ftp). Далее следует поле типа соединителя (socket): stream (TCP поток байтов); dgram - передача данных в виде UDP-дейтограмм. Следующее поле характеризует протокол, используемый данным видом сервиса (TCP или UDP). За ним идет поле, которое описывает способ реализации процедуры (wait/nowait; для поточных серверов nowait). Следующее поле представляет собой идентификатор пользователя (UID), но обычно пользователем является системный администратор - root. Встречается два исключения. Процедура finger выполняется с UID=nobody или daemon, а uucp использует реальное имя пользователя. За полем uid следует поле сервера (в примере /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd). В это поле заносится полное описание пути к программе-серверу, запускаемой inetd. Завершающим полем является поле аргументы, куда записывается строка, передаваемая программе-серверу. Содержимое файла inetd.conf должно быть предметом особой заботы администратора, так как от содержимого этого файла зависит эффективная работа сети и ее безопасность. Как уже отмечалось выше, одним из важнейших частей любого узла Интернет является сервер имен (DNS). Конфигурация DNS-сервера определяется тремя файлами: named.boot, named.ca и named.local. Зонная информация содержится в файле named.rev, а данные о локальном домене в файле named.hosts. Отладка, контроль и диагностика DNS-сервера осуществляется с использованием программ nslookup (или dig). Рассмотрим пример использования процедуры nslookup (здесь выполнены запросы по серверам имен, по почтовым серверам и по параметрам зоны ответственности): Nslookup (запуск сервера)
Non-authoritative answer:
Authoritative answers can be found from (официальные данные могут быть получены от):
set type=ANY (запрос всей информации)
Authoritative answers can be found from:
...................................
(Параметр preference характеризует степень предпочтения почтового сервера, чем он ниже - тем выше предпочтение.) Authoritative answers can be found from:
set type=SOA (запрос параметров, зоны сервера имен, см. RFC-1034-35)
Authoritative answers can be found from:
Рассмотренный пример показывает, что DNS-сервер весьма важный объект узла, от него зависит скорость обслуживания запросов и надежность системы в целом. Именно по этой причине помимо основного любой узел имеет несколько вторичных DNS-серверов. Программа dig функционально является аналогом nslookup, но в прикладном плане имеет определенные отличия, она снабжена рядом полезных опций (таблица 5.3): Таблица 5.3 Опции программы dig
Ниже приведен пример использования команды dig для сервера имен узла DESY (Гамбург): dig @vxdesy.desy.de ns
;; AUTHORITY RECORDS:
;; ADDITIONAL RECORDS:
;; FROM: ns.itep.ru to SERVER: vxdesy.desy.de 131.169.30.46 Программа ifconfig служит для контроля состояния сетевых интерфейсов, их конфигурирования и проверки. С помощью этой команды интерфейсу присваивается IP-адрес, субсетевая маска и широковещательный адрес. Примером использования ifconfig для получения информации об интерфейсе может служить: ifconfig le0 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> Флаг UP означает, что интерфейс готов к использованию, DOWN указывает на необходимость перевода интерфейса в состояние UP с помощью команды ifconfig le0 up. Если эта команда не проходит, следует проверить соединительный кабель или сам интерфейс. Флаг RUNNING говорит о том, что интерфейс работает. При отсутствии этого флага следует проверить правильность инсталляции. Флаг BROADCAST указывает на то, что интерфейс поддерживает широковещательный режим адресации (MULTICAST - допускает многоадресное обращение). Флаг NOTRAILERS - показывает, что интерфейс не поддерживает trailer-инкапсуляцию (Ethernet). Вторая строка отклика на команду начинается с ключевого слова inet (Интернет) и содержит IP-адрес, маску субсети и широковещательный адрес. На ошибку в задании маски субсети указывает факт доступности удаленных ЭВМ и машин локальной субсети при недоступности ЭВМ соседних субсетей. При неверном задании IP-адреса возможны самые разные ошибки. При неверной сетевой части адреса команда Ping будет вызывать ошибку типа "no answer". Ошибка же в части адреса, характеризующей ЭВМ, может быть не замечена в течение длительного времени, если носителем ошибочного адреса является персональная ЭВМ, обращений к которой извне не происходит. Определенное время можно использовать и чужой IP-адрес. Такого рода ошибки не могут быть выявлены с помощью ifconfig, здесь хорошую службу может оказать программа arp (см. описание протокола в RFC-826). Эта программа позволяет анализировать преобразование IP-адресов в физические (Ethernet). Она имеет несколько полезных опций (возможны вариации для разных реализаций и ОС):
Ниже приведен пример исполнения команды arp, которая печатает имя объекта, его IP- и физический адреса (следует иметь в виду, что содержимое ARP-таблиц изменяется со временем, время хранения записи задается администратором сети): arp -a
Указанием на наличие ошибки в ARP-таблице может служить сообщение о недоступности или неизвестности ЭВМ при выполнении команд типа FTP или telnet. Такие сообщения возможны, например, при использовании одного и того же IP-адреса двумя ЭВМ. Все зависит от того, какая из машин успела "прописаться" в ARP-таблице раньше. Просматривая таблицу, администратор может заметить, что одному и тому же IP-адресу временами соответствуют разные физические адреса. Легальность адреса может быть проверена с помощью содержимого файла /etc/ethers. Первые три байта физического адреса характеризуют производителя интерфейса (см. Assigned Numbers, RFC-1700), что может помочь найти "IP-двойника". Если анализ ARP-таблицы не помог, попробуйте войти в ЭВМ, соответствующую подозрительному адресу, с помощью команды telnet. Если ЭВМ допускает удаленный доступ, характер входного сообщения поможет разобраться, что это за машина. Одной из наиболее информативных команд является netstat (за исчерпывающим описанием опций и методов применения отсылаю к документации на ваше сетевое программное обеспечение). Эта команда может вам дать информацию о состоянии интерфейсов на ЭВМ, где она исполнена: netstat -i
Name - имя интерфейса, если в этом поле стоит *, это означает, что интерфейс в состоянии down; Net/Dest - показывает IP-адрес сети или ЭВМ, куда интерфейс осуществляет доступ; Address - IP-адрес интерфейса; Ipkt - число принятых пакетов; Ierr - число ошибок при приеме пакетов; Opkts - число отправленных пакетов через данный интерфейс, Oerrs - число ошибок при отправке; Collis - число столкновений в сегменте Ethernet, зафиксированных интерфейсом; Queue - длина очереди пакетов, ждущих отправки. Программа nrtstat позволяет ознакомиться и с маршрутной таблицей: netstat -nr Маршрутная таблица
Колонка место назначения указывает на конечную точку маршрута, колонка маршрутизатор - имя маршрутизатора, через который достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора или его адрес. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Флаг "M" указывает на то, что маршрут был изменен с помощью сообщения о переадресации. Флаг <null> говорит о том, что адресат достижим непосредственно. Возможности netstat не ограничиваются локальной сетью или автономной системой, с помощью ее можно получить некоторую информацию об удаленных ЭВМ или маршрутизаторах. Например: netstat -r 194.85.112.34
Это может быть полезно при экспресс диагностике внешних каналов связи, когда простого ping или traceroute оказалось недостаточно. Если возникло подозрение относительно маршрутизации пакетов, можно сначала проверить работает ли программа gated, для этого выдайте команду: ps 'cat /etc/gated.pid' после чего обратитесь к системному администратору :-). Если нужно получить информацию о смонтированных файловых системах, вы можете воспользоваться командой: showmount -e ns (ns - имя ЭВМ) Крайне полезна для контроля конфигурации системы команда host, она имеет много опций и с ее помощью можно узнать о доступных типах услуг, об именах и IP-адресах почтовых серверов и серверов имен, о кодах их предпочтения и т.д.. host -a vitep5
Additional information:
Во второй колонке данной выдачи указано время жизни пакетов (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса. В пятой колонке идут названия серверов, IP-адреса ЭВМ и коды предпочтения (15, 200 и 210). Более подробно о возможностях этой команды можно ознакомиться в [11]. В последнее время появилось несколько комплексных (общедоступных) пакетов диагностики (NetWatch, WS_watch, SNMPMAN, Netguard и др.). Некоторые из этих пакетов позволяют построить графическую модель тестируемой сети, выделяя цветом или с помощью вариации картинок работающие ЭВМ. Программы, использующие протокол SNMP, проверяют наличие посредством специального запроса доступность SNMP-демона, с помощью ICMP-протокола определяют работоспособность ЭВМ, после чего отображают переменные и массивы данных из управляющей базы данных MIB (если эта база имеет уровень доступа public). Это может делаться автоматически или по запросу оператора. SNMP-протокол позволяет мониторировать вариации загрузки отдельных сегментов сети пакетами UDP, TCP, ICMP и т.д., регистрируя количество ошибок по каждому из активных интерфейсов. Для решения этой задачи можно использовать соответствующую программу, которая регулярно опрашивает MIB интересующих вас ЭВМ, а полученные числа заносятся в соответствующий банк данных. При возникновении нештатной ситуации администратор сети может просмотреть вариации потоков в сегментах сети и выявить время и причину сбоя в системе. Аналогичные данные можно получить с помощью программы, переводящей интерфейс Ethernet в режим приема всех пакетов (mode=6). Такая программа допускает получение данных по всем типам пакетов, циркулирующих в данном кабельном сегменте. Введя в программу определенные фильтры (отбор по IP-адресам отправителей, получателей, по широковещательным запросам или определенным протоколам) можно узнать много полезного о своей сети. К сожалению, этот метод пригоден только в отношении логического сегмента, к которому подключена ваша ЭВМ. Такие программы могут использоваться для контроля сетевых ресурсов, если ЭВМ размещена на соответствующем сегменте, что может оказаться актуально в связи с коммерциализацией сетевых услуг. По этой причине метод диагностики через SNMP-резидентов более универсален. Упомянутые в начале программы Tcpdump и Etherfind крайне полезны для отладки программ, работающих с сетевыми пакетами. Они позволяют отображать все входящие и посылаемые пакеты. Следует иметь в виду, что эти программы потенциально опасны с точки зрения несанкционированного доступа и, поэтому их применение часто возможно только для привилегированных пользователей. Работа интерфейса в режиме перехвата всех пакетов также представляет угрозу безопасности сети (возможность получения чужих паролей). С учетом этого обстоятельства должно приветствоваться использование программного обеспечения, где содержимое пакетов терминального обмена подвергается шифрованию-дешифрованию. Определенный интерес может представлять диагностическая программа ttcp, которая позволяет измерять некоторые характеристики TCP- или UDP-обменов между двумя узлами (ftp.sgi.com, каталог sgi/src/ttcp или vgr.brl.mil ftp/pub/ttcp.c). Перечисленные режимы работают в рамках протокола TCP, для исследования процессов, требующих UDP, следует использовать опцию -u. Существует множество других опций, обеспечивающих реализацию самых разнообразных режимов работы (см. [10] и справочные руководства на вашей ЭВМ). Конфигурация сети и режимы ее работы определяются системными переменными, которые задаются администратором сети. Имена этих сетевых переменных для разных ЭВМ и программных пакетов варьируются. Ниже будут перечислены основные переменные, определяющие работу TCP/IP протоколов для SunOS 4.1.3. IPFORWARDING - значение этой константы инициализирует системную переменную ip_forwarding. Если она равна -1, IP-дейтограммы никогда не переадресуются, а переменная уже никогда не меняется. Если же она равна 0 (значение по умолчанию), IP-дейтограммы не переадресуются. Переменная принимает значение 1, когда доступны несколько интерфейсов. При значении константы, равном 1, переадресация всегда разрешена. SUBNETSARELOCAL - константа, определяющая начальное значение переменной ip_subnetsarelocal. Если она равна 1 (по умолчанию), то IP-адрес места назначения с идентификатором сети, идентичным с тем, что имеет ЭВМ- отправитель, считается локальным вне зависимости от идентификатора субсети. Если константа равна нулю, то локальным будет считаться только адрес, принадлежащий данной субсети (при совпадении идентификаторов сети и субсети). IPSENDREDIRECTS - константа, используемая для определения стартового значения переменной ip_sendredirects. Если константа равна 1, (по умолчанию) ЭВМ при выполнении процедуры forward посылает ICMP-сообщения о переадресации. При равенстве нулю ICMP-сообщения не посылаются. DIRECTED_BROADCAST - константа, определяющая начальное значение переменной ip_dirbroadcast. Если константа равна 1 (по умолчанию), получаемые дейтограммы, адрес места назначения которых является широковещательным адресом интерфейса, переадресуются на канальный широковещательный уровень. При равенстве нулю такие дейтограммы ничтожаются. Ряд системных переменных содержится в файле in_proto каталога /usr/kvm/sys/netinet. При изменении этих переменных система должна быть перезагружена. tcp_default_mss значение MSS протокола TCP для нелокальных адресатов, по умолчанию равна 512. tcp_keepidle определяет число 500 мс тактов между посылками запросов о работоспособности. По умолчанию равна 14400 (2 час.). tcp_keepintvl определяет число 500 мс тактов между посылками запросов о работоспособности, когда не получено никакого отклика. По умолчанию эта переменная равна 150 (75сек). tcp_keeplen используется для обеспечения совместимости с ранними версиями (4.2BSD), должна равняться 1. tcp_nodelack при неравенстве нулю требует отправки немедленного отклика (ACK), по умолчанию равна нулю. tcp_recvspace определяет размер входного TCP-буфера и влияет на величину окна. По умолчанию эта переменная равна 4096. tcp_sendspace определяет размер выходного TCP-буфера, по умолчанию равна 4096. tcp_ttl задает значение поля TTL в TCP-сегменте, по умолчанию имеет значение 60. udp_cksum при неравенстве нулю требует вычисления контрольной суммы для отправляемых UDP-дейтограмм и проверки контрольных сумм для получаемых UDP-дейтограмм, если поле контрольной суммы не равно нулю. По умолчанию переменная равна нулю. udp_recvspace определяет размер входного UDP-буфера, по умолчанию равна 18000, что соответствует двум 9000-байтным дейтограммам. udp_sendspace задает объем выходного UDP-буфера, ограничивая предельную длину посылаемой дейтограммы. По умолчанию переменная равна 9000. udp_ttl определяет значение поля TTL для UDP-дейтограмм, значение по умолчанию - 60. Для изменения значений этих переменных необходимо иметь системные привилегии. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
4.6.4 Смарт-карты EMV
UP:
4.5.8 Поиск узлов и людей
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
5.1 Сетевая диагностика с применением протокола SNMP
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Обслуживание и диагностирование больших многосегментных, многопротокольных сетей, размещенных на большой территории, а в некоторых случаях и в нескольких городах (например, корпоративные сети типа Интранет), представляет собой тяжелую проблему. Так как сеть может быть построена с использованием различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол snmp, который служит для целей управления в ISDN, X.25, FDDI, ATM, TCP/IP и других сетях. Протокол SNMP (std15, RFC-1448, -1592, -1901, 1902-1907, 1908-1910) использует управляющую базу данных mib (RFC-1213, -1158, -1792, -1042; std16, std17), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Для того чтобы база данных была доступна, необходимо наличие snmp-демона с режимом свободного доступа (поле community = public). Рассмотрим сеть, изображенную на рис. 4.1.1.
Рис. 4.1.1. Пример диагностируемой сети Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол tcp/ip, возможно применение для целей диагностики протокола icmp (RFC-1256, -1788, -1885, -792). Этот протокол также как и snmp пригоден для диагностики не только локальной сети но и каналов Интернет. Если использовать icmp не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, а при длинных сегментах зарегистрировать ухудшение качества сегмента при подключении слишком большого числа ЭВМ. Такая техника может прогнозировать ухудшение пропускной способности канала при подключении дополнительных ЭВМ. Но применение icmp ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма ограничены. Следует иметь в виду, что в многопротокольных средах структуры MIB могут заметно отличаться, варьируется несколько и формат SNMP-пакетов. В настоящее время существует достаточно большой выбор коммерческих программ сетевой SNMP-диагностики (их цены лежат в диапазоне 5-45 тыс. дол.). Особую ценность представляют аппаратно-программные комплексы (15-55 тыс. дол.), которые способны диагностировать состояние оборудования и кабельных сегментов. К сожалению, для отечественных пользователей они по причине цены практически недоступны. Сеть ИТЭФ, которая была зарегистрирована одной из первых в качестве узла Интернет в 1991 году, в настоящее время содержит более 400 ЭВМ при суммарной длине кабельных сегментов около 10 км и обслуживается 6 сотрудниками. В сети используются протоколы TCP/IP, Novell, Arcnet и др.. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig (venera.isi.edu/pub), hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch (windom.ucar.edu), snmpman (http:// www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp,eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de/windows/util). Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное использование IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств. Не все ЭВМ имеют активные SNMP-резиденты, это происходит по причине экономии оперативной памяти или по соображениям безопасности. Еще меньше snmp-агентов, доступных в режиме public (поле SNMP-пакета community; формат пакетов описан, например, в книге Семенова Ю.А. "Протоколы и ресурсы Интернет", Москва, "Радио и связь", 1996). Но для контроля ситуации достаточно иметь по одному активному SNMP-резиденту на каждом из кабельных сегментов. При этом не обязательно ставить их в общедоступный режим, можно использовать для получения диагностической информации и пароль. При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика и для целей диагностики не все ее записи представляют интерес. При написании нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):
Выбор определялся тем, что именно эти переменные варьируются динамически в течение суток. Ставилась задача исследования временных вариаций потоков в заданном сегменте и выработки критериев для диагностики потенциально опасных ситуаций. Измерения проводились каждые полчаса в течение недели. Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так переменная snmpinbadcommunityuses {snmp 5} может сообщить о попытках несанкционированного доступа к базе mib. Переменные snmpintoobigs {snmp 8}, snmpingenerrs {snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д. полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать, если ipfragfails велико, о неверном выборе MTU. Рассмотрим средние значения некоторых переменных за сутки. Так переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормально. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети, если соотнести эти цифры с входным и выходным потоками пакетов можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток. Такие ошибки возможны из-за всплеска шумов или наводок (например, по сети переменного тока). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результат работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки случилось мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках tcp-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети, чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок, неупомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP-активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.
Рис. 4.1.2. Вариации tcpinsegs и udpindatagrams в течение недели Для защищенных систем доступ к snmp-резиденту в пакетах должно использоваться поле community = паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp-пакетов пароль может быть открыт. При написании таких программ нужно учитывать версии MIB, используемые анализируемыми узлами, а также тот факт, что snmp-отклики могут иметь для разных операционных сред. Рассмотрим, как варьируются некоторые из перечисленных переменных в течении суток и недели. На рис. 4.1.2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый - понедельнику, но уже следующей недели. На рис. 4.1.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность захватывает период от 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last (или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Фрагмент распечатки, выданной программой last на ЭВМ, snmp-резидентом которой пользовалась наша программа, приведен ниже.
Первая колонка содержит имена пользователей, вторая - тип задачи (PTS/n - удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet (PTS). Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Рассмотрев, например, результаты работы программы last и рис. 5.1.3а, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствии сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.
Рис. 5.1.3(а, б). Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts По горизонтальной оси отложено время от начала суток. Кривая, отмеченная треугольниками, соответствует правой шкале диаграммы, это справедливо для всех последующих рисунков. Входной и выходной потоки через данный интерфейс практически равны. На рис. 5.1.4(а,б) показана вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части рис. 5.1.4а (19:00 - 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать, как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора mtu для объектов, участвующих в данном обмене. Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunrea chs и ifinunknownprotos.На рис. 5.1.5(а и б) показаны суточные вариации потоков udp-дейтограмм, а на рис. 5.1.6(а и б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).
Рис. 5.1.4(а,б). Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)
Рис. 5.1.5(а,б). Суточные вариации потоков UDP-дейтограмм.
Рис. 5.1.6(а, б). Суточные вариации потоков TCP-сегментов |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
5 Диагностика локальных сетей и Интернет
UP:
5 Диагностика локальных сетей и Интернет
|
|
|
|
6.2 Виртуальные локальные сети VLAN, Интранет
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Широкое внедрение ИНТРАНЕТ, где группы разбросанных по сети пользователей локальных сетей объединяются друг с другом с помощью виртуальных каналов VLAN (Virtual Local Area Network; http://www.3com.com/nsc/200374.html), потребовало разработки новых протоколов. Архитектура VLAN позволяет эффективно разделять трафик, лучше использовать полосу канала, гарантировать успешную совместную работу сетевого оборудования различных производителей и обеспечить высокую степень безопасности. При этом пакеты следуют между портами в пределах локальной сети. В последнее время для задач построения VLAN разработан стандартный протокол IEEE 802.10 (3-ий сетевой уровень). Этот протокол предполагает, что пакеты VLAN имеют свои идентификаторы, которые и используются для их переключения. Протокол может поддерживать работу 500 пользователей и более. Полное название стандарта - IEEE 802.10 Interoperable LAN/MAN Security (MAN - Metropolitan Area Network - региональная или муниципальная сеть). Стандарт принят в конце 1992 года. Количество VLAN в пределах одной сети практически не ограничено. Протокол позволяет шифровать часть заголовка и информационное поле пакетов. Стандарт ieee 802.10 определяет один протокольный блок данных (PDU), который носит название SDE (Secure Data Exchange) PDU. Заголовок пакета ieee 802.10 имеет внутреннюю и внешнюю секции и показан на рис. 6.2.1.
Рис. 6.2.1 Формат пакета IEEE 802.10 Поле чистый заголовок включает в себя три субполя. MDF (Management Defined Field) является опционным и содержит информацию о способе обработки PDU. Четырехбайтовое субполе said (Security Association Identifier) - идентификатор сетевого объекта (VLAN ID). Субполе 802.10 LSAP (Link Service Access Point) представляет собой код, указывающий принадлежность пакета к протоколу vlan. Предусматривается режим, когда используется только этот заголовок. Защищенный заголовок копирует себе адрес отправителя из mac-заголовка (MAC - Media Access Control), что повышает надежность. Поле ICV (Integrity Check Value) - служит для защиты пакета от несанкционированной модификации. Для управления VLAN используется защищенная управляющая база данных SMIB(security management information base). Наличие VLAN ID (said) в пакете выделяет его из общего потока и переправляет на опорную магистраль, через которую и осуществляется доставка конечному адресату. Размер поля data определяется физической сетевой средой. Благодаря наличию mac-заголовка VLAN-пакеты обрабатываются как обычные сетевые кадры. По этой причине VLAN может работать в сетях TCP/IP (Appletalk или Decnet менее удобны). В среде типа Netbios работа практически невозможна. Сети ATM прозрачны для VLAN. Протокол VLAN поддерживается корпорацией cisco, 3com и др.. Хотя VLAN ориентирован на локальные сети, он может работать и в WAN, но заметно менее эффективно. В последнее время разработано большое число специальных программных средств сетевой безопасности. Среди них Firewall занимает лидирующее положение. В разделе "Повторители, мосты (бриджи), мультиплексоры, переключатели и маршрутизаторы" упоминалась технология виртуальных сетей (vlan). Созданная для целей безопасности эта техника оказалась полезной для структуризации локальных сетей, приводящей к улучшению их рабочих характеристик. В настоящее время доступны переключатели, маршрутизаторы и даже концентраторы, поддерживающие виртуальные сети. Виртуальные сети просто необходимы, когда локальная сеть в пределах одного здания совместно используется несколькими фирмами, а несанкционированный доступ к информации желательно ограничить. Принцип построения виртуальной сети показан на рис. 6.2.2.
Рис. 6.2.2. Схема переключателя (или концентратора) с поддержкой VLAN. Для формирования VLAN необходимо устройство, где возможно осуществлять управление тем, какие порты могут соединяться. Например, пусть запрограммирована возможность пересылки пакетов между портами 1, 3 и 6, 2 и 5, а также между портами 4, 7 и 8. Тогда пакет из порта 1 никогда не попадет в порт 2, а из порта 8 в порт 6 и т.д. Таким образом, переключатель как бы разделяется на три независимых переключателя, принадлежащих различным виртуальным сетям. Управление матрицей переключения возможно через подключаемый из вне терминал или удаленным образом с использованием протокола SNMP. Если система переключателей, концентраторов (и возможно маршрутизаторов) запрограммирована корректно, возникнет три независимые виртуальные сети. Данная технология может быть реализована не только в рамках локальной сети. Возможно выделение виртуальной сети в масштабах Интернет. В сущности, идея создания корпоративных сетей в Интернет (ИНТРАНЕТ) является обобщением идей виртуальных сетей на региональные сети. Такая корпоративная сеть должна иметь один шлюз для входа в Интернет. Такой шлюз может выполнять функции Firewall, решая проблемы безопасности корпоративной сети. |
|
Previous:
6.1 Технические средства сетевой безопасности
UP:
6 Сетевая безопасность
|
|
|
||||||||||||||||||||||||
|
6.3 Система Firewall
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||
|
Учитывая важность проблемы защиты, разработана специальная система firewall ("огненная стена"). Система firewall заменяет маршрутизатор или внешний порт сети (gateway). Защищенная часть сети размещается за ним. Пакеты, адресованные Firewall, обрабатываются локально, а не просто переадресуются. Пакеты же, которые адресованы объектам, расположенным за Firewall, не доставляются. По этой причине хакер вынужден иметь дело с системой защиты ЭВМ Firewall. Схема взаимодействия Firewall с локальной сетью и внешним Интернет показана на рис. 6.3.1.
Рис. 6.3.1. Схема Firewall Такая схема проще и надежнее, так как следует заботиться о защите одной машины, а не многих. Экран, маршрутизатор и ЭВМ управления экраном объединены небольшой, незащищенной локальной сетью. Основные операции по защите осуществляются здесь на IP-уровне. Эту схему можно реализовать и на одной ЭВМ, снабженной двумя интерфейсами. При этом через один интерфейс осуществляется связь с Интернет, а через второй - с защищенной сетью. Такая ЭВМ совмещает функции маршрутизатора-шлюза, экрана и управления экраном. Возможна реализация Firewall, показанная на рис 6.3.2. Здесь функция экрана выполняется маршрутизатором.
Рис. 6.3.2. Схема Firewall, где функцию экрана выполняет маршрутизатор В этой схеме доступ из Интернет возможен только к прокси-серверу, ЭВМ из защищенной сети могут получить доступ к Интернет тоже только через прокси-сервер. Ни один пакет посланный из защищенной ЭВМ не может попасть в Интернет и, аналогично, ни один пакет из Интернет не может попасть непосредственно защищенной ЭВМ. Возможны и другие более изощренные схемы, например со вторым "внутренним" Firewall для защиты от внутренних угроз. Недостатки FireWall происходят от ее преимуществ, осложняя доступ извне, система делает трудным и доступ наружу. По этой причине система FireWall должна выполнять функции DNS (сервера имен) для внешнего мира, не выдавая никакой информации об именах или адресах внутренних объектов, функции почтового сервера, поддерживая систему псевдонимов для своих клиентов. Псевдонимы не раскрываются при посылке почтовых сообщений во внешний мир. Служба FTP в системе может и отсутствовать, но если она есть, доступ возможен только в сервер FireWall и из него. Внутренние ЭВМ не могут установить прямую FTP-связь ни с какой ЭВМ из внешнего мира. Процедуры telnet и rlogin возможны только путем входа в сервер FireWall. Услуги типа NFS, rsh, rcp, finger и т.д. не допускаются. Ни одна из ЭВМ в защищенной сети не может быть обнаружена с помощью PING (ICMP) извне. И даже внутри сети будут возможны только определенные виды трафика между строго определенными машинами. Понятно, что в целях безопасности защищенная сеть не может иметь выходов во внешний мир помимо системы экран, в том числе и через модемы. Экран конфигурируется так, чтобы маршрут по умолчанию указывал на защищенную сеть. Экран не принимает и не обрабатывает пакеты внутренних протоколов маршрутизации (например, RIP). ЭВМ из защищенной сети может адресоваться к экрану, но при попытке направить пакет с адресом из внешней сети будет выдан сигнал ошибки, так как маршрут по умолчанию указывает назад в защищенную сеть. Для пользователей защищенной сети создаются специальные входы для FTP (см. библиографию раздела 6 "Сетевая безопасность в Интернет"), telnet и других услуг. При этом не вводится каких-либо ограничений по транспортировке файлов в защищенную сеть и блокируется передача любых файлов из этой сети, даже в случае, когда инициатором FTP-сессии является клиент защищенной сети. Единственные протоколы, которым всегда позволен доступ к ЭВМ Firewall являются SMTP (электронная почта) и NNTP (служба новостей). Внешние клиенты Интернет не могут получить доступа ни к одной из защищенных ЭВМ ни через один из протоколов. Если нужно обеспечить доступ внешним пользователям к каким-то данным или услугам, для этого можно использовать сервер, подключенный к незащищенной части сети (или воспользоваться услугами ЭВМ управления экраном, что нежелательно, так как снижает безопасность). ЭВМ управления экраном может быть сконфигурирована так, чтобы не воспринимать внешние (приходящие не из защищенной сети) запросы типа FTP, telnet и пр., это дополнительно повысит безопасность. Стандартная система защиты здесь часто дополняется программой wrapper (см. раздел 6 "Сетевая безопасность в Интернет"). Немалую пользу может оказать и хорошая система регистрации всех сетевых запросов. Системы FireWall часто используются и в корпоративных сетях, где отдельные части сети удалены друг от друга. В этом случае в качестве дополнительной меры безопасности применяется шифрование пакетов. Система FireWall требует специального программного обеспечения. Следует иметь в виду, что сложная и дорогостоящая система FireWall не защитит от "внутренних" злоумышленников. Нужно тщательно продумать систему защиты модемных каналов (сама система FireWall на них не распространяется, так как это не внешняя часть сети, а просто удаленный терминал). Если требуется дополнительная степень защиты, при авторизации пользователей в защищенной части сети могут использоваться аппаратные средства идентификации, а также шифрование имен и паролей. При выборе той или иной системы Firewall следует учитывать ряд обстоятельств.
Информацию по системам Firewall можно найти по следующим адресам.
|
||||||||||||||||||||||||
|
Previous:
6.2 Виртуальные локальные сети VLAN, Интранет
UP:
6 Сетевая безопасность
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.3.1 Список видов атак, зарегистрированных Network ICE
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Число официально зарегистрированных в мире сетевых инцидентов различного рода возрастает экспоненциально, о чем можно судить по рис. 1. (см. http://www.cert.org/stats/). Этот рост совпадает с ростом числа узлов в интернет, так что процент хулиганов и шизефреников величина похоже инвариантная. Атаки можно разделить на несколько классов:
Список номеров портов для известных троянских коней можно найти в http://www.simovits.com/nyheter9902.html К первому типу относятся и атаки типа SMURF, ICMP flood и TCP SYN flood. ICMP flood не использует эффектов усиления на локальных широковещательных адресах, а работает c адресами типа 255.255.255.255. Здесь следует заметить, что для аналогичных целей хакеры могут использовать и протоколы TCP или UDP.
Рис. 1. Распределение числа официально зарегистрированных сетевых инцидентов по годам. Ниже на рис. 2 показано распределение атак сети ИТЭФ по их разновидностям (Это и последующие два распределения построены студентом МФТИ А.Тарховым).
Рис. 2. На рис.3 показана зависимость числа атак от времени суток, полученная за 19 дней.
Рис. 3. На рис.4 показано распределение атак по доменным зонам. Из распределения видно, что этому занятию предаются чаще всего "жители" больших и комерческих сетей. Хотя нельзя исключить, что именно они являются чаще жертвами хакеров.
Рис. 4.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.3 Система Firewall
UP:
6 Сетевая безопасность
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.4 Системы шифрования
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Проблема сокрытия содержания послания при его транспортировке волновала людей с древних пор. Известно, что еще Цезарь (100-44 годы до нашей эры) при переписке использовал шифр, получивший его имя. В 1518 году Джоанес Тритемиус написал первую книгу по криптографии, где впервые были описаны многоалфавитные подстановочные шифры. Лишь в 1918 году во время первой мировой войны в Германии была применена шифровальная система ADFGVX. Позднее в 1933-45 годах в Германии была разработана и применена первая шифровальная машина (на этом принципе работает система crypt в UNIX). Мощное развитие криптография получила в период второй мировой войны. С этой шифровальной машиной связан и первый успех в области вскрытия сложных шифров. Чаще всего шифруются тексты документов, но в последнее время шифрованию подвергаются и изображения, голосовые данные и даже тексты программ. Шифрование предполагает преобразование исходного текста Т с использованием ключа К в зашифрованный текст t. Симметричные криптосистемы для шифрования и дешифрования используется один и тот же ключ К. Появившиеся в последние годы системы с открытым ключом, осуществляют шифрование с помощью общедоступного ключа, для дешифрования в этом случае необходим секретный ключ, который порождается совместно с открытым. Как шифрование, так и дешифрование может реализоваться программно или аппаратно. При этом должны выполняться определенные требования:
В симметричных криптосистемах могут использоваться одно- или многоалфавитные подстановки (например, одно-алфавитная подстановка Цезаря), при этом производится замена символов исходного текста на другие с использованием достаточно сложных алгоритмов. Многоалфавитные подстановки несравненно более надежны. К числу простых методов шифрования относится способ перестановок символов исходного текста (этот метод эффективен только лишь при достаточно большой длине исходного текста). Множество перестановок символов для текста из N символов равно N!, что до какой-то степени гарантирует надежность процедуры. Несколько большую надежность предлагает метод гаммирования, когда на исходный текст накладывается псевдослучайная последовательность бит, генерируемая на основе ключа шифрования, например, с использованием операции исключающего ИЛИ. Обратное преобразование (дешифрование) выполняется генерацией точно такой же псевдослучайной последовательности и наложением ее на зашифрованной текст. Гаммирование уязвимо для случая, когда злоумышленнику становится известен фрагмент исходного текста. В этих обстоятельствах он без труда восстановит фрагмент псевдослучайной последовательности, а по нему и всю последовательность. Так если достаточно большое число сообщений начинается со слов "Секретно", а в конце ставится дата сообщения, расшифровка становится вопросом времени и терпения. Ключ может быть одноразового и многоразового использования. Одноразовый ключ достаточно большой длины (или бесконечный) может обеспечить сколь угодно высокую надежность, но его использование создает неудобства, связанные с его транспортировкой (ключ должен быть как-то доставлен получателю зашифрованного послания). В табличке 6.4.1 приведен пример использования такого вида ключа. Таблица 6.4.1.
Зашифрованный текст получается здесь из исходного добавлением значения очередного кода ключа (сложение может быть заменено вычитанием или операцией исключающее ИЛИ). Исходный текст в данном случае невозможно восстановить без знания ключа. Примером шифрования с использованием секретного ключа является метод Видженера (Vigenere; www.massconfusion.com/crypto/lecture/method6.html), относящийся к числу много алфавитных подстановок. Здесь берется небольшое целое число m и алфавит после каждой символьной подстановки сдвигается на m символов. Например, для m=4 1. abcdefghijklmnopqrstuvwxyz Ключ = golf (смотри левую вертикальную колонку символов). Исходный текст разбивается на группы по m символов (в рассмотренном случае по 4). Для каждой группы первый символ заменяется соответствующей буквой первого алфавита, вторая - из второго и т.д. Например, фраза "get me out of here please" будет преобразована следующим образом: getm eout ofhe repl ease Наибольшее распространение в последнее время получило блочное шифрование, где последовательность процедур воздействует на блок входного текста. Одним из наиболее известных таких методов стал DES (Data Encryption Standard), который работает с блоками данных по 64 байта (1998 год). Существует четыре режима работы:
Из-за того, что алгоритм DES в настоящее время представляется устаревшим и не обеспечивает достаточной надежности, довольно часто исходный текст последовательно шифруется трижды с помощью различных ключей. Шифрование и дешифрование базируются на использовании ключей. Математически это можно выразить следующим образом (cм. lglwww.epfl.ch/~jkienzle/digital_money/node11.html; www.ee.mtu.edu/courses/ ee465/groupa/overview.html): EK(M) = C Эффективность системы шифрования определяется числом кодовых комбинаций или ключей, которое необходимо перебрать, чтобы прочесть зашифрованный текст. Существует две системы ключей шифрования/дешифрования. Для симметричных алгоритмов предполагается, что ключ дешифрования может быть вычислен по известному ключу шифрования. Оба ключа при этом должны быть секретными (например, система DES). Отправитель и получатель должны знать ключи до начала обмена (эти ключи могут и совпадать). Набор таких ключей может быть достаточно большим и в процессе инициализации осуществляется выбор пары ключей, которые будут использованы в данной сессии. В общем случае могут использоваться довольно большие кодовые таблицы, но такая схема неудобна для многоточечного обмена. Шифры бывают поточными и блочными. В первом случае обработка исходного текста производится побитно или побайтно. Во втором - текст перед обработкой разбивается на блоки. Асимметричные схемы шифрования/дешифрования предполагают существования независимых ключей для шифрования и дешифрования. Причем один не может быть получен из другого и наоборот. В идеале ключ дешифровки не может быть получен из шифрующего ключа за любое разумное время. В этом случае ключ шифрования может быть сделан общедоступным (например, алгоритм RSA). Партнеры до начала коммуникаций должны послать друг другу ключи шифрования КШО и КШП (ключи шифрования отправителя и получателя). Возможность перехвата таких ключей опасности не представляет. Дешифрование выполняется с помощью ключей КДО и КДП, которые образуют пары с КШО и КШП соответственно и формируются совместно. Ключи КШО и КШП обычно пересылаются на фазе инициализации сессии информационного обмена. Шифрование может осуществляться по определенным правилам с помощью таблиц шифрования или ключей. При этом могут использоваться самые разные алгоритмы, в том числе, например, перемещение символов текста определенным образом. За свою историю люди придумали достаточно большое число способов шифрования. Новейшие из них базируются на методиках, заимствованных из теории чисел. По этой причине, прежде чем переходить к следующему разделу, введем некоторые определения. Конгруентность. a конгруентно b по модулю n (a ╨ nb), если при делении на n a и b, получается идентичный остаток. Так 100 ╨ 11 34 (100 и 34 при делении на 11 дают остаток 1) и -6 ╨ 810 (ведь -6 =8(-1)+2). Мы всегда имеем a ╨ nb для некоторого 0 ё bё n-1. Если a ╨ nb и с╨ d, то справедливы равенства: a +c ╨ n(b + d) и ac ╨ nbd Аналогичная процедура для деления не всегда справедлива: 6╨ 1218 но 3N 9. Приведенные здесь и далее математические определения и обоснования взяты из: http://lglwww.epfl.ch/~jkienzle/digital/node20.html. Необходимо также вспомнить о знакомом всем со школьной скамьи понятии наибольшего общего делителя. Для a и b число (a,b) является наибольшим общим делителем, который делит a и b без остатка: (56,98)=14; (76,190)=38 Теорема 1. Для любых a,b существуют целые числа x,y, для которых ax+by=(a,b). В данной статье не приводится доказательств представленных утверждений, их следует искать в книгах по дискретной математике. В этом можно убедиться, решая уравнение 30x+69y=3 путем последовательных упрощающих подстановок (ищется целочисленное решение: 30x+69y=3
Легко видеть, что x"=1, y'=0 является решением окончательного уравнения. Мы можем получить решение исходного уравнения путем обратной подстановки. x'=x"-3y'=1 y=y'-3x'=-3 x=x'-1y=7 Мы можем решить уравнение вида 30x+69y=15 путем умножения нашего решения: y=-15, x=35. Должно быть ясно, что уравнение не будет иметь целочисленного решения, если 15 заменить на что-то некратное (30,69)=3. Все другие целочисленные решения 30x+69y=15 могут быть получены, варьируя первое решение: y=-15+(30/3)t x=35 -(69/3)t для целого t Если мы проделаем то же для произвольного равенства ax+by=(a,b), мы возможно получим один из коэффициентов равным нулю, а другой - (a,b). В действительности эта процедура представляет собой алгоритм Евклида для нахождения наибольшего общего делителя. Важно то, что этот процесс реализуем на ЭВМ даже в случае, когда a и b имеют несколько сотен значащих цифр. Легко показать, что 600-значное число не потребует более чем 4000 уравнений. Теорема 1 справедлива и для простых чисел.
Во многих криптографических приложениях используется: a a2 a3 . mod p, где a и p целые числа. Оказывается, можно выполнить такие вычисления даже для случая, когда в указанную процедуру вовлечены достаточно большие числа, например: 432678 mod 987. Фокус заключается в том, что берется число и осуществляется возведение в квадрат. 4322 = 186624; 186624 mod 987 = 81; 4324 mod 987 = 812 mod 987 = 639 Вычисления с использованием показателя включают в себя ограниченное число умножений. Если числа содержат несколько сотен цифр, необходимы специальные подпрограммы для выполнения таких вычислений. Рассмотрим последовательность степеней 2n mod 11: 2 4 8 5 10 9 7 3 6 1 Здесь числа от 1 до 10 появляются в виде псевдослучайной последовательности. Теорема 2 Пусть p является простым числом. Существует такое a, что для каждого 1ё b ё p-1, существует такое 1ё x ё p-1, что ax ╨ pb, a не обязательно равно 2. Степени 2 mod 7 равны 2, 4, 1. Далее числа повторяются, а числа 3, 5, или 6 не могут быть получены никогда. Рассмотрим некоторые следствия этой теоремы. Следствие 4. Пусть a соответствует требованиям теоремы 2, тогда ap-1 ╨ p1. Лемма Согласно теореме 2, если
p простое число, существует такое a, при котором равенство ax ╨ pb имеет решение для любого bN 0. Такое значение a называется примитивным корнем p, а x называется дискретным логарифмом b. Получение b при заданных a и x относительно просто, определение же x по a и b заметно сложнее. Многие современные системы шифрования основываются на факте, что никаких эффективных путей вычисления дискретных логарифмов не найдено.
Никакого эффективного метода определения примитивных корней также неизвестно. Однако часто возможно найти примитивные корни в некоторых специальных случаях. Возьмем p=1223. p-1=2*13*47. Согласно лемме, если a не примитивный корень, тогда мы либо имеем a26
, a94
или Легко показать, что если a примитивный корень, ax примитивный корень в том и только том случае, если (x,p-1)=1. В этом примере это означает, что число примитивных корней равно 1222*(1/2)*(12/13)*(46/47)=552 Таким образом, если мы выберем а произвольно, вероятность того, что это будет примитивный корень равна ~.45. Выбирая а наугад и тестируя, можно сравнительно быстро найти примитивный корень. Наиболее современные системы шифрования используют асимметричные алгоритмы с открытым и секретным ключами, где нет проблемы безопасной транспортировки ключа. К числу таких систем относится алгоритм rsa (rivest-shamir-adleman - разработчики этой системы - Рональд Ривест, Ади Шамир и Леонард Адлеман, 1977 год), базирующийся на разложение больших чисел на множители. Другие сходные алгоритмы используют целочисленные логарифмы и вычисление корней уравнений. В отличие от других систем эти позволяют кроме шифрования эффективно идентифицировать отправителя (электронная подпись). К системам с открытым ключом предъявляются следующие требования:
К сожалению, эти алгоритмы достаточно медленно работают. По этой причине они могут использоваться для транспортировки секретных ключей при одном из традиционных методов шифрования-дешифрования. Но следует помнить, что не существует абсолютных мер защиты. На рис.6.4.1. показан способ нарушения конфиденциальности в системах с двухключевой схемой шифрования.
Рис. 6.4.1. Если хакер умудрится вставить свою ЭВМ в разрыв канала, соединяющего субъектов А и В, у него появляется возможность перехватывать в том числе и шифрованные сообщения. Пусть субъект А сформировал пару ключей К1А и К2А (ключ с индексом 2 является секретным), аналогичную пару ключей сгенерировал субъект В (К1В и К2В ). Хакер же тем временем подготовил две пары ключей (К1ХА:К2ХА и К1ХВ:К2ХВ ). Когда субъект А пошлет открытый ключ К1А субъекту В, хакер его подменит ключом К1ХА . Аналогичную процедуру он проделает с ключом К1В, посланным от В к А. Теперь сообщение А к В, зашифрованное с помощью ключа К1ХА будет послано В. Хакер его перехватывает, дешифрует с помощью ключа К2ХА, шифрует с помощью ключа К1ХВ и посылает В. Субъект В, получив послание, дешифрует его с помощью "секретного" ключа К2ХВ, полученного от хакера (о чем он, естественно, не подозревает). Аналогичная процедура будет проведена и при посылки сообщения от В к А. В сущности единственным параметром который изменится существенным образом будет время доставки сообщения, так как это время будет включать дешифровку и повторную шифровку сообщения. Но при использовании быстродействующей ЭВМ и при работе с традиционной электронной почтой это может оказаться незаметным. Понятно, что между А и В появится дополнительный шаг (hop). Но и это может быть легко замаскировано под прокси сервер или Firewall. Решить эту проблему можно путем пересылки открытого ключа своему партнеру по какому-то альтернативному каналу или сверки его по телефону. Полезную информацию по системам шифрования можно получить на следующих серверах:
www.cs.hut.fi/crypto/
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.3.1 Список видов атак, зарегистрированных Network ICE
UP:
6 Сетевая безопасность
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.4.1 Алгоритм DES
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Стандарт шифрования DES (Data Encryption Standard) был разработан в 1970-х годах, он базируется на алгоритме DEA. Исходные идеи алгоритма шифрования данных DEA (data encryption algorithm) были предложены компанией IBM еще в 1960-х годах и базировались на идеях, описанных Клодом Шенноном в 1940-х годах. Первоначально эта методика шифрования называлась lucifer (разработчик Хорст Фейштель, название dea (см. http/:snoopy.falkor.gen.nz/~rae/des.html) она получила лишь в 1976 году. Lucifer был первым блочным алгоритмом шифрования, он использовал блоки размером 128 бит и 128-битовый ключ. По существу этот алгоритм являлся прототипом DEA. В 1986 в Японии (NIT) разработан алгоритм FEAL(Fast data Encipherment ALgorithm), предназначенный для использования в факсах, модемах и телефонах (длина ключа до 128 бит). Существует и ряд других разработок. DEA (ANSI x3.92-1981; www.cryptosoft.com/html/fips46-2.htm) оперирует с блоками данных размером 64 бита и использует ключ длиной 56 бит. Такая длина ключа соответствует 1017 комбинаций, что обеспечивало до недавнего времени достаточный уровень безопасности. В дальнейшем можно ожидать расширения ключа до 64 бит (например, LOKI) или вообще замены DES другим стандартом. Входной блок данных, состоящий из 64 бит, преобразуется в выходной блок идентичной длины. Ключ шифрования должен быть известен, как отправляющей так и принимающей сторонам. В алгоритме широко используются перестановки битов текста. Вводится функция f, которая работает с 32-разрядными словами исходного текста (А) и использует в качестве параметра 48-разрядный ключ (J). Схеме работы функции f показана на рис. 6.4.1.1. Сначала 32 входные разряда расширяются до 48, при этом некоторые разряды повторяются. Схема этого расширения показана ниже (номера соответствуют номерам бит исходного 32-разрядного кода). 32 1 2 3 4 5 Для полученного 48-разрядного кода и ключа выполняется операция исключающее ИЛИ (XOR). Результирующий 48-разрядный код преобразуется в 32-разрядный с помощью S-матриц. На выходе S-матриц осуществляется перестановка согласно схеме показанной ниже (числа представляют собой порядковые номера бит). 16 7 20 21
Рис. 6.4.1.1. Алгоритм работы функции f Преобразование начинается с перестановки бит (IP - Initial Permutation) в 64-разрядном блоке исходных данных. 58-ой бит становится первым, 50-ый - вторым и т.д. Схема перестановки битов показана ниже. 58 50 42 34 26 18 10 2 Полученный блок делится на две 32-разрядные части L0 и R0. Далее 16 раз повторяются следующие 4 процедуры:
Пусть A=Li, а J - преобразованный ключ. С помощью функции f(A,J) генерируется 32-разрядный выходной код. Структурная схема реализации алгоритма dea показана на рис. 6.4.1.2.
Рис. 6.4.1.2. Структурная схема реализации алгоритма DEA Инверсная перестановка разрядов предполагает следующее размещение 64 бит зашифрованных данных (первым битом становится 40-ой, вторым 8-ой и т.д.). 40 8 48 16 56 24 64 32 S-матрицы представляют собой таблицы содержащие 4-ряда и 16 столбцов. Матрица S(1) представлена ниже (эта матрица, также как и те, что приведены в ссылке 2, являются рекомендуемыми). No. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Исходный 48-разрядный код делится на 8 групп по 6 разрядов. Первый и последний разряд в группе используется в качестве адреса строки, а средние 4 разряда - в качестве адреса столбца. В результате каждые 6 бит кода преобразуются в 4 бита, а весь 48-разрядный код в 32-разрядный (для этого нужно 8 S-матриц). Существуют разработки, позволяющие выполнять шифрование в рамках стандарта DES аппаратным образом, что обеспечивает довольно высокое быстродействие. Преобразования ключей Kn (n=1,.,16; Kn = KS(n,key), где n - номер итерации) осуществляются согласно алгоритму, показанному на рис. 6.4.1.3.
Рис. 6.4.1.3. Алгоритм вычисления последовательности ключей Kn Для описания алгоритма вычисления ключей Kn (функция KS) достаточно определить структуру "Выбора 1" и "Выбора 2", а также задать схему сдвигов влево (табл. 6.4.1.2). "Выбора 1" и "Выбора 2" представляют собой перестановки битов ключа (PC-1 и PC-2; табл. 6.4.1.1). При необходимости биты 8, 16,., 64 могут использоваться для контроля четности. Для вычисления очередного значения ключа таблица делится на две части С0 и D0. В С0 войдут биты 57, 49, 41,., 44 и 36, а в D0 - 63, 55, 47,., 12 и 4. Так как схема сдвигов задана (табл. 6.4.1.2) C1,D1; Cn, Dn и так далее могут быть легко получены из C0 и D0. Так, например, C3 и D3 получаются из C2 и D2 циклическим сдвигом влево на 2 разряда Таблица 6.4.1.1
Таблица 6.4.1.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.4 Системы шифрования
UP:
6 Сетевая безопасность
|
|
|
|
6.4.2 Алгоритм шифрования RSA
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Алгоритм RSA предполагает, что посланное закодированное сообщение может быть прочитано адресатом и только им. В этом алгоритме используется два ключа - открытый и секретный. Данный алгоритм привлекателен также в случае, когда большое число субъектов (N) должно общаться по схеме все-со-всеми. В случае симметричной схемы шифрования каждый из субъектов каким-то образом должен доставить свои ключи всем остальным участникам обмена, при этом суммарное число используемых ключей будет достаточно велико при большом значении N. Применение асимметричного алгоритма требует лишь рассылки открытых ключей всеми участниками, суммарное число ключей равно N. Сообщение представляется в виде числа M. Шифрование осуществляется с помощью общедоступной функции f(M), и только адресату известно, как выполнить операцию f-1 . Адресат выбирает два больших простых (prime) числа p и q, которые делает секретными. Он объявляет n=pq и число d, c (d,p-1)=(d,q-1)=1 (один из возможных способов выполнить это условие, выбрать d больше чем p/2 и q/2). Шифрование производится по формуле: f(M) ╨ Md mod n, где M и f(M) оба ё n-1. Как было показано, может быть вычислено за разумное время, даже если M, d и n содержит весьма большое число знаков. Адресат вычисляет M на основе Md
, используя свое знание p и q. В соответствие со следствием 6, если Исходный текст M получается адресатом из зашифрованного F(M) путем преобразования: M = (F(M))e (mod pq). Здесь как исходный текст, так и зашифрованный рассматриваются как длинные двоичные числа. Аналогично (Md)e ╨ qM, если dc ╨ (q-1)1. e удовлетворяет этим двум условиям, если cd ╨ (p-1) (q-1)1. Теорема 1 гласит, что мы можем позволить e=x, когда x является решением уравнения dx + (p-1)(q-1)y = 1. Так как (Md)e - M делимо на p и q, оно делимо и на pq, следовательно, мы можем определить M, зная Md , вычислив его значение в степени e и определив остаток от деления на pq. Для соблюдения секретности важно, чтобы, зная n, было нельзя вычислить p и q. Если n содержит 100 цифр, подбор шифра связан с перебором ~1050 комбинаций. Данная проблема изучается уже около 100 лет. RSA-алгоритм запатентован (20 сентября 1983, действует до 2000 года). Теоретически можно предположить, что возможно выполнение операции f-1 , не вычисляя p и q. Но в любом случае задача эта не проста и разработчики считают ее трудно факторизуемой. Предположим, что мы имеем зашифрованный текст f(M) и исходный текст M, и мы хотим найти значения p и q. Нетрудно показать, что таких исходных данных для решения задачи недостаточно - надо знать все возможные значения Mi. Проясним использование алгоритма RSA на конкретном примере. Выбираем два простые числа p=7; q=17 (на практике эти числа во много раз длиннее). В этом случае n = p*q будет равно 119. Теперь необходимо выбрать e, выбираем e=5. Следующий шаг связан с формированием числа d так, чтобы d*e=1 mod [(p-1)(q-1)]. d=77 (использован расширенный алгоритм Эвклида). d - секретный ключ, а e и n характеризуют открытый ключ. Пусть текст, который нам нужно зашифровать представляется M=19. С = Memod n. Получаем зашифрованный текст C=66. Этот "текст" может быть послан соответствующему адресату. Получатель дешифрует полученное сообщение, используя М= Cdmod n и C=66. В результате получается M=19. На практике общедоступные ключи могут помещаться в специальную базу данных. При необходимости послать партнеру зашифрованное сообщение можно сделать сначала запрос его открытого ключа. Получив его, можно запустить программу шифрации, а результат ее работы послать адресату. На использовании общедоступных ключей базируется и так называемая электронная подпись, которая позволяет однозначно идентифицировать отправителя. Сходные средства могут применяться для предотвращения внесения каких-либо корректив в сообщение на пути от отправителя к получателю. Быстродействующие аппаратные 512-битовые модули могут обеспечить скорость шифрования на уровне 64 кбит в сек. Готовятся ИС, способные выполнять такие операции со скоростью 1 Мбайт/сек. Разумный выбор параметра e позволяет заметно ускорить реализацию алгоритма. |
|
Previous:
6.4.1 Алгоритм DES
UP:
6 Сетевая безопасность
|
|
|
||||||||||||||||
|
6.4.3 Электронная подпись
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||
|
В конце любого письма мы привыкли ставить подпись с тем, чтобы уведомить получателя о том, кто является отправителем данного документа. Кроме того, подпись ответственного лица придает документу юридическую силу. По мере внедрения электронных средств доставки документов (факс и электронная почта) проблема их достоверности обрела крайнюю актуальность. Ведь копирование любой последовательности битов или пикселей не представляет никакой трудности. Современные телекоммуникационные каналы уязвимы для перехвата и искажения пересылаемых документов. Рассмотрим сначала то, от каких действий злоумышленника должна защищать система идентификации.
Решение практически всех этих проблем может быть реализовано с помощью электронной подписи, базирующейся на алгоритме RSA. Рассмотрим принципы, на которых базируется электронная подпись. Пусть имеются секретные коды d, p и q, а также открытые e и n=pq. Пусть также А передает сообщение DATA адресату Б. Электронная подпись отправителя А базируется на его секретном ключе и открытом ключе получателя Б. Сначала отправитель с помощью хэш-функции (SHS - Secure Hash Standard; www.nist.gov/itl/div897/pubs/fip180-1.htp) генерирует дайджест своего сообщения длиной 160 бит (5 слов). Затем с помощью своего секретного ключа он формирует электронную подпись. При этом А не может отказаться от того, что именно он послал сообщение, так как только он знает свой секретный ключ. Электронную подпись нельзя использовать повторно и подписанный документ нельзя модифицировать, так как любые модификации неизбежно изменят его дайджест, а, следовательно, и электронную подпись. Получатель с помощью открытого ключа дешифрует код электронной подписи, а затем с использованием дайджеста проверяет ее корректность. Национальный институт стандартов США принял стандарт DSS (Digital Signature Standard; www.itl.nist.gov/div897/pubs/fip198.htm), в основу которого легли алгоритмы Эль-Гамаля и RSA. Рассмотрим алгоритмы вычисления дайджеста сообщения, электронной подписи и идентификации отправителя. Начнем с алгоритма SHA (Secure Hash Algorithm). Сначала сообщение разбивается на блоки длиной 512 бит. Если длина сообщения не кратна 512, к последнему блоку приписывается справа 1, после чего он дополняется нулями до 512 бит. В конец последнего блока записывается код длины сообщения. В результате сообщение приобретает вид n 16-разрядных двоичных слов M1,M2,.,Mn. M1 содержит первый символ. Алгоритм SHA использует 80 логических функций f0,f1,.,f79, которые производят операции над тремя 32-разрядными словами (B,C,D):
В алгоритме используется также 80 констант K1,K2,., K79:
Вводится 5 переменных Hi инициализируемых как: H0 = 67452301 Делим массив M на группы из 16 слов W0, W1,.,W15 (W0 самое левое слово). Для t = 16 - 79 wt = S1(Wt-3 XOR Wt-8 XOR Wt-14 XOR Wt-16) Ak означает операцию циклического сдвига влево на k разрядов. Пусть теперь A = H0, B = H1, C = H2, D = H3, E = H4. В результате обработки массива М будет получено 5 слов H0, H1, H2, H3, H4 с общей длиной 160 бит, которые и образуют дайджест сообщения. Полученная кодовая последовательность с высокой степенью уникальности характеризует сообщение. Любое редактирование сообщения практически неизбежно приведет к изменению дайджеста. Поскольку алгоритм вычисления дайджеста общеизвестен, он не может рассматриваться как гарантия предотвращения модификации сообщения. Смысл вычисления дайджеста заключается в уменьшении объема данных, подлежащих шифрованию. Для того чтобы превратить дайджест в электронную подпись надо воспользоваться секретным ключом. Схема реализации алгоритма DSA (Digital Signature Standard) показана на рис. 6.4.3.1.
Рис. 6.4.3.1. Схема вычисления и верификации электронной подписи (DSA) DSA использует следующие параметры (www.itl.nist.gov/div897/pubs/fip186.htm): p - простое число, которое при 512ё L
ё 1024 удовлетворяет условию 2L-1 < p < 2L, L кратно 64. k равно случайному или псевдослучайному целому числу, для которого 0 < k < q. Целые p, q и g могут быть общедоступными и использоваться группой пользователей. Секретным и открытым ключами являются х и у, соответственно. Параметры х и k используются только для формирования электронной цифровой подписи и должны храниться в секрете. Параметр k генерируется для каждой подписи. Подпись сообщения M представляет собой два числа r и s, вычисленные согласно формулам: r = (gk mod p) mod q SHA(M) - представляет собой дайджест сообщения M (160-битовая строка). После вычисления r и s следует проверить, не равно ли одно из них нулю. Для верификации электронной подписи проверяющая сторона должна иметь параметры p, q и g, а также открытый ключ отправителя (подписанта) y. Пусть M`, r` и s` представляют собой полученное сообщение и электронную подпись. Получатель начинает верификацию с проверки условия 0 < r` < q и 0 < s` < q. Если хотя бы одно из условий не выполнено, электронная подпись некорректна. Далее производится вычисление: w = (s`)-1 mod q Если v = r`, верификация подписи завершилась успешно и получатель может с высокой вероятностью быть уверен, что он получил сообщение от партнера, владеющего секретным ключом х, соответствующим открытому ключу у. Если же v не равно r`, то сообщение было модифицировано или подписано самозванцем. В ссылке 3 на предыдущей странице можно найти описание алгоритма нахождения (проверки) простых чисел и генерации псевдослучайных чисел. |
||||||||||||||||
|
Previous:
6.4.2 Алгоритм шифрования RSA
UP:
6 Сетевая безопасность
|
|
|
|
6.4.4 Безопасная почта PGP
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
В связи с массовым внедрением электронной почты и, в перспективе, полным вытеснением традиционной, проблема конфиденциальности доставки электронных сообщений становится крайне актуальной. В последние годы разработано несколько почтовых систем, предоставляющих эту конфиденциальность. Примером такой системы может служить PEM - почта с улучшенной защитой от несанкционированного доступа (PEM - Privacy Enhanced Mail, RFC-1421, 1422, 1423 и 1424). Первая разработка в области электронной криптографии относится к 1976 году, когда была создана система Диффи-Хелмана (Diffie-Hellman) с общедоступным шифровальным ключом. Позднее, в 1977 году Ривестом, Шамиром и Адлеманом была предложена двух ключевая система RSA (Rivest-Shamir-Adleman). Эта разработка была выполнена под патронажем Национального научного фонда США (NSF) и в 1983 году запатентована в США. PEM является стандартом Интернет для улучшения защищенности электронной почты. PEM использует криптографическую технику для обеспечения контроля правильности передачи сообщения, защищенности и идентификации. Стандарт позволяет вам знать, что полученное сообщение не было изменено, быть уверенным, что ваше сообщение будет получено именно тем и только тем, кому было адресовано. Предусмотрена интеграция MIME (Multipurpose Internet Mail Extensions) и PEM. Существует подписной лист (LISTSERV) для пользователей, интересующихся вопросами развития и использования PEM. Для подписки необходимо послать соответствующее сообщение по адресу pem-dev-request@tis.com. Для пользователей PEM имеется еще один подписной лист: tispem-users@tis.com. Для подписки следует направлять заявки по адресу: tispem-users-request@tis.com. С вопросами по использованию TIS/PEM следует обращаться в tispem-support@tis.com. Имеется версия программного обеспечения PEM в свободном доступе, например, TIS/PEM V7.0 (UNIX, только для США и Канады). Эта версия содержит в себе:
Система TIS/PEM доступна через анонимное FTP в США и Канаде по адресу: ftp.tis.com pub/PEM/README; pub/PEM/LICENSE; pub/PEM/BUGS. Файл README содержит дополнительные инструкции по применению PEM. Несравненно большей популярностью пользуется конфиденциальная почтовая система PGP (Pretty Good Privacy - замечательная конфиденциальность). История создания PGP довольно драматична (см. http://www.dcs.ex.ac.uk/~aba/timeline/. Создателем PGP является Фил Циммерман (США, 1991 год). PGP базируется на двух ключевой системе шифрования RSA и алгоритме IDEA (International Data Encryption Algorithm, предложен Ксейа Лайем и Джеймсом Массейем, Швейцария). Творение Циммермана было встречено без энтузиазма Агентством Национальной Безопасности США и против него было возбуждено уголовное дело. Хотя АНБ и могущественно, здравый смысл и закон в данном случае восторжествовали. Что же касается патента на RSA, он не является международным и вся ответственность за использование программ, базирующихся на данном алгоритме, лежит на пользователе (юридически ситуация весьма запутана). В России применение любой системы шифрования (формально даже архивирование!) требует лицензирования. Все правительства любят все держать в тайне, но не любят, когда кто-то пытается хранить в тайне что-то от правительства (даже если это любовные письма; если вы интересуетесь юридической стороной проблемы использования PGP, смотрите в http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm. Чему здесь удивляться, ведь история "черных кабинетов" (в том числе и в России) исчисляется столетиями. PGP версия 2.5 (http://www.ifi.uio.no/~staalesc/PGP ) (и более поздние используют RSAREF 1.0 вместо MPILIB) представляет собой публично доступный (легальный!) пакет электронной почты со встроенной системой шифрования сообщений. Пакет обеспечивает конфиденциальность переписки и пересылки файлов. Конфиденциальность заключается в том, что только лица, кому адресовано послание или файл, смогут его прочесть. PGP поддерживает технологию электронной подписи, гарантирующей получателю, что сообщение пришло именно от вас. Предусмотрен контроль неизменности сообщения в процессе доставки (принцип сходен с идеей CRC). При этом не требуется каких-либо секретных каналов для пересылки ключей кодирования. Именно эта схема являлась до недавнего времени основной. Главный ее недостаток - необходимость транспортировки секретного ключа. PGP использует технику шифрования с общедоступными ключами, совмещая удобства системы кодирования RSA с быстродействием традиционных методов. Существуют коммерческие версии PGP, встроенные в известные текстовые редакторы WORD и другие. В PGP предусмотрена схема, резко ускоряющая дешифровку. Возможно применение большого набора пар общедоступных и секретных ключей. Имеется система авторизации, контролирующая доступ к ключам и препятствующая использованию краденных секретных ключей. Предусмотрены и другие методы повышения секретности пересылки любых сообщений. Пакет работает под MS-DOS, UNIX, Windows. Данная версия позволяет посылать сообщение сразу нескольким адресатам. Пакет имеет встроенную справочную систему (Help на английском, французском и испанском языках. Описания, инструкции по постановке и использованию можно найти по адресу: FTP ftp.uu.net/pub/security/pgp. |
|
Previous:
6.4.3 Электронная подпись
UP:
6 Сетевая безопасность
|
|
|
|
6.4.6 Алгоритм Диффи-Хелмана
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Алгоритм Диффи-Хелмана (1976 год) использует функцию дискретного возведения в степень и похож на метод Эль-Гамаля. Сначала генерируются два больших простых числа n и q. Эти два числа не обязательно хранить в секрете. Далее один из партнеров P1 генерирует случайное число x и посылает другому участнику будущих обменов P2 значение A = qx mod n По получении А партнер P2 генерирует случайное число у и посылает P2 вычисленное значение B = qy mod n Партнер P1, получив В, вычисляет Kx = Bx mod n, а партнер P2 вычисляет Ky = Ay mod n. Алгоритм гарантирует, что числа Ky и Kx равны и могут быть использованы в качестве секретного ключа для шифрования. Ведь даже перехватив числа А и В, трудно вычислить Kx или Ky . Алгоритм Диффи-Хелмана, обеспечивая конфиденциальность передачи ключа, не может гарантировать того, что он прислан именно тем партнером, который предполагается. Для решения этой проблемы был предложен протокол STS (station-to-station). Этот протокол для идентификации отправителя использует технику электронной подписи. Подпись шифруется общим секретным ключом, после того как он сформирован. Подпись включает в себя идентификаторы как P1, так и P2. (см. также RFC-2786 "Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000".) |
|
Previous:
6.4.5 Алгоритм Эль Гамаля
UP:
6 Сетевая безопасность
|
|
|
|
6.4.7 IDEA - международный алгоритм шифрования данных
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
IDEA является блочным алгоритмом шифрования данных, запатентованным швейцарской фирмой Ascom (http://fn2.freenet.edmonton.ab.ca/~jsavard/co0404.html). Фирма, правда, разрешила бесплатное некоммерческое использование своего алгоритма (применяется в общедоступном пакете конфиденциальной версии электронной почты PGP). Здесь в отличие от алгоритма DES не используются S-блоки или таблицы просмотра. В IDEA применяются 52 субключа, каждый длиной 16 бит. Исходный текст в IDEA делится на четыре группы по 16 бит. Для того чтобы комбинировать 16 битные коды, используется три операции: сложение, умножение и исключающее ИЛИ. Сложение представляет собой обычную операцию по модулю 65536 с переносом. При составлении таблицы умножения принимаются специальные меры для того, чтобы операция была обратимой. По этой причине вместо нуля используется код 65536. Рассмотрим алгоритм IDEA. Пусть четыре четверти исходного текста имеют имена A, B, C и D, а 52 субключа - К(1), К(2),., К(52). Перед реализацией алгоритма выполняются операции: А = А*К(1); B = B + K(2); C = C + K(3); D = D * K(4); Первый цикл вычислений включает в себя: E = A XOR C; F = B XOR D Меняем местами В и С. Повторяем это всё 8 раз, используя К(7) - К(12) для второго раза и, соответственно, К(43) - К(48) - для восьмого. После восьмого раза В и С местами не меняются. Выполняем после этого операции: A = A * K(49) В результате закодированный текст имеет ту же длину, что и исходный. Схема этого весьма запутанного алгоритма может быть пояснена на рис. 6.4.7.1. По своему характеру алгоритм напоминает процедуры вычисления хэш-функции.
Рис. 6.4.7.1. Схема реализации алгоритма шифрования IDEA При дешифровке используется тот факт, что A XOR B не изменяется, если C A и B будет произведена операция XOR C использованием любого числа. Это утверждение справедливо для любых значений А и В. Операции сложения (слагаемые заменяются их дополнением по модулю 2) и умножения (множители заменяются из обратными величинами по модулю 65537) также допускают инверсию. Первые четыре ключа дешифровки (KD) определяются несколько иначе, чем остальные. KD(1) = 1/K(49); Последующие операции производятся восемь раз с добавлением 6 к индексу ключей дешифрования и вычитанием 6 из индекса ключей шифрования. KD(5) = K(47) Субключи IDEA генерируются следующим образом. 128-битовый ключ IDEA определяет первые восемь субключей (128=8*16). Последующие ключи (44) получаются путем последовательности циклических сдвигов влево этого кода на 25 двоичных разрядов. SKIPJACK Skipjack - секретный в прошлом блочный алгоритм, который ассоциируется с микросхемой Clipper (описание стало открытым в июне 1989 года). Алгоритм представляет собой альтернативу решениям, предлагаемым в алгоритмах IDEA и Safer (развитие идей DES, Lucifer и Blowfish). Блок исходных данных также как и в idea разбиваются на четыре группы. Алгоритм легко реализуется на обычной ЭВМ. Skipjack включает в себя 32 цикла шифрования. Эти циклы имеют две разновидности (А и В). Цикл А выполняет следующие операции. Первая группа бит исходного текста подвергается шифрованию с использованием G-перестановок (четырех цикличный шифр Файстела - специальный класс блочных шифров, где зашифрованный текст получается из исходного путем многократного использования одного и того же преобразования, напоминает шифр DES. Исходный текст разделяется на две части. Функция преобразования f и ключ используются для преобразования одной из половин а результат объединяется со второй частью исходного кода с помощью операции исключающее ИЛИ. После этого части меняются местами и процедура повторяется и т.д.). Для полученного результата и номера цикла (RN = 1-32) и четвертой группы исходного текста (W4) выполняется операция XOR. После этого производится перенос: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1. Цикл В осуществляет следующие преобразования. Для второй группы бит исходного текста (W2) выполняется операция XOR с номером цикла и первой группой бит исходного текста (W2 = (W2 XOR RN) XOR W1). Затем первая группа блока (W1) подвергается шифрованию с использованием G-перестановок. После этого производится перенос данных: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1. Последовательность выполнения алгоритма Skipjack предполагает выполнение 8 циклов типа А, 8 циклов В, 6 циклов А и 8 циклов В.
Рис. 6.4.7.2. Блок-схема алгоритма шифрования Skipjack G-перестановки включают в себя разделение группы из 16 бит на две подгруппы по 8 бит. Подобно DES левая половина кода не изменяется в процессе реализации цикла шифрования, а используется в качестве входного параметра F-функции, для результата которой и правой части кода выполняется операция XOR. В отличии от DES половины кода меняются местами лишь после завершающего цикла. F-функция G-перестановок достаточно проста: входные данные и субключ цикла объединяются операцией XOR, а результат заменяется кодом из таблицы просмотра (lookup-таблица - F). Субключи для G имеют длину 8 бит и являются первыми четырьмя байтами 80-битового исходного ключа. Первые 4 байта используются в первом цикле, следующие 4 - во втором, последние 2 байта вместе с первыми двумя - в третьем и т.д. 12 первых циклов реализации алгоритма шифрования Skipjack показаны на рис. 6.4.7.2. Первый цикл типа А отображен вместе со схемой реализации G-функции. Для следующих 7 циклов типа А G-функция отмечена квадратиком с буквой G. Цифрами (1-12) отмечен ввод данных для цикла с соответствующим номером. При реализации F-функции используется таблица (16*16) перестановок кодов 0-255. В случае дешифровки циклы выполняются в обратном порядке. Аналогом цикла А при дешифровке является последовательность операций: Для групп бит W1 и W2 и номера цикла выполняется операция XOR (циклы здесь нумеруются, начиная с 32 до 1). Затем W2 подвергается обратной G-перестановке, после чего выполняется перенос: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3. Аналог цикла типа В при дешифровке включает в себя следующие операции: Группа бит W2 подвергается обратной G-перестановке. W3 объединяется с номером цикла и группой бит W2 с помощью операции исключающее ИЛИ. После чего производится перемещение: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3. |
|
Previous:
6.4.6 Алгоритм Диффи-Хелмана
UP:
6 Сетевая безопасность
|
|
|
|
6.4.8 Алгоритм шифрования SAFER
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Алгоритм шифрования SAFER (Secure And Fast Encryption Routine; http://fn2.freenet.edmonton.ab.ca/~jsavard/co0403.html) не использует разбивку исходного текста на блоки (как это делается в DES или IDEA). Здесь исходный текст пропускается через S-матрицы, которые заменяются на обратные версии при дешифровании. В SAFER используется 8 циклов. Первый шаг цикла заключается в использовании первого субключа для преобразования 8 байт исходного текста. То, как используется субключ, зависит от номера байта в группе. Так для 1-го, 4-го, 5-го и 8-го для этого служит операция XOR, а для 2-го, 3-го, 6-го и 7-го байтов применяется операция сложения. Затем при обработке текста в S-матрице байты, для которых было применено исключающее ИЛИ, поступают на обычную матрицу, для остальных применяется инвертированная. s-матрицы представляют собой таблицы байтов, которые получаются по формуле 45N mod 257, где N -номер кода в таблице (после чего выделяются 8 младших разрядов).
1 45 226 147 190 69 21 174
64 53 72 156 81 47 59 85
241 51 239 218 44 181 178 43
4 180 133 74 246 19 84 182
0 212 31 110 67 188 236 83
193 204 185 101 176 210 198 172
16 206 18 39 213 76 79 214
253 77 124 183 11 238 173 75 Обратная матрица при этом имеет вид. 128 0 176 9 96 239 185 253 112 237 232 236 114 179 21 195 32 169 157 132 152 5 156 187 121 223 170 246 62 163 241 17 208 80 89 63 77 98 52 10 95 249 212 85 11 220 55 49 41 160 143 178 90 216 166 126 109 240 2 40 206 221 155 234 После обработки с помощью S-матрицы используется второй субключ, который воздействует на блок преобразуемых данных. В этом случае используется другая последовательность операций: ADD, XOR, XOR, ADD, ADD, XOR, XOR, ADD (сравните с порядком операций, указанным в первом абзаце главы). Далее байты группируются: второй байт заменяется суммой первого байта и второго, первый - суммой нового значения второго байта и первого, четвертый - суммой третьего и четвертого, третий - суммой нового значения четвертого и третьего и т.д. вплоть до 8 байта включительно (см. рис. 6.4.8.1). При суммировании в результате операции учитываются только младшие 8 бит. По завершении этой процедуры байты выкладываются в следующем порядке (цифры означают старое положений байтов):
Рис. 6.4.8.1. Блок-схема реализации цикла алгоритма SAFER После этого процедуры группирования и суммирования и перемешивания байтов повторяются. Дешифровка в рамках алгоритма SAFER реализуется для каждой из процедур (путем замены их на обратные), примененной при шифровании независимо. В качестве первого 64-битного субключа используется основной ключ шифрования. Для генерации последующих ключей используется циклический сдвиг влево на 3 бита. Полученные результаты объединяются с определенной константой (специфичной для каждого цикла) с помощью операции исключающее ИЛИ (XOR). Для первого субключа эта константа равна нулю. Далее используются константы, приведенные ниже: 16733B1E8E70BD86 |
|
Previous:
6.4.7 IDEA - международный алгоритм шифрования данных
UP:
6 Сетевая безопасность
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.4.9 Аутентификация в Интернет
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. Введение Аутентификационные требования вычислительных систем и сетевых протоколов варьируются в весьма широких пределах. Пароли, которые уязвимы для атак пассивного типа, не могут удовлетворить требованиям современного Интернет [CERT94]. А помимо пассивных атак в сетевой среде сплошь и рядом предпринимаются активные методы [Bellovin89, Bellovin92, Bellovin93, CB94, Stoll90]. 2. Определения и терминология, используемые в данном документе Активная атака . Попытка некорректной модификации данных с целью аутентификации или авторизации с помощью вставления ложных пакетов в поток данных или их модификации. Асимметричная криптография. Криптографическая система, которая использует различные ключи для шифрования и дешифрования. Эти два ключа являются математически связанными. Называется также криптографией с общедоступным ключом. Аутентификация. Идентификация источника информации. Авторизация. Предоставление прав доступа на основе аутентификации. Конфиденциальность. Защита информации, так чтобы лицо, не авторизованное для доступа к данным, не могло их читать, даже если имеется доступ к соответствующему каталогу или сетевому пакету. Шифрование. Механизм, используемый для обеспечения конфиденциальности. Целостность . Защита информации от неавторизованной модификации. Сертификат ключа . Информационная структура, состоящая из общедоступного ключа, идентификатора лица, системы и информации, аутентифицирующей ключ и ассоциацию общедоступного ключа с идентификатором. Ключи, используемые PEM, являются примером сертификата ключа [Kent93]. Пассивная атака. Атака на систему аутентификации, которая не предполагает введения каких-либо данных в поток, но базируется на возможности мониторинга информации, которой обмениваются другие партнеры. Эта информация может быть использована позднее. Исходный текст (Plain-text). Незашифрованный текст. Атака воспроизведения (Replay Attack). Атака на систему аутентификации путем записи и последующего воспроизведения ранее посланных корректных сообщений или их частей. Любая неизменная информация, такая как пароль или биометрические данные могут быть записаны и использованы позднее для имитации аутентичности. Симметричная криптография. Система шифрования, которая использует один и тот же ключ для шифрования и дешифрования. Иногда называется криптографией с секретным ключом. 3. Аутентификационные технологии Существует некоторое число различных классов аутентификации, начиная с полного ее отсутствия до очень строгих механизмов контроля. Для различных целей могут использоваться разные виды аутентификации. 3.1. Отсутствие аутентификации Простейшая аутентификационная система не имеет аутентификации вовсе. Изолированная от сети частная персональная ЭВМ является примером, где аутентификация не нужна. Другим примером может служить автономная общедоступная рабочая станция, обслуживающая некоторые конференции, где раскрытие информации или ее модификация не являются критическими. 3.2. Аутентификационные механизмы, уязвимые для пассивных атак Простая проверка пароля является наиболее общей формой аутентификации. Простые аутентификационные проверки имеют различные формы: ключ может быть паролем, запомненным пользователем, он может быть физическим или электронным объектом, принадлежащим пользователю, он может быть уникальной биологической характеристикой. Простые аутентификационные системы считаются "раскрывающими", так как, если ключ передается по сети, он может быть перехвачен злоумышленником. Имеются сообщения об успешных пассивных атаках в Интернет с помощью "расколотых" уже ЭВМ [CERT94]. Механизмы раскрывающей аутентификации уязвимы для атак "воспроизведения". Ключи доступа могут быть запомнены в атакуемой машине и при наличии бреши в системе безопасности можно получить доступ ко всем паролям. Обычно форма хранения паролей допускает их сверку, но не чтение. 3.3. Аутентификационные механизмы, уязвимые для активных атак Не раскрывающие парольные системы созданы для предотвращения атак воспроизведения. Разработано несколько систем для генерации не раскрываемых паролей. Система аутентификации S/Key (TM), разработанная в Bellcore генерирует много одноразовых паролей из одного секретного ключа [Haller94]. Она не использует физических объектов (token), поэтому удобна для аутентификации машина-машина. Аутентификация S/Key не требует запоминания секретного ключа пользователя, что является преимуществом при работе с ненадежными вычислительными системами. В ее сегодняшнем виде система S/Key уязвима для переборных атак со словарем в случае неудачного выбора пароля. Система CHAP протокола PPP не является раскрывающей, но применима только локально [LS92, Simpson93]. 3.4. Аутентификационные механизмы, не уязвимые для пассивных атак По мере расширения применения сетей растет необходимость более жесткой аутентификации. В открытых сетях большое число пользователей могут получить доступ к информации, переносимой по сети. При желании пользователь может сымитировать ситуацию, при которой посланная им информация будет восприниматься, как посланная другим сетевым объектом. Более мощные аутентификационные системы используют вычислительные возможности партнеров, участвующих в процессе аутентификации. Аутентификация может быть однонаправленной, например аутентификация пользователей в вычислительной системе, или она может быть взаимной, когда оба партнера должны идентифицировать друг друга. Некоторые системы аутентификации используют криптографические методы и формируют общий секретный код (например, ключ сессии), который может быть использован при последующем обмене. Например, пользователю после завершения процесса аутентификации может быть предоставлен аутентификационный билет, который может быть использован для получения других услуг без дополнительной аутентификации. Эти системы аутентификации могут также обеспечить, когда требуется, конфиденциальность (используя шифрование) при передаче данных по незащищенным сетям. 4. Криптография Криптографические механизмы широко используются для осуществления аутентификации в современных сетях. Существует два базовых вида криптографии (симметричная и асимметричная). Одной из фундаментальных проблем для криптографии является транспортировка секретных ключей. 4.1. Симметричная криптография Симметричная криптография включает в себя все системы, которые используют один и тот же ключ для шифрования и дешифрования. Таким образом, если кто-либо получит ключ, он сможет дешифровать и читать информацию, зашифрованную с его помощью. Такое лицо сможет шифровать и посылать любые данные, выдавая их за информацию, посланную легальным владельцем этого секретного ключа. Это означает, что знание ключа нежелательным третьим лицом полностью компрометирует конфиденциальность системы. Следовательно, используемые ключи должны доставляться безопасным способом, либо курьером, либо с применением специального протокола пересылки ключей, лучшим из которых является алгоритм Нидхэма-Шрёдера [NS78, NS87]. Широко используется алгоритм DES (Data Encryption Standard), который был стандартизован для защиты правительственной информации в США. Он представляет собой один из лучших симметричных алгоритмов шифрования [NBS77]. Хорошо известной системой, работающей в открытых сетях, является система аутентификации Kerberos (TM), которая была разработана в рамках проекта Athena в MIT [SNS88, BM91, KN93]. Система Kerberos базируется на алгоритме DES и использует специальный сервер, который хранит секретные ключи всех пользователей и услуг. Он может генерировать коды, которые позволяют пользователям и процессам идентифицировать себя в других системах. Как в любой схеме с распределенной аутентификацией, эти верительные коды работают в пределах местного административного домена. Следовательно, если пароль пользователя раскрыт, злоумышленник будет способен маскироваться под этого пользователя и проникнуть в любую систему, обслуживаемую Kerberos. Так как сервер Kerberos знает все секретные ключи, он должен быть достаточно безопасным. Ключи сессии Kerberos могут использоваться для обеспечения конфиденциальности при обмене между любыми объектами в пределах зоны действия сервера. 4.2. Асимметричная криптография В конце 1970, главным прорывом в криптографии стала разработка асимметричной криптографии. Здесь для шифрования и дешифрования используются разные ключи, которые генерируются совместно. Наилучшая асимметричная система базируется на алгоритме, предложенном Rivest, Shamir и Adleman, и называется по инициалам авторов RSA [RSA78]. SPX представляет собой экспериментальную систему, которая преодолевает ограничения системы Kerberos путем применения криптографии с общедоступным ключом RSA [TA91]. SPX предполагает глобальную иерархию сертифицирующих узлов по одному или более для каждого из партнеров. Она использует цифровую подпись, которая состоит из строки кодов, зашифрованных секретным ключом отправителя, и которая может быть проверена с помощью соответствующего общедоступного ключа. Общедоступные ключи предполагаются правильными, так как получены с сертифицирующей подписью. Критические секции аутентификационного обмена шифруются посредством общедоступных ключей получателя, что препятствует атаке воспроизведения. 4.3. Криптографические контрольные суммы Криптографические контрольные суммы являются одним из наиболее важных средств разработчиков криптографических протоколов. Криптографическая контрольная сумма или MIC (message integrity checksum) служат для контроля целостности сообщений и аутентификации. Например, Secure SNMP и SNMPv2 вычисляют криптографическую контрольную сумму MD5 для совместного секретного блока данных и информации, которая должна быть аутентифицирована [Rivest92, GM93]. Это служит для того, чтобы аутентифицировать источник данных при этом предполагается, что эту сумму крайне трудно фальсифицировать. Она не указывает на то, что сами посланные данные корректны, а лишь на то, что они посланы именно данным отправителем. Криптографические контрольные суммы могут использоваться для получения относительно эффективной аутентификации, и особенно полезны при обмене ЭВМ-ЭВМ. Главная трудность реализации - передача ключей. 4.4. Цифровые подписи (сигнатуры) Цифровая подпись представляет собой криптографический механизм, который является аналогом рукописной подписи. Она служит для аутентификации блока данных и подтверждает то, что она получена от отправителя. Цифровая подпись, использующая асимметричную криптографию (общедоступные ключи) может быть полезной для определения источника сообщения даже в случае, когда отправитель отрицает свое авторство. Цифровая подпись обеспечивает аутентификацию без конфиденциальности, так как текст самого сообщения не шифруется. Цифровая подпись использована в системе конфиденциальной почты PEM (Privacy Enhanced Mail) [Linn93, Kent93, Balenson93, Kaliski93]. 5. Аутентификация пользователя на ЭВМ Существует много различных подходов к проблеме аутентификации пользователя в удаленных ЭВМ. Имеется две угрозы при доступе к удаленной ЭВМ. Во-первых, злоумышленник может перехватить идентификатор и пароль пользователя и позднее воспользоваться ими при атаке "воспроизведения". Во-вторых, сама форма пароля позволяет хакеру попытаться его угадать. В настоящее время большинство систем используют открытый текст для передачи паролей по сетевым каналам, что сильно упрощает их перехват [Anderson84, Kantor91]. Такая система не обеспечивает адекватной защиты от атак воспроизведения, когда злоумышленник сумел заполучить идентификатор и пароль удаленного пользователя. 5.1. Защита против пассивной атаки является необходимой Отсутствие, по крайней мере, не раскрывающей парольной системы, означает предоставление неограниченного доступа любому, кто имеет физический доступ к сети. Например, всякий кто имеет доступ к кабелю Ethernet<, может имитировать работу любого пользователя данного сегмента сети. Таким образом, когда кто-то имеет пароль, передаваемый по Ethernet открытым текстом, реализуется первичная система безопасности. Когда размер локальной системы невелик (а это справедливо не только для Ethernet, но и для FDDI или Token-Ring LAN), данная система может еще рассматриваться как приемлемая, но это совершенно не так для сетей Интернет [CERT94]. Минимальной защитой против пассивных атак, таких как прослушивание сети, является применение не раскрывающей системы паролей. Такая система может функционировать на пассивном терминале или в качестве коммуникационной программы (напр., Crosstalk или PROCOMM), которая эмулирует пассивный терминал на персональной ЭВМ. Использование более строгой аутентификационной системы защитит против пассивных атак со стороны удаленных систем за счет ограничения использования простых терминалов. Разумно ожидать, что производители коммуникационных программ и не программируемых пользователем терминалов (таких как Х-терминалы) встроят систему не раскрываемых паролей или более строгие аутентификационные системы. Одним из преимуществ Kerberos является то, что при правильном использовании пароль пользователя никогда не покидает пределов рабочей станции. Вместо этого они используются для расшифровки билетов пользователя Kerberos. 5.2. Защита периметра Защита периметра применяется все шире. В этих системах пользователь сначала осуществляет аутентификацию в определенном объекте сети, например, в ЭВМ "firewall", используя систему не раскрываемых паролей. Пользователь затем использует вторую систему для аутентификации в каждой ЭВМ или в группе ЭВМ, где он хотел бы получить доступ к определенным услугам. В защите периметра существует несколько недостатков, по этой причине эту систему следует рассматривать как временное решение. Сетевой шлюз не прозрачен на IP-уровне и по этой причине работа с каждым видом сервиса должна производиться независимо. Использование двойной аутентификации является трудно осуществимым или невозможным для связи ЭВМ-ЭВМ. Протоколы точка-точка, которые являются обычными для Интернет механизмов без установления связи, легко уязвимы. Защита периметра должна быть плотной и полной, так как в случае ее прорыва внутренняя защита оказывается слабой и легко преодолимой. Частой формой защиты периметра является передача приложений. Так как эти передачи являются протокольно зависимыми, IP-коннективность ЭВМ в пределах периметра с внешним миром оказывается нарушенной и часть преимуществ Интернет пропадает. Административное преимущество защиты периметра заключается в том, что число ЭВМ, которые могут быть подвергнуты атаке, достаточно мало. Эти машины могут быть тщательно проверены с точки зрения угроз безопасности. Но достаточно трудно или даже невозможно создать достаточно "герметичную" систему. Безопасность системы защиты периметра достаточно сложна, так как шлюз должен пропускать некоторые типы трафика, например, электронную почту. Другие сетевые услуги, такие как NTP (Network Time Protocol) и FTP могут также оказаться желательными [Mills92, PR85, Bishop]. Более того, шлюзовая система периметра должна быть способна пропускать весь трафик всего домен, заключенного в данный периметр. 5.3. Защита от активных атак является крайне желательной В обозримом будущем потребуются достаточно мощные системы, способные противостоять активным атакам. Многие корпоративные сети, базирующиеся на широковещательной технологии, такой как Ethernet, вероятно нуждаются в такой методике. Чтобы защититься от активных атак, или обеспечить конфиденциальность, необходимо использовать протокол с шифрованием сессии, например, Kerberos, возможно использование аутентификационного механизма, который защищает от атаки воспроизведения. В системе Kerberos, пользователи получают коды доступа от сервера Kerberos и используют их для аутентификации, чтобы осуществить доступ к услугам других ЭВМ сети. Вычислительная мощность локальной рабочей станции может быть использована для дешифрования кодов доступа (используя ключ, извлеченный из пароля, введенного пользователем) и запоминания на время пока это требуется. Если протокол безопасности базируется на синхронизации часов, тогда может быть полезен протокол NTPv3, так как он распространяет временные метки для большого числа ЭВМ и является одним из немногих протоколов Интернет, которые содержат механизмы аутентификации [Bishop, Mills92]. Другим подходом для доступа к сетевым ЭВМ является введение для всех внешних машин общего секретного кода Kerberos KDC. Это делает эти машины "серверами", а не рабочими станциями. Этот общий секретный код может быть затем использован для шифрования всех обменов между машинами, обеспечивая безопасную передачу аутентификационной информации KDC. Наконец, рабочие станции, которые удаленно доступны, могут использовать асимметричную криптографическую технологию для шифрования телекоммуникаций. Общедоступный ключ рабочей станции будет предоставлен всем клиентам. Пользователь может применить общедоступный ключ для шифрования пароля, а удаленная система дешифрует его и аутентифицирует пользователя без угрозы раскрытия пароля при транспортировке. Ограничением этой системы безопасности, ориентированной на рабочую станцию заключается в том, что она не аутентифицирует индивидуальных пользователей, а только индивидуальные рабочие станции. В некоторых средах, например, в многоуровневых правительственных системах безопасности необходима аутентификация пользователь-пользователь. 6. Раздача ключей и управление Управление доступом для ключей является самой тяжелой проблемой, с которой приходится сталкиваться при обеспечении аутентификации в больших сетях Интернет. Протокол Нидхема-Шрёдера [NS78, NS87], который используется в системе Kerberos, базируется на централизованном сервере ключей. В больших корпоративных сетях требуется значительное число таких ключевых серверов, по крайней мере, один ключевой сервер на каждый административный домен. Существует также нужда в механизмах для отдельных ключевых серверов, необходимых для координирования генерации ключей сессий участников в различных административных доменах. Большинство алгоритмов шифрования с использованием общедоступных ключей требуют достаточно больших вычислительных мощностей и по этой причине они неидеальны для шифрования пакетов в сети. Однако асимметричное свойство делает их очень полезными в начале сессии для получения симметричных ключей сессии. На практике, коммерческий сектор, вероятно, использует асимметричный алгоритм для цифровых подписей и пересылки ключей, но не для массового шифрования данных. Для целей пересылки ключей можно использовать алгоритмы RSA и Диффи-Хелмана [DH76]. Преимуществом асимметричной методики является отсутствие необходимости иметь центральный сервер для хранения и рассылки ключей. Система PEM использует цифровые подписи для аутентификации общедоступных ключей пользователей [Kent93]. Результатом этой операции является сертификат, который содержит общедоступный ключ партнера. Сертификаты ключей могут рассылаться различными способами. В одном из вариантов рассылка ключей встраивается в существующие службы каталогов. Это может быть сделано, например, путем расширения возможностей DNS и включения ключа ЭВМ в ресурсную запись нового типа. Для мультикастных сессий, управление рассылкой ключей сложнее, так как число обменов, необходимых для широко используемых методик пропорционально числу участников. 7. Аутентификация сетевых услуг Кроме необходимости аутентификации пользователей и ЭВМ друг другу, многие сетевые услуги сами нуждаются в аутентификации. Наиболее общий случай в настоящее время - это отсутствие поддержки в протоколе какой-либо аутентификации. Bellovin и другие документировали многие случаи, когда существующие протоколы могут использоваться для атаки удаленной ЭВМ, так как там не существует встроенной процедуры аутентификации [Bellovin89]. Некоторые протоколы предоставляют возможность передачи незащищенных паролей совместно с протокольной информацией. Исходные протоколы SNMP использовали этот метод, многие маршрутные протоколы продолжают его использовать и сейчас [Moy91, LR91, CFSD88]. Этот метод полезен, так как несколько повышает безопасность передачи. Существует много протоколов, которые нуждаются в поддержке более строгих аутентификационных механизмов. Например, известно, что протокол SNMP нуждается в существенном усилении аутентификации. Это вызвало разработку протоколов Secure SNMP, которые поддерживают опционную аутентификацию, используя цифровую подпись и опционное шифрование с привлечением алгоритма DES. Цифровые подписи, используемые в Secure SNMP, базируются на добавлении криптографической контрольной суммы к SNMP-информации. Криптографическая контрольная сумма вычисляется с использованием алгоритма MD5 и секретного кода, используемого совместно обоими партнерами обмена. Технология цифровой подписи должна рассматриваться как необходимое средство при разработке новых технологий аутентификации (но не конфиденциальности). Цифровые подписи могут использовать ключи и методы как симметричной, так и асимметричной криптографии. Если доступна централизованная система распределения ключей, опционная поддержка цифровой подписи может быть обеспечена для большинства протоколов с минимальными издержками. Каждый протокол может столкнуться проблемой пересылки ключей и установки параметров обмена, и это приведет к усложнению использования техники цифровой подписи. Для случаев, когда требуется аутентификация и конфиденциальность для схемы коммуникации ЭВМ-ЭВМ, может быть применено шифрование, базирующееся на симметричной или асимметричной схеме, или даже на их комбинации. Использование асимметричной криптографии упрощает управление раздачей ключей. Каждая ЭВМ шифрует свою информацию перед отправкой, безопасность же внутри машины обеспечивается средствами операционной системы ЭВМ. В некоторых случаях, возможно включающих электронную почту, может оказаться желательным обеспечить безопасность в пределах приложения на уровне пользователь-пользователь, а не ЭВМ-ЭВМ. Безопасная почта PEM использует именно этот подход [Linn93, Kent93, Balenson93, Kaliski93]. 8. Будущие направления Просматривается тенденция внедрения все более строгих механизмов аутентификации. Следует ожидать введения не раскрывающей пароли аутентификации и более широкого использования механизмов с общедоступным ключом. Растет важность аутентификации сессий и процессов, проблема целостности и конфиденциальности сообщений при передаче по сетевым каналам. Так как коммуникации ЭВМ-ЭВМ становятся все более важными, протоколы связи человек-машина становятся менее существенными. Использование криптосистем с общедоступным ключом для аутентификации пользователь-ЭВМ упрощает многие аспекты, но хранение простых паролей, а также общедоступных и секретных ключей остается актуальной проблемой. Следует учитывать, что размер общедоступного ключа, используемого в настоящее время, по меньшей мере, составляет 500 бит. В будущем, вероятно, будут применяться еще более длинные ключи. Таким образом, пользователи могут хранить свои ключи в виде пригодном для электронного считывания. Использование ROM, такой как флоппи-диск или магнитная карточка может решить эту проблему, но тогда пользователь неизбежно доверяет свои ключи считывающему устройству. Применение смарт-карты, совмещающей память и программу, более предпочтительно. Такие приборы могут обеспечить аутентификацию без риска разглашения секретных кодов, которые они хранят. Они могут также взаимодействовать с пользователем, осуществляя простую аутентификацию при разблокировании карты. Применение криптосистем с общедоступным ключом при аутентификации ЭВМ-ЭВМ лишено проблем запоминания ключей, которые характерны для интерфейсов человек-машина. Многопользовательская ЭВМ может запоминать свои ключи в области памяти, защищенной от доступа пользователей. Если рассматривать существующие симметричные алгоритмы как одно-ключевые, а асимметричные, такие как RSA в качестве двухключевых систем, можно предположить появление в будущем N-ключевых методик (где N больше 2). Если бы такая N-ключевая технология существовала, она могла бы использоваться для реализации масштабируемых протоколов для рассылки ключей в случае мультикастинга. В настоящее время ведется разработка технологии CBT (Core Based Tree), предназначенной для решения подобной задачи [BFC93]. Ссылки
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.4.8 Алгоритм шифрования SAFER
UP:
6 Сетевая безопасность
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол Нидхэма-Шрёдера предназначен для решения проблемы аутентификации (см., например, http://www.cs.sunysb.edu/~zhaoming/np.html , http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/node14.html , а также [1]). Протоколу уже более 20 лет. Алгоритм предназначен для организации аутентифицированного канала между разными ЭВМ в сети по схеме точка-точка. Задача решается с помощью одного или двух серверов аутентификации с использованием общедоступных или общих секретных ключей. Данный протокол предоставляет децентрализованную услугу аутентификации. Операция аутентификации может охватывать несколько процессов.
Безопасная передача данных по сети, которая сама не является безопасной, предполагает шифрование передаваемой информации. Будем предполагать, что каждая из сторон, участвующих в обмене, способна шифровать и дешифровать данные. Протокол Нидхэма-Шрёдера может работать как для симметричной, так и несимметричной схем шифрования (с общим секретным ключом и с двумя парами ключей, соответственно). Будем также считать, что злоумышленник может подключить свою ЭВМ в любую точку пути, по которому происходит обмен и, таким образом, способен перехватить, воспроизвести или исказить любое сообщение. ЭВМ же субъектов обмена и сервер аутентификации предполагаются защищенными от вторжения. Сервер аутентификации может предоставить идентификационную информацию, вычисляемую на основе секретного ключа субъекта аутентификации. Сначала рассмотрим вариант с использованием симметричного шифрования/дешифрования (один ключ). При схеме шифрования с одним ключом, предполагается, что секретный ключ известен обоим субъектам обмена (А и В) и серверу аутентификации. Инициатором обмена будем считать субъекта А. Сообщения, посылаемые от А к В, могут быть дешифрованы только В и субъект В должен быть уверен, что сообщение пришло именно от А. В начале предположим, что оба субъекта находятся в области действия общего сервера аутентификации (AS). AS знает секретные ключи субъектов А и В (KA и KB, соответственно). Обмен начинается с того, что субъект А генерирует свой идентификатор IA1, который будет использоваться только один раз. Первое сообщение, посылаемое от A к AS, содержит:
Здесь предполагается, что сообщение послано открытым текстом, но в принципе оно может быть и зашифровано с использованием ключа KA.
Получив это сообщение AS , извлекает из базы данных секретные ключи KA и KB, а также вычисляет новый ключ CK (ключ сессии), который будет использован для осуществления процедуры аутентификации. Этот новый ключ должен быть непредсказуемым, он используется только для одной операции аутентификации. Далее AS посылает субъекту А следующее сообщение:
Верхний индекс в данном выражении означает, что содержимое в скобках зашифровано с использованием ключа-индекса. КА и КВ - секретные ключи субъектов А и В, соответственно. Так как выражение (IA1, B, CK, {CK, A}KB) зашифровано ключом КА, то только субъект А может его дешифровать и прочесть. Субъект А проверяет наличие идентификатора IA1 (это подтверждает то, что данное сообщение является откликом на сообщение А), и имени субъекта, с которым А намерен обмениваться данными (В). В результате дешифровки сообщения от AS А получает во владение рабочий ключ СК. Наличие В в сообщение является обязательным. В противном случае злоумышленник может заменить В на, например, Х в сообщении (1), и в дальнейшем А будет взаимодействовать с Х а не с В, сам того не подозревая. Заметим, что часть текста {CK, A}KB субъект А прочесть не может. Если все прошло нормально, субъект А посылает В следующее сообщение:
Нетрудно видеть, что содержимое {CK, A}KB является частью сообщения, полученного от AS. Дешифровать это послание может только субъект В, так как оно зашифровано его секретным ключом. После дешифровки В также становится владельцем ключа сессии CK. Наличие А в сообщении подтверждает факт, что код получен именно от данного субъекта. Все обмены между А и В далее будут выполняться с использованием ключа шифрования СK. Чтобы сделать схему симметричной и уменьшить вероятность атаки воспроизведения, В следует послать А свой идентификатор:
зашифрованный ключом СК. При этом ожидается отклик:
Таким образом, в данной версии протокола используется 5 сообщений. Злоумышленник не может имитировать такой обмен, так как не владеет ключом CK. Это число для регулярно взаимодействующих партнеров можно сократить до трех, убрав обмен сообщениями 1.1 и 1.2. При этом ключ СК будет использоваться многократно. Здесь желательно заменить обмены 1.3 и 1.4 на:
Теперь рассмотрим вариант протокола для случая асимметричного шифрования (двух ключевая схема). Предполагается, что субъекты А и В вычислили пары ключей (PKA-SKA) и (PKB-SKB), соответственно. Имена ключей, начинающиеся с буквы P, относятся к общедоступным ключам (public), а имена, начинающиеся с буквы S, - к секретным. Инициатором, как и в предыдущем случае, будем считать субъект А. Обмен начинается с посылки AS запроса открытого ключа В (PKB).
AS откликнется сообщением:
Сообщение зашифровано секретным ключом AS (SKAS). Открытый ключ AS (PKAS) предполагается А известным, что позволяет А успешно дешифровать данное сообщение. Здесь предполагается, что подмена ключей (SKAS-PKAS) злоумышленником-посредником невозможна. Шифрование данных с использованием ключа SKAS не гарантирует конфиденциальности, но исключает модификацию сообщения по дороге (ведь никто посторонний не знает ключ SKAS). Важно, чтобы субъект А был уверен, что он получил именно PKB, а не что-то иное. Следующим шагом будет посылка сообщения от А к В:
Это сообщение может быть дешифровано только субъектом В. Смысл его заключается в том, что А уведомляет В о намерении установить с ним связь, и передает ему свой одноразовый идентификатор IA. Далее В запрашивает у AS открытый ключ А:
После этого производится взаимная аутентификация субъектов, завершающая сессию, для чего посылаются сообщения:
Таким образом, в этом варианте аутентификация потребовала семи шагов, но 4 из них (2.1, 2.2, 2.4 и 2.5) могут быть устранены, если партнеры помнят общедоступные ключи друг друга. В этом случае схема становится эквивалентной приведенной выше версии с симметричным шифрованием. Так как открытые ключи общедоступны, во многих случая для обеспечения большей достоверности следует использовать шифрование типа: {{сообщение}SKA}SKB. В реальной жизни субъекты не всегда могут находиться в пределах зоны ответственности одного общего сервера аутентификации. По этой причине в общем случае каждый из субъектов может иметь свой сервер аутентификации (ASA и ASB). Так как и в этом варианте перед субъектом А стоит задача сформировать для В сообщение типа {CK, A}KB (шаг 1.3). В вычисление таких выражений будут вовлечены оба сервера, так как только ASA может шифровать объекты посредством ключа КА, и только ASB может воспользоваться ключом КВ. Не исключается необходимость обеспечения безопасного обмена между AS. Примерами такого обмена могут служить операции, завершающие сессию аутентификации:
IA1 передается для того, чтобы сохранить состояние ASA между сообщениями 1.11 и 1.12. При работе с открытыми ключами возможно непосредственное обращение А к ASB, если субъект А владеет общедоступным ключом PKASB. По минимуму аутентификация при асимметричной схеме шифрования требует пересылки трех сообщений. Протокол Нидхэма-Шрёдера пригоден и для работы с электронными подписями. Электронная подпись, как обычно, формируется на основе дайджеста D (например, MD5) пересылаемого документа. Сначала рассмотрим вариант с традиционной схемой шифрования. Субъект А начинает передачу с посылки AS сообщения:
AS откликается, послав:
Сообщение 3.2 зашифровано ключом AS и, следовательно, не может дешифровано А. Субъект А шлет документ субъекту В с блоком подписи, следующим за текстом. При получении В сначала дешифрует текст и вычисляет дайджест документа CD, затем посылает блок подписи в AS для дешифровки.
Сервер дешифрует блок подписи и возвращает результат В:
Если возвращенный дайджест D соответствует CD, тогда субъект, упомянутый в 3.4, является отправителем подписанного текста. Если соответствия нет, это означает, что на этапах 3.1 -3.4 произошло искажение блока подписи или самого текста. В случае варианта шифрования с общедоступными ключами схема электронной подписи упрощается. В этом варианте можно даже не формировать дайджест можно послать текст, зашифрованный сначала секретным ключом А, а затем с привлечением общедоступного ключа В.
Субъект-получатель В дешифрует полученный текст сначала с помощью своего секретного ключа (SKB), а затем с привлечением общедоступного ключа А (PKA). При такой схеме А не сможет отказаться от того, что именно он послал текст, так как только он владеет секретным ключом SKA. Прочесть же текст может только субъект В, так как только он владеет секретным ключом SKB. В настоящее время разработан улучшенный протокол Нидхэма-Шрёдера (см. http://dimacs.rutgers.edu/Workshops/Security/program2/dedecker/node4.html ). [1] Roger M. Needham and Michael D. Schroeder, Using Encryption for Authentication in Large Networks of Computers. Communication of the ACM, V.21, N12, December 1978. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.4.9 Аутентификация в Интернет
UP:
6 Сетевая безопасность
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.5 Протокол SSL. Безопасный уровень соединителей
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Протокол SSL спроектирован для обеспечения конфиденциальности обмена между двумя прикладными процессами клиента и сервера (см. http://www.netscape.com/eng/security/SSL_2.html). Он предоставляет возможность аутентификации сервера и, опционно, клиента. SSL требует применения надежного транспортного протокола (например, TCP). Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложения, такие как HTTP, FTP, TELNET и т.д. могут работать поверх протокола SSL совершенно прозрачно. Протокол SSL может согласовывать алгоритм шифрования и ключ сессии, а также аутентифицировать сервер до того как приложение примет или передаст первый байт данных. Все протокольные прикладные данные передаются зашифрованными с гарантией конфиденциальности. Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:
6.5.1. Спецификация протокола записей SSL В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка. Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным. При равенстве 1, посылаемый рекорд является security escape (в настоящее время не определено ни одного значения security escapes; это зарезервировано для будущих версий протокола). Код длины рекорда не включает в себя число байт заголовка (2 или 3). Для 2-байтового заголовка его длина вычисляется следующим образом (используется Си-подобная нотация): RECORLENGTH = ((byte[0] & 0x7F << 8)) | byte[1]; Где byte[0] представляет собой первый полученный байт, а byte[1] - второй полученный байт. Когда используется 3-байтовый заголовок, длина рекорда вычисляется следующим образом: RECORD-LENGTH = ((byte[0] & 0x3F) << 8)) | byte[1]; Заголовок рекорда определяет значение, называемое PADDING. Значение PADDING специфицирует число байтов добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра, если применен блочный шифр. Отправитель "заполненного" рекорда добавляет заполнитель после имеющихся данных, а затем шифрует все это, благо длина этого массива кратна размеру блока используемого шифра. Содержимое заполнителя не играет роли. Так как объем передаваемых данных известен, заголовок сообщения может быть корректно сформирован с учетом объема субполя PADDING. Получатель этого рекорда дешифрует все поле данных и получает исходную информацию. После этого производится вычисление истинного значения RECORD-LENGTH (с учетом наличия опционного PADDING), при этом заполнитель из поля данные удаляется. 6.5.1.2. Формат информационных записей SSL Часть данных рекорда SSL состоит из трех компонентов (передаваемых и получаемых в приведенном ниже порядке): MAC-DATA[MAC-SIZE] ACTUAL-DATA представляет собой реальные переданные данные (поле данных сообщения). PADDING-DATA - это данные заполнителя, посылаемые когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения (Message Authentication Code). Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом: MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ] Где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA>, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи - "big endian"). MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам). Значение SECRET зависит оттого, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC). SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи, используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются. Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай "I/O Error" (т.e. как непоправимая ошибка, которая вызывает закрытие соединения). Окончательная проверка соответствия выполняется, когда используется блочный шифр и соответствующий протокол шифрования. Объем данных в рекорде (RECORD-LENGTH) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место "I/O Error" (что вызовет разрыв соединения). Уровень рекордов SSL используется для всех коммуникаций SSL, включая сообщения диалога и информационный обмен. Уровень рекордов SSL применяется как клиентом, так и сервером. Для двухбайтового заголовка, максимальная длина рекорда равна 32767 байтов. Для трехбайтового заголовка, максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL. Прежде чем послать первый рекорд SSL все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVER-HELLO. 6.5.2. Спецификация протокола диалога SSL Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента. Фаза 1 Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO. К этому моменту, как клиент, так и сервер имеют достаточно информации, чтобы знать, нужен ли новый мастерный ключ. Когда новый мастерный ключ не нужен, клиент и сервер немедленно переходят в фазу 2. Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр). Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий. Наконец, после того как мастерный ключ определен, сервер посылает клиенту сообщение SERVER-VERIFY. Этот заключительный шаг аутентифицирует сервер, так как только сервер, который имеет соответствующий общедоступный ключ, может знать мастерный ключ. Фаза 2 Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR. Раз партнер послал сообщение finished он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера. Как только оба партнера послали и получили сообщения finished, протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол. 6.5.2.2. Типовой протокол обмена сообщениями В несколько упрощенном варианте диалог SSL представлен на рис. 6.5.1.
Рис. 6.5.1. Алгоритм работы SSL Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что "нечто" зашифровано с помощью ключа "key". 6.5.2.2.1. При отсутствии идентификатора сессии
6.5.2.2.2. Идентификатор сессии найден клиентом и сервером
6.5.2.2.3. Использован идентификатор сессии и аутентификация клиента
В последнем обмене, response_data является функцией auth_type. 6.5.2.3. Ошибки Обработка ошибок в протоколе соединений SSL весьма проста. Когда ошибка детектирована, обнаруживший его посылает своему партнеру сообщение. Ошибки, которые являются неустранимыми, требуют от клиента и сервера разрыва соединения. Серверы и клиент должны "забыть" все идентификаторы сессии, сопряженные с разорванным соединением. Протокол диалога SSL определяет следующие ошибки: NO-CIPHER-ERROR Эта ошибка присылается клиентом серверу, когда он не может найти шифр или размер ключа, который поддерживается также и сервером. Эта ошибка неустранима. NO-CERTIFICATE-ERROR Когда послано сообщение REQUEST-CERTIFICATE, эта ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима. BAD-CERTIFICATE-ERROR Такой отклик присылается, когда сертификат по какой-то причине считается принимающей стороной плохим. Плохой означает, что, либо некорректна подпись сертификата, либо некорректно его значение (например, имя в сертификате не соответствует ожидаемому). Эта ошибка устранима (только для аутентификации клиента). UNSUPPORTED-CERTIFICATE-TYPE-ERROR Этот отклик присылается, когда клиент/сервер получает тип сертификата, который он не поддерживает. Эта ошибка устранима (только для аутентификации клиента). 6.5.2.4. Сообщения протокола диалога SSL Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения, и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol). После того как каждый из партеров определил пару ключей сессии, тела сообщений кодируются с помощью этих ключей. Для клиента это происходит, после того как он верифицировал идентификатор сессии, сформировал новый ключ сессии и послал его серверу. Для сервера это происходит, после того как идентификатор сессии признан корректным, или сервер получил сообщение клиента с ключом сессии. Для сообщений SSLHP (SSL Handshake Protocol) используется следующая нотация: char MSG-EXAMPLE Эта нотация определяет данные в протокольном сообщении, включая код типа сообщения. Порядок передачи соответствует порядку перечисления. Для записи "THING-DATA", значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении. Например, если THING-MSB был равен нулю, а THING-LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт. Длина кодов характеризуется целым числом без знака, и когда MSB и LSB объединяются, результат также является целым числом без знака. Если не указано обратного, длины полей измеряются в байтах. 6.5.2.5. Протокольные сообщения клиента Существует несколько сообщений, которые могут быть сформированы только клиентом. Эти сообщения ни при каких обстоятельствах не могут быть посланы сервером. Клиент, получив такое сообщение, закрывает соединение с сервером и присылает приложению уведомление об ошибке. CLIENT-HELLO (Фаза 1; посылается открыто) char MSG-CLIENT-HELLO Когда клиент впервые подключается к серверу, он должен послать сообщение CLIENT-HELLO. Сервер ожидает это сообщение от клиента первым. Любое другое сообщение от клиента в данных обстоятельствах рассматривается как ошибка. Клиент посылает серверу свою версию SSL, спецификацию шифров, некоторые данные вызова (challenge data), и данные идентификатора сессии. Данные идентификатора сессии посылаются клиентом только в том случае, когда в его кэше имеется идентификатор сессии, а значение SESSION-ID-LENGTH не равно нулю. Когда идентификатора сессии нет, то значение SESSION-ID-LENGTH должно быть равно нулю. Данные вызова используются для аутентификации сервера. После того как клиент и сервер согласовали пару ключей сессии, сервер присылает сообщение SERVER-VERIFY с зашифрованной формой CHALLENGE-DATA. Заметим также, что сервер не пошлет сообщения SERVER-HELLO пока не получит сообщения CLIENT-HELLO. Это делается так, чтобы сервер мог в первом сообщении клиенту определить состояние идентификатора сессии клиента (т.e. улучшить эффективность протокола и уменьшить объем обменов). Сервер рассматривает сообщение CLIENT-HELLO и проверяет, поддерживает ли он версию программы клиента и хотя бы одну позицию в спецификации шифров клиента. Сервер может опционно отредактировать спецификацию шифров, удалив записи, которые он решил не поддерживать. Отредактированная версия будет прислана в сообщении SERVER-HELLO, если идентификатор сессии не находится в кэше сервера. Значение CIPHER-SPECS-LENGTH должно быть больше нуля и кратно 3. Код SESSION-ID-LENGTH должен быть равен нулю или 16. Значение CHALLENGE-LENGTH должно быть больше чем ³ 16 и £ 32. Это сообщение должно быть первым, посланным клиентом серверу. После его посылки клиент ждет сообщения SERVER-HELLO. Любое другое сообщение, присланное сервером (кроме ERROR) не допустимо. CLIENT-MASTER-KEY (Фаза 1; посылается вначале открыто) char MSG-CLIENT-MASTER-KEY Клиент посылает это сообщение, когда он определил мастерный ключ для работы с сервером. Заметим, что когда идентификатор сессии согласован, это сообщение не посылается. Поле CIPHER-KIND указывает, какой шифр выбран из спецификации CIPHER-SPECS сервера. Данные CLEAR-KEY-DATA содержат открытую часть MASTER-KEY. CLEAR-KEY-DATA комбинируются с SECRET-KEY-DATA, чтобы образовать MASTER-KEY, при этом SECRET-KEY-DATA составляет младшие байты MASTER-KEY. ENCRYPTED-KEY-DATA содержит секретные части MASTER-KEY, зашифрованные с использованием общедоступного ключа сервера. Шифруемые блоки формируются с использованием блоков типа 2 PKCS#1 [5]. Информационная часть блока имеет следующий формат: char SECRET-KEY-DATA[SECRET-LENGTH] SECRET-LENGTH равно числу байт каждого из ключей сессии. SECRET-LENGTH плюс CLEAR-KEY-LENGTH равно числу байт в ключе шифра (как это определено CIPHER-KIND). Если после дешифрования SECRET-LENGTH окажется неравным ожидаемому значению, регистрируется ошибка. Ошибкой считается и ситуация, когда CLEAR-KEY-LENGTH не равно нулю и CIPHER-KIND является не экспортным шифром. Если алгоритм ключа требует аргумента (например, вектора инициализации DES-CBC), тогда поле KEY-ARG-LENGTH будет ненулевым и KEY-ARG-DATA будет содержать соответствующую информацию. Для алгоритмов SSL_CK_RC2_128_CBC_WITH_MD5, SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 и SSL_CK_DES_192_EDE3_CBC_WITH_MD5 должны присутствовать данные KEY-ARG с длиной 8 байт. Вычисление ключей сессии клиента и сервера является функцией CIPHER-CHOICE: SSL_CK_RC4_128_WITH_MD5 Где KEY-MATERIAL-0[0-15] означает первые 16 байт данных KEY-MATERIAL-0, с KEY-MATERIAL-0[0], образующим старший байт CLIENT-READ-KEY. Данные передаются хэш-функции MD5, начиная с MASTER-KEY, далее следует "0" или "1", затем вызов (CHALLENGE) и, наконец, CONNECTION-ID. Заметим, что "0" означает ASCII символ нуль (0x30), а не значение нуль. "1" означает ASCII символ 1 (0x31). MD5 выдает 128 бит выходных данных, которые используются в качестве ключа алгоритма шифрования (старший байт хэша MD5 становится старшим байтом ключевого материала). SSL_CK_DES_64_CBC_WITH_MD5 Для DES-CBC, 16-байтовый ключевой материал формируется с помощью MD5. Первые 8 байт дайджеста MD5 используются в качестве CLIENT-READ-KEY, в то время как оставшиеся 8 байт используются в качестве CLIENT-WRITE-KEY. Вектор инициализации берется из KEY-ARG-DATA. SSL_CK_DES_192_EDE3_CBC_WITH_MD5 KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ] CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7] Данные передаются хэш-функции MD5 в указанном порядке, слева направо: первым поступает MASTER-KEY, затем "0", "1" или "2", далее CHALLENGE и, наконец, CONNECTION-ID (идентификатор сессии). Заметим, что "0" означает ascii символ нуль (0x30), а не код нуль. "1" означает ascii символ 1 (0x31). "2" означает ascii символ 2 (0x32). Всего генерируется 6 ключей, 3 ключа читающей стороны для шифра DES-EDE3 и 3 - для пишущей стороны для функции DES-EDE3. Вектор инициализации формируется в KEY-ARG-DATA. Вспомним, что MASTER-KEY передан серверу в сообщении CLIENT-MASTER-KEY. CHALLENGE выдается серверу клиентом в сообщении CLIENT-HELLO. CONNECTION-ID передается клиенту от сервера в сообщении SERVER-HELLO. Это делает получаемые в результате ключи, зависящими от исходной и текущей сессии. Заметим, что мастерный ключ никогда не используется для шифрования данных, и следовательно не может быть легко раскрыт. Сообщение CLIENT-MASTER-KEY должно быть послано после сообщения CLIENT-HELLO и до сообщения CLIENT-FINISHED. Сообщение CLIENT-MASTER-KEY должно быть послано, если сообщение SERVER-HELLO содержит значение SESSION-ID-HIT равное 0. CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным) char MSG-CLIENT-CERTIFICATE Это сообщение посылается клиентом SSL в ответ на сообщение сервера REQUEST-CERTIFICATE. CERTIFICATE-DATA содержит данные, определенные значением CERTIFICATE-TYPE. Сообщение об ошибке ERROR посылается с кодом NO-CERTIFICATE-ERROR, если данный запрос не может быть обработан корректно (например, получатель сообщения не имеет зарегистрированного сертификата). CERTIFICATE-TYPE является одним из: SSL_X509_CERTIFICATE RESPONSE-DATA несет в себе аутентификационные данные отклика. Эти данные зависят от значения AUTHENTICATION-TYPE, посланного сервером. Когда код AUTHENTICATION-TYPE равен SSL_AT_MD5_WITH_RSA_ENCRYPTION, тогда RESPONSE-DATA содержит цифровую подпись следующих компонентов (в указанном порядке):
Цифровая подпись формируется с привлечением MD5, полученный хэш шифруется с использованием общедоступного ключа клиента, формат подписи согласуется со стандартом PKCS#1 [5]. Сервер аутентифицирует клиента путем верификации его цифровой подписи. Допускается добавление нового типа AUTHENTICATION-TYPE или идентификатора алгоритма цифровой подписи. Это сообщение должно быть послано клиентом только в ответ на сообщение REQUEST-CERTIFICATE сервера. CLIENT-FINISHED (Фаза 2; посылается шифрованным) char MSG-CLIENT-FINISHED Клиент посылает это сообщение, после успешной обработки соответствующего сообщения сервера. Заметим, что клиент должен быть готов к приему сообщений от сервера, пока не получит сообщение SERVER-FINISHED. Данные CONNECTION-ID представляют собой исходный идентификатор соединения сервера, посланный в его сообщении SERVER-HELLO и зашифрованный посредством согласованного ключа сессии. "N" равно числу байт в посланном сообщении, таким образом "N-1" равно числу байт в сообщении за вычетом одного байта заголовка. Для версии протокола 2, клиент должен посылать это сообщение после получения сообщения SERVER-HELLO. Если в сообщении SERVER-HELLO флаг SESSION-ID-HIT не равен нулю, тогда сообщение CLIENT-FINISHED посылается немедленно, в противном случае сообщение CLIENT-FINISHED посылается после сообщения CLIENT-MASTER-KEY. 6.5.2.6. Протокольные сообщения сервера Существует несколько сообщений, которые генерируются только серверами. SERVER-HELLO (Фаза 1; посылается открыто) char MSG-SERVER-HELLO Сервер посылает это сообщение после получения CLIENT-HELLO. Сервер возвращает флаг SESSION-ID-HIT, указывающий, известен ли серверу полученный идентификатор сессии (т.e. хранится ли он в кэше сервера). Флаг SESSION-ID-HIT будет не равен нулю, если клиент посылает серверу идентификатор сессии (в сообщении CLIENT-HELLO с SESSION-ID-LENGTH != 0), а сервер обнаружит этот идентификатор в своем кэше. Если флаг SESSION-ID-HIT не равен нулю, то поля CERTIFICATE-TYPE, CERTIFICATE-LENGTH и CIPHER-SPECS-LENGTH будут содержать код нуль. Значение CERTIFICATE-TYPE, если оно не равно нулю, должно содержать одну из перечисленных выше величин (см. информацию о сообщении CLIENT-CERTIFICATE). Когда флаг SESSION-ID-HIT равен нулю, сервер укладывает свой сертификат, спецификацию шифров и идентификатор соединения и посылает их клиенту. Используя эту информацию, клиент может сформировать ключ сессии и послать его серверу в сообщении CLIENT-MASTER-KEY. Когда флаг SESSION-ID-HIT не равен нулю, как сервер так и клиент вычисляют новую пару ключей сессии, базируясь на мастерном ключе MASTER-KEY, который они получили при создании идентификатора SESSION-ID. SERVER-READ-KEY и SERVER-WRITE-KEY получаются из исходных ключей MASTER-KEY тем же способом, что CLIENT-READ-KEY и CLIENT-WRITE-KEY: SERVER-READ-KEY = CLIENT-WRITE-KEY Заметим, что когда ключи получены и установлен флаг SESSION-ID-HIT, а сервер обнаружил идентификатор сессии клиента в своем кэше, тогда данные KEY-ARG-DATA используются с момента, когда определен идентификатор SESSION-ID. Это делается, потому что клиент не посылает новых данных KEY-ARG-DATA (напомним, что данные KEY-ARG-DATA посланы в сообщении CLIENT-MASTER-KEY). CONNECTION-ID-DATA представляет собой строку случайных байт, используемых сервером и клиентом в разных местах протокола. Сообщение CLIENT-FINISHED содержит зашифрованную версию CONNECTION-ID-DATA. Длина CONNECTION-ID должна лежать между 16 и 32 байтами, включительно. CIPHER-SPECS-DATA определяет тип шифра и длину ключа (в битах), которые поддерживает принимающая сторона. Каждая спецификация SESSION-CIPHER-SPEC имеет длину 3 байта и выглядит как: char CIPHER-KIND-0
Этот список не является исчерпывающим и может быть расширен в будущем. Конфигурации этих средств безопасности стандартизованы (см. табл. 6.5.1). Таблица 6.5.1
Шифр SSL_CK_RC4_128_EXPORT40_WITH_MD5 имеет тип RC4, где некоторые ключи сессии посылаются открыто, а остальные в зашифрованном виде. MD5 используется в качестве хэш-функции для получения MAC и ключей сессии. Этот тип шифра предлагается для поддержки "экспортных" версий (т.e. версий протокола, которые могут быть применены за пределами Соединенных Штатов) клиента или сервера. Экспортные реализации протокола диалога SSL будут иметь длины секретных ключей не более 40 бит. Для не экспортных реализаций длины ключей могут быть больше (рекомендуется, по крайней мере, 128 бит). Клиенты и серверы могут иметь не перекрывающийся набор поточных шифров. Но это означает, что они не могут общаться. Версия 2 протокола диалога SSL определяет, что SSL_CK_RC4_128_WITH_MD5 должен иметь длину ключа 128 бит. SSL_CK_RC4_128_EXPORT40_WITH_MD5 также имеет длину ключа 128 бит. Однако только 40 бит являются секретными (другие 88 пересылаются от клиента к серверу открыто). Сообщение SERVER-HELLO посылается, после того как сервер получит сообщение CLIENT-HELLO, и до того как сервер пошлет SERVER-VERIFY. SERVER-VERIFY (Фаза 1; посылается шифрованным) char MSG-SERVER-VERIFY Сервер посылает это сообщение после пары ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY), согласованных посредством идентификатора сессии или явно через спецификацию сообщения CLIENT-MASTER-KEY. Сообщение содержит зашифрованную копию данных CHALLENGE-DATA, посланных клиентом в сообщении CLIENT-HELLO. "N" равен числу байт в сообщении, которое было послано, таким образом, "N-1" соответствует числу байт в CHALLENGE-DATA за вычетом байта заголовка. Это сообщение используется для верификации сервера следующим образом. Настоящий сервер имеет секретный ключ, который соответствует общедоступному ключу, содержащемуся в его сертификате, переданном в сообщении SERVER-HELLO. Таким образом, настоящий сервер сможет извлечь и реконструировать пару ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY). Наконец, только сервер, который выполнил корректно извлечение и дешифрование может правильно зашифровать CHALLENGE-DATA. Это, по существу, "доказывает", что сервер имеет секретный ключ, который образует пару с открытым ключом из сертификата сервера. Данные CHALLENGE-DATA должны иметь в точности ту же длину, что и в сообщении клиента CLIENT-HELLO. Их значение должно в точности согласовываться с посланным клиентом открыто в сообщении CLIENT-HELLO. Клиент должен дешифровать это сообщение и сравнить полученный результат с тем, что было послано, и только в случае успешного сравнения сервер считается достойным доверия. Если длины не совпадают или не согласуются значения, клиент соединение разрывает. Это сообщение должно быть послано сервером клиенту либо после обнаружения идентификатора сессии (при этом посылается отклик SERVER-HELLO с флагом SESSION-ID-HIT не равным нулю) или когда сервер получает сообщение CLIENT-MASTER-KEY. Это сообщение должно быть послано до любого сообщения фазы 2 или до сообщения SEVER-FINISHED. SERVER-FINISHED (Фаза 2; посылается зашифрованным) Сервер посылает это сообщение, когда он удовлетворен результатом диалога с клиентом по поводу безопасности и готов продолжить передачу/прием протокольных данных верхнего уровня. Кэши идентификаторов сессии должны содержать копию MASTER-KEY, посланного в сообщении CLIENT-MASTER-KEY, в качестве мастерного ключа, предназначенного для генерации всех последующих ключей сессии. Здесь "N" имеет то же значение, что и в определениях, представленных выше. Это сообщение должно посылаться после сообщения SERVER-VERIFY. REQUEST-CERTIFICATE (Фаза 2; посылается шифрованным) char MSG-REQUEST-CERTIFICATE Сервер может выдать этот запрос в любое время диалога второй фазы, требуя присылки сертификата клиента. Клиент немедленно откликается посылкой сообщения CLIENT-CERTIFICATE, если он имеет сертификат, в противном случае присылается уведомление об ошибке с кодом NO-CERTIFICATE-ERROR. CERTIFICATE-CHALLENGE-DATA представляет собой короткую строку байтов (с длиной ³ 16 байт и £ 32 байтам), которую клиент использует для отклика на этот запрос. Значение AUTHENTICATION-TYPE используется, чтобы выбрать конкретные средства для аутентификации клиента. Определены следующие типы:
Тип SSL_AT_MD5_WITH_RSA_ENCRYPTION требует, чтобы клиент сформировал MD5-дайджест сообщения, используя информацию, как это описано выше в разделе о сообщении CLIENT-CERTIFICATE. Раз дайджест сформирован, клиент шифрует его, используя свой секретный ключ. Сервер аутентифицирует клиента, когда получает сообщение CLIENT-CERTIFICATE. Это сообщение может быть послано после сообщения SERVER-VERIFY и до сообщения SERVER-FINISHED. 6.5.2.7. Протокольные сообщения Клиент/Сервер Эти сообщения генерируются как клиентом, так и сервером. ERROR (посылается открыто или зашифровано) char MSG-ERROR Это сообщение посылается, когда обнаружена ошибка. После посылки сообщения, отправитель закрывает соединение. Получатель регистрирует ошибку и затем также разрывает соединение. Это сообщение посылается открыто, если произошла ошибка при согласовании ключа сессии. После того как ключ сессии согласован, сообщения об ошибках шифруются также как и обычные сообщения. Приложение A. ASN.1 синтаксис сертификатов Сертификаты используются SSL для аутентификации серверов и клиентов. SSL Сертификаты базируются в основном на X.509 [3]. Сертификат X.509 содержит следующую информацию (в нотации ASN.1 [1]): X.509-Certificate ::= SEQUENCE { certificateInfo CertificateInfo, CertificateInfo ::= SEQUENCE { version [0] Version DEFAULT v1988, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo } Version ::= INTEGER { v1988(0) } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER,
Сертификаты верифицируются в несколько шагов. Во-первых, проверяется подпись сертификата и, если она некорректна, некорректен и сертификат (произошла транспортная ошибка или попытка модификации). Далее верифицируется поле CertificateInfo::issuer. Там должна быть ссылка на эмитента, которому приложение доверяет. Поле CertificateInfo::validity проверяется на текущую дату и верифицируется. Наконец, проверяется поле CertificateInfo::subject. Эта проверка опционна и зависит от уровня доверия, необходимого приложению, которое использует SSL. Приложение B. Идентификаторы объектов и типов атрибутов SSL использует субнабор X.520 типов атрибутов, а также несколько специфических идентификаторов объектов. Будущие модификации протокола SSL смогут поддерживать больше типов атрибутов и больше идентификаторов объектов. B.1. Выбранные типы атрибутов
B.2. Идентификаторы объекта md2withRSAEncryption { ... pkcs(1) 1 2 } Идентификатор объекта для цифровой подписи, которая используется при шифровании MD2 и RSA. Применяется при SSL-верификации подписи сертификата. md5withRSAEncryption { ... pkcs(1) 1 4 } Идентификатор объекта для цифровой подписи, которая используется при шифровании MD5 и RSA. Применяется при SSL-верификации подписи сертификата. rc4 { ... rsadsi(113549) 3 4 } Алгоритм симметричного поточного шифра RC4, используемый SSL для массового шифрования. Приложение C. Значения протокольных констант Ниже рассмотрены различные протокольные константы. Одна вещь требует особого упоминания - IANA зарезервировала номер порта для "https" (HTTP использующий SSL). Этот порт имеет номер 443. C.1. Коды версии протокола #define SSL_CLIENT_VERSION 0x0002 C.2. Коды протокольных сообщений Определены следующие значения для кодов сообщений, которые используются версией 2 протокола диалога SSL. #define SSL_MT_ERROR 0 C.3. Коды сообщений об ошибках Определены следующие значения для кодов ошибок, используемых в сообщениях ERROR. #define SSL_PE_NO_CIPHER 0x0001#define SSL_PE_NO_CERTIFICATE 0x0002 #define SSL_PE_BAD_CERTIFICATE 0x0004 #define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006 C.4. Значения вида шифра Определены следующие значения для кодов CIPHER-KIND, используемых в сообщениях CLIENT-HELLO и SERVER-HELLO. #define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80 C.5. Коды типа сертификата Определено следующее значение для кода типа сертификации, используемое в сообщениях SERVER-HELLO и CLIENT-CERTIFICATE. #define SSL_CT_X509_CERTIFICATE 0x01 C.6. Коды типов аутентификации Определено следующее значение для кода типа аутентификации, используемое в сообщениях REQUEST-CERTIFICATE. #define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01 C.7. Верхние/нижние ограничения Следующие величины определяют верхние/нижние ограничения для различных протокольных параметров. #define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256 Приложение D: Атаки В данном разделе описываются различные атаки, которые могут быть предприняты против протокола SSL. Этот перечень не может считаться исчерпывающим. SSL показал устойчивость к этим атакам. D.1. Раскрытие шифров SSL зависит от нескольких криптографических технологий. Шифрование с общедоступным ключом RSA [5] используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным. Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем, потратив большое количество компьютерного времени, предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию. Этот подход легче, чем попытка вскрытия криптографии всех возможных сообщений. Заметим, что SSL пытается сделать цену таких атак выше, чем выгоды от успешной атаки, таким образом, делая ее пустой тратой времени и денег. D.2. Атака открытого текста Атака открытого текста производится, когда атакующий имеет соображения о том, какого типа сообщения посылаются зашифрованными. Атакующий может формировать базу данных, где ключами являются зашифрованные строки известного текста (или открытого текста). Раз база данных создана, с помощью простых просмотровых функций можно идентифицировать ключ сессии, который соответствует определенному зашифрованному блоку данных. Если ключ сессии удалось раскрыть, можно дешифровать весь поток данных. Общедоступные аппаратные средства могут сделать эту работу быстрее и эффективнее. Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4. Способ блокирования атак открытого текста заключается в том, чтобы сделать объем необходимого общедоступного оборудования неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в два раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей (решение потребует такого количества атомов, которого нет во всей вселенной). Даже если может использоваться меньший словарь, он должен быть сначала сформирован с использованием открытых битов ключа. Это достаточно время емкий процесс. Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (например, в случае не экспортного варианта). Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей "дикого хакера". D.3. Атака отклика Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента. SSL отбивает эту атаку, с помощью специального кода "nonce" (идентификатор соединения), который является уникальным. Теоретически злоумышленник не может предугадать этот код заранее, так как он основывается на наборе случайных событий, неподвластных злоумышленнику и, следовательно, он не может реагировать адекватно на запросы сервера. Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать "правильную" сессию, основываясь на коде nonce, посланном сервером посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными. D.4. Человек посередине Атака посредника (человек посередине) предполагает участие в коммуникационной сессии трех субъектов: клиента, сервера и посредника-злоумышленника, находящегося между ними. Такое положение позволяет злоумышленнику перехватывать все сообщения, следующие в обоих направлениях, и при желании подменять их. "Посредник" прикидывается сервером для клиента и клиентом для сервера. В случае SSL такая атака невозможна из-за использования сервером сертификатов. Во время диалога об установлении безопасного соединения с сервером необходимо предоставить сертификат, который подписан сертификационным центром. В этом сертификате размещается общедоступный ключ сервера, его имя и имя эмитента сертификата. Клиент верифицирует подпись сертификата, а затем проверяет имя эмитента. Если посредник предоставляет поддельный сертификат, то он не пройдет проверку подписи, так как злоумышленник не может знать секретного ключа сервера. Приложение E: Термины Прикладной протокол Массовый шифр Клиент CLIENT-READ-KEY CLIENT-WRITE-KEY Мастерный ключ MD2 MD2 [8] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Эта функция является предшественницей MD5 [7] [9]. MD5 MD5 [7] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Функция имеет свойства, которые делают ее полезной при обеспечении конфиденциальности, главное из этих свойств - невозможность обратимости.Nonce Регистрируемый информационный обмен Шифрование общедоступным ключом Конфиденциальность RC2, RC4 Сервер Сервером считается приложение субъекта, которое реагирует на запросы установления соединения клиентов. Сервер является пассивным объектом, ожидающим запросов от клиентов. Шифр сессии Шифр сессии является массовым шифром, который пригоден для шифрования или дешифрования произвольного объема данных. Шифры сессии используются в основном по причинам их высоких эксплуатационных характеристик (прежде всего, имеется в виду быстродействие). Шифры сессии, используемые этим протоколом, симметричны. Симметричные шифры предполагают применение одного и того же ключа, как для шифрования, так и дешифрования. Идентификатор сессии Идентификатор сессии является случайным числом, генерируемым клиентом, который идентифицирует таким способом себя серверу. Идентификатор сессии может рассматриваться как средство доступа обоих участников к записанному секретному ключу (в нашем случае к ключу сессии). Если оба партнера помнят идентификатор сессии, тогда считается, что секретный ключ известен и его не нужно согласовывать.Ключ сессии SERVER-READ-KEY SERVER-WRITE-KEY Симметричный шифр Ссылки
Патентное заявление Эта версия протокола SSL базируется на использовании патентованной технологии шифрования с общедоступным ключом, которая служит для аутентификации и шифрования/дешифрования. Процесс стандартизации в Интернет, определенный в RFC 1310, требует письменного заявления от владельца патента, что лицензия предоставляется пользователям на определенных, приемлемых условиях, прежде чем рекомендации будет одобрены в качестве предложения, проекта или стандарта Интернет. Массачусетский Технологический институт и Совет попечителей Стэнфордского университета (Leland) предоставили эксклюзивные права PKP (Public Key Partners) на следующие патенты США и все соответствующие зарубежные патенты: Криптографическое устройство и метод (Diffie-Hellman) No. 4,200,770 Эти патенты объявлены PKP покрывающими все известные методы шифрования с общедоступным ключом, включая вариации, базирующиеся на алгоритме Эль Гамаля. Группа PKP предоставила письменные гарантии Интернет сообществу, что участники могут получить на разумных не дискриминирующих условиях права на использование технологий, покрываемых этими патентами. Эта гарантия представлена в документе RFC 1170 "Public Key Standards и Licenses". Данный документ датирован 20 апреля 1990, и может быть получен в IANA (Internet Assigned Number Authority). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
UP:
6 Сетевая безопасность
|
|
|
|
6.6 Безопасное ядро (SSH)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены "посторонние" машины. Для того чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа "безопасное ядро" SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH использует для шифрования как открытого ключа так и симметричной схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы как telnet, rlogin, rsh и rcp. Эта программа для ЭВМ, на которых установлена, шифрует также и сессии X Windows. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или HTTP. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты. Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата. Для формирования SSH-прокси на удаленном WEB-сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию -L: SSH -L5678:www.pod.potol.com:80 www.pod.potol.com Аргумент, следующий после флага опции -L имеет формат: <локальный порт>:<удаленная ЭВМ>:<удаленный порт>. Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду logout на удаленной ЭВМ. Общедоступную версию SSH можно найти по адресу: www.cs.hut.fi/ssh. Информацию о коммерческих версиях для Windows и Macintosh можно найти на сервере: www.datafellows.com/f-secure. |
|
Previous:
6.5 Протокол SSL. Безопасный уровень соединителей
UP:
6 Сетевая безопасность
|
|
|
|
6.7 Безопасность WEB-серверов
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
WEB-сервер достаточно сложная и потому уязвимая для атак программа. Причем угрозы могут исходить из самых неожиданных мест. Так в конце июня 1997 года было обнаружено, что Windows-95 (и NT) "повисает" (полный перечень причин повисания этой системы может занять целый том) при приходе на ее вход ICMP-пакета с длиной, которая не соответствует значению, указанному в его поле заголовка Длина. WEB-сервер, также как любая сеть должен иметь свою, желательно записанную на бумаге политику безопасности. Это должен быть достаточно простой документ типа приведенного ниже. Доступ к WEB-серверу имеет пять уровней:
Для получения доступа на уровне 3-5 необходимо письменное разрешение директора организации или его заместителя по информационным системам. Доступ уровня 2 автоматически получают все сотрудники организации или фирмы при авторизации. Администраторы могут аннулировать авторизацию по решению заместителя директора по информационным системам, а при чрезвычайных обстоятельствах самостоятельно, но с последующим уведомлением руководства. Работа с локальной консоли WEB-сервера разрешается только администраторам. Удаленная работа администраторам запрещена, они должны работать только с локального терминала. CGI-скрипты устанавливаются на сервер после их проверки и одобрения как минимум двумя членами группы администраторов. Скрипты, исходные тексты которых недоступны, устанавливаются только по решению заместителя директора по информационным системам. Информация из каталогов /private, которая считается конфиденциальной, доступна только с терминала самой ЭВМ. При работе с WEB-сервером не допускается доступ к базам данных или файлам, если для этого не имеется соответствующего разрешения. Описание политики безопасности должно включать указание периода формирования резервных копий содержимого сервера, описания допустимых сетевых услуг и время профилактических остановок. Включается сюда перечень видов обязательного мониторинга сервера и просмотра дневника посещений. Приведенный текст описания политики безопасности может варьироваться в широких пределах, он зависит от используемой ОС и набора сетевых утилит. Наиболее безопасной сетевой средой считается Macintosh OS. Это связано с тем, что она не включает в себя интерпретатора команд, не поддерживает скрипты и не предоставляет каких-либо дополнительных сетевых услуг, неавторизованный просмотр WEB-страниц на Макинтоше практически не возможен. Системы Windows NT и UNIX обладают сопоставимыми и достаточно высокими уровнями безопасности. Большое число сообщений о дефектах безопасности UNIX свидетельствует о его массовом использовании. Теперь рассмотрим, что нужно сделать, чтобы обеспечить максимально возможную безопасность WEB-cервера.
При работе с ОС Windows NT следует отключить доступ TCP/IP от услуг NETBIOS. Это может быть сделано с помощью Firewall, блокировкой доступа к портам 137 и 138 для UDP и TCP. Можно решить эту проблему отключения NETBIOS от TCP/IP драйвера переконфигурировав Windows NT. Если WEB-сервер нуждается в контроле доступа, то в настоящее время (в HTTP/1.1) имеется две возможности. Первая (basic) - предполагает традиционный ввод и передачу по сети имени клиента и пароля. Эта схема проста, но допускает перехват параметров доступа (а между клиентом и сервером может быть достаточно много промежуточных узлов). Вторая схема (digest) для пользователя выглядит аналогично, но вводимое имя и пароль не передаются по сети непосредственно. На их базе формируется дайджест MD5, который пересылается по сети и используется для идентификации клиента. |
|
Previous:
6.6 Безопасное ядро (SSH)
UP:
6 Сетевая безопасность
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.8 Протокол TLS версия 1.0
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
'The TLS Protocol Version 1.0'. T. Dierks, C. Allen. January 1999. RFC-2246. 1. Введение Первоначальной целью протокола TLS (Transport Layer Security) является обеспечение конфиденциальности и целостности данных при коммуникации двух приложений. Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (напр., TCP [TCP]), размещается протокол записей TLS. Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства:
Протокол записей TLS используется для инкапсуляции различных протоколов высокого уровня. Один из таких инкапсулируемых объектов, протокол диалога TLS, позволяет серверу и клиенту аутентифицировать друг друга и согласовать алгоритм шифрования и крипто-ключи до того как приложение передаст или примет первый байт информации. Протокол диалога TLS обеспечивает безопасное соединение, которое имеет три базовых свойства:
Одним из преимуществ TLS является то, что он не зависит от протокола приложения. Протоколы верхнего уровня могут размещаться поверх протокола TLS прозрачным образом. Стандарт TLS, однако, не специфицирует то, как протоколы увеличивают безопасность с помощью TLS; решение о том, как инициализировать TLS-диалог и как интерпретировать сертификаты аутентификации, оставляется на усмотрение разработчиков протоколов и программ, которые работают поверх TLS. 2. Цели Целями протокола TLS в порядке приоритетности являются:
3. Цели данного документа Этот документ и сам протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape. Различие между этим протоколом и SSL 3.0 не значительны, но они вполне достаточны, чтобы сделать TLS 1.0 и SSL 3.0 не совместимыми (хотя TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0). Этот документ предназначен, прежде всего, для читателей, которые будут создавать протокольные приложения, и осуществлять их криптографический анализ. Спецификация была написана именно с такими намерениями и именно для этих двух групп разработчиков. Для этой цели многие правила и структуры данных, зависимые от алгоритма, включены в текст (а не в приложение), обеспечивая более легкий к ним доступ. 4. Язык представления Представление данных в этом документе напоминает синтаксис языка Си и XDR [XDR], но эти параллели достаточно приблизительны и не имеют никакого отношения к самому протоколу TSL. эти представления применены лишь для целей упрощения восприятия материала. 4.1. Базовый размер блока Базовым блоком данных считается один байт (т.e. 8 бит). Многобайтовые информационные элементы представляют собой объединение последовательности байтов слева направо и сверху вниз. Многобайтовые элементы извлекаются из байтового потока (используя нотацию Си) следующим образом: value = (байт[0] << 8*(n-1)) | (байт[1] << 8*(n-2)) | ... | байт[n-1]; Этот порядок байтов для многобайтовых последовательностей является стандартным для сетей (big endian). 4.2. Разное Комментарии начинаются с "/*" и завершаются "*/". Опционные компоненты выделяются с помощью помещения их в двойные квадратные скобки "[[ ]]". Однобайтовые объекты, содержащие не интерпретируемые данные, имеют 'непрозрачный' тип (opaque). 4.3. Векторы Вектор (одномерный массив) является потоком однородных информационных элементов. Размер вектора может быть специфицирован во время документирования или оставаться не специфицированным вплоть до начала работы. В любом случае длина определяет число байтов, а не число элементов в векторе. Синтаксис спецификации нового типа T', который является вектором фиксированной длины типа T, имеет вид T T'[n]; Здесь T' занимает в информационном потоке n байт, где <n кратно размеру T. Длина вектора не включается в кодированный поток. В следующем примере Datum определен, как три последовательные байта, которые не интерпретируются протоколом, в то время как Data представляет собой три вектора Datum, состоящие из девяти байт.
Векторы переменной длины определяются путем спецификации субдиапазона легальных длин, используя нотацию T T' В следующем примере, обязательным является вектор, который должен содержать от 300 до 400 байт непрозрачного типа. Он не должен быть пустым. Поле действительной длины занимает два байта, uint16, достаточных, чтобы представить значение 400 (смотри раздел 4.4). С другой стороны, longer может представить до 800 байт данных, или 400 uint16 элементов, и может быть пустым. Его кодовое представление будет включать два байта поля реальной длины, за которым будет следовать вектор. Длина закодированного вектора должна быть четной, кратной длине одиночного элемента (например: 17-байтовый вектор uint16 будет нелегальным).
4.4. Числа Базовый числовой тип данных представляет собой байт без знака (uint8). Все более длинные типы цифровых данных образуются из фиксированной последовательности байт без знака, объединенных вместе, как это описано в разделе 4.1,. Следующие числовые типы являются предопределенными. uint8 uint16[2]; Все значения здесь и в дальнейшем записываются в 'сетевом порядке' (big-endian); uint32 представленное шестнадцатеричными байтами 01 02 03 04 эквивалентно десятичному значению 16909060. 4.5. Нумерованный тип Еще одним типом данных является enum (enumerated). Поле типа enum предполагает, что величина декларирована при определении. Каждое определение дает новый тип. Только нумерованные элементы того же типа могут присваиваться и сравниваться. Каждому нумерованному элементу должно быть присвоено значение, как это показано в следующем примере. Так как нумерованные элементы неупорядочены, им может быть присвоено любое уникальное значение в любом порядке. enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; Нумерованные элементы занимают в байтовом потоке столько места, сколько требует максимальное определенное порядковое значение. Следующее определение требует использования одного байта для поля типа Color (цвет). enum { red(3), blue(5), white(7) } Color; Можно опционно специфицировать значение без ассоциированной с ним метки, чтобы задать ширину без определения избыточного элемента. В следующем примере, Taste в потоке данных занимает два байта, но может предполагать значения 1, 2 или 4. enum { sweet(1), sour(2), bitter(4), (32000) } Taste; Имена элементов нумерации собраны в пределах определенного типа. В первом примере, полная ссылка на второй элемент будет выглядеть как Color.blue. Такое описание не требуется, если объект присвоения (target) хорошо специфицирован.
Для нумерованных элементов, которые не преобразуются во внешнее представление, цифровая информация может быть опущена. enum { low, medium, high } Amount; 4.6. Сконструированные типы Типы структуры могут быть сформированы для удобства из примитивных типов. Каждая спецификация декларирует новый, уникальный тип. Синтаксис определения весьма похож на используемый в Си. struct {
Поля в структуре могут быть квалифицированы, используя имена типов, которые синтаксис подобный нумерованным элементам. Например, T.f2 относится ко второму полю предыдущей декларации. Структурные определения допускают вложения. 4.6.1. Варианты Определенные структуры могут иметь варианты, базирующиеся на некотором знании того, что доступно в среде. Селектор должен иметь тип нумерованного элемента, который определяет возможные варианты структуры. Телу структуры варианта может быть присвоена метка для ссылок. Механизм, с помощью которого при работе выбирается вариант, языком презентации не определен. struct {
Например: enum { apple, orange } VariantTag;
struct {
struct {
Структуры варианта могут быть подготовлены (сужены) путем спецификации значения селектора до спецификации типа. Например: orange VariantRecord является суженным типом для VariantRecord, содержащего variant_body типа V2. 4.7. Криптографические атрибуты В TSL используются четыре криптографические операции: цифровая подпись, блочное и поточное шифрование и шифрование с помощью общедоступного ключа. Криптографические ключи соответствуют состоянию текущей сессии (смотри раздел 6.1). Алгоритм цифровой подписи включает в себя однопроходные хэш-функции, служащие для преобразования подписываемого текста. Элемент с цифровой подписью кодируется как непрозрачный вектор <0..216-1>, где длина специфицируется алгоритмом подписи и ключом. В подписи RSA, 36-байтовая структура двух хэшей (один SHA и один MD5) кодируется с помощью секретного ключа. Описание кодировки смотри в [PKCS1]. В DSS, 20 байтов хэша SHA передаются непосредственно алгоритму цифровой подписи DSA (Digital Signing Algorithm) без дополнительного хэширования. В результате получаются числа r и s. Подпись DSS представляет собой непрозрачный вектор, содержимое которого представляет собой результат DER-кодирования:
При поточном шифровании, исходный текст сначала объединяется с псевдослучайным кодом идентичной длины (формируется специальным генератором) с помощью операции исключающее ИЛИ. При использовании блочного шифра, каждый блок исходного текста преобразуется в зашифрованный кодовый блок той же длины. Все блочные шифрования выполняются в режиме CBC (Cipher Block Chaining), и все зашифрованные блочные элементы будут иметь размер, кратный длине шифрового блока. При шифровании с использованием общедоступного ключа, алгоритм открытого ключа используется для шифрования данных так, чтобы их можно было дешифровать только с помощью секретного ключа, который образует пару с открытым ключом. Элемент, зашифрованный с помощью открытого ключа, выглядит как непрозрачный вектор <0..216-1>, где длина определяется алгоритмом подписи и ключом. В следующем примере: stream-ciphered struct {
Содержимое хэша передается алгоритму подписи, затем вся структура шифруется с привлечением поточного шифра. Длина этой структуры в байтах будет равна 2 байтам для поля field1 и field2, плюс два байта для длины подписи, плюс длина выходных данных алгоритма подписи. Это известно благодаря тому факту, что алгоритм и ключ для подписи известны до кодирования или декодирования этой структуры. 4.8. Константы Типофицированные константы могут быть определены для целей спецификации путем декларации символа нужного типа и присвоения ему определенных значений. Не полностью специфицированные типы (непрозрачные элементы, векторы переменной длины, и структуры, которые содержат непрозрачные элементы) не могут стать объектами присвоения. Нельзя опускать ни одно поле многоэлементной структуры или вектора. Например, struct { uint8 f1; uint8 f2;} Example1;
5. HMAC и псевдослучайные функции Ряд операций на уровне записей и диалога требуют ключевого MAC; это дайджест определенных данных, защищенных секретным кодом. Фальсификация MAC невозможна без знания секретного кода. Конструкция, которая используется для этой операции, имеет название HMAC и описана в [HMAC]. HMAC может использоваться с разными хэш-алгоритмами. TLS использует ее при диалоге с другими алгоритмами: MD5 и SHA-1, обозначая их как HMAC_MD5(secret, data) и HMAC_SHA(secret, data). Для других шифровых наборов и защищенных данных могут быть определены дополнительные хэш-алгоритмы, но в данной версии протокола для целей диалога жестко заданы MD5 и SHA-1. Кроме того, необходима схема расширения применения секретных кодов (secret) на блоки данных с целью генерации ключей и валидации. Такая псевдослучайная функция (PRF) использует в качестве входной информации секретный код, порождающий код (seed) и идентификационную метку (label). При этом формируется выходной массив произвольной длины. Для того чтобы сделать PRF максимально секретной, она использует два хэш-алгоритма так, чтобы гарантировать секретность при сохранении работоспособности хотя бы одного из них. Сначала, определена функция разложения данных, P_hash(secret, data), которая использует одну хэш функция для распространения секретного кода на произвольное число выходов: P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
где + обозначает объединение.
Для требуемого качества данных P_hash может итерироваться столько раз, сколько нужно. Например: если P_SHA-1 использовался для формирования 64 байт данных, его следует итерировать четыре раза (до A(4)), создавая 80 байт выходных данных; последние 16 байт последней итерации будут отброшены, оставляя 64 байта. PRF TLS создана путем расщепления секретного кода на две части и использования одной половины для генерации данных с помощью P_MD5, а другой половины - для формирования данных посредством P_SHA-1, выходные данных этих двух процедур объединяются затем с помощью операции исключающего ИЛИ. S1 и S2 являются двумя равными по длине половинами секретного кода. Их длина определяется путем округления результата деления исходного секретного кода на два. Таким образом, если исходный секретный код имеет длину в байтах, характеризуемую нечетным числом, то последний байт S1 будет тем же, что и первый байт S2. L_S = длина секретного кода в байтах; PRF определяется как результат смешения двух псевдослучайных потоков с помощью операции исключающее ИЛИ. PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); Метка представляет собой ASCII-строку. Она должна быть включена в исходном виде без байта длины или завершающего нуля. Например: метка "slithy toves" будет представлена в виде: 73 6C 69 74 68 79 20 74 6F 76 65 73 Заметим, что, так как MD5 выдает на выход 16 байт, а SHA-1 - 20 байт, границы их внутренних итераций не будут выровнены; чтобы сформировать на выходе 80 байт P_MD5 осуществит итерации до A(5), в то время как P_SHA-1 - до A(4). 6. Протокол записей TLS Протокол записей TLS является послойным. На каждом уровне, сообщения могут включать поля длины, описания и содержимого. Протокол записей берет сообщения, подлежащие пересылке, разбивает их на блоки, опционно сжимает данные, применяет MAC, шифрует и передает результат. Полученные данные дешифруются, верифицируются, декомпрессируются, восстанавливается их первоначальный вид, результат передается клиентам верхнего уровня. Четыре протокола описаны в данном документе: протокол диалога, протокол уведомления, протокол спецификации изменения шифра, и прикладной информационный протокол. Для того чтобы позволить расширение протокола TLS, разрешена поддержка протоколом дополнительных типов записей. Любые новые типы записей должны размещать значения типа немедленно за величинами ContentType четырех типов, описанных здесь (смотри Приложение A.2). Если реализация TLS получает рекорд нераспознаваемого типа, она должна его игнорировать. Любой протокол, предназначенный для использования поверх TLS, должен быть тщательно сконфигурирован, для того чтобы противостоять любым атакам. Заметим, что из-за того, что тип и длина записи не защищены шифрованием, следует принимать меры, чтобы минимизировать трафик анализа этих величин. 6.1. Состояния соединений Состояние соединения TLS является операционной средой протокола записей TLS. Оно специфицирует алгоритмы сжатия, шифрования и MAC. Кроме того, известны параметры этих алгоритмов: секретный код MAC, а также ключи шифрования и IV соединения для направлений чтения и записи. Логически существует четыре состояния соединения: текущие состояния чтения и записи, и отложенные состояния чтения и записи. Все записи обрабатываются в текущих состояниях чтения или записи. Параметры безопасности для отложенных состояний могут быть установлены протоколом диалога TLS. Протокол диалога может селективно переводить любое отложенное состояние в текущее, при этом соответствующее текущее состояние становится отложенным. Не допускается формировать состояние, которое не инициализировано с учетом параметров безопасности текущего состояния. Исходное текущее состояние всегда специфицировано без компрессии, шифрования или MAC. Параметры безопасности для состояния чтения и записи соединения TLS задаются путем определения следующих величин:
Эти параметры определены в языке представления в виде: enum { server, client } ConnectionEnd; /* Алгоритмы, специфицированные в CompressionMethod, BulkCipherAlgorithm и MACAlgorithm могут быть добавлены. */
Уровень записей будет использовать параметры безопасности для формирования следующих шести объектов: Секретный код MAC записи клиента Параметры записи клиента используются сервером при получении и обработке записей и наоборот. Алгоритм, использованный для генерирования этих объектов с помощью параметров безопасности, описан в разделе 6.3. Раз параметры безопасности определены и ключи сформированы, состояния соединения могут быть в любой момент реализованы путем перевода их в текущее состояние. Эти текущие состояния должны актуализоваться после обработки каждой записи. Каждое состояние соединения включает в себя следующие элементы:
6.2. Уровень записей Уровень записей TLS получает не интерпретированные данные от верхних уровней в непустых блоках произвольного размера. 6.2.1. Фрагментация Уровень записей фрагментирует информационные блоки и превращают их в записи TLSPlaintext, несущие данные в виде последовательностей длиной 214 байтов или меньше. Границы сообщения клиента на уровне записей не сохраняются (т.e., несколько сообщений клиента одного и того же ContentType могут быть объединены в одну запись TLSPlaintext, или одно сообщение может быть фрагментировано). struct { uint8 major, minor;} ProtocolVersion;
struct { ContentType type;
Данные различных типов содержимого уровня записей TLS могут перекрываться. Прикладные данные вообще имеют более низкий приоритет при передаче, чем другие типы содержимого. 6.2.2. Сжатие и восстановление записи Все записи сжаты с использованием алгоритма сжатия, определенным состоянием текущей сессии. Всегда имеется активный алгоритм сжатия; однако в исходный момент он определен как CompressionMethod.null. Алгоритм сжатия преобразует структуру TLSPlaintext в структуру TLSCompressed. Функции сжатия инициализируются информацией по умолчанию при переходе соединения в активное состояние. Должно использоваться сжатие без потерь, а длина содержимого не может стать больше чем 1024 байт. Если функция восстановления встречает фрагмент TLSCompressed.fragment, длина которого окажется больше 214 байт, она должна выдать уведомление о фатальной ошибке преобразования.
Операция CompressionMethod.null является идентификационной; ни одно из полей не изменено. Функции декомпрессии (восстановления) отвечают за то, что внутренний буфер не будет переполнен при обработке сообщения. 6.2.3. Защита поля данных записи Функции шифрования и MAC преобразуют структуру TLSCompressed в TLSCiphertext. Функции дешифрования выполняют обратную процедуру. MAC записи включает также номер по порядку, чтобы было можно детектировать лишние или повторные сообщения.
6.2.3.1. Нуль или стандартный поточный шифр Поточные шифры (включая BulkCipherAlgorithm.null - смотри приложение A.6) преобразуют структуры TLSCompressed.fragment в (или из) структуры TLSCiphertext.fragment. stream-ciphered struct { opaque content[TLSCompressed.length]; MAC генерируется как: HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + где "+" означает объединение (слияние).
Заметим, что MAC вычисляется до шифрования. Поточный шифр преобразует весь блок, включая MAC. Для поточных шифров, которые не используют вектор синхронизации (такой как RC4), состояние шифра записи используется в последующих пакетах. Если CipherSuite равен TLS_NULL_WITH_NULL_NULL, шифрование представляет собой операцию идентичного преобразования (т.e., данные не шифруются, а размер MAC равен нулю, что говорит о том, что MAC не используется). TLSCiphertext.length равна TLSCompressed.length плюс CipherSpec.hash_size. 6.2.3.2. Блочный шифр CBC Для блочных шифров (таких как RC2 или DES), функции шифрования и MAC преобразуют структуры TLSCompressed.fragment в блоки структур TLSCiphertext.fragment или обратно. block-ciphered struct {
MAC генерируется, как это описано в разделе 6.2.3.1.
Длина шифрованных данных (TLSCiphertext.length) на единицу больше чем сумма TLSCompressed.length, CipherSpec.hash_size и padding_length. Пример. Если длина блока равна 8 байт, длина содержимого (TLSCompressed.length) равна 61 байтов, а длина MAC равна 20 байтов, длина до заполнения составляет 82 байта. Таким образом, длина заполнения по модулю 8 должна быть равна 6, для того чтобы сделать полную длину четной, кратной 8 байтам (длина блока). Длина заполнения может быть 6, 14, 22 и т.д. до 254. Если бы длина заполнения была минимально необходимой (6), заполнитель имел бы 6 байтов, каждый из которых содержал число 6. Таким образом, последние 8 октетов GenericBlockCipher до блочного шифрования были бы xx 06 06 06 06 06 06 06, где xx последний октет MAC. Для блочного шифра в режиме CBC (Cipher Block Chaining) вектор инициализации (IV) для первой записи генерируется с другими ключами и секретными кодами, когда параметры безопасности заданы. IV для последующих записей равен последнему блоку шифрованного текста предыдущей записи. 6.3. Вычисление ключа Протокол записей требует алгоритма для генерации ключей, IV и секретных кодов MAC из параметров безопасности, поставляемых протоколом диалога. Мастерный секретный код (master secret) хэшируется в последовательность байтов, которая присваивается секретным кодам MAC, ключам и IV, требуемых текущим состоянием соединения (смотри приложение A.6). CipherSpecs требует чтобы клиент записал секретный код MAC, чтобы сервер записал секретный код MAC, клиент и сервер записали ключ и IV, которые сформированы из мастерного секретного кода в указанном порядке. Не использованные значения остаются пустыми. Для генерации ключей вычисляется key_block = PRF(SecurityParameters.master_secret, "key expansion", до тех пор пока не будет сформирован выход. Затем key_block позиционируется следующим образом: client_write_MAC_secret[SecurityParameters.hash_size] Значения client_write_IV и server_write_IV генерируются только для не экспортных блочных шифров. Для экспортируемых блочных шифров, векторы инициализации генерируются позже, как это описано ниже. Любой лишний материал key_block отбрасывается. Спецификация шифра, которая определена в данном документе, требует 2 x 24 байтовых ключей, 2 x 20 байтовых секретных кодов MAC, и 2 x 8 байтов IV, для 104 байтов материала ключей. Алгоритмы экспортируемого шифрования (для которого CipherSpec.is_exportable равно 'истинно') требуют дополнительной обработки для получения ключей записи, как это показано ниже: final_client_write_key =
final_server_write_key =
Алгоритмы экспортируемого шифрования получают свои IV исключительно из случайных кодов сообщений hello: iv_block = PRF("", "IV block", SecurityParameters.client_random +
Блок iv_block делится на два инициализационных векторов, как это делалось выше для key_block: client_write_IV[SecurityParameters.IV_size] Заметим, что PRF используется в этом случае без секретного кода: это означает, что секретный код имеет длину нуль байт и не вносит ничего в хэширование PRF. 6.3.1. Пример генерации экспортного ключа TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 требует пяти случайных байт для каждого из двух ключей шифрования и 16 байт для каждого ключа MAC, что составляет 42 байта ключевого материала. Выход PRF запоминается в key_block. Блок key_block делится, а ключи записи запоминаются, так как это алгоритм экспортного шифрования.
7. Протокол диалога TLS Протокол диалога TLS содержит набор из трех суб-протоколов, которые используются, чтобы партнеры могли согласовать используемые параметры безопасности для уровня записи, аутентифицировать себя, и уведомлять друг друга об ошибках. Протокол диалога ответственен за согласования характеристик сессии, куда входят следующие объекты:
Эти объекты используются затем для определения параметров безопасности для уровня записей при защите прикладных данных. Многие соединения могут реализоваться в рамках той же сессии с помощью процедуры возобновления (resumption) протокола диалога. 7.1. Протокол изменения спецификации шифра Протокол изменения спецификации шифра предназначен для оповещения об изменении стратегии шифрования. Протокол использует одно сообщение, которое зашифровано и архивировано в рамках текущего состояния соединения. Сообщение состоит из одного байта со значением 1. struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec; Сообщение изменения спецификации шифра посылается как клиентом, так и сервером, для того чтобы уведомить партнера о том, что последующие записи будут защищены с помощью только что согласованных ключей и спецификации CipherSpec. Получение этого сообщения заставляет получателя на уровне записей немедленно скопировать состояние ожидания чтения в текущее состояние чтения. Сразу после посылки сообщения отправитель должен дать команду уровню записей преобразовать состояние ожидания записи в активное состояние записи. (Смотри раздел 6.1.) Сообщение изменения спецификации шифра посылается во время диалога после согласования набора параметров безопасности, но до посылки проверочного завершающего сообщения (смотри раздел 7.4.9). 7.2. Протокол оповещения Одним из типов содержимого, поддерживаемого слоем записей TLS, является оповещение. Сообщения оповещения передают описание возникшей ситуации. Оповещения с аварийным уровнем вызывают немедленное прерывание соединения. В этом случае, другие соединения сессии могут оставаться в рабочем состоянии, но идентификатор сессии должен быть объявлен не действительным, блокируя установление новых соединений. Подобно другим сообщениям, оповещения шифруются и сжимаются, как это специфицировано состоянием текущего соединения. enum { warning(1), fatal(2), (255) } AlertLevel; enum { close_notify(0),
(255)} AlertDescription; 7.2.1. Оповещения закрытия Клиент и сервер должны оба знать, что соединение завершается, для того чтобы избежать атаки усечения (truncation). Оба партнера могут запустить обмен сообщениями закрытия.
Оба партнера могут инициализировать закрытие, послав уведомление close_notify. Любые данные, полученные после оповещения о закрытии, игнорируются. Каждый из партнеров обязан послать уведомление close_notify, прежде чем разрывать соединение со стороны записи. Требуется, чтобы другой партнер реагировал своим уведомлением close_notify и закрывал соединение немедленно, аннулируя все не завершенные записи. Для инициатора закрытия не требуется ждать получения отклика close_notify, прежде чем закрыть соединение со стороны чтения. Если прикладной протокол, использующий TLS, гарантирует, что любые данные могут быть переданы через используемое TLS-соединение после его закрытия, реализация TLS должна получить уведомление-отклик close_notify до оповещения прикладного уровня о том, что соединение TLS завершает свою работу. Если прикладной протокол не передает никаких дополнительных данных, но лишь закрывает ниже лежащее транспортное соединение, тогда реализация может выбрать вариант закрытия транспорта, не дожидаясь отклика close_notify. Предполагается, что закрытие соединения надежно доставляет все данные, ждущие передачи, прежде чем транспортная система будет блокирована. 7.2.2. Оповещения об ошибках Обработка ошибок в протоколе диалога TLS очень проста. Когда обнаруживается ошибка, обнаруживший партнер посылает сообщение другому партнеру. При передаче или получении сообщения о фатальной ошибке, оба партнера немедленно закрывают соединение. Серверы и клиенты должны забыть любые идентификаторы сессии, ключи и секретные коды, связанные с неудачным соединением. Определены следующие оповещения об ошибках:
Для всех ошибок, где уровень оповещения не специфицирован явно, отправитель может сам определить, является ли ошибка фатальной. Если получено оповещение с уровнем предупреждения, получатель может сам решить, воспринимать ли ее как фатальную. Однако все сообщения, которые переданы с фатальным уровнем, должны рассматриваться как фатальные. 7.3. Обзор протокола диалога Криптографические параметры состояния сессии формируются протоколом диалога TLS, который работает поверх уровня записей TLS. Когда клиент и сервер TLS впервые начинают взаимодействие, они согласуют версию протокола, выбирают криптографические алгоритмы, опционно аутентифицируют друг друга и используют методику с общедоступным ключом для формирования общего секретного кода. Протокол диалога TLS включает в себя следующие шаги:
Заметим, что верхние слои не должны слишком полагаться на TLS, всегда согласуя самые безопасные из возможных соединений между партнерами: существует много способов, с помощью которых злоумышленник, включившийся в разрыв соединения, может попытаться заставить партнеров принять наименее безопасный метод связи из числа поддерживаемых ими. Протокол был устроен так, чтобы минимизировать этот риск, но, тем не менее, существуют некоторые возможности атак. Например, хакер может блокировать доступ к порту, через который обеспечивается безопасное обслуживание, или попытаться заставить партнеров установить не аутентифицированное соединение. Фундаментальным правилом является то, что верхние уровни должны знать, каковы требования безопасности и никогда не передавать данные по каналам, которые менее безопасны, чем это предписано этими требованиями. Протокол TLS является безопасным, здесь любой шифровой набор предлагает свой уровень безопасности. Если вы согласуете использование 3DES с 1024-битовым RSA-ключом при связи с ЭВМ, чей сертификат вы проверили, вы можете быть уверены в безопасности. Однако вы никогда не должны посылать данные по каналу, где используется 40-битовая шифрование, если только вы не уверены, что данные не стоят того, чтобы кто-то тратил силы на их дешифрование. Эти цели достигаются протоколом диалога, который может быть суммирован следующим образом. Клиент посылает сообщение hello, на которое сервер должен также откликнуться сообщением hello, в противном случае возникает ситуация фатальной ошибки и соединение разрывается. Сообщения client hello и server hello используются для установления более безопасного взаимодействия клиента и сервера. Сообщения client hello server hello устанавливают следующие атрибуты: версия протокола, ID-сессии, шифровой набор и метод сжатия. Кроме того, партнеры генерируют и пересылают друг другу два случайных числа: ClientHello.random и ServerHello.random. Реальный обмен ключами использует до четырех сообщений: сертификат сервера, ключевой обмен сервера, сертификат клиента и ключевой обмен клиента. Новые методы ключевого обмена могут быть созданы с помощью спецификации формата для этих сообщений, чтобы позволить клиенту и серверу согласовать использование общего секретного кода. Этот секретный код должен быть достаточно длинным. Современные методы ключевого обмена пересылают коды длиной от 48 до 128 байт. Вслед за сообщениями hello, сервер, если он должен быть аутентифицирован, посылает свой сертификат. Кроме того, если необходимо, может быть послано сообщение ключевого обмена (например, если сервер не имеет сертификата, или если его сертификат служит только для подписи). Если сервер аутентифицирован, он может затребовать сертификат от клиента, если выбран соответствующий шифровой набор. После этого сервер пошлет сообщение hello done, указывающее, что фаза диалога hello завершена. Сервер ждет отклика клиента. Если сервер послал сообщение сертификатного запроса, клиент должен послать сообщение сертификата. Сообщение ключевого обмена клиента послано, и его содержимое зависит от алгоритма с общедоступным ключом, который выбрали клиент и сервер при обмене сообщениями hello. В этой точке клиентом посылается сообщение об изменении спецификации шифра, и клиент копирует записанную шифровую спецификацию в текущую спецификацию. После этого клиент немедленно посылает сообщение finished для новых алгоритмов, ключей и секретных кодов. В качестве отклика сервер пошлет свое сообщение об изменении шифровой спецификации, перенесет записанную шифровую спецификацию в текущую, и пошлет свое сообщение finished с использованием новой шифровой спецификации. В этой точке диалог завершается, а клиент и сервер могут начать обмен прикладными данными (смотри блок-схему обмена ниже на рис. .1).
Certificate*
Рис. .1. Обмен сообщениями в процессе диалога * отмечает опционные или зависящие от ситуации сообщения, которые посылаются не всегда.Когда клиент и сервер решают возобновить предыдущую сессию или задублировать существующую сессию (вместо согласования новых параметров безопасности), следует обмен следующими сообщениями: Клиент посылает ClientHello, используя ID-сессии, которая должна быть возобновлена. Сервер проверяет свой кэш сессий на соответствие. Если соответствие имеется, а сервер желает возобновить соединение со специфицированным состоянием сессии, он посылает ServerHello с тем же значением ID-сессии. В этой точке, как клиент, так и сервер должны послать сообщения об изменении шифровой спецификации, после чего перейти к завершающим сообщениям finished. Раз восстановление сессии завершилось, клиент и сервер могут начать обмен прикладными данными. Смотри диаграмму на рис. .2. Если соответствия с ID-сессии не найдено, сервер генерирует новый ID сессии, а клиент TLS и сервер осуществляют полный диалог.
[ChangeCipherSpec]
Рис. .2. Обмен сообщениями для упрощенного диалога 7.4. Протокол диалога Протокол диалога TLS представляет собой один из фиксированных клиентов высокого уровня протокола записей TLS. Этот протокол используется для согласования атрибутов безопасности сессии. Сообщения диалога передаются уровню записей TLS, где они инкапсулируются в одну или более структур TLSPlaintext, которые обрабатываются и передаются так, как это специфицировано текущим состоянием активной сессии. enum { hello_request(0), client_hello(1), server_hello(2),
Сообщения протокола диалога представлены ниже в порядке, в котором они должны быть посланы. Посылка сообщений диалога в неправильном порядке приведет к фатальной ошибке. Ненужные сообщения диалога могут быть опущены. Обратите внимание на одно исключение: сообщение сертификата используется в диалоге дважды (от клиента к серверу, а затем от сервера к клиенту), но оно описано лишь для первого случая его использования. Одно сообщение не привязано к этим правилам порядка обмена, это сообщение запроса Hello, которое может быть послано в любое время, но которое должно игнорироваться клиентом, если приходит в середине диалога. 7.4.1. Сообщения Hello Сообщения фазы hello используются для выяснения возможностей клиента и сервера по повышению безопасности информационного обмена. Когда начинается новая сессия, состояние шифрования уровня записей, алгоритмы хэширования и сжатия инициализируются нулем. Текущее состояние соединения используется для сообщений согласования параметров. 7.4.1.1. Запрос Hello Сообщение-запрос hello может быть послано сервером в любое время. Значение этого сообщения: Запрос Hello является простым уведомлением о том, что клиент должен начать согласование путем посылки сообщения client hello. Это сообщение будет проигнорировано клиентом, если он участвует в сессии согласования. Это сообщение может игнорироваться клиентом, если он не хочет заново согласовывать параметры сессии, или клиент может, если хочет, реагировать уведомлением no_renegotiation. Так как сообщения диалога предназначены для осуществления определенных действий над прикладными данными, ожидается, что согласование начнется до того, как будут получены новые записи от клиента. Если сервер посылает запрос hello, но не получает отклика client hello, он может разорвать соединение с фатальным уведомлением. После посылки запроса hello, серверы не должны повторять запрос до тех пор, пока диалог согласования не завершится. Структура этого сообщения: Это сообщение не должно никогда включаться в хэши сообщений и использоваться в завершающих сообщениях (finished), а также в сообщении верификации сертификатов. 7.4.1.2. Hello клиента Когда клиент инициализирует соединение с сервером, первым должно быть послано сообщение client hello. Клиент может также послать client hello в качестве отклика на запрос hello или по своей собственной инициативе, для того чтобы заново согласовать параметры безопасности существующего соединения. Сообщение hello клиента включает в себя случайную структуру, которая позднее используется протоколом. struct { uint32 gmt_unix_time; opaque random_bytes[28];} Random;
Сообщение client hello включает в себя идентификатор сессии переменной длины. Если это поле не пусто, его значение идентифицирует сессию, чьи параметры безопасности клиент желает использовать повторно. Идентификатор сессии может соответствовать какому-то предшествующему соединению, текущему соединению, или другому активному соединению. Вторая опция полезна, если клиент хочет изменить случайные структуры и получить текущие значения параметров соединения, в то время как третья опция делает возможным установить несколько независимых безопасных соединений без повторения всей процедуры протоколы диалога. Эти независимые соединения могут существовать последовательно или одновременно; SessionID становится действенным, когда диалог согласования завершается обменом сообщениями Finished, и сохраняется до тех пор, пока не состарится или из-за фатальной ошибки в соединении данной сессии. Действительное содержимое SessionID определяется сервером. opaque SessionID<0..32>; Так как SessionID передается без шифрования или MAC-защиты, серверы не должны помещать конфиденциальные данные в идентификаторы сессий, что могло бы привести к возрастанию уязвимости. Заметим, что содержимое диалога в целом, включая SessionID, защищено сообщениями Finished, пересылаемыми в конце диалога. Список CipherSuite, передаваемый от клиента серверу в сообщении client hello, содержит комбинации криптографических алгоритмов, поддерживаемых клиентом в порядке их предпочтения (предпочтительный вариант - первый). Каждый CipherSuite определяет алгоритм пересылки ключей, алгоритм массового шифрования (включая длину секретного ключа) и алгоритм MAC. Сервер выберет шифровой набор или, если приемлемого варианта нет, пришлет уведомление об ошибке и прервет соединение. uint8 CipherSuite[2]; /* Cryptographic suite selector */ Hello клиента включает в себя список алгоритмов сжатия, поддерживаемых клиентом, в порядке их предпочтения. enum { null(0), (255) } CompressionMethod;
После посылки сообщения client hello, клиент ждет сообщения server hello. Любое другое сообщение диалога, присланное сервером, за исключением запроса hello, рассматривается как фатальная ошибка. В интересах прямой совместимости, клиенту разрешено включать в сообщение client hello после методов сжатия дополнительные данные. Эти данные должны быть включены в хэши диалога, в противном случае они игнорируются. Это единственное сообщение диалога, для которого это допускается; для всех остальных сообщений, объем данных должен точно соответствовать описанию сообщения. 7.4.1.3. Hello сервера Сервер посылает это сообщение в ответ на сообщение client hello, когда он может найти приемлемый набор алгоритмов. Если он не может сделать приемлемый выбор, он реагирует уведомлением об ошибке диалога. Структура этого сообщения:
7.4.2. Сертификат сервера Сервер должен послать сертификат, всякий раз, когда согласованный метод обмена ключами не является анонимным. За этим сообщением всегда непосредственно следует сообщение server hello. Тип сертификата должен соответствовать выбранному алгоритму обмена ключами шифров, обычно это сертификат X.509v3. Он должен содержать ключ, который соответствует методу обмена ключами. Если не специфицировано обратного, алгоритм подписи для сертификата должен быть тем же, что и алгоритм для ключа сертификата. Если не специфицировано обратного, общедоступный ключ может иметь любую длину.
Все сертификатные профайлы, ключи и криптографические форматы определены рабочей группой IETF PKIX [PKIX]. Когда присутствует расширение использования ключа, бит digitalSignature должен быть установлен для ключа выбранного для подписи, как это описано выше, а бит keyEncipherment должен присутствовать, чтобы разрешить шифрование, как это описано выше. Бит keyAgreement должен быть установлен для сертификатов Diffie-Hellman. Так как CipherSuites, который специфицирует методы нового ключевого обмена, заданы для протокола TLS, они используют формат сертификата и необходимые ключевые данные. Структура этого сообщения:
Тот же тип сообщения и структура будут использоваться для отклика клиента на сообщение запроса сертификата. Заметим, что клиент может не посылать сертификата, если он не имеет подходящего, чтобы послать его серверу в ответ на его аутентификационный запрос. 7.4.3. Сообщение ключевого обмена сервера Это сообщение будет послано немедленно после сообщения сертификата сервера (или сообщения server hello, если это анонимное согласование параметров). Сообщение ключевого обмена сервера посылается сервером только когда сообщение сертификата сервера (если послано) не содержит достаточно данных, чтобы позволить клиенту осуществлять обмен предмастерными секретными кодами (premaster secret). Это верно для следующих методов обмена ключами: RSA_EXPORT (если открытый ключ в сертификате длиннее, чем 512 бит) Нелегально посылать сообщение ключевого обмена сервера для следующих методов пересылки ключей: RSA Это сообщение передает криптографическую информацию, чтобы позволить клиенту оперировать с premaster секретным кодом: либо общедоступный ключ RSA, чтобы зашифровать предмастерный секретный код, либо общедоступный ключ Diffie-Hellman, с помощью которого клиент может завершить обмен ключами. В качестве дополнительных определены наборы CipherSuites TLS, которые включают в себя новые алгоритмы обмена ключами. Сервер пошлет сообщение обмена ключами тогда и только тогда, когда тип сертификата, ассоциированный с алгоритмов обмена ключами, не предоставил достаточно информации клиенту, чтобы осуществить пересылку предмастерного секретного кода. Согласно настоящему закону США об экспорте, модули RSA больше 512 бит не могут использоваться для ключевого обмена в программах, экспортируемых из США. Более длинные ключи RSA, зашифрованные в сертификатах, могут быть использованы для подписи более коротких ключей RSA в случае метода ключевого обмена RSA_EXPORT. Структура этого сообщения:
struct { opaque dh_p<1..2^16-1>;
struct { select (KeyExchangeAlgorithm) {
enum { anonymous, rsa, dsa } SignatureAlgorithm; select (SignatureAlgorithm)
7.4.4. Запрос сертификата Не анонимный сервер может опционно запросить сертификат от клиента, если это возможно для выбранного шифрового набора. За этим сообщением, если оно послано, непосредственно следует сообщение ключевого обмена сервера (Server Key Exchange) (в противном случае, сообщение сертификата сервера). Структура этого сообщения:
DistinguishedName получается из [X509]. Считается фатальной ошибкой (оповещение handshake_failure), если анонимный сервер запрашивает идентификацию клиента. 7.4.5. Hello done сервера Сообщение сервера hello done посылается сервером, чтобы индицировать конец hello сервера и связанных с ним сообщений. После отправки этого сообщения сервер ждет отклика клиента. Это сообщение означает, что сервер завершил подготовку для ключевого обмена, и клиент может приступить к процедуре пересылки ключей. По получении сообщения сервера hello done клиент должен проверить, что сервер предоставил корректный сертификат, если это требуется, и что параметры, присланные сервером приемлемы. Структура этого сообщения: struct { } ServerHelloDone; 7.4.6. Сертификат клиента Это первое сообщение, которое может послать клиент после получения сообщения от сервера hello done. Это сообщение посылается только в случае запроса присылки сертификата со стороны сервера. Если приемлемого сертификата нет, клиент должен послать пустое сообщение сертификата. Если сервером для продолжения диалога требуется аутентификация клиента, он может откликнуться, послав уведомление о фатальной ошибке. Сертификаты клиента посылаются с использованием структуры сертификата, определенной в разделе 7.4.2. Когда используется метод ключевого обмена, базирующийся на статическом методе Diffie-Hellman (DH_DSS или DH_RSA), если требуется аутентификация клиента, группа Diffie-Hellman и генератор закодированные в сертификате клиента должны соответствовать параметрам Diffie-Hellman'а, специфицированным сервером, если параметры клиента планируется использовать для ключевого обмена. 7.4.7. Сообщение обмена ключами клиента Это сообщение посылается клиентом всегда. За ним непосредственно следует сообщение сертификата клиента, если оно посылается. В противном случае оно будет первым сообщением, посылаемым клиентом после получения сообщения сервера hello done. С помощью этого сообщения устанавливается предмастерный секретный код, либо путем прямой передачи его, зашифровав с применением RSA, либо с помощью передачи параметров Diffie-Hellman, которые позволят каждой из сторон согласовать применение одного и того же предмастерного секретного кода. Когда в качестве метода передачи ключей использован DH_RSA или DH_DSS, запрашивается сертификация клиента, и клиент может откликаться посылкой сертификата, который содержит общедоступный ключ Diffie-Hellman, чьи параметры (группа и генератор) соответствуют, специфицированным в сертификате сервера. Это сообщение не содержит никаких других данных. Структура этого сообщения: Выбор сообщений зависит от выбранного метода ключевого обмена. Смотри раздел 7.4.3, где дано определение KeyExchangeAlgorithm. struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; 7.4.7.1. Сообщение зашифрованного RSA предмастерного секретного кода Если для согласования ключей и аутентификации применен алгоритм RSA, клиент генерирует 48-байтовый предмастерный секретный код, шифрует его с помощью общедоступного ключа из сертификата сервера или временного RSA-ключа, переданного в сообщении ключевого обмена сервера, и посылает результат в сообщении зашифрованного предмастерного секретного кода (encrypted premaster secret). Эта структура является вариантом сообщения ключевого обмена клиента. Структура этого сообщения:
struct { public-key-encrypted PreMasterSecret pre_master_secret;} EncryptedPreMasterSecret; Атака, рассмотренная Даниэлем Блайбенбахером (Daniel Bleichenbacher) [BLEI], может быть предпринята против TLS-сервера, который использует PKCS#1, закодированный с помощью RSA. Наилучший способ избежать уязвимости от этой атаки является обработка некорректно форматированных сообщений точно также как и корректно сформатированные RSA-блоки. Таким образом, когда сервер получает некорректно сформатированный RSA-блок, он должен сформировать случайное 48-байтовое число и использовать его в дальнейшем в качестве предмастерного секретного кода. Таким образом, сервер будет действовать идентично вне зависимости оттого, является ли полученный RSA-блок корректным.
7.4.7.2. Общедоступный Diffie-Hellman-ключ клиента Эта структура передает общедоступную величину (Yc) Diffie-Hellman-алгоритма для клиента, если она не была уже включена в сертификат клиента. Шифрование, используемое для Yc, определяется нумерованным параметром PublicValueEncoding. Эта структура является вариантом сообщения ключевого обмена клиента. Структура этого сообщения:
struct { select (PublicValueEncoding) {
7.4.8. Верификация сертификата Это сообщение используется для осуществления в явной форме верификации сертификата клиента. Оно посылается вслед за сертификатом клиента, который имеет возможность подписи (т.e. все сертификаты кроме тех, которые содержат фиксированные параметры Diffie-Hellman). При посылке это сообщение следует немедленно за сообщением ключевого обмена клиента. Структура этого сообщения имеет вид: Тип подписи определен в 7.4.3. CertificateVerify.signature.md5_hash MD5(handshake_messages); Здесь handshake_messages относятся ко всем сообщениям диалога, посланным или полученным, начиная с hello клиента, и вплоть до (но исключая) данное сообщение, содержащее поля типа и длины сообщений диалога. Это представляет собой соединение всех структур диалога, как это определено в 7.4. 7.4.9. Сообщение Finished Сообщение finished всегда посылается немедленно после сообщения изменения шифровой спецификации, чтобы верифицировать процессы ключевого обмена и аутентификации. Существенно, чтобы сообщение об изменении шрифтовой спецификации было получено между другими сообщениями диалога и сообщением Finished. Сообщение finished является первым, защищенным с использованием только что согласованных алгоритмов, ключей и секретных кодов. Получатели сообщений finished должны верифицировать корректность содержимого. Раз партнер послал свое сообщение Finished и получил корректное сообщение от другой стороны, он может начать посылать и получать через данное соединение прикладные данные. struct { opaque verify_data[12];} Finished;
Если в соответствующей точке диалога за сообщением finished не следует сообщение об изменении шифровой спецификации, это считается фатальной ошибкой. Хэши, содержащиеся в сообщениях finished, посланных серверам, включает в себя Sender.server; а посланные клиентом содержат Sender.client. Значение handshake_messages включает все сообщения диалога, начиная с hello клиента и вплоть до (но не включая) это сообщение finished. Здесь могут быть отличия от handshake_messages из раздела 7.4.8, так как сюда может входить сообщение верификации сертификата. Следует также иметь в виду, что, handshake_messages для сообщения finished, посланного клиентом, будет отличаться от посланного сервером, так как второе, включает первое. Сообщения об изменении шифровой спецификации, уведомления и любые другие типы записей не являются сообщениями диалога и не включаются в вычисления хэшей. В хэши диалога не включаются также сообщения запроса Hello Request. 8. Криптографические вычисления Для того чтобы начать защиту соединения, протоколу записей TLS необходима спецификация набора алгоритмов, мастерный секретный код и случайные коды клиента и сервера. Алгоритмы аутентификации, шифрования и MAC определяются cipher_suite, выбранным сервером и указанным в сообщении server hello. Алгоритм сжатия согласуется в сообщениях hello, а случайные коды пересылаются в сообщениях hello. Все что остается - это вычислить мастерный секретный код. 8.1. Вычисление мастерного секретного кода Для всех методов ключевого обмена используется один и тот же алгоритм преобразования pre_master_secret в master_secret. Значение pre_master_secret следует стереть из памяти, как только завершится вычисление master_secret. master_secret = PRF(pre_master_secret, "master secret", Мастерный секретный код всегда имеет длину 48 байт. Длина предмастерного секретного кода варьируется в зависимости от метода ключевого обмена. 8.1.1. RSA Когда для аутентификации сервера и ключевого обмена используется RSA, 48- байтовый pre_master_secret генерируется клиентом, шифруется с помощью общедоступного ключа сервера и посылается серверу. Сервер использует свой секретный ключ для дешифрования pre_master_secret. Оба партнера преобразуют затем pre_master_secret в master_secret, как это специфицировано выше. Цифровые подписи RSA реализуются с помощью PKCS #1 [PKCS1] с типом блока 1. Шифрование RSA с использованием общедоступного ключа выполняется с помощью PKCS #1 с типом блока 2. 8.1.2. Diffie-Hellman Выполняются обычные вычисления по алгоритму Diffie-Hellman. В качестве pre_master_secret используется согласованный ключ (Z), преобразование его в master_secret, описано выше. Параметры Diffie-Hellman специфицируются сервером и могут быть одноразовыми или взятыми из сертификата сервера. В отсутствии стандарта на прикладной профайл приложение TLS должно использовать шифровой набор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Сообщения прикладных данных вырабатываются уровнем записей, фрагментируются, сжимаются и шифруются на основе параметров состояния соединения. Сообщения рассматриваются как прозрачные данные уровня записей. A. Значения протокольных констант A.1. Уровень записей A.2. Сообщение об изменении спецификации шифра struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec; A.3. Сообщения уведомления (Alert) enum { warning(1), fatal(2), (255) } AlertLevel;
struct { AlertLevel level; AlertDescription description; } Alert; A.4. Протокол диалога enum { hello_request(0), client_hello(1), server_hello(2),
} HandshakeType;
A.4.1. Сообщения Hello struct { } HelloRequest; A.4.2. Аутентификация сервера и сообщения обмена ключами opaque ASN.1Cert<224-1>; A.4.3. Аутентификация клиента и сообщения обмена ключами struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; A.4.4. Завершающее сообщение диалога struct { opaque verify_data[12]; } Finished; A.5. Коды CipherSuite Следующие значения определены кодами CipherSuite, используемыми в сообщениях client hello и server hello. CipherSuite определяет шифровую спецификацию, поддерживаемую в TLS версии 1.0. TLS_NULL_WITH_NULL_NULL специфицировано и является исходным состоянием TLS-соединения во время начала диалога в канале, эта спецификация не согласуется, так как она предоставляет услуги незащищенного соединения. CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; Следующие определения CipherSuite требуют, чтобы сервер предоставлял RSA-сертификат, который можно использовать для ключевого обмена. Сервер может потребовать присылки сертификата RSA или DSS, пригодного для цифровой подписи.
Следующие определения CipherSuite используются для аутентифицированного сервером (и опционно клиентом) алгоритма Diffie-Hellman. DH обозначает шифровой набор, в котором сертификат сервера содержит параметры алгоритма Diffie-Hellman, подписанные провайдером сертификата CA (certificate authority). DHE обозначает временный Diffie-Hellman, где параметры Diffie-Hellman подписаны с помощью DSS- или RSA-сертификата, который подписан посредством CA. Используемый алгоритм подписи специфицирован согласно параметрам DH или DHE. Сервер может запросить от клиента сертификат RSA или DSS, пригодный для подписи, чтобы аутентифицировать клиента. Он может запросить также сертификат Diffie-Hellman. Любой сертификат Diffie-Hellman, предоставленный клиентом должен использовать параметры (группа и генератор), описанные сервером.
Следующие шифровые наборы используются для полностью анонимного обмена с применением алгоритма Diffie-Hellman, в котором ни один из партнеров не аутентифицирован. Заметим, что этот режим уязвим для атак 'посредника' (man-in-the-middle) и по этой причине неприемлем.
Все шифровые наборы, чей первый байт равен 0xFF, рассматриваются частными и могут быть использованы для определения локальных/экспериментальных алгоритмов. Дополнительные шрифтовые наборы могут быть зарегистрированы путем публикации документа RFC, который специфицирует этот набор, включая необходимую протокольную информацию TLS, кодировку сообщений, получение предмастерных секретных кодов, симметричного шифрования, MAC-вычисления и ссылки на описания используемых алгоритмов. Редакционная комиссия RFC по своему разумению может опубликовать и неполное описание шифрового набора, если сочтет, что данное описание представляет определенный интерес. Коды шифровых наборов { 0x00, 0x1C } и { 0x00, 0x1D } зарезервированы, чтобы избежать конфликта с наборами, базирующимися на Fortezza в SSL 3. A.6. Параметры безопасности Эти параметры безопасности определены протоколом диалога TLS и передаются уровню записи TLS, для того чтобы инициализировать состояние соединения. SecurityParameters включают в себя: enum { null(0), (255) } CompressionMethod; /* Алгоритмы специфицированы в CompressionMethod, BulkCipherAlgorithm и MACAlgorithm и могут быть добавлены. */ struct { ConnectionEnd entity; B. Словарь
C. Определения CipherSuite
* Указывает, что IsExportable = истинно
Ограничение на размер ключа характеризуют максимальную длину ключевого общедоступного кода, который может быть легально использован в экспортируемом шифровом наборе.
* Указывает IsExportable = 'истинно'.
D. Замечания о реализации D.1. Временные ключи RSA Экспортные ограничения США устанавливает верхний предел длины ключей RSA равный 512 битам, но не вводят ограничений на размер RSA ключей, используемых для цифровых подписей. Часто нужны сертификаты длиннее 512 бит, так как 512-битные RSA ключи не достаточно безопасны для особо важных транзакций или для приложений требующих долговременной безопасности. Некоторые сертификаты предназначены исключительно для цифровых подписей и не могут использоваться для ключевого обмена. Когда общедоступный ключ в сертификате не может быть использован для шифрования, сервер подписывает временный RSA-ключ, который затем пересылается. В экспортируемых приложениях, временный RSA-ключ должен иметь максимально возможную длину (т.e., 512 бит). Так как 512-битовые RSA-ключи имеют относительно низкую безопасность, они должны часто заменяться. Для обычных коммерческих применений предлагается, чтобы ключи заменялись ежедневно или после каждых 500 транзакций, или даже чаще, если это возможно. Заметим, что, так как допускается многократное использование временного ключа, он должен каждый раз при использовании подписываться. Генерация ключа RSA является трудоемким процессом. Во многих случаях, процессу формирования ключа может быть приписан низкий фоновый приоритет. Как только сформирован новый ключ, старый временный ключ может быть заменен. D.2. Генерация псевдослучайных чисел и стартовые коды (Seeding) TLS требует наличия криптографически безопасного генератора псевдослучайных чисел (PRNG). Должны быть приняты меры для формирования стартовых кодов такого PRNG. Доступны генераторы PRNG, базирующиеся на безопасных хэш операциях, например, MD5 и/или SHA, но они не могут предоставить большую безопасность, чем та, которая определяется размером псевдослучайного генерируемого числа. (Например: генератор, базирующийся на MD5 обычно гарантирует безопасность на уровне 128 бит.) Чтобы оценить необходимую длину порождающего кода, следует добавить несколько битов непредсказуемой информации к каждому байту порождающего кода. Например: времена нажатия клавиш, полученные от стандартного 18.2 кГц PC таймера, может бать 1-2 безопасных бита, но в любом случае размер этого кода должен быть не менее 16 бит. В качестве порождающего кода для 128-битового генератора PRNG может потребоваться приблизительно 100 таких таймерных кодов. Функции порождающих кодов в RSAREF и в версиях BSAFE до 3.0 не имеют порядковой зависимости. Например: если предоставлены 1000 бит порождающего кода, по одному за раз в результате 1000 обращений к этой функции, PRNG окажется в состоянии, которое зависит только от числа 0 или 1 в порождающем коде (т.e., имеется 1001 возможных конечных состояний). Приложения, использующие BSAFE или RSAREF должны предпринимать дополнительные меры для обеспечения нужных порождающих кодов. Это может быть осуществлено путем накопления битов порождающего кода в буфере и обработки их как целое. Нужно только учитывать, что такие меры могут создать автокорреляции кодов. D.3. Сертификаты и аутентификация За верификацию целостности сертификата отвечает приложение, оно должно также поддерживать аннулирование сообщений, содержащих сертификат. Сертификаты должны всегда верифицироваться, чтобы гарантировать корректность подписи (СА). Выбор и добавление доверительных провайдеров сертификатов (СА) следует делать осмотрительно. Пользователи должны иметь возможность просмотреть информацию о сертификате и корневом провайдере сертификатов (CA). D.4. Шифровые наборы TLS поддерживает широкий диапазон размеров ключей и уровней безопасности, включая те, которые предоставляют минимальную или никакой безопасности. Корректная реализация не будет поддерживать много шифровых наборов. Например: 40-битовое шифрование легко ломается, поэтому приложения, требующие надежной безопасности, не должны разрешать применение 40-битовых ключей. Аналогично, анонимный алгоритм Diffie-Hellman не надежен, так как уязвим для атак 'посредников' (man-in-the-middle). Приложения должны накладывать также ограничения на минимальный и максимальный размер ключей. Например: сертификатные цепочки, содержащие 512-битные ключи RSA или подписи не могут считаться удовлетворительными для задач, требующих высокой безопасности. E. Совместимость с SSL По историческим причинам и для того чтобы избежать использования резервных номеров портов, прикладные протоколы, безопасность которых обеспечивается с помощью TLS 1.0, SSL 3.0, и SSL 2.0 часто используют один и тот же порт. Например: протокол HTTPS (HTTP с обеспечением безопасности за счет SSL или TLS) использует порт 443 вне зависимости от того, какой протокол безопасности применен. Таким образом, должен быть определен некоторый механизм согласования применения тех или иных протоколов. TLS версии 1.0 и SSL 3.0 очень схожи. Клиенты TLS, которые желают согласовать применение SSL 3.0, должны посылать серверу сообщения client hello, используя формат записей SSL 3.0 и посылая {3, 1} в поле версии (TLS 1.0). Если сервер поддерживает только SSL 3.0, он откликнется server hello SSL 3.0. Если же он поддерживает TLS, то пришлет отклик TLS server hello. Дальнейшее согласование будет продолжено согласно с выбранным протоколом. Аналогично, TLS-сервер, который хочет работать с клиентами SSL 3.0, должен воспринимать сообщения SSL 3.0 client hello и реагировать на server hello, если получено SSL 3.0 client hello с полем версии равным {3, 0}, означающим, что клиент не поддерживает TLS. Всякий раз, когда клиент уже знает верхний протокол, известный серверу (например, когда возобновляется сессия), он должен инициировать соединение в рамках этого протокола. Клиенты TLS 1.0, которые поддерживают работу с серверами SSL версии 2.0, должны посылать сообщения client hello SSL версии 2.0 [SSL2]. Серверы TLS должны воспринимать любой формат client hello, если они хотят поддерживать работу с клиентами SSL 2.0, на том же порту соединения. Единственное отклонение спецификации от версии 2.0 является возможность специфицировать версию со значением три и поддерживать больше шифровых типов в CipherSpec. Возможность посылать сообщения client hello версии 2.0 следует исключить из употребления так быстро, как это возможно. Разработчики должны предпринять все меры, чтобы ускорить эти работы. Версия 3.0 предоставляет лучшие механизмы для введения новых версий. Следующие шифровые спецификации являются переходными от SSL версии 2.0. Они предполагают использования RSA для ключевого обмена и аутентификации.
Шифровые спецификации совместимые с TLS могут быть включены в сообщения client hello версии 2.0, используя описанный ниже синтаксис. Любой элемент V2CipherSpec с первым байтом равным нулю будет игнорироваться серверами версии 2.0. Клиенты, посылающие любую из перечисленных выше спецификаций V2CipherSpecs должны также включать и TLS-эквивалент (смотри приложение A.5): V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; E.1. Hello клиента версия 2 Сообщение client hello версии 2.0 представлены ниже. Истинные определения предполагаются совпадающими со спецификацией SSL версии 2.0. uint8 V2CipherSpec[3];
Запросы возобновления TLS-сессии должны использовать сообщение TLS client hello. E.2. Избежание атак понижения версии посредником (man-in-the-middle) Когда клиенты TLS возвращаются к режиму совместимости с версией 2.0, они должны использовать специальное форматирование блоков PKCS #1. Это сделано так, что TLS-серверы будут отклонять сессии версии 2.0 с совместимыми TLS-клиентами. Когда клиенты TLS работают в режиме совместимости с версией 2.0, они устанавливают правые случайные 8 байт (менее значимые) заполнителя PKCS (исключая завершающий нулевой заполнитель) для RSA-шифрования поля ENCRYPTED-KEY-DATA CLIENT-MASTER-KEY, равными 0x03 (остальные байты заполнителя содержат произвольные случайные значения). После дешифрования поля ENCRYPTED-KEY-DATA, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом. F. Анализбезопасности Протокол TLS создан для того, чтобы установить безопасное соединение между клиентом и сервером через канал не гарантирующий безопасность. В данном документе делаются несколько традиционных предположений, включая то, что атакующие имеют достаточно большие вычислительные ресурсы и не могут получить секретную информацию из источников, помимо протокольных. Предполагается, что атакующий может перехватить, модифицировать, уничтожать и подменить сообщения, посланные по коммуникационному каналу. F.1. Протокол диалога Протокол диалога несет ответственность за выбор CipherSpec и генерацию мастерного секретного кода (Master Secret), которые вместе являются первичными криптографическими параметрами, сопряженными с безопасной сессией. Протокол диалога может также аутентифицировать партнеров, которые имеют сертификаты, подписанные пользующимся доверием провайдером сертификатов. F.1.1. Аутентификация и обмен ключами TLS поддерживает три режима аутентификации: аутентификация обоих партнеров, аутентификация сервера не аутентифицированным клиентом, и полностью анонимная. Всякий раз, когда сервер аутентифицирован, канал безопасен со стороны атак 'посредника' (man-in-the-middle), по анонимные сессии полностью беззащитны для такого рода атак. Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение сертификата должно предоставить корректную сертификационную цепочку, ведущую к приемлемому провайдеру сертификатов. Аналогично, аутентифицированные клиенты должны предоставить приемлемый сертификат серверу. Каждый партнер ответственен за верификацию сертификата противоположной стороны, за его пригодность. Общей целью процесса ключевого обмена является формирование pre_master_secret, известного партнерами обмена, но неизвестного хакерам. Код pre_master_secret будет использован для генерации master_secret (смотри раздел 8.1). Код master_secret необходим, чтобы сформировать сообщения верификации сертификата, шифровальных ключей, секретных кодов MAC финального сообщения (смотри разделы 7.4.8, 7.4.9 и 6.3). Путем посылки корректного финального сообщения (finished) партнеры подтверждают то, что они знают правильное значение pre_master_secret. F.1.1.1. Анонимный обмен ключами Полностью анонимные сессии могут быть реализованы с помощью ключевого обмена на основе алгоритмов RSA или Diffie-Hellman. При анонимном RSA, клиент шифрует pre_master_secret с помощью не сертифицированного общедоступного ключа сервера, полученного из его сообщения ключевого обмена. Результат посылается в сообщении ключевого обмена клиента. Так как злоумышленники не знают секретного ключа сервера, практически не реально для них дешифровать pre_master_secret. Заметим, что анонимные шифровые RSA-наборы в данном документе не определены. В случае алгоритма Diffie-Hellman, общедоступные параметры сервера содержатся в его сообщении ключевого обмена, а параметры клиента посылаются в его сообщении ключевого обмена. Злоумышленники, которые не знают секретных ключей, не способны выполнить вычисления согласно алгоритму Diffie-Hellman и получить правильный результат (т.e. pre_master_secret). Полностью анонимные соединения предоставляют защиту только против пассивных видов атак. Если только не используется надежно защищенный канал, позволяющий проверку того, что финальное сообщение не подменено злоумышленником, в ситуациях, где возможна активная атака 'посредника' (man-in-the-middle) необходима аутентификация сервера. F.1.1.2. Обмен ключами по схеме RSA с аутентификацией В случае RSA, ключевой обмен и аутентификация сервера совмещаются. Общедоступный ключ может содержаться в сертификате сервера или быть временным RSA-ключом, посланным в сообщении ключевого обмена сервера. Когда используются временные RSA-ключи, они подписываются сертификатом сервера RSA или DSS. Подпись включает текущее значение ClientHello.random, поэтому старые подписи и временные ключи не могут быть повторно использованы. Серверы могут использовать одиночный временный RSA-ключ для нескольких сессий. Опция временного ключа RSA полезна, если серверы нуждаются в больших сертификатах, но вынуждены соглашаться с правительственными регламентациями для размеров ключей при ключевом обмене. После проверки сертификата сервера, клиент шифрует pre_master_secret с помощью общедоступного ключа сервера. В случае успешной дешифровки pre_master_secret и выработки корректного финального сообщения, сервер демонстрирует, что он знает секретный ключ, соответствующий его сертификату. Когда RSA используется для ключевого обмена, клиенты аутентифицируются, используя сообщение верификации сертификата (смотри раздел 7.4.8). Клиент подписывает значение, полученное из master_secret и все предыдущие сообщения диалога. Эти сообщения диалога включают сертификат сервера, который связывает подпись с сервером, и ServerHello.random, связывающий подпись с текущим процессом диалога. F.1.1.3. Обмен ключами по схеме Diffie-Hellman с аутентификацией Когда используется пересылка ключей по схеме Diffie-Hellman, сервер может либо предоставить сертификат, содержащий фиксированные параметры Diffie-Hellman, либо использовать сообщение ключевого обмена сервера, чтобы послать набор временных параметров, подписанных сертификатом DSS или RSA. Временные параметры хэшируются со значениями hello.random до формирования подписи, чтобы гарантировать, что злоумышленник не сможет воспользоваться старыми параметрами. В любом случае клиент может проверить сертификат или подпись, чтобы убедиться в том, что параметры принадлежат серверу. Если клиент имеет сертификат, содержащий фиксированные параметры Diffie-Hellman, его сертификат содержит информацию, необходимую для ключевого обмена. Заметим, что в этом случае клиент и сервер получат один и тот же результат (т.e., pre_master_secret) каждый раз, когда они обмениваются информацией. Чтобы предотвратить пребывание в памяти pre_master_secret дольше, чем это требуется, этот код должен быть, как можно быстрее преобразован в master_secret. Параметры клиента Diffie-Hellman должны быть совместимыми с теми, что поставляются сервером для ключевого обмена. Если клиент имеет стандартный сертификат DSS или RSA или он не аутентифицирован, тогда клиент посылает набор временных параметров серверу в сообщении ключевого обмена клиента, затем опционно использует сообщение верификации сертификата, чтобы аутентифицировать себя. F.1.2. Атаки понижения версии Так как TLS содержит существенные улучшения по сравнению с SSL версии 2.0, атакующие могут попытаться создавать TLS-совместимых клиентов и серверов, чтобы вернуться к версии 2.0. Эта атака может произойти, если (и только если) два TLS-совместимых партнера используют диалог в SSL 2.0. Хотя решение, использующее неслучайное заполнение сообщения блока PKCS #1 типа 2, не является красивым, оно предоставляет безопасный путь для серверов версии 3.0, чтобы заметить такую атаку. Это решение не безопасно по отношению злоумышленников, которые могут попытаться подсунуть ключ и осуществить подмену сообщения ENCRYPTED-KEY-DATA, содержащего тот же ключ (но с нормальным заполнителем) до момента истечения порога ожидания, заданного приложением. Партнеры, озабоченные атаками этого типа, никогда не должны использовать 40-битовые ключи шифрования. Вариация заполнителя младших 8 байт PKCS не увеличивает безопасности, так как это просто эквивалентно увеличению размера входного блока на 8 байт. F.1.3. Регистрация атак против протокола диалога Атакующий может попытаться повлиять на диалоговый обмен, чтобы заставить партнеров выбрать другой алгоритм шифрования, отличный от того, который бы они выбрали сами. Так как многие реализации будут поддерживать 40-битовое экспортное шифрование, а некоторые могут даже поддерживать отсутствие шифрования или алгоритмы MAC, возможность такой атаки должна всегда учитываться. Для этой атаки злоумышленник должен активно изменить одно или более сообщений диалога. Если это произойдет, клиент и сервер вычислят разные значения для хэшей сообщения диалога. В результате, партнеры не воспримут друг от друга финальные сообщения. Без master_secret, злоумышленник не может восстановить финальные сообщения, таким образом, факт атаки будет раскрыт. F.1.4. Возобновляемые сессии Когда соединение установлено путем возобновления сессии, новые значения ClientHello.random и ServerHello.random хэшируются вместе с master_secret сессии. Если установлено, что код master_secret не поврежден и что хэш-операции, использованные для получения ключей и секретных кодов MAC также безопасны, то соединение можно считать безопасным и независимым от предыдущих соединений. Атакующие не могут использовать известные ключи шифрования или секретные коды MAC, для того, чтобы скомпрометировать master_secret без нарушения исполнения операций хэширования. Сессии не могут возобновляться, если только клиент и сервер не хотят этого. Если любой из партнеров подозревает, что сессия скомпрометирована, или что сертификаты не действительны, он должен потребовать полного диалога. Для верхнего предела времени жизни идентификатора сессии предлагается значение 24 часа, так как атакующий, получивший значение master_secret может подменить скомпрометированного партнера пока сохраняется старое значение ID-сессии. Приложения, которые могут работать в относительно небезопасной среде не должны записывать ID-сессии в постоянную память. F.1.5. MD5 и SHA TLS использует хэш-функции весьма консервативно. Где возможно, как MD5, так и SHA используются вместе для того, чтобы не катастрофические дефекты в одном алгоритме не приводили к разрушения всего протокола. F.2. Защита прикладных данных Код master_secret кэшируется с помощью ClientHello.random и ServerHello.random, чтобы получить уникальные ключи для шифрования данных и секретные коды MAC для каждого соединения. Исходящие данные перед посылкой защищаются с помощью MAC. Для того чтобы исключить атаки, связанные с модификаций или воспроизведения сообщений, из секретного кода MAC вычисляется MAC, номер по порядку, длина сообщения, содержимое сообщения и две фиксированные символьные строки. Поле типа сообщения необходимо, чтобы гарантировать то, что сообщения, предназначенные для одного клиента слоя записи TLS, не будут переадресованы другому. Номер по порядку гарантирует, что попытки уничтожить или поменять порядок сообщений будут детектированы. Так как номера по порядку имеют 64 бита, они не могут быть переполнены. Сообщения от одного партнера не могут быть вставлены в выходные сообщения другого, так как они используют независимые секретные коды MAC. Аналогично, ключи записи сервера и клиента независимы, так что ключи поточных шифров используются только раз. Если атакующий расколол ключ шифрования, все сообщения, зашифрованные этим ключом, могут быть прочитаны. Аналогично, раскрытие ключа MAC может сделать возможной атаку, сопряженную с модификацией передаваемых сообщений. Так как MAC зашифрован, атаки модификации сообщений требуют также взлома и алгоритма шифрования. Секретные коды MAC могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивы против повреждений, даже если взломаны ключи шифрования. G. Патентное заявление Следует иметь в виду, что применение ряда алгоритмов ограничено действующими патентами. К их числу относятся, например, SSL (патент США No. 5,657,390; Netscape). Существуют ограничения на коммерческое использование алгоритма RSA (RSA Data Security, Inc.). Политика компании Netscape в этой области достаточно либеральна. Ссылки
Архивы по рассматриваемой тематике смотри на сервере: http://www.imc.org/ietf-tls/mail-archive/ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.7 Безопасность WEB-серверов
UP:
6 Сетевая безопасность
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
6.9 Квантовая криптография
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||
|
Базовой задачей криптографии является шифрование данных и аутентификация отправителя. Это легко выполнить, если как отправитель, так и получатель имеют псевдослучайные последовательности бит, называемые ключами. Перед началом обмена каждый из участников должен получить ключ, причем эту процедуру следует выполнить с наивысшим уровнем конфиденциальности, так чтобы никакая третья сторона не могла получить доступ даже к части этой информации. Задача безопасной пересылки ключей может быть решена с помощью квантовой рассылки ключей QKD (Quantum Key Distribution). Надежность метода зиждется на нерушимости законов квантовой механики. Злоумышленник не может отвести часть сигнала с передающей линии, так как нельзя поделить электромагнитный квант на части. Любая попытка злоумышленника вмешаться в процесс передачи вызовет непомерно высокий уровень ошибок. Степень надежности в данной методике выше, чем в случае применения алгоритмов с парными ключами (например, RSA). Здесь ключ может генерироваться во время передачи по совершенно открытому оптическому каналу. Скорость передачи данных при этой технике не высока, но для передачи ключа она и не нужна. По существу квантовая криптография может заменить алгоритм Диффи-Хелмана, который в настоящее время часто используется для пересылки секретных ключей шифрования по каналам связи. Первый протокол квантовой криптографии (BB84) был предложен и опубликован в 1984 году Беннетом и Брассардом. Позднее идея была развита Экертом в 1991 году. В основе метода квантовой криптографии лежит наблюдение квантовых состояний фотонов. Отправитель задает эти состояния, а получатель их регистрирует. Здесь используется квантовый принцип неопределенности, когда две квантовые величины не могут быть измерены одновременно с требуемой точностью. Так поляризация фотонов может быть ортогональной диагональной или циркулярной. Измерение одного вида поляризации рэндомизует другую составляющую. Таким образом, если отправитель и получатель не договорились между собой, какой вид поляризации брать за основу, получатель может разрушить посланный отправителем сигнал, не получив никакой полезной информации. Отправитель кодирует отправляемые данные, задавая определенные квантовые состояния, получатель регистрирует эти состояния. Затем получатель и отправитель совместно обсуждают результаты наблюдений. В конечном итоге со сколь угодно высокой достоверностью можно быть уверенным, что переданная и принятая кодовые последовательности тождественны. Обсуждение результатов касается ошибок, внесенных шумами или злоумышленником, и ни в малейшей мере не раскрывает содержимого переданного сообщения. Может обсуждаться четность сообщения, но не отдельные биты. При передаче данных контролируется поляризация фотонов. Поляризация может быть ортогональной (горизонтальной или вертикальной), циркулярной (левой или правой) и диагональной (45 или 1350). В качестве источника света может использоваться светоизлучающий диод или лазер. Свет фильтруется, поляризуется и формируется в виде коротких импульсов малой интенсивности. Поляризация каждого импульса модулируется отправителем произвольным образом в соответствии с одним из четырех перечисленных состояний (горизонтальная, вертикальная, лево- или право-циркулярная). Получатель измеряет поляризацию фотонов, используя произвольную последовательность базовых состояний (ортогональная или циркулярная). Получатель открыто сообщает отправителю, какую последовательность базовых состояний он использовал. Отправитель открыто уведомляет получателя о том, какие базовые состояния использованы корректно. Все измерения, выполненные при неверных базовых состояниях, отбрасываются. Измерения интерпретируются согласно двоичной схеме: лево-циркулярная поляризация или горизонтальная - 0, право-циркулярная или вертикальная - 1. Реализация протокола осложняется присутствием шума, который может вызвать ошибки. Вносимые ошибки могут быть обнаружены и устранены с помощью подсчета четности, при этом один бит из каждого блока отбрасывается. Беннет в 1991 году предложил следующий протокол.
Схема реализация однонаправленного канала с квантовым шифрованием показана на рис. .1. Передающая сторона находится слева, а принимающая - справа. Ячейки Покеля служат для импульсной вариации поляризации потока квантов передатчиком и для анализа импульсов поляризации приемником. Передатчик может формировать одно из четырех состояний поляризации (0, 45, 90 и 135 градусов). Собственно передаваемые данные поступают в виде управляющих сигналов на эти ячейки. В качестве канала передачи данных может использоваться оптическое волокно. В качестве первичного источника света можно использовать и лазер.
На принимающей стороне после ячейки Покеля ставится кальцитовая призма, которая расщепляет пучок на два фотодетектора (ФЭУ), измеряющие две ортогональные составляющие поляризации. При формировании передаваемых импульсов квантов приходится решать проблему их интенсивности. Если квантов в импульсе 1000, есть вероятность того, что 100 квантов по пути будет отведено злоумышленником на свой приемник. Анализируя позднее открытые переговоры между передающей и принимающей стороной, он может получить нужную ему информацию. В идеале число квантов в импульсе должно быть около одного. Здесь любая попытка отвода части квантов злоумышленником приведет к существенному росту числа ошибок у принимающей стороны. В этом случае принятые данные должны быть отброшены и попытка передачи повторена. Но, делая канал более устойчивым к перехвату, мы в этом случае сталкиваемся с проблемой "темнового" шума (выдача сигнала в отсутствии фотонов на входе) приемника (ведь мы вынуждены повышать его чувствительность). Для того чтобы обеспечить надежную транспортировку данных логическому нулю и единице могут соответствовать определенные последовательности состояний, допускающие коррекцию одинарных и даже кратных ошибок. Дальнейшего улучшения надежности криптосистемы можно достичь, используя эффект EPR (Binstein-Podolsky-Rosen). Эффект EPR возникает, когда сферически симметричный атом излучает два фотона в противоположных направлениях в сторону двух наблюдателей. Фотоны излучаются с неопределенной поляризацией, но в силу симметрии их поляризации всегда противоположны. Важной особенностью этого эффекта является то, что поляризация фотонов становится известной только после измерения. На основе EPR Экерт предложил крипто-схему, которая гарантирует безопасность пересылки и хранения ключа. Отправитель генерирует некоторое количество EPR фотонных пар. Один фотон из каждой пары он оставляет для себя, второй посылает своему партнеру. При этом, если эффективность регистрации близка к единице, при получении отправителем значения поляризации 1, его партнер зарегистрирует значение 0 и наоборот. Ясно, что таким образом партнеры всякий раз, когда требуется, могут получить идентичные псевдослучайные кодовые последовательности. Практически реализация данной схемы проблематична из-за низкой эффективности регистрации и измерения поляризации одиночного фотона. Неэффективность регистрации является платой за секретность. Следует учитывать, что при работе в однофотонном режиме возникают чисто квантовые эффекты. При горизонтальной поляризации (H) и использовании вертикального поляризатора (V) результат очевиден - фотон не будет зарегистрирован. При 450 поляризации фотона и вертикальном поляризаторе (V) вероятность регистрации 50%. Именно это обстоятельство и используется в квантовой криптографии. Результаты анализа при передаче двоичных разрядов представлены в таблице .1. Здесь предполагается, что для передатчика логическому нулю соответствует поляризация V, а единице - +450, для принимающей стороны логическому нулю соответствует поляризация -450, а единице - Н.
Понятно, что в первой и четвертой колонке поляризации передачи и приеме ортогональны и результат детектирования будет отсутствовать. В колонках 2 и 3 коды двоичных разрядов совпадают и поляризации не ортогональны. По этой причине с вероятностью 50% может быть позитивный результат в любом из этих случаев (и даже в обоих). В таблице предполагается, что успешное детектирование фотона происходит для случая колонки 3. Именно этот бит становится первым битом общего секретного ключа передатчика и приемника. Однофотонные состояния поляризации более удобны для передачи данных на большие расстояния по оптическим кабелям. Такого рода схема показана на рис. .2 (алгоритм В92; R. J. Hughes, G. G. Luther, G. L. Morgan, C. G. Peterson and C. Simmons, "Quantum cryptography over optical fibers", Uni. of California, Physics Division, LANL, Los Alamos, NM 87545, USA).
В алгоритме В92 приемник и передатчик создают систему, базирующуюся на интерферометрах Маха-Цендера. Отправитель определяет углы фазового сдвига, соответствующие логическому нулю и единице (F A=p/2), а приемник задает свои фазовые сдвиги для логического нуля (F B=3p/2) и единицы (F B=p). В данном контексте изменение фазы 2p соответствует изменению длины пути на одну длину волны используемого излучения. Хотя фотоны ведут себя при детектировании как частицы, они распространяются как волны. Вероятность того, что фотон, посланный отправителем, будет детектирован получателем равна
и характеризует интерференцию амплитуд волн, распространяющихся по верхнему и нижнему путям (см. рис. .2). Вероятность регистрации будет варьироваться от 1 (при нулевой разности фаз) до нуля. Здесь предполагается, что отправитель и получатель используют фазовые сдвиги (F A, F B) = (0, 3 p/2) для нулевых бит и (F A, F B) = (p/2, p) для единичных битов (для алгоритма ВВ84 используются другие предположения). Для регистрации одиночных фотонов, помимо ФЭУ, могут использоваться твердотельные лавинные фотодиоды (германиевые и InGaAs). Для понижения уровня шума их следует охлаждать. Эффективность регистрации одиночных фотонов лежит в диапазоне 10-40%. При этом следует учитывать также довольно высокое поглощение света оптическим волокном (~0,3-3ДБ/км). Схема интерферометра с двумя волокнами достаточно нестабильна из-за разных свойств транспортных волокон и может успешно работать только при малых расстояниях. Лучших характеристик можно достичь, мультиплексируя оба пути фотонов в одно волокно [7] (см. рис. .3).
В этом варианте отправитель и получатель имеют идентичные неравноплечие интерферометры Маха-Цендера (красным цветом отмечены зеркала). Разность фаз длинного и короткого путей DT много больше времени когерентности светового источника. По этой причине интерференции в пределах малых интерферометров не происходит (Б). Но на выходе интерферометра получателя она возможна (В). Вероятность того, что фотонные амплитуды сложатся (центральный пик выходного сигнала интерферометра В) равна
Следует заметить, что эта амплитуда сигнала в четыре раза меньше чем в случае, показанном на рис .2. Разветвители пучка (полупрозрачные зеркала) могут быть заменены на оптоволоконные объединители (coupler). Практические измерения для транспортного кабеля длиной 14 км показали эффективность генерации бита ключа на уровне 2,2 10-3 при частоте ошибок (BER) около 1,2%. Библиография
|
|||||||||||||||||||||||||||||
|
Previous:
6.8 Протокол TLS версия 1.0
UP:
6 Сетевая безопасность
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6.10 Идентификатор доступа к сети
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Региональные Интернет сервис-провайдеры (ISP), работающие в пределах определенной области или провинции, стремятся объединить свои усилия с другими региональными провайдерами, для того чтобы обеспечить доступ к Интернет через телефонную сеть в пределах как можно большего пространства. Национальные ISP хотят совмещать свои операции с одним или более ISP в других странах, предлагая телефонный доступ к сети в пределах группы стран или даже континента. Бизнесмены хотели бы предложить своим служащим пакет услуг Интернет на глобальной основе. Эти услуги могут включать помимо традиционного доступа к Интернет, также безопасный доступ к корпоративным сетям через виртуальные частные сети (VPN), используя туннельные протоколы, такие как PPTP, L2F, L2TP и IPSEC в туннельном режиме. Для того чтобы улучшить взаимодействие роуминга и сервиса туннелирования, желательно иметь стандартизованный метод идентификации пользователей. Ниже предлагается синтаксис для идентификаторов доступа к сети NAI (Network Access Identifier). Примеры приложений, которые используют NAI, и описания семантики можно найти в [1]. Здесь используются следующие определения:
Как описано в [1], существует много услуг, использующих телефонный доступ, а число провайдеров, предлагающих такие услуги (в том числе для подвижных пользователей) стремительно растет. Для того чтобы обеспечить большой объем роуминга, одним из требований является способность идентифицировать "домашний" аутентификационный сервер пользователя. Эта функция в сети выполняется с помощью идентификатора NAI, посылаемого пользователем серверу NAS в процессе первичной PPP-аутентификации. Ожидается, что NAS будет использовать NAI как часть процесса открытия нового туннеля, с целью определения конечной точки этого туннеля. Идентификатор доступа к сети имеет форму user@realm (но это не обязательно почтовый адрес). Заметьте, что в то время как пользовательская часть NAI согласуется с BNF, описанной в [5], BNF строки описания области допускает использования в качестве первого символа цифры, что не разрешено BNF, описанной в [4]. Это изменение было сделано с учетом сложившейся в последнее время практикой, FQDN, такое как 3com.com вполне приемлемо. Заметьте, что хозяева NAS могут быть вынуждены модифицировать свое оборудование, чтобы обеспечить поддержку рассмотренного формата NAI. Оборудование, работающее с NAI должно работать с длиной кодов, по крайней мере, в 72 октета. Формальное определение NAI Грамматика для NAI представленная ниже, описана в ABNF, как это представлено в [7]. Грамматика для имен пользователей взята из [5], а грамматика имен областей является модифицированной версией [4].
Примеры правильных идентификаторов сетевого доступа: fred@3com.com Примеры неправильных идентификаторов сетевого доступа: fred@foo В данном разделе определено новое пространство имен, которое должно администрироваться (NAI-имена областей). Для того чтобы избежать создания каких-либо новых административных процедур, администрирование именных областей NAI возлагается на DNS. Имена областей NAI должны быть уникальными и право их использование для целей роуминга оформляется согласно механизму, применяемому для имен доменов FQDN (fully qualified domain name). При намерении использовать имя области NAI нужно сначала послать запрос по поводу возможности применения соответствующего FQDN. Заметьте, что использование FQDN в качестве имени области не предполагает обращения к DNS для локализации сервера аутентификации. В настоящее время аутентификационные серверы размещаются обычно в пределах домена, а маршрутизация этой процедуры базируется на локальных конфигурационных файлах. Реализации, описанные в [1], не используют DNS для поиска аутентификационного сервера в пределах домена, хотя это и можно сделать, используя запись SRV в DNS, что описано в [6]. Аналогично, существующие реализации не используют динамические протоколы маршрутизации или глобальную рассылку маршрутной информации. Ссылки
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
6.9 Квантовая криптография
UP:
6 Сетевая безопасность
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
6 Сетевая безопасность
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Совсем недавно персональная ЭВМ стоила в России дороже автомашины, сегодня же десятки (а может быть и сотни) тысяч ЭВМ работают дома, развлекая и зарабатывая деньги своим хозяевам. Сети ЭВМ из достояния научных центров постепенно стали обязательным атрибутом процветающих торговых фирм, банков, милиции, таможни, налоговые службы и т.д. Если раньше главной проблемой было создание сети и обеспечение доступа к Интернет, то сегодня по мере увеличения размеров сети проблема безопасности выходит на лидирующие позиции. Безопасность - комплексное понятие, это и ограничение нежелательного доступа, и сохранность информации, и живучесть самой сети. Актуальность проблемы подтверждает количество RFC-документов, опубликованных за последнее время [1-14, 18] по данной тематике (см. библиографию в конце данного раздела). Эту статью следует рассматривать как обзор возможных угроз и способов защиты. В основном это касается обычных сетей, не содержащих конфиденциальную или тем более секретную информацию. Но многие соображения, приводимые здесь, носят достаточно универсальный характер. Существуют юридические аспекты сетевой безопасности, организационные и программно-технические. Здесь будут рассмотрены два последних, тем более что следование букве закона не относится к числу главных добродетелей программистов. Рассмотрим сначала факторы, влияющие на надежность сети. Источниками ненадежности сети могут быть:
Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли, и спросить не с кого. Начинать надо с того, что в вашей власти, а это, прежде всего, правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (uninterruptable power supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использовании специального интерфейса и соответствующего программного обеспечения, работающего согласно протоколу SNMP. Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами. С использованием нанотехнологии фирма IBM разработала запоминающее устройство с плотностью записи данных 1 Терабит на квадратный дюйм. Это позволяет записать 25 миллионов страниц или 25 DVD дисков на площади одной почтовой марки. Система использует тысячи сверх тонких иголок из кремния, которые служат для формирования миниатюрных углублений в тонкой синтетической пленке. Вершины иголок имеют размер нескольких атомов (диаметр ≤ 10нм). Технология допускает перезапись.Внедрение этой технологии на какое-то время решит проблему. Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа exabyte емкостью 2.5-20 Гбайт достаточно широко используются, но относительно высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи для них не слишком высока). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более. К сожалению, помимо объективных причин на надежность и устойчивость работы сети влияет и субъективный фактор. Это, прежде всего некомпетентный персонал, различные компьютерные вирусы и хакеры. Скрытая безработица среди высоко квалифицированных программистов способствует распространению хакерства в России. Практическое отсутствие сетевых вирусов связано с ограниченностью сетей в России и со сложностью их написания, но этот барьер будет скоро преодолен и к этому следует готовиться уже сегодня. Еще в декабре 1994 года я получил предупреждение о распространении сетевых вирусов (good times и xxx-1) по Интернет: "there are two virus infected messages circulated in the internet. (Не читайте!! Не загружайте!!! Немедленно уничтожайте!!!!) Или еще один более свежий пример "if you receive an email titled "it takes guts to say jesus" do not open it. it will erase everything on your hard drive. this information was announced yesterday morning from ibm; aol states that this is a very dangerous virus, much worse than "melissa," and that there is no remedy for it at this time." ЭВМ, подключенная к сети, потенциально всегда уязвима. Есть сообщения о вирусе cascade в сетях Novell, созданы вирусы, переносимые с помощью электронной почты (например, вирусы, базирующиеся на макросах WinWord), и т.д. Последние наиболее опасны, так как, проглядывая какое-то очередное сообщение, содержащее приложение (attachment), клиент может и не предполагать, какую угрозу это таит. Макро-вирус может выполнять функцию "троянского коня". Тривиальным и одновременно крайне полезным советом является рекомендация стирать, не читая, сообщения, содержащие исполняемое приложение, даже если это сообщение получено от вашего хорошего знакомого (это может быть рассылка, выполняемая мактро-вирусом, через его адресную книгу). Если есть сомнения, позвоните вашему знакомому, или пошлите ему mail, прежде чем читать подозрительное послание. Троянский конь. К этой категории относят две разновидности объектов. Один из них - программа, засылаемая в атакуемый узел, которая осуществляет перехват всего ввод с терминала, записывает эти данные в файл и позднее пересылает этот файл "хозяину этого коня". Другой объект является пассивным, выглядит безопасным и привлекательным. Например, находится в каталоге FTP-депозитария games и выглядит как игра. Легковерный клиент может скопировать такой файл и попытаться его запустить. Результатом может стать уничтожение содержимого жесткого диска. Кролики. Это программы, которые быстро размножаются в памяти или на диске, поглощая ресурсы ЭВМ, что может привести к повисанию или разрушению операционной системы. Сами по себе эти программы, как правило, не несут в себе разрушительных функций. Черви. Программы, напоминающие "кроликов", но способные перемещаться по сети Интернет от одного узла к другому (узлы должны иметь идентичную операционную среду). Макро вирусы. Вирусы, базирующие на макросах таких систем, как excel или winword. Опасность таких вирусов заключается в том, что они могут разноситься электронной почтой, когда соответствующие файлы подсоединены к почтовому сообщению. Попытка просмотра текста excel или winword приводит к заражению ЭВМ этим вирусом. После чего такая машина может стать сама разносчиком вируса. Из-за простоты заражения этот тип вируса в настоящее время наиболее опасен. Кроме того, он может иметь все свойства "троянского коня", что усугубляет опасность. Все перечисленные программы создавались людьми специально для нанесения вреда, их мотивации предмет изучения психологов и социологов. Но есть потенциально опасные объекты, специально не создаваемые для нанесения вреда. Это, прежде всего, программы, разработанные не профессионалами и не лишенные ошибок. Следует иметь в виду, что любая ошибка в программе опасна сама по себе, но она может стать объектом атаки хакера. По этой причине бездумное использование не сертифицированных программ несет в себе достаточно высокий уровень риска. Существуют и другие угрозы, например, так называемая "Молдавская связь". Суть этой уловки, использованной впервые одним из провайдеров в Молдове, заключается в том, что в каком-то депозитарии или web-странице приводится ссылка на некоторый привлекательный объект, например набор эротических картинок. Но для их просмотра предлагается скопировать себе специальную программу. При запуске оговоренной программы канал связи с местным провайдером разрывается и устанавливается связь через модем с другим удаленным провайдером. Это особенно опасно для людей, подключенных к Интернет через модем, так как может стоить им многие сотни долларов за пользование междугородним телефоном. Многие современные просмотрщики файлов (viewer) и вставные программы (plug-in), предоставляя определенные удобства, несут в себе ощутимые угрозы безопасности. Мало того, что они являются достаточно часто разносчиками вирусов, некоторые из них снабжены интерпретаторами команд. Такие интерпретаторы встраиваются, например, для создания справочной системы, но хакер может ввести туда свои, нужные только ему команды. А некоторые команды могут, скажем, разметить ваш диск. Подводя итоги, можно сказать, что всякая программа, имеющая макро процессор, потенциально опасна. По этой же причине следует избегать применения редактора emacs (UNIX) в качестве внешнего просмотрщика. Опасна и любая программа, способная запустить внешнее приложение. Примером такой программы можно назвать microsoft powerpoint, которая допускает во время презентации запуск любого приложения. Конфигурируя свою систему windows, не желательно объявлять powerpoint в качестве просмотрщика. И чем меньше программ просмотрщиков в системе, тем лучше для ее здоровья. Современные WEB-серверы довольно широко используют java-аплеты. При этом должны строго выполняться определенные правила.
Если все эти условия выполняются, аплеты совершенно безопасны, но контролировать это желательно. При создании протоколов Интернет в начале 80-х годов авторы мало думали о безопасности. Предполагалось, что пользоваться сетью будут исключительно ответственные и добропорядочные люди. Но людям, к сожалению, свойственно преувеличивать свои положительные качества. Реальность оказалась не столь позитивна. Сказалась и любовь получать что-то бесплатно и врожденный разрушительный потенциал. Некоторые приемы хакеров описаны в разделе, посвященном протоколу TCP. Рассмотрим, что может произойти, если будет получен TCP-сегмент с битами SYN и FIN, равными 1. При получении такого сегмента TCP осуществляет переход в состояние close_wait. Если до этого не было установлено соединений, переход в это состояние не должен производиться, но большинство реализаций выполняют его. Такой переход крайне не желателен, так как в этом состоянии не работает таймер и система останется в нем вечно. Другой вид атак протокола TCP называется "syn flooding". Здесь используется трехшаговый диалог при установлении соединения (SYN -> syn+ack -> ack; см. описание протокола TCP в разделе 4.4.3). Когда ЭВМ-1 получает запрос syn от ЭВМ-2, она должна подождать в частично открытом состоянии, по крайней мере, 75 секунд. Это позволяет успешно устанавливать связь даже в условиях очень больших сетевых задержек. Проблема заключается в том, что многие реализации способны отслеживать ограниченное число соединений (по умолчания 5). ЭВМ-злоумышленник может воспользоваться ограниченностью очереди и послать атакуемой ЭВМ большое число SYN-запросов, не отвечая на присылаемые SYN+ACK. В результате очередь будет быстро переполнена и прием запросов на соединение прекратится до тех пор, пока очередь не будет обслужена или очищена по таймауту. Данный метод пригоден для отключения ЭВМ от сети, во всяком случае, на 75 сек. Этот вид атаки часто является частью процедуры проникновения, когда нужно заблокировать ЭВМ от получения нежелательных откликов. Существует разновидность атаки, когда хакер посылает данные в пакетах с адресом отправителя, отличным от его собственного (при этом трудно установить адрес, откуда такая атака предпринимается). Здесь имеются некоторые проблемы для атакующей стороны. ЭВМ-адресат посылает все отклики по указанному адресу отправителя, кроме того, хакеру нужно как-то выяснить порядковый номер сегмента, записываемый в каждый пересылаемый пакет. При установлении соединения оконечный сегмент, содержащий ACK, должен нести ISN (initial sequence number; cм. описание транспортного протокола TCP раздел 4.4.3) удаленной ЭВМ. Этот сегмент посылается ЭВМ, чей адрес указан в первоначальном запросе SYN. Хакер должен выяснить ISN каким-то иным способом (этому может помочь служба netstat). Так как ISN 32-разрядное число случайно угадать его совсем не просто. Но в большинстве систем (например, unix bsd) ISN берется из некоторого счетчика, содержимое которого увеличивается на 128 каждую секунду и на 64 после каждого нового соединения. Например: x -> s: syn(ISNx) Таким образом, установив однажды соединение с нужной ЭВМ (s), некоторое время спустя можно с высокой вероятностью угадать значение ISN, послав несколько пакетов с разными значениями ISN. При завершении процедуры посылается сегмент SYN+ACK, который будет отвергнут, так как машина получатель не инициализировала связь. В пакете отклике будет установлен флаг RST и соединение окажется абортированным. Чтобы этого не произошло, хакер может предпринять атаку типа syn-flooding, что приведет к игнорированию SYN+ACK. В результате соединение будет установлено и хакер, празднуя победу, может продолжить свое черное дело, например, он может исполнить какую-либо r-команду на атакуемой ЭВМ. Если даже изменять ISN каждые 4 микросекунды, проблему угадывания разрешить не удастся. Радикальным решением может стать лишь псевдослучайная генерация ISN-кодов (при этом случайным образом должны задаваться не менее 16 бит). Решить проблему поможет шифрование соответствующей части содержимого пакета. Рассмотрим здесь еще несколько таких атак. Один из известных методов базируется на IP-опции "маршрутизации отправителя" (source routing). ЭВМ инициатор обмена может специфицировать маршрут, которым получатель должен воспользоваться при пересылке отклика. Маршрут может быть специфицирован так, чтобы он проходил через узел, контролируемый хакером. Эта, достаточно простая методика атаки, в настоящее время неэффективна, так как большинство маршрутизаторов сконфигурированы так, чтобы отфильтровывать пакеты с маршрутизацией отправителя. Интересные возможности предоставляет вариант, когда хакер вставляет свою машину на пути обмена двух других узлов (hijacking). Обычные методы атак (типа spoofing) могут не привести к успеху из-за необходимости идентификации (пароль!). В данном методе хакер позволяет завершиться установлению связи и аутентификации и только после этого перехватывает контроль над виртуальным каналом. Этот способ использует механизм "десинхронизации" tcp-соединения. Когда порядковый номер полученного пакета не совпадает с ожидаемым значением, соединение называется десинхронизованным. Полученный пакет в зависимости от его номера будет выброшен или буферизован (если он находится в пределах окна). Таким образом, если узлы, участвующие в обмене сильно десинхронизованы, приходящие к ним пакеты будут отбрасываться. Хакер в этом случае может вводить пакеты с корректными порядковыми номерами. Разумеется, это совсем просто, если машина хакера является транзитной, что позволяет ей "портить" или удалять нормальные пакеты и подменять их своими. Атака же возможна и в случае, когда машина хакера находится где угодно. В этом случае "отброшенные" пакеты могут вызвать посылку ACK, которые содержат ожидаемое значение порядкового номера пакета, но и они будут отвергнуты из-за неверного их номера и т.д.. При реализации этой схемы пересылается большое число "лишних" пакетов ACK. Количество их будет сколь угодно велико, по этой причине данная ситуация называется "штормом ACK'. Обмен уведомлениями (ACK) о неверных ISN будет продолжаться до тех пор, пока один из таких пакетов не будет потерян. Механизм обмена IP-дейтограммами устроен так, что вероятность потери тем выше, чем больше пакетов передается, т.е. процесс саморегулируется. Тем не менее, высокая интенсивность потока сегментов ACK может говорить об атаке. В норме процент сегментов ACK от общего потока TCP составляет 30-45%. Иллюстрацией данного метода нападения может служить рис. 6.1.
Рис. 6.1 Десинхронизация может быть осуществлена при установлении соединения. Хакер в этом случае обрывает процесс трехшагового диалога. После того как ЭВМ Б пошлет SYN+ACK ЭВМ А, ЭВМ хакера пошлет пакет от Б к А, который с помощью бита RST оповещает о закрытии соединения. После этого затевается новый трехшаговый диалог с целью установления соединения с А, но уже с другими кодами порядковых номеров. Схема алгоритма атаки показана на рис. 6.2 (Сравните с рис. 4.4.3.3 и 4.4.3.4). ЭВМ Б проигнорирует сообщения от А, так как они имеют неправильные (навязанные хакером) номера, а ЭВМ А проигнорирует сообщения от Б, так как ожидает, что они будут пронумерованы по-новому. Теперь хакер знает, какие номера нужны А и Б (непосредственно же А и Б взаимодействовать не могут, так как не знают правильных номеров) и может перехватывать, модифицировать или посылать сообщения по своему усмотрению как А, так и Б. Но десинхронизация может быть реализована и в ходе сессии. Если послать флаг RST в середине сессии, соединение будет закрыто, о чем будет оповещено приложение и пользователь. Для того чтобы вызвать десинхронизацию в середине сессии, не закрывая соединения, достаточно поменять порядковые номера в сообщениях. Протокол telnet имеет механизм, который позволяет решить такую задачу. В рамках протокола можно посылать команды nop ("Ничего не делать", согласитесь - хорошие команды!). Эти команды не производят никакого эффекта, но увеличивают ожидаемое значение порядкового номера сегмента. Послав некоторое количество таких команд, ЭВМ хакера вызовет десинхронизацию. Теперь только хакер знает правильные значения порядковых номеров пакетов и может начать свою подрывную работу. Одним из наиболее эффективных методов обнаружения таких атак помимо процента сегментов ACK является сравнение потоков ACK для сервера и клиента. Полной гарантией безопасности в такой ситуации может стать только шифрование на прикладном уровне, например по схеме kerberos. В случае использования почты хороший результат может дать электронная подпись (например, PGP). Атака на раннем этапе установления соединения может осуществляться следующим образом. Соединение при этом разрушается и вместо него формируется новое с другим значением ISN. Хакер прослушивает виртуальный канал и ждет сообщения SYN+ACK от сервера клиенту (вторая фаза установления соединения). При получении такого сообщения хакер посылает серверу RST-кадр, а затем SYN-пакет с теми же параметрами (TCP-порт), но с другим значением ISN (далее и на рис 6.2 этот кадр обозначается a_ack_0; префикс А указывает на принадлежность атакующей машине хакера). Сервер, получив RST, закроет прежнее соединение и, получив SYN, сформирует новое для того же порта, но с новым значением ISN. После чего пошлет клиенту кадр SYN+ACK. Детектировав это пакет хакер посылает серверу кадр ACK. При этом сервер переходит в состояние established. Клиент перешел в это состояние при получении от сервера первого кадра SYN+ACK. На рис. 6.2 не показан обмен пакетами ACK, вызванными получением некорректных значений ISN. Как сервер так и клиент находятся в несинхронизованном состоянии established. Обмен здесь полностью контролируется атакующей ЭВМ
Рис. 6.2. Алгоритм атаки с использованием десинхронизации. Префикс А указывает на то, что сегмент послан атакующей ЭВМ; С - клиентом; s - сервером. Отправка атакующих кадров выделена малиновым цветом. Определенные услуги хакеру может оказать внутренний протокол маршрутизации rip. Этот протокол служит для рассылки информации о маршрутах в локальной сети и не требует контроля доступа, что всегда благоприятствует злоумышленникам. Хакер может разослать маршрутную информацию, которая убедит окружающие узлы в том, что наикратчайший путь во внешний мир проходит через ЭВМ хакера Х. Тогда все пакеты, адресованные за пределы локальной сети, будут сначала попадать в ЭВМ Х. Протокол управляющих сообщений ICMP носит вспомогательный характер (вспомним популярную утилиту ping, использующую этот протокол). Пакеты ICMP также не требуют проверки доступа (именно благодаря этому протокол пригоден для работы в масштабах Интернет). По одной этой причине протокол привлекателен для хакеров. Известны случаи, когда с его помощью люди с разных континентов бесплатно обменивались сообщениями. Пригоден протокол и для блокировки обслуживания. Для блокировки обслуживания используются icmp-сообщения "time exceeded" (превышено время) или "destination unreachable" (адресат недоступен). Первое сообщение означает, что предел указанный в поле TTL заголовка пакета превышен. Такое может произойти из-за зацикливания пакетов или, когда адресат расположен очень далеко. Сообщение "destination unreachable" имеет несколько значений. Но все они означают, что нет способа благополучно доставить пакет адресату. Оба сообщения вынуждают адресата немедленно прервать соединение. Для реализации своих коварных планов хакеру достаточно послать одно из этих сообщений одному или обоим участникам обмена. Протокол ICMP может использоваться и для перехвата пакетов. ICMP-сообщение "redirect" обычно используется внешними портами (gateway) сети в случаях, когда какая-то ЭВМ по ошибке полагает, что адресат находится вне локальной сети и направляет пакеты, адресованные ему, через внешний порт. Хакер может послать ICMP-сообщение "redirect" и вынудить другую ЭВМ посылать пакеты через узел, указанный хакером. У данного метода (также как и предыдущего с использованием RIP) имеется определенное ограничение - хакер и жертва должны находиться в пределах общей локальной сети. Ещё одним объектом атак может стать DNS (domain name service) локальной сети. Например, администратор узла durak.dura.com может принять решение разрешить только местные соединения. Это может быть специфицировано с помощью записи "allow *.dura.com", а не обязательно через указание IP-адресов. Тем более, что в сети может использоваться большое число блоков IP-адресов. Когда соединение установлено ЭВМ durak обращается к DNS для того, чтобы преобразовать IP-адрес отправителя в имя, которое затем служит для проверки условия, заданного администратором. Если хакер имеет доступ к местному DNS-серверу, он может заставить DNSоткликаться на его IP-адрес любым именем ЭВМ или домена. Зная об установленных администратором ограничениях, хакер может сделать так, что на запрос с его IP-адресом DNS будет откликаться именем "trustme.dura.com" (что удовлетворяет установленному ограничению). Такая атака может быть легко предотвращена путем повторного DNS-запроса с именем ЭВМ, присланным при первом запросе. Если IP-адрес, полученный при втором запросе, не совпадет с использованным в качестве параметра в первом, это означает, что DNS подверглась атаке. Для атаки DNS извне достаточно узнать номер используемого UDP порта и ISN. О способах определения ISN говорилось выше. Задача упрощается в тех случаях, когда начальным значением ISN является нуль. Номер же используемого в данный момент UDP-порта при определенном везении можно найти путем подбора, ведь здесь нет никакой аутентификации или ограничений на число попыток. DNS один из самых привлекательных объектов для атак, так как через посредство AXFR-запросов можно получить информацию об узлах, которые используют определенные версии ОС с известными слабостями, упрощающими вторжение. Точкой уязвимости могут быть загружаемые через сеть рабочие станции или Х-терминалы. Процедура загрузки предполагает использование протоколов RARP, TFTP и BOOTP. Все они практически не имеют сколько-нибудь серьезной защиты. Наиболее уязвим протокол RARP. Здесь желательно позаботиться о том, чтобы номер порта udp выбирался ЭВМ, осуществляющей загрузку случайным образом. В противном случае хакер может легко перехватит процедуру обмена и загрузить нужную ему конфигурацию программного обеспечения, обеспечив себе широкие ворота для проникновения. bootp предлагает дополнительные возможности защиты в виде 4-байтного случайного кода идентификатора процедуры (transaction ID). Это заметно мешает хакеру прервать процедуру и инициировать новую сессию загрузки (rebooting). Должны быть предприняты все меры, чтобы начатая процедура загрузки была своевременно завершена. Пребывание системы в промежуточном состоянии заметно облегчает разнообразные атаки. Некоторые другие виды атак описаны в разделе, посвященном протоколу http. Многие из перечисленных выше проблем решаются при использовании прокси серверов типа firewall . Но даже Firewall не может предотвратить атак со стороны хакеров, работающих внутри локальной сети. Здесь к их услугам огромный арсенал. Это, прежде всего, использование сетевого интерфейса для приема всех пакетов, следующих по сегменту (6-ой режим работы интерфейса), а также программные продукты типа tcpdump или Etherfind. Такой режим легко позволяет перехватывать незашифрованные пароли, определять используемые номера портов или ISN. К счастью такой комфорт для хакера предоставляется в пределах его логического сегмента, что стимулирует, кроме всего прочего, использование мостов, переключателей и локальных маршрутизаторов, которые ограничивают зону, где хакер может осуществлять перехваты. По этой же причине рекомендуется авторизованным администраторам работать с консоли, а не удаленного терминала. Следует иметь в виду, что обнаружить такого "шалуна" не так просто, ведь он может во многих случаях указывать в посылаемых пакетах не свой IP- и MAC-адрес. Еще одним инструментом взлома может оказаться протокол ARP. Хакер может послать большое число широковещательных запросов, содержащих несуществующий IP-адрес. ЭВМ при получении такого запроса должна его обработать и может попытаться его переадресовать какому-то серверу. Всё это уже само по себе нежелательно, так как порождает большой паразитный трафик. Помимо этого хакер может попытаться послать широковещательный отклик, сообщая свой MAC-адрес в качестве адреса места назначения. Это может при определенных условиях предоставить возможность перехвата трафика между ЭВМ, пославшей первичный запрос, и истинным узлом назначения. Таким образом, постоянный мониторинг широковещательных запросов следует считать одной из составных частей системы безопасности локальной сети (см. также Robert T. Morris, A Weakness in the 4.2bsd Unix TCP/IP Software, Computer Science Technical Report N 117, at&t Bell laboratories), тем более что такой мониторинг не пораждает дополнительного трафика. Определенную пользу с точки зрения безопасности может принести программы типа wrapper , которая позволяет отфильтровать нежелательные запросы и решить проблему аутентификации. Новые возможности в этой сфере предоставит новая версия протокола IPv6. Некоторые проблемы могут быть решены путем шифрования содержимого пакетов. Применение сетей расширяется со скоростью 20% в месяц. Внешний трафик мультинациональных организаций увеличивается со скоростью 30% в год, а только за 1996 год сетевые воры украли ценной информации на сумму более 10 млн. долларов США (www.cuviello.com/_potrfolio/_semaphore). Число зарегистрированных попыток нелегального проникновения в информационные системы растет экспоненциально, достигнув темпа прироста 60% в год. Но нужно принимать во внимание, что существенная часть таких попыток остается незамеченной или незарегистрированной. Адекватны этому и темпы роста расходов крупных фирм на средства и системы информационной безопасности. Следует, впрочем иметь в виду, что чем лучше сеть (или ЭВМ) защищена от хакеров, тем менее удобно в ней работать. Поэтому администратор сети всегда должен выбирать меньшее из зол, нельзя же делать лечение более опасным, чем сама болезнь. Хакер, пытающийся нелегально проникнуть в ЭВМ, обычно начинает с использования процедуры Finger, чтобы определить имена реальных пользователей сети или ЭВМ (имя одного пользователя обычно известно - это root). Администратор сети-жертвы может заблокировать работу Finger. Но именно этот протокол наряду с SMTP используется системами Whois, X.500 и FRED при поиске людей в сети Интернет. Заблокировав Finger, администратор усложняет общение с внешними сетями. Есть все же правила, следовать которым должен любой администратор. Среди них жесткое требование к выбору паролей и регулярной их смене является наиважнейшим. Известно, что 80% всех проблем, связанных с нелегальным проникновением в сеть, вызваны плохими паролями. Пароль должен содержать не менее 5-7 символов. Желательно, чтобы он включал в себя строчные и прописные символы, а также цифры. Любые имена, фамилии, общеизвестные географические названия, названия улиц, номер страхового полиса, кредитной карточки, домашний номер телефона (записанные обычным образом или задом на перед), последовательности клавишей типа qwerty или абвгд и т.д. совершенно непригодны в качестве паролей, так как их подбор, например, с помощью программы satan занимает не более 5 минут. Наиболее важные части системы могут быть защищены двойным паролем, но даже это не дает полной гарантии. Во-первых, имеется возможность перехвата ваших пакетов (например, с помощью программы tcpdump или ее аналога), когда вы вводите свой пароль с удаленного терминала. Во-вторых, существуют программы типа "троянского коня", которые, будучи засланы в многопользовательскую систему, перехватывают весь ввод с терминалов, записывают их в виртуальные файлы и спустя какое-то время пересылаются "хозяину коня". На этом арсенал орудий взлома не исчерпывается. Одним словом, если у вас имеется информация, доступ к которой не желателен, не храните ее в ЭВМ, подключенной к Интернет (или любой другой аналогичной сети). Следует иметь в виду, что "шалуны" могут быть и среди ваших коллег или друзей. Никогда ни при каких обстоятельствах не следует передавать свой пароль кому бы то ни было. Если это в вашей власти, помогите просящему получить к ЭВМ легальный доступ, но не передавайте пароль. В моей практике был случай, когда один программист из ИТЭФ передал свой пароль своему другу. Этот друг ради баловства через узел ИТЭФ заслал троянского коня в амстердамский телекоммуникационный узел. Факт засылки стал известен (для обнаружения используется программный пакет cops) и администратор сети прислал нам в институт оповещение об этом досадном инциденте. Были приняты административные меры к человеку, передавшему свой пароль (он был лишен определенных привилегий и доступа к ряду ЭВМ). Вряд ли какой-либо администратор мечтает о славе пособника сетевым террористам. Безопасность сети определяется ее администратором. Именно он должен позаботиться о распределении ответственности между пользователями и администраторами ЭВМ и субсетей, именно он определяет конфигурацию программного обеспечения узла, вырабатывает меры на случай вторжения или повреждения системы. Администратор сети формулирует требования к сетевым паролям и контролирует их выполнение, определяет время жизни паролей (рекомендуемое время замены паролей равно 3-6 месяцам, новый пароль должен радикально отличаться от старого). В тех случаях, когда ЭВМ помимо терминальных входов имеет доступ через модемы, используются, кроме того, так называемые "телефонные пароли" (dialup passwords). В этом случае во время процедуры logon помимо имени-идентификатора и пароля вводится также и телефонный пароль. Этот пароль является общим для всех пользователей на данной машине. Управляет этой процедурой исполняемый файл /etc/dpasswd. Программа имеет ряд опций. Сами пароли хранятся в закодированном виде в файле /etc/d_passwd. Если идентификация пользователя по названным выше трем параметром не увенчалась успехом, пользователю будет предложено повторить процедуру без указания того, какой из параметров введен неверно. Для того чтобы контролировать, кто, когда и сколько времени провел в вашей ЭВМ, имеется файл-дневник (log-файл), где производятся соответствующие записи (например, /etc/wtmp). В таблице 6.1 размещены ссылки на различные log-файлы. Таблица 6.1.
Одной из мер безопасности в локальной сети может быть кодировка всех пакетов, посылаемых с удаленных терминалов. Для реализации этого надо модифицировать все сетевое программное обеспечение или оснастить сеть специальными аппаратными средствами. Принимая во внимание, что в России используется на 99% зарубежное сетевое программное обеспечение, а денег на специальное оборудование безопасности обычно не предусмотрено в бюджете, этот путь представляется пока не самым удобным. Шифрование предполагает две процедуры - собственно кодирование информации с использованием секретного ключа и пересылка секретного ключа. Для передачи секретных ключей, паролей доступа (если их нужно пересылать) и идентификации партнеров, участвующих в обмене (а это иногда крайне важно, достаточно вспомнить посылку ложной телеграммы графом Монте-Кристо) используется схема с открытым и секретным ключами или алгоритм Диффи-Хелмана. Схема с шифрованием проще реализовать для корпоративных сетей, т.е. для сетей принадлежащих одной фирме или отрасли (см. также раздел 6.5 и 6.6 ). Аналогичная схема может успешно использоваться между партнерами, которые заранее согласовали метод и ключи шифрования. Шифровка-дешифровка может проводиться аппаратным или программным образом для текстов или даже самих пересылаемых пакетов. Здесь предполагается наличие механизма пересылки ключей, подтверждения их получения и т.д. Шифрование не заменяет другие меры безопасности, так как несанкционированное вторжение может привести к потере или повреждению файлов, а в особо тяжелых случаях к разрушению всей операционной системы. В unix имеется две команды для шифрования - DES (data encryption standard) и crypt. Последняя команда базируется на старом методе кодирования, использованном в немецкой шифровальной машине enigma времен второй мировой войны. Обе программы имеют сходный формат применения и требуют ключ, который представляет собой последовательность символов, аналогичную паролю. Для указания ключа служит опция -k. Опция -e задает режим шифрования, -d - дешифрования. Так как программа crypt обеспечивает заметно меньшую защиту, чем DES, можно сначала архивировать файл, например, с помощью программы tar. На системах шифрования базируются некоторые почтовые системы, например, PGP (pretty good privacy) или PEM. Современные системы электронных подписей и конфиденциальной электронной почты основаны обычно на открытом и секретном ключах, эта технология (шифрование открытым ключом) базируется на криптографическом алгоритме Rivest-Shamir-Adelman'а (RSA). Эти ключи формируются попарно и являются математически связанными. Первый может пересылаться по обычным (открытым) каналам связи и используется для шифрования отправителем, а второй (секретный) - не пересылается и служит только для дешифрования получателем. Следует учитывать, что применение шифрования в России регулируется специальными законами. Желательно, чтобы любые два объекта в сети общались друг с другом с использованием индивидуального набора ключей. Если в сети имеется n объектов, то необходимое число ключей равно [(n-1)*n]/2 (для n=100 это число равно 4950). Скрытое и эффективное хранение такого числа ключей само по себе уже может представлять проблему (а если n равно 1000!). К сожалению, алгоритм RSA работает довольно медленно, по этой причине для шифрования больших объемов информации используются алгоритмы только с одним ключом (секретным), например, технология DES, которая способна гарантировать приемлемое быстродействие для шифрования и дешифрования в реальном масштабе времени. Секретный ключ DES пересылается с использованием техники шифрования RSA. RSA техника удобна для взаимной идентификации узлов до начала информационного обмена и для программ автоматического управления генерацией и распределением ключей дешифровки в сетях с большим числом объектов. Существуют и аппаратные средства шифрования и контроля доступа, как отечественные, так и зарубежные (например, RG xxx комплекты фирмы racal или оборудование компании semaphore). Использование аппаратных средств может сохранить пропускную способность сети при введении шифрования/дешифрования неизменной. Особо эффективными для блокировки нелегального доступа могут быть специальные кодовые карточки, которые можно использовать и в случае удаленного доступа через коммутируемую телефонную сеть. Интернет - открытая система, поэтому любые системы защиты плохо сочетаются с идеологией этой сети. Но Интернет может реально обеспечить любой уровень защиты уже сегодня. Рассмотрим одну из наиболее распространенных схем защиты (рис. 6.3).
Рис. 6.3. Сначала формируется традиционный TCP-канал (для Telnet, FTP или SMTP). Этот канал используется для обмена командами. Далее управление передается блоку безопасности, который формирует отдельный канал для обмена шифрованной информацией (например, Kerberos). Перед началом обмена блок выясняет наличие аналогичного блока у партнера. Практически такая схема может быть реализована с использованием алгоритма Нидхама-Шрёдера (Needham-Schroeder). Здесь каждая ЭВМ использует общий ключ с сервером аутентификации. При необходимости установить соединение ЭВМ получает ключ от сервера и пересылает его адресату соединения (возможно в зашифрованном виде). Схема может работать с секретными и общедоступными ключами. Атака здесь затруднена не только из-за применения шифрования но и благодаря наличию дополнительного агента, участвующего в процессе соединения (сервера аутентификации). Функции такого сервера может взять на себя DNS. Конечно, не следует исключать возможности атаки на сервер аутентификации (например, с помощью подбора ISN). Многие процедуры в Интернет не требуют для своего выполнения пароля, именно это обстоятельство создает еще одно окно уязвимости для сетей. Но и в случаях аутентификации с использованием пароля проблемы остаются. Если пароль передается в незашифрованном виде, он может быть легко перехвачен. Определенный интерес здесь может представлять и применение системы одноразовых паролей (например, skey). Суть этой технологии заключается в том, что после конфигурирования системы для очередной процедуры идентификации клиентом и сервером генерируется новый пароль. Перехват самого пароля в этом случае теряет смысл, так как воспользоваться им уже не возможно, а восстановить алгоритм формирования паролей даже по результатам достаточно большого числа перехватов практически не реально. Некоторые сетевые запросы (например, в HTTP) могут нести в себе пароли. Помимо перехвата таких сообщений имеется возможность использования их для подбора пароля, так как здесь часто нет ограничений на число попыток. Распознавание "свой-чужой" можно организовать непосредственно на пакетном уровне. Такая возможность предусмотрена в протоколе SNMP (поле community). Но возможно создание специального программного обеспечения, где все без исключения пакеты будут идентифицироваться. Для этого предусмотрены специальные коды для поля тип протокола (сети Ethernet). Например, для передачи шифрованных пакетов: UDP IP - 11; TCP/IP - 06; DEC LAT - 6004 и XNS - 0600. В последнее время широкое распространение получают индивидуальные сертификаты пользователя (см., например, www.verisign.com). Такие сертификаты эквивалентны высоконадежной электронной подписи идентифицирующей отправителя сообщения. Создавая сеть, следует сразу закладывать некоторые элементы, обеспечивающие безопасность. Так прокладку сетевых кабелей желательно производить в металлических коробах, что сделает подключение к ним более затруднительным, или, там где это целесообразно, использовать оптоволоконные кабели. Повторители и концентраторы нужно размещать в запираемых шкафах. Некоторые концентраторы контролируют MAC-адреса пакетов. Такое оборудование позволяет блокировать порт, если обнаруживаются пакеты с неизвестным MAC-адресом, а также выявлять случаи подключения одного и того же MAC-адреса к разным портам. Определенную угрозу сетевой безопасности может представлять возможность присвоения хакером "чужого" MAC-адреса своей сетевой карте. Современные концентраторы запрещают подключенному к порту узлу передавать кадры с MAC-адресом, не совпадающим с определенным администратором для данного порта. Это обеспечивает дополнительную надежность канального уровня. Как же можно определить, подверглась ли ваша ЭВМ атаке или нет? (Последующие рекомендации относятся к ОС UNIX). Начинать надо с просмотра log-файла (см. ниже описание утилиты last). Но следует иметь в виду, что отсутствие подозрительных записей в этом файле не является гарантией безопасности. Хакер может без труда отредактировать этот файл. Следующим шагом должен стать поиск любых спрятанных файлов. При этом нужно позаботиться о наличии копии всех рабочих системных и пользовательских файлов. Хакер может оставить каталоги с необычными именами типа ".", ". " (три точки + три пробела), ".xxx", ".mail", которые неопытный пользователь может принять за системные. Целесообразно контролировать неизменность базовых системных файлов, таких как logon, telnet и др., так как хакер, видоизменив их, может предоставить себе свободный доступ в систему. Полезно контролировать дату действующей версии таких программ. Далее следует просмотреть файл /etc/inetd.conf на предмет внесения в него каких-либо модификаций. Не рекомендуется разрешать в этом файле услуги типа: systat - порт 11; tftp - порт 69 и link - порт 87. Прежде всего следует искать строки, которые могут исполнять программы ядра (например, /bin/sh или bin/csh). Нужно проверить также все программы, на которые имеются ссылки в файле /etc/inetd.conf, так как хакер может заменить их и встроить в них программы типа троянского коня. Надо внимательно изучить содержимое файла /etc/hosts.equiv, /etc/hosts.lpd (эти файлы не должны допускать запись кому угодно) на наличие в них нелокальных имен ЭВМ, а также все файлы ~/.rhost в особенности ~root, ~uucp, ~ftp и другие программы, допускающие запись извне. В случае обнаружения несанкционированного вторжения следует исследовать и другие ЭВМ, подключенные к сети. Нужно просмотреть файл /etc/passwd и выявить изменения, внесенные в него за последнее время. Особое внимание должно быть уделено авторизации новых пользователей. Если ваша машина использует услуги UUCP, проверьте файл L.cmds. Он должен содержать только те команды, которые вам действительно нужны. Этот файл должен принадлежать root (а не uucp). Не следует оставлять без внимание содержимое файлов /etc/ttytab, /etc/ttys, а также /users/lib/aliases и любые другие файлы, определяющие конфигурацию системы. Везде, где возможно, нужно установить соответствующий уровень доступа к каталогам. Определенного успеха в деле повышения защиты сети можно добиться, используя ограничения допуска. Маршрутизаторы и ЭВМ, имеющие контроль доступа, сверяют адрес отправителя запроса со списком доступа. Если адрес содержится в разрешительном списке, доступ реализуется, в противном случае запрос отвергается. Такие возможности предусмотрены в маршрутизаторах фирмы CISCO, имеются они и в некоторых сетевых пакетах UNIX (например, пакет wrapper). Этот пакет осуществляет мониторинг всех интернетовских и обычных сетевых запросов. Программа wrapper доступна по адресу: FTP:cert.sei.cmu.edu/pub/network_tools/tcp_wrapper.shar. Файл содержит исходный текст на языке Си и Makefile для генерации демона wrapper, который имеет имя tcpd. В указанном выше депозитарии в каталоге info можно найти документ DOD 5200.28-std "Trusted Computer System Evaluation Criteria", представляющий собой стандарт, который регламентирует общие принципы сетевой безопасности. Целесообразно мониторировать доступ к fingerd, ftpd, tftpd, rshd, rlogind, rexecd и telnetd. Если вы строите защищенную систему, следует использовать статические таблицы маршрутизации. Должна быть заблокирована возможность добавления маршрутов по умолчанию в процессе загрузки системы. Регулярно просматривайте маршрутные таблицы с помощью команды netstat -nr. При выборе программного обеспечения для защищаемой сети следует тщательно изучить его особенности, ведь авторы программ могут оставить "люки" (недокументированные обходы системы защиты) или предусмотреть универсальный ключ дешифровки сообщений. Абсолютных систем защиты не существует и вряд ли такие системы появятся в будущем. Но можно создать защиту, стоимость взлома которой не окупится. Именно к этому и следует стремиться (люди любопытны, но достаточно ленивы). Помимо Finger, хорошую службу хакеру может сослужить программа TFTP (ведь она не требует пароля), если с помощью ее доступен файл /etc/passwd, где в закодированном виде хранятся все пароли. Заполучив этот файл, хакер сможет заняться подбором паролей на своей ЭВМ, благо для этой цели имеется немало программ. Желательно вообще закрыть доступ пользователей к TFTP, закомментировав, например, соответствующую запись в файле inetd.conf. Полезно также удалить systat и link. В новейших версиях ОС пароли хранятся в "теневых" файлах, недоступных для обычных пользователей. Для проверки добротности паролей администратор сети может воспользоваться программами npasswd, passwd+ или SATAN. Программа npasswd проверяет соответствие паролей определенным требованиям перед их запоминанием в соответствующем файле. Среди параметров, контролируемых npasswd, содержится минимальное число символов в пароле, список нелегальных кодов (например, последовательности повторяющихся символов типа "wwww"). Программа контролирует отсутствие в пароле персональной информации, доступной с помощью Finger, проверяет наличие в пароле цифр и букв верхнего и нижнего регистров, а также общеупотребительных слов из словаря. Программа доступна по адресу: FTP://ftp.cc.utexas.edu/pub/npasswd.tar.Z. (см. также [14-16] в конце этой главы). Программа passwd+ выполняет аналогичные функции, но предоставляет более гибкий набор средств тестирования паролей. passwd+ имеет специальный язык, позволяющий реконфигурировать систему контроля паролей. Конфигурация записывается в файл /etc/password.test (UNIX). Программа SATAN (работает с ОС UNIX, в настоящее время доступна версия 1.1.1) была создана для подбора ("вскрытия") паролей, но в умелых руках она может стать эффективным средством выбора надежных паролей и выявления непригодных. При использовании системы SATAN или других аналогичных программных продуктов нужно проявлять особую осторожность. Такие системы имеют встроенную систему защиты, но перехват, например, ключа сессии, может открыть доступ хакеру ко многим паролям пользователей. Эти программы для запуска требуют, как правило, системных привилегий. Защищенность сети зависит от конфигурации программного обеспечения. Для ОС UNIX определенную угрозу предоставляют так называемые r-команды. Эти команды используют файлы /etc/hosts.equiv и .hosts. Следует проверить эти файлы и /etc/hosts.ltd на наличие символа (+). Нужно помнить, что файл .hosts имеется в каталоге каждого пользователя. Если в вашей сети используется UUCP, удалите все неиспользуемые команды из файла L.cmds, выполните команды chown root L.cmds, chown uucp L.sys и chmod 600 L.sys. Эти меры сделают вашу систему более устойчивой против нежелательных вторжений. Корректная конфигурация NFS и sendmail сделает систему еще безопаснее. Дальнейшей безопасности будет способствовать сокращение списка системных (secure) терминалов (файлы /etc/ttys и /etc/ttytab). Но само по себе этого недостаточно - администраторы должны постоянно контролировать ситуацию. Для этого рекомендуется регулярно выполнять команды who и ps, которые сообщают список активных пользователей и процессов. Команды ps -aux для BSD и ps -ef для System 5 выведут на экран список пользователей, которые инициировали активные процессы. Вы можете также воспользоваться командой ls -lR, чтобы просмотреть принадлежность и уровни доступности файлов в каталоге. Хакеры часто оставляют на диске файлы, чтобы облегчить себе в будущем доступ или обеспечить системные привилегии. Для контроля ситуации следует время от времени выполнять команду ls -a | grep '^\.', которая ищет файлы, начинающиеся с символа точка. Хакеры часто полагают, что пользователь воспримет файлы типа .mail или .xxxx как системные, и не будет беспокоиться. Если вами найдены файлы, вызывающие подозрения, следует немедленно проконсультироваться с администратором сети. Объектом самого пристального внимания должны быть файлы /etc/inetd.conf, /etc/hosts.equiv, /etc/hosts.ltd, /etc/passwd и .rhosts. Доступ к ним должен быть ограничен, их копии полезно хранить в недоступном месте. Полезно также записать в отдельный файл основные параметры ваших рабочих файлов, это позволит вам заметить факт их модификации. Чтобы обнаружить "сюрпризы", оставленные непрошеными визитерами, можно воспользоваться командой find / -user root -perm -4000 -print, которая ищет файлы, принадлежащие root и устанавливающие уровень привилегий -4000. Команда Find может использоваться для проверки уровня доступа к жизненно важным файлам (-perm -2 или -perm -2000), a также файлов без определенного хозяина (-nouser -o -nogroup). Последние файлы должны быть удалены. Странная активность в системе в необычное время суток, в необычные дни или с неизвестного удаленного терминала должна вызывать пристальное внимание. Для контроля активности в ЭВМ (UNIX) служит команда last. Эта команда отображает содержимое файла /usr/adm/wtmp, где содержится информация о том кто, когда и откуда заходил в систему. Ниже приведен небольшой фрагмент результата работы команды last.
Записи располагаются от настоящего к прошлому, что видно из предлагаемого отрывка. В колонке <Имя пользователя> и <терминал> в случае "анонимного FTP" помещается метка FTP. Так как обычно результат работы команды last занимает десятки страниц, бывает полезно воспользоваться командой grep, чтобы просмотреть отдельные фрагменты файла /usr/adm/wtmp, отвечающие определенным критериям. Например: last | grep '03:'(поиск входов в систему межу 3 и 4 часами утра)
........................................ Пользователю не важно, по какой причине он не получил своевременно важное сообщение, или почему реакция сети вдруг стала равной нескольким секундам. А такие вещи могут происходить из-за установки неоптимальных параметров сети (TTL, MTU, window и т.д.), в результате перегрузки сетевого сегмента (что может произойти, если один из пользователей разорвет кабельный сегмент) или из-за потока широковещательных запросов. Дестабилизация сети может происходить по причине зацикливания пакетов или осцилляций маршрутов. Зацикливание пакета возможно при установке маршрутов по умолчанию типа A -> B и B -> A, когда в системе появляется пакет с ошибочным адресом. Возможно это и при установке параметра вариация > 1 во внутреннем протоколе маршрутизации IGRP. Осцилляции маршрутов свойственны системам с динамическими протоколами маршрутизации при неверной установке таймеров. Источником потока широковещательных запросов может стать IP-мост, по обе стороны которого появились идентичные IP-адреса, или неисправное оборудование (например, сетевой принтер). Администратор должен отслеживать ситуацию и при возникновении нештатного ее состояния, с помощью диагностической программы выявить и устранить причину. Вы можете быть защищены системой Firewall, использовать шифрование при обменах и т.д., но, если ваш персональный компьютер время от времени доступен для посторонних - он совершенно не защищен. Злоумышленник, вооруженный бутабильной дискетой, может стартовать ЭВМ и, обойдя, таким образом, необходимость ввести пароль, скопирует или сотрет нужные ему файлы. Несколько улучшит ситуацию конфигурация, которая требует ввода пароля на фазе загрузки системы (SYSKEY; Microsoft), а также запирание корпуса ЭВМ и порта флоппи-диска (если это предусмотрено). Если у злоумышленника достаточно времени, он может просто снять с вашей машины жесткий диск, поставить его на свою машину, и сделать все, что ему нужно. Так что какой-то гарантией безопасности может служить лишь надежный запор на помещении, где находится ваша ЭВМ. Для мониторирования безопасности ЭВМ создан специальный набор программ COPS (Computer Oracle Password and Security). COPS контролирует доступ к файлам, каталогам и оборудованию, содержимое файлов /etc/passwd, /etc/group, /etc/hosts.equiv и .hosts, а также регистрирует изменения состояния SUID. После завершения всех проверок результат посылается в виде почтового сообщения системному администратору. Программы COPS доступны по адресу: cert.sei.cmu.edu/pub/cops.tar.Z Существует несколько подписных листов и депозитариев, аккумулирующих и распространяющих информацию по сетевой безопасности:
SUB VIRUS-L <ваше полное имя>. Немало полезной информации по проблематике сетевой безопасности можно найти в группе новостей comp.security.announce и в анонимных депозитариях: nic.merit.edu, pyrite.rutgers.edu, sparkyfs.erg.sri.com, ftp.win.tue.nl, info.cert.org, ftp.ucar.edu, ftp.ee.lbl.gov и т.д. (последние два адреса относятся к диагностическим сетевым программам). Антивирусные программы можно найти во многих анонимных депозитариях, там же обычно есть разделы и по сетевой безопасности, например, www.ynet.com, http://www.esat.kuleuven.ac.be (система SESAME) или ftp://ftp.compapp.dcu.ie/pub/sesame и т.д. В таблице 6.2 приведены ссылки на серверы, посвященные проблематике безопасности и смежным областям. Таблица 6.2. URL серверов по проблематике безопасности
Библиография по проблематике сетевой безопасности
Безопасность вещь относительная. Для того чтобы конкретизировать обсуждаемый предмет, введены четыре уровня безопасности, обозначенные латинскими буквами A-D. Каждый из уровней поделен на субуровни, обозначаемые соотвествующей буквой и цифрой (например, А1, А2, А3 или D1, D2 и т.д.). Уровню D1 соответствует DOS, где пользователь имеет доступ ко всем системным ресурсам и программам. Владельцем файлов является текущий пользователь. С-уровень предлагает большую безопасность, чем D-уровень. На С-уровне пользователь должен быть идентифицирован, прежде чем он получит доступ к своим файлам. Стандартная система UNIX с канонической схемой доступа (login/password) относится к уровню безопасности С1. Уровень С2 включает возможность блокировать для пользователя исполнение некоторых команд, если не выполняются определенные условия. При этом пользователь не может также контролировать определенные операции, которые имеют место. Многие современные UNIX-системы, в частности SCO-UNIX, могут обеспечивать безопасность на уровне С2. В-уровень дает еще большие гарантии безопасности, запрещая пользователю изменять условия доступа для файлов. Очень не многие операционные системы и практически ни одна коммерчески доступная система не обеспечивают такого уровня безопасности. Но при выборе уровня безопасности следует учитывать, что повышение надежности неизбежно уменьшает удобство пользования системой, так что обычно приходится идти на определенный компромисс. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
5.5 Конфигурирование сетевых систем
UP:
5 Диагностика локальных сетей и Интернет
|
|
|
|
6.1 Технические средства сетевой безопасности
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли и спросить не с кого. Начинать надо с того, что в вашей власти, а это прежде всего правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (Uninterruptable Power Supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При снижении напряжения сети переменного тока ниже определенного уровня UPS (около 208v) отключает потребителя от сети и осуществляет питание ЭВМ от ~220v, получаемого от аккумулятора самого UPS. Учитывая нестабильность напряжения сети в России, можно считать полезным применение активных стабилизаторов на входе UPS. При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использование специального интерфейса и соответствующего программного обеспечения, работающего согласно протокола SNMP(см. рис. 6.1.1).
Рис. 6.1.1. Схема подключения UPS. При исчезновении первичного напряжения ~220V спустя некоторое время UPS выдает сигнал shutdown вычислительной машине. Современный UPS может мониторировать не только напряжение питание, но температуру окружающей среды, своевременно осуществляя спасение жизненно важных файлов до наступления чрезмерного перегрева системы. При этом значение напряжения питания и температуры можно считывать с использованием протокола SNMP. Некоторые продвинутые системы автономного питания допускают подключение агентов SNMP непосредственно к локальной сети, что открывает дополнительные возможности дистанционного управления и мониторинга. Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами. Создавая сеть, следует сразу закладывать некоторые элементы, обеспечивающие безопасность. Так прокладку сетевых кабелей желательно производить в металлических коробах или трубах, что сделает подключение к ним более затруднительным. Повторители и концентраторы нужно размещать в запираемых шкафах. Некоторые концентраторы контролируют MAC-адреса пакетов. Такое оборудование позволяет блокировать порт, если обнаруживаются пакеты с неизвестным MAC-адресом, а также выявлять случаи подключения одного и того же MAC-адреса к разным портам. Определенную угрозу сетевой безопасности может представлять возможность присвоение хакером "чужого" MAC-адреса своей сетевой карте. Современные концентраторы запрещают подключенному к порту узлу передавать кадры с MAC-адресом, не совпадающим с определенным администратором для данного порта. Это обеспечивает дополнительную надежность канального уровня. Активные разработки в последнее время ведутся в области систем идентификации, базирующихся на распознавания отпечатков пальцев, ладони, подписи или голоса. Для этих целей используются новейшие достижения в области быстрых Фурье-преобразований, нейронных сетей и пр. В качестве вводных устройств используются оптические сканеры, а также резистивные экраны. Для ввода подписи служат специальные планшеты , а также изощренные методы сравнения и установления идентичности. Так как современные системы шифрования предполагают использование довольно трудоемких вычислений, которые заметно замедляют процесс, разрабатываются специальные микросхемы. Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа Exabyte емкостью 2.5-10Гбайт еще достаточно широко используются, высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи на них оставляет желать лучшего). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более . В последнее время широкое распространение получают панели касания, способные распознавать людей по отпечатку пальца или ладони (см. http://elce.quarta.msk.ru/UCC/t_scrb_e.htm). Сходные устройства используются для непосредственного ввода подписи клиента (устройство типа планшет, иногда совмещаемое с дисплеем) и сверки ее с имеющимся образцом. |
|
Previous:
6 Сетевая безопасность
UP:
6 Сетевая безопасность
|
|
|
|
6.4.5 Алгоритм Эль Гамаля
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Алгоритм Эль-Гамаля может использоваться для формирования электронной подписи или для шифрования данных. Он базируется на трудности вычисления дискретного логарифма. Для генерации пары ключей сначала берется простое число p и два случайных числа g и x, каждое из которых меньше p. Затем вычисляется: y = gx mod p Общедоступными ключами являются y, g и p, а секретным ключом является х. Для подписи сообщения M выбирается случайное число k, которое является простым по отношению к p-1. После этого вычисляется a = gk mod p. Далее из уравнения M = (xa + kb) mod (p-1) находим b. Электронной подписью для сообщения M будет служить пара a и b. Случайное число k следует хранить в секрете. Для верификации подписи необходимо проверить равенство: yaab mod p = gM mod p. Пара a и b представляют собой зашифрованный текст. Следует заметить, что зашифрованный текст имеет размер в два раза больше исходного. Для дешифрования производится вычисление: M = b/ax mod p |
|
Previous:
6.4.4 Безопасная почта PGP
UP:
6 Сетевая безопасность
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
7.2 Сетевые драйверы
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Читатели, знакомые с телекоммуникационными протоколами, могут заинтересоваться тем, как писать прикладные программы для работы с пакетами. Прикладная программа взаимодействует с драйвером сетевого интерфейса. Ethernet-интерфейс, как и всякий другой, содержит несколько статусных управляющих регистров (CSR) и один или несколько регистров данных. Запись (чтение) в эти регистры выполняется в IBM/PC с помощью команд IN (OUT). Каждому регистру ставится в соответствие определенный номер порта. Блок номеров портов задается с помощью переключателей на интерфейсе или в процессе постановки пакетного драйвера. В последнем случае в AUTOEXEC-файле должна присутствовать строка, например (для DOS): NE2000 0x60 0x5 0x300, (если ваша ЭВМ снабжена интерфейсом типа NE2000). Здесь предполагается, что интерфейс будет использовать номер прерывания 0x60, аппаратное прерывание 0x5 и блок портов, начиная с шестнадцатеричного адреса 0x300 (io_addr). Следует иметь в виду, что разные интерфейсы могут иметь разное число CSR-регистров и отличные от приведенных ниже функции (NE2100). Интерфейс характеризуется тремя целыми числами: класс (8 бит), тип (16 бит) и номер. Класс говорит о том, для какой из сетевых сред предназначен данный прибор (PPP, DIX Ethernet, IEEE 802.3, IEEE 802.5, Pronet-10, Appletalk и т.д.). Тип описывает конкретную реализацию интерфейса (NE2000, NI5210, 3C501 и т.д.). Тип 0xffff соответствует всем интерфейсам данного класса. В случае, когда ЭВМ оснащена более чем одним интерфейсом идентичного типа, для их идентификации используется номер. На рис. 7.2.1 показана структура управляющего (CSR) регистра сетевого интерфейса. В таблице 7.2.1 приведен перечень основных классов с примерами определенных типов интерфейсов.
Рис. 7.2.1.А Структура CSR-регистра интерфейса (CSR0)
CSR1 (доступ разрешен при CSR0[stop] = 1)
Рис. 7.2.1.Б. CSR1 CSR2 (доступ разрешен при CSR0[stop] = 1)
Рис. 7.2.1В. CSR2
csr3 (доступ разрешен при CSR0[stop] = 1)
Рис. 7.2.1.Г. CSR3 Таблица 7.2.1.
Любой пакетный драйвер имеет блок исходных данных (MS-DOS), напр.:
Структура переменных init_mode (смещение = 0) имеет вид
Рис. 7.2.2. Структура переменных init_mode
Кольцевой входной буфер имеет следующую структуру:
Структура переменных rd_stat имеет вид
Рис. 7.2.3. Структура переменных rd_stat
Выходной буфер имеет сходную структуру. Я не буду описывать здесь то, как следует писать системные драйверы (Исчерпывающую информацию по написанию таких драйверов читатель может найти в книге "Написание драйверов для MS-DOS" Р.Лея и "Уэйт Груп", Москва "Мир", 1995), тем более что существует достаточное их количество в депозитариях общего доступа (Например, анонимное FTP по адресам ftp.funet.fi, ftp.switch.ch или oak.oakland.edu, депозитарий SimTel ). Приведенное выше описание регистров интерфейса не является единственно возможным (см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi. Структура драйверов варьируется для разных операционных систем. Для системных программистов полезно иметь возможность настраивать драйвер или непосредственно интерфейс на определенный режим, например, на прием всех пакетов, проходящих по кабельному сегменту. Последнее может представлять интерес в диагностических целях, так как вслед за пакетным драйвером загружается Etherdrv, Winsock или winpkt и т.д., блокирующие режим приема всех пакетов (mode=6). Ниже приведен пример описания основных параметров драйвера:
; размер буфера для мультикаст-адресов
Работа с пакетным драйвером в MS-DOS Существует множество пакетных драйверов. Можно обнаружить несколько модификаций для одного и того же типа интерфейса. Эти драйверы могут быть ориентированы на работу в разных программных средах (Novell, UNIX, MS-DOS и т.д.) и иметь разные возможности. Для MS-DOS сложился неофициальный стандарт, который позволяет использовать драйвер для самых разных приложений. Драйвер может использовать минимум возможностей интерфейса (базовый уровень), реализовать более широкий набор функций (мультикастинг, сбор статистики и т.д.) или поддерживать практически все, на что способен данный прибор. В последнем случае он занимает больше места в памяти. Описания операций с пакетными драйверами, приведенные ниже, выполнены в нотации ассемблера IBM/PC. При написании программы следует помнить, что порядок байтов в Ethernet противоположен тому, который используется в вашей IBM/PC. Пакетные драйверы используют программные прерывания в интервале 0x60 - 0x80. Следует сразу заметить, что не все прерывания из этого списка свободны и при конфигурировании системы следует проявлять осмотрительность. Для того чтобы избежать конфликтов с другими внешними устройствами, предусматривается возможность реконфигурации прерываний. Предполагается, что программа обработки прерываний начинается с команды безусловной передачи управления (JMP), за которой следует текстовая строка "PKT DRVR". Именно эта строка служит указателем при поиске адреса пакетного прерывания. Практически все драйверы могут работать с различными протоколами (TCP/IP, OSI и др.). Решить задачу мультиплексирования на связном уровне помогает процедура access_type, которая обеспечивает доступ для пакетов определенного типа. Все функции реализуются с помощью обращения к драйверу с набором определенных параметров. При этом значение регистра AH определяет тип запроса. Каждому типу используемого сетевого протокола, с которым работает интерфейс, ставится в соответствие целочисленный указатель (handle), получаемый с помощью процедуры access_type. Выполнимость драйвером тех или иных операций может быть выяснена с помощью запроса driver_info. При работе с драйвером следует проявлять осторожность и спасать нужные вам регистры. Следует также помнить, что порядок байтов в PC и в некоторых сетях, включая Ethernet, не совпадает. Описание основных запросов, посылаемых пакетному драйверу: 1. Получение информации о типе и функциональных возможностях драйвера driver_info AH == 1,
Целочисленный указатель (handle) должен быть занесен в регистр BX (для старых драйверов). В случае ошибки устанавливается флаг carry, а код ошибки заносится в регистр DH. Сообщение BAD_HANDLE (неверный указатель) возможно только для старых драйверов. При благополучном исполнении флаг carry равен нулю, а в регистры будет занесены следующие параметры:
Ниже приведен пример программы, реализующей некоторые из описанных запросов.
.DATA
.CODE
HAVE_SIGNATURE:
2. Организация доступа для пакетов данного
типа Запрос access_type инициализирует доступ для пакетов определенного типа (type). Аргумент typelen - длина спецификации типа в байтах, для PC/TCP равна 5 (наименьшее значение - 2, для IP и ARP). Аргумент receiver является указателем на подпрограмму, которая вызывается при приеме пакета. Получая пакет, драйвер дважды обращается к этой программе. Первый раз (при AX==0) это делается с целью получения адреса буфера, куда должен быть положен пакет. Прикладная программа в этом случае должна выдать указатель буфера в регистры ES:DI. Если прикладной процесс не имеет свободного буфера,то возвращается значение 0:0. Пакет выбрасывается и повторное обращение к программе receiver отменяется. Форма реализации запроса аналогична приведенному для driver_info:
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
При успешном выполнении запроса флаг carry=0, а в регистр AX занесен указатель (handle). Обращение к приемнику (receiver): (*receiver)(handle, flag, len [, buffer])
if AX == 1,
Если параметр typelen равен нулю, прикладной процесс готов получать все пакеты. Очень важно, чтобы при первом обращении к receiver (AX==0) CX (длина пакета) была указана правильно, что позволит выделить нужное место в памяти. CX должна включать в себя длину MAC-заголовка и размер самого сообщения без контрольной суммы (CRC). Повторный вызов (AX==1) программы receiver указывает на то,что пакет записан в буфер и прикладная программа может с ним работать. Адрес буфера будет указан в регистрах DS:SI. 3. Завершение доступа пакетов данного типа release_type int release_type(handle) AH == 3; _release_type proc near
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможная ошибка: BAD_HANDLE (не верный указатель). При успешном выполнении запроса флаг carry=0. Эта операция прерывает доступ пакетов, соответствующих указателю, полученному с помощью запроса access_type. Старый указатель после выполнения этого запроса не действителен. 4. Процедура посылки пакета send_packet(buffer, length) AH == 4 (код запроса) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 12 CANT_SEND. send_packet отправляет пакет с числом байт, равным CX. Пакет должен в исходный момент лежать, начиная с адреса DS:SI. Прикладная программа должна сформировать все необходимые заголовки. Информация, нужная для осуществления демультиплексирования пакетов (MAC или LLC), также должна быть записана в пакет, так как при этом запросе не сообщается значение указателя (handle). 5. Завершение работы драйвера terminate(handle) AH == 5 (код запроса) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки: 1 BAD_HANDLE; Завершает работу драйвера, соответствующего указателю, который приведен в качестве параметра запроса. Если возможно, драйвер будет выгружен и занимаемая им память освобождена. 6. Получение физического адреса интерфейса get_address(handle,buf,len) AH == 6 (код запроса) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки: 1 BAD_HANDLE; Копирует текущее значение сетевого (физического) адреса интерфейса в буфер. Если получено сообщение NO_SPACE, это означает, что выделенного места (len=CX) для копирования адреса не хватило. 7. Возвращение интерфейса в исходное состояние reset_interface(handle) AH == 7 (код запроса) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки: 1 BAD_HANDLE; Возвращает интерфейс в исходное состояние, прерывая все процессы. Местное значение физического сетевого адреса, если оно было изменено, восстанавливается из ROM, прием переключается в режим 3, а список мультикастинг-адресов обнуляется. При работе с несколькими указателями (handle) возможны серьезные неприятности, по этому выполнение запроса блокируется и присылается сообщение CANT_RESET. 8. Запрос установки режима приема пакетов set_rcv_mode(handle,mode) AH == 20 (код запроса) int handle; В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки: 1 BAD_HANDLE; Устанавливает режим приема пакетов. Режим 3 используется по умолчанию. Возможны (но не для всех интерфейсов) следующие режимы:
9. Считывание действующего режима приема пакетов get_rcv_mode(handle) AH == 21 (код запроса) int handle; BX (входной параметр - указатель) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в регистр AX заносится код режима приема пакетов. 10. Занесение списка мультикастинг-адресов в интерфейс set_multicast_list(addrlst,len) AH == 22 (код запроса) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки: 6 NO_MULTICAST; Список адресов представляет собой счетную последовательность, начинающуюся с байта числа адресов в списке. На список адресов указывает комбинация регистров ES:DI. Сообщение NO_SPACE присылается, если указатель адреса отсутствует, или число адресов превосходит аппаратные возможности интерфейса. Прежде чем заносить список, полезно сначала ознакомиться с имеющимся уже списком, выполнив запрос get_multicast_list. При получении сообщения NO_SPACE рекомендуется попытаться установить режим приема 3 с помощью запроса set_rcv_mode. 11. Получение рабочего списка мультикастинг-адресов get_multicast_list AH == 23 (код запроса) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки: 6 NO_MULTICAST; При успешном выпонении запроса флаг carry=0, в регистр CX заносится длина списка адресов, а регистры ES:DI указывают на начало счетной оследовательности, где запрошенный список лежит. Прикладная программа не должна модифицировать этот список. 12. Получение статистических данных об ошибках и трафике через данный интерфейсget_statistics(handle) AH == 24 (код запроса) В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в массиве, начиная с адреса DS:SI, лежит запрошенная информация. struct statistics {
Статистические данные имеют вид целых 32-разрядных чисел в формате IBM/PC. 13. Смена физического адреса интерфейса set_address(addr, len) AH == 25 В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки: 13 CANT_SET; При благоприятном выполнении запроса флаг carry=0, а значение регистра CX сохраняется. Запрос используется в случае, когда необходим специфический физический адрес интерфейса (например, в случае DECNET). При наличии более одного указателя (handle) драйвер откажется исполнить данный запрос и пришлет сообщение CANT_SET. Этим не исчерпывается перечень возможных запросов, существует некоторое количество операций, относящихся к экстра-набору функций (код функциональности 5 или 6, смотри описание запроса driver_info). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
7.1 Winsock (для UNIX, Windows-95 и -NT)
UP:
7 Программирование для сетей (новые идеи, принципы и возможности)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||
|
7 Программирование для сетей (новые идеи, принципы и возможности)
Семенов Ю.А. (ГНЦ ИТЭФ) |
|||||
Программирование - искусство индивидуальное, но сетевое программирование имеет много специфических особенностей, требующих выполнения определенных правил. Оно в значительной мере напоминает написание программ реального времени, так как здесь также приходится иметь дело с постоянно изменяющимися обстоятельствами. Заметные отличия возникают из-за работы в разных операционных системах (DOS, UNIX, Windows, OS/2). Существуют задачи, которые даже сегодня лучше реализовать в ОС DOS. К таким задачам следует отнести хронометраж некоторых сетевых операций (к сожалению многозадачные и многопользовательские системы довольно часто вносят ошибки в результаты временных измерений с использованием внутренних машинных часов). Кроме того, в рамках, например, ICMP.DLL нельзя послать очередной пакет до тех пор, пока не истечет таймаут или не будет получен отклик. Это также создает некоторые трудности. Да и библиотека RAWSOCK не у каждого под рукой. Если задача может быть решена в рамках Windows, ничего другого и не нужно (при всех бесчисленных недостатках эта среда наиболее дружественна к пользователю). В крайнем случае, можно без особого труда перенести ваше приложение в Windows NT или OS/2. Если же вы разрабатываете нечто для многопользовательской среды, стоит подумать о работе под ОС UNIX. Новейшие пакеты для работы с соединителями (socket) заметно облегчают работу программисту. Современные соединители (см. http: //www.stardust.com/wsresource/winsock2/ws2ident.html) способны настраиваться на протокольный набор (это не обязательно TCP/IP) и на конкретный протокол. Библиотеки допускают работу как IPv4 так и с IPv6, необходимо лишь корректно задать параметры. Идеология соединителей, пришедшая из UNIX, и унификация библиотек для работы с ними заметно облегчают перенос программ из одной ОС в другую. Сегодня программист, даже не вникая в особенности протокола, за счет использования стандартных библиотек может создать программу любого приложения. Современная среда программирования, особенно в Windows, позволяет сформировать и удобный интерфейс для работы с разрабатываемым приложением. Новейшие версии библиотек для работы с соединителями позволяют запускать и управлять несколькими процессами ввода/вывода одновременно. Следует иметь в виду, что, например, в системе UNIX все виды Интернет услуг обслуживает демон inetd. Конкретный запрос (telnet, FTP, finger и т.д.) поступает именно к нему, inetd резервирует номер порта и запускает соответствующий процесс, после чего переходит в режим ожидания новых запросов. Такая схема позволяет эффективно и экономно работать со стандартными номерами портов. Практически любая утилита использует в качестве параметра имя какого-либо узла или ЭВМ. По этой причине исполнение программы начинается с посылки запроса серверу имен (DNS). После получения нужного IP-адреса посылается ARP-запрос. Далее формируется соединитель и посылается запрос, который зависит от типа реализуемого приложения. В следующих двух статьях рассмотрено программирование для DOS (непосредственная работа с драйвером сетевого интерфейса) и программирование для Windows. Программирование для UNIX во многом сходно с программированием для Windows, так как здесь используется сходная библиотека для работы с соединителями. |
|||||
|
Previous:
6.10 Идентификатор доступа к сети
UP:
6 Сетевая безопасность
|
|||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
7.1 Winsock (для UNIX, Windows-95 и -NT)
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Какие бы замечательные идеи в области телекоммуникаций, распределенных баз знаний или поисковых систем вам не пришли в голову, реализовать их на практике можно, лишь написав соответствующую программу. Основные операционные среды (Unix, Windows 95, NT или 2000) базируются в настоящее время на идеологии соединителей (socket). Эта технология была разработана в университете г. Беркли (США) для системы Unix, поэтому соединители иногда называют соединителями Беркли (berkeley sockets). Соединители реализуют механизм взаимодействия не только партнеров по телекоммуникациям, но и процессов в ЭВМ вообще (см. [15]). Вопросы сетевого программирования под MS DOS рассмотрены в [24]. Работа с соединителями содержит ряд этапов: соединитель создается, настраивается на заданный режим работы, используется для организации обмена и, наконец, ликвидируется. Технология соединителей поддерживает работу с любыми стеками протоколов, совмещенные процедуры ввода/вывода, использование большого числа сервис-провайдеров (серверов услуг), возможность группирования соединителей, что позволяет реализовать их приоритетное обслуживание, и многое другое. Набор операторов, поддерживающих интерфейс сервис провайдера, образует отдельную динамическую библиотеку. Для общей синхронизации работы сервис-провайдеров и приложений в winsock введено понятие объектов событий. Объекты событий служат в частности для организации работы совмещенных по времени процессов информационного обмена. Здесь уместно замечание об использовании стандартных номеров портов. В много задачных, многопользовательских системах стандартные номера портов используются при инициализации процесса. Так как допускается несколько идентичных соединений (например, несколько одновременных сессий FTP) между клиентом и сервером, стандартными номерами портов здесь не обойтись. Ведь psips сервера могут соотвествовать несколько pcipc клиента. В системах, ориентированных на соединение, пара комбинаций IP-адресов и номеров портов однозначно определяет канал связи между двумя процессами в ЭВМ. Такая комбинация называется соединителем (socket). Номера портов могут и совпадать, так как относятся к разным машинам, но IP-адреса должны быть обязательно разными. Впервые идея соединителя была использована в системе 4.3 BSD Unix для организации сетевого ввода/вывода. В Unix внешнее устройство и файл с точки зрения системного программиста эквивалентны. Сетевые процедуры несколько сложнее и не укладываются в такую простую схему. Из этой простой схемы выпадают, прежде всего, операции, при которых сервер пассивно ожидает обращения особенно для операций обмена не ориентированных на соединение. Соединитель является пограничным понятием между протоколами телекоммуникаций и операционной системой ЭВМ. Соединители играют важную роль при написании прикладных программ (API). Соединитель отправителя = IP-адрес отправителя + номер порта отправителя Межкомпьютерные коммуникации не сводятся к знакомству с соседским депозитарием, к выполнению операций Telnet, FTP и т.д. Одной из важнейших задач является удаленный контроль за процессами в больших рассредоточенных системах, когда обмен информацией активизируется не человеком, а ЭВМ. Примерами таких задач могут служить управление современными высокотехнологичными производствами, сбор метео- или другой геофизической информации в реальном масштабе времени, эксперименты в области физики высоких энергий, где для контроля установки и сбора экспериментальных данных используются десятки (а иногда и сотни) вычислительных машин, которые обмениваются диагностической информацией и данными. Именно для решения таких задач и применяются идеи соединителей (sockets), "труб" и т.д.. Понятие соединителя в прикладных программах это не просто комбинация IP-адресов и номеров портов, это указатель на структуру данных, где хранятся параметры виртуального канала. Прежде чем воспользоваться соединителем, его нужно сформировать. Оператор формирования соединителя имеет вид: s=socket(INT AF, INT type, INT protocol); где все параметры целочисленные, AF (address_family) - характеризует набор протоколов, соответствующий данному соединителю (это может быть набор Internet, Unix, Appletalk и т.д.). Для Интернет AF может принимать только значение PF_INET, для Unix - PF_UNIX. Аргумент type определяет тип коммуникаций (SOCK_STREAM, SOCK_RAW, и SOCK_DGRAM). Аргумент protocol задает код конкретного протокола из указанного набора (заданного AF), который будет реализован в данном соединении. Протоколы обозначаются символьными константами с префиксом IPPROTO_ (например, IPPROTO_TCP или IPPROTO_UDP). Допускается значение protocol=0 (протокол не указан), в этом случае используется значение по умолчанию для данного вида соединений. Значения AF и type можно обычно найти в файле <sys/socket.h>. Возвращаемый параметр S представляет собой дескриптор соединителя. Параметр SOCK_STREAM говорит о том, что вы намерены создать надежный двунаправленный канал обмена, ориентированный на соединение (TCP для Интернет). Связь c другим процессом в этом случае устанавливается оператором connect. После установления соединения данные могут посылаться оператором send или получаться посредством оператора recv. Параметр SOCK_DGRAM характеризует канал, не ориентированный на соединение, с пакетами фиксированного размера (например, UDP в случае AF= PF_INET). Такой канал позволяет использовать операторы sendto и recvfrom. Параметр SOCK_RAW определяет третий режим, при котором возможно использование протоколов нижнего уровня, например ICMP. Таким образом, формирование соединителя - это создание описывающей его структуры данных. Если операция socket завершилась успешно, s равно дескриптору соединителя, в противном случае s=INVALID_SOCKET (-1). С помощью оператора WSAGetLastError можно получить код ошибки, проясняющий причину отрицательного результата. Дескриптор соединителя указывает на элемент таблицы дескрипторов, соответствующий данному соединителю. Оператор socket отводит место в этой таблице. Элемент такой таблицы имеет вид: Код семейства протоколов; IP-адрес определяет интерфейс ЭВМ, а номер порта в данном случае характеризуют сетевую процедуру. Так как в Unix возможно формирование соединителя без IP-адресов, а для практической работы они нужны, имеется оператор bind, который позволяет присвоить определенный адрес заданному соединителю: r=bind(s, const struct socketaddr far*name, int namelen), где s - целочисленный код дескриптора, параметр name (идентификатор локального адреса) обычно (для Интернет) содержит три величины: IP-адрес ЭВМ, код протокольного набора, номер порта, который определяет характер приложения. Структура адресной информации имеет вид:
struct sockaddr { Параметр namlen определяет длину второго параметра. В рамках этой идеологии легко реализовать систему клиент-сервер. IP-адрес может быть сделан равным INADDR_ANY (или =0), если ЭВМ имеет несколько интерфейсов. При номере порта равным нулю, windows socket присвоит порту уникальный номер в диапазоне 1024-5000. Приложение может выполнить операцию getsockname после bind, чтобы определить присвоенный адрес. Оператор bind выполняется до операций connect или listen. При корректном выполнении оператор bind возвращает код 0 (r=0), в противном случае SOCKET_ERROR=-1. Команда bind выдается для записи собственного номера порта. Сервер генерирует команду bind, чтобы подготовить определенный вид связи (например, FTP), и пассивно ожидает запроса connect со стороны клиента: R=connect(s, const struct socketaddr FAR*name, int namelen), где s - дескриптор соединителя, name - идентификатор адреса места назначения (указатель на структуру данных), а namelen - длина этого адреса. Таким образом, оператор connect сообщает ip-адрес и номер порта удаленной ЭВМ. Если адресное поле структуры name содержит нули, оператор connect вернет ошибку WSAEADDRNOTAVAIL (или SOCKET_ERROR=-1). Установка в режим ожидания осуществляется командой listen, которая организует очередь запросов: R=listen(s, int backlog), где backlog - задает максимальный размер очереди для приходящих запросов соединения (то есть сколько запросов может быть принято на обслуживание без потерь, обычно этот параметр равен 5). При переполнении очереди будет послано сообщение об ошибке. Следует иметь в виду, что клиент, ориентированный на соединение, также должен прослушивать порт протокола, ожидая появления дейтограмм-откликов. Ожидающий соединитель посылает каждому отправителю сообщение-отклик, подтверждающее получение запроса на соединение. Оператор listen подготавливает соединитель к обработке потока запросов, система должна быть достаточно быстродействующей. Запросы из очереди извлекаются оператором accept: R=accept(s, struct sockaddr FAR*addr, int FAR*addrlen), где s - дескриптор соединителя, который прослушивает соединение (тот же, что и в listen), addr - опционный указатель на структуру, которая содержит адрес, addrlen - код длины адреса. Оператор accept позволяет серверу принять запрос от клиента. Когда входная очередь сформирована, программа реализует процедуру accept и переходит в режим ожидания запросов. Программа извлекает первый элемент очереди, создает новый соединитель со свойствами, идентичными s, и при успешном выполнении возвращает дескриптор нового соединителя. При возникновении ошибки возвращается код INVALID_SOCKET. По окончании обработки запроса сервер вновь вызывает accept, который возвращает ему дескриптор соединителя очередного запроса, если таковой имеется. Если очередь пуста, accept блокирует программу до получения связи. Существуют серверы с параллельной и последовательной обработкой запросов. Параллельный обработчик запросов не ждет завершения обработки предшествующего запроса и вызывает оператор accept немедленно. В системе Unix используются обычно параллельные обработчики запросов. Схема взаимодействия различных операторов winsock в рамках идеологии клиент/сервер для случая процедур, ориентированных на соединение, показана на рисунке 7.1. Стрелками обозначены направления посылки сетевых сообщений. Следует иметь в виду, что программе клиента (выделена рамкой) не нужно знать номер порта, по этой причине она не обращается к процедуре bind, а для установления связи сразу вызывает оператор connect. Современные распределенные информационные системы, WWW-серверы, поисковые системы и т.д. эффективно используют механизмы формирования соединителей и многие процедуры, описанные в данном разделе. Из литературы [24] известно, что для многих видов услуг в Интернет выделены строго определенные номера портов. Доступ же к этим услугам должен быть обеспечен достаточно большому числу пользователей. С клиентской стороны при этом используются номера портов со значениями из диапазона 1024-5000. Для каждого нового клиентского запроса в ЭВМ-сервере, как правило, открывается новый процесс.
Рис. 7.1.Схема взаимодействия операторов winsock для процедур, ориентированных на соединение Лишь при успешной реализации всех перечисленных операций может начаться обмен данными. Для пересылки данных могут использоваться команды write, read, send, recv. Команды write и read имеют форму вызова: R=write(s, buf, len) или R=read(s, buf, len), где s - дескриптор соединителя, buf - имя массива, подлежащего пересылке (или предназначенного для приема), len - длина этого массива. Оператор writev отличается от write тем, что данные могут не лежать в виде непрерывного массива: R=writev(s, io_vect, vectlen) или R=readv(s, io_vect, vectlen), где s - дескриптор соединителя, io_vect - вектор-указатель на список указателей, vectlen - длина списка указателей. Команда выполняется медленнее, чем write или read. Список указателей имеет формат (рис. 7.2):
Рис. 7.2 Формат списка указателей для функций readv и writev Команды send(s, msg_buf, buflen, flags) и recv имеют аналогичный формат, но среди параметров обращения содержат переменную flags, которая служит для целей диагностики и управления передачей данных (например, пересылка информации с высоким приоритетом (MSG_OOB - Message Out Of Band), что используется, в частности, при передаче звуковых сообщений). При работе с операторами send или recv надо быть уверенным, что принимающая сторона знает, что ей следует делать с этими приоритетными сообщениями. Другой возможный флаг, определяемый константой MSG_PEEK, позволяет анализировать запросы из входной очереди транспортного уровня. Обычно после считывания данных из входной очереди, они уничтожаются. Когда MSG_PEEK=1, данные из входной очереди не стираются. Этот флаг используется, например, программой FTP. При успешном выполнении команды будет возвращено число переданных байтов, в противном случае -1. Все перечисленные выше операторы рассчитаны на использование в рамках протоколов, ориентированных на установление соединения (TCP), где не требуется указание адреса места назначения. В протоколах типа UDP (не ориентированных на соединение) для передачи информации используются операторы sendto, recvfrom или sendmsg: R=sendto(s, msg_buf, buflen, flags, adr_struc, adr_struc_len) где s - дескриптор соединителя, msg_buf - указатель на буфер, где лежит сообщение, buflen - длина этого буфера (длина сообщения), adr_struc - адресная структура, содержащая исчерпывающую информацию об адресате, adr_struc_len - длина этой структуры. Оператор recvfrom принимает все данные, приходящие на его порт. Приняв дейтограмму, recvfrom записывает также адрес, откуда эта дейтограмма получена. Сервер может посылать по этому адресу дейтограмму-отклик. Вызов оператора sendmsg имеет форму: R=sendmsg(s, msg_struc, flags) [или recvmsg(s, msg_struc, flags)], где s - дескриптор соединителя, msg_struc - информационная структура, формат которой показан ниже на рисунке 7.3. Применение структур делает программирование пересылки сообщений более гибким. Следует учитывать, что для обменов, не ориентированных на соединение, соединитель как бы состоит лишь из одной половины (IP-адрес и номер порта). "Соединители", созданные для обмена (UDP) однажды, далее могут жить своей жизнью. Они могут принимать пакеты от других аналогичных "соединителей" и сами посылать им дейтограммы (кавычки здесь связаны с тем, что это не реальный соединитель и никакого соединения здесь не осуществляется).
Рис. 7.3. Формат информационной структуры msg_struc Взаимодействие операторов winsock для систем, не ориентированных на соединение, показано на рисунке 7.4. Здесь также как и в случае, ориентированном на соединение, сервер вызывает socket и bind, после чего обращается к процедуре recvfrom (вместо read или recv). Программа-клиент в данной схеме обращается к оператору bind и совсем не использует оператор connect (ведь предварительного соединения не нужно). Для передачи запросов и приема откликов здесь служат операторы sendto и recvfrom, соответственно.
Рис. 7.4. Схема взаимодействия операторов winsock для процедур, не ориентированных на соединение Помимо уже описанных операторов для работы с соединителями (sockets) имеется еще один - select, довольно часто используемый серверами. Оператор select позволяет процессу отслеживать состояние одного или нескольких соединителей. Для каждого соединителя вызывающая программа может запросить информацию о статусе read, write или error. Форма обращения имеет вид: R=select(num_of_socks, read_socks, write_socks, error_socks, max_time), где num_of_socks - число контролируемых соединителей (в некоторых реализациях не используется и является необязательным, по умолчанию это число не должно превышать 64). В версии Беркли read_socks, write_socks и error_socks представляют собой побитовые маски, определяющие тип соединителя. Параметр read_socks представляет собой указатель на структуру, описывающую набор соединителей, состояние которых контролируется на возможность чтения (версия winsock). Если соединитель находится в состоянии listen, он будет помечен как "готов для чтения", при условии, что запрос на соединение уже получен. Это предполагает выполнение оператора accept без блокировки. Для других соединителей "готовность к чтению" подразумевает наличие в очереди запросов чтения. Для соединителей типа SOCK_STREAM это означает, что виртуальный соединитель, соответствующий данному соединителю закрылся, и операторы recv или recvfrom будут выполнены без блокировки. Если виртуальное соединение закрыто корректно, оператор recv вернет код 0, в противном случае (например, принудительное закрытие) будет возвращен код WSAECONNRESET. Параметр write_socks - указатель на набор соединителей, состояние которых контролируется на возможность записи. Если соединитель находится в процессе выполнения процедуры connect, "способность к записи" означает, что установление связи завершено. Для других соединителей это значит, что операции send или sendto будут выполнены без блокировки. Параметр error_socks - это указатель на набор соединителей, контролируемых на ошибки. В некоторых реализациях этот аргумент идентифицирует список соединителей, помеченных как приоритетные. Соединитель помечается как приоритетный, если опция SO_OOBINLINE=FALSE. На случай ошибки оператор select отмечает соединитель, где это произошло. select работает лишь с теми соединителями, которые были выделены с помощью масок. При успешном выполнении оператор возвращает число соединителей, готовых к операциям ввода/вывода и модифицирует коды масок в соответствии с состоянием соединителей. Прикладная программа может использовать результаты вызова оператора select, анализируя полученные коды масок. Аргумент max_time определяет максимальное время, выделенное select для завершения своей работы. Для уточнения типа ошибки, возникшей при исполнении операции select, можно воспользоваться процедурой WSAGetLastError. Другим важным оператором является closesocket(s), который закрывает канал соединителя с одной из сторон. Все описанные выше операторы (кроме socket, bind и listen) блокируют работу программы до своего завершения. Практически любая операция, непосредственно связанная с выполнением процедур ввода/вывода, может блокировать выполнение других прикладных функций winsock. Для обслуживания прикладных процессов (например, WWW-сервера, работа с распределенными базами данных и пр.) разработано много других сервисных программ (WINSOCK.DLL), перечень которых представлен в таблице 7.1. Таблица 7.1. Перечень служебных операторов для работы с соединителями (Беркли)
Большинство перечисленных команд имеют развитую систему диагностики, кроме того, во многих реализациях Unix имеется много других полезных команд, описание которых вы можете найти в инструкциях по использованию системы Unix. Рассмотрим некоторые из них. Программа ioctlsocket(s, long cmd, u_long FAR*argp) служит для получения параметров соединителя (выполнение не зависит от типа протокола и коммуникационной субсистемы). Аргумент cmd представляет собой код команды, которая будет выполнена для соединителя s, argp - указатель на параметр команды. Возможно применение команд: FIONBIO - разрешает/запрещает режим блокировки соединителя s (команда WSAAsyncSelect ставит соединитель в режим запрета блокировок автоматически). FIONREAD - определяет объем данных, которые могут быть автоматически считаны через соединитель s. SIOCATMARK - задает режим чтения приоритетной информации (для соединителей типа SOCK_STREAM. Программа setsockopt(s, int level, int optname, const char far* optval, int optlen) устанавливает текущие значения опций для соединителя s. Аргумент level описывает уровень, на котором определена данная опция (например, SOL_SOCKET или IPPROTO_TCP). optname - имя опции, значение которой устанавливается, optval - указатель на буфер, где лежит значение опции, optlen - размер этого буфера. Для опции SO_LINGER - это размер структуры, для остальных - длина целого. При корректном исполнении setsockopt возвращает нуль, в противном случае SOCKET_ERROR. Программа setsockopt поддерживает следующие опции (BSD поддерживает и некоторые другие опции; колонка тип соответствует значению optval, таблица 7.2): Таблица 7.2. Опции соединителей для оператора setsockopt.
Программа getsockopt(s, int level, int optname, char far* optval, int FAR* optlen) позволяет получить значение опции для любого типа соединителей. Значения параметров обращения аналогичны setsockopt. Ниже представлена таблица (7.3) поддерживаемых опций. В среде Windows существуют аналоги (асинхронные) многих из приведенных выше операторов. Имена этих операторов имеют префикс WSA (Windows Socket Asynchronous). Асинхронными они названы по той причине, что их выполнение сопряжено с определенным диалогом и ни начало, ни завершение не ограничено какими-либо временными рамками. Список таких операторов представлен в таблицах 7.4 и 7.5 (версия windows socket 2.2). Таблица 7.3. Опции соединителей для оператора getsockopt
Таблица 7.4. Основные операторы winsock
Из этого списка можно выделить две программы WSAStartup и WSACleanup, первая вызывается в начале любой процедуры, вторая - ее завершает. wsastartup может вызываться за время сессии несколько раз, она позволяет указать версию winsock или получить информацию об ее конкретной реализации. При вызове WSAStartup осуществляется диалог с динамической библиотекой WINSOCK.DLL и настройка параметров системы. При аварийном завершении программы нужно корректно окончить работу с WINSOCK.DLL. Следует при этом помнить, что WSACleanup воздействует на все потоки завершаемого процесса (например, в случае Windows 95 или NS). Определенные проблемы может вызвать перенос программ из Unix в Windows, так как там вместо read и write используются операторы recv и send, вместо ioctl - ioctlsocket, а вместо close - closesocket. Некоторые операторы вообще непереносимы: readv, writv, recvmsg и sendmsg и части программы, где они содержатся, необходимо переписать. При обнаружении ошибки Unix присваивает переменной errno соответствующее значение. В winsock для этой цели используется символьная константа SOCKET_ERROR (равная -1), а для уточнения типа ошибки следует вызвать WSAGetLastError. В системах Windows 95 или NT этот оператор обращается к программе Win32 GetLastError, которая возвращает значение ошибки для сессии, вызвавшей эту ошибку. Таблица 7.5. Асинхронные операторы
* Программа может вызвать блокировку при работе с блокирующим соединителем. При написании программ на персональной ЭВМ, например, на С++ или ассемблере существует возможность выбора модели памяти: small, medium, compact, large или huge. Эти модели отличаются друг от друга числом сегментов (по 64 Кбайт) памяти, выделяемой для программы и данных. Модель small предполагает, что все указатели имеют тип near, если явно не указано обратное (не записан модификатор FAR). Модель large считает по умолчанию все указатели дальними, если явно не присутствует модификатор near. В модели huge длина блока данных может превышать размер одного сегмента. С особенностями этих моделей рекомендуется ознакомиться по описаниям конкретных трансляторов. Используя те или иные модели при создании сетевых программ, нужно учитывать проблемы, которые могут возникнуть при переносе вашей программы из одной операционной среды в другую. ОС Unix, Windows NT и Windows 97 не поддерживают каких-либо моделей памяти и их система адресации скорее совместима с моделью large. Но при переносе программы из одной среды в другую об этой проблеме лучше не забывать и перед началом отладки полезно изучить особенности адресации. При программировании под Windows 3.1 нужно учитывать то, что для доступа к процессору (ЦПУ) необходимо, чтобы программа, захватившая его раньше, прекратила свою работу и освободила ЦПУ. Этого не требуется в среде Unix, Windows 95 или Windows NT. Различие этих операционных сред особенно заметно при выполнении блокирующих процедур, рассмотренных выше, например операции сетевого ввода/вывода. Блокирующие процедуры являются потенциальным источником "повисания" программ, например, оператор recv может вечно ждать отклика, в то время как удаленный сервер будет ждать сообщения от программы, выполняющей recv. По этой причине создание не блокирующих соединителей представляется привлекательным. Такие соединители формируются путем вызова стандартного оператора socket с последующим обращением к процедуре, изменяющей режим работы соединителя (по умолчанию создается блокирующий соединитель). После этого при вызове блокирующего оператора, например, recv при условии, что соединитель не имеет запрашиваемых данных, система возвратит флаг ошибки. Таким образом, при работе с неблокирующим соединителем, операционная система проверяет возможность немедленного выполнения процедуры, и возвращает сигнал ошибки, если это не возможно. Все операторы winsock являются асинхронными и неблокирующими. Асинхронные операции при невозможности выполнить требуемую операцию не выдают сообщения об ошибке, за тем, чтобы процедура была выполнена так как нужно, в этом случае следит операционная система. По завершении асинхронной операции ОС Windows посылает сообщение тому окну, из которого эта операция была вызвана. Но и операторы, работающие с неблокирующими соединителями Беркли, также являются неблокирующими. В то же время все операции ввода и вывода в Unix являются синхронными. Хотя оператор WSAAsyncSelect считается аналогом select, между ними имеется существенное отличие. WSAAsyncSelect - единственный оператор, использующий дескриптор соединителя в качестве параметра. Если select контролирует состояние нескольких соединителей, для того чтобы достичь того же результата с помощью wsaasyncselect надо реализовать столько вызовов, сколько соединителей мы хотим мониторировать. Форма обращения к WSAAsyncSelect имеет вид: WSAAsyncSelect(SOCKETs, HWND hWnd, unsigned int wMsg, long lEvent), где s - дескриптор соединителя, состояние которого мы хотим контролировать, аргумент, hWnd - дескриптор окна-получателя сообщения; wMsg - определяет тип посылаемого сообщения (эти два параметра являются стандартными для всех функций Windows); lEvent - битовая маска, определяющая тип событий, которые нас интересуют. Возможные значения параметра lEvent приведены в таблице 7.6. Таблица 7.6. Возможные значения параметра lEvent оператора WSAAsyncSelect
При необходимости контроля комбинации вышеперечисленных состояний эти маски могут объединяться по ИЛИ. Как только состояние соединителя станет соответствовать выбранной маске, Windows пошлет прикладной программе соответствующее сообщение. Это сообщение содержит дескриптор окна, откуда осуществлен вызов процедуры WSAAsyncSelect, идентификатор сообщения, а также 16-битовый и 32- битовый параметры этого сообщения. Первый из них представляет собой дескриптор соединителя, где это событие произошло. Младшие 16 бит второго параметра являются кодом события, а старшие предназначены для записи кода ошибок, если они произошли. Как уже было отмечено, обращение к WSAAsyncSelect переводит соединитель в неблокирующее состояние. При необходимости реализовать, например, процедуру recv, следует обратиться с начала к WSAAsyncSelect, запросив Windows информировать вас о готовности чтения (lEvent=FD_READ). После этого обработчик сообщений windows при получении соответствующего сигнала предоставит возможность прикладной программе перейти к выполнению операции recv. Так как соединитель уже получил данные, блокировки не произойдет и программа их немедленно получит. Особое внимание блокирующим операциям должно быть уделено в Windows 3.1, поскольку блокировка остановит не только выполнение задачи, вызвавшей эту операцию, но и все другие приложения (ЭВМ станет неуправляемой на время блокировки). Здесь блокирующие процедуры должны быть запрещены, вместо этого при необходимости вызова такой процедуры windows реализует цикл по проверке состояния соединителя (очереди сообщений). Остальные приложения могут при этом продолжить свою работу, а при получении благоприятного сообщения Windows разрешает выполнение блокирующей процедуры, так как она уже не может вызвать блокировки. Осложнения могли бы возникнуть, если обработчик сообщений Windows получит сигнал, который приведет к вызову другой блокирующей процедуры. Сегодня в Windows действует правило, запрещающее такие вызовы из прикладных программ как блокирующие, так и неблокирующие. То есть, на время выполнения блокирующей процедуры все обращения к сетевому интерфейсу запрещены. Имеется несколько операторов Winsock, предназначенных для работы с блокирующими процедурами (смотри таблицу 7.7): Таблица 7.7.
При необходимости прервать блокирующую операцию можно вызвать процедуру WSACancelBlockingCall, прикладная программа получит при этом сообщение об ошибке (WSAEINTR). Оператор WSAIsBlocking возвращает значение TRUE, если в данный момент реализуется блокирующая операция. Последние два оператора из четырех названных служат для построения пользовательских обработчиков сообщений. Аппарат соединителей предполагает возникновение и исчезновение вычислительных и управляющих процессов. Новый процесс может наследовать "старые" соединители. В этом случае может возникнуть необходимость выяснить, адрес партнера, с которым взаимодействует данный соединитель. Эту задачу можно решить с помощью команды getpeername(s, destaddr, addrlen), где destaddr - указатель на структуру типа (рис. 7.5):
Рис. 7.5. Указатель на структуру типа для команды getpeername AF - идентифицирует семейство протоколов (для TCP/IP=2), для которого порожден данный соединитель, вся структура занимает 16 октетов. addrlen - указатель на переменную, куда будет записана длина адреса. Соединитель может быть выключен командой close(s), где s идентификатор соединителя, который надлежит закрыть. Если пользователь не хочет более посылать или получать данные, он может выдать команду shutdown(s, how), где параметр how может принимать значения: 0 - блокируется прием данных; 1 - блокируется передача данных; 3 - блокируются любые обмены. Каждое соединение должно иметь свой неповторимый код ISN (Initial Sequence Number). Этот код посылается клиентом серверу с помощью сегмента SYN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (ESTABLISHED, CLOSED, LISTEN, SYN_SENT, SYN_RCVD и т.д.), переход между которыми строго регламентирован (смотри раздел 4.4.3). При написании диагностических и управляющих программ под Windows 95 или NT можно использовать простые соединители (Sock_Raw) или библиотеку ICMP.DLL (эта динамическая библиотека не является частью Win32 API). Библиотека ICMP.DLL содержит в частности процедуру ICMPSendEcho, которая посылает запросы эхо по указанному адресу и возвращает отклик в пределах указанного временного интервала. В качестве аргументов запрос ICMPSendEcho использует ICMP-дескриптор, который получается в результате запроса IcmpCreateFile. HANDLE WINAPI IcmpCreateFile(VOID); Обращение к процедуре посылки ICMP запроса эхо имеет формат:
/* указатель на буфер, где лежат данные, подлежащие посылке */
/* указатель на буфер для приема пакета-отклика */
Приложение может использовать WSAEnumProtocols для определения того, какой транспортный протокол (стек протоколов) поддерживается, и попутно можно получить дополнительную информацию, которая содержится в структуре WSAPROTOCOL_INFO. В то время как в WinSock 1.1 имеется только одно семейство адресов AF_INET, включающее в себя ограниченное число известных типов соединителей и идентификаторов протоколов, в WinSock 2 это ограничение снято. Информация по WinSock 2 доступна по адресу: www.stardust.com/winsock/ws_specs.htm В настоящее время WinSock допускает совмещение по времени нескольких операций ввода/вывода. Такого рода операции возможны только для соединителей, созданных оператором WSASocket с флагом WSA_FLAG_OVERLAPPED=1 (Win32). Запросы получения и отправки информации возвращают отклик немедленно. Если получен нуль, это означает, что операция ввода/вывода завершилась успешно, если же получен флаг SOCKET_ERROR с кодом ошибки WSA_IO_PENDING, указывает на успешное начало операции, последующие сообщения позволят судить о дальнейшем выполнении операции. Допуская возможность нескольких операций ввода/вывода одновременно, нужно обеспечить соответствие между этими процессами и сообщениями об их завершении. В Winsock эта проблема решена с помощью введения объектов события (event objects), по аналогии с Win32. Эти объекты создаются, уничтожаются, устанавливаются в определенное состояние и т.д. Приложение может использовать оператор WSACreateEvent для создания дескриптора (указателя) объекта события, который передается в качестве обязательного параметра для совмещаемых во времени процедур посылки и получения данных (WSASend, WSASendTo, WSARecv, WSARecvFrom). Каждому оператору создания объекта WSACreateEvent должен соответствовать оператор WSACloseEvent, ликвидирующий его. Объекты события используются также оператором WSAEventSelect для того, чтобы связать FD_XXX сетевое события с объектами события. В 32-разрядной среде операторы для работы с объектами события WSACreateEvent, WSACloseEvent, WSAResetEvent, WSASetEvent, WSAGetOverlappedResult и WSAWaitForMultipleEvents строго соответствуют операторам Win32. Приложение может установить режим ожидания с блокировкой для одного или нескольких объектов события, используя оператор WSAWaitForMultipleEvents. Для этих целей можно применить и WaitForMultipleObjects. Если при ожидании предпочтительнее отсутствие блокировки, можно воспользоваться оператором WSAGetOverlappedResult, чтобы проконтролировать завершение заданного процесса. Операторы запуска совмещаемых по времени процессов ввода/вывода WSASend, WSASendTo, WSARecv, WSARecvFrom используют в качестве опционного указателя lpCompletionRoutine, который позволяет по завершении процесса обмена передать управление определенной приложением программе. В версии WinSock 2 введено понятие группы соединителей, которое позволяет приложению сообщить сервис провайдеру, что данный набор соединителей имеет определенные идентичные свойства (атрибуты). К числу этих свойств относятся относительные приоритеты отдельных соединителей в пределах группы, а также спецификация качества услуг (QOS). Приложения, реализующие мультимедийные потоки данных, нуждаются в организации специфических взаимоотношений между наборами соединителей. Как минимум это может включать подсказку сервис провайдеру о приоритетности потоков информации. Например, при проведении видеоконференций звуковое сопровождение должно иметь более высокий приоритет, чем видеоинформация. Кроме того, существуют сервис провайдеры, которые могут обеспечить запрашиваемое качество обслуживание (код QOS). WSASocket и WSAAccept представляют собой два новых оператора, используемых для создания соединителей и групп, а также для включения соединителя в определенную группу. Идентификатор группы соединителя можно узнать с помощью оператора getsockopt с опцией SO_GROUP_ID. Установка и проверка относительного приоритета соединителей в группе осуществляется соответственно операторами getsockopt и setsockopt с опцией SO_GROUP_PRIORITY. Опции соединителей приведены в таблице 7.8. Таблица 7.8. Опции соединителей
Сводная таблица кодов операций для процедуры ioctl приведена ниже (таблица 7.9). Оператор WSAIoctl поддерживает также все операции, специфицированные для процедуры iocltsocket. Таблица 7.9. Коды операций
Оператор WSAAccept устанавливает условное соединение и имеет следующую структуру параметров. WSAAccept (
IN и OUT указывают на то, является ли данный параметр входным или выходные. Программа извлекает очередную заявку на соединение из очереди соединителя s и проверяет с помощью специфицированной программы выполнение условий соединения. Если условия выполнены, возвращается флаг CF_ACCEPT, программа создает новый соединитель и осуществляет подключение его к группе в соответствии с параметром g, выработанным программой проверки условий. Вновь созданный соединитель имеет те же параметры, что и s, включая те, что задаются операторами контроля WSAAsyncSelect или WSAEventSelect. Если программа проверки условия вернула флаг CF_REJECT, запрос на соединение аннулируется. При невозможности принять решение немедленно, программа проверки условия должна вернуть флаг CF_DEFER, при этом никаких действий не предпринимается. Когда приложение будет готово обслужить запрос на соединение, оно снова запустит процедуру WSAAccept и пришлет либо CF_ACCEPT, либо CF_REJECT в качестве результата проверки условий. Для соединителей, которые остаются в блокирующем режиме, когда в очереди нет запросов на соединение, WSAAccept блокирует вызывающую программу до появления заявки на соединение. Для соединителей неблокирующего типа, когда очередь пуста, оператор WSAAccept вернет флаг ошибки. При завершении процедуры в addrlen будет записана реальная длина адреса в байтах. Если addr и (или) addrlen равны нулю, это означает, что нет никакой информации об адресе удаленного адресата. В противном случае эти параметры несут в себе реальную информацию не зависимо от результатов проверки условий. Прототип программы проверки условий имеет формат: int CALLBACK
ConditionFunc представляет собой указатель имени программы, которая служит для проверки условий. В 16-битной версии Windows, эта программа выполняется в рамках той же сессии, что и WSAAccept, поэтому вызов каких-либо иных WinSock операторов кроме WSAIsBlocking и WSACancelBlockingCall не возможен. Программа проверки условий должна находиться в DLL или прикладном модуле. Для определения адреса программы проверки условий следует пользоваться оператором MakeProcInstance. Переменные lpCallerId и lpCallerData являются параметрами, которые содержат адрес партнера и любую пользовательскую информацию, которая была прислана вместе с запросом на соединение. lpSQOS представляет собой указатель на текущую спецификацию QOS соединителя s (по одной для каждого из концов виртуального канала), за которой следуют дополнительные параметры, заданные провайдером. Нулевое значение lpSQOS указывает на то, что вызывающая сторона не задала значения QOS. lpGQOS - указатель на спецификацию QOS группы соединителей, созданной запрашивающей стороной (для каждого из направлений обмена), за которой следуют дополнительные параметры, заданные провайдером. lpCalleeId представляет собой локальный адрес вызывающей стороны. lpCalleeData используется программой проверки условий для записи результатов ее работы. lpCalleeData первоначально содержит размер буфера, предназначенного для сервис провайдера. Положение буфера определяется указателем lpCalleeData->buf. Программа проверки условий должна скопировать lpCalleeData->len байт в lpCalleeData->buf, а затем провести актуализацию lpCalleeData->len, с тем чтобы сообщить действительное число переданных байтов. В таблице 7.10 представлен перечень кодов-сообщений об ошибках вместе с их эквивалентами для Berkley-соединителей. Таблица 7.10. Краткое описание сообщений об ошибках
Введено понятие WOSA-интерфейса (Windows Open Service Architecture), который обеспечивает связь между прикладной программой и сетевыми процедурами ОС. Этот интерфейс заметно упрощает программирование при работе с пакетами. Каждая процедура, распознаваемая WOSA, имеет в свою очередь несколько интерфейсов, ориентированных на конкретных сервис-провайдеров. Применение этих средств реализуется через DLL. WinSock, следуя модели WOSA, обеспечивает прикладной интерфейс для сетевого программирования (API - Application Programming Interface), который организует доступ к транспортным услугам и серверу имен сервис-провайдера (SPI - Service Provider Interfaces). SPI ориентирован на использование в рамках 32-битовой модели Microsoft Windows, включая Windows NT и Windows 95. Транспортные сервис-провайдеры (например, TCP/IP или IPX/SPX) и именные серверы (DNS) в WinSock представляют собой динамические библиотеки (DLL) с одной точкой входа для процедур инициализации WSPStartup или NSPStartup (обратите внимание на то, что здесь под сервис-провайдером подразумевается система, способная предоставить определенный вид услуг). Все остальные процедуры сервис-провайдера сделаны доступными для WinSock DLL через диспетчерскую таблицу. Динамическая библиотека сервис-провайдера загружаются в память WinSock DLL только по мере необходимости и выгружаются, когда они более не нужны. Динамическая библиотека сервис-провайдера имеет обычно расширение .WSP или .NSP. Процедуры WinSock SPI имеют префиксы:
Сервис-провайдеры WinSock при работе со строками используют UNICODE. WinSock DLL выполняют необходимые преобразования при работе с приложениями, использующими ANSI или UNICODE. Конкретный сервис-провайдер может поддерживать один или более протоколов. Так TCP/IP-провайдер должен как минимум поддерживать TCP- и UDP-протоколы, в то время как IPX/SPX-провайдер - IPX, SPX и SPX II. Каждый поддерживаемый протокол описывается в структуре WSAPROTOCOL_INFO, а набор таких структур представляет собой каталог используемых протоколов (более детальную информацию по данной тематике можно найти по адресу: www.stardust.com/winsock/ws_specs.htm). Одной из главных задач WinSock DLL является выполнение функции регулировщика информационных потоков между приложениями и сервис-провайдерами. Каждый сервис-провайдер взаимодействует только с WinSock DLL. WinSock DLL заботится об объединении потоков событий от разных сервис-провайдеров и направлении их приложению. Эта библиотека берет на себя функции арбитража и синхронизации. Взаимоотношения между сервис-провайдерами (даже если они поддерживают разные протоколы) улаживаются также WinSock DLL. Работа WinSock DLL базируется на параметрах соединителей, которые задаются при формировании (socket и WSASocket), именно эта информация определяет, какой из сервис провайдеров будет задействован. Для выбора сервис провайдера используется процедура WSPSocket. В случае процедуры socket, WinSock DLL находит запись в структуре WSAPROTOCOL_INFO, которая соответствует входным параметрам (идентификатор стека протоколов, тип соединителя, протокол). Сервис-провайдеры используют сетевые протоколы низкого уровня. WinSock DLL осуществляет управление на среднем уровне, обеспечивая связь транспортных протоколов с приложениями. Транспортный SPI WinSock аналогичен WinSock API с точки зрения базовых процедур с соединителями. Так процедурам connect и WSAConnect ставится в соответствие WSPConnect; accept и WSAAccept - WSPAccept, а socket и WSASocket - WSPSocket. Так как WinSock DLL не поставляется теперь разработчиками стека протоколов, расширение функциональных возможностей представляет определенную проблему. Для преодоления этих трудностей новейшие версии WinSock используют процедуру WSAIoctl, чтобы помочь сервис-провайдерам на практике реализовать какие-либо функциональные новшества. Для введения расширенных возможностей приложение должно запросить указатель на точку входа в соответствующую программу. Это делается с помощью процедуры WSAIoctl, используя команду SIO_GET_EXTENSION_FUNCTION_POINTER. При этом входной буфер процедуры WSAIoctl содержит идентификатор запрашиваемой функции, в выходной буфер будет занесен указатель на нужную программу. Идентификаторы, присвоенные новым функциям, должны быть уникальными глобальными идентификаторами (GUID - Global Unique IDentifiers), которые присваиваются им поставщиками сервис-провайдеров. Для того чтобы транспортный протокол стал доступен через WinSock, он должен быть правильно инсталлирован и зарегистрирован в WinSock. Когда транспортный сервис-провайдер инсталлирован с помощью программы поставщика, соответствующая информация должна быть введена в конфигурационную базу данных, чтобы дать WinSock DLL необходимые данные для взаимодействия с сервис-провайдером. В WinSock DLL содержится процедура WSCInstallProvider для инсталляции программ поставщиков и процедура выгрузки этих программ WSCDeinstallProvider. Структура WSAPROTOCOL_INFO поставляется для каждого протокола и указывает на то, является ли этот протокол базовым, слоевым или стеком. Величина поля ProtocolChain.ChainLen интерпретируется как:
Инсталляция стека протоколов возможна лишь после загрузки всех составных частей (слоевых и базовых протоколов). Структура WSAPROTOCOL_INFO для стека протоколов использует поле ProtocolChain для описания длины стека и идентификации каждой из составных частей. Отдельные протоколы, входящие в стек последовательно перечислены в массиве ProtocolChain.ChainEntries, нулевой элемент списка соответствует первому протоколу слоя. SDK (System Development Kit) для WinSock включает в себя инструментальную WinSock и отладочную DLL. При разработке протокольно-независимых приложений для систем клиент-сервер нужно зарегистрировать имя сервера в банке имен, только это может сделать его доступным извне. Программа-клиент может функционировать лишь при условии, если она способна найти необходимую ей процедуру в поле имен и получить доступ к соответствующему транспортному протоколу и адресной информации. Для тех кто работает с протоколами TCP/IP это может в начале вызвать определенные трудности, которые компенсируются возможностями создания программ, пригодных для широкого класса самых разнообразных протоколов (например, Novell). Под работой с полем имен здесь подразумевается возможность установления соответствия между протоколом и адресным атрибутом сетевой услуги, которой присвоено какое-то имя. Примерами таких полей имен могут служить уже используемые системы DNS (Domain Name System), NDS (Netware Directory Services), X.500 и др. Поля имен могут быть динамическими, статическими и постоянными. Динамические поля имен служат для краткосрочной регистрации сетевой услуги. Часто они базируются на широковещательной системе определения доступности той или иной услуги. Примерами таких систем являются SAP в среде Netware и NBP в среде Appletalk. Статические поля имен формируются при первоначальном создании сервера имен и в дальнейшем могут изменяться лишь администратором сети. Традиционная система DNS относится именно к этой разновидности. Программа может воспользоваться таким банком имен, но не может произвести туда запись. Постоянное поле имен сходно с динамическим - запись туда происходит в реальном масштабе времени, но после регистрации имя записывается в постоянную память и остается там до тех пор, пока не придет запрос на ликвидацию этой записи. Примерами такой системы могут служить X.500 и NDS. Некоторые поля имен организованы иерархически, X.500 и NDS, например, позволяют неограниченное число уровней вложения. Программные интерфейсы, предназначенные для посылки запросов в именные базы данных, сильно варьируются в зависимости от разновидности используемого поля имен. Сервер имен представляет собой резидентную программу, которая обеспечивает интерфейс между WinSock SPI и некоторой существующей базой данных имен. Используемые услуги в WinSock группируются в классы услуг и в пределах класса имя услуги должно быть уникально. Примерами классов услуг могут служить FTP и SQL. Каждому классу присваивается имя и идентификатор (ID). Имя класса может не быть уникальным, но идентификатор обязан быть неповторимым. В качестве идентификаторов классов услуг в Winsock используются GUID (Globally Unique Identifiers). Для генерации GUID имеется специальная программа (UUIDGEN.EXE), которой может воспользоваться разработчик новых классов услуг. DNS в Internet не имеет развитой системы для записи информации о классах услуг. Для TCP/IP-класса услуг GUID присвоен раз и навсегда. WinSock DLL может маршрутизовать прикладные операции в пространстве имен и переадресовывать их соответствующим серверам имен. Процедуры установки классов услуг, регистрации и обслуживания запросов осуществляются непосредственно через интерфейс API - SPI. Процедура WSAGetServiceClassNameByServiceClassId не имеет аналога среди операторов SPI, так как эта процедура WinSock DLL осуществляет обращение к NSPGetServiceClassInfo. Переключение сервера имен из активного состояния в пассивное и обратно осуществляется с помощью процедуры WSCEnableNSProvider. В активном состоянии могут находиться несколько серверов имен одновременно. Инициализация сервис провайдеров выполняется с помощью процедуры WSPStartup (см. аналогично WSAStartup). Каждой процедуре WSPStartup должна соответствовать процедура WSPCleanup. Процедура WSPSocket имеет параметр flags, который позволяет контролировать атрибуты соединителя. Флаг WSA_FLAG_OVERLAPPED указывает на то, что данный соединитель будет использоваться в режиме совмещения процессов ввода/вывода. Существуют атрибуты, ответственные за использование соединителя для работы в многоточечном и/или мультикастинг режимах. Только соединители, созданные для работы в многоточечном режиме, пригодны для запуска многоточечных сессий с помощью WSPJoinLeaf. Соединитель, созданный для работы в блокирующем режиме, может быть преобразован в неблокирующий с помощью процедур WSPAsyncSelect, WSPEventSelect или WSPIoctl. Перевод соединителя в блокирующий режим производится посредством процедур WSPIoctl, если WSPAsyncSelect неактивен, или WSPEventSelect, если активен. Процедура WSPCloseSocket ликвидирует дескриптор соединителя и все процессы, использующие этот соединитель, будут прерваны. Понятие блокировки для среды Windows было фундаментальным. В WinSock 1.1, блокирующие процедуры WinSock были проблемой, так как они парализовали взаимодействие приложения и надстройки Windows, а применение псевдо-блокирующей техники не всегда давало удовлетворительный эффект. В ОС типа Windows 95 или Windows NT блокирующие процедуры уже не могут вызвать каких-либо проблем, более того, они уже представляются привлекательными. Интерфейс WinSock 2 API уже не поддерживает более псевдоблокировку, но для обеспечения совместимости с WinSock 1.1 он эмулирует этот механизм. В среде Win16, где настоящее блокирование не поддерживается ОС, блокирующие процедуры, которые не могут быть закончены немедленно, обслуживаются с использованием псевдоблокировки. Сервис-провайдер инициализирует процедуру, после чего входит в цикл, внутри которого осуществляет доставку любых сообщений Windows и проверяет завершение процедуры. Если процедура завершилась, или если вызван оператор WSPCancelBlockingCall, происходит выход из цикла, а блокирующая процедура завершается с соответствующим результатом. Эта схема вполне приемлема для простых приложений. Но она неприемлема для приложений, где должны реализоваться сложные схемы доставки сообщений, например, для модели MDI (Multiple Document Interface). Для таких приложений псевдоблокировка должна быть реализована в самом приложении. Сервис-провайдер в этом случае должен вызывать именно этот цикл. Для этого он должен получить указатель на него, обратившись к WPUQueryBlockingCallback. Сервис-провайдер WinSock не может исходить из предположения, что псевдоблокировка, используемая приложением, обеспечит обработку сообщений. Если приложение не приспособлено для решения таких задач, оно откликнется флагом FALSE. Если сервис-провайдер требует обработки сообщений для своих внутренних нужд, он может вызвать процедуру PeekMessage до передачи управления циклу псевдоблокировки в приложении. Сервис-провайдер WinSock использует псевдоблокировку лишь при выполнении определенных условий:
Если условия не выполнены, уход в цикл псевдоблокировки осуществлен не будет. Если во время цикла псевдоблокировки получено сообщение Windows, существует опасность того, что будет предпринята попытка вызова еще одной процедуры WinSock. Из-за трудностей управления этим процессом WinSock 1.1 запрещает такие вызовы. Любая попытка осуществить вложенный вызов процедур WinSock вызовет ошибку WSAEINPROGRESS. Для WinSock 1.1 это ограничение справедливо как для блокирующих, так и для неблокирующих процедур. Имеется два исключения из этого правила. Это процедура, которая позволяет приложению проверить, находится ли система в цикле псевдоблокировки (WSAIsBlocking), и процедура ухода из этого цикла (WSPCancelBlockingCall). WinSock 2 DLL имеет средства для формирования объектов событий, как для приложения, так и для сервис-провайдера, хотя на практике объекты событий создаются в основном приложениями. Для формирования объектов событий в WinSock имеется оператор WPUCreateEvent. Дескриптор объекта события имеет смысл лишь в контексте программы, его сформировавшей. В среде Win32 работа с объектами событий выполняется самой операционной системой. Объекты событий в WinSock представляют собой простые конструкции, которые могут создаваться и уничтожаться, они могут устанавливаться и сбрасываться. Клиент создает объект события и передает его дескриптор в качестве параметра таким процедурам как WSPSend и WSPEventSelect. Когда оговоренные условия выполнены, сервис-провайдер использует дескриптор для того, чтобы установить объект события с помощью оператора WPUSetEvent. При этом клиент WinSock SPI может находиться в состоянии блокировки-ожидания или в режиме запроса, ожидая, когда объект события будет установлен. Клиент может сбросить объект события в нуль, снова его установить и использовать снова. Субъект (приложение или сервис-провайдер), создавший объект события, ответственен и за его ликвидацию. Сервис-провайдер может это сделать с помощью WPUCloseEvent. Одной из главных задач сервис-провайдера является сообщение приложению о том, что произошло соответствующее сетевое событие. Список сетевых событий включает в себя:
Стандартный BSD-интерфейс соединителей имеет только одно средство получить информацию о сетевых событиях - оператор select. Этот метод не может дать информацию о событиях FD_QOS и FD_GROUP_QOS. В Windows Sockets 1.1 используется асинхронный механизм получения информации о сетевых событиях. Для регистрации интересующих событий можно использовать процедуру WSPAsyncSelect. Когда нужное сетевое событие произойдет, соответствующему окну будет послано сообщение, заданное клиентом. Сервис-провайдер использует для тех же целей процедуру WPUPostMessage. В среде Win32 этот метод получения данных о событиях нельзя считать эффективным. WSPEventSelect ведет себя практически также как WSPAsyncSelect за исключением того, что вместо посылки сообщения Windows при сетевом событии типа FD_XXX, устанавливается соответствующий объект события. Факт прихода сетевого события FD_XXX сервис-провайдером запоминается. Вызов процедуры WSPEnumNetworkEvents вызывает копирование текущего содержимого памяти сетевых событий в буфер клиента, а основная память событий очищается. Сервис-провайдеры (ISDN или ATM) могут использовать групповые значения QOS при формировании виртуального канала и повышения эффективности своей работы. Пакеты для соединителей в пределах группы мультиплексируются обычным образом. Операторы WSPSocket и WSPAccept предназначены для формирования соединителей и подключения новых соединителей, к той или иной группе. Однажды включенный в группу соединитель остается в ней до своего закрытия. Группа прекращает свое существование, лишь когда последний соединитель группы будет закрыт. Идентификатор группы соединителей может быть получен с помощью оператора WSPGetSockOpt с опцией SO_GROUP_ID. Узнать об относительном приоритете соединителя в группе можно, воспользовавшись процедурой WSPGet/SetSockOpt с опцией SO_GROUP_PRIORITY. Групповое значение QOS можно задать при выполнении WSPConnect, или WSPIoctl с SIO_SET_GROUP_QOS, если специфицированный соединитель является "учредителем" группы. Оператор WSPIoctl с SIO_GET_GROUP_QOS может использоваться для получения группового значения QOS заданного соединителя. Для провайдеров, поддерживающих группирование соединителей, минимально необходимы следующие функции:
Существуют группы двух видов. Одни включают в себя соединители, ориентированные на соединение, они могут быть подключены только к определенному адресу ЭВМ, остальные группы относятся к другому виду. Провайдер не может включить в группу соединитель, который не удовлетворяет этому условию. Провайдер не может также выполнить соединение, если адресат не соответствует адресу места назначения группы соединителей. Групповой адрес места назначения определяется, когда выполняется процедура connect для первого из соединителей группы. Единственный индивидуальный параметр соединителя в группе - его внутренний уровень приоритета. Провайдер должен уметь считывать значение приоритета, но он может полностью игнорировать этот параметр. В настоящее время не существует каких-либо механизмов для сопоставления приоритетов соединителей, принадлежащих к разным группам, или соединителей вне групп. Поддержка провайдеров групп не означает непременную поддержку различного качества услуг (QOS, см. RFC-1363). Поддержание работы с приоритетами соединителей в пределах группы является рекомендательным требованием. Схема приоритетов WinSock 2 имеет смысл лишь для мультиплексирования данных при соединении точка-точка, например, в случае телефонной связи или любых других вариантах, реализующих коммутацию каналов. Характер информационного обмена описывается спецификацией потока (flow specs), для каждого соединителя используется две такие спецификации, по одной для каждого из направлений обмена. Запрос на соединение реализуется через процедуры WSPConnect или WSPIoctl с кодом команды SIO_SET_QOS/SIO_SET_GROUP_QOS. Спецификация потока параметрически задает уровень сервиса (QOS) и определяет механизм адаптации приложения к сетевым условиям. В WinSock 2 спецификация потока содержит следующие характеристики QOS:
Для протоколов, ориентированных на соединение более удобно для приложения оговаривать QOS при формировании соединения. Это делается путем запроса WSPConnect, направленного сервис-провайдеру. Если QOS было задано с помощью WSPIoctl, его значение может быть переписано при выполнении процедуры WSPConnect. Бессвязные соединители могут также использовать WSPConnect с целью установления определенного уровня QOS для канала связи с партнером После каждой попытки установить связь провайдер производит коррекцию спецификации потока для того, чтобы наилучшим образом отразить реальную ситуацию в сети. Предполагается, что клиенты могут использовать текущую сетевую информацию для того, чтобы оптимально реализовать возможности сети. Но после того как информация о состоянии сети получена, условия могут измениться, партнеры могут согласовать другой уровень QOS, так что приложение должно быть готово ко всему. Для информирования клиента о возможных изменениях условий в Winsock используется механизм сетевых событий (FD_QOS и FD_GROUP_QOS). Сервис-провайдер должен генерировать события типа FD_QOS/FD_GROUP_QOS, если уровень сервиса изменился значительно. Клиент должен использовать WSPIoctl с кодами команд SIO_GET_QOS и/или SIO_GET_GROUP_QOS, чтобы получить соответствующую спецификацию потока и выяснить, изменился ли уровень сервиса (QOS). Структура QOS должна актуализоваться вне зависимости от типа события FD_QOS/FD_GROUP_QOS. Если новый уровень сервиса неприемлем, клиент может попытаться приспособиться к новым условиям или закрыть соединение. При повторной попытке согласовать уровень QOS успешный выход из процедуры WSPIoctl указывает, что новое значение QOS приемлемо. Структура QOS в WinSock 2 описана в файле Winsock2.h и представлена ниже. typedef enum
typedef struct _QualityOfService {
Определения:
Приложения, которые не склонны иметь дело с QOS-структурой непосредственно, могут воспользоваться именами известных видов сервиса и получить нужные данные с помощью запроса WSPGetQOSByName. Прежде чем использовать соединитель, надо связать его с локальным адресом. Это выполняется с помощью процедуры WSPBind, или WSPConnect. Сервер сначала создает соединитель, связывает его с известным локальным адресом (что позволяет клиенту найти его) и переводит соединитель в режим ожидания посредством WSPListen, готовя его к приему запросов на соединение. Одновременно система подготавливает структуру для формирования очереди запросов. Сервис-провайдер заносит поступающие запросы в очередь, где они ожидают обработки. Запросы могут быть удалены клиентом из очереди по таймауту. Если использован соединитель блокирующего типа, сервер может немедленно вызвать процедуру WSPAccept, которая вызовет блокировку на время ожидания запроса на соединение. В качестве альтернативы сервер может использовать один из механизмов обработки сетевых событий, описанный ранее. В зависимости от выбранного механизма провайдер или пошлет сообщение Windows или даст знать о приходе запроса на соединение через объект события. Клиент со своей стороны создаст соответствующий соединитель, запустит процедуру подключения и пошлет запрос WSPConnect, указав известный адрес сервера. Если соединитель является блокирующим, WSPConnect вызовет блокировку до тех пор пока сервер не получит и не обработает запрос на соединение или пока не произойдет таймаут. Клиент должен использовать механизм сетевых событий для отслеживания процесса соединения. Когда сервер запускает процедуру WSPAccept, сервис-провайдер инициализирует программу проверки условий, поставляемую приложением. В качестве параметров обращения используется информация, полученная вместе с запросом на соединение (берется из очереди запросов). Эта информация включат в себя адрес подключаемой ЭВМ, данные о пользователе и характеристику QOS, если таковая имеется. На основе полученной информации сервер определяет, принять данный запрос или нет. Если сервер принял запрос, он должен сформировать новый соединитель с теми же атрибутами что и соединитель ожидавший прихода запроса. Исходный соединитель остается в режиме ожидания последующих запросов. Для получения локального адреса сопряженными соединителями используется запрос WSPGetSockName. Это особенно полезно, когда послан запрос WSPConnect без предварительного вызова процедуры WSPBind. Как было сказано ранее, процедура WSPAccept позволяет воспользоваться поставляемой клиентом программой проверки условий, которая осуществляет условную обработку запросов на соединения, ожидающие обслуживания. Принятие решения осуществляется на основе информации, поступающей вместе с запросом (идентификатор источника запроса, QOS и т.д.). Если программа проверки условий возвращает флаг CF_ACCEPT, формируется новый соединитель с теми же свойствами, что и исходный. Если программа проверки вернет флаг CF_REJECT, запрос на соединение будет отвергнут. При возвращении флага CF_DEFER принятие решения откладывается, а запрос на соединение остается в очереди. Клиент должен будет осуществить вызов WSPAccept еще раз. Некоторые протоколы позволяют переслать информацию в процессе установления связи. Если такая информация получена, она помещается в буфер провайдера, а WinSock SPI получает указатель на этот буфер и длину записи. Если клиент WinSock SPI желает послать некоторую информацию в ответ, он может скопировать ее в буфер, предоставляемый сервис-провайдером. Разрыв соединения может быть выполнен несколькими способами. Для инициализации прерывания связи можно, например, применить процедуру WSPShutdown (с параметром how равным SD_SEND или SD_BOTH), и WSPSendDisconnect. Процедура WSPCloseSocket может быть применена и для аварийного прерывания соединения. Сервис провайдер сообщает о разрыве соединения по инициативе удаленного партнера с помощью сетевого события FD_CLOSE. При реализации процедуры разрыва соединения возможен обмен определенной информацией, если это предусмотрено используемым протоколом. Инициатор разрыва связи может вызвать WSPSendDisconnect, чтобы сообщить, что данных больше посылаться не будет и можно ликвидировать соединение. При этом может быть послана некоторая служебная информация, предусмотренная протоколом обмена. Для чтения этой информации партнер может воспользоваться оператором WSPRecvDisconnect. По завершении этого обмена обе стороны вызывают процедуры WSPCloseSocket. Следует различать процедуры прерывания (shutdown) связи и ее разрыва (close). Прерывание связи сопряжено с определенным диалогом между партнерами, после чего связь "замораживается", но дескриптор связи сохраняется. Существует два типа прерывания связи: аварийное (аппаратное) и нормальное. При нормальном прерывании любые данные, которые стояли в очереди, пересылаются до завершения процесса прерывания. При аварийном же прерывании непосланная информация теряется. В Windows Sockets, как процедура WSPShutdown, так и WSPSendDisconnect могут использоваться для инициализации прерывания связи. В то время как запрос WSPCloseSocket служит для ликвидации дескрипторов соединителей и освобождения связанных с ними ресурсов. Путем установки определенных значений для опций соединителей SO_LINGER и SO_DONTLINGER можно получит следующие варианты реализации процедуры WSPCloseSocket.
Для соединителей, соответствующих протоколам неориентированных на соединение, работа, выполняемая оператором WSPConnect, связана главным образом с установлением адреса места назначения по умолчанию, что позволит в дальнейшем использовать соединитель в операциях обмена, ориентированных на соединение (WSPSend and WSPRecv). Любые дейтограммы, полученные от отправителя с адресом, отличным от специфицированного, будут проигнорированы. Место назначения по умолчанию может быть изменено с помощью повторного вызова WSPConnect. Любая дейтограмма из входной очереди будет отброшена, если новый адрес отличается от адреса, заданного в предыдущем WSPConnect. Если новый адрес равен нулю, соединитель будет отсоединен, так как удаленный адрес не определен, в результате операторы WSPSend и WSPRecv возвратят флаг ошибки WSAENOTCONN, в то же время WSPSendTo и WSPRecvFrom могут использоваться по-прежнему. Существует три базовых способа выполнения операций ввода/вывода:
Первый вариант является режимом по умолчанию, неблокирующий вариант может использоваться на любом соединителе, который поставлен в соответствующий режим. Третья разновидность обмена реализуется только на соединителях, которые при формировании были объявлены совмещенными. Процедуры посылки WSPSend и WSPSendTo и приема WSPRecv и WSPRecvFrom реализуют все три указанных режима обмена. Сервис-провайдеры определяют метод обмена на основе режима работы соединителя, атрибутов и входных параметров. Простейшим режимом обмена в WinSock 2 является блокирующий ввод/вывод. Этот режим устанавливается по умолчанию. Любая операция ввода/вывода на блокирующем соединителе вернет управление системе только по завершении процедуры. Таким образом, в ходе любой сессии может выполняться только одна операция ввода/вывода. Это простой режим, но отнюдь не самый эффективный. Если соединитель находится в неблокирующем состоянии, любая операция обмена должна либо завершаться немедленно, либо возвращать флаг ошибки WSAEWOULDBLOCK, указывая, что операция не может быть завершена корректно. Необходим механизм для определения, когда следует попытаться выполнить операцию еще раз. Для решения этой проблемы определен список сетевых событий, наступление которых может контролироваться с помощью процедур WSPSelect, WSPAsyncSelect или WSPEventSelect. В WinSock 2 впервые разрешено совмещение нескольких процедур ввода/вывода и потребована поддержка этого режима всеми сервис-провайдерами. Этот режим возможен только для соединителей, сформированных с помощью WSPSocket с флагом WSA_FLAG_OVERLAPPED. Для приема данных клиент может воспользоваться процедурами WSPRecv или WSPRecvFrom, чтобы указать буферы, куда будут записываться данные. Если один или более буферов подготовлены приложением до начала обмена, информация будет заноситься непосредственно в буферы пользователя и многоступенчатое копирование будет исключено. Если буферов заранее приложением не подготовлено, информация заносится сервис-провайдером во внутренний буфер и система ждет запроса, чтобы перенести данные в буфер приложения. Исключением из этого правила является случай, когда приложение использует WSPSetSockOpt для установления нулевого размера входного буфера. В этом варианте данные принимаются лишь при наличии указателей на буфер приложения. При посылке информации клиенты для выдачи указателей на буфер данных используют WSPSend или WSPSendTo. В совмещенном режиме процедуры посылки и получения данных завершаются немедленно. Полученный по возврату нуль, указывает на то, что процедура завершилась успешно. То есть, сформирован соответствующий объект события или программа завершения установлена в очередь с помощью WPUQueueApc. Возврат флага SOCKET_ERROR, сопряженного с кодом ошибки WSA_IO_PENDING, указывает, что совмещенная операция успешно начата и будет позднее сообщено, когда выходной буфер будет свободен или входной буфер будет заполнен. Любые другие коды ошибок говорят о сбое. Совмещаться могут как операции ввода, так и вывода. Следует иметь в виду, что если было послано несколько блоков данных друг за другом, сообщения о завершении операций по их пересылке могут прийти в другом порядке. Тоже может произойти и при приеме данных. Сервис-провайдеры имеют два способа сообщать о завершении совмещенных по времени операций: установка объекта события, заданного программой-клиентом, или запуск заданной клиентом программы завершения. В обоих случаях каждой из совмещенных операций ставится в соответствие структура WSAOVERLAPPED. Память для размещения этой структуры выделяется клиентом и используется им для указания того, какой из объектов следует установить при завершении процесса обмена. Структура WSAOVERLAPPED может использоваться сервис-провайдером для хранения дескриптора соответствующей совмещенной процедуры. Для извлечения нужной информации из указанной структуры можно воспользоваться оператором WSPGetOverlappedResult. Если параметр lpCompletionRoutine совмещенной операции не равен нулю, то сервис-провайдер может вызвать программу завершения, специфицированную клиентом. WinSock DLL предлагает асинхронную процедуру вызова (APC) программ завершения обмена. Для реализации той или иной функции в рамках сессии сервис-провайдер вызывает сначала процедуру WPUQueueApc. Сервис-провайдер должен позаботиться о том, чтобы процесс, соответствующий выбранному контексту, был активным до вызова функции WPUQueueApc. WPUQueueApc берет в качестве входных параметров указатель на структуру WSATHREADID, указатель на процедуру APC и 32-разрядный контекстный код. Сервис-провайдеры всегда получают указатель на соответствующую структуру WSATHREADID через параметр lpThreadId. Провайдер должен запомнить структуру WSATHREADID и выдать указатель на ее копию в качестве параметра оператора WPUQueueApc. Так как механизм APC работает только с одним 32-разрядным контекстным кодом, процедура APC не может быть сама программой завершения, заданной клиентом. Сервис-провайдер должен выдать указатель на свою собственную процедуру APC, которая, используя контекстный код, обеспечивает доступ к необходимой информации для совмещенной операции обмена и вызывает заданную клиентом программу завершения. Сервис-провайдер должен позволить клиентам WinSock 2 вызов процедур чтения или записи во время выполнения процедуры завершения обмена и гарантировать, что для данного соединителя не будет допущено вложение операций завершения. Структура WSAOVERLAPPED создает коммуникационную среду между запуском совмещенной операции обмена и последующим ее завершением. Структура WSAOVERLAPPED совместима со структурой OVERLAPPED для Win32: typedef struct _WSAOVERLAPPED {
Приоритетные данные могут доставляться пользователю независимо от обычной информации. Для коммуникационных протоколов, где предусмотрена пометка данных как срочные (например, TCP, позволяющий доставку срочной информации в общем потоке данных) система извлекает приоритетную информацию из общего потока и запоминает отдельно. Пользователь может определить, имеется ли приоритетная непрочитанная информация, используя процедуру WSPIoctl(SIOCATMARK). Для протоколов, где положение приоритетной информации в общем потоке имеет смысл, сервис-провайдер обеспечивает указатели, определяющие это положение. Для таких протоколов допускается обработка приоритетных данных в общем информационном потоке. Это достигается путем установки опции соединителя SO_OOBINLINE (OOB - Out-Of-Band). Для других протоколов, где блоки приоритетных данных независимы от общего информационного потока, попытка установить опцию SO_OOBINLINE вызовет ошибку. Приложение может использовать команду SIOCATMARK WSPIoctl для определения наличия непрочитанных блоков приоритетной информации. При запрещении SO_OOBINLINE (disabled - значение по умолчанию): Сервис-провайдер WinSock сообщает клиенту о FD_OOB событиях, если клиент зарегистрирован для этого с помощью процедуры WSPAsyncSelect, точно таким же образом FD_READ используется для сообщения о присутствии обычных данных. Таким образом, FD_OOB посылается, когда поступает приоритетная информация, а также когда данные прочитаны с использованием флага MSG_OOB, в условиях присутствия приоритетных данных, подлежащих чтению. Сообщение FD_READ для приоритетных данных не посылается. Сервис-провайдер WinSock возвращает соответствующий набор exceptfds при выполнении процедуры WSPSelect, если приоритетные данные присутствуют в очереди соединителя. Клиент может вызвать WSPRecv с MSG_OOB для чтения блока приоритетных данных. Клиент может вызвать процедуру WSPRecv без MSG_OOB для чтения потока обычной информации. Блок приоритетных данных не может появиться в потоке обычных данных. Если приоритетные данные остаются после запроса WSPRecv, сервис-провайдер дает сообщение клиенту с помощью флага FD_OOB или через exceptfds при использовании запроса B>WSPSelect. Для протоколов, где приоритетные данные находятся в потоке обычных данных, одного запроса WSPRecv недостаточно. Один вызов WSPRecv вернет обычные данные до маркера, и потребуется второй запрос WSPRecv для чтения данных после маркера. При разрешении SO_OOBINLINE (enabled): Сообщение FD_OOB не посылается для приоритетных данных, а процедуры WSPSelect и WSPAsyncSelect рассматривают эти данные как обычные, о типе информации можно судить по readfds соединителя или по сообщению FD_READ, соответственно. Клиент не может осуществлять вызов WSPRecv с флагом MSG_OOB для чтения блока приоритетных данных - в противном случае будет получен код ошибки WSAEINVAL.
Программа WSPAsyncSelect прекрасно приспособлена для выявления приоритетных данных, когда SO_OOBINLINE находится в состоянии выключено. Использование соединителя несколькими процессами одновременно организовано следующим образом. Базовый процесс для получения специальной структуры WSAPROTOCOL_INFO вызывает WSPDuplicateSocket. Эта процедура для передачи структуры другому процессу использует межпроцессный механизм коммуникаций (IPC). Последний процесс использует структуру WSAPROTOCOL_INFO при обращении к WSPSocket. Дескриптор соединителя, полученный в результате этой операции, будет дополнительным дескриптором исходного соединителя, который с этого момента может использоваться двумя процессами. Такой механизм разработан для того, чтобы удовлетворить как требованиям однопроцессной версии Windows 3.1, так и многопроцессным вариантам Windows 95 и NT. Следует иметь в виду, что совместное использование соединителей несколькими процессами возможно и без использования WSPDuplicateSocket, так как дескриптор соединителя доступен для всех процессов. Когда формируется дескриптор нового соединителя IFS-провайдер должен вызвать WPUModifyIFSHandle, а не-IFS-провайдер должен вызвать WPUCreateSocketHandle (IFS - Installable File System). Так как реально дублируются дескрипторы, а не сами соединители, все параметры соединения оказываются абсолютно идентичными. Контроль состояния используемых совместно соединителей осуществляется посредством WSPAsyncSelect и WSPEventSelect. Вызов одного из указанных запросов с одним из дескрипторов соединителя в качестве параметра, аннулирует любую предшествующую регистрацию событий для указанного соединителя, вне зависимости от того, какой из дескрипторов использован для новой регистрации. Таким образом, нельзя для процесса A иметь FD_READ-события, а для процесса B получать FD_WRITE-события. Процесс может вызвать WSPCloseSocket для дублирующего соединителя и старый дескриптор будет ликвидирован, в то время как сам соединитель, ему соответствующий, останется открытым вплоть до выполнения процедуры WSPCloseSocket. Два или более дескрипторов могут соответствовать одному и тому же соединителю и использоваться независимо для операций ввода/вывода. Однако, интерфейс WinSock не осуществляет какого-либо контроля за доступом, задача координации совместного использования соединителя является объектом ответственности самих процессов. Для простоты в дальнейшем термин "многоточечный" будет означать широковещательный или мультикастинг. В настоящее время многоточечные приложения (напр., IP-мультикастинг, ST-II, T.120, ATM UNI, и т.д.) значительно различаются по способу подключения узла к многоточечной сессии. Для декларации различных многоточечных атрибутов протокола в WinSock 2 используется структура WSAPROTOCOL_INFO. Просматривая эти атрибуты, программист может узнать, какие соглашения должны быть реализованы. В плоскости управления существует два типа различных сессий: rooted и non-rooted (корневые и некорневые). В случае корневого управления существует участник, называемый c_root, который отличается от всех остальных членов многоточечной сессии, которые называются c_leaf (периферийные члены группы). Участник сессии c_root должен оставаться в списке участников на протяжении всей многоточечной сессии, так как без его участия сессия будет прервана. c_root обычно инициирует многоточечную сессию путем установления связей с участниками типа c_leaf. c_root может вводить членов в группу, но c_leaf может подключиться к c_root позднее. Для некорневой плоскости управления, все участники многоточечной сессии являются периферийными узлами и не существует какого-то выделенного узла. Каждый c_leaf должен подключиться к многоточечной сессии, которая либо существует всегда (как в случае IP-мультикастинг адреса), или создана за счет какого-то внешнего механизма. При другом подходе c_root по-прежнему существует, но принадлежит сети в целом (не является одним из участников сессии). Так как корневой узел существует, некорневая управляющая плоскость может рассматриваться как неявно корневая. Примерами такого рода неявно корневых схем являются система IP-мультикастинга многоточечные блоки управления (Multipoint Control Unit - MCU) в H.320-видеоконференциях и т.д. В плоскости данных существует два стиля передачи информации: rooted и non-rooted (корневой и некорневой). В корневой плоскости данных существует выделенный участник, называемый d_root. Обмен данными происходит исключительно между d_root и остальными участниками многоточечной сессии, которые называются d_leaf. Трафик может быть однонаправленным или двунаправленным. Данные, посланные d_root, будут доставлены всем d_leaf, в то время как данные, отправленные d_leafs попадут только в d_root. В случае корневой плоскости данных не существует потока данных между периферийными узлами группы (d_leaf). В некорневой плоскости данных, все участники эквивалентны и любая информация, посланная участником, будет доставлена всем членам группы (сессии). Аналогично каждый узел d_leaf может получать данные ото всех остальных узлов группы, а также от любых узлов, не участвующих в данной сессии. В структуре WSAPROTOCOL_INFO имеется три поля атрибутов для выделения различных схем, используемых в плоскостях управления и данных:
В определенные моменты соединители, включенные в многоточечную сессию, могут по своему поведению отличаться от соединителей типа точка-точка. Так соединитель вида d_leaf в корневой плоскости данных может только посылать информацию участнику d_root. Это вызывает необходимость для клиента быть способным заявить об этом на стадии формирования соединителя. Делается это с помощью четырех многоточечных атрибутных флагов, которым присваивается определенное значение через параметр dwFlags в WSPSocket: SA_FLAG_MULTIPOINT_C_ROOT служит для создания соединителя, работающего как c_root. Это разрешено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости управления. WSA_FLAG_MULTIPOINT_C_LEAF предназначен для генерации соединителя, работающего как c_leaf. Это возможно, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO. WSA_FLAG_MULTIPOINT_D_ROOT предполагает формирование соединителя, работающего как d_root. Это позволено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости данных. WSA_FLAG_MULTIPOINT_D_LEAF служит для создания соединителя, работающего как d_leaf. Это допускается, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO. Когда создается многоточечный соединитель, один из двух флагов плоскости управления и один из двух флагов плоскости данных должны быть заданы в параметре dwFlags WSPSocket. Таким образом, при создании многоточечного соединителя могут быть реализованы четыре возможности: c_root/d_root, c_root/d_leaf, c_leaf/d_root, или c_leaf /d_leaf. Когда d_leaf-соединители используются в некорневой плоскости данных, обычно желательно управлять системой так, чтобы отправляемый трафик попадал назад в тот же соединитель. Команда SIO_MULTIPOINT_LOOP для WSPIoctl используется для разрешения или запрещения зацикливания многоточечного трафика. При использовании мультикастинга обычно необходимо специфицировать способ реализации сессии. Среди параметров сессии важную роль играет число вовлеченных сетевых сегментов. Для регулирования этого числа используется команда SIO_MULTICAST_SCOPE WSPIoctl. Нулевое значение числа сетевых сегментов означает, что мультикастинг пакеты не покинут пределы ЭВМ и могут попадать только во внутренние соединители. Значение единица (число по умолчанию) указывает, что мультикастинг-пакеты не могут выйти за пределы маршрутизатора локальной сети. Большие величины позволят распространение сообщений, проходящих соответствующее число маршрутизаторов. Этот код идентичен параметру времени жизни (TTL) в IP-мультикастинге. Многоточечный соединитель часто характеризуется его ролью в плоскости данных и управления. Следует иметь в виду, что один и тот же соединитель может иметь совершенно разную роль в разных плоскостях. В схемах для корневой плоскости периферийные узлы добавляются в многоточечную группу одним из двух способов. В первом методе, корень использует WSPJoinLeaf для инициализации соединения с периферийным узлом и приглашает его быть участником сессии. Со стороны периферийного узла приложение должно создать c_leaf-соединитель и использовать WSPListen для установки его в режим ожидания (listen). Периферийный узел получит сообщение FD_ACCEPT, которое означает приглашение присоединиться к многоточечной сессии, и может объявить о своем желании подключиться путем вызова WSPAccept. Корневое приложения получит сообщение FD_CONNECT, когда операция подключения к группе завершена. Во втором методе роли меняются. Корневой клиент создает соединитель c_root и переходит в режим ожидания (listen). Периферийный узел, желающий присоединиться к сессии, создает соединитель c_leaf и запускает WSPJoinLeaf, чтобы инициализировать соединение и доступ. Корневой клиент получает FD_ACCEPT, когда приходит запрос доступа, и принимает периферийный узел в группу посредством запроса WSPAccept. Периферийный узел получает FD_CONNECT, когда он принят в группу. Для случая IP-мультикастинга это эквивалентно опции соединителя IP_ADD_MEMBERSHIP. Читателей, знакомых с использованием несвязного UDP-протокола в IP-мультикастинге, может смутить семантика, ориентированная на соединение, присутствующая здесь. В частности указание на то, что используется запрос WSPJoinLeaf для соединителя UDP и ожидание сообщения FD_CONNECT могут вызвать недоразумение. Существуют уже, однако, прецеденты использования такой семантики для протоколов, не ориентированных на соединение. Разрешено и иногда полезно, например, использовать процедуру WSPConnect для UDP-соединителей. Общим результатом применения семантики, ориентированной на соединение для несвязных соединителей, является ограничение на то, как эти соединители могут использоваться. UDP-соединитель, используемый в WSPJoinLeaf, будет иметь определенные ограничения, а ожидание сообщения FD_CONNECT (которое в этом случае указывает на посылку соответствующего IGMP-сообщения) является одним из таких ограничений. Существует три случая, когда клиент может использовать WSPJoinLeaf:
Как было упомянуто ранее, WSPJoinLeaf используется для присоединения периферийного узла к многоточечной сессии. WSPJoinLeaf имеет те же параметры и семантику, что и WSPConnect за исключением того, что он возвращает дескриптор соединителя (как и WSPAccept), и имеет дополнительный параметр dwFlags. Параметр dwFlags показывает, будет ли соединитель работать только в режиме чтения, только в режиме записи или в обоих режимах. Только многоточечный соединитель может использоваться в качестве входного параметра s этой процедуры. Если многоточечный соединитель находится в неблокирующем состоянии, полученный дескриптор соединителя нельзя будет использовать до тех пор, пока не будет получено FD_CONNECT. Корневое приложение в многоточечной сессии может вызвать WSPJoinLeaf один или более раз для того, чтобы добавить новые узлы к текущей многоточечной сессии. Параметры дескриптора соединителя, присланного WSPJoinLeaf, варьируются в зависимости от того, является ли дескриптор c_root или c_leaf. Для c_root соединителя, параметр name означает имя определенного периферийного узла, который должен быть добавлен, а возвращенный дескриптор соединителя является c_leaf и соответствует вновь добавленному периферийному узлу. Некоторые многоточечные приложения могут позволять этому соединителю "постороннее" общение с корневым сервером. При вызове WSPJoinLeaf для соединителя c_leaf, параметр name содержит адрес корневого приложения (для схемы корневого управления) или существующей многоточечной сессии (некорневая схема управления), и возвращенный дескриптор соединителя является тождественным по отношению ко входному дескриптору соединителя. В корневой схеме управления, корневой клиент должен поставить свой c_root соединитель в режим ожидания с помощью WSPListen. При запросе периферийного узла о присоединении к группе присылается стандартное сообщение FD_ACCEPT. Корневой клиент использует для подключения нового периферийного узла обычную процедуру WSPAccept. Запрос WSPAccept присылает дескриптор соединителя c_leaf, точно также как и WSPJoinLeaf. Многоточечный корневой клиент является ответственным за прерывание сессии. Такое приложение может использовать WSPShutdown или WSPClosesocket для соединителя c_root, чтобы прислать всем членам группы соединителей c_leaf сообщение FD_CLOSE. Рассмотрим семантическое отличие многоточечных и обычных соединителей . В плоскости управления имеется существенное семантическое отличие между соединителями c_root и обычными соединителями точка-точка:
Не существует какого-либо семантического различия между соединителем c_leaf и традиционным соединителем в плоскости управления, за исключением того, что соединитель c_leaf может использоваться процедурой WSPJoinLeaf, а использование соединителя c_leaf в WSPListen указывает на то, что должны восприниматься только запросы многоточечного соединения. В плоскости данных семантическое отличие между соединителями d_root и традиционными соединителями заключается в следующем:
Соединитель d_leaf в корневой плоскости данных не имеет каких-либо семантических отличий от традиционных соединителей, однако, в некорневой плоскости данных информация, посланная на соединитель d_leaf, поступит ко всем периферийным узлам группы. Данные могут передаваться любым участником многоточечной сессии. Информация о том, находится ли соединитель d_leaf в корневой или некорневой плоскости данных, хранится в структуре соединителя WSAPROTOCOL_INFO. Сводные данные по опциям Winsock 2 вместе с их значениями по умолчанию приведены в таблице 7.11 (см. также описания WSPGetSockOpt и WSPSetSockOpt). Сервис-провайдеры Windows должны распознавать все эти опции. Таблица 7.11. Опции Winsock 2.
В таблице 7.12 приведен список ioctl-кодов команд для соединителей. Таблица 7.12. ioctl-коды команд для соединителей (Winsock 2)
В таблице 7.13 представлены основные характеристики базовых SPI (Service Provider Interfaces) процедур передачи данных для Winsock 2. Таблица 7.13. Базовые SPI процедуры передачи данных Winsock 2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
7 Программирование для сетей (новые идеи, принципы и возможности)
UP:
7 Программирование для сетей (новые идеи, принципы и возможности)
|
|
|
|
8.1 Вопросы по данному курсу
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Программу для проверки знаний по курсам этого сервера читатель может найти по адресу: saturn.itep.ru (knowtest). Список вопросов там почти в два раза длиннее.
Вопросы по курсу "Протоколы и ресурсы Интернет" |
|
Previous:
8 Заключение
UP:
8 Заключение
|
|
|
|
8 Заключение
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Автор признателен читателю, который прочел эти тексты до конца. Надеюсь, что это было не самое скучное и бесполезное занятие. Я являюсь свидетелем и участником развития Интернет в России с самого его начала и это внушает самые оптимистические надежды. В стране, где главным жизненным увлечением заметной части населения является воровство (во всяком случае для той ее части, которая имеет возможность и определенные способности), появление дорогостоящей общенациональной сети при полном отсутствии поддержки со стороны правительства (по крайней мере на начальном этапе) можно считать чудом двадцатого века. Причины этого явления еще предстоит понять и объяснить. Существующая система Internet неидеальна, в ней не мало недостатков больших и малых. Наиболее серьезные трудности связаны с проблемой маршрутизации, не существует механизма выравнивания загрузки каналов в рамках внешних протоколов, механизмы управления не всегда удобны и безопасны, диагностика не совершенна. Система адресации Internet архаична и уже готов новый стандарт (расширение разрядности адресов до 128), многие сервисные услуги неудобны, например, не производится предупреждения об отключении связи при пассивности пользователя, telnet не имеет возможностей непосредственного копирования удаленных файлов, поисковые системы не всегда позволяют найти то, что нужно, если эта информация имеется и т.д. и пр. Но именно это должно привлечь новых молодых людей (возможно и из России), которые усовершенствуют систему. Ничто не идеально в этом мире, ведь совершенство означает прекращение развития и, следовательно, неизбежную гибель. Internet жив, возможно его идеи поменяют жизнь людей не меньше, чем это сделало радио или телевидение. Ведь именно Интернету мы обязаны появлением электронных журналов, всемирных дискуссионных клубов по интересам, глобальных баз данных, IP-телефонии, видеоконференций и прочих удивительных вещей, именно электронная почта помогла распространять правдивую информацию в незабвенные августовские дни 1991 года. Таким образом, телекоммуникационные сети могут стать гарантом демократии, можно блокировать телевидение и прессу, но чтобы остановить электронную почту, нужно выключить телефонную сеть по всей стране. Попробую сделать некоторые конкретные прогнозы в этой области на будущее. Меня на это подталкивает стоящая у меня дома на полке книга "Космическая эра. Прогнозы на 2001 год" (Москва, "Мир", 1970), которая является переводом книги "Space Ege in Fiscal Year 2001", 1966. В этой книге дан прогноз развития науки и технологии до 2001-го года. Прогнозы этой книги в области космоса оказались чересчур оптимистичными (обитаемые станции на Луне, полеты человека к Марсу, коммерция в космосе и т.д.). Удивительно, что во время написания этой книги люди уже разрабатывали и испытывали технологии, которые легли в основу Интернет. Привожу цитату из этой книги: "Устройства графической и буквенно-цифровой индикации будут использоваться не только как средство взаимодействия человека с машиной, но, по-видимому, с помощью таких быстродействующих устройств можно будет также осуществлять и связь между людьми". За более чем 34 года сделан совершенно точный прогноз относительно цифровых телекоммуникаций. Полагаю, прогресс в этой области даже превзошел то, что себе представляли авторы этой книги. Я не решаюсь сделать столь далекие предсказания (это написано в 1998 году и я не намерен изменять что-либо в будущем).
Время покажет, был ли я пессимистом или оптимистом. В том, что все это будет, я уверен, могу ошибаться только в сроках. Предпосылками для этого должны стать снижение цен на отоволоконные кабели, принтеры и терминальное оборудование, разработки дешевых специализированных интегральных схем, часть из которых уже имеется, другие разрабатываются сегодня; аппаратные устройства сжатия информации и много другое. Создание широкой информационной сети с доступом в каждый дом породит немало новых проблем. Это прежде всего обеспечение защиты частной информации, предотвращение вторжения в личную жизнь. Огромную работу здесь предстоит выполнить программистам. Это и разработка более эффективных алгоритмов сжатия данных, шифрования/дешифрования информации, новых протоколов передачи, удобных пользовательских интерфейсов, более совершенных распределенных баз данных и поисковых систем. Буду счастлив, если среди людей, кто внесет свой вклад в это общее дело, окажутся и читатели этой книги. В следующем веке сети предоставят много новых рабочих мест для граждан планеты Земля. Желаю гражданам всемирного государства Интернет новых успехов и приятных приключений. |
|
Previous:
7.2 Сетевые драйверы
UP:
7 Программирование для сетей (новые идеи, принципы и возможности)
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
9 Литература
Семенов Ю.А. (ГНЦ ИТЭФ) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Previous:
8.1 Вопросы по данному курсу
UP:
8 Заключение
|
WWW Site Search