Единственная особенность в монтаже двух подрозетников – строгое выравнивание их по уровню (особенное внимание нужно обратить при фиксации гипсом). Чем больше подрозетников в ряду, тем труднее их выставить идеально.

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

RFC 6733 — базовый протокол диаметра

Инженерная группа Интернета (IETF) В. Фахардо, Под ред.
Запрос комментариев: 6733 Telcordia Technologies
Устаревшие: 3588, 5719 J.Аркко
Категория: Отслеживание стандартов Ericsson Research
ISSN: 2070-1721 Дж. Лоуни
                                                   Исследовательский центр Nokia
                                                            G. Zorn, Ed.
                                                             Сеть Дзен
                                                            Октябрь 2012 г.


                         Базовый протокол диаметра

Аннотация

   Базовый протокол Diameter предназначен для аутентификации,
   Структура авторизации и учета (AAA) для таких приложений
   как доступ к сети или мобильность IP как в локальном, так и в роуминге
   ситуации.Этот документ определяет формат сообщения, транспорт,
   отчеты об ошибках, бухгалтерский учет и службы безопасности, используемые всеми
   Применения диаметра. Базовый протокол Diameter, как определено в этом
   документ устарел RFC 3588 и RFC 5719, и он должен поддерживаться
   все новые реализации Diameter.

Статус этой памятки

   Это документ Internet Standards Track.

   Этот документ является продуктом Инженерной группы Интернета.
   (IETF). Он представляет собой консенсус сообщества IETF.Оно имеет
   получил публичное рецензирование и был одобрен к публикации
   Инженерная группа управления Интернетом (IESG). Дополнительная информация о
   Интернет-стандарты доступны в разделе 2 RFC 5741.

   Информация о текущем статусе этого документа, исправлениях,
   а как оставить отзыв о нем можно узнать на
   http://www.rfc-editor.org/info/rfc6733.














Фахардо и др. Стандарты Track [Страница 1] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


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

   Авторские права (c) 2012 IETF Trust и лица, указанные как
   авторы документа.Все права защищены.

   Этот документ регулируется BCP 78 и Правовой нормой IETF Trust.
   Положения, касающиеся документов IETF
   (http://trustee.ietf.org/license-info) действует на дату
   публикация этого документа. Просмотрите эти документы
   внимательно, поскольку они уважительно описывают ваши права и ограничения
   к этому документу. Компоненты кода, извлеченные из этого документа, должны
   включить упрощенный текст лицензии BSD, как описано в разделе 4.e
   Правовые положения Trust и предоставляются без гарантии, как
   описана в упрощенной лицензии BSD.Этот документ может содержать материалы из документов IETF или IETF.
   Материалы опубликованы или станут общедоступными до ноября
   10, 2008. Лица, контролирующие авторские права на некоторые из этих
   материал, возможно, не давал IETF Trust право разрешать
   модификации такого материала вне Процесса стандартизации IETF.
   Без получения соответствующей лицензии от лица (лиц), контролирующего
   авторские права на такие материалы, этот документ не может быть изменен
   вне Процесса стандартизации IETF, и производные от него разработки могут
   не создаваться вне процесса стандартов IETF, кроме как для форматирования
   его для публикации как RFC или для перевода на другие языки
   чем английский.Содержание

   1. Введение ............................................... ..... 7
      1.1. Протокол диаметра .......................................... 9
           1.1.1. Описание комплекта документов .................... 10
           1.1.2. Условные обозначения, используемые в этом документе .................. 11
           1.1.3. Отличия от RFC 3588 .............................. 11
      1.2. Терминология ............................................... 12
      1.3. Подход к расширяемости ................................. 17
           1.3.1. Определение новых значений AVP ........................... 18
           1.3.2. Создание новых AVP .................................. 18
           1.3.3. Создание новых команд .............................. 18
           1.3.4. Создание новых приложений диаметра ................. 19
   2. Обзор протокола .............................................. 20
      2.1. Транспорт ................................................. 22
           2.1.1. Рекомендации по SCTP.................................... 23
      2.2. Защита сообщений о диаметре ................................ 24
      2.3. Соответствие диаметру приложения ........................... 24
      2.4. Идентификаторы приложений ................................... 24
      2.5. Соединения и сеансы .................................. 25
      2.6. Таблица пиров ................................................ 26



Фахардо и др. Стандарты Track [Страница 2] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


      2.7. Таблица маршрутизации ............................................. 27
      2.8. Роль агентов диаметра ................................... 28
           2.8.1. Релейные агенты ....................................... 30
           2.8.2. Прокси-агенты ....................................... 31
           2.8.3. Агенты перенаправления .................................... 31
           2.8.4. Бюро переводов ................................. 32
      2.9. Разрешение на диаметр пути ............................... 33
   3.Диаметр заголовка ................................................ 34
      3.1. Коды команд ............................................. 37
      3.2. Спецификация формата кода команды ......................... 38
      3.3. Соглашения об именах команд Diameter ....................... 40
   4. Диаметр AVP .............................................. .... 40
      4.1. Заголовок AVP ................................................ 41 год
           4.1.1. Дополнительные элементы заголовка ...........................42
      4.2. Базовые форматы данных AVP .................................... 43
      4.3. Производные форматы данных AVP .................................. 44
           4.3.1. Общие производные форматы данных AVP .................. 44
      4.4. Сгруппированные значения AVP ........................................ 51
           4.4.1. Пример AVP с сгруппированным типом данных ............... 52
      4.5. AVP для базового протокола диаметра ............................... 55
   5. Пары диаметра ................................................. 58
      5.1. Одноранговые соединения .......................................... 58
      5.2. Обнаружение однорангового узла Diameter ................................... 59
      5.3. Обмен возможностями ..................................... 60
           5.3.1. Возможности-Обмен-Запрос ..................... 62
           5.3.2. Возможности-Обмен-Ответ ....................... 63
           5.3.3. Vendor-Id AVP ...................................... 63
           5.3.4. Прошивка-Ревизия AVP .............................. 64
           5.3.5. Host-IP-Address AVP ................................ 64
           5.3.6. Поддерживаемый идентификатор поставщика AVP ............................ 64
           5.3.7. Название продукта AVP ................................... 64
      5.4. Отключение одноранговых соединений ............................ 64
           5.4.1. Disconnect-Peer-Request ............................ 65
           5.4.2. Disconnect-Peer-Answer ............................. 65
           5.4.3. Отключение-причина AVP............................... 66
      5.5. Обнаружение сбоев транспорта ............................... 66
           5.5.1. Device-Watchdog-Request ............................ 67
           5.5.2. Ответ устройства-сторожевого пса ............................. 67
           5.5.3. Алгоритм отказа транспорта ........................ 67
           5.5.4. Процедуры аварийного переключения и восстановления после сбоя ................... 67
      5.6. Конечный автомат узла ........................................ 68
           5.6.1. Входящие соединения............................... 71
           5.6.2. События ............................................. 71
           5.6.3. Действия ............................................ 72
           5.6.4. Избирательный процесс ............................... 74






Фахардо и др. Стандарты Track [Страница 3] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   6. Обработка сообщения Diameter .................................... 74
      6.1. Обзор маршрутизации запроса диаметра ......................... 74
           6.1.1. Отправка запроса .............................. 75
           6.1.2. Отправка запроса .................................. 76
           6.1.3. Прием запросов ................................. 76
           6.1.4. Обработка локальных запросов .......................... 76
           6.1.5. Пересылка запросов ................................. 77
           6.1.6. Маршрутизация запросов .................................... 77
           6.1.7. Предиктивное предотвращение петель .......................... 77
           6.1.8. Перенаправление запросов ............................... 78
           6.1.9. Ретрансляция и проксирование запросов ..................... 79
      6.2. Диаметр обработки ответа ................................ 80
           6.2.1. Обработка полученных ответов ........................ 81
           6.2.2. Ретрансляция и проксирование ответов ...................... 81
      6.3. Исходный хост AVP ........................................... 81
      6.4. Origin-Realm AVP .......................................... 82
      6.5. AVP назначения-хоста ...................................... 82
      6.6. Целевая область AVP ..................................... 82
      6.7. Маршрутизация AVP .............................................. 83
           6.7.1. Маршрут-запись AVP ................................... 83
           6.7.2. Прокси-информация AVP ..................................... 83
           6.7.3. Прокси-хост AVP ..................................... 83
           6.7.4. Прокси-состояние AVP .................................... 83
      6.8. Auth-Application-Id AVP ................................... 83
      6.9. Acct-Application-Id AVP ................................... 84
      6.10. Внутренний идентификатор безопасности AVP ................................... 84
      6.11. Идентификатор приложения, зависящий от поставщика ....................... 84
      6.12. Перенаправление хоста AVP ........................................ 85
      6.13. Перенаправление-хост-использование AVP .................................. 85
      6.14. Перенаправление-максимальное время кеширования AVP .............................. 87
   7. Обработка ошибок .............................................. ... 87
      7.1. Код результата AVP ........................................... 89
           7.1.1. Информационная ...................................... 90
           7.1.2. Успех ............................................ 90
           7.1.3. Ошибки протокола .................................... 90
           7.1.4. Переходные отказы ................................. 92
           7.1.5. Постоянные отказы ................................. 92
      7.2. Бит ошибки ................................................ 0,95
      7.3. Сообщение об ошибке AVP ......................................... 96
      7.4. AVP с отчетами об ошибках .................................. 96
      7.5. Failed-AVP AVP ............................................ 96
      7.6. AVP экспериментального результата ................................... 97
      7.7. AVP с кодом результата эксперимента .............................. 97
   8.Сессии пользователей Diameter ......................................... 98
      8.1. Конечный автомат сеанса авторизации ....................... 99
      8.2. Конечный автомат бухгалтерской сессии ......................... 104





Фахардо и др. Стандарты Track [Страница 4] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


      8.3. Повторная аутентификация, инициированная сервером ................................. 110
           8.3.1. Re-Auth-Request ................................... 110
           8.3.2. Повторная авторизация-ответ .................................... 110
      8.4. Завершение сеанса ...................................... 111
           8.4.1. Запрос на завершение сеанса ....................... 112
           8.4.2. Сессия-Завершение-Ответ ........................ 113
      8.5. Прерывание сеанса ....................................... 113
           8.5.1. Запрос на прерывание сеанса ............................. 114
           8.5.2. Прервать-Сессию-Ответ.............................. 114
      8.6. Вывод о завершении сеанса по идентификатору государства-источника ....... 115
      8.7. AVP Auth-Request-Type .................................... 116
      8.8. Идентификатор сеанса AVP ........................................... 116
      8.9. Авторизация-пожизненная AVP ............................... 117
      8.10. Авторизация-льготный период AVP ................................... 118
      8.11. Авторизация-состояние сеанса AVP .................................. 118
      8.12. AVP типа Re-Auth-Request-Type................................ 118
      8.13. AVP тайм-аута сеанса ..................................... 119
      8.14. Имя пользователя AVP ........................................... 119
      8.15. Прерывание-причина AVP ................................... 120
      8.16. Идентификатор состояния источника AVP ..................................... 120
      8.17. AVP с привязкой к сеансу ..................................... 120
      8.18. Сеанс-сервер-отказоустойчивый AVP ............................. 121
      8.19. AVP с несколькими раундами и тайм-аутом................................ 122
      8.20. Класс АВП ............................................... 122
      8.21. Временная метка события AVP ..................................... 122
   9. Бухгалтерский учет ............................................... ..... 123
      9.1. Модель, ориентированная на сервер .................................... 123
      9.2. Сообщения протокола ........................................ 124
      9.3. Расширение бухгалтерского приложения и требования ........ 124
      9.4. Устойчивость к сбоям......................................... 125
      9.5. Бухгалтерские записи ....................................... 125
      9.6. Корреляция бухгалтерских записей ........................ 126
      9.7. Коды команд учета ................................. 127
           9.7.1. Бухгалтерия-Запрос ................................ 127
           9.7.2. Бухгалтерия-Ответ ................................. 128
      9.8. Бухгалтерские AVP .......................................... 129
           9.8.1. Учетная запись типа AVP........................ 129
           9.8.2. Acct-Interim-Interval AVP ......................... 130
           9.8.3. Номер бухгалтерской записи AVP ..................... 131
           9.8.4. Acct-Session-Id AVP ............................... 131
           9.8.5. Acct-Multi-Session-Id AVP ......................... 131
           9.8.6. Учет-идентификатор подсессии AVP ..................... 131
           9.8.7. AVP, требующий учета в реальном времени .................. 132
   10. Таблицы встречаемости AVP ........................................ 132
      10.1. Таблица AVP команд основного протокола ......................... 133
      10.2. Учетная таблица AVP .................................... 134





Фахардо и др. Стандарты Track [Страница 5] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   11. Соображения по поводу IANA .......................................... 135
      11.1. Заголовок AVP ..............................................135
           11.1.1. Коды AVP ........................................ 136
           11.1.2. Флаги AVP ........................................ 136
      11.2. Диаметр заголовка ......................................... 136
           11.2.1. Коды команд .................................... 136
           11.2.2. Флаги команд .................................... 137
      11.3. Значения AVP .............................................. 137
           11.3.1. Код экспериментального результата AVP ..................... 137
           11.3.2. Значения AVP кода результата ........................... 137
           11.3.3. Значения AVP типа бухгалтерской записи ................ 137
           11.3.4. Значения AVP причины прекращения ..................... 137
           11.3.5. Значения AVP Redirect-Host-Usage ................. 137
           11.3.6. Значения AVP сеанса-сервера-аварийного переключения ............... 137
           11.3.7. Значения AVP, привязанные к сеансу ....................... 137
           11.3.8. Значения AVP причины отключения ...................... 138
           11.3.9. Значения AVP типа запроса аутентификации ..................... 138
           11.3.10. Значения AVP Auth-Session-State ................... 138
           11.3.11. Значения AVP типа Re-Auth-Request ................. 138
           11.3.12. Значения AVP, требуемые для учета в реальном времени ......... 138
           11.3.13. Внутренний идентификатор безопасности AVP (код 299) ............... 138
      11.4. _diameters Регистрация имени службы и номера порта .... 138
      11.5. Идентификаторы протокола полезной нагрузки SCTP....................... 139
      11.6. Параметры S-NAPTR ..................................... 139
   12. Конфигурируемые параметры, связанные с протоколом диаметра ............ 139
   13. Соображения безопасности ..................................... 140
      13.1. Использование TLS / TCP и DTLS / SCTP ............................. 140
      13.2. Рекомендации по одноранговой сети ............................. 141
      13.3. Рекомендации по AVP ...................................... 141
   14. Список литературы ................................................... 142
      14.1. Нормативные ссылки .................................... 142
      14.2. Информационные ссылки .................................. 144
   Приложение A. Благодарности ..................................... 147
     А.1. Этот документ ............................................. 147
     А.2. RFC 3588 ................................................ ..148
   Приложение B. Пример S-NAPTR ...................................... 148
   Приложение C. Обнаружение дубликатов.................................. 149
   Приложение D. Интернационализированные доменные имена ....................... 151













Фахардо и др. Стандарты Track [Страница 6] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


1. Введение

   Протоколы аутентификации, авторизации и учета (AAA), такие как
   TACACS [RFC1492] и RADIUS [RFC2865] изначально были развернуты в
   обеспечить коммутируемый PPP [RFC1661] и доступ к серверу терминалов.Через некоторое время,
   Поддержка AAA была необходима для многих новых технологий доступа, масштабов и
   сложность сетей AAA выросла, и AAA также использовался на новых
   приложения (например, передача голоса по IP). Это привело к новым требованиям к AAA.
   протоколы.

   Требования к сетевому доступу для протоколов AAA кратко изложены в
   Абоба и др. [RFC2989]. Они включают:

   Отказоустойчивый

      [RFC2865] не определяет механизмы аварийного переключения и, как следствие,
      Поведение при отказе зависит от реализации. Для того, чтобы
      обеспечивают четко определенное поведение при отказе, поддерживает Diameter
      подтверждения на уровне приложений и определяет алгоритмы аварийного переключения
      и связанный с ним конечный автомат.Безопасность на уровне передачи

      RADIUS [RFC2865] определяет аутентификацию на уровне приложений и
      схема целостности, которая требуется только для использования с ответом
      пакеты. Хотя [RFC2869] определяет дополнительную аутентификацию и
      механизм целостности, использование требуется только во время Extensible
      Сеансы протокола аутентификации (EAP) [RFC3748]. Пока атрибут
      поддерживается скрытие, [RFC2865] не обеспечивает поддержку для отдельных
      конфиденциальность пакетов. В бухгалтерском учете [RFC2866] предполагает, что
      защита от воспроизведения обеспечивается внутренним сервером биллинга, а не
      чем в самом протоколе.Хотя [RFC3162] определяет использование IPsec с RADIUS, поддержка
      IPsec не требуется. Чтобы обеспечить универсальную поддержку
      безопасность на уровне передачи и позволяет как внутри-, так и между
      развертываний AAA в домене, Diameter обеспечивает поддержку TLS / TCP и
      DTLS / SCTP. Безопасность обсуждается в разделе 13.

   Надежный транспорт

      RADIUS работает через UDP и не определяет поведение повторной передачи;
      в результате надежность зависит от реализации.В качестве
      описанный в [RFC2975], это серьезная проблема в бухгалтерском учете, где
      потеря пакетов может привести непосредственно к потере дохода. Для того, чтобы






Фахардо и др. Стандарты Track [Страница 7] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


      обеспечить четко определенное транспортное поведение, диаметр превышает
      надежные транспортные механизмы (TCP, Stream Control Transmission
      Протокол (SCTP)), как определено в [RFC3539].Агентская поддержка

      RADIUS не предоставляет явной поддержки агентов, включая
      прокси, перенаправления и ретрансляторы. Поскольку ожидаемое поведение
      не определено, это зависит от реализации. Диаметр определяет
      поведение агента явно; это описано в Разделе 2.8.

   Сообщения, инициированные сервером

      Хотя инициируемые сервером сообщения определены в RADIUS [RFC5176],
      поддержка не обязательна. Это затрудняет реализацию
      такие функции, как незапрошенное отключение или повторная аутентификация /
      повторная авторизация по запросу в гетерогенном развертывании.Чтобы
      решить эту проблему, поддержка сообщений, инициированных сервером
      обязательно в диаметре.

   Переходная поддержка

      В то время как Diameter не использует общий блок данных протокола (PDU)
      с RADIUS были приложены значительные усилия для обеспечения
      обратная совместимость с RADIUS, так что два протокола могут
      быть развернутыми в той же сети. Первоначально ожидается, что
      Диаметр будет развернут в новых сетевых устройствах, а также
      внутри шлюзов, обеспечивающих связь между устаревшими RADIUS
      устройств и агентов Diameter.Эта возможность позволяет использовать диаметр
      поддержка будет добавлена ​​в унаследованные сети путем добавления шлюза
      или сервер, говорящий как на RADIUS, так и на Diameter.

   Помимо выполнения вышеуказанных требований, Diameter также
   обеспечивает поддержку для следующего:

   Возможности переговоров

      RADIUS не поддерживает сообщения об ошибках, согласование возможностей или
      обязательный / необязательный флаг для атрибутов. С RADIUS
      клиенты и серверы не осведомлены о возможностях друг друга,
      они не смогут успешно вести переговоры о взаимных
      приемлемый сервис или, в некоторых случаях, даже знать, что
      услуга реализована.Диаметр включает поддержку ошибок
      обработка (раздел 7), согласование возможностей (раздел 5.3) и
      обязательные / необязательные пары атрибут-значение (AVP)
      (Раздел 4.1).





Фахардо и др. Стандарты Track [Страница 8] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   Обнаружение и настройка пира

      Реализации RADIUS обычно требуют, чтобы имя или адрес
      серверов или клиентов можно настроить вручную, а также
      соответствующие общие секреты.Это приводит к большому
      административное бремя и создает соблазн повторно использовать
      Общий секрет RADIUS, что может привести к серьезной безопасности
      уязвимости, если Request Authenticator не глобально и
      временный уникальный, как требуется в [RFC2865]. Через DNS, Диаметр
      включает динамическое обнаружение пиров (см. раздел 5.2). Вывод
      динамических ключей сеанса включается через уровень передачи
      безопасность.

   Со временем возможности устройств сервера доступа к сети (NAS)
   существенно увеличились.В результате, пока диаметр
   значительно более сложный протокол, чем RADIUS, он остается
   возможно реализовать во встроенных устройствах.

1.1. Протокол диаметра

   Базовый протокол Diameter предоставляет следующие возможности:

   o Возможность обмениваться сообщениями и доставлять AVP

   o Обсуждение возможностей

   o Уведомление об ошибке

   o Расширяемость, требуемая в [RFC2989], за счет добавления новых
      приложения, команды и AVP

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

   Все данные, доставляемые протоколом, представлены в виде AVP.Некоторые из
   эти значения AVP используются самим протоколом Diameter, а
   другие предоставляют данные, связанные с конкретными приложениями, которые
   используйте Диаметр. AVP могут быть произвольно добавлены в сообщения Diameter,
   единственное ограничение состоит в том, что формат кода команды (CCF)
   спецификации (раздел 3.2). AVP используются базой
   Протокол Diameter для поддержки следующих необходимых функций:

   o Транспортировка аутентификационной информации пользователя для целей
      включения Diameter-сервера для аутентификации пользователя

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



Фахардо и др.Стандарты Track [Страница 9] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   o Обмен информацией об использовании ресурсов, которая может быть использована для
      бухгалтерские цели, планирование мощностей и т. д.

   o Маршрутизация, ретрансляция, проксирование и перенаправление сообщений Diameter
      через иерархию серверов

   Базовый протокол Diameter удовлетворяет минимальным требованиям для
   Протокол AAA, как указано в [RFC2989]. Базовый протокол может быть
   используется сам по себе только для целей бухгалтерского учета, или он может использоваться с
   Приложение Diameter, например Mobile IPv4 [RFC4004] или сеть
   доступ [RFC4005].Также возможно, что базовый протокол будет
   расширен для использования в новых приложениях за счет добавления новых
   команды или AVP. Первоначально в центре внимания Diameter был доступ к сети.
   и бухгалтерские приложения. Действительно универсальный протокол AAA, используемый
   многие приложения могут предоставлять функции, не предусмотренные
   Диаметр. Поэтому совершенно необходимо, чтобы дизайнеры новых
   приложения понимают свои требования перед использованием Diameter.
   См. Раздел 1.3.4 для получения дополнительной информации о приложениях Diameter.Любой узел может инициировать запрос. В этом смысле Diameter является равноправным
   одноранговый протокол. В этом документе Diameter-клиент - это устройство на
   край сети, который выполняет контроль доступа, например
   Сервер доступа к сети (NAS) или внешний агент (FA). Диаметр
   клиент генерирует сообщения Diameter для запроса аутентификации,
   авторизация и бухгалтерские услуги для пользователя. Диаметр
   агент - это узел, который не обеспечивает аутентификацию локального пользователя или
   услуги авторизации; агенты включают прокси, перенаправления и ретрансляцию
   агенты.Сервер Diameter выполняет аутентификацию и / или
   авторизация пользователя. Узел Diameter может действовать как агент для
   определенные запросы, выступая в качестве сервера для других.

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

1.1.1. Описание комплекта документов

   Спецификация диаметра состоит из обновленной версии базовой
   спецификация протокола (этот документ) и транспортный профиль
   [RFC3539].Этот документ отменяет RFC 3588 и RFC 5719. A
   сводку обновлений базового протокола, включенную в этот документ, можно
   находится в Разделе 1.1.3.

   Этот документ определяет базовую спецификацию протокола для AAA, которая
   включает поддержку бухгалтерского учета. Есть также множество
   документы приложений, описывающие приложения, которые используют эту базу
   спецификация для аутентификации, авторизации и учета.
   В этих прикладных документах указано, как использовать протокол Diameter.
   в контексте их применения.Фахардо и др. Стандарты Track [Страница 10] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


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

   «Разъяснения по маршрутизации запроса диаметра на основе
   Имя пользователя и область "[RFC5729] определяет конкретное поведение о том, как
   запросы маршрутизации на основе содержимого AVP имени пользователя (атрибут
   Пара значений).1.1.2. Условные обозначения, используемые в этом документе

   Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
   документ следует интерпретировать, как описано в [RFC2119].

1.1.3. Отличия от RFC 3588

   Этот документ устарел RFC 3588, но полностью обратно совместим.
   с этим документом. Изменения, внесенные в этот документ, касаются
   устранение проблем, которые возникли во время внедрения
   Диаметр (RFC 3588).Дан обзор некоторых основных изменений.
   ниже.

   o Устарело использование AVP внутриполосной защиты для согласования
      Безопасность транспортного уровня (TLS) [RFC5246]. Это вообще было
      считают, что самозагрузка TLS через Inband-Security AVP
      создает определенные риски безопасности, потому что не полностью
      защищать информацию, передаваемую в CER / CEA (Возможности-
      Обмен-Запрос / Возможности-Обмен-Ответ). Эта версия
      Диаметр использует общий подход к определению хорошо известного
      защищенный порт, который одноранговые узлы должны использовать при обмене данными через TLS / TCP
      и DTLS / SCTP.Этот новый подход дополняет существующий внутриполосный
      переговоры о безопасности, но он не заменяет его полностью. В
      старый метод сохранен по причинам обратной совместимости.

   o Устарел обмен сообщениями CER / CEA в открытом состоянии.
      Эта функция была включена в таблицу конечного автомата одноранговых узлов RFC.
      3588, но нигде в этом
      документ. По мере продвижения работы над этим документом стало ясно
      что множественность значений и использования AVP с идентификатором приложения в
      сообщения CER / CEA (и сами сообщения) рассматриваются как
      злоупотребление правилами расширяемости Diameter и, следовательно, необходимость
      упрощение.Обмен возможностями в открытом состоянии осуществлен.
      повторно введен в отдельной спецификации [RFC6737], которая явно
      определяет новые команды для этой функции.





Фахардо и др. Стандарты Track [Страница 11] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   o Упрощенные требования безопасности. Использование охраняемого транспорта
      для обмена сообщениями Diameter остается обязательным. Однако TLS /
      TCP и DTLS / SCTP стали основными методами защиты
      Диаметр с IPsec в качестве вторичной альтернативы.См. Раздел 13
      для подробностей. Поддержка структуры сквозной безопасности
      (E2E-последовательность AVP и бит P в заголовке AVP) также были
      устарело.

   o Изменена расширяемость диаметра. Это включает в себя исправления
      Описание расширяемости диаметра (раздел 1.3 и другие) на
      лучшая помощь дизайнерам приложений Diameter; кроме того, новый
      спецификация ослабляет политику в отношении распределения
      Коды команд для использования в зависимости от производителя.

   o Уточнено использование идентификатора приложения.Разъяснить правильное использование
      Информация об идентификаторе приложения, которую можно найти в нескольких местах
      внутри сообщения Diameter. Это включает коррелирующее приложение
      Идентификаторы можно найти в заголовках сообщений и AVP. Эти изменения также
      четко укажите правильное значение идентификатора приложения для использования
      сообщения специального базового протокола (ASR / ASA, STR / STA), а также
      пояснить содержание и использование идентификатора Vendor-Specific-Application-Id.

   o Уточнены исправления маршрутизации. Этот документ более четко определяет
      какую информацию (AVP и идентификаторы приложений) можно использовать для создания
      общие решения по маршрутизации.Правило расстановки приоритетов
      критерии перенаправления маршрутизации при обнаружении нескольких записей маршрута
      через редирект также был добавлен (см. Раздел 6.13).

   o Упрощенное обнаружение одноранговых узлов Diameter. Открытие диаметра
      process теперь поддерживает только широко используемые схемы обнаружения; остальные
      устарели (подробности см. в Разделе 5.2).

   Есть много других исправлений, которые были внесены в
   этот документ, который нельзя считать значительным, но у них есть
   стоимость тем не менее.Примеры: удаление устаревших типов, исправления
   государственная машина, разъяснение избирательного процесса, сообщение
   проверка, исправления для значений Failed-AVP и Result-Code AVP и т. д. Все
   исправлений, поданных против RFC 3588 до публикации этого
   документ был адресован. Исчерпывающий список изменений не
   показано здесь по практическим соображениям.

1.2. Терминология

   AAA

      Аутентификация, авторизация и учет.





Фахардо и др. Стандарты Track [Страница 12] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   ABNF

      Расширенная форма Бэкуса-Наура [RFC5234].Метаязык со своим
      формальный синтаксис и правила. Он основан на форме Бэкуса-Наура и
      используется для определения обмена сообщениями в двунаправленном
      протокол связи.

   Бухгалтерский учет

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

   Бухгалтерский учет

      Учетная запись представляет собой сводку ресурса
      потребление пользователя за весь сеанс. Бухгалтерские серверы
      создание бухгалтерской записи может сделать это путем обработки промежуточных
      учетные события или учетные события с нескольких устройств
      обслуживает того же пользователя.Аутентификация

      Акт проверки личности сущности (субъекта).

   Авторизация

      Акт определения того, будет ли запрашивающая организация (субъект)
      получить доступ к ресурсу (объекту).

   Пара атрибут-значение (AVP)

      Протокол Diameter состоит из заголовка, за которым следует один или несколько
      Пары атрибут-значение (AVP). AVP включает заголовок и
      используется для инкапсуляции специфичных для протокола данных (например, маршрутизации
      информации), а также аутентификации, авторизации или
      бухгалтерская информация.Формат командного кода (CCF)

      Модифицированная форма ABNF, используемая для определения команд Diameter (см.
      Раздел 3.2).

   Агент диаметра

      Агент Diameter - это узел Diameter, который обеспечивает ретрансляцию, прокси,
      перенаправление или услуги перевода.




Фахардо и др. Стандарты Track [Страница 13] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   Диаметр клиента

      Клиент Diameter - это узел Diameter, который поддерживает клиент Diameter.
      приложений, а также базовый протокол.Клиенты диаметра
      часто реализуется в устройствах, расположенных на краю сети и
      предоставлять услуги контроля доступа для этой сети. Типичный
      примеры клиентов Diameter включают сервер доступа к сети
      (NAS) и внешний агент мобильного IP (FA).

   Диаметр узла

      Узел Diameter - это хост-процесс, который реализует Diameter.
      протокол и действует как клиент, агент или сервер.

   Диаметр Peer

      Два узла Diameter совместно используют прямой транспорт TCP или SCTP
      соединения называются одноранговыми узлами Diameter.Диаметр сервера

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

   Вниз по течению

      Нисходящий поток используется для определения направления конкретного
      Сообщение Diameter от домашнего сервера к клиенту Diameter.

   Домашнее царство

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

      Сервер Diameter, обслуживающий домашнюю область.

   Промежуточный учет

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




Фахардо и др. Стандарты Track [Страница 14] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   Местное царство

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

   Многосессионный

      Мультисессия представляет собой логическое соединение нескольких сессий.
      Мультисессии отслеживаются с помощью Acct-Multi-Session-Id. An
      Примером мультисессии может быть пакет Multi-link PPP. Каждый
      нога пакета будет сеансом, в то время как весь пакет будет
      быть мультисессионным.

   Идентификатор доступа к сети

      Идентификатор доступа к сети, или NAI [RFC4282], используется в
      Протокол Diameter для извлечения личности пользователя и его области.В
      identity используется для идентификации пользователя во время аутентификации и / или
      авторизация, пока область используется для маршрутизации сообщений
      целей.

   Прокси-агент или прокси

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

   Царство

      Строка в NAI, которая следует сразу за символом «@».
      Имена областей NAI должны быть уникальными и совмещены
      администрирование пространства имен DNS. Диаметр использует
      область, также называемая областью, для определения
      могут ли сообщения быть удовлетворены локально или они должны быть
      перенаправлено или перенаправлено.В RADIUS имена областей не обязательно
      совмещены с пространством имен DNS, но могут быть независимыми от него.








Фахардо и др. Стандарты Track [Страница 15] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   Учет в реальном времени

      Бухгалтерский учет в реальном времени предполагает обработку информации о
      использование ресурсов в течение определенного временного окна. Обычно время
      ограничения вводятся, чтобы ограничить финансовый риск.В
      Приложение Diameter Credit-Control [RFC4006] является примером
      приложение, определяющее функции учета в реальном времени.

   Агент ретрансляции или реле

      Пересылает запросы и ответы на основе маршрутизации
      AVP и записи в таблице маршрутизации. Поскольку реле не определяют политику
      решения, они не проверяют и не изменяют немаршрутизирующие AVP. Как
      в результате реле никогда не отправляют сообщения, не нужно понимать
      семантика сообщений или немаршрутизируемых AVP, и способны
      обработка любого приложения или типа сообщения Diameter.Поскольку реле
      принимать решения на основе информации о маршрутизации AVP и области
      таблицы пересылки, они не сохраняют состояние использования ресурсов NAS или
      сеансы в процессе.

   Агент перенаправления

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

   Сессия

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

   Агент с отслеживанием состояния

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



Фахардо и др. Стандарты Track [Страница 16] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   Подсессия

      Подсессия представляет собой отдельную услугу (например,g., QoS или данные
      характеристики), предоставленные данному сеансу. Эти услуги могут
      происходить одновременно (например, одновременная передача голоса и данных
      во время одного сеанса) или поочередно. Эти изменения в сессиях
      отслеживаются с помощью Account-Sub-Session-Id.

   Состояние транзакции

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

   Агент перевода

      Агент трансляции (TLA на рисунке 4) - это узел Diameter с отслеживанием состояния.
      который выполняет трансляцию протокола между Diameter и другим
      Протокол AAA, например RADIUS.

   Upstream

      Восходящий поток используется для определения направления конкретного
      Сообщение Diameter от клиента Diameter к домашнему серверу.

   Пользователь

      Сущность или устройство, запрашивающее или использующее некоторый ресурс для поддержки
      из которых клиент Diameter сгенерировал запрос.1.3. Подход к расширяемости

   Протокол Diameter предназначен для расширения за счет использования нескольких
   механизмы, в том числе:

   o Определение новых значений AVP

   o Создание новых AVP

   o Создание новых команд

   o Создание новых приложений




Фахардо и др. Стандарты Track [Страница 17] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   С точки зрения расширяемости, аутентификация Diameter,
   авторизация и бухгалтерские приложения обрабатываются одинаково
   путь.Примечание. Разработчикам протоколов следует попытаться повторно использовать существующие функции,
   а именно значения AVP, AVP, команды и приложения Diameter. Повторное использование
   упрощает стандартизацию и внедрение. Чтобы избежать потенциального
   проблемы взаимодействия, важно убедиться, что семантика
   повторно используемых функций хорошо изучены. Учитывая, что диаметр может
   также несут атрибуты RADIUS как Diameter AVP, такое повторное использование
   соображения также применимы к существующим атрибутам RADIUS, которые могут быть
   полезно в приложении Diameter.1.3.1. Определение новых значений AVP

   Чтобы выделить новое значение AVP для AVP, определенных в Diameter
   базового протокола, IETF необходимо утвердить новый RFC, описывающий
   Значение AVP. Соображения IANA для этих значений AVP обсуждаются в
   Раздел 11.3.

   Распределение значений AVP для других AVP регулируется IANA.
   рассмотрение документа, определяющего эти AVP. Обычно
   выделение новых значений для AVP, определенной в RFC, потребует
   Обзор IETF [RFC5226], в то время как значения для AVP, зависящие от поставщика, могут быть
   выделено продавцом.1.3.2. Создание новых AVP

   Определяемая новая AVP ДОЛЖНА использовать один из типов данных, перечисленных в
   Разделы 4.2 или 4.3. Если соответствующий производный тип данных уже
   определено, его СЛЕДУЕТ использовать вместо базового типа данных, чтобы
   возможность повторного использования и хорошая практика проектирования.

   В случае необходимости логической группировки AVP, и
   в данной команде возможно несколько "групп", рекомендуется
   использовать сгруппированный AVP (см. раздел 4.4).

   Создание новых AVP может происходить по-разному.Рекомендуемый
   подход состоит в том, чтобы определить новую AVP общего назначения в Standards Track.
   RFC одобрен IETF. Однако, как описано в Разделе 11.1.1,
   есть другие механизмы.

1.3.3. Создание новых команд

   Новый код команды ДОЛЖЕН быть выделен, когда требуются AVP (те
   обозначены как {AVP} в определении CCF) добавляются, удаляются из,
   или переопределить в (например, изменив требуемую AVP на
   необязательный) существующая команда.



Фахардо и др. Стандарты Track [Страница 18] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   Кроме того, если транспортные характеристики команды
   изменилось (например, по количеству обходов
   требуется), ДОЛЖЕН быть зарегистрирован новый код команды.Изменение CCF команды, такое как описано выше, ДОЛЖНО
   приведет к определению нового кода команды. Это впоследствии
   приводит к необходимости определить новое приложение Diameter для любого
   приложение, которое будет использовать эту новую команду.

   Рекомендации IANA для кодов команд обсуждаются в
   Раздел 3.1.

1.3.4. Создание новых приложений диаметра

   Каждая спецификация приложения Diameter ДОЛЖНА иметь назначенный IANA
   Идентификатор приложения (см. Раздел 2.4). Управляемое пространство идентификаторов приложений
   плоский, и нет никакой связи между разными диаметрами
   приложения в отношении их идентификаторов приложений.Таким образом, там
   эти идентификаторы приложений не поддерживают управление версиями
   самих себя; каждое приложение Diameter представляет собой отдельное приложение.
   Если приложение связано с другим диаметром
   приложения, такая связь не известна Diameter.

   Прежде чем описывать правила создания новых приложений Diameter,
   важно обсудить семантику вхождений AVP как
   заявлено в CCF и M-bit флаге (раздел 4.1) для AVP. Там
   нет никаких отношений между ними; они установлены
   независимо.o CCF указывает, какие AVP помещены в команду Diameter с помощью
      отправитель этой команды. Часто, поскольку есть несколько режимов
      протокольных взаимодействий, многие из AVP обозначены как
      по желанию.

   o Бит M позволяет отправителю указать получателю,
      непонимание семантики AVP и ее содержимого является
      обязательный. Если M-бит установлен отправителем и получателем
      не понимает AVP или значений, содержащихся в этой AVP,
      тогда возникает сбой (см. раздел 7).Разработчик протокола принимает решение, когда разрабатывать новый
   Применение диаметра, а не расширение диаметра другими способами.
   Однако новое приложение Diameter ДОЛЖНО быть создано, когда один или несколько
   из следующих критериев:







Фахардо и др. Стандарты Track [Страница 19] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   M-битная установка

      AVP с битом M в столбце MUST таблицы флагов AVP является
      добавлен в существующую команду / приложение.AVP с M-битом
      в столбце MAY таблицы флагов AVP добавляется к существующему
      Команда / Приложение.

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

   Команды

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

      Если существующее приложение меняет значение / семантику своего
      AVP отмечает или добавляет новые биты флагов, затем новое приложение Diameter
      ДОЛЖЕН быть создан.

   Если определение команды CCF позволяет это, реализация может
   добавить произвольные дополнительные AVP с очищенным M-битом (в том числе
   определенные AVP) к этой команде без необходимости определять новый
   применение. Пожалуйста, обратитесь к Разделу 11.1.1 за подробностями.

2. Обзор протокола

   Базовый протокол Diameter занимается установкой
   соединения с пирами, согласование возможностей, способ отправки сообщений
   и маршрутизируется через одноранговые узлы, и как соединения в конечном итоге разрываются
   вниз.Базовый протокол также определяет определенные правила, которые применяются ко всем
   обмен сообщениями между узлами Diameter.

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

   Первоначальный запрос на аутентификацию и / или авторизацию пользователя
   будет включать AVP с идентификатором сеанса.Затем Session-Id используется во всех
   последующие сообщения для идентификации сеанса пользователя (см. Раздел 8 для



Фахардо и др. Стандарты Track [Страница 20] 

RFC 6733 Diameter Base Protocol Октябрь 2012 г.


   Дополнительная информация). Сообщающая сторона может принять запрос или
   отклонить его, вернув ответное сообщение с набором Result-Code AVP
   чтобы указать, что произошла ошибка. Специфическое поведение
   Сервер или клиент Diameter, получающие запрос, зависят от Diameter.
   приложение занято.Состояние сеанса (связанное с Session-Id) ДОЛЖНО быть освобождено после
   получение Session-Termination-Request, Session-Termination-
   Ответ, истечение авторизованного времени обслуживания в Session-Timeout
   AVP и согласно правилам, установленным в конкретном диаметре
   применение.

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

   Клиенты Diameter ДОЛЖНЫ поддерживать базовый протокол, который включает
   бухгалтерский учет.Кроме того, они ДОЛЖНЫ полностью поддерживать каждый диаметр.
   приложение, которое необходимо для реализации клиентского сервиса, например,
   Требования к серверу доступа к сети (NASREQ) [RFC2881] и / или Mobile
   IPv4. Клиент Diameter ДОЛЖЕН называться «Клиент Diameter X».
   где X - это приложение, которое оно поддерживает, а не "Диаметр".
   Клиент ».

   Серверы Diameter ДОЛЖНЫ поддерживать базовый протокол, который включает
   бухгалтерский учет. Кроме того, они ДОЛЖНЫ полностью поддерживать каждый диаметр.
   приложение, необходимое для реализации намеченной услуги, e.грамм.,
   NASREQ и / или мобильный IPv4. Сервер Diameter ДОЛЖЕН называться
   «Сервер Diameter X», где X - приложение, которое он поддерживает, и
   не «Сервер диаметра».

   Релеи Diameter и агенты перенаправления прозрачны для Diameter
   приложений, но они ДОЛЖНЫ поддерживать базовый протокол Diameter, который
   включает бухгалтерский учет и все приложения Diameter.

   Прокси-серверы Diameter ДОЛЖНЫ поддерживать базовый протокол, который включает
   бухгалтерский учет. Кроме того, они ДОЛЖНЫ полностью поддерживать каждый диаметр.
   приложение, необходимое для реализации прокси-сервисов, e.грамм.,
   NASREQ и / или мобильный IPv4. Прокси-сервер Diameter ДОЛЖЕН называться
   "Прокси-сервер диаметра X", где X - приложение, которое он поддерживает, и
   не «Прокси-сервер диаметра».










Фахардо и др. Стандарты Track [Страница 21] 

Что такое задняя коробка?

Задний ящик — это металлический или пластиковый ящик, который встраивается в стену. Затем к задней части корпуса прикрепляется передняя панель розетки или выключателя.

Какой задний ящик мне нужен?

Для задних ящиков используются два основных материала.Бывают металлические задние ящики и пластиковые задние ящики.

Пластиковые задние коробки

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

Металлические задние коробки

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

Какой тип задней коробки мне понадобится?

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

Задняя коробка какой глубины мне понадобится?

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

Если вы устанавливаете новые задние ящики, мы всегда советуем не экономить на глубине. Это упрощает установку выключателей и розеток — электрик поблагодарит вас за это позже!

Розетки и выключатели стандартные

Мы рекомендуем следующие глубины для стандартных выключателей и розеток:

Переключатели: 16 мм
Гнездо и диммеры: 25 мм
Разъемы USB: 35 мм
Переключатели для бритвы и кухонной плиты: 32 мм

Плоские, безвинтовые и тонкие розетки и выключатели

Для тонких, безвинтовых или плоских пластин вам потребуются более глубокие задние коробки, поэтому мы рекомендуем следующие размеры:

Переключатели 25 мм
Розетки и диммеры 35 мм
USB-разъемы, переключатели для бритвы и плиты 47 мм

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

Задние коробки для поверхностного монтажа

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

Кабельные вводы для открытых ящиков

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

Будьте в безопасности!

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

Sks Hirschmann Jack Розетка, вертикальная вертикальная Диаметр штифта: 4 мм Никелированный BU 20 1 шт. 930177000 Технический паспорт

Система 4 мм / система 4 мм

SKS Kontakttechnik GmbH I Neue Schichtstraße 14 I D-09366 Niederdorf I Telefon + 49-37296-930-300 I Telefax +49 37296-930-301 I www.sks-kontakt.de I info @ sks-kontakt.de

2013-04_1

Produktbeschreibung

Описание продукта

Beschreibung

Описание

Blanke Buchse, Durchmesser 4 мм, Messing,
vernickelt mit Lötanschluss und M6 Gewinde. Zum
Einbau in Gerätechassis und Schalttafeln до 13,5 мм
Wandstärke.

Блестящий металл диаметром 4 мм из никелированной латуни
Розетка с пайкой и резьбой M6. Для установки
в шасси оборудования и панели переключателей до
13.Толщина стенки 5 мм.

Тип

Тип

BU 20

BU 20

Gehäusefarbe / Artikel-Nr.

Цвет корпуса / арт.

Zeichnung

Чертеж

Technische Daten

Технические данные

Kontaktart

Тип контакта

ungefederte Buchse Ø 4 мм

Торцевой ключ

löten, M6 Gewinde

припой, резьба M6

Bemessungsspannung

Номинальное напряжение

30 VAC / 60 VDC

30 VAC / 60 VDC

Messkategorie lt.IEC61010

Кат. соотв. согласно
IEC61010

CAT I

CAT I

Bemessungsstrom
(снижение номинальных характеристик Kurve beachten)

Номинальный ток
(пожалуйста, учитывайте кривую снижения характеристик)

16 A

16 A

Durchgangswiderstand

Сопротивление контакта

5 мОм

5 мОм

Gehäusebefestigung

Монтаж

schrauben

винт

Werkstoff

Материал

Kontaktmaterial

Материал контактов

Messing

brass71

никель

Gehäusematerial

Материал корпуса

Umgebungsbedingungen

Условия окружающей среды

Temperaturbereich

Диапазон температур

-25 ° C до + 100 ° C

-25 ° C 9007 1

Brennbarkeitsklassen

Класс воспламеняемости

Gehäuse (Grundmaterial)

Корпус (основной материал)

Buchsen / розетки

BU 20

930 1730 1730

ø 4

ø 7,5

20

27

M 6×0,75

1,5