RFC 3033 — Применение информационного поля и идентификатора протокола, определённых Рекомендациями ITU-T Q.2941 и Q.2957, в интересах IP-протокола в MPLS-системах

1. Цель документа

Этот стандарт определяет применение (правила использования) информационного поля и идентификатора протокола, представленных в стандартах Q.2941 и Q.2957, в интересах IP-протокола.

• Рекомендация ITU-T Q.2941

  «Digital subscriber signalling system no. 2 — Generic identifier transport»
  (Система сигнализации №2 для цифровых абонентов — Доставка единого идентификатора).

• Рекомендация ITU-T Q.2957

  «Digital subscriber signalling system no. 2 — User-to-user signalling»
  (Система сигнализации №2 для цифровых абонентов — Межабонентская (сквозная) сигнализация).

2. ATM-соединения, связанные с сеансом связи

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

Основными характеристиками ШЦСИО (B-ISDN) являются высокая скорость передачи, логическое мультиплексирование, связанное с виртуальными маршрутами и соединениями (VP/VC), и адаптивное обеспечения качества обслуживания (QoS) в каждом виртуальном соединении (VC-соединение). Поэтому вполне естественно использовать указанные характерные преимущества ШЦСИО с целью внедрения в IP-сети современного метода обслуживания мультимедийного трафика. Адаптивное обеспечение качества обслуживания и логическое мультиплексирование в ШЦСИО являются наиболее вероятным подходом при обеспечении гарантированной высококачественной связи в Internet-сети. И когда соответствующее виртуальное соединение обеспечивает проведение продолжительного сеанса связи, тогда может быть достигнута высокая эффективность доставки пакетов за счёт использования высокой скорости передачи и логического мультиплексирования в ШЦСИО.

Далее рассматриваются функции ШЦСИО-сигнализации, которые востребованы при проведении сеанса связи по виртуальному соединению, и которые усовершенствованы в целях поддержки IP-протокола.

2.1. Сигнализация продолжительного сеанса связи (сессии)

На рис. 2.1 приведён пример формирования VC-соединения для доставки пакетов в течение продолжительной сессии.

В начале, доставка пакетов в течение нового сеанса связи осуществляется по VC-соединению, установленному между маршрутизаторами в режиме «по-умолчанию». Затем, если маршрутизатор определяет, что сеанс связи является продолжительным, то он устанавливает новое VC-соединение для этой продолжительной сессии. Если новое VC-соединение сформировано успешно, то доставка пакетов перемещается в новое VC-соединение в течение этой продолжительной сессии.

В этой процедуре устанавливается ATM/VC-соединение, и программный модуль ШЦСИО-сигнализации, расположенный на стороне вызываемого маршрутизатора, должен распознать, что входящий вызов относится к сеансу связи с использованием IP-протокола, и оповестить об этом программный модуль, реализующий функции IP-протокола (IP-модуль). Основываясь на этой информации, IP-модуль переведёт передачу IP-пакетов по новому VC-соединению.

Более того, для реализации такой процедуры сигнализации, система ШЦСИО-сигнализации должна включать идентификатор сеанса связи в качестве информационного элемента (ИнфЭл). Существующие ИнфЭл, например, «информация о нижнем уровне ШЦСИО» (B-LLI), «информация о верхнем уровне ШЦСИО» (B-HLI), «информация об интерфейсе «пользователь-пользователь» (User-user) и «общий идентификатор» (Generic Identifier), способны доставлять данные об идентификаторе сеанса связи. Учитывая специфическое предназначение всех этих ИнфЭл, наиболее приемлемым из них для использования является ИнфЭл «общий идентификатор».

2.2. Сигнализация сеанса высококачественной связи

Главное отличие сигнализации запроса сеанса высококачественной связи (QoS-sensitive session signaling) от сигнализации продолжительного сеанса связи (сессии, long-lived session signaling) заключается в том, что вызов (запрос) не обусловлен фактом обнаружения продолжительного сеанса связи, а обусловлен функционированием протокола, отвечающего за установление высококачественного соединения для доставки данных, например, протокола резервирования ресурса (Resource ReSerVation Protocol — RSVP, RFC 2205). Для внедрения QoS-сигнализации в ATM-системы, ATM-сеть должна доставлять маршрутизаторам не только идентификатор сессии, но и идентификатор протокола, отвечающего за настройку высококачественного соединения (QoS-протокол).

Существует две схемы доставки данных о QoS-протоколе. Первая из них предусматривает доставку по VC-соединению между маршрутизаторами, установленному в режиме «по-умолчанию», или доставку по соответствующему VC-соединению. В данном случае, сеанс высококачественной связи и ATM/VC-соединение устанавливаются последовательно. Вторая схема предусматривает доставку данных о QoS-протоколе в формате ИнфЭл в рамках системы ШЦСИО-сигнализации. В данном случае, сеанс высококачественной связи и ATM/VC-соединение устанавливаются одновременно. Вторая схема имеет следующие преимущества (по сравнению с первой):

• Проще в реализации:

  • Управление доступом проще, так как управление доступом к IP- и ATM-уровням может предоставляться одновременно.

  • Контрольный счётчик времени реализуется проще, так как нет необходимости контролировать формирование IP- и ATM-соединений последовательно.

• Если QoS-протокол поддерживает процедуры согласования, то ATM/VC-соединение может быть сформирован по результатам процедуры согласования, проведённой QoS-протоколом, использующим это соединение.

Тем не менее, вторая схема не работоспособна, по крайней мере, в том случае, когда для проведения сеанса высококачественной связи используется постоянный виртуальный канал (Permanent Virtual Circuit, PVC). Более того, следует учитывать обе процедуры.

На рис. 2.2 представлена диаграмма передачи последовательности сообщений, которая обеспечивает одновременную организацию сеанса высококачественной связи и ATM/VC-соединения.

В настоящее время RSVP-протокол выполняет функции настройки соединения, а в будущем, вероятнее всего, будут созданы новые протоколы для настройки соединений.

Для реализации рассмотренной процедуры сигнализации, система ШЦСИО-сигнализации должна включать ИнфЭл «пользователь-пользователь», который способен доставлять протокольные данные настройки соединения.

3. Информационные элементы сигнализации: «пользователь-пользователь» и «общий идентификатор»

3.1. «Общий идентификатор»

ИнфЭл «Общий идентификатор» позволяет сторонам сквозного соединения в ATM-сети обмениваться идентификаторами. Описание этого идентификатора представлено в Рекомендациях ITU-T Q.2941, Q.2941.1 и Q.2941.2. В этих стандартах «Общий идентификатор» рассматривается как дополнительный ИнфЭл протокола сигнализации через интерфейс «пользователь-сеть», описанный в Рекомендациях ITU-T Q.2931 и Q.2971. Протокольные сообщения «Setup», «Alerting», «Connect», «Release», «Release Complete», «Add Party», «Party Alerting», «Add Party Ack», «Add Party Reject», «Drop Party» и «Drop Party Ack», которыми обмениваются взаимодействующие стороны сквозного соединения в ATM-сети, могут включать до трёх ИнфЭл «Общий идентификатор». ATM-сеть транслирует ИнфЭл «Общий идентификатор» прозрачно, если только он не содержит ошибок в правилах кодирования.

На рис. 3.1 представлен формат ИнфЭл «Общий идентификатор» (Q.2931, Q.2941), который имеет следующее кодирование:

• Идентификатор ИнфЭл (первый октет)

  В данном случае, этот октет имеет кодировку: «01111111» (0x7F), — «Доставка общего идентификатора».

• Октет 2

  Включает:

  • Биты 1…5

  Это поле содержит указания для обработки ИнфЭл. Оно включает:

  • Биты 1…3

    Инструкция по обработке ИнфЭл.

  • Бит 4

    Резервный бит.

  • Бит 5

    Бит «Флаг». Если этот бит имеет значение «1», то необходимо следовать инструкции по обработке ИнфЭл.

  • Биты 6…7

    Это поле определяет стандарт кодирования (международный, национальный и др.).

• Октеты 3…4

  Размер поля полезной нагрузки ИнфЭл.

• Октет 5

  Это поле указывает на стандарт или прикладную систему, использующую данный ИнфЭл. Для IP-протокола это поле может иметь следующие значения:

  • «00000011» (0x03) — IPv4-протокол.

  • «00000100» (0x04) — ST2+ (протокол доставки потокового трафика в Internet-сети, Internet Stream Protocol, RFC 1819).

  • «00000101» (0x05) — IPv6-протокол.

  • «00000110» (0x06) — MPLS-система.

  Примечание. Кроме указанных стандартов поддерживаются и другие, например, DSM-CC (Digital Storage Media Command and Control), H.310/H.321, MPOA (Multiprotocol over ATM), ATM VCC (Virtual Channel Connection) Trunking, AAL2 (ATM Adaptation Layer) и H.323/H.245.

• Октет 6

  Поле «Тип идентификатора». Это поле может принимать следующие значения:

  • «00000001» (0x01) — сеанс связи.

  • «00000010» (0x02) — ресурс.

  • «00001010 … 11111101» (0x10…0xFD) — зарезервировано для IANA.

  • «11111110» (0xFE) — для экспериментального или корпоративного применения.

• Октет 7

  Поле «Длина идентификатора».

• Октет 8…

  Поле «Значение идентификатора» (с 8-го октета).

ИнфЭл «Общий идентификатор» может содержать несколько идентификаторов, а его максимальная длина составляет 63 октета.

3.2. Сигнализация через интерфейс «Пользователь-пользователь»

Сигнализация через интерфейс «Пользователь-пользователь» обеспечивает доставку информации по сквозному соединению ATM-сети между взаимо действующими пользователями. В Рекомендациях ITU-T Q.2931, Q.2957 и Q.2971 она рассматривается как дополнительный ИнфЭл для протокола сигнализации через интерфейс «Пользователь-сеть». Протокольные сообщения «Setup», «Alerting», «Connect», «Release», «Release Complete», «Progress», «Add Party», «Party Alerting», «Add Party Ack», «Add Party Reject», «Drop Party» и «Drop Party Ack», которыми обмениваются взаимодействующие стороны сквозного соединения в ATM-сети, могут включать ИнфЭл «Пользователь-пользователь». ATM-сеть транслирует ИнфЭл «Пользователь-пользователь» прозрачно, если только он не содержит ошибок в правилах кодирования.

С точки зрения реальных систем ШЦСИО-сигнализации, кажется, что ИнфЭл «Общий идентификатор» и «Пользователь-пользователь» имеют одинаковое функциональное предназначение. Однако некоторые исключения из правил их обработки совпадают не полностью, так как их цели различны. ИнфЭл «Общий идентификатор» разработан для доставки идентификаторов между плоскостями управления (c-planes^[?] ) ШЦСИО-архитектуры, в то время как сквозная сигнализация «Пользователь-пользователь» разработана для доставки данных пользователя через плоскости управления ШЦСИО-архитектуры. Другое различие заключает в том, что сквозная сигнализация «Пользователь-пользователь» обеспечивает межсетевое взаимодействие на основе применения ИнфЭл «Пользователь-пользователь», установленного Рекомендацией ITU-T Q.931, а ИнфЭл «Общий идентификатор» для этого не предусмотрен. Также следует заметить, что ATM-сеть может проверять содержание ИнфЭл «Общий идентификатор», но не способна проверить содержание ИнфЭл «Пользователь-пользователь».

На рис. 3.2 представлен формат ИнфЭл «Пользователь-пользователь», который имеет следующее кодирование:

• Идентификатор ИнфЭл (первый октет)

  В данном случае, этот октет имеет кодировку: «01111110» (0x7E), — «Пользователь-пользователь».

• Октет 2

  Включает:

  • Биты 1…5

    Это поле содержит указания для обработки ИнфЭл. Оно включает:

    • Биты 1…3

      Инструкция по обработке ИнфЭл.

    • Бит 4

      Резервный бит.

    • Бит 5

      Бит «Флаг». Если этот бит имеет значение «1», то необходимо следовать инструкции по обработке ИнфЭл.

  • Биты 6…7

    Это поле определяет стандарт кодирования (международный, национальный и др.).

• Октеты 3…4

  Размер поля полезной нагрузки ИнфЭл.

• Октет 5

  Это поле указывает на протокол верхнего уровня, использующего данный ИнфЭл.

• Октет 6

  Поле «Информация пользователя». Это поле содержит информацию интерфейса «Пользователь-пользователь», которая подлежит доставке.

Максимальная длина ИнфЭл «Пользователь-пользователь» составляет 133 октета.

4. Назначение полей: «Информация» и «Идентификатор протокола»

4.1. Назначение в ИнфЭл «Общий идентификатор»

4.1.1. Использование ИнфЭл «Общий идентификатор»

Принцип назначения полей «Идентификатор протокола» и «Информация» в интересах IP-протокола в ИнфЭл «Общий идентификатор» представлен на рис. 4.1.

Поле «Идентификатор стандарта или прикладной системы» (Identifier related standard/application) содержит одно из следующих значений: «IPv4», «ST2+», «IPv6» или «MPLS». Поле «Тип идентификатора» (Identifier type) содержит одно из следующих значений: «Session», «Resource» или «Experiment/Organization».

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

	Стандарт/прикладная система	Тип идентификатора
Идентификатор IPv4-сессии	IPv4	Session
Идентификатор IPv6-сессии	IPv6	Session
Идентификатор виртуального MPLS-соединения	MPLS	Resource
Экспериментальное или корпоративное применение	IPv4/ST2+/IPv6/MPLS	Experiment

Сообщение ШЦСИО-сигнализации, доставляемое между сторонами (пользователями) сквозного соединения, может содержать до трёх ИнфЭл «Общий идентификатор». Каждый из этих ИнфЭл может включать несколько идентификаторов.

Когда сообщение ШЦСИО-сигнализации, содержащее ИнфЭл «Общий идентификатор», поступает в ATM-сеть, которая такой идентификатор не поддерживает, тогда сеть «сбрасывает» вызов, уничтожает ИнфЭл или уничтожает всё сообщение (Q.2931 и Q.2941.1).

Для обеспечения надёжной доставки ИнфЭл «Общий идентификатор», когда вызывающая сторона передаёт сообщение «Setup» или «Add Party», содержащее три ИнфЭл «Общий идентификатор», вызываемая сторона должна направить ответное сообщение «Connect» или «Add Party Ack», которое должно содержать, по крайней мере, один ИнфЭл «Общий идентификатор». Вызываемая сторона может не включать в своё ответное сообщение те же самые идентификаторы, которые она получила от вызывающей стороны. Вызывающая сторона должна подтвердить, что ответное сообщение содержит, по крайней мере, один ИнфЭл «Общий идентификатор». Это правило позволяет согласовать идентификатор. Детали процедуры согласования идентификатора в данном документе не рассматриваются.

4.1.2. Идентификатор IPv4-сессии

Если в поле «Идентификатор стандарта или прикладной системы» ИнфЭл «Общий идентификатор» содержится значение «IPv4», а поле «Тип идентификатора» этого же элемента содержится значение «Session», то идентификатором является идентификатор IPv4-сессии. На рис. 4.2 представлен формат идентификатора IPv4-сессии.

Поля IPv4-адреса отправителя и получателя, протокол транспортного уровня, номера портов отправителя и получателя составляют поле «Значение идентификатора» (рис. 4.1).

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

4.1.3. Идентификатор IPv6-сессии

Если в поле «Идентификатор стандарта или прикладной системы» ИнфЭл «Общий идентификатор» содержится значение «IPv6», а поле «Тип идентификатора» этого же элемента содержится значение «Session», то идентификатором является идентификатор IPv6-сессии. На рис. 4.3 представлен формат идентификатора IPv6-сессии.

Поля IPv6-адреса отправителя и получателя, протокол транспортного уровня, номера портов отправителя и получателя составляют поле «Значение идентификатора» (рис. 4.1).

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

4.1.4. Идентификатор виртуального MPLS-соединения

Если в поле «Идентификатор стандарта или прикладной системы» ИнфЭл «Общий идентификатор» содержится значение «MPLS», а поле «Тип идентификатора» этого же элемента содержится значение «Resource», то идентификатором является идентификатор виртуального MPLS-соединения. На рис. 4.4 представлен формат идентификатора виртуального MPLS-соединения.

Поле идентификатора виртуального MPLS-соединения составляет поле «Значение идентификатора» (рис. 4.1).

4.1.5. Идентификатор экспериментального или корпоративного применение

Если в поле «Идентификатор стандарта или прикладной системы» ИнфЭл «Общий идентификатор» содержится одно из следующих значений: «IPv4», «ST2+», «IPv6» или «MPLS», а поле «Тип идентификатора» этого же элемента содержится значение «Experiment/Organization», то идентификатором является идентификатор экспериментального или корпоративного применения. На рис. 4.5 представлен формат идентификатора экспериментального или корпоративного применения.

Первые 3 октета поля «Значение идентификатора» должны содержать уникальный идентификатор, устанавливаемый организацией (IEEE 802-1990).

4.2. Назначение в ИнфЭл «Пользователь-пользователь»

4.2.1. Использование сигнализации через интерфейс «Пользователь-пользователь»

Принцип назначения полей «Идентификатор протокола» и «Информация» в интересах IP-протокола в ИнфЭл «Пользователь-пользователь» представлен на рис. 4.6.

Поле «Определитель протокола» (Protocol discriminator) содержит значение «0х06» — протокол/приложение Internet-сети. В этом случае, первый октет поля «Информация пользователя» является полем «Идентификатор протокола/приложения Internet-сети».

В поле «Идентификатор протокола/приложения Internet-сети» может содержаться одно из следующих значений:

• «00000000» (0x00) — Зарезервировано.
• «00000001» (0x01) — Зарезервировано для стандарта ST2+.
• «00000010» (0x02) — Сообщение RSVP-протокола.
• «00000011 … 11111101» (0x03…0xFD) — Зарезервировано для IANA.
• «11111110» (0xFE) — Идентификатор экспериментального или корпоративного применения.
• «11111111» (0xFF) — Зарезервировано.

За полем «Идентификатор протокола/приложения Internet-сети» следует поле «Данные протокола/приложения Internet-сети».

Когда сообщение ШЦСИО-сигнализации, содержащее ИнфЭл «Пользователь-пользователь», поступает в ATM-сеть, которая такой идентификатор не поддерживает, тогда сеть «сбрасывает» вызов, уничтожает ИнфЭл или уничтожает всё сообщение (Q.2931, Q.2957 и Q.2971).

Для обеспечения надёжной доставки ИнфЭл «Пользователь-пользователь», когда вызывающая сторона передаёт сообщение «Setup» или «Add Party», содержащее ИнфЭл «Пользователь-пользователь», вызываемая сторона должна направить ответное сообщение «Connect» или «Add Party Ack», которое должно содержать ИнфЭл «Пользователь-пользователь». Вызываемая сторона может не включать в своё ответное сообщение те же самые данные пользователя, которые она получила от вызывающей стороны. Вызывающая сторона должна подтвердить, что ответное сообщение содержит ИнфЭл «Пользователь-пользователь». Это правило позволяет проводить процедуру согласования. Детали самой процедуры согласования в данном документе не рассматриваются.

4.2.2. Сообщение RSVP-протокола

Формат сообщения RSVP-протокола представлен на рис. 4.7.

Поле «Определитель протокола/приложения Internet-сети» (Internet protocol/application identifier) содержит значение «0х02» — сообщения RSVP-протокола. RSVP-сообщение размещается в поле «Данные протокола/приложения Internet-сети». Сообщение «Setup» может включать «Resv-сообщение» RSVP-протокола. Сообщение «Connect» может включать «ResvConf-сообщение» RSVP-протокола. Сообщение «Release» может включать «ResvErr-сообщение» или «ResvTear-сообщение» RSVP-протокола.

4.2.3. Идентификатор экспериментального или корпоративного применение

Формат сообщения для экспериментального или корпоративного применения в рамках ИнфЭл «Пользователь-пользователь» представлен на рис. 4.8.

5. Открытые вопросы

The following issues are still remain in this document.

• Generic Identifier support for session aggregation.

  Session aggregation support may be needed in a backbone environment. Wild card style aggregated session identifier may be feasible. However, before specifying Generic Identifier support for it, session aggregation model in ATM VCs should be clarified.

• Generic Identifier support for the IPv6 flow label and traffic classes.

  The IPv6 flow label and traffic classes support may be needed in future. However, currently their semantics are not clear.

6. Согласование с IANA

When the Identifier related standard/application field in the Q.2941.2 Generic Identifier information element is the IPv4, ST2+, IPv6, or MPLS, numbers between 0x10-0xFD in the Identifier type field are reserved for IANA assignment. (See section 3.1.) Following the policies outlined in [14], these numbers are allocated through an IETF Consensus action.

When the Protocol discriminator field in the Q.2957 User-user information element is the Internet protocol/application, numbers between 0x03-0xFD in the Internet protocol/application identifier field are reserved for IANA assignment. (See section 4.2.1.) Following the policies outlined in [14], these numbers are allocated through an IETF Consensus action.

7. Вопросы безопасности

Данный стандарт устанавливает правила применения информационного поля и идентификатора протокола, представленных в стандартах Q.2941 и Q.2957, в интересах IP-протокола, и поэтому не снижает уровень защищённости системы ШЦСИО-сигнализации.

Если на вызываемой стороне, в системе ШЦСИО-сигнализации, поступило сообщение «Setup», содержащее номер вызывающей стороны, и если оно было проверено и принято ATM-сетью или было обработано сетью, то оно приемлемо для использования в процедуре аутентификации вызывающей стороны, когда номер вызывающей стороны является составной частью аутентификационной информации, с целью повышения уровня защищённости.

Приложение A. Применение информационного поля и идентификатора протокола в интересах стандарта ST2+

Приложение A.1. Идентификатор сеанса связи ST2+

Если поле «Идентификатор стандарта или прикладной системы» ИнфЭл «Общий идентификатор» содержится значение «ST2+», а поле «Тип идентификатора» содержит значение «Session», то идентификатором является идентификатор сеанса связи ST2+. Формат сообщения «Идентификатор сеанса связи ST2+» представлен на рис. 4.9.

Приложение A.2. Протокол доставки управляющих сообщений для стандарта ST2+

Формат ИнфЭл «Пользователь-пользователь», используемого в интересах протокола доставки управляющих сообщений для стандарта ST2+ (Stream Control Message Protocol, SCMP) представлен на рис. 4.10.

Протокольные сообщения «Setup» и «Add Party» могут включать SCMP-сообщение «CONNECT». Протокольные сообщения «Connect» и «Add Party Ack» могут включать SCMP-сообщение «ACCEPT». Протокольные сообщения «Release» и «Drop Party» могут включать SCMP-сообщение «DISCONNECT». Протокольные сообщения «Release», «Release Complete», «Add Party Reject» и «Drop Party» могут включать SCMP-сообщение «REFUSE».

Ссылки

[1]	ITU-T, «Broadband Integrated Services Digital Network (B-ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control», ITU-T Recommendation Q.2931, Сентябрь 1995.
[2]	ITU-T, «Broadband Integrated Services Digital Network (B-ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface Layer 3 Specification for Point-to-Multipoint Call/Connection Control», ITU-T Recommendation Q.2971, October 1995.
[3]	ITU-T, «Broadband Integrated Services Digital Network (B-ISDN) Digital Subscriber Signaling System No. 2 (DSS 2): Generic Identifier Transport», ITU-T New Recommendation Q.2941.1, Сентябрь 1997.
[4]	ITU-T, «Broadband Integrated Services Digital Network (B-ISDN) Digital Subscriber Signaling System No. 2 (DSS 2): Generic Identifier Transport Extensions», ITU-T New Recommendation Q.2941.2, Декабрь 1999.
[5]	ITU-T, «Stage 3 Description for Additional Information Transfer Supplementary Service Using B-ISDN Digital Subscriber Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User Signalling (UUS)», ITU-T Recommendation Q.2957, Февраль 1995.
[6]	ITU-T, «Stage 3 Description for Additional Information Transfer Supplementary Service Using B-ISDN Digital Subscriber Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User Signalling (UUS)», ITU-T Recommendation Q.2957 Amendment 1, Декабрь 1999.
[7]	Postel, J., Ed., «Протокол IP (Internet Protocol)», STD 5, RFC 791, Сентябрь 1981.
[8]	Deering, S. и R. Hinden, «Спецификация протокола IPv6», RFC 2460, Декабрь 1998.
[9]	Postel, J., «Протокол датаграмм клиента (UDP)», STD 6, RFC 768, Август 1980.
[10]	Postel, J., Ed., «Протокол управления передачей (TCP)», STD 7, RFC 793, Сентябрь 1981.
[11]	Delgrossi, L. и L. Berger, Ed., «Internet Stream Protocol Version 2 (ST2) Protocol Specification — Version ST2+», RFC 1819, Август 1995.
[12]	Braden, R., Ed., «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, Сентябрь 1997.
[13]	Nagami, K., Demizu, N., Esaki, H., Katsube, Y. и P. Doolan, «VCID Notification over ATM link for LDP», RFC 3038, Январь 2001.
[14]	Narten, T., and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.
[15]	P. Newman, T. Lyon, and G. Minshall, «Flow Labelled IP: A Connectionless Approach to ATM», Proc. IEEE Infocom, Март 1996.
[16]	S. Damaskos and A. Gavras, «Connection Oriented Protocols over ATM: A case study», Proc. SPIE, Vol. 2188, pp.226-278, Февраль 1994.
[17]	ITU-T, «Integrated Services Digital Network (ISDN) Overall Network Aspects and Functions ISDN Protocol Reference Model», ITU-T Recommendation I.320, Ноябрь 1993.
[18]	ITU-T, «Digital Subscriber Signaling System No. 1 (DSS 1) Specification of a Synchronization and Coordination Function for the Provision of the OSI Connection-mode Network Service in an ISDN Environment», ITU-T Recommendation Q.923, Февраль 1995.

Благодарности

I would like to thank Kenichi Kitami of the NTT Information Sharing Lab. Group, who is also the chair of ITU-T SG11 WP1, Shinichi Kuribayashi of the NTT Information Sharing Platform Labs., Hiroshi Yao and Takumi Ohba of the NTT Network Service Systems Labs., and Noriyuki Takahashi of the NTT Information Sharing Platform Labs., for their valuable comments and discussions.

And I would also like to thank the active members of IETF, ITU-T, and ATM Forum, especially Joel Halpern of Newbridge Networks, Andrew Malis of Ascend Communications, George Swallow and Bruce Davie of Cisco Systems, Rao Cherukuri of IBM, Rajiv Kapoor of AT&T;, Greg Ratta of Lucent, Kaoru Kenyoshi of NEC, Hiroto Uno of Hitachi, Hiroshi Esaki and Kenichi Nagami of Toshiba, and Noritoshi Demizu of NAIST for their valuable comments and suggestions.

Also, this specification is based on various discussions during the ST2+ over ATM project at the NTT Multimedia Joint Project with NACSIS. I would like to thank Professor Shoichiro Asano of the National Center for Science Information Systems for his invaluable advice in this area.