Архитектура протоколов транспортной мультисервисной сети

Нарушения биполярности, которые не являются частью строки подавления нулей HDB3, рассматриваются как ошибки в линии и считаются отдельно для получения информации о качестве связи в тех случаях, когда функция CRC-4 не используется.

Условия тревоги E1 (CEPT)

Чрезмерная частота ошибок. Частота возникновения ошибок определяется по сигналам выравнивания кадров. При числе ошибок более 10?3, которое сохраняется от 4 до 5 секунд, подается сигнал тревоги, снимаемый после удержания числа ошибок не более 10?4 в течение 4 -- 5 секунд.

Потеря выравнивания кадров (или потеря синхронизации). Этот сигнал подается при наличии слишком большого числа ошибок в сигнале FAS (например, 3 или 4 ошибки FAS в последних 5 кадрах). Сигнал потери выравнивания сбрасывается при отсутствии ошибок FAS в двух последовательных кадрах. Сигнал потери выравнивания передается путем установки бита A (см. рисунок).

Потеря выравнивания мультикадра (используется для мультикадров 256S). Этот сигнал передается при обнаружении слишком большого числа ошибок в сигнале MAS. Сигнал передается за счет установки бита Y (см. рисунок). Сигнал тревоги (AIS). Сигнал AIS (Alarm Indication Signal) представляет собой некадрированный сигнал «все единицы», используемый для поддержки синхронизации при потере входного сигнала (например, условие тревоги в оборудовании, поддерживающем сигнал в линии). Отметим, что оборудование, получившее сигнал AIS, теряет синхронизацию кадров.

Поток E1 позволяет передавать услугу "определитель номера" на цифровые АТС клиента.

3.4 MGCP

Описание и назначение

MGCP Media Gateway Control Protocol дословно -- Протокол контроля медиа-шлюзов. Является протоколом связи в распределённых VoIP системах передачи голоса по протоколу IP.

MGCP описан в RFC 3435, который заменил устаревший к настоящему времени RFC 2705, заменивший, в свою очередь, Simple Gateway Control Protocol (SGCP).

Сходный протокол для тех же целей Megaco, совместная продукция IETF (RFC 3525) и ITU (рекомендации H.248-1). Оба протокола описаны единым аппаратно-программным интерфейсом (API) Архитектура и требования MGCP в RFC 2805

Разработчики этого протокола опирались на принцип декомпозиции шлюзов и сетевую архитектуру, состоящую из:

транспортных шлюзов (TGW);

контроллера шлюзов (MGC);

шлюзов сигнализации (SGW).

Впоследствии эти три элемента составили основу - Softswitch - гибкой системы управления коммутацией.

Рис. 3.4. Описание стека протоколов MGCP.

Функции

Распределённые системы состоят из агента вызовов -- Call Agent (или контроллера медиашлюза), по крайней мере одного медиашлюза (MG) и по крайней мере одного сигнального шлюза (SG), подключенных к Телефонной сети общего пользования (ТФОП). С точки зрения сети ОКС-7 такой симбиоз устройств рассматривается как один узел с одним общим пойнт-кодом.

Signaling Gateway (SG)

Шлюз сигнализации - обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к контроллеру шлюзов и перенос сигнальной информации в обратном направлении.

На практике сигнальный шлюз (SG) и медиашлюз (MG) подключены в один физический коммутатор, но это совсем не обязательно. Call Агент не использует MGCP для контроля сигнального шлюза (SG), для этих целей -- обратной связи между сигнальным шлюзом (SG) и Агентом используются протоколы SIGTRAN.

Media Gateway (MG)

Медиашлюз выполняет функции преобразования речевой информации, поступающей со стороны ТфОП в голосовых каналах с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP (кодирование и упаковку речевой информации в пакеты RTP, и далее в UDP и IP) а также обратное преобразование).

Медиашлюз использует протокол MGCP для сигнализации событий, таких как информация что трубка положена/снята или набираемые цифры вызываемого номера (донабор).

Call Agent

Call Агент - контроллер шлюзов, выполняет функции управления шлюзами, который использует протокол MGCP чтобы сообщать медиашлюзу:

какие события направлять Call Агенту

каким образом оконечные устройства должны соединяться друг с другом

какие тональные сигналы вызова должны воспроизводится на оконечных устройствах

MGCP позволяет также следить Call Агенту за состоянием оконечных устройств на медиашлюзе (MG).

Как правило, медиашлюз конфигурирован со списком Call Агентов, от которых может принимать инструкции-запросы.

В принципе, уведомления можно посылать разным Агентам от каждого оконечного устройства (как предусмотрено Call Агентами, для этого используется параметр NotifiedEntity). Практически однако, желательно, чтобы в данный момент всеми оконечными устройствами управлял один и тот контролер шлюзов; другие Call Агенты доступны в случае резервирования ресурсов для обеспечения избыточности, если первичный Агент отказывает, или теряет контакт с медиашлюзом. В случае такого отказа управление шлюзом автоматически переходит к резервному контролеру шлюзов. Всё о чём необходимо позаботиться для такого сценария, это обмен информацией о состоянии между двумя Агентами, однако, это не гарантирует, что оба не будут пытаться управлять одним и тем же шлюзом. Для разрешения конфликтов используется способность опрашивать шлюз, чтобы определить, который из Агентов является управляющим в данный момент.

Пакеты MGCP

Пакеты MGCP отличаются от многих других протоколов. Он резервирует обычно порт UDP 2427, датаграммы MGCP могут содержать и пустые значения, совсем не так как обычно строятся пакеты в протоколах TCP. Пакет MGCP является командой (запросом) или ответом. Команды (запросы) начинаются с четырехбуквенного кода, ответы начинаются с трехзначного цифрового кода.

В MGCP каждая команда несёт в себе идентификатор транзакции и получает ответ на каждую.

Список запросов содержит всего восемь команд: AUEP, AUCX, CRCX, DLCX, MDCX, NTFY, RQNT, RSIP.

Две команды используются Агентом, чтобы сделать запрос на медиа шлюз:

AUEP -- аудит конечного устройства и AUCX -- аудит соединения.

Три команды используются Call Агентом, чтобы управлять RTP соединением на медиа шлюзе (шлюз может также послать команду DLCX, когда нужно удалить соединение для самоуправления):

CRCX -- создать соединение,

DLCX -- удалить соединение,

MDCX -- изменить соединение.

Команда RQNT используется медиа шлюзом для запроса об уведомлениях используется Агентом, чтобы запросить уведомление о событиях на медиа шлюзе. В частности может использоваться для передачи сообщения о нажатой клавише в рамках тонального набора (в качестве альтернативного варианта вместо RFC 2833 или G.711-inband).

Команда NTFY используется медиа шлюзом, чтобы сообщить Агенту, что обнаружено событие, о котором Агент предварительно запросил уведомление (командой RQNT). Пример использования: переключение на другой тип передаваемых данных (с голоса на факс или наоборот).

Команда RSIP -- рестарт в процессе, используется медиа шлюзом, чтобы указать Агенту, идёт процесс перезапуска.

3.5 UDP

Описание и назначение

UDP - User Datagram Protocol/ Протокол для передачи датаграмм пользователя (RFC-768). Протокол UDP базируется на протоколе IP и предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает негарантированную доставку данных, т.е. не требует подтверждения их получения; кроме того, данный протокол не требует установления соединения между источником и приемником информации.

Функции

Уровень (по модели OSI): Транспортный.

UDP один из ключевых элементов Transmission Control Protocol/Internet Protocol, набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (в данном случае называемые датаграммами) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных. Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определён в RFC 768.

UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.

Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.

Структура пакета

UDP -- минимальный ориентированный на обработку сообщений протокол транспортного уровня, задокументированный в RFC 768. Соответственно выполняет все фунции транспортного уровня.

UDP не предоставляет никаких гарантий доставки сообщения для протокола верхнего уровня и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. -- Ненадёжный протокол датаграмм).

UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надёжная передача в случае необходимости должна реализовываться пользовательским приложением.

Рис.3.5. Структура пакета

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя

В этом поле указывается номер порта отправителя. Предполагается, что это значение задаёт порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из «хорошо известных».

Порт получателя

Это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если клиент -- хост-получатель, то номер порта эфемерный, иначе (сервер -- получатель) это «хорошо известный порт».

Длина датаграммы

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка -- 8 байт. Теоретически, максимальный размер поля -- 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 -- 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

В Jumbogram'мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (2^32 -- 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт -- данным.

Контрольная сумма

Поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями. Поле не является обязательным для IPv4.

Расчёт контрольной суммы

Метод для вычисления контрольной суммы определён в RFC 768.

Перед расчётом контрольной суммы UDP-сообщение дополняется в конце нулевыми битами до длины, кратной 16 битам (псевдозаголовок и добавочные нулевые биты не отправляются вместе с сообщением). Поле контрольной суммы в UDP-заголовке во время расчёта контрольной суммы отправляемого сообщения принимается нулевым.

Для расчёта контрольной суммы псевдозаголовок и UDP-сообщение разбивается на слова (1 слово = 2 байта (октета) = 16 бит). Затем рассчитывается поразрядное дополнение до единицы суммы всех слов с поразрядным дополнением. Результат записывается в соответствующее поле в UDP-заголовке.

Нулевое значение контрольной суммы зарезервировано и означает, что датаграмма не имеет контрольной суммы. В случае, если вычисленная контрольная сумма получилась равной нулю, поле заполняют двоичными единицами.

При получении сообщения получатель считает контрольную сумму заново (уже учитывая поле контрольной суммы), и, если в результате получится двоичное число из шестнадцати единиц (то есть 0xffff), то контрольная сумма считается сошедшейся. Если сумма не сходится (данные были повреждены при передаче), датаграмма уничтожается.

Псевдозаголовки

Псевдозаголовок для IPv4

Если UDP работает над IPv4, контрольная сумма вычисляется при помощи псевдозаголовка, который содержит некоторую информацию из заголовка IPv4. Псевдозаголовок не является настоящим IPv4-заголовком, используемым для отправления IP-пакета. В таблице приведён псевдозаголовок, используемый только для вычисления контрольной суммы.



Рис. 3.6. Псевдозаголовок для IPv4.

Адреса источника и получателя берутся из IPv4-заголовка. Значения поля «Протокол» для UDP равно 17 (0x11). Поле «Длина UDP» соответствует длине заголовка и данных.

Вычисление контрольной суммы для IPv4 необязательно, если она не используется, то значение равно 0.

Псевдозаголовок для IPv6

При работе UDP над IPv6 контрольная сумма обязательна. Метод для её вычисления был опубликован в RFC 2460:

При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:

Рис. 3.7. Псевдозаголовок для IPv6.

Адрес источника такой же, как и в IPv6-заголовке. Адрес получателя -- финальный получатель; если в IPv6-пакете не содержится заголовка маршрутизации (Routing), то это будет адрес получателя из IPv6-заголовка, в противном случае, на начальном узле, это будет адрес последнего элемента заголовка маршрутизации, а на узле-получателе -- адрес получателя из IPv6-заголовка. Значение «Следующий заголовок» равно значению протокола -- 17 для UDP. Длина UDP -- длина UDP-заголовка и данных.

Надёжность и решения проблемы перегрузок

Из-за недостатка надёжности приложения UDP должны быть готовы к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надёжности на прикладном уровне.

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP -- примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или erasure codes.

Более серьёзной потенциальной проблемой является то, что в отличие от TCP, основанные на UDP приложения не обязательно имеют хорошие механизмы контроля и избегания перегрузок. Чувствительные к перегрузкам UDP-приложения, которые потребляют значительную часть доступной пропускной способности, могут поставить под угрозу стабильность в Интернете.

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol -- протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Приложения

Многочисленные ключевые Интернет-приложения используют UDP, в их числе -- DNS (где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа), Простой Протокол Управления Сетями (SNMP), Протокол Маршрутной Информации (RIP), Протокол Динамической Конфигурации Узла (DHCP).

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

Сравнение UDP и TCP

TCP -- ориентированный на соединение протокол, что означает необходимость «рукопожатия» для установки соединения между двумя хостами. Как только соединение установлено, пользователи могут отправлять данные в обоих направлениях.

Надёжность -- TCP управляет подтверждением, повторной передачей и тайм-аутом сообщений. Производятся многочисленные попытки доставить сообщение. Если оно потеряется на пути, сервер вновь запросит потерянную часть. В TCP нет ни пропавших данных, ни (в случае многочисленных тайм-аутов) разорванных соединений.

Упорядоченность -- если два сообщения последовательно отправлены, первое сообщение достигнет приложения-получателя первым. Если участки данных прибывают в неверном порядке, TCP отправляет неупорядоченные данные в буфер до тех пор, пока все данные не могут быть упорядочены и переданы приложению.

Тяжеловесность -- TCP необходимо три пакета для установки сокет-соединения перед тем, как отправить данные. TCP следит за надёжностью и перегрузками.

Потоковость -- данные читаются как поток байтов, не передается никаких особых обозначений для границ сообщения или сегментов.

UDP -- более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путем передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. Однако, основным преимуществом UDP над TCP являются приложения для голосовой связи через интернет-протокол (Voice over IP, VoIP), в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

Ненадёжный -- когда сообщение посылается, неизвестно, достигнет ли оно своего назначения -- оно может потеряться по пути. Нет таких понятий, как подтверждение, повторная передача, тайм-аут.

Неупорядоченность -- если два сообщения отправлены одному получателю, то порядок их достижения цели не может быть предугадан.

Легковесность -- никакого упорядочивания сообщений, никакого отслеживания соединений и т. д. Это небольшой транспортный уровень, разработанный на IP.

Датаграммы -- пакеты посылаются по отдельности и проверяются на целостность только если они прибыли. Пакеты имеют определенные границы, которые соблюдаются после получения, то есть операция чтения на сокете-получателе выдаст сообщение таким, каким оно было изначально послано.

Нет контроля перегрузок -- UDP сам по себе не избегает перегрузок. Для приложений с большой пропускной способностью возможно вызвать коллапс перегрузок, если только они не реализуют меры контроля на прикладном уровне.

3.6 IP

Описание и назначение

IP - Internet Protocol - Протокол межсетевого взаимодействия, который используется в TCP/IP сетях (RFC-791, -950, -919, -922).

Протокол IP организует пакетную передачу информации от узла к узлу IP-сети, не используя процедур установления соединения между источником и приемником информации.

Именно IP стал тем протоколом, который объединил отдельные компьютерные сети во всемирную сеть Интернет. Неотъемлемой частью протокола является адресация сети (см. IP-адрес).

Протокол IP является датаграммным протоколом: при передаче информации по протоколу IP каждый пакет передается от узла к узлу и обрабатывается в узлах независимо от других пакетов.

Функции

IP объединяет сегменты сети в единую сеть, обеспечивая доставку пакетов данных между любыми узлами сети через произвольное число промежуточных узлов (маршрутизаторов). Он классифицируется как протокол третьего уровня по сетевой модели OSI, т.е. поддерживает функции сетевого уровня.

Маршрутизация и ретрансляция

Сетевые соединения

Мультиплексирование сетевых соединений

Фрагментация

Обнаружение и исправление ошибок

Упорядочивание

Управление потоком данных

Перенос срочных данных

Сброс сетевого соединения

Сервисный выбор

Отображение между сетевыми адресами и адресами звена данных

Отображение передачи данных в режиме без установления соединения сетевого уровня на передачу без установления соединения уровня звена данных

IP не гарантирует надёжной доставки пакета до адресата, так как он не имеет механизмов повторной передачи и механизмов управления потоком данных (flow-control). В частности, пакеты могут прийти не в том порядке, в котором были отправлены, продублироваться (приходят две копии одного пакета), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не прийти вовсе. Гарантию безошибочной доставки пакетов дают некоторые протоколы более высокого уровня -- транспортного уровня сетевой модели OSI, -- например, TCP, которые используют IP в качестве транспорта.

Структура протокола в различных версиях

В современной сети Интернет используется IP четвёртой версии, также известный как IPv4. В протоколе IP этой версии каждому узлу сети ставится в соответствие IP-адрес длиной 4 октета (4 байта). При этом компьютеры в подсетях объединяются общими начальными битами адреса. Количество этих бит, общее для данной подсети, называется маской подсети (ранее использовалось деление пространства адресов по классам -- A, B, C; класс сети определялся диапазоном значений старшего октета и определял число адресуемых узлов в данной сети, сейчас используется бесклассовая адресация).

В настоящее время вводится в эксплуатацию шестая версия протокола -- IPv6, которая позволяет адресовать значительно большее количество узлов, чем IPv4. Эта версия отличается повышенной разрядностью адреса, встроенной возможностью шифрования и некоторыми другими особенностями. Переход с IPv4 на IPv6 связан с трудоёмкой работой операторов связи и производителей программного обеспечения и не может быть выполнен одномоментно. На середину 2010 года в Интернете присутствовало более 3000 сетей, работающих по протоколу IPv6. Для сравнения, на то же время в адресном пространстве IPv4 присутствовало более 320 тысяч сетей, но в IPv6 сети гораздо более крупные, нежели в IPv4.

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

Рис.3.8. Структура протокола IP в версии 4.

Версия -- для IPv4 значение поля должно быть равно 4.

IHL -- (Internet Header Length) длина заголовка IP-пакета в 32-битных словах (dword). Именно это поле указывает на начало блока данных (англ. payload -- полезный груз) в пакете. Минимальное корректное значение для этого поля равно 5.

Длина пакета -- длина пакета в октетах, включая заголовок и данные. Минимальное корректное значение для этого поля равно 20, максимальное -- 65 535.

Идентификатор -- значение, назначаемое отправителем пакета и предназначенное для определения корректной последовательности фрагментов при сборке пакета. Для фрагментированного пакета все фрагменты имеют одинаковый идентификатор.

3 бита флагов. Первый бит должен быть всегда равен нулю, второй бит DF (don't fragment) определяет возможность фрагментации пакета и третий бит MF (more fragments) показывает, не является ли этот пакет последним в цепочке пакетов.

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

Время жизни (TTL) -- число маршрутизаторов, которые может пройти этот пакет. При прохождении маршрутизатора это число уменьшатся на единицу. Если значения этого поля равно нулю то, пакет должен быть отброшен и отправителю пакета может быть послано сообщение Time Exceeded (ICMP тип 11 код 0).

Протокол -- идентификатор интернет-протокола следующего уровня указывает, данные какого протокола содержит пакет, например, TCP или ICMP (см. IANA protocol numbers и RFC 1700). В IPv6 называется «Next Header».

Контрольная сумма заголовка -- вычисляется в соответствии с RFC 1071.



Рис.3.9. Структура протокола IP в версии 6.

Версия -- для IPv6 значение поля должно быть равно 6.

Класс трафика -- определяет приоритет трафика (QoS, класс обслуживания).

Метка потока -- уникальное число, одинаковое для однородного потока пакетов.

Длина полезной нагрузки -- длина данных в октетах (заголовок IP-пакета не учитывается).

Следующий заголовок -- задаёт тип расширенного заголовка (англ. IPv6 extension), который идёт следующим. В последнем расширенном заголовке поле Next header задаёт тип транспортного протокола (TCP, UDP и т. д.) и определяет следующий инкапсулированный уровень.

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

3.7 Ethernet

Ethernet (от англ. ether «эфир») -- семейство технологий пакетной передачи данных для компьютерных сетей.

Ethernet - архитектура сетей с разделяемой средой и широковещательной передачей со скоростью 10Мбит/с (все узлы получают пакет одновременно), метод доступа - CSMA/CD. Стандарт определен документом IEEE 802.3. Физическая топология - шина для экранированного коаксиального кабеля (коаксиала), звезда - для витой пары, двухточечное соединение - для оптоволоконного кабеля (оптоволокна).

Функции

Стандарты Ethernet определяют проводные соединения и электрические сигналы на физическом уровне, формат кадров и протоколы управления доступом к среде -- на канальном уровне модели OSI и поддерживает функции канального уровня.

Установление и разъединение соединения уровня звена данных

Передача данных

Расщепление звена данных

Управление порядком следования SDU уровня звена данных

Синхронизация

Обнаружение и исправление ошибок

Управление потоком данных

Отображение SDU звена данных на PDU звена данных

Сброс соединения звена данных

Коммутация и ретрансляция

Поддержка топологии сети

Обеспечение обмена информацией между смежными узлами сети

Ethernet в основном описывается стандартами IEEE группы 802.3. Ethernet стал самой распространённой технологией ЛВС в середине 1990-х годов, вытеснив такие устаревшие технологии, как Arcnet и Token ring.

Формат кадра

Существует несколько форматов Ethernet-кадра.

Первоначальный Version I (больше не применяется).

Ethernet Version 2 или Ethernet-кадр II, ещё называемый DIX (аббревиатура первых букв фирм-разработчиков DEC, Intel, Xerox) -- наиболее распространена и используется по сей день. Часто используется непосредственно протоколом Интернет.

Novell -- внутренняя модификация IEEE 802.3 без LLC (Logical Link Control).

Кадр IEEE 802.2 LLC.

Кадр IEEE 802.2 LLC/SNAP.

Некоторые сетевые карты Ethernet, производимые компанией Hewlett-Packard использовали при работе кадр формата IEEE 802.12, соответствующий стандарту 100VG-AnyLAN.

В качестве дополнения Ethernet-кадр может содержать тег IEEE 802.1Q для идентификации VLAN, к которой он адресован, и IEEE 802.1p для указания приоритетности.

Разные типы кадра имеют различный формат и значение MTU.

Рис. 3.10. Формат кадра Ethernet Version 2 или Ethernet-кадр II

MAC-адреса

При проектировании стандарта Ethernet было предусмотрено, что каждая сетевая карта (равно как и встроенный сетевой интерфейс) должна иметь уникальный шестибайтный номер (MAC-адрес), прошитый в ней при изготовлении. Этот номер используется для идентификации отправителя и получателя кадра, и предполагается, что при появлении в сети нового компьютера (или другого устройства, способного работать в сети) сетевому администратору не придётся настраивать MAC-адрес.

Уникальность MAC-адресов достигается тем, что каждый производитель получает в координирующем комитете IEEE Registration Authority диапазон из шестнадцати миллионов (2^24) адресов, и по мере исчерпания выделенных адресов может запросить новый диапазон. Поэтому по трём старшим байтам MAC-адреса можно определить производителя. Существуют таблицы, позволяющие определить производителя по MAC-адресу; в частности, они включены в программы типа arpalert.

MAC-адрес считывается один раз из ПЗУ при инициализации сетевой карты, в дальнейшем все пакеты генерируются операционной системой. Все современные операционные системы позволяют поменять его. Для Windows начиная как минимум с Windows 98 он менялся в реестре. Некоторые драйвера сетевых карт давали возможность изменить его в настройках, но смена работает абсолютно для любых карт.

Некоторое время назад, когда драйверы сетевых карт не давали возможность изменить свой MAC-адрес, а альтернативные возможности не были слишком известны, некоторые провайдеры Internet использовали его для идентификации машины в сети при учёте трафика. Программы из Microsoft Office, начиная с версии Office 97, записывали MAC-адрес сетевой платы в редактируемый документ в качестве составляющей уникального GUID-идентификатора. MAC адрес роутера передавался Mail.Ru агентом на свой сервер открытым текстом при логине.

Разновидности Ethernet

В зависимости от скорости передачи данных, и передающей среды существует несколько вариантов технологии. Независимо от способа передачи стек сетевого протокола и программы работают одинаково практически во всех нижеперечисленных вариантах.

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

Большинство Ethernet-карт и других устройств имеет поддержку нескольких скоростей передачи данных, используя автоопределение (autonegotiation) скорости и дуплексности, для достижения наилучшего соединения между двумя устройствами. Если автоопределение не срабатывает, скорость подстраивается под партнёра, и включается режим полудуплексной передачи. Например, наличие в устройстве порта Ethernet 10/100 говорит о том, что через него можно работать по технологиям 10BASE-T и 100BASE-TX, а порт Ethernet 10/100/1000 -- поддерживает стандарты 10BASE-T, 100BASE-TX и 1000BASE-T.

3.8 Речевой кодек G.729

Для эффективной передачи любого вида информации по сети требуется предварительная подготовка - сжатие, форматирование, кодирование.

Для подготовки информации различными фирмами предложено большое количество аудиокодеков.

В данной работе используется кодек для передачи речи по пакетным сетям: G.729.

G.729 -- узкополосный речевой кодек, который применяется для эффективного цифрового представления узкополосной телефонной речи (сигнала телефонного качества). Такая речь характеризуется полосой между 300 и 3400 Гц и может быть оцифрована с частотой дискретизации 8 кГц. В идеале речевой кодек должен представлять речь такой разрядностью, какая только возможна. В этом случае восстановленная речь будет точно соответствовать оригиналу. На практике приходится выбирать разрядность кодека и мириться с некоторой погрешностью квантования.

G.729 -- широко используемый тип кодека, скорость 8 Кбит/с. Согласно теории, речевой сигнал длительностью в одну секунду можно полностью описать (то есть оцифровать, передать или сохранить в цифровом виде и затем восстановить в исходный сигнал по цифровому представлению) цифровым потоком 60 байт/сек. Идея оцифровывать и передавать (или сохранять) в цифровом виде не сам сигнал, а его параметр (количество переходов через ноль, спектральные характеристики и др.), чтобы затем по этим параметрам выбирать модель голосового тракта и синтезировать исходный сигнал, лежит в основе вокодеров (VOice CODER) или «синтезирующих кодеков».

Для всех типов кодеков справедливо правило: чем меньше плотность цифрового потока, тем больше восстановленный сигнал отличается от оригинала. Однако восстановленный сигнал гибридных кодеков обладает вполне высокими характеристиками, восстанавливается тембр речевого сигнала, его динамические характеристики, другими словами, его «узнаваемость» и «распознаваемость».

Алгоритм основан на модели кодирования с использованием линейного предсказания с возбуждением по алгебраической кодовой книге (CELP-модель). Кодер оперирует с кадрами речевого сигнала длиной 10 мс, дискретизованными с частотой 8 КГц, что соответствует 80-ти 16-битным отсчётам в линейном законе. Для каждого кадра производится анализ речевого сигнала и выделяются параметры модели (коэффициенты фильтра линейного предсказания, индексы и коэффициенты усиления в адаптивной и фиксированной кодовых книгах). Далее эти параметры кодируются и передаются в канал.

В декодере битовая посылка используется для восстановления параметров сигнала возбуждения и коэффициентов синтезирующего фильтра. Речь восстанавливается путём пропускания сигнала возбуждения через кратковременный синтезирующий фильтр.

Синтезирующий фильтр имеет полюсную передаточную функцию 10-го порядка. Для работы синтезатора основного тона используется адаптивная кодовая книга. Впоследствии речь улучшается адаптивной постфильтрацией.

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

Вокодер обрабатывает кадры речевых сигналов длиной 10 мс. Дополнительно существует задержка длиной 5 мс (look-ahead buffer), что в сумме выливается в алгоритмическую задержку 15 мс («10+5»). Задержки речевого сигнала в практическом приложении этого алгоритма также определяются временем, затрачиваемым на:

процессы кодирования и декодирования;

передачу по каналу;

мультиплексирование при комбинировании аудиоданных с другими видами данных.

3.9 RTP

Протокол передачи в реальном времени (RTP) обеспечивает сквозные услуги доставки звуковой и видеоинформации в реальном масштабе времени;

RTP обеспечивает идентификацию типа полезной нагрузки, нумерацию последовательности, временные метки, и текущий контроль доставки.

Протокол был разработан Audio-Video Transport Working Group в IETF и впервые опубликован в 1996 году как RFC 1889, и заменён в RFC 3550 в 2003 году.

Протокол RTP переносит в своём заголовке данные, необходимые для восстановления аудиоданных или видеоизображения в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и т. п.). В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты.

RTP не имеет стандартного зарезервированного номера порта. Единственное ограничение состоит в том, что соединение проходит с использованием чётного номера, а следующий нечётный номер используется для связи по протоколу RTCP. Тот факт, что RTP использует динамически назначаемые адреса портов, создаёт ему трудности для прохождения межсетевых экранов, для обхода этой проблемы, как правило, используется STUN-сервер.

Установление и разрыв соединения не входит в список возможностей RTP, такие действия выполняются сигнальным протоколом (например, RTSP или SIP протоколом).

RTP был разработан как протокол реального времени, из конца в конец (end-to-end), для передачи потоковых данных. В протокол заложена возможность компенсации джиттера и детектированию нарушения последовательности пакетов данных -- типичных событий при передаче через IP-сети. RTP поддерживает передачу данных для нескольких адресатов через Multicast. RTP рассматривается как основной стандарт для передачи голоса и видео в IP-сетях и совместно с кодеками.

Приложения, формирующие потоки реального времени, требуют своевременной доставки информации и для достижения этой цели могут допустить некоторую потерю пакетов. Например, потеря пакета в аудио-приложении может привести к доле секунды тишины, которая может быть незаметна при использовании подходящих алгоритмов скрытия ошибок. Протокол TCP, хотя и стандартизирован для передачи RTP, как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки. Вместо этого, большинство реализаций RTP базируется на UDP. Кроме этого, существуют другие спецификации для транспортных протоколов SCTP и DCCP, но они мало распространены.

Компоненты протокола

Спецификация RTP описывает два подпротокола:

Протокол передачи данных, RTP, который взаимодействует с передачей данных реального времени. Информация, предоставляемая посредством этого протокола, включает в себя тайм-штамп (для синхронизации), последовательный номер (для детектирования потери и дублирования пакетов) и формат полезной нагрузки, который определяет формат кодирования данных.

Протокол контроля, RTCP, используемый для определения качества обслуживания (QOS), обратной связи и синхронизации между медиа-потоками. Занимаемая полоса пропускания RTCP мала в сравнении с RTP, обычно около 5 %.

Управляющий сигнальный протокол, такой как SIP, H.323, MGCP или H.248. Сигнальные протоколы управляют открытием, модификацией и закрытием RTP-сессий между устройствами и приложениями реального времени.

Управляющий протокол описания медиа, такой как Session Description Protocol.

Функции

Протокол RTP (англ. Real-time Transport Protocol) работает на транспортном уровне. И поддерживает функции транспортного уровня

Структура пакета

Рис. 3.11. Структура пакета протокола RTP.

0-1 -- Ver. (2 бита) указывает версию протокола. Текущая версия -- 2.

2 -- P (один бит) используется в случаях, когда RTP-пакет дополняется пустыми байтами на конце.

3 -- X (один бит) используется для указания расширений протокола, задействованных в пакете.

4-7 -CC (4 бита) содержит количество CSRC-идентификаторов, следующих за постоянным заголовком.

8 -- M (один бит) используется на уровне приложения и определяется профилем. Если это поле установлено, то данные пакета имеют какое-то особое значение для приложения.

9-15 -- PT (7 бит) указывает формат полезной нагрузки и определяет её интерпретацию приложением.

64-95 -- SSRC указывает источник синхронизации.

Список литературы

1. Электронный курс лекций по дисциплине «Мультисервисные сети связи». СибГУТИ.

2. Теоретический материал для выполнения лабораторной работы №1 «Эталонная модель взаимодействия - OSI» по дисциплине «Мультисервисные сети связи». СибГУТИ.

3. Теоретический материал для выполнения лабораторной работы №2 «Архитектура протоколов транспортной мультисервисной сети» по дисциплине «Мультисервисные сети связи». СибГУТИ.

4. Теоретический материал для выполнения лабораторной работы №3 «Протоколы транспортных и информационных сетей» по дисциплине «Мультисервисные сети связи». СибГУТИ.

5. А.Голышко. Статья «Три концепции NGN. Конец истории "традиционных" сетей связи». Информационно-справочная социальная сеть радиотехников и электроников http://umup.ru

6. Г.Г. Яновский. Статья «IP Multimedia Subsystem: принципы, стандарты и архитектура». 2006г. Вестник связи http://greenmount.narod.ru/qnowskijGG.html

7. Википедия. Свободная Энциклопедия. Статьи: http://ru.wikipedia.org/wiki/ISUP, http://ru.wikipedia.org/wiki/Message_Transfer_Part, http://ru.wikipedia.org/wiki/MGCP, http://ru.wikipedia.org/wiki/UDP, http://ru.wikipedia.org/wiki/IP и др.

Размещено на Allbest.ru

...