Интегрированные сети ISDN
Протокол
2. Протокол
2.1. Общий заголовок
Далее рассматриваются форматы сообщений и объекты, которыми обмениваются PEP и удаленный PDP. Каждое сообщение COPS состоит из заголовка, за которым следует некоторое число типизованных объектов.
| 0 | 1 | 2 | 3 |
| Версия | Флаги | Код операции | Тип клиента |
| Длина сообщения |
//// далее обозначает зарезервированное поле и должно содержать 0.
В заголовке имеются поля:
| Версия: 4 бита | Номер версии COPS. Текущее значение версии 1. |
| Флаги: 4 бита | Определенные значения флага (все другие флаги должны быть установлены в нулевое состояние): 0x1 Solicited Message Flag Bit. Этот флаг устанавливается, когда поступает запрос COPS. Этот флаг не должен устанавливаться (значение=0), если только не специфицировано обратное в разделе 3 |
Ниже в таблице представлены значения поля код операции.
| Код операции (8 бит) |
Функция | Название операции |
| 1 | Запрос | REQ |
| 2 | Решение | DEC |
| 3 | Отчет о состоянии | RPT |
| 4 | Стереть состояние запроса | DRQ |
| 5 | Синхронизовать состояние запроса> | SSQ |
| 6 | Client-Open | OPN |
| 7 | Client-Accept | CAT |
| 8 | Client-Close | CC |
| 9 | Keep-Alive | KA |
| 10 | Завершить синхронизацию | SSC |
Поле Тип клиента: 16 бит
Тип клиента идентифицирует клиента политики. Интерпретация всех инкапсулированных объектов Типы клиента, которые устанавливают старший бит в поле тип клиента, зависят от производителя (enterprise specific; это типы клиентов 0x8000 - 0xFFFF). Для сообщений KA тип клиента в заголовке должен быть установлен равным 0, так как KA используется для проверки связи.
Длина сообщения: 32 бит
Размер сообщения в октетах, который включает в себя стандартный заголовок COPS и все инкапсулированные объекты. Сообщения должны иметь длину кратную 4 октетам.
2.2. Форматы специфических объектов COPS
Все объекты имеют один и тот же формат; каждый объект состоит из одного или более 32-битных слов с 4-октетным заголовком. Формат показан на рисунке:
| 0 | 1 | 2 | 3 |
| Длина (октеты) | C-Num | C-Type | |
| (Содержимое объекта) |
Длина характеризуется двухоктетной величиной, которая описывает число октетов (включая заголовок), которые образуют объект.
Если длина в октетах не попадает на границу слова, кратную 32-бит, должно использоваться заполнение вплоть до конца объекта, так чтобы обеспечивать выравнивание, прежде чем объект будет послан. На принимающей стороне соответствующая граница объекта определяется округлением объявленной ранее длины объекта до значения кратного ближайшим 32-бит.
Обычно, C-Num идентифицирует класс информации в объекте, а C-тип идентифицирует субтип или версию информации, содержащейся в объекте.
C-num: 8 бит
| 1 | Дескриптор (Handle) |
| 2 | Контекст |
| 3 | Входной интерфейс |
| 4 | Выходной интерфейс |
| 5 | Код причины |
| 6 | Решение |
| 7 | LPDP решение |
| 8 | Ошибка |
| 9 | Специфические данные клиента |
| 10 | Таймер Keep-Alive |
| 11 | Идентификация PEP |
| 12 | Тип отчета |
| 13 | Адрес переадресации PDP |
| 14 | Последний PDP-адрес |
| 15 | Таймер аккоунтинга |
| 16 | Целостность сообщения |
2.2.1. Объект дескриптор (Handle)
Объект Handle (дескриптор) содержит уникальную величину, которая идентифицирует инсталлированное состояние. Эта идентификация используется большинством операций COPS. Состояние, соответствующее дескриптору, должно быть непосредственно удалено, когда оно более не применимо.
C-Num = 1
C-Type = 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
| 0 | 1 | 2 | 3 |
| R-Type | M-Type |
| 0x01 | Запрос входящего сообщения/Управления доступом (Incoming-Message/Admission Control) |
| 0x02 | Запрос выделения ресурсов |
| 0x04 | Запрос исходящего сообщения |
| 0x08 | Запрос конфигурации |
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
C-Type = 1, IPv4-адрес + Интерфейс
| 0 | 1 | 2 | 3 |
| IPv4 Address format | |||
| ifindex |
C-Type = 2, IPv6-адрес + Интерфейс
| 0 | 1 | 2 | 3 |
|
IPv6 Address format |
|||
| ifindex |
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-Type = 1, IPv4-адрес + интерфейс
Некоторые форматы 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
| 0 | 1 | 2 | 3 |
| Reason-Code | Reason Sub-code |
| Код причины | |
| 1 | Не специфицировано |
| 2 | Управление |
| 3 | Preempted (Другое состояние запроса получает предпочтение) |
| 4 | Tear (Используется для сообщения об удалении указанного состояния) |
| 5 | Таймаут (время локального состояния истекло) |
| 6 | Route Change (Изменение делает некорректным состояние запроса) |
| 7 | Недостаточные ресурсы (локальные ресурсы исчерпаны) |
| 8 | Директива PDP (решение PDP вызвало аннулирование) |
| 9 | Неподдерживаемое решение (решение PDP не поддерживается) |
| 10 | Synchronize Handle Unknown (дескриптор не известен) |
| 11 | Промежуточный дескриптор (stateless event) |
| 12 | Malformed Decision (восстановление не возможно) |
| 13 | Неизвестный объект COPS от PDP: Субкод (октет 2) содержит неизвестный C-Num объекта (октет 3) содержит неизвестный C-тип объекта |
2.2.6. Объект Decision
Решение, принятое PDP. Присутствует в откликах. Специфические необязательные объекты решения необходимы в решениях для определенных запросов в зависимости от типа клиента.
C-Num = 6
C-тип = 1, флаги решения (обязательные)
| 0 | 1 | 2 | 3 |
| Код команды | Флаги |
0 = Решение NULL (Конфигурационные данные недоступны)
1 = Инсталлировать (Admit request/Install configuration)
2 = Удалить (запрос/конфигурацию)
Флаги:
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
| 0 | 1 | 2 | 3 |
| Код ошибки | Субкод ошибки |
| Код ошибки | Причина |
| 1 | Плохой дескриптор |
| 2 | Неверный указатель ссылки (Invalid handle reference) |
| 3 | Плохой формат сообщения (Malformed Message) |
| 4 | Невозможна обработка (сервер не может обслужить запрос) |
| 5 | Отсутствует обязательная информация, специфическая для клиента |
| 6 | Неподдерживаемый тип клиента |
| 7 | Отсутствует обязательный объект COPS |
| 8 | Отказ клиента |
| 9 | Коммуникационный отказ (Communication Failure) |
| 10 | Не специфицировано |
| 11 | Закрытие сессии |
| 12 | Переадресация на предпочтительный сервер |
| 13 |
Неизвестный объект COPS: Субкод (октет 2) содержит C-Num и C-Type (октет 3) неизвестного объекта. |
| 14 | Неуспех аутентификации |
| 15 | Необходима аутентификация |
2.2.9. Объект специфической информации клиента (ClientSI)
Для запросов необходимы различные типы этого объекта, он используется в откликах и, когда необходимо, в процедурах open. Объект содержит специфическую информацию для клиента данного типа.
C-Num = 9,
C-Type = 1, Signaled ClientSI.
Поле переменной длины. Все объекты/атрибуты, специфичные для сигнального протокола клиента или внутреннего состояния, инкапсулируются в один или более информационных объектов, специфических для клиента. Формат данных, инкапсулированных в объект ClientSI, определяется типом клиента.
C-Type = 2, Именованный ClientSI.
Поле переменной длины. Содержит именованную конфигурационную информацию, полезную для передачи специфических данных о PEP, запросе, или сконфигурированном состоянии серверу PDP.
2.2.10. Объект Keep-Alive-таймер (KATimer)
Значение времени кодируются в виде 2-октетных целых чисел и измеряются в секундах. Время выдержки таймера рассматривается как приращение.
C-Num = 10,
C-Type = 1, значение таймера Keep-alive
Объект таймер используется для спецификации максимального временного интервала, в течение которого сообщение COPS должно быть послано или получено. Диапазон значений таймаутов лежит в пределах 1 - 65535 секунд. Значение нуль соответствует бесконечности.
| 0 | 1 | 2 | 3 |
| ////////////// | Значение таймера KA |
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
| 0 | 1 | 2 | 3 |
| Report-Type | ///////////// |
1 = Success : Решение было успешным для PEP
2 = Failure : Решение не могло быть реализовано PEP
3 = Accounting: Актуализация аккоунтинга для инсталлированного состояния.
2.2.13. Адрес пересылки PDP (PDPRedirAddr)
PDP при закрытии PEP-сессии для конкретного типа клиента может опционно использовать этот объект для того чтобы переадресовать PEP на специфицированный адрес сервера и заданный порт TCP:
C-Num = 13,
C-Type = 1, IPv4-адрес+ TCP порт
| 0 | 1 | 2 | 3 |
| Формат IPv4-адреса | |||
| ///////////////////////// | TCP Port Number |
| 0 | 1 | 2 | 3 |
|
Формат IPv6-адреса |
/p>
2.2.14. Последний адрес PDP (LastPDPAddr)
Когда PEP имеет определенный тип клиента, он должен специфицировать последний PDP, который он успешно открыл (им получено сообщение Client-Accept) со времени, когда PEP последний раз перезагружался. Если со времени последней загрузки не использовалось никакого PDP, PEP просто не включит этот объект в сообщение Client-Open.
C-Num = 14,
C-Type = 1, IPv4-адрес (тот же формат, что и для PDPRedirAddr)
C-Type = 2, IPv6-адрес (имеет тот же формат, что и PDPRedirAddr)
2.2.15. Объект Accounting-таймер (AcctTimer)
Время кодируется в виде двухоктетых целых чисел и измеряется в секундах. Значение таймера рассматривается как временной интервал между двумя событиями.
C-Num = 15,
C-Type = 1, Значение таймера аккоунтинга
Значение опционного таймера используется для определения минимального интервала между периодическими отчетами о типах аккоунтинга. Оно используется PDP для того чтобы охарактеризовать PEP приемлемое значение интервала между не запрошенными аккоунтинг-актуализациями через сообщения-отчеты, когда это применимо. Он обеспечивает для PDP метод управления объемом аккоунтинг-трафика в сети. Диапазон конечных значений времени лежит в пределах 1 - 65535 секунд (два октета). Значение нуль означает, что не должно быть не запрошенных аккоунтинг-актуализаций.
| 0 | 1 | 2 | 3 |
| ////////////// | ACCT Timer Value |
2.2.16. Объект целостность сообщения (Message Integrity)
Объект целостности (integrity) включает в себя порядковый номер и дайджест сообщения, полезный для аутентификации и проверки целостности сообщения COPS. Когда используется этот объект, он размещается в самом конце сообщения COPS. Дайджест вычисляется для всего сообщения COPS за исключением самого дайджеста. Отправитель сообщения COPS вычисляет и заполняет дайджест-секцию объекта Integrity. Получатель сообщения вычисляет дайджест для этого сообщения и сравнивает его с тем, что хранится в объекте Integrity.
C-Num = 16,
C-Type = 1, HMAC дайджест
Объект 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 бит.
| 0 | 1 | 2 | 3 |
| Key ID | |||
| Sequence Number | |||
|
...Keyed Message Digest... |
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 поддерживают разные типы клиентов (как это показано на Рисунок ).
