Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи
Недавно появилась задача использовать собственные маршруты при подключении через OpenVPN на MacOSX. Если это сделать по аналогии с OpenVPN — просто добавить в конфиг параметр up/route-up, то в логе вы увидите, что не удалось выполнить из-за дубликата параметра. Что за ересь? Идём на сайт tunnelblick’a в раздел документации и видим, что нужно использовать специфические имена скриптов. Но куда их ложить?
Нашёл в интернете заметку, где сказано, что ложить их нужно по такому пути /Library/Application Support/Tunnelblick/Users/<user_name>/<config_name>.tlbk/Contents/Resources/, если у вас личный когфиг, или по такому /Library/Application Support/Tunnelblick/Shared/<config_name>.tblk/Contents/Resources, если общий.
Примечание.
Да, именно с таким сообщением начала падать kafka спустя некоторое время после запуска. Включение режима debug немного увеличило «понятность»
ERROR Error while accepting connection (kafka.network.Acceptor)
java.net.SocketException: Invalid argument
at sun.nio.ch.Net.setIntOption0(Native Method)
at sun.nio.ch.Net.setSocketOption(Net.java:341)
at sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:190)
at sun.nio.ch.SocketAdaptor.setBooleanOption(SocketAdaptor.java:271)
at sun.nio.ch.SocketAdaptor.setTcpNoDelay(SocketAdaptor.java:306)
at kafka.network.Acceptor.accept(SocketServer.scala:654)
at kafka.network.Acceptor.run(SocketServer.scala:579)
at java.lang.Thread.run(Thread.java:748)
Читать далее →
Запись опубликована автором skeletor в рубрике FreeBSD, Linux, Solaris, www, Разное, мелочи.Что бы запустить скрипт разово, существует несколько методов:
Читать далее →
Запись опубликована автором skeletor в рубрике FreeBSD, Linux, Solaris, Разное, мелочи.Данная заметка была найдена на просторах интернета, но что бы не потерялась, добавлю себе. И так, если получаем ошибку:
genunix: [ID 702911 kern.notice] basic rctl process.max-stack-size (value 8388608) exceeded by process 938819 uid 80 ...
Читать далее →
Запись опубликована автором skeletor в рубрике Solaris, Разное, мелочи.Данная ошибка начала возникать после обновления simpleSAML. Причём появляется только на один из ресурсов на который настроено SSO и не у всех, а у нескольких человек. С чем конкретно связано — пока неясно. Начал исследовать, что общего у этих проблемных человек — только то, что работают с одним внешним ресурсом и всё. Не густо…
Читать далее →
Запись опубликована автором skeletor в рубрике www, Программирование, Разное, мелочи.Данная заметка будет дополняться по мере возникновения таковых и будет содержать особенности, которые мало где описаны и не всегда очевидны.
Читать далее →
Запись опубликована автором skeletor в рубрике Разное, мелочи.Симптомы: системные диски время от времени вгружаются на 100% busy. Через rwsnoop вычисляем, что это fmd просто конски пишет в файлы:
/var/fm/fmd/fltlog
/var/fm/fmd/ckpt/eft
Ротация, перезапуск fmd ни к чему не приводит. С помощью утилиты fmstat посмотрим счётчики событий fmd
Читать далее →
Запись опубликована автором skeletor в рубрике Solaris.Здесь буду приводить лишь некоторые нюансы, которые являются нестандартными. После вставки модема смотрим его VID:PID:
$ lsusb Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 005: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Читать далее →
Запись опубликована автором skeletor в рубрике Разное, мелочи, Шлюз, инет.ASLR (англ. address space layout r andomization — «рандомизация размещения адресного пространства») — технология, применяемая в операционных системах, при использовании которой случайным образом изменяется расположение в адресном пространстве процесса важных структур данных, а именно образов исполняемого файла, подгружаемых библиотек, кучи и стека.
Читать далее →
Запись опубликована автором skeletor в рубрике FreeBSD, Linux, OpenBSD, Solaris, Разное, мелочи.Сейчас всё чаще сервера подключают сразу к нескольким провайдерам. Поэтому, остро стоит проблема корректной работы сервисов, неважно к какому из каналов сервера вы подключились. У OpenVPN для этого есть несколько «хаков».
Читать далее →
Запись опубликована автором skeletor в рубрике Безопасность, Разное, мелочи.инкапсуляция (логический интерфейс) | MPLS приложений Руководство пользователя
Описание
Настройте тип инкапсуляции логического уровня связи. Не все типы инкапсуляции поддерживаются на коммутаторах. См. интерфейс командной строки.
Начиная Junos OS выпуске 20.1R1, агрегированные интерфейсы Ethernet поддерживают инкапсуляцию VLAN TCC (трансляционной перекрестной связи) на платформах серии MX. Дополнительные сведения см. в «Настройка инкапсуляции VLAN TCC». Поддерживаются только не ethernet-интерфейсы, а также интерфейсы SONET и ATM. Предполагается, что пользователь получит соединения-участникы агрегированной ethernet с поддерживаемым аппаратным обеспечением для настройки инкапсуляции VLAN TCC, а внешняя проверка записи для агрегированных интерфейсов Ethernet (AE) не выполняется.
Параметры
atm-ccc-cell-relay— Используйте инкапсуляцию ячеей-ретрансляции ATM.
atm-ccc-vc-mux— Используйте виртуальный канал ATM (VC) мультиплексную инкапсуляцию в схемах CCC. При использовании такого типа инкапсуляции можно настроить только ccc семейство.
atm-cisco-nlpid-Используйте инкапсуляцию протокола сетевого уровня Cisco ATM (NLPID). При использовании такого типа инкапсуляции можно настроить только inet семейство.
atm-mlppp-llc-Только для интерфейсов ATM2 IQ используйте Multilink Point-to-Point (MLPPP) через AAL5 LLC. Для этого типа инкапсуляции маршрутизатор должен быть оснащен СЛУЖБами связи или PIC служб голосовой связи. Инкапсуляция MLPPP через ATM не поддерживается на интерфейсах ATM2 IQ OC48.
atm-nlpid—Используйте инкапсуляцию ATM NLPID. При использовании такого типа инкапсуляции можно настроить только inet семейство.
atm-ppp-llc(Интерфейсы ATM2 IQ и серия MX с интерфейсами MPC/MIC, использующими MIC ATM только с SFP) Используйте PPP через инкапсуляцию LLC AAL5.
atm-ppp-vc-mux(интерфейсы ATM2 IQ и серия MX с интерфейсами MPC/MIC, использующими MIC ATM только с SFP) Используйте PPP через ATM AAL5 мультиплексную инкапсуляцию.
atm-snap(Все интерфейсы, включая серия MX с интерфейсами MPC/MIC с использованием MIC ATM с SFP) Используют инкапсуляцию точки подсетей ATM (SNAP).
atm-tcc-snap— Используйте инкапсуляцию ATM SNAP в трансляционных перекрестных соединениях (TCC) каналов.
atm-tcc-vc-mux-Используйте мультиплексную инкапсуляцию ATM VC в цепях TCC. При использовании такого типа инкапсуляции можно настроить только tcc семейство.
atm-vc-mux(Все интерфейсы, включая серия MX с интерфейсами MPC/MIC с использованием ATM MIC с SFP) Используют мультиплексную инкапсуляцию ATM VC. При использовании такого типа инкапсуляции можно настроить только inet семейство.
ether-over-atm-llc(Все IP-интерфейсы, включая серия MX с интерфейсами MPC/MIC, использующими ATM MIC с SFP) Для интерфейсов, передателей IP-трафика, используйте Ethernet через LLC-инкапсуляцию ATM. При использовании такого типа инкапсуляции многоточки интерфейсы настраивать нельзя.
ether-vpls-over-atm-llc-Только для интерфейсов ATM2 IQ используйте виртуальный частный lan-сервис Ethernet (VPLS) через инкапсуляцию ATM LLC для мостового интерфейса Ethernet и интерфейсов ATM через экземпляр маршрутизации VPLS (как описано в RFC 2684, Многопротокольная инкапсуляция на уровне 5адаптации ATM). Пакеты с интерфейсов ATM преобразуются в стандартные инкапсулированные кадры Ethernet ENET2/802.3 с удаленной последовательность проверки кадров (FCS).
ether-vpls-over-fr-Для интерфейсов E1, T1, E3, T3 и SONET используйте виртуальный частный lan сервис Ethernet (VPLS) через инкапсуляцию Frame Relay для поддержки мостового Ethernet через инкапсулированные TDM интерфейсы для приложений VPLS на RFC 2427, Multiprotocol Interconnect через Frame Relay.
MIC SONET/SDH OC3/STM1 (многоуровневый) MIC с SFP, многоканальный SONET/SDH OC3/STM1 (Многоуровневый) MIC с SFP, и DS3/E3 MIC не поддерживают инкапсуляцию Ethernet через Frame Relay.
ether-vpls-over-ppp-Только для интерфейсов E1, T1, E3, T3 и SONET используйте виртуальный частный lan-сервис Ethernet (VPLS) через инкапсуляцию протокола «точка-точка» (PPP) для поддержки мостового Ethernet через интерфейсы PPP-TDM для приложений VPLS.
ethernet— Используйте инкапсуляцию Ethernet II (как описано в RFC 894, стандарт передачи IP-датаграмм по сетям Ethernet).
ethernet-ccc—Используйте инкапсуляцию Ethernet CCC на интерфейсах Ethernet.
ethernet-vpls-Используйте инкапсуляцию Ethernet VPLS на интерфейсах Ethernet, которые имеют активную VPLS и которые должны принимать пакеты, несущие стандартные значения ID протокола метки (TPID).
Встроенная PIC Gigabit Ethernet на маршрутизаторе M7i не поддерживает расширенную инкапсуляцию VLAN VPLS.
ethernet-vpls-fr— Используйте установку VPLS, когда CE подключено к маршрутизатору PE по мультиплексирование с разделением по времени (TDM) связи. Этот тип инкапсуляции позволяет маршрутизатору PE прервать внешнее соединение Frame Relay уровня 2, использовать биты 802.1p внутри внутреннего заглука Ethernet для классификации пакетов, посмотреть на MAC-адрес из загона Ethernet и использовать MAC-адрес для пересылки пакета в заданный экземпляр VPLS.
frame-relay-ccc—Используйте инкапсуляцию Frame Relay в цепях CCC. При использовании такого типа инкапсуляции можно настроить только ccc семейство.
frame-relay-ether-type-Используйте инкапсуляцию типа ether Frame Relay для совместимости с Cisco Frame Relay. Для физического интерфейса необходимо настроить гибкую инкапсуляцию Frame-Relay.
frame-relay-ether-type-tcc-Используйте канал Ether типа Frame Relay для TCC, совместимого с Cisco, в сетях TCC для подключения различных носителей. Для физического интерфейса необходимо настроить гибкую инкапсуляцию Frame-Relay.
frame-relay-ppp—Используйте PPP в цепях Frame Relay. При использовании такого типа инкапсуляции можно настроить только ppp семейство.
frame-relay-tcc—Используйте инкапсуляцию Frame Relay в цепях TCC для подключения различных средств связи. При использовании такого типа инкапсуляции можно настроить только tcc семейство.
gre-fragmentation-Только для интерфейсов адаптивной службы используйте инкапсуляцию фрагментации GRE для фрагментации пакетов IPv4 в туннелях GRE. Эта инкапсуляция очищает бит not fragment (DF) в загоне пакета. Если размер пакета превышает значение максимальный размер пакета (MTU), то перед инкапсуляцией пакет фрагментирован.
multilink-frame-relay-end-to-end-Используйте инкапсуляцию MLFR FRF.15. Эта инкапсуляция используется только на интерфейсах многоканальных соединений, служб связи и голосовых услуг, а также на интерфейсах T1 или E1, а также поддерживается на интерфейсах LSQ и избыточных LSQ.
multilink-ppp— Используйте инкапсуляцию MLPPP. Эта инкапсуляция используется только на интерфейсах многоканальных соединений, служб связи и голосовых служб, а также на интерфейсах T1 или E1.
ppp-over-ether-Используйте PPP через инкапсуляцию Ethernet для настройки обычного интерфейса Ethernet для динамического логического интерфейса PPPoE на M120 и M320 маршрутизаторах с интеллектуальной очереди 2 (IQ2) CS, а также на серия MX маршрутизаторах с MPC.
ppp-over-ether-over-atm-llc(серия MX маршрутизаторы с MPC, использующие MIC ATM только с SFP) Для интерфейсов ATM, используйте PPP через Ethernet через LLC-инкапсуляцию ATM. При использовании такого типа инкапсуляции нельзя настроить адрес интерфейса. Вместо этого настройте адрес интерфейса на интерфейсе PPP.
vlan-bridge-Используйте инкапсуляцию моста Ethernet VLAN на интерфейсах Ethernet, которые имеют IEEE 802.1Q, службы гибкого ethernet и мостов, и которые должны принимать пакеты, несущие TPID 0x8100 или TPID, определенный пользователем.
vlan-ccc— Используйте инкапсуляцию виртуальной локальной сети (VLAN) Ethernet в схемах CCC. При использовании такого типа инкапсуляции можно настроить только ccc семейство.
vlan-vci-ccc— Используйте межсетевую инкапсуляцию ATM-to-Ethernet в схемах CCC. При использовании такого типа инкапсуляции можно настроить только ccc семейство.
vlan-tcc—Используйте инкапсуляцию Ethernet VLAN в цепях TCC. При использовании такого типа инкапсуляции можно настроить только tcc семейство.
vlan-vpls—Используйте инкапсуляцию Ethernet VLAN в цепях VPLS.
vxlan-Используйте VXLAN плоскость данных инкапсуляцию для EVPN.
Группирование магистралей между Catalyst 4500/4000, 5500/5000, и 6500/6000 Series Switches с использованием инкапсуляции 802.1Q с системным ПО Cisco CatOS
Интерактивный документ. В данном документе содержится анализ конкретного устройства Cisco.Содержание
Введение
Предварительные условия
Требования
Используемые компоненты
Условные обозначения
Что такое транк?
Основные характеристики транкинга 802.1Q
Механизм добавления тегов
Фактор связующего дерева
Реализации Cisco
Конфигурирование транков 802.1Q
Требования к программному обеспечению и оборудованию
Режимы DTP
Пошаговый пример
Распространенные ошибки
Разные собственные виртуальные локальные сети
Разные VTP домены
Ошибка при удалении сетей VLAN расширенного диапазона из порта транка
Режим транкинга несовместим с типом инкапсуляции
Команды, используемые в данном документе
Перечень команд
Дополнительные сведения
Данный документ содержит общие сведения о концепции транкинга между двумя коммутаторами Ethernet и сосредоточен на стандарте транкинга IEEE 802.1Q. После краткого описания механизма транкинга 802.1Q приведено описание реализации с использованием коммутаторов Catalyst серий 4500/4000, 5500/5000 и 6500/6000. Пример приведен полностью вместе с указанием нескольких типичных ошибок конфигурации транкинга 802.1Q, возникающих при использовании системного ПО Catalyst OS (CatOS). Примеры транкинга 802.1Q с системным ПО Cisco IOS® см. в Конфигурация транкинга 802.1Q между коммутаторами Catalyst 3550/3560/3750 и Catalyst, на которых выполняется ПО Cisco IOS.
Требования
Для этого документа отсутствуют особые требования.
Используемые компоненты
Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.
Условные обозначения
Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.
В терминологии Cisco, транк — это канал типа «точка-точка», по которому передаются данные нескольких сетей VLAN. Назначение транка – экономить порты при создании канала связи между двумя устройствами, реализующими VLAN (обычно это два коммутатора). На следующей схеме можно видеть две виртуальные локальные сети, которые должны быть доступными на двух коммутаторах: Sa и Sb. Первым простым способом реализации является создание между устройствами двух физических каналов. Каждый из этих каналов передает трафик для виртуальной локальной сети.
Конечно, это решение не масштабируется. Условием добавления третьей VLAN является потеря двух дополнительных портов. Кроме того данная модель неэффективна в плане распределения нагрузки — трафик некоторых VLAN может не оправдывать пропускную способность выделенного канала. Транк объединяет виртуальные каналы в один физический канал передачи данных, как показано на следующей схеме:
В данном примере уникальный физический канал между двумя коммутаторами может передавать трафик любой сети VLAN. Для этого каждый кадр, отправляемый по каналу, Sa добавляет тег, чтобы Sb знал какой сети VLAN этот кадр принадлежит. Существуют различные схемы добавления тегов. Для сегментов Ethernet наиболее часто используются следующие:
протокол межкоммутационного канала Inter-Switch Link (ISL) (патентованный собственный ISL протокол Cisco)
802.1Q (стандарт IEEE, который рассматривается в данном документе)
Механизм добавления тегов
802.1Q использует внутренний механизм добавления тегов. «Внутренний» означает, что тэг вставляется в кадр:
Примечание. В случае протокола ISL кадр инкапсулируется.
Примечание. Обратите внимание на транк 802.1Q, одна VLAN НЕ помечена. Эта виртуальная локальная сеть, называемая собственной VLAN, должна быть настроена на каждой стороне транка. Таким образом можно выяснить какой сети VLAN принадлежит кадр, полученный без тега.
Механизм добавления тегов предполагает изменение кадра; устройство транкинга вставляет 4-байтный тег и повторно вычисляет контрольную последовательность кадра (FCS):
Поле EtherType, определяющее кадр 802.1Q, имеет значение 0x8100. В дополнение к 12-битному VLAN-ID, 3 бита зарезервированы для добавления тега приоритета IEEE 802.1p.
Примечание. Вставка тега в кадр, который уже имеет максимальный размер для Ethernet, создает кадр размером 1522 байт, который приемное оборудование может воспринять как «baby giant» (большой кадр). В спецификации стандарта IEEE 802.3 увеличен максимальный размер стандартного кадра, чтобы устранить эту проблему.
Фактор связующего дерева
Стандарт IEEE 802.1Q — это не только механизм добавления тегов. Он также определяет уникальный экземпляр связующего дерева, выполняющийся на собственной сети VLAN для всех остальных VLAN в сети. Такая сеть с одним связующим деревом (MST) является менее гибкой чем сеть со связующими деревьями для каждой VLAN (PVST), в которой для каждой сети VLAN используется свой экземпляр протокола Spanning Tree Protocol (STP). Cisco разработала протокол PVST+, чтобы сделать возможным выполнение нескольких экземпляров STP (даже в сети 802.1Q), используя механизм туннелирования. Хотя это не входит в спектр вопросов данного документа, но кратко это можно описать, как использование устройства Cisco для соединения зоны MST (обычно сеть на основе 802.1Q другого поставщика) с зоной PVST (обычно сеть на основе Cisco ISL). Нет особой конфигурации, которую можно настроить для реализации этого. В идеальной ситуации смешанная среда выглядит как показано на схеме ниже:
Реализация Cisco
В текущей реализации устройства Cisco поддерживают сети VLAN в количестве только до 1005. Это ограничение, введенное для согласования количества VLAN доступных с протоколом ISL, разрешено стандартом 802.1Q. Cisco разработала функцию сопоставления VLAN в CatOS 5.1, чтобы упростить функциональную совместимость с устройствами других поставщиков, однако она редко требуется.
Примечание. Дополнительную информацию о функции сопоставления VLAN см. в Настройка сетей VLAN.
Cisco также адаптировала свой динамический протокол ISL (DISL) и преобразовала его в динамический протокол транкинга (DTP). DISL может согласовывать транкинг ISL на канале между двумя устройствами. DTP, помимо этого, может согласовать тип инкапсуляции транкинга (802.1 Q или ISL), который также будет использован. Это полезная возможность, поскольку некоторые устройства Cisco поддерживают только ISL или 802.1Q, тогда как другие поддерживают оба протокола.
В реализации Cisco транк – это двухточечное соединение, хотя можно использовать инкапсуляцию 802.1Q на сегменте Ethernet, совместно используемом более чем двумя устройствами. Такая конфигурация требуется редко, но возможна при отказе согласования DTP.
Требования к программному обеспечению и оборудованию
С точки зрения ПО инкапсуляция 802.1Q впервые появилась в ПО CatOS версии 4.1. Однако в этом выпуске конфигурацию транкинга необходимо было программировать, прикладывая значительные усилия; DTP появился только в CatOS версии 4.2. См. раздел Режимы DTP данного документа.
Порты не всех коммутаторов Cisco Catalyst поддерживают инкапсуляцию 802.1Q. В настоящее время коммутаторы Catalyst 4500/4000 поддерживают только 802.1Q, порты Catalyst 6500/6000 способны использовать инкапсуляцию 802.1Q или ISL. В зависимости от модуля, порты Catalyst 5500/5000, поддерживающие транкинг, способны работать с инкапсуляцией ISL, инкапсуляцией 802.1Q или и с обеими одновременно. Выполните команду show port capabilities, чтобы получить точные сведения об этом. Способность транкинга указывается в явном виде:
Sa> (enable) show port capabilities 1/1 Model WS-X5530 Port 1/1 Type 1000BaseSX Speed 1000 Duplex full Trunk encap type 802.1Q,ISL Trunk mode on,off,desirable,auto,nonegotiate Channel no Broadcast suppression percentage(0-100) Flow control receive-(off,on,desired),send-(off,on,desired) Security no Membership static Fast start yes Rewrite no
Режимы DTP
При настройке порта для транкинга можно задать два параметра: режим транкинга и тип инкапсуляции (если порт поддерживает DTP).
Режим транкинга определяет согласование портом настройки транка со своим портом назначения. Ниже перечислены возможные настройки:
Режим транкинга
Отправка кадров DTP
Описание
Конечное состояние (локальный порт)
on
Да, периодически
Локальный порт сообщает удаленным портам о своем переходе в состояние транкинга.
Транкинг, без условий.
auto
Да, периодически
Локальный порт сообщает удаленным портам о своей способности транкинга, но не запрашивает переход в состояние транкинга.
Этот порт перейдет в состояние транкинга, только если это нужно удаленному порту, т.е. удаленный порт в режиме on или desirable.
desirable
Да, периодически
Локальный порт сообщает удаленным портам о своей способности транкинга и запрашивает переход в состояние транкинга.
Если порт обнаруживает, что удалённый порт способен к транкингу (удаленный порт в режиме on, desirable или auto), он перейдет в состояние транкинга или останется в состоянии без транкинга.
nonegotiate
НЕТ
Локальный порт переходит в режим безусловного транкинга без DTP уведомления удаленного порта.
Транкинг, без условий.
off
ДА
Отключить транкинг порта. DTP кадры отправляются только если порт переходит в состояние без транкинга.
Без транкинга, без условий.
Обратите внимание, что некоторые режимы (on, nonegotiate, off) явно задают состояние, в каком окажется порт. Неправильная настройка может привести к опасному или несовместимому состоянию, когда одна сторона выполняет транкинг, а другая – нет.
Порт в режиме on, auto или desirable периодически отправляет DTP кадры. Порт транкинга в режиме auto или desirable переходит в состояние без транкинга, если не получает DTP обновление от соседа в течение пяти минут.
Примечание. Если используется ПО CatOS 4.1, необходимо отключить любую форму согласования, задав режим off или nonegotiate при настройке транкинга 802.1Q.
Тип инкапсуляции позволяет пользователю выбрать использование 802.1Q или ISL при настройке транка. Конечно этот параметр уместен, если используемый модуль поддерживает оба типа. Параметр может принимать три различных значения:
Тип инкапсуляции
Описание
ISL
Устанавливает ISL для инкапсуляции порта.
dot1q
Устанавливает 802.1Q для инкапсуляции порта.
negotiate
Эта инкапсуляция доступна только в режимах auto или desirable транкинга.
Если удаленный порт имеет тип инкапсуляции по согласованию (negotiate), то транк в итоге будет создан с ISL.
Если удаленный порт настроен для ISL или 802.1Q или способен работать только с ISL или 802.1Q, то для инкапсуляции транкинга будет использоваться инкапсуляция удаленного порта.
В разделе Результаты возможных конфигураций транков Fast Ethernet и Gigabit Ethernet документа Настройка транков VLAN на портах Fast Ethernet и Gigabit Ethernet см. список всех возможных результирующих конфигураций.
Примечание. Между двумя коммутаторами, находящимися в различных VLAN Trunk Protocol (VTP) доменах, согласование будет отсутствовать. См. раздел Настройка VTP.
Пошаговый пример
Схема сети
Этот пример основан на очень простой лабораторной системе, состоящей из двух коммутаторов Catalyst 5500/5000, соединенных между собой через порты, поддерживающие транки. Для соединения двух коммутаторов требуется перекрестный кабель.
Минимальная установка транка 802.1Q с проверками возможности подключения
Выполните следующие действия.
Убедитесь, что состояния портов показывают, что они включены, но не находятся в состоянии транкинга.
Соедините терминал с консолью коммутаторов. См. документ Подключение терминала к порту консоли на коммутаторах Catalyst, если необходимо. Сначала проверьте состояние порта, участвующего в установке. Используйте команду show port 5/24 на Sa (show port 2/24 на Sb) и убедитесь, что они в состоянии connected (подключен):
Sa> (enable) show port 5/24 Port Name Status Vlan Level Duplex Speed Type ----- ------------------ ---------- ---------- ------ ------ ----- ------------ 5/24 connected 1 normal a-full a-100 10/100BaseTX !--- Output suppressed.
Для порта этого типа установлено значение по умолчанию. Этим значением является VLAN 1, оно получено в результате согласования полнодуплексной передачи данных на скорости 100 Мбит/с. Выполните команду show trunk 5/24, чтобы получить явное подтверждение, что порт не в состоянии транкинга, а его режим по умолчанию auto и инкапсуляция negotiate.
Sa> (enable) show trunk 5/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 5/24 auto negotiate not-trunking 1 !--- Output suppressed.
Задайте IP-адрес на интерфейсах управления sc0.
Используйте команду set interface sc0 10.0.0.1 на коммутаторе Sa и команду set interface sc0 10.0.0.2 на коммутаторе Sb, чтобы назначить IP-адрес этим двум коммутаторам. Команда show interface подтверждает, что интерфейс управления теперь правильно настроен в сети VLAN 1 по умолчанию:
Sa> (enable) set interface sc0 10.0.0.1 Interface sc0 IP address set. Sa> (enable) show interface sl0: flags=51<,POINTOPOINT,RUNNING> slip 0.0.0.0 dest 0.0.0.0 sc0: flags=63<UP,BROADCAST,RUNNING> vlan 1 inet 10.0.0.1 netmask 255.0.0.0 broadcast 10.255.255.255 Sa> (enable)При наличии результата выполнения команды show interface от устройства Cisco, можно воспользоваться средством интерпретации выходных данных Output Interpreter (только для зарегистрированных пользователей), чтобы выявить потенциальные проблемы и их местоположение.
Проверьте возможность подключения между Sa и Sb.
Выполните команду ping 10.0.0.2 из коммутатора Sa, чтобы подтвердить возможность подключения к коммутатору Sb:
Sa> (enable) ping 10.0.0.2 10.0.0.2 is alive Sa> (enable)
Настройте одинаковый VTP домен на обоих коммутаторах.
Теперь назначьте одинаковый VTP домен обоим коммутаторам. Как видно наличие одинакового VTP домена обязательно для использования DTP согласования. Выполните команду set vtp domain cisco на обоих коммутаторах, чтобы настроить их с одинаковым именем домена «cisco»:
Sa> (enable) set vtp domain cisco VTP domain cisco modified Sa> (enable)
Создайте сеть VLAN 2 в каждом коммутаторе.
Выполните команду set vlan 2 на обоих коммутаторах, чтобы создать VLAN 2. Если коммутаторы уже соединены транком, необходимо выполнить эту команду только на одном коммутаторе, а другой коммутатор узнает об этом автоматически через VTP. Поскольку транк еще не создан, отсутствует VTP связь между Sa и Sb:
Sa> (enable) set vlan 2 Vlan 2 configuration successful Sa> (enable)
Измените интерфейсы управления на VLAN 2.
Теперь переместите интерфейс управления на обоих коммутаторах в VLAN 2. Таким способом демонстрируется отсутствие связи между Sa и Sb перед установлением транка. Выполните команду set interface sc0 2 на каждом коммутаторе, чтобы переместить интерфейс sc0 в VLAN 2. Выполните команду show interface, чтобы проверить эффективность команды:
Sa> (enable) set interface sc0 2 Interface sc0 vlan set. Sa> (enable) show interface sl0: flags=51<UP,POINTOPOINT,RUNNING> slip 0.0.0.0 dest 0.0.0.0 sc0: flags=63<UP,BROADCAST,RUNNING> vlan 2 inet 10.0.0.1 netmask 255.0.0.0 broadcast 10.255.255.255 Sa> (enable)Проверьте, не нарушено ли соединение между двумя коммутаторами.
Теперь проверка связи командой ping 10.0.0.2 с коммутатором Sb дает отрицательный результат, подтверждая отсутствие соединения в VLAN 2 между двумя коммутаторами:
Sa> (enable) ping 10.0.0.2 no answer from 10.0.0.2 Sa> (enable)
Проверьте возможности порта.
Перед началом настройки транка, командой show port capabilities можно убедиться, что оба порта способны реализовать транкинг 802.1Q:
Sa> (enable) show port capabilities 5/24 Model WS-X5225R Port 5/24 Type 10/100BaseTX Speed auto,10,100 Duplex half,full Trunk encap type 802.1Q,ISL Trunk mode on,off,desirable,auto,nonegotiate Channel 5/23-24,5/21-24 Broadcast suppression percentage(0-100) Flow control receive-(off,on),send-(off,on) Security yes Membership static,dynamic Fast start yes Rewrite yes Sa> (enable)
Задайте инкапсуляцию транка 802.1Q.
Теперь необходимо настроить транк в Sa. Как видно на шаге 1 оба порта были в режиме транкинга по умолчанию auto, а тип инкапсуляции negotiate. Комбинация режимов auto-auto не устанавливает транк. Так и должно быть: каждая сторона готова стать транком, но сделает это лишь по запросу удаленной стороны. Принимая во внимание конфигурацию по умолчанию:
Необходимо всего лишь изменить режим транкинга на desirable на одной стороне, чтобы установить транк. По причине того, что порт в режиме desirable уведомляет своего соседа о желании перейти в режим транкинга. Поскольку удаленный порт (в режиме auto) переходит в состояние транкинга после получения запроса, этого достаточно для установления транка.
Если на подчиненном интерфейсе настроить инкапсуляцию dot1q, тогда VLAN невозможно будет вновь использовать в системе, поскольку внутренним образом 6500 или 7600 выделяют VLAN, а затем делают подчиненный интерфейс единственным членом этой сети. Таким образом невозможно иметь VLAN и пытаться использовать ее в подчиненном интерфейсе и наоборот. Чтобы устранить эту проблему, вместо подчиненных интерфейсов создайте порты транкинга и, таким образом, VLAN будет видна во всех интерфейсах. Если требуются подчиненные интерфейсы, тогда сети VLAN, добавленные в эти подчиненные интерфейсы, невозможно использовать в других портах.
Также нужно указать, какую инкапсуляцию следует использовать. Это нужно из-за того, что оба порта поддерживают ISL, и сначала выбирается эта инкапсуляция, когда обе стороны в режиме negotiate.
Синтаксис команды: set trunk модуль/порт [on | off | desirable | auto | nonegotiate] [vlan_range] [isl | dot1q | negotiate]. Выполните команду set trunk 5/24 dot1q desirable на коммутаторе Sa:
Sa> (enable) set trunk 5/24 dot1q desirable Port(s) 5/24 trunk mode set to desirable. Port(s) 5/24 trunk type set to dot1q. 1997 May 07 17:32:01 %DTP-5-TRUNKPORTON:Port 5/24 has become dot1q trunk 1997 May 07 17:32:02 %PAGP-5-PORTFROMSTP:Port 5/24 left bridge port 5/24 1997 May 07 17:32:13 %PAGP-5-PORTTOSTP:Port 5/24 joined bridge port 5/24
Убедитесь, что установлен транк.
Журнал консоли для предыдущей команды ясно показывает, что порт перешел в состояние транкинга, однако можно также выполнить команду show trunk 5/24 на Sa и команду show trunk 2/24 на Sb для проверки. Обратите внимание на небольшое различие между двумя примерами выходных данных:
Порт на Sa находится в режиме desirable, а порт на Sb находится в режиме auto.
Еще интереснее то, что инкапсуляция dot1q на Sa, тогда как на Sb — это n-dot1q. Это свидетельство того, что Sb согласовал свою инкапсуляцию с dot1q. Если не задана инкапсуляция на Sa, оба порта установят инкапсуляцию n-isl:
Sa> (enable) show trunk 5/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 5/24 desirable dot1q trunking 1 Port Vlans allowed on trunk -------- ----------------------------------------------------------- 5/24 1-1005 Port Vlans allowed and active in management domain -------- ----------------------------------------------------------- 5/24 1-2 Port Vlans in spanning tree forwarding state and not pruned -------- ----------------------------------------------------------- 5/24 1-2 Sa> (enable) Sb> (enable) show trunk 2/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 2/24 auto n-dot1q trunking 1 !--- Output suppressed.
При наличии результата выполнения команды show trunk на устройстве Cisco, можно воспользоваться средством интерпретации выходных данных Output Interpreter (только для зарегистрированных пользователей), чтобы выявить потенциальные проблемы и их местоположение.
Проверка соединения.
Можно убедиться, что VLAN 2 теперь проходит через транк, простой проверкой связи с Sb командой ping с Sa:
Sa> (enable) ping 10.0.0.2 10.0.0.2 is alive Sa> (enable)
Задание собственной VLAN
Выполните следующие действия.
Выполните команду set vlan.
Команда set vlan 2 5/24 используется для назначения порта конкретной сети VLAN. В случае порта транкинга он меняет собственную VLAN на VLAN 2. Разумеется аналогичную операцию необходимо выполнить на Sb командой set vlan 2 2/24 :
Sa> (enable) set vlan 2 5/24 VLAN 2 modified. VLAN 1 modified. VLAN Mod/Ports ---- ----------------------- 2 5/24 Sa> (enable)Теперь, до изменения собственной VLAN на Sb, имеется несоответствие между конфигурациями Sa и Sb. Две стороны транка имеют разные конфигурации собственной VLAN. На этом этапе на консоли Sb появляются некоторые предупредительные сообщения.
Примечание. Сообщать о несоответствии могут разные коммутаторы, в зависимости от того, какой коммутатор является корневым мостом для сетей VLAN 1 и 2.
Sb> (enable) 2000 Dec 07 16:31:24 %SPANTREE-2-RX_1QPVIDERR: Rcved pvid_inc BPDU on 1Q port 2/24 vlan 1. 2000 Dec 07 16:31:24 %SPANTREE-2-TX_BLKPORTPVID: Block 2/24 on xmtting vlan 2 for inc peer vlan. 2000 Dec 07 16:31:24 %SPANTREE-2-RX_BLKPORTPVID: Block 2/24 on rcving vlan 1 for inc peer vlan 2. Sb> (enable) Sb> (enable) set vlan 2 2/24 VLAN 2 modified. VLAN 1 modified. VLAN Mod/Ports ---- ----------------------- 2 2/24 Sb> (enable) 2000 Dec 07 16:31:46 %SPANTREE-2-PORTUNBLK: Unblock previously inc port 2/24 on vlan 1. 2000 Dec 07 16:31:48 %SPANTREE-2-PORTUNBLK: Unblock previously inc port 2/24 on vlan 2.
Несоответствие собственных VLAN было исправлено и все пришло в норму.
Проверьте результат.
Теперь просто проверьте результат выполнения этих команд для транка командой show trunk 5/24:
Sa> (enable) show trunk 5/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 5/24 desirable dot1q trunking 2 <
Задание сетей VLAN, разрешенных на транке
Выполните следующие действия.
Создайте дополнительные VLAN.
Вновь создаваемый транк по умолчанию содержит все сети VLAN, существующие в сети. Рассмотрим, как можно ограничить список разрешенных сетей VLAN для транка. Во-первых, необходимо создать две дополнительных сети VLAN (3 и 4). Например, чтобы создать дополнительные VLAN выполните команду set vlan 3 и команду set vlan 4 на Sa. Команду необходимо ввести только на одном коммутаторе, а VTP распространит эти изменения на другой коммутатор.
Примечание. Эта часть настройки одинакова независимо от используемой инкапсуляции: 802.1Q или ISL.
Sa> (enable) set vlan 3 Vlan 3 configuration successful Sa> (enable) set vlan 4 Vlan 4 configuration successful
Удаление VLAN из транка.
Команда clear trunk модуль/список портов vlan позволяет удалить одну или несколько VLAN из заданного транка. На данном этапе четыре созданных сети VLAN были определены на транке. Удалите VLAN 2 и VLAN 3 командой clear trunk 5/24 2-3 на Sa и командой clear trunk 2/24 2-3 на Sb. Проверьте результат выполнения команды clear командой show trunk 5/24. Теперь только сети VLAN 1 и 4 входят в транк между Sa и Sb. Проверка связи между Sa и Sb командой ping теперь дает отрицательный результат:
Sa> (enable) clear trunk 5/24 2-3 Removing Vlan(s) 2-3 from allowed list. Port 5/24 allowed vlans modified to 1,4-1005. Sa> (enable) show trunk 5/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 5/24 desirable dot1q trunking 2 Port Vlans allowed on trunk -------- --------------------------------------------------------- 5/24 1,4-1005 Port Vlans allowed and active in management domain -------- --------------------------------------------------------- 5/24 1,4 Port Vlans in spanning tree forwarding state and not pruned -------- --------------------------------------------------------- 5/24 1,4
Повторная активация VLAN.
Чтобы добавить VLAN обратно в транк, используйте команду set trunk модуль/список портов vlan.
Sa> (enable) set trunk 5/24 2 Adding vlans 2 to allowed list. Port(s) 5/24 allowed vlans modified to 1-2,4-1005. Sa> (enable) show trunk Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 5/24 desirable dot1q trunking 2 Port Vlans allowed on trunk -------- --------------------------------------------------------- 5/24 1-2,4-1005 Port Vlans allowed and active in management domain -------- --------------------------------------------------------- 5/24 1-2,4 Port Vlans in spanning tree forwarding state and not pruned -------- --------------------------------------------------------- 5/24 1-2,4
Теперь VLAN 2 вновь передается по транку. Проверка связи между Sa и Sb командой ping теперь дает положительный результат.
Разные собственные виртуальные локальные сети
Это распространенная ошибка конфигурации. На каждом конце транка 802.1Q должна быть настроена одинаковая собственная VLAN. Помните, что коммутатор при получении кадра без тега назначит его собственной VLAN транка. Если одна сторона настроена для собственной VLAN 1, а другая – для собственной VLAN 2, кадр, отправленный в VLAN 1 на одной стороне, будет получен VLAN 2 на другой стороне. Это приводит к объединению VLAN 1 и 2. Однако для этого нет никаких оснований, а следствием такого объединения могут быть проблемы с подключениями в сети.
Устройство Cisco, как правило, предупреждает о несоответствии собственной VLAN. Типы сообщений об ошибках, отображаемые в этом случае на консоли, см. в шаге 1 раздела Задание собственной VLAN. Всегда проверяйте, чтобы собственная VLAN была одинаковой в конфигурации транка на обоих коммутаторах.
Разные VTP домены
При создании транка между двумя коммутаторами и использовании DTP согласования перепроверьте, что настроен один и тот же VTP домен на обоих коммутаторах. Между двумя коммутаторами, находящимися в различных VTP доменах, согласование не осуществляется. В примере, приведенном в данном разделе, используется рабочая конфигурация транкинга, описанная выше.
Примечание. Даже если два коммутатора находятся в разных VTP доменах можно организовать связь между ними, вручную добавив сети VLAN на каждом коммутаторе. Несмотря на различие VTP доменов, связь по сети VLAN будет работать. Однако VTP обновления не распространяются по такому каналу на этой VLAN из-за различия доменов.
Sa в режиме транкинга desirable, инкапсуляция dot1q
Sb в режиме транкинга auto, инкапсуляция negotiate
Одна и та же собственная VLAN и одинаковые сети VLAN разрешены на каждой стороне
Единственным различием является то, что VTP домен «с» назначен на Sa, а VTP домен «cisco» назначен на Sb:
Sa> (enable) show trunk No ports trunking. Sa> (enable) show trunk 5/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 5/24 desirable dot1q not-trunking 1 Port Vlans allowed on trunk -------- ------------------------------------------------------------- 5/24 1-1005 Port Vlans allowed and active in management domain -------- ------------------------------------------------------------- 5/24 1 Port Vlans in spanning tree forwarding state and not pruned -------- ------------------------------------------------------------- 5/24 Sb> (enable) show trunk No ports trunking. Sb> (enable) show trunk 2/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 2/24 auto negotiate not-trunking 1 Port Vlans allowed on trunk -------- --------------------------------------------------------------- 2/24 1-1005 Port Vlans allowed and active in management domain -------- --------------------------------------------------------------- 2/24 1 Port Vlans in spanning tree forwarding state and not pruned -------- --------------------------------------------------------------- 2/24 Sb> (enable)
Видно, что транк не создан. При возникновении ошибки подобного типа проверьте VTP домен, настроенный на каждом коммутаторе. Выполните команду show vtp domain:
Sa> (enable) show vtp domain Domain Name Domain Index VTP Version Local Mode Password -------------------------------- ------------ ----------- ----------- ---------- c 1 2 server - Vlan-count Max-vlan-storage Config Revision Notifications ---------- ---------------- --------------- ------------- 8 1023 0 disabled Last Updater V2 Mode Pruning PruneEligible on Vlans --------------- -------- -------- ------------------------- 10.0.0.1 disabled disabled 2-1000 Sb> (enable) show vtp domain Domain Name Domain Index VTP Version Local Mode Password -------------------------------- ------------ ----------- ----------- ---------- cisco 1 2 server - Vlan-count Max-vlan-storage Config Revision Notifications ---------- ---------------- --------------- ------------- 8 1023 20 disabled Last Updater V2 Mode Pruning PruneEligible on Vlans --------------- -------- -------- ------------------------- 10.0.0.1 disabled disabled 2-1000
Теперь переместите коммутатор Sa в VTP домен «cisco» командой set vtp domain cisco. Через несколько секунд после согласования транк будет установлен вновь:
Sa> (enable) set vtp domain cisco VTP domain cisco modified Sa> (enable) 1997 May 13 13:59:22 %DTP-5-TRUNKPORTON:Port 5/24 has become dot1q trunk 1997 May 13 13:59:22 %PAGP-5-PORTFROMSTP:Port 5/24 left bridge port 5/24 1997 May 13 13:59:33 %PAGP-5-PORTTOSTP:Port 5/24 joined bridge port 5/24
Если нужно сохранить различные VTP домены, но при этом создать транк между двумя коммутаторами, необходимо запрограммировать транкинг на каждой стороне транка (используя nonegotiate/on).
Ошибка при удалении сетей VLAN расширенного диапазона из порта транка
При попытке удалить сети VLAN расширенного диапазона из порта транка командой clear trunk, на консоли коммутатора иногда возникает эта ошибка:
Failed to clear vlans in the extended range Maximum of 64 trunks can have non-default extended range vlan configuration. Use the 'set trunk' command to restore some existing entries to the default value.
Примечание. Термин расширенный диапазон подразумевает любую сеть VLAN в диапазоне 1025-4094. Термин стандартный расширенный диапазон по умолчанию подразумевает все сети VLAN в диапазоне 1025-4094. При попытке удалить любую VLAN в диапазоне 1025-4094, сеть VLAN становится нестандартного расширенного диапазона. Максимальное число транков, входящих в нестандартный расширенный диапазон составляет 64. К ним относятся неактивные и активные транки.
Эта ошибка и ограничение числа транков значением 64 обусловлены блоком энергонезависимого ОЗУ, используемого для хранения нестандартных конфигураций для сетей VLAN расширенного диапазона. Чтобы увидеть все транки, настроенные с нестандартными расширенными диапазонами, выполните команду show trunk extended-range. По умолчанию конфигурация целиком хранится в энергонезависимом ОЗУ. Энергонезависимое ОЗУ имеет различные «блоки» для хранения нестандартных конфигураций. Эти блоки распределяются по разным категориям, например глобальный или модульный. Блок, содержащий нестандартную конфигурацию для расширенных диапазонов, ограничен 64 транками.
Имеется два способа уменьшить число транков нестандартного расширенного диапазона. Первый способ заключается в настройке любых портов неактивных/неиспользуемых транков обратно для стандартных разрешенных сетей VLAN. Используйте команду set trunk модуль/порт 1025-4094. После чего команда clear trunk модуль/порт 1025-4094 должна выполняться для расширенных сетей VLAN. Второй способ состоит в изменении режима конфигурирования с двоичного (по умолчанию) на текстовый. Командой set config mode text можно изменить режим конфигурирования на текстовый. Текстовый режим обычно использует меньший объем энергонезависимого ОЗУ или флэш-памяти по сравнению с двоичным режимом конфигурирования.
Примечание. При работе в режиме настройки текстового файла большинство пользовательских настроек сразу не сохраняются в энергонезависимом ОЗУ; изменения конфигурации записываются только в динамическое ОЗУ. Необходимо выполнить команду write memory, чтобы сохранить конфигурацию в энергонезависимой памяти. Командой set config mode text auto-save можно автоматически сохранить текстовую конфигурацию в энергонезависимом ОЗУ.
Режим транкинга несовместим с типом инкапсуляции
Об этой распространенной проблеме центру технической поддержки Cisco известно с момента начала поставок первых модулей с поддержкой 802.1Q и ISL. Пользователи привыкли к настройке транка командой set trunk модуль/порт on или set trunk модуль/порт nonegotiate. Проблема в том, что по умолчанию задан тип инкапсуляции negotiate. Инкапсуляцию типа negotiate поддерживают только режимы auto или desirable транкинга. Типы on и nonegotiate инкапсуляции не выполняют никаких согласований между коммутаторами и должны жестко задаваться для инкапсуляции ISL или 802.1Q при настройке. Ниже приведена запись журнала о том, что происходит в коммутаторе в этом случае:
Sa> (enable) set trunk 5/24 on Failed to set port 5/24 to trunk mode on. Trunk mode 'on' not allowed with trunk encapsulation type 'negotiate'. Sa> (enable) set trunk 5/24 nonegotiate Failed to set port 5/24 to trunk mode nonegotiate. Trunk mode 'nonegotiate' not allowed with trunk encapsulation type 'negotiate'. Sa> (enable)
Это имеет смысл, поскольку если нет согласования с удаленным портом, как узнать тип инкапсуляции (802.1Q или ISL), который нужно использовать, чтобы создать транк? Имеется две возможности:
Использовать режим desirable. В этом случае происходит согласование режима инкапсуляции с удаленным портом:
Sa> (enable) set trunk 5/24 desirable Port(s) 5/24 trunk mode set to desirable. Sa> (enable) 1997 May 09 17:49:19 %DTP-5-TRUNKPORTON:Port 5/24 has become isl trunk
Задание инкапсуляции, которую следует использовать:
Sa> (enable) set trunk 5/24 isl on Port(s) 5/24 trunk mode set to on. Port(s) 5/24 trunk type set to isl. Sa> (enable) 1997 May 09 17:50:16 %DTP-5-TRUNKPORTON:Port 5/24 has become isl trunk
Перечень команд
Рефакторинг поля в свойство — Visual Studio (Windows)
- Чтение занимает 2 мин
В этой статье
Область применения этого рефакторинга:
Что? Эта возможность позволяет включить поле в свойство и обновлять все случаи использования этого поля, чтобы применить созданное свойство.
Когда? Требуется переместить поле в свойство и обновить все ссылки на это поле.
Зачем? Вы хотите предоставить другим классам доступ к полю, но не хотите давать им прямой доступ. Заключив поле в свойство, можно написать код для проверки присваиваемого значения.
Практическое руководство
Выделите имя типа, который требуется инкапсулировать, или поместите в него текстовый курсор:
C#:
Visual Basic:
Затем выполните одно из следующих действий.
- Клавиатура
- Нажмите клавиши CTRL+R, а затем — CTRL+E. (Обратите внимание, что сочетание клавиш может отличаться в зависимости от выбранного профиля.)
- Нажмите клавиши CTRL+ . чтобы активировать меню Быстрые действия и рефакторинг. Затем во всплывающем окне предварительного просмотра выберите пункт Инкапсулировать поле.
- Мышь
- Последовательно выберите Правка >Рефакторинг > Инкапсулировать поле.
- Щелкните код правой кнопкой мыши и выберите меню Быстрые действия и рефакторинг. Затем во всплывающем окне предварительного просмотра выберите пункт Инкапсулировать поле.
Выбор Описание Инкапсулировать поле (и использовать свойство) Инкапсулирует поле со свойством и обновляет все случаи использования поля, чтобы применить созданное свойство. Инкапсулировать поле (но продолжать использовать поле) Инкапсулирует поле со свойством, но оставляет без изменений все случаи использования поля. Свойство создается, а ссылки на поле обновляются, если они выбраны.
Совет
Перейдите по ссылке Просмотреть изменения, чтобы узнать, каким будет результат, прежде чем зафиксировать его.
C#:
Visual Basic:
- Клавиатура
См. также раздел
Angular — Вид инкапсуляции — В угловых,компонент CSS стили инкапсулированы в вид компонента и не влияют на ос
В угловых,компонент CSS стили инкапсулированы в вид компонента и не влияют на остальную часть приложения.
Чтобы контролировать, как происходит инкапсуляция для каждого компонента , вы можете установить режим инкапсуляции представления в метаданных компонента. Выберите один из следующих режимов:
ShadowDomпредставления ShadowDom использует собственную реализацию теневой DOM браузера (см. Теневой DOM на сайте MDN ) для присоединения теневой DOM к элементу узла компонента, а затем помещает представление компонента внутри этой теневой DOM. Стили компонента включены в теневой DOM.Emulatedинкапсуляция представления (по умолчанию) имитирует поведение теневой модели DOM путем предварительной обработки (и переименования) кода CSS для эффективного применения CSS к представлению компонента. Дополнительные сведения см. В разделе Проверка сгенерированного CSS ниже.Noneозначает, что Angular не просматривает инкапсуляцию. Angular добавляет CSS к глобальным стилям. Обсуждаемые ранее правила области видимости, изоляции и защиты не применяются. По сути это то же самое, что и вставка стилей компонента в HTML.
Чтобы установить режим инкапсуляции компонента, используйте свойство encapsulation в метаданных компонента:
// warning: few browsers support shadow DOM encapsulation at this time encapsulation: ViewEncapsulation.ShadowDom
ShadowDom представления ShadowDom работает только в браузерах, которые имеют встроенную поддержку теневого DOM (см. Shadow DOM v1 на сайте Могу ли я использовать ). Поддержка все еще ограничена, поэтому инкапсуляция Emulated представления является режимом по умолчанию и рекомендуется в большинстве случаев.
Проверка сгенерированных CSS
При использовании эмулированной инкапсуляции вида,угловая препроцессорная обработка всех стилей компонентов таким образом,чтобы они приближались к стандартным правилам CSS-диапазона теней.
В DOM работающего углового приложения с включенной инкапсуляцией эмулированного вида каждый элемент DOM имеет некоторые дополнительные атрибуты:
<hero-details _nghost-pmm-5>
<h3 _ngcontent-pmm-5>Mister Fantastic</h3>
<hero-team _ngcontent-pmm-5 _nghost-pmm-6>
<h4 _ngcontent-pmm-6>Team</h4>
</hero-team>
</hero-detail>Существует два вида генерируемых атрибутов:
- Элемент, который будет теневым DOM-хостом в собственной инкапсуляции, имеет сгенерированный атрибут
_nghost. Обычно это относится к элементам хоста компонента. - Элемент в представлении компонента имеет атрибут
_ngcontent, который определяет, какому эмулируемому теневому DOM хоста принадлежит этот элемент.
Точные значения этих атрибутов не важны. Они генерируются автоматически, и вы никогда не должны ссылаться на них в коде приложения. Но они нацелены на сгенерированные стили компонентов, которые находятся в разделе <head> DOM:
[_nghost-pmm-5] {
display: block;
border: 1px solid black;
}
h4[_ngcontent-pmm-6] {
background-color: white;
border: 1px solid #777;
}Эти стили подвергаются _nghost обработке, поэтому каждый селектор дополняется селекторами атрибутов _nghost или _ngcontent . Эти дополнительные селекторы активируют правила области видимости, описанные на этой странице.
Taski Procarpet 30 — Ковромоечная машина 2 в 1 (для экстракции и инкапсуляции)
Основные характеристики
- Надежность и высокая производительность
- Многофункциональность
- Низкая стоимость в использовании
- Простота использования
Надежность и высокая производительность
Как и всё профессиональное уборочное оборудование TASKI, машина TASKI procarpet 30 разработана с учетом самых высоких требования к надежности и эффективности. Отличная всасывающая способность машины в сочетании с оптимальными химическими средствами обеспечивают максимальную эффективность при уходе за коврами.
Многофункциональность
TASKI procarpet 30 позволяет пользователям выбирать тот метод уборки, который наиболее полно отвечает требованиям, с учетом доступного времени на уборку и уровня загрязнения.
Машина может быть установлена в режим глубокой чистки (экстракции) при сильных загрязнениях, либо в режим промежуточной уборки (инкапсуляция) благодаря которому ковры сохнут всего за 1,5-2 часа!
Низкая стоимость в использовании
Новая машина позволяет контролировать выполнение всех задач по уходу за коврами и выбирать метод ухода в зависимости от поставленных задач. Проведение промежуточной уборки позволяет продлить время между глубокой чисткой (экстракцией), дольше сохраняя привлекательный вид коврового покрытия и не требуя увеличения времени высыхания.
Простота использования
Для переключения режима работы машины с экстрации на инкапсуляцию необходимо заменить щетку и моющее средство, а также переключить тумблер режима уборки на приборной панели. Оптимальная точка баланса и эргономичность машины позволяет оператору работать длительное время без усталости и напряжения.
Широкий ассортимент доплнительных аксессуаров и принадлежностей позволяет решать различные задачи по уборке. Машина может дополнительно комплектоваться инструментом для уборки в труднодоступных местах, таких как углы и пространство под столом.
С комплектом аксессуаров в который входит: шланг до 6м, трубка (3 секции) и насадка для впрыска/сбора раствора возможно проводить уборку номерного фонда отелей без заезда машины в номера.
Щетки к машине Taski Procarpet 30 приобретаются отдельно.
Высокая мощность 3 Вт теплый белый свет СИД высокий cri светодиодные чипы инкапсуляции режим купольного света бисера
1. Могу ли я получить скидку для навального заказа?
Да, если вам нужен заказ на большую партию товара или вы хотите заказной продукции, мы можем предоставить оптовую цену.
2. Можно ли быть уверенным, учитывайте это перед размещением заказа?
Если вы хотите оформить заказ, пожалуйста, не стесняйтесь, чтобы отправить нам запрос по электронной почте или свяжитесь с нами через менеджера по продажам для украшений ручной работы, мы ответим вам в течение 24 часов (за исключением рабочий день).
3. Какие способы оплаты доступны?
T/T(PayPal), Western Union, и защищенную систему оплаты предпочтительны.
4. Есть ли у вас мы работаем с прямыми поставками и сколько стоит доставка?
Да, мы работаем с прямыми поставками. Вы должны оставить приемник информацию вашего заказа, когда вы размещаете заказ, тогда мы отправим вам товары в соответствии с заказом по адресу, который вы оставили. Стоимости доставки исходя из ваших вещей в вашем заказе объем и вес, а также его можно рассчитать.
5. Все изображения являются реальными фотографиями?
Да, все фотографии реальные фото фотографии всех товаров на этой странице, 100%-это настоящие снимки по нашей вине.
6. Что вы можете сказать по поводу качества светодиодных?
С нами можно связаться следующими способами не беспокоиться о том, что в качестве нашей продукции. Наша компания является основным производителем светодиодных ламп в Китае. Вся наша продукция экспортируется по всему миру с 2009 года.
7. Есть ли какие-либо таможенные пошлины и налог на импорт?
В связи с использованием различных политики в разных странах, там могут быть некоторые таможенные пошлины и налоги на импорт, но это не считается в цене и должны быть оплачены вами. Мы не несем ответственности за какие-либо таможенные пошлины и налог на импорт.
Если вам нужны другие светодиодные лампы, пожалуйста, найдите его на нашем веб-сайте:
#
encapsulation-mode
Используйте encapsulation-mode, чтобы установить режим инкапсуляции, который протокол безопасности использует для инкапсуляции IP-пакетов.
Используйте режим отмены инкапсуляции, чтобы восстановить значение по умолчанию.
Синтаксис
режим инкапсуляции {транспорт | туннель}
отменить режим инкапсуляции
По умолчанию
IP-пакеты инкапсулируются в туннельном режиме.
Представления
Представление набора преобразований IPsec
Предопределенные роли пользователей
network-admin
Параметры
transport: Использует транспортный режим для инкапсуляции IP-пакетов.
туннель: использует туннельный режим для инкапсуляции IP-пакетов.
Руководство по использованию
IPsec поддерживает следующие режимы инкапсуляции:
T ransport mode — Протоколы безопасности защищают данные верхнего уровня IP-пакета. Для вычисления заголовков протокола безопасности используются только данные транспортного уровня. Вычисленные заголовки протокола безопасности и зашифрованные данные (только для инкапсуляции ESP) помещаются после исходного IP-заголовка.Вы можете использовать транспортный режим, когда требуется сквозная защита безопасности (защищенная начальная и конечная точки передачи являются фактическими начальной и конечной точками данных). Транспортный режим обычно используется для защиты связи между хостами.
T unnel mode —Протоколы безопасности защищают весь IP-пакет. Весь IP-пакет используется для вычисления заголовков протокола безопасности. Вычисленные заголовки протокола безопасности и зашифрованные данные (только для инкапсуляции ESP) инкапсулируются в новый IP-пакет.В этом режиме инкапсулированный пакет имеет два заголовка IP. Внутренний заголовок IP — это исходный заголовок IP. Внешний заголовок IP добавляется сетевым устройством, предоставляющим услугу IPsec. Вы должны использовать туннельный режим, когда защищенная начальная и конечная точки передачи не являются фактическими начальной и конечной точками пакетов данных (например, когда два шлюза предоставляют IPsec, но начальная и конечная точки данных находятся на двух хостах позади шлюзов). Туннельный режим обычно используется для защиты связи от шлюза к шлюзу.
Наборы преобразований IPsec на обоих концах туннеля IPsec должны иметь одинаковый режим инкапсуляции.
Примеры
# Настроить набор преобразований IPsec tran1 для использования транспортного режима для инкапсуляции IP-пакетов.
системное представление [Sysname] ipsec transform-set tran1 [Sysname-ipsec-transform-set-tran1] транспорт в режиме инкапсуляции
Связанные команды
ipsec transform-set
Тип инкапсуляции — обзор
Любой старый концентратор, коммутатор или маршрутизатор (Wellfleet, Bay, Nortel, Synoptic и т. Д.) может быть широковещательным или многоадресным трафиком, включая пакеты BOFL. Если вы не уверены, посмотрите коды Ethertype в кадре, чтобы выяснить, что вы захватили.
Любой сервер, на котором работает протокол информации о маршрутизации (RIP) или, что еще хуже, серверы Novell, выступающие в качестве маршрутизаторов с протоколом Network Link Services (NLSP) или RIP для обмена пакетами Интернета (IPX). Отключите маршрутизацию сервера Novell, если она не нужна, и добавьте статический маршрутизатор (шлюз по умолчанию) в Inetcfg.nlm, чтобы устранить этот трафик.
Серверы и другие устройства, использующие SNMP, который не нужен. Я обнаружил, что серверы и другие устройства все еще указывают на давно удаленную NMS, а также обнаружил, что устройства не опрашивают абсолютно ничего. Все это трафик, генерируемый в вашей сети.
Серверы с несколькими протоколами, привязанными к их интерфейсным картам.
Клиенты Novell с автоматическим определением типа кадра, установленным на «авто.«Это действительно плохо, потому что по сути каждый загружающийся клиент Novell должен транслировать на сервер, чтобы узнать, какой тип кадра он должен использовать. Это для каждого клиента в вашей сети… это может складываться.
Избегайте использования нескольких типов инкапсуляции для IPX; широковещательные передачи будут распространяться для каждого типа, используемого в вашей сети. Вы можете привязать к серверам несколько типов инкапсуляции, и это увеличивает накладные расходы.
Отключите протокол связующего дерева (STP) на любом порту, который не подключен или никогда не будет подключен к другим концентраторам или коммутаторам.(Будьте осторожны, чтобы кто-то не подключил его без вашего ведома, иначе у вас возникнут проблемы!)
Старое оборудование, которое неисправно, как дребезжащая сетевая карта, может создать много нежелательного трафика в вашей сети. Что еще хуже, он может выполнять сброс кольца на Token Rings и поднимать линии ISDN, если он не настроен должным образом. Следите за проблемными устройствами, которые необходимо отремонтировать или заменить.
Хосты, настроенные с помощью AppleTalk (AppleShare), остались в прошлом.В большинстве случаев вы можете настроить компьютеры Mac на использование IP, но во многих случаях AppleTalk остается на месте по всей сети. Думаете, это не создает проблем с трафиком? Используйте Sniffer Pro, и вы удивитесь, сколько трафика все еще проходит через AppleTalk.
Клиенты с запущенным общим доступом к файлам и принтерам (или серверной службой) являются основными участниками широковещательной передачи. Да, эта простая конфигурация для включения общего доступа к файлам и принтерам или включения службы сервера дает вашим клиентам право совместно использовать папки и принтеры и действовать как сервер, но вы также разрешили этому клиенту участвовать в службе браузера.Посетите главу 4, чтобы увидеть множество проблем, связанных с тем, чтобы это произошло.
Клиенты с поддержкой NetBIOS также являются огромными фанатами широковещательной передачи и пропускной способности. Поскольку хост в сети использует NetBIOS, он работает как протокол на основе широковещательной передачи. Без использования WINS-сервера у вас будут серьезные проблемы с широковещательной передачей с этим протоколом. Используйте WINS-сервер и, если можете, отключите этого монстра протокола, если это возможно.
Клиенты с несколькими настроенными протоколами, такими как IPX и NetBEUI, также проблематичны по двум причинам: порядок привязки замедляет работу клиента, а несколько протоколов, использующих средства связи на основе широковещательной передачи, добавят больше трафика в ваш сегмент сети, который с другими устройствами иметь дело.Когда вы привязываете несколько протоколов к вашей сетевой карте, вы можете передавать только по одному протоколу за раз, и, что еще хуже, существует предпочтительный порядок привязки. На рис. 12.12 можно увидеть (и исправить) проблему с порядком привязки, выполнив следующие действия:
- 1.
Откройте свойства сети (в Windows 2000), выбрав Пуск | Настройки | Панель управления | Сеть и коммутируемое соединение .
- 2.
В верхней части диалогового окна «Сеть и удаленное подключение» выберите пункт меню Advanced и выберите в меню Advanced Settings .
- 3.
Откроется диалоговое окно, показанное на рисунке 12.16. После открытия просмотрите перечисленные протоколы и убедитесь, что протокол, который вы используете чаще всего, находится в верхней части порядка привязки. Вы можете изменить порядок с помощью стрелок справа от диалогового окна.
Рисунок 12.16. Просмотр порядка связывания для рабочей станции Windows 2000 Professional
Метод и его состав для инкапсуляции, стабилизации и доставки миРНК в анионный полимерный наноплекс: оценка in vitro-in vivo
Динамическое рассеяние света (DLS), SEM , TEM и AFM
Подготовленные и оптимизированные наноплексы были определены для размера частиц, индекса полидисперсности (PDI) и дзета-потенциала с помощью Zetasizer (Nano-ZS90, Malvern Instruments, Вустершир, Великобритания).Вкратце, суспензия наноплекса была разбавлена сверхчистой водой, и образец был измерен под фиксированным углом (обратное рассеяние 173 °). С помощью электрофоретического анализатора дзета-потенциал наноплекса измеряли с помощью Zetasizer (Nano-ZS90, Malvern Instruments, Вустершир, Великобритания). Все образцы были измерены при 25 ± 2 ° C, и измерения были выполнены в трех экземплярах для оценки эффективности результатов.
Размер и морфология частиц полученного наноплекса определяли после лиофилизации с помощью сканирующей электронной микроскопии (SEM) с использованием микроскопа JSM-7001FA (JEOL, Токио, Япония).Водная суспензия наноплекса держалась на кремниевой пластине, которая прилипала к металлическому штырю. После этого подложку сушили в вакууме и покрывали слоем золота толщиной 20 нм. Шлейфы наблюдались при излучении 5,0 кВ с рабочим расстоянием 9,5–10,5 мм 51 . Далее морфологию DTsiANp проводили с помощью просвечивающего электронного микроскопа (ТЕМ; Philips, Tecnai 20, Голландия; ускоряющее напряжение: 200 кВ; увеличение: 40000 ×). Размер DTsiANp измеряли с помощью программного обеспечения AnalySIS (Soft Imaging Systems, Ройтлинген, Германия).Капля разбавленного наноплекса удерживалась на медной сетке с углеродным покрытием. Образец окрашивали 1% об. Водным раствором фосфорновольфрамовой кислоты и отставляли для впитывания. После высыхания образец сфокусировался, и были сделаны изображения 52 . Кроме того, атомно-силовая микроскопия (зонд: SCANASYST-AIR (диапазон модуля: <20 МПа; номинальное значение k ~ 0,4 Н / м, типичный радиус наконечника <10 нм), АСМ; Bruker Multimode 8, Bruker, США) также была проведена для ДЦиАНп 53 . После характеристики наноплекса присутствие интактного альбумина в приготовленных ANp, DTANp, siANp и DTsiANp оценивали с помощью SDS-PAGE и набора для анализа реагентов BCA.Дендримерная матрица была дополнительно подтверждена в наноплексе с помощью анализа TNBSA, и изменения поверхностного заряда через дзета-потенциал представлены в дополнительном файле.
Определение эффективности инкапсуляции миРНК наноплекса миРНК с помощью анализа задержки геля
Связывание миРНК и эффективность инкапсуляции d : соотношение siR с siANp и DTsiANp определяли с помощью электрофореза в агарозном геле. Вкратце, голая миРНК была взята в качестве контроля, а несвязанная миРНК от siANp и DTsiANp была отделена с помощью VivaSpin (порог молекулярной массы: 50 кДа; GE Healthcare, Thermo Scientific, США) при 16000 g в течение 10 минут при 4 ° C. .Супернатант собирали и осадок повторно диспергировали в воде, не содержащей нуклеазы, обработанной DEPC (Ambion, США). Затем суспензию наноплекса и супернатант (10 мкл) смешивали с 5 мкл (6X) загрузочного красителя и доводили до конечного объема 15 мкл, используя воду, не содержащую нуклеаз, обработанную DEPC (Ambion, США). Приготовленную композицию наносили на 2% -ный (масс. / Об.) Агарозный гель и прогоняли через трис-боратный (ТВЭ) (40 мМ Трис-HCl, 1% об. / Об. Уксусная кислота, 1 мМ ЭДТА) буфер при 80 В. Электрофоретическая подвижность анализировали гелем, окрашенным бромидом этидия, с использованием ультрафиолетового (УФ) осветителя (GelDoc, Bio-Rad, США) 2 .Кроме того, фактическая инкапсуляция миРНК внутри наноплекса была подтверждена с помощью анализа защиты миРНК. Протокол эксперимента, как указано в дополнительном материале.
Определение эффективности захвата миРНК наноплексом миРНК с помощью анализа Ribogreen
Кроме того, подтверждение инкапсуляции миРНК определяли по количеству экстрагированной миРНК из лиофилизированных DTsiANp и siANp в соответствии с протоколом, описанным Cun et al . с небольшой модификацией 54 .Для анализа точно навески (1,5 мг) лиофилизированных наноплексов солюбилизировали в 150 мкл хлороформа с 500 мкл буфера ТЕ. Для извлечения миРНК из органической фазы в водную смесь перемешивали и непрерывно вращали при 25 ± 2 ° C в течение примерно 90 мин. Затем смесь центрифугировали при 16000 g в течение 25 мин при 4 ° C для разделения водной и органической фаз. Остатки хлороформа удаляли инкубацией супернатанта при 37 ± 2 ° C в течение 5 мин. Затем супернатанты разбавляли буфером TE и концентрацию миРНК измеряли с помощью реагента Ribogreen (Thermo Scientific, США) в соответствии с инструкциями производителя через многомодовый планшет-ридер (длина волны возбуждения: 485 нм и длина волны испускания: 520 нм; Varioskan LUX Multimode, Thermo Fisher Scientific, Массачусетс, США).Анализ всех образцов проводили в трех экземплярах. Инкапсуляцию миРНК рассчитывали, используя фактическую массу миРНК (нг) в наноплексе на всю массу наноплекса (мг). Кроме того, инкапсуляция миРНК в наноплекс также была рассчитана с помощью данного уравнения следующим образом:
$$ siRNA \, encapsulation = \ frac {loading \, of \, siRNA} {theoratical \, loading \, of \, миРНК} $$
(1)
Сывороточная стабильность siRNA nanoplex
siRNA оказалась нестабильной в сыворотке из-за сывороточных нуклеаз, поэтому после захвата соотношения siR d: стабильность siRNA в присутствии сыворотки была проверена как для siANp, так и для DTsiANp со ссылкой к голой миРНК, как указано в протоколе Tarantula et al .с небольшой модификацией 55 . Для анализа брали голую миРНК (260 нг / лунку миРНК; 10 мкМ), 1,5 мг (эквивалентно 260 нг / лунку миРНК) siANp и DTsiANp. Наноплексы и голую миРНК инкубировали с равным объемом (50 мкл) RPMI 1640, содержащего 10% об. / Об. Фетальной бычьей сыворотки (FBS), при 37 ± 0,5 ° C. Через определенный интервал времени, т.е. 0, 1, 2, 4, 6 и 24 часа, аликвоты центрифугировали при 21000 g в течение 15 минут при 4 ° C. Супернатант удаляли и поддон хранили при -20 ° C до проведения гель-электрофореза.Через 24 часа сбора образцов стабильность миРНК оценивали с помощью гель-электрофореза. Для этого аликвоты (10 мкл) смешивали с 5 мкл (6X) загрузочного красителя и приготовленную композицию наносили на 2% -ный (вес / объем) агарозный гель и прогоняли через 1X TBE (трис-борат) (40 мМ трис-HCl. , 1% об. / Об. Уксусная кислота, 1 мМ EDTA) при 80 В. Электрофоретическую подвижность анализировали за счет бромида этидия с использованием ультрафиолетового (УФ) осветителя (GelDoc, Bio-Rad, США).
Кроме того, влияние сыворотки на размер частиц, PDI и поверхностный дзета-потенциал также оценивали для того, чтобы siAN и DTsiANp были инкубированы с равным объемом RPMI 1640, содержащим 10% об. / Об. Концентрацию сыворотки при 37 ± 0.5 ° С. В заранее определенные моменты времени 0, 1, 2, 4, 6 и 24 часа размер частиц, PDI и дзета-потенциал поверхности измеряли с помощью Zetasizer Nano ZS90 (Malvern Instruments, UK). Все эксперименты проводили в трех повторностях при 37 ± 0,5 ° C 51 .
Эндо / лизосомная тенденция к ускользанию развитой миРНК Nanoplex
Аминогруппа, представленная на концевом конце дендримера, была чувствительна к эндосомному pH (кислому) 41 . Поэтому, чтобы понять влияние pH окружающей среды (физиологический и эндосомный pH) на siANp и DTsiANp обрабатывали фосфатным буферным солевым раствором (pH 7.4), натрий-ацетатный буфер (pH 5; эндосомный pH) и ацетатный буфер (pH 4,5; поздний эндосомный pH) для оценки стабильности. Протокол соблюдался так же, как сообщала наша группа ранее, с небольшими поправками 41 . Оптимизированные ANp и DTANp инкубировали с различным буфером в течение 0, 1, 2, 4, 6 и 24 часов. Размер частиц, PDI и дзета-потенциал наноплексов проверяли в заранее определенные моменты времени с помощью Zetasizer Nano ZS90 (Malvern Instruments, UK) для оценки стабильности наноплексов.Влияние pH микроокружения на простой альбумин и дендример также оценивали с точки зрения дзета-потенциала в различный временной интервал с помощью Zetasizer Nano ZS90. Все эксперименты проводили в трех повторностях при 25 ± 2 ° C. Кроме того, эндо / лизосомальная ускользающая активность наноплекса оценивалась с помощью красного красителя лизо-трекера на подоцитах, обработанных HG, и протокол был таким, как обсуждалось в дополнительном разделе ( см. Дополнительный материал ).
Анализ жизнеспособности клеток для выяснения биосовместимости разработанной siRNA nanoplex
Первоначально подоциты почек человека предназначались для размножения клеток в 25 см 3 Т-колба в полной среде RPMI 1640 (содержала 10% об / об FBS, 0.5% об. / Об. Инсулин-трансферрин-селен (ITS) и 1% об. / Об. Смесь пенициллин-стрептомицин и антибиотик) при 33 ± 0,5 ° C с 5% CO 2 до слияния 60–80% . После этого клетки были переведены на температуру 37 ± 0,5 ° C с 5% CO 2 для дифференцировки на 10–14 дней. Свежую среду давали клеткам три раза в неделю 56,57 . Эти дифференцированные клетки использовали для каждого эксперимента. После дифференцировки клетки подоцитов человека высевали в 96-луночные планшеты (1 × 10 4 клеток / лунку) и давали возможность расти в течение ночи в полной среде RPMI 1640 при 37 ± 0.5 ° C с 5% CO 2 . Затем клетки обрабатывали HG (30 мМ) для индукции in vitro модели DN в течение 48 часов. После этого для лечения использовали эквивалентное количество ANp, DTANp, siANp и DTsiANp (0,625 мг; 1 пмоль siRNA / лунку и инкубировали в течение 24 ч. После этого МТТ (3- (4,5-диметилтиазол-2-ил) -2,5-дифенилтетразолий бромид) добавляли к клеткам (20 мкл; 5 мг / мл) и инкубировали еще 4 часа при 37 ± 0,5 ° C с 5% CO 2 58 . Раствор МТТ был заменен с 100 мкл ДМСО для растворения кристаллов формазана.Необработанные клетки были взяты в качестве контроля со 100% жизнеспособностью клеток. Оптическую плотность измеряли при 575 нм с помощью УФ-ридера для микропланшетов (Multiscan GO, Thermo Fisher Scientific, Массачусетс, США) при 37 ± 0,5 ° C. Жизнеспособность клеток рассчитывалась следующим образом: 59 .
$$ Ячейка \, жизнеспособность (\%) = \ frac {Абс \, (образец)} {Абс \, (контроль)} \ times 100 \% $$
(2)
Поглощение клетками наноплекса миРНК в модели DN подоцитов HG
Для оценки интернализации анализ клеточного поглощения проводили на подоцитах, обработанных HG, в соответствии с протоколом, описанным Huang et al .с небольшой модификацией 60 . Дифференцированные клетки подоцитов высевали в 6-луночный планшет (2 × 10 5 клеток / лунку) с помощью покровного стекла. Клетки обрабатывали высоким содержанием глюкозы (30 мМ; HG) 31 в течение 48 часов в присутствии среды RPMI 1640 с нарушенной сывороткой (1% об. / Об. FBS) 61 для создания модели in vitro DN. Среду заменяли на Opti-MEM, содержащую DTsiANp, нагруженную FAM-миРНК (30 пмоль миРНК / лунку; 10 мкМ). Через 12 часов клеточное распределение миРНК наблюдали с помощью конфокальной микроскопии (максимальное возбуждение: 494 нм; максимальное излучение: 520 нм, Leica Microsystems, Вецлар, Германия) 60 .
Эффективность подавления гена: количественная ОТ-ПЦР
ПЦР в реальном времени была проведена для оценки эффективности подавления HDAC4 наноплекса, нагруженного HDAC4. Дифференцированные клетки подоцитов выращивали в 6-луночных планшетах (2 × 10 5 клеток / лунку) в полной среде RPMI 1640 до достижения 60% слияния. Затем среду удаляли и инкубировали с HG (30 мМ), содержащей среду RPMI 1640 с нарушенной сывороткой (1% об. / Об. FBS), в течение 48 часов 61 . После этого в среду добавляли Opti-MEM, содержащий DTsiANp / HDAC4 (~ 30 пмоль миРНК / лунку), и инкубировали в течение 24 часов.Здесь DTsiANp / Scramble выбран в качестве отрицательного контроля. После обработки суммарную РНК экстрагировали с помощью мини-набора RNeasy (Qiagen, Hilden, Германия), как указано в протоколе производителя, и количественно определяли с помощью спектрофотометра Nanodrop-2000 (Thermo Fisher Scientific, Массачусетс, США). КДНК получали с помощью набора для синтеза кДНК iscript (Bio-Rad, Калифорния, США). Затем экспрессию гена HDAC4 количественно оценивали с помощью разведения кДНК 1:10 с использованием супермикса iScript SYBR green (Bio-Rad, Калифорния, США) с помощью StepOne Real-time PCR (Applied Biosystems, Калифорния, США).Праймеры KiCqStart для ПЦР были использованы для амплификации 18 с (прямой: 5′-GTAACCCGTTGAACCCCATT-3 ‘и обратный: 5′-CCATCCAATCGGTAGTAGCG-3′) и гена HDAC4 (прямой: 5’-AGTGTCGACCTCCTATATAACTACTCCTCCTCTACTACTCCA-3 ‘и обратный: 5’-GCC -3 ′). Уровень экспрессии HDAC4 анализировали по значениям Ct (порог цикла). Эксперимент проводили в трех повторностях 62 .
Экспрессия HDAC4 по данным вестерн-блоттинга:
In vitro и in vivoДля оценки экспрессии HDAC4 в клетках подоцитов и мышиной модели был проведен вестерн-блоттинг.После дифференцировки подоцитов клетки высевали в 6-луночные планшеты (2 × 10 5 клеток / лунку) в полной среде RPMI 1640 и обрабатывали HG (30 мМ) в среде с нарушенной сывороткой (среда RPMI 1640 с 1% об. / Об. FBS. ) в течение 48 часов 31 . DTsiANp / HDAC4 (30 пмоль / лунка siRNA; 6,5 мг наноплекс) и DTsiANp / Scramble обрабатывали в течение 48 часов. Белок экстрагировали и лизат ресуспендировали в буфере для лизиса RIPA, содержащем 1 мкл коктейля ингибиторов протеазы. Концентрацию белка в клетках и тканях подоцитов оценивали с помощью реагента BCA.Белок (25 мкг) отделяли с помощью SDS-PAGE (акриламидный гель 10%) и переносили через PVDF-мембрану с помощью набора RTA Trans Turbo (Bio-Rad, США). Затем проводили определение специфического белка с использованием инкубации с первичным антителом против (HDAC4 1: 1000, Abcam, Кембридж, Великобритания) и (β-актин 1: 5000, Santacruz, США) при 4 ° C в течение ночи. После завершения инкубации с первичным антителом мембрану промывали 0,1% TBST после инкубации с HRP-конъюгированным вторичным антителом ((козий антимышиный IgG-HRP 1: 20000, Santacruz и козий антикроличий IgG-HRP 1: 20000, Abcam ) при комнатной температуре в течение 2 часов.Детектирование полос осуществляли с помощью субстрата хемилюминесценции (Bio-Rad, США). Кроме того, интенсивность полосы была определена количественно с помощью программного обеспечения ImageJ (NIH, Bethesda, MD).
Для in vivo вестерн-блот-анализа здоровые почки мышей, STZ-индуцированные DN контрольных мышей и обработанные наноплексом почки гомогенатировали с использованием лизатора тканей (Tissue Lyser LT, Qiagen, Германия) и центрифугировали (12000 g в течение 5 минут) для определения оставшейся ткани. удаление. Собранный супернатант использовали для экстракции белка и измерения содержания белка с использованием реагента BCA, а вестерн-блоттинг-анализ выполняли, как упомянуто выше.
Анализ гемосовместимости
Для оценки биосовместимости наноплекс был проведен анализ гемосовместимости 41,51 . Вкратце, кровь крыс брали в гепаринизированные флаконы (5000 МЕ / мл, Himedia, Mumbai, India), центрифугировали при 1000 g в течение 10 минут для поддона для эритроцитов. Осадок промывали 0,9% масс. / Об. Физиологическим раствором (5X). Для экспериментов готовили 2% об. / Об. Раствор эритроцитов. Раствор эритроцитов инкубировали с ANp, DTANp (концентрации дендримеров 1, 2,5 и 5 мкг / мл), физиологическим раствором (0% гемолиз; отрицательный контроль) и Triton X-100 (0.1% об. / Об.) (100% гемолиз; положительный контроль) в течение 2 часов при 37 ± 0,5 ° C для взаимодействия. Через 2 часа суспензию центрифугировали при 1000 g в течение 10 минут и супернатант, полученный в каждой группе, анализировали на содержание гемоглобина по оптической плотности при 540 нм с использованием УФ-считывающего устройства для микропланшетов (Varioskan LUX Multimode, Thermo Fisher Scientific, Массачусетс, США). Процент гемолиза определяли с помощью следующего уравнения:
$$ \% Гемолиз = 100 \ times \ frac {(Abs.Sample-Abs.Negative \, Control)} {(Abs.Положительный \, Контроль-Абс. Отрицательный \, Ccontrol)} $$
(3)
, где Абс. Образец взорвался на поглощение образца, поглощение отрицательного контроля (0,9% масс. / Об. Физиологического раствора), поглощение положительного контроля (Тритон-X).
Модель экспериментального животного и лечение
Все исследования на животных проводились в соответствии с руководящими принципами и протоколами Национального института фармацевтического образования и исследований (NIPER) по уходу и использованию лабораторных животных.Все процедуры и протоколы, использованные в этом исследовании, были одобрены институциональным комитетом по этике животных (IAEC) в NIPER-Ahmedabad, Гуджарат, Индия, см. Номер письма об одобрении: NIPER-A / IAEC / 2017/034. Самцам мышей C57BL / 6 (средняя масса тела: 18–23 г) (Поставщик: Исследовательский центр Zydus, Ахмедабад) внутрибрюшинно в течение 5 дней подряд вводили 50 мг / кг стрептозотоцина (STZ) (0,1 М цитратный буфер (pH 4,5)). чтобы избежать острой токсичности СТЗ Контрольным животным вводили только цитратный буфер.Подтверждение наличия диабета осуществляли по уровням глюкозы в крови в хвостовой вене (глюкоза натощак> 12 ммоль; глюкометр Accu Chek-Active, Roche, США). Мышей случайным образом разделили на экспериментальную группу (в каждой группе по шесть мышей). Всех мышей умерщвляли через 4 недели после инъекции голой миРНК HDAC4, DTsiANp / scramble, DTsiANp / HDAC4 мышам с диабетом. Разработанный наноплекс миРНК вводили мышам через хвостовую вену в дозе 1 мг / кг дважды в неделю. После обработки из свежесобранной почки клубочковую часть отделяли от половины почки и гомогенерировали с помощью лизатора тканей (TissueLyser LT, Qiagen, Германия), затем центрифугировали (12000 g в течение 5 мин) для удаления остатков ткани.Супернатант собирали для экстракции белка для Вестерн-блоттинга 63 . Другая половина была зафиксирована в формалине для гистологической оценки клубочков. После завершения лечения концентрации альбумина в моче измеряли с помощью набора ELISA для мышиного альбумина (ab108792, Abcam, Кембридж, Великобритания) и представляли как коэффициент экскреции альбумина с мочой (UAER) 64 .
Гистопатологический анализ почек
Изолированная ткань почки была взята для гистологического исследования, зафиксирована в 4% параформальдегиде и залита парафином.Срезы толщиной 5 мкм обрабатывали для окрашивания гематоксилином и эозином в соответствии с протоколом производителя. Морфологическая оценка и полуколичественный анализ среза были выполнены для гломерулярной области на предмет повреждения клубочков с использованием программного обеспечения ImageJ. Зону клубочков определяли с помощью программного обеспечения ImageJ с использованием 15 случайных изображений области коры на мышь под полем зрения с низким увеличением (400 ×) 65 .
Статистический анализ
Результаты представлены как среднее ± S.D или среднее ± SEM. Статистические различия между группами оценивали с помощью одностороннего дисперсионного анализа (ANOVA) для анализа данных in vitro, и , in vivo, . После этого пост-тест Бонферрони был применен ко всей паре столбцов с контролем. p <0,05 считалось значимым. Статистический анализ проводился с помощью Graph Pad Prism (программное обеспечение GraphPad, SPSS, Чикаго, Иллинойс, США).
rfc4717
Сетевая рабочая группа L.мартини
Запрос комментариев: 4717 Дж. Джаякумар
Категория: Отслеживание стандартов Cisco Systems, Inc.
М. Боччи
Alcatel
Н. Эль-Аавар
Уровень 3 Коммуникации, ООО
Дж.Брейли
ECI Telecom Inc.
Г. Колейни
Nortel Networks
Декабрь 2006 г.
Методы инкапсуляции для транспортировки
Асинхронный режим передачи (ATM) по сетям MPLS
Статус этой памятки
Этот документ определяет протокол отслеживания стандартов Интернета для
Интернет-сообщество и просит обсуждения и предложения по
улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
Официальные стандарты протокола »(STD 1) для состояния стандартизации
и статус этого протокола. Распространение этой памятки не ограничено.
Уведомление об авторских правах
Авторские права (C) IETF Trust (2006 г.).
Абстрактный
Псевдопровод (PW) асинхронного режима передачи (ATM) используется для передачи
Ячейки ATM по сети MPLS. Это позволяет поставщикам услуг
предлагать "эмулированные" услуги ATM по существующим сетям MPLS. Этот
документ определяет методы инкапсуляции ячеек ATM в
псевдопровод.Он также определяет процедуры использования PW для
предоставлять услуги банкомата.
Мартини и др. Стандарты Track [Страница 1]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
Оглавление
1. Введение ............................................... ..... 3
2. Спецификация требований ................................... 4
3. Заявление о применимости ......................................... 4
4.Терминология ................................................. .... 4
5. Общий метод инкапсуляции .................................... 6
5.1. Управляющее слово ........................................... 6
5.1.1. Общее контрольное слово ............................ 7
5.1.2. Предпочтительное управляющее слово .......................... 8
5.1.3. Установка поля порядкового номера в
Слово управления ........................................ 9
5.2.Требования к MTU ........................................... 9
5.3. Битовое значение MPLS Shim S ..................................... 10
5.4. Значения TTL прокладки MPLS ...................................... 10
6. Применимость режима инкапсуляции ............................... 10
6.1. Режим ATM N-to-One Cell ....................................... 11
6.2. Инкапсуляция ячеек ATM "один-к-одному" ......................... 13
6.3. Инкапсуляция кадра SDU AAL5 ............................. 13
6.4. Инкапсуляция кадра PDU AAL5 ............................. 14
7. Поддержка ячеек ATM OAM ........................................... 15
7.1. Корпус VCC ................................................ ..15
7.2. Корпус VPC ................................................ ..16
7.3. Режим эмуляции ячейки OAM SDU / PDU ........................... 16
7.4. Работа с дефектами ........................................... 17
8. Режим ATM N-to-One Cell ........................................ 0,18
8.1. Инкапсуляция услуг ATM N-to-One ........................ 19
9. Режим ATM One-to-One Cell ....................................... 21
9.1. Инкапсуляция услуг ATM One-to-One ..................... 21
9.2. Порядковый номер ........................................... 22
9.3. Служба передачи ячеек ATM VCC ............................ 22
9.4. Услуги ATM VPC .......................................... 24
9.4.1. Услуги передачи ячеек ATM VPC .................... 25
10.Режим ATM AAL5 CPCS-SDU ........................................ 26
10.1. Прозрачная инкапсуляция кадра SDU AAL5 ................. 27
11. Режим кадра AAL5 PDU ........................................... 28
11.1. Прозрачная инкапсуляция кадра PDU AAL5 ................. 28
11.2. Фрагментация ............................................ 30
11.2.1. Процедуры в направлении ATM-PSN ............ 30
11.2.2. Процедуры в направлении PSN-ATM ............31
12. Сопоставление классов обслуживания ATM и PSN ..................... 31
13. Поддержка ILMI .............................................. .... 32
14. Под-TLV параметров интерфейса, специфичных для ATM ..................... 32
15. Контроль перегрузки ............................................ 32
16. Соображения безопасности ....................................... 33
17. Нормативные ссылки .......................................... 34
18. Информационные ссылки ........................................ 34
19. Существенные участники ...................................... 36
Мартини и др. Стандарты Track [Страница 2]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
1. Введение
Сети с коммутацией пакетов (PSN) могут снизить
сложность инфраструктуры поставщика услуг, позволяя
практически любой существующий цифровой сервис, который будет поддерживаться через один
сетевая инфраструктура.Преимущество этой модели для сервиса
провайдер состоит из трех частей:
-я. Использование существующих систем и услуг для предоставления
увеличенная пропускная способность ядра с коммутацией пакетов.
-ii. Сохранение существующих сетевых операционных процессов и
процедуры, используемые для поддержки унаследованных сервисов.
-iii. Использование общей сетевой инфраструктуры с коммутацией пакетов для
поддерживать как основные требования к мощности существующих
услуги и требования новых услуг поддерживаются
изначально через сеть с коммутацией пакетов.В этом документе описывается метод передачи услуг ATM через MPLS. Это
перечисляет специфические требования ATM и предоставляет форматы инкапсуляции
и семантика для подключения граничных сетей ATM через пакетный
коммутируемая сеть с использованием MPLS.
На рисунке 1 ниже показана эталонная модель услуг банкомата. Этот
модель адаптирована из [RFC3985].
| <----- Псевдопровод -----> |
| |
| | <- Туннель PSN -> | |
Обслуживание банкомата V V V V Обслуживание банкомата
| + ---- + + ---- + |
+ ---- + | | PE1 | ================== | PE2 | | + ---- +
| | ---------- |.| Provider Edge 1 Provider Edge 2 |
| |
| <-------------- Эмулированная служба ----------------> |
Заказчик Заказчик
Край 1 Край 2
Рисунок 1: Эталонная модель услуги ATM
Мартини и др. Стандарты Track [Страница 3]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
2.Спецификация требований
Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
«ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
документ следует интерпретировать, как описано в [RFC2119].
3. Заявление о применимости
Услуга ATM over PW не предназначена для идеальной имитации
традиционный сервис банкоматов, но его можно использовать для приложений, которые
нужна транспортная услуга банкомата.
Ниже приведены заметные различия между традиционными услугами банкоматов.
и протокол, описанный в этом документе:
- Порядок ячеек банкомата можно сохранить с помощью ДОПОЛНИТЕЛЬНОЙ последовательности
поле в контрольном слове; однако реализации не
требуется для поддержки этой функции.Использование этой функции может
влияют на другие обязательства по обеспечению качества обслуживания (QoS) банкоматов.
- Модель QoS для традиционных банкоматов может быть эмулирована. Однако
подробная спецификация эмуляции QoS ATM выходит за рамки
этого документа. Эмуляция должна обеспечивать
требуемые обязательства ATM QoS для приложения конечного пользователя.
- Механизмы управления потоком ATM прозрачны для MPLS
сеть и не может отражать статус сети MPLS.- Поддержка уровня управления для SVC, SVP, SPVC и SPVP ATM есть
выходит за рамки этого документа.
Обратите внимание, что инкапсуляции, описанные в этой спецификации, являются
идентичны описанным в [Y.1411] и [Y.1412].
4. Терминология
Режим «один к одному»: указывает метод инкапсуляции, который отображает один банкомат.
Соединение виртуального канала (VCC) (или одно соединение виртуального пути ATM
(VPC)) в один псевдопровод.
Режим N-к-одному (N> = 1): определяет метод инкапсуляции, который отображает
один или несколько VCC ATM (или один или несколько VPC ATM) к одному псевдопроводу.Сеть с коммутацией пакетов (PSN): сеть IP или MPLS.
Pseudowire Emulation Edge to Edge (PWE3): механизм, который имитирует
основные атрибуты услуги (например, выделенная линия T1 или
Frame Relay) через PSN.
Мартини и др. Стандарты Track [Страница 4] RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. Клиентская граница (CE): устройство, с которого исходит один конец службы. и / или прекращается. CE не знает, что он использует эмулированный сервис, а не родной сервис.Provider Edge (PE): устройство, которое предоставляет PWE3 для CE. Псевдопровод (PW): соединение между двумя PE, передаваемое через PSN. PE обеспечивает адаптацию между CE и PW. Pseudowire PDU: PDU, отправленный на PW, который содержит все данные. и управляющая информация, необходимая для предоставления желаемой услуги. Туннель PSN: туннель, внутри которого могут быть вложены несколько PW, чтобы они прозрачны для основных устройств PSN. Ограничение PSN: направление трафика, в котором передается информация от CE. адаптированы к PW, и блоки PW-PDU отправляются в PSN.CE Bound: направление трафика, в котором PW-PDU принимаются на PW. из PSN, преобразованы обратно в эмулируемую службу и отправлены в CE. Вход: точка, в которой служба банкомата инкапсулируется в псевдопроводный PDU (направление от ATM к PSN). Выход: точка, в которой услуга банкомата декапсулируется из псевдопроводный PDU (направление от PSN к ATM). CTD: Задержка передачи клеток. MTU: Максимальный блок передачи. SDU: блок служебных данных. OAM: Эксплуатация и техническое обслуживание.PVC: постоянное виртуальное соединение. ATM-соединение, которое предоставляется через интерфейс управления сетью. Связь не сигнализируется. VCC: подключение виртуального канала. Коммутируемое соединение ATM на основе VCI заголовка ячейки. VPC: подключение по виртуальному пути. Коммутируемое соединение ATM на основе VPI заголовка ячейки. Дополнительная терминология, относящаяся к псевдопроводам и виртуальному уровню 2. Частные сети (L2VPN) в целом можно найти в [RFC4026].Мартини и др. Стандарты Track [Страница 5]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
5. Общий метод инкапсуляции
В этом разделе описан общий формат инкапсуляции для ATM over
Псевдопроводы PSN.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок псевдопроводов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Управляющее слово банкомата |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Полезная нагрузка службы банкоматов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 2: Общий формат инкапсуляции ATM по сетям PSN
Заголовок транспорта PSN зависит от конкретного туннелирования.
используемая технология.Этот заголовок используется для транспортировки инкапсулированного
Информация ATM через ядро с коммутацией пакетов.
Заголовок Pseudowire идентифицирует конкретную услугу ATM на
туннель. В случае MPLS заголовок псевдопроводной сети - это один или несколько MPLS.
метки внизу стека меток MPLS.
Слово управления ATM вставляется перед полезной нагрузкой службы ATM. Это
может содержать длину и порядковый номер в дополнение к определенным
управляющие биты, необходимые для выполнения услуги.
5.1. Контрольное слово
Контрольные слова, определенные в этом разделе, основаны на общем PW.
Управляющее слово MPLS, как определено в [RFC4385].Они дают возможность
чтобы упорядочить отдельные кадры на PW, избегая равных затрат
многопутевая балансировка нагрузки (ECMP) [RFC2992] и механизмы OAM
включая VCCV [VCCV].
[RFC4385] гласит: «Если PW чувствителен к изменению порядка пакетов и
переносится через MPLS PSN, который использует содержимое MPLS
полезная нагрузка для выбора пути ECMP, она ДОЛЖНА использовать механизм, который
предотвращает неправильную сортировку пакетов ». Это необходимо, потому что ECMP
реализации могут проверять первый полубайт после метки MPLS
стек, чтобы определить, является ли помеченный пакет IP.Таким образом,
если VPI соединения ATM передается через PW с использованием N-to-one
инкапсуляция в режиме ячейки без контрольного слова начинается с
0x4 или 0x6, его можно принять за пакет IPv4 или IPv6. Этот
Мартини и др. Стандарты Track [Страница 6]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
может, в зависимости от конфигурации и топологии MPLS
сети, привести к ситуации, когда все пакеты для данного PW не
следуйте по тому же пути.Это может увеличить количество неупорядоченных кадров на
задан PW, или заставить пакеты OAM следовать по пути, отличному от фактического
трафик (см. раздел 4.4.3 о порядке кадров).
Функции, предоставляемые контрольным словом, могут не понадобиться для
дан ATM PW. Например, ECMP может отсутствовать или быть активным на
в сети MPLS строгая последовательность кадров может не потребоваться и т. д.
Если это так, и контрольное слово не ТРЕБУЕТСЯ
режим инкапсуляции для других функций (таких как длина или
транспортировка специфической информации протокола ATM), контрольное слово
имеет небольшую ценность и поэтому является ДОПОЛНИТЕЛЬНЫМ.Ранний ATM PW
были развернуты реализации, которые не включают контрольное слово
или возможность обработать один, если он есть. Чтобы помочь в обратном
совместимость, будущие реализации ДОЛЖНЫ иметь возможность отправлять и
получать кадры без контрольного слова.
Во всех случаях выходной PE ДОЛЖЕН знать, что входящий PE
отправит контрольное слово над конкретным PW. Это может быть достигнуто
конфигурация PE или сигнализация, как определено в [RFC4447].
Если псевдопровод пересекает сетевое соединение, требующее минимум
размер кадра (практический пример - Ethernet) с минимальным кадром
размером 64 октета, то такие ссылки будут применять заполнение к
pseudowire PDU для достижения минимального размера кадра.В этом случае
управляющее слово должно включать поле длины, равное длине PDU. А
требуется, чтобы выходной PE обнаруживал и удалял такие
обивка.
5.1.1. Общее контрольное слово
Это управляющее слово используется в следующих режимах инкапсуляции:
- Режим ATM One-to-one Cell
- Режим кадра AAL5 PDU
Документ контрольного слова PWE3 [RFC4385] предоставляет следующее
структура для общего контрольного слова:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Задается инкапсуляцией PW |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Мартини и др.Стандарты Track [Страница 7]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
Подробная структура режима ATM One-to-one Cell Mode и
Режим кадра PDU AAL5 выглядит следующим образом:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Resvd | Порядковый номер | Специфические для банкоматов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
На приведенной выше диаграмме первые 4 бита ДОЛЖНЫ быть установлены в 0, чтобы указать
Данные PW.Они ДОЛЖНЫ игнорироваться принимающим PE.
Следующие четыре бита зарезервированы и ДОЛЖНЫ быть установлены в 0 при
передача и игнорируется при приеме.
Следующие 16 бит обеспечивают порядковый номер, который можно использовать для
гарантия доставки заказанного пакета. Обработка последовательности
числовое поле НЕОБЯЗАТЕЛЬНО.
Пространство порядковых номеров - это 16-битное круговое пространство без знака. В
значение порядкового номера 0 используется, чтобы указать, что порядковый номер
алгоритм проверки не используется.
Последние 8 бит обеспечивают пространство для переноса специфичных для ATM флагов.Эти
определены ниже в деталях протокола.
Поле длины для ячейки "один-к-одному" не требуется.
и режимы кадра PDU, поскольку PDU PSN всегда больше 64
байты; следовательно, в каналах Ethernet в PSN заполнение не применяется.
5.1.2. Предпочтительное контрольное слово
Это управляющее слово используется в следующих режимах инкапсуляции:
- Режим ATM N-to-one Cell
- Режим кадра SDU AAL5
Это определяется следующим образом:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Флаги | Res | Длина | Порядковый номер |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
На приведенной выше диаграмме первые 4 бита ДОЛЖНЫ быть установлены в 0, чтобы указать
Данные PW.Они ДОЛЖНЫ игнорироваться принимающим PE.
Мартини и др. Стандарты Track [Страница 8] RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. Следующие 4 бита предоставляют пространство для переноса специфичных для протокола флагов. Они определены ниже в деталях, относящихся к конкретному протоколу. Следующие 6 бит обеспечивают поле длины, которое используется следующим образом: Если длина пакета (определяется как длина полезной нагрузки уровня 2 плюс длина управляющего слова) меньше 64 байтов, Поле длины ДОЛЖНО быть установлено равным длине пакета.В противном случае поле длины ДОЛЖНО быть установлено в ноль. Значение поля длины, если ненулевое значение, может использоваться для удаления любого отступа. Когда пакет достигает выходной маршрутизатор поставщика услуг, может быть желательно удалить заполнение перед пересылкой пакета. Обратите внимание, что поле длины не используется в режиме N-к-одному и ДОЛЖЕН быть установлен в 0. Последние 16 бит обеспечивают порядковый номер, который можно использовать для гарантия доставки заказанного пакета. Обработка последовательности числовое поле НЕОБЯЗАТЕЛЬНО.Пространство порядковых номеров - это 16-битное круговое пространство без знака. В значение порядкового номера 0 используется, чтобы указать, что порядковый номер алгоритм проверки не используется. 5.1.3. Установка поля порядкового номера в контрольном слове Этот раздел применяется к полю порядкового номера как в Generic и предпочтительные контрольные слова. Для данного эмулируемого виртуального канала и пары маршрутизаторов PE1 и PE2, если PE1 поддерживает последовательность пакетов, затем процедуры последовательности, определенные в [RFC4385] ДОЛЖЕН использоваться.Пакеты, полученные не по порядку, МОГУТ быть отброшены или переупорядочены в усмотрение получателя. Простое расширение алгоритма обработки в [RFC4385] МОЖЕТ быть используется для обнаружения потерянных пакетов. Если PE-маршрутизатор согласился не использовать порядковый номер приема обработки, и он получил ненулевой порядковый номер, то он СЛЕДУЕТ отправить сообщение о состоянии PW, указывающее на ошибку приема и отключить PW. 5.2. Требования к MTU Сеть ДОЛЖНА быть настроена с MTU, достаточным для транспортировать самые большие рамы инкапсуляции.Если MPLS используется в качестве протокол туннелирования, например, это может быть 12 или более байтов больше, чем самый большой размер кадра. Другие протоколы туннелирования могут иметь более длинные заголовки и требовать больших MTU. Если вход Мартини и др. Стандарты Track [Страница 9]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
маршрутизатор определяет, что инкапсулированный PDU уровня 2 превышает MTU
туннель, через который он должен быть отправлен, PDU ДОЛЖЕН быть отброшен.Если выходной маршрутизатор получает инкапсулированный PDU уровня 2, чей
длина полезной нагрузки (т. е. длина самого PDU без каких-либо
заголовки инкапсуляции) превышает MTU целевого уровня 2
интерфейс, PDU ДОЛЖЕН быть отброшен.
5.3. Битовое значение прокладки S MPLS
Маршрутизатор с коммутацией меток входа (LSR), PE1, ДОЛЖЕН установить бит S
метку PW на значение 1, чтобы обозначить, что метка VC находится на
нижняя часть стека. Для получения дополнительной информации о настройке S-бита см.
[RFC3032].5.4. Значения TTL прокладки MPLS
Установка значения TTL на этикетке PW - это приложение
зависимый. В любом случае, процедура обработки TTL [RFC3032],
включая обработку истекших TTL, НЕОБХОДИМО соблюдать.
6. Применимость режима инкапсуляции
В этом документе определены два метода инкапсуляции ячеек ATM:
а именно, режим "один-к-одному" и режим "N-к-одному".
Режим N-to-One (N> = 1) определяет метод инкапсуляции, который
сопоставляет один или несколько VCC ATM (или один или несколько VPC ATM) одному
псевдопровод.Это единственный ОБЯЗАТЕЛЬНЫЙ режим. Один формат используется для
как VCC, так и VPC сопоставление с туннелем. 4-октетный заголовок ATM
неизменен в инкапсуляции; таким образом, VPI / VCI присутствует всегда.
Ячейки из одного или нескольких VCC (или одного или нескольких VPC) могут быть
соединены.
Режим "один к одному" определяет метод инкапсуляции, который сопоставляет один
ATM VCC или один ATM VPC к одному псевдопроводу. Для VCC VPI / VCI
не включено. Для VPC VPI не включается. Ячейки из одного VCC
или один VPC может быть объединен.Этот режим НЕОБЯЗАТЕЛЬНЫЙ.
Кроме того, для ATM поддерживаются различные ДОПОЛНИТЕЛЬНЫЕ инкапсуляции.
Транспортный протокол AAL5: один для блоков ATM AAL5 SDU, а другой - для блоков ATM AAL5 PDU.
Описанные инкапсуляции поддерживают три модели развертывания.
в этом документе:
-я. Одиночное соединение ATM: PW переносит ячейки только одного
ATM VCC или VPC. Это поддерживает как транспортировку
мультисервисное обслуживание ATM и L2VPN через PSN для всех AAL
типы.
Мартини и др.Стандарты Track [Страница 10]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
-ii. Несколько подключений ATM: PW переносит ячейки нескольких
ATM VCC и / или VPC. Это также поддерживает как транспортную
мультисервисного ATM и сервиса L2VPN через PSN для всех AAL
типы.
-iii. AAL5: PW переносит кадры AAL5 только одного ATM VCC. А
большая часть данных, передаваемых в сетях банкоматов,
на основе кадров и поэтому использует AAL5.Отображение AAL5 занимает
преимущество разграничения фреймов более высокого уровня в
Уровень ATM для повышения эффективности использования полосы пропускания по сравнению с
с базовым картированием ячеек. Характер услуги, поскольку
определяется категорией обслуживания ATM [TM4.0] или ATM
возможность передачи [I.371], должна быть сохранена.
6.1. Режим ATM N-to-One Cell
Эта инкапсуляция поддерживает как одиночный, так и множественный банкомат.
Модели развертывания подключения. Эта инкапсуляция НЕОБХОДИМА.Инкапсуляция позволяет переносить несколько VCC / VPC в пределах одного
одиночная псевдопроволока. Однако поставщик услуг может пожелать предоставить
один VCC к псевдопроводу, чтобы удовлетворить QoS или восстановление
требования.
Инкапсуляция также поддерживает привязку нескольких VCC / VPC к
одиночный псевдопровод. Эта возможность полезна, чтобы делать больше
эффективное использование пространства заголовка демультиплексирования PW, а также
упрощение предоставления услуг VCC / VPC.
В простейшем случае эту инкапсуляцию можно использовать для передачи
одна ячейка ATM на PDU PSN.Однако для обеспечения лучшего PSN
эффективность полосы пропускания, несколько ячеек ATM могут опционально
инкапсулированы в один блок PDU PSN. Этот процесс называется клеточным
конкатенация.
Инкапсуляция имеет следующие атрибуты:
-я. Поддерживает все типы уровня адаптации ATM.
-ii. Незавершенные ячейки OAM / Admin транспортируются между
пользовательские ячейки в том же порядке, в котором они были получены. Этот
требование позволяет использовать различную производительность
приложения для управления и безопасности.Мартини и др. Стандарты Track [Страница 11]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
-iii. Чтобы повысить эффективность транспортировки в сети PSN, несколько
ячейки могут быть инкапсулированы в один PW PDU. Этот процесс
называется объединением ячеек. Сколько ячеек вставить или
как долго ждать прибытия ячейки перед отправкой PW PDU
решение о реализации.Объединение ячеек увеличивает задержку
и изменение задержки для услуги ретрансляции соты.
-iv. Бит CLP из каждой ячейки может быть сопоставлен с соответствующим
маркировка на PDU PW. Это позволяет отбрасывать приоритет
сохраняться через PSN.
-v. Если используется модель развертывания соединения Single ATM, то
проще предоставить услугу уровня ATM. Природа
услуги в соответствии с категорией услуги банкомата
[TM4.0] или возможность передачи ATM [I.371], должна быть
сохранились.
Ограничения инкапсуляции ячеек ATM N-to-one:
-vi. В настоящее время нет определенного метода для перевода
прямая индикация перегрузки (EFCI) к соответствующему
функции в PSN. Также нет возможности перевести PSN
перегрузка EFCI при передаче выходным PE.
-vii. Контрольная сумма заголовка ячейки ATM может обнаруживать 2-битную ошибку или
обнаружение и исправление однобитовой ошибки в заголовке ячейки.Аналогичной функциональности нет в большинстве сетей PSN. А
однобитовая ошибка в PW PDU, скорее всего, вызовет
пакет, который должен быть отброшен из-за контрольной последовательности кадра L2 (FCS)
отказ.
-viii. Ячейки могут быть объединены из нескольких VCC или VPC.
принадлежность к разным категориям услуг и QoS
требования. В этом случае пакет PSN должен получить
обработка PSN для поддержки наивысшего QoS банкомата
Поставляются VCC / VPC.-ix. Инкапсуляция ячеек поддерживает только двухточечную метку
Коммутируемые пути (LSP). Многоточечный и двухточечный
многоточечные - подлежат дальнейшему изучению (FFS).
-Икс. Количество объединенных ячеек ATM ограничено MTU.
размер и задержка передачи ячейки (CTD) и задержка ячейки
вариации (CDV) нескольких соединений ATM, которые
мультиплексируются в один PW.
Мартини и др. Стандарты Track [Страница 12]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
6.2. Инкапсуляция ячеек ATM "один-к-одному"
Эта ДОПОЛНИТЕЛЬНАЯ инкапсуляция поддерживает одиночное соединение ATM.
модель развертывания.
Как и режим инкапсуляции ячеек N-to-one, режим One-to-one
поддерживает конкатенацию ячеек. Преимущество такой инкапсуляции:
что он использует меньшую полосу пропускания, чем инкапсуляция N-к-одному, для
заданное количество сцепленных ячеек. Поскольку только один ATM VCC или VPC
переносится на PW, VCI и / или VPI ATM VCC или VPC могут быть
полученный из контекста PW с использованием метки PW.Эти поля
поэтому не нужно инкапсулировать для VCC, и только VCI
должен быть инкапсулирован для VPC. Таким образом, такая инкапсуляция позволяет
провайдеры услуг для достижения более высокой эффективности использования полосы пропускания в PSN
ссылок, чем инкапсуляция N-к-одному для данного количества
сцепленные ячейки.
Применяются ограничения vi, vii, ix и x режима N-к-одному.
6.3. Инкапсуляция кадра SDU AAL5
Эта ДОПОЛНИТЕЛЬНАЯ инкапсуляция поддерживает модель AAL5. Этот режим
позволяет транспортировать ATM AAL5 CSPS-SDU, путешествующих по определенному
Постоянный виртуальный канал ATM через сеть к другому постоянному виртуальному каналу ATM.Эта инкапсуляция
используется PW типа 0x0002 "ATM AAL5 SDU VCC transport" как выделено
в [RFC4446].
Инкапсуляция AAL5 SDU более эффективна для небольших SDU AAL5, чем
инкапсуляции клеток VCC. В свою очередь, это более эффективный
альтернатива службе сотовой ретрансляции при переносе [RFC2684] -
инкапсулированные IP PDU через PSN.
Инкапсуляция AAL5-SDU требует сегментации и повторной сборки (SAR)
на ATM-интерфейсе PE-CE. Эта функция SAR обеспечивается общими
готовые аппаратные компоненты.После повторной сборки AAL5-SDU
переносится через псевдопровод к выходному PE. В этом заключается еще один
преимущество инкапсуляции AAL5-SDU.
Ограничения инкапсуляции AAL5 SDU:
-я. Если ячейка ATM OAM получена на входном PE, она отправляется
перед ячейками окружающего кадра AAL5. Следовательно,
Может произойти переупорядочение ячеек OAM, что может вызвать
Мониторинг производительности OAM и приложения безопасности ATM для
работают неправильно.Мартини и др. Стандарты Track [Страница 13]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
-ii. Если PDU ALL5 зашифрован с использованием стандартов безопасности ATM,
PE не сможет извлечь ALL5 SDU, и поэтому
весь PDU будет удален.
-iii. CRC PDU AAL5 не передается через PSN. КПР
поэтому должен быть регенерирован на выходном PE, поскольку CRC
имеет сквозное значение для безопасности банкоматов.Это означает
что CRC AAL5 не может использоваться для точной проверки
ошибки на сквозном ATM VCC.
-iv. Длина кадра AAL5 может превышать MTU PSN.
Это требует фрагментации, которая может быть недоступна для
все узлы в конечной точке PW.
-v. Этот режим не сохраняет значение бита CLP для
каждая ячейка ATM в PDU AAL5. Следовательно, прозрачность
настройки CLP могут быть нарушены. Кроме того, добавление тегов
некоторых ячеек может произойти, если теги не разрешены
определение соответствия [TM4.0].
-vi. Этот режим не сохраняет состояние EFCI для каждого банкомата.
ячейка в PDU AAL5. Следовательно, прозрачность
Состояние EFCI может быть нарушено.
6.4. Инкапсуляция кадра PDU AAL5
Эта ДОПОЛНИТЕЛЬНАЯ инкапсуляция поддерживает модель AAL5.
Основное приложение, поддерживающее инкапсуляцию кадра AAL5 PDU
через PSN - это прозрачная передача служб уровня ATM, которые используют
AAL5 для переноса кадров более высокого уровня. Главное преимущество этого AAL5
режим заключается в том, что он прозрачен для ATM OAM и безопасности ATM
Приложения.Одним из важных соображений является возможность обработки информации OAM.
как в оригинальной сети. Этот режим инкапсуляции позволяет это
прозрачность при выполнении инкапсуляции кадра AAL5. Этот режим
поддерживает фрагментацию, которая может выполняться для сохранения
положение ячеек OAM по отношению к пользовательским ячейкам.
Фрагментация также может выполняться для сохранения размера
пакет, содержащий PDU AAL5 в пределах MTU канала.
Фрагментация позволяет PE установить размер PW.
значение пакета отличается от значения исходного PDU AAL5.Этот
означает, что PE имеет контроль над задержкой и джиттером, предоставленными для
Ячейки банкоматов.
Мартини и др. Стандарты Track [Страница 14]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
Весь AAL5-PDU инкапсулирован. В этом случае все необходимое
параметры, такие как CPCS-UU (индикатор CPCS User-to-User), CPI
(Индикатор общей части), длина (длина CPCS-SDU) и CRC
(Cyclic Redundancy Check), транспортируются как часть полезной нагрузки.Обратите внимание, что перенос полного PDU также позволяет упростить
операция фрагментации, поскольку она выполняется на границах ячеек
и CRC в трейлере AAL5 PDU можно использовать для проверки
целостность PDU.
Повторная сборка не требуется на выходном PE для соединения PSN-ATM.
направление.
Ограничения v и vi режима AAL5 SDU применяются к этому режиму как
хорошо.
7. Поддержка ячеек ATM OAM
7.1. Дело VCC
Как правило, при настройке службы ATM VCC оба PE ДОЛЖНЫ действовать.
как коммутатор VC, в соответствии с процедурами OAM, определенными в
[Я.610].
PE ДОЛЖНЫ иметь возможность прозрачно передавать следующие ячейки OAM:
- Сигнал индикации тревоги F5 (AIS) (сегментный и сквозной)
- Индикатор удаленного дефекта F5 (RDI) (сегментный и сквозной)
- Шлейф F5 (сегментный и сквозной)
- Управление ресурсами
- Управление производительностью
- Проверка непрерывности
- Безопасность
Однако, если он настроен как граница административного сегмента,
PE СЛЕДУЕТ завершать и обрабатывать ячейки OAM сегмента F5.
Ячейки OAM F4 вставляются или извлекаются на окончании канала VP.Эти ячейки OAM не видны на окончании канала VC и не отображаются.
поэтому не пересылается через PSN.
Когда PE работает в транспортном режиме AAL5 CPCS-SDU, если он
не поддерживает транспортировку ячеек ATM, PE ДОЛЖЕН отвергать входящие MPLS
кадры на ATM PW, которые содержат метку PW с установленным битом T.
Мартини и др. Стандарты Track [Страница 15]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
7.2. Дело VPC
При настройке для службы ретрансляции ячеек VPC оба PE ДОЛЖНЫ действовать как
перекрестное соединение VP в соответствии с процедурами OAM, определенными в
[Я.610].
PE ДОЛЖНЫ иметь возможность обрабатывать и передавать следующие ячейки OAM
прозрачно согласно [I.610]:
- F4 AIS (сегментный и сквозной)
- F4 RDI (сегментный и сквозной)
- F4 loopback (сегментный и сквозной)
Однако, если он настроен как граница административного сегмента,
PE СЛЕДУЕТ завершать и обрабатывать ячейки OAM сегмента F4.
F5 OAM здесь не вставляются и не извлекаются. PE ДОЛЖНЫ быть в состоянии
прозрачно передать следующие ячейки OAM:
- F5 AIS (сегментный и сквозной)
- F5 RDI (сегментный и сквозной)
- Шлейф F5 (сегментный и сквозной)
- Управление ресурсами
- Управление производительностью
- Проверка непрерывности
- Безопасность
Ячейка OAM МОЖЕТ быть инкапсулирована вместе с другими ячейками пользовательских данных.
если используется инкапсуляция нескольких ячеек.7.3. Режим эмуляции ячейки OAM SDU / PDU
PE, работающий в транспортном режиме ATM SDU или PDU, не поддерживает
транспортировка ячеек OAM через PW МОЖЕТ обеспечить поддержку OAM на ATM
ПВХ с использованием следующих процедур:
- Ответ петлевых ячеек
Если сквозная ячейка OAM F5 получена от VC ATM,
либо PE, который транспортирует этот виртуальный канал ATM, с обратной связью
значение индикации 1, и PE имеет отображение метки для ATM
VC, тогда PE ДОЛЖЕН уменьшить значение индикации кольцевой проверки и
закольцевать ячейку на VC банкомата.В противном случае ячейка обратной связи
PE ДОЛЖЕН быть отброшен PE.
Мартини и др. Стандарты Track [Страница 16]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
- сигнализация AIS
Если входящий PE, PE1, получает ячейку OAM AIS F4 / F5, он ДОЛЖЕН
уведомить удаленный PE о сбое. Удаленный PE, PE2, ДОЛЖЕН в
Включите отправку ячеек AIS F5 OAM на соответствующие PVC. Обратите внимание, что если
PE поддерживает пересылку ячеек OAM, затем полученный OAM
Ячейки сигналов тревоги AIS также ДОЛЖНЫ пересылаться по PW.- сбой интерфейса
Если PE обнаруживает сбой физического интерфейса, или интерфейс
административно отключен, PE ДОЛЖЕН уведомить удаленный PE
для всех VC, связанных с отказом.
- Обнаружение сбоев PSN / PW
Если PE обнаруживает сбой в PW, получив метку
вывод средств для определенного идентификатора PW или целевой рассылки меток
Сбой сеанса протокола (LDP) или уведомление TLV о состоянии PW
получен, то ДОЛЖНА быть сгенерирована соответствующая ячейка OAM AIS F5 для всех
затронутые PVC банкоматов.Аварийный сигнал AIS OAM будет сгенерирован
порт вывода ATM PE, обнаружившего сбой.
7.4. Обработка дефектов
На рисунке 3 показаны четыре возможных места дефектов на PWE3.
услуга:
- (a) О подключении банкомата от CE к PE
- (b) На стороне банкомата PW
- (c) На стороне PSN PE
- (d) В PSN
+ ---- + + ---- +
+ ---- + | PE1 | ================== | PE2 | + ---- +
| | --- а ------ | b..c ...| Provider Edge 1 Provider Edge 2 |
| |
| <-------------- Эмулированная служба ----------------> |
Заказчик Заказчик
Край 1 Край 2
Рисунок 3: Расположение дефектов
Мартини и др. Стандарты Track [Страница 17] RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. Для сбоев в (a) или (b) в случае VPC входной PE ДОЛЖЕН быть способен генерировать F4 AIS при приеме дефекта нижнего уровня (например, LOS).В случае VCC входящий PE ДОЛЖЕН иметь возможность генерировать AIS F5 после приема соответствующего AIS F4 или дефект нижнего слоя (например, LOS). Эти сообщения отправляются через PSN. Для отказов в (c) или (d), в случае VCC, выходной PE ДОЛЖЕН быть может создать AIS F5 на основе сбоя PSN (например, PSN сбой туннеля или LOS на порту PSN). В случае VPC исходящий PE ДОЛЖЕН иметь возможность генерировать AIS F4 на основе сбоя PSN (например, как сбой туннеля PSN или LOS на порту PSN).Если входящий PE не может поддерживать создание ячеек OAM, он МОЖЕТ уведомить выходной PE, используя обслуживание, специфичное для псевдопроводов такой механизм, как сообщение о статусе PW, определенный в [RFC4447]. В качестве альтернативы, например, входящий PE МОЖЕТ отвести метка псевдопроводной сети (метка PW), связанная с услугой. На получив такое уведомление, выходной PE ДОЛЖЕН генерировать соответствующий F4 AIS (для VPC) или F5 AIS (для VCC). Если PW в одном направлении выходит из строя, то полный двунаправленный обслуживание считается отказавшим.8. Режим ATM N-to-One Cell. Режим N-к-одному (N> = 1), описанный в этом документе, позволяет поставщик услуг, предлагающий услуги ATM на основе PVC или SVC через сеть. Инкапсуляция позволяет использовать несколько ATM VCC или VPC. переносится в одном туннеле PSN. Поставщик услуг также может использовать Режим N-to-one для предоставления либо одного VCC, либо одного VPC в туннеле. В этом разделе определяются службы ретрансляции ячеек VCC и VPC через PSN. и их применимость. Мартини и др.Стандарты Track [Страница 18]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
8.1. Инкапсуляция услуг ATM N-to-One
В этом разделе описан общий формат инкапсуляции для ATM over
Псевдопроводы PSN.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| заголовок псевдопроводной сети |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Флаги | Res | Длина | Порядковый номер |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Полезная нагрузка службы банкоматов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 4: Общий формат инкапсуляции ATM через сети PSN
Заголовок транспорта PSN зависит от конкретного туннелирования.
используемая технология.Этот заголовок используется для транспортировки инкапсулированного
Информация ATM через ядро с коммутацией пакетов.
Заголовок Pseudowire идентифицирует конкретную услугу ATM на
туннель. Услуги, не относящиеся к ATM, также могут передаваться по туннелю PSN.
Как показано выше на рисунке 4, контрольное слово ATM вставлено перед
полезная нагрузка службы банкомата. Он может содержать поле длины и
поле порядкового номера в дополнение к определенным контрольным битам, необходимым для
нести службу.
Полезная нагрузка услуги банкомата зависит от услуги, предлагаемой через
псевдопровод.Это определено в следующих разделах.
В этом режиме инкапсуляции ячейки ATM транспортируются индивидуально.
Инкапсуляция одной ячейки ATM - единственное, что НЕОБХОДИМО.
инкапсуляция для банкоматов. Инкапсуляция более чем одной ячейки ATM
в кадре PSN НЕОБЯЗАТЕЛЬНО.
Инкапсуляция ячейки ATM состоит из ДОПОЛНИТЕЛЬНОГО контрольного слова и
одна или несколько ячеек ATM, каждая из которых состоит из 4-байтового заголовка ячейки ATM
и 48-байтовую полезную нагрузку ячейки ATM. Этот заголовок ячейки ATM определяется как
в разделе FAST encapsulation [FBATM] 3.1.1, но без
байт трейлера. Длина каждого кадра без инкапсуляции
заголовки кратны 52 байтам. Максимальное количество ячеек банкомата
которые могут быть помещены в раму таким образом, ограничены только
сетевой MTU и способность выходного маршрутизатора обрабатывать
их. Входящий маршрутизатор НЕ ДОЛЖЕН отправлять больше ячеек, чем исходящий.
Мартини и др. Стандарты Track [Страница 19]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
роутер готов получить.Количество ячеек, которые выходят
маршрутизатор готов принимать, может быть настроен на входе
маршрутизатор или сигнализация, например, с использованием методов, описанных ниже
в этом документе и в [RFC4447]. Количество инкапсулированных ячеек
в конкретном кадре можно сделать вывод по длине кадра. В
контрольное слово НЕОБЯЗАТЕЛЬНО. Если используется контрольное слово, то флаг
и биты длины в управляющем слове не используются. Эти биты ДОЛЖНЫ быть
установлен в 0 при передаче и ДОЛЖЕН игнорироваться при получении.Биты EFCI и CLP передаются по сети в ячейке ATM.
заголовок. Граничные маршрутизаторы, реализующие этот документ, МОГУТ, когда
либо добавляя, либо удаляя описанную здесь инкапсуляцию, измените
бит EFCI от нуля до единицы, чтобы отразить перегрузку в
сеть, известная граничному маршрутизатору, и измените бит CLP с
от нуля до единицы, чтобы отразить маркировку от пограничного контроля банкомата
Устойчивая скорость передачи ячеек. Биты EFCI и CLP НЕ ДОЛЖНЫ быть изменены.
от единицы до нуля.Эта диаграмма иллюстрирует инкапсуляцию двух ячеек ATM:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Контрольное слово (необязательно) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| ВПИ | VCI | PTI | C |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Полезная нагрузка банкомата (48 байтов) |
| "|
| "|
| "|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| ВПИ | VCI | PTI | C |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Полезная нагрузка банкомата (48 байтов) |
| "|
| "|
| "|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 5: Многосотовая инкапсуляция ATM
* Когда несколько VCC или VPC транспортируются по одному псевдопроводу,
Значения VPI / VCI ДОЛЖНЫ быть уникальными.Когда несколько VCC или VPC
от другого физического пути передачи, это может быть
необходимо для присвоения уникальных значений VPI / VCI соединениям ATM.
Если они из одного и того же физического пути передачи, VPI / VCI
ценности уникальны.
Мартини и др. Стандарты Track [Страница 20]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
* VPI
Входящий маршрутизатор ДОЛЖЕН скопировать поле VPI из входящей ячейки.
в это поле.Для определенных эмулируемых виртуальных каналов выходной маршрутизатор
МОЖЕТ генерировать новый VPI и игнорировать VPI, содержащийся в этом
поле.
* VCI
Входящий маршрутизатор ДОЛЖЕН скопировать поле VCI из входящего ATM.
заголовок ячейки в это поле. Для конкретных эмулируемых VC
выходной маршрутизатор МОЖЕТ создать новый VCI.
* PTI и CLP (бит C)
Поля PTI и CLP - это поля PTI и CLP входящих
Ячейки банкоматов. Заголовки ячеек в пакете:
заголовки ATM (без поля проверки ошибок заголовка (HEC))
входящая ячейка.9. Режим ATM "один-к-одному"
Режим «один к одному», описанный в этом документе, позволяет службе
провайдер, предлагающий услуги ATM на основе PVC или SVC в сети.
Инкапсуляция позволяет переносить один ATM VCC или VPC в пределах
одиночная псевдопроволока.
9.1. Инкапсуляция услуг ATM One-to-One
В этом разделе описан общий формат инкапсуляции для ATM over
псевдопроводы на MPLS PSN. На рисунке 6 представлен общий формат для
инкапсуляция ячеек ATM в пакеты.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок псевдопроводов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Resvd | Необязательный порядковый номер | Специфические для банкоматов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Полезная нагрузка службы банкоматов |
| |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 6: Общий формат для инкапсуляции в режиме "один-к-одному" через сети PSN
Мартини и др.Стандарты Track [Страница 21]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
Транспортный заголовок MPLS PSN зависит от того, как устроена сеть MPLS.
настроен. Заголовок Pseudowire идентифицирует конкретный банкомат.
сервис в туннеле PSN, созданный транспортным заголовком PSN.
Этот заголовок используется для передачи инкапсулированной информации ATM.
через ядро с коммутацией пакетов.
Общее контрольное слово вставляется после заголовка псевдопроводов.ТРЕБУЕТСЯ наличие контрольного слова.
Заголовок, специфичный для ATM, вставляется перед полезной нагрузкой услуги ATM.
Заголовок, специфичный для ATM, содержит контрольные биты, необходимые для передачи
услуга. Они определены в описаниях услуг ATM ниже.
Длина заголовка, специфичного для ATM, не всегда может составлять один октет. Это
зависит от типа услуги.
Группа октетов полезной нагрузки ATM - это полезная нагрузка службы, которая
инкапсулируется.
9.2. Последовательность чисел
Порядковый номер требуется не для всех услуг.Порядок порядкового номера обрабатывается в соответствии с разделом 5.1.3.
9.3. Служба передачи ячеек ATM VCC
Услуга передачи ячеек VCC характеризуется отображением
одиночный ATM VCC (VPI / VCI) в псевдопровод. Эта услуга полностью
прозрачно для уровня адаптации ATM. Отдельная ячейка VCC
транспортное обслуживание НЕОБЯЗАТЕЛЬНО. Эта услуга ДОЛЖНА использовать следующие
формат инкапсуляции:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок псевдопроводов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Resvd | Необязательный порядковый номер | M | V | Res | PTI | C |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| |
| Полезная нагрузка ячейки ATM (48 байтов) |
| |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 7: Инкапсуляция одной ячейки VCC ATM
Мартини и др.Стандарты Track [Страница 22]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
* M (транспортный режим) бит
Бит (M) байта управления указывает, содержит ли пакет
ячейка ATM или полезная нагрузка кадра. Если установлено значение 0, пакет содержит
ячейка банкомата. Если установлено в 1, PDU содержит полезную нагрузку AAL5.
* V (присутствует VCI) бит
Бит (V) байта управления указывает, является ли поле VCI
присутствует в пакете.Если установлено в 1, поле VCI присутствует для
сотовый. Если установлено значение 0, поле VCI отсутствует. На случай, если
VCC, поле VCI не требуется. Для VPC поле VCI равно
требуется и передается с каждой ячейкой.
* Зарезервированные биты
Зарезервированные биты должны быть установлены в 0 на передатчике и
игнорируется при приеме.
* Биты PTI
3-битный идентификатор типа полезной нагрузки (PTI) включает уровень ATM
Кодирование ячейки PTI. Эти биты устанавливаются в значение
PTI инкапсулированной ячейки банкомата.* C (CLP) Бит
Поле приоритета потери ячеек (CLP) указывает значение CLP для
инкапсулированная ячейка.
Для повышения эффективности транспортировки входящий PE ДОЛЖЕН иметь возможность
инкапсулировать несколько ячеек ATM в псевдопроводный PDU. Вход
выходящий PE ДОЛЖЕН согласовать максимальное количество ячеек в одном
псевдопроводный PDU. Это соглашение может быть достигнуто через
механизм сигнализации, специфичный для псевдопроводов, или через статическую конфигурацию.
Когда несколько ячеек инкапсулированы в один и тот же пакет PSN,
Байт, специфичный для ATM, ДОЛЖЕН повторяться для каждой ячейки.Это означает, что 49
байты используются для инкапсуляции каждой 53-байтовой ячейки ATM.
Мартини и др. Стандарты Track [Страница 23]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок псевдопроводов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Resvd | Необязательный порядковый номер | M | V | Res | PTI | C |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| |
| Полезная нагрузка ячейки ATM (48 байтов) |
| |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| M | V | Res | PTI | C | |
+ - + - + - + - + - + - + - + - + |
| Полезная нагрузка ячейки ATM (48 байтов) |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| |
+ - + - + - + - + - + - + - + - +
Рисунок 8: Инкапсуляция нескольких ячеек VCC ATM
9.4. Услуги ATM VPC
Служба VPC определяется путем сопоставления одного VPC (VPI) с
псевдопровод. Таким образом, он имитирует перекрестное соединение виртуального пути через
PSN. Все VCC, принадлежащие VPC, прозрачно переносятся
сервис VPC.
Выходной PE может выбрать применение другого VPI, отличного от
который прибыл на вход PE. Выходной PE ДОЛЖЕН выбрать
исходящий VPI, основанный исключительно на заголовке псевдопроводной сети. Как VPC
службы, выходной PE НЕ ДОЛЖЕН изменять поле VCI.Мартини и др. Стандарты Track [Страница 24]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
9.4.1. Услуги передачи ячеек ATM VPC
Услуга передачи ячеек VPC ATM является ДОПОЛНИТЕЛЬНОЙ.
Эта услуга ДОЛЖНА использовать следующую инкапсуляцию режима ячеек:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок псевдопроводов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Resvd | Необязательный порядковый номер | M | V | Res | PTI | C |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| VCI | |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |
| |
| Полезная нагрузка ячейки ATM (48 байтов) |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 9: Инкапсуляция VPC с одной ячейкой
Байт управления ATM содержит ту же информацию, что и в VCC.
инкапсуляция за исключением поля VCI.* Биты VCI
16-битный идентификатор виртуального канала (VCI) включает ATM
Значение VCI уровня ячейки.
Для повышения эффективности транспортировки входящий PE ДОЛЖЕН иметь возможность
инкапсулировать несколько ячеек ATM в псевдопроводный PDU. Вход
выходящий PE ДОЛЖЕН согласовать максимальное количество ячеек в одном
псевдопроводный PDU. Это соглашение может быть достигнуто через
механизм сигнализации, специфичный для псевдопроводов, или через статическую конфигурацию.
Если исходящий PE поддерживает объединение ячеек, входящий PE ДОЛЖЕН
только объединение ячеек до «Максимального количества объединенных банкоматов.
ячейки в кадре "суб-TLV параметра интерфейса, полученного как часть
протокол управления [RFC4447].Когда несколько ячеек ATM инкапсулированы в один и тот же пакет PSN,
Байт, специфичный для ATM, ДОЛЖЕН повторяться для каждой ячейки. Это означает, что 51
байты используются для инкапсуляции каждой 53-байтовой ячейки ATM.
Мартини и др. Стандарты Track [Страница 25]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок псевдопроводов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Resvd | Необязательный порядковый номер | M | V | Res | PTI | C |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| VCI | |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |
| |
| Полезная нагрузка ячейки ATM (48 байтов) |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| | M | V | Res | PTI | C | VCI |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| VCI | |
+ - + - + - + - + - + - + - + - + |
| Полезная нагрузка ячейки ATM (48 байтов) |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| |
+ - + - + - + - + - + - + - + - +
Рисунок 10: Инкапсуляция VPC с несколькими ячейками
10.Режим ATM AAL5 CPCS-SDU
Служба VCC полезной нагрузки AAL5 определяет соответствие между полезной нагрузкой
VCC AAL5 и один псевдопровод. Служба VCC полезной нагрузки AAL5
требует сегментации ATM и поддержки повторной сборки на PE.
Услуга CPCS-SDU полезной нагрузки AAL5 является ДОПОЛНИТЕЛЬНОЙ.
Даже самый маленький TCP-пакет требует двух ячеек ATM при пересылке.
AAL5 на собственном банкомате. Желательно избегать этой прокладки.
на псевдопроводе. Следовательно, как только входной PE собирает
AAL5 CPCS-PDU, PE отбрасывает трейлер PAD и CPCS-PDU, а затем
входной PE вставляет результирующую полезную нагрузку в псевдопроводный PDU.Выходной PE ДОЛЖЕН регенерировать PAD и трейлер перед передачей.
кадр AAL5 на выходном порте ATM.
Эта служба разрешает транспортировку ячеек OAM и RM, но
не пытается поддерживать относительный порядок этих ячеек с помощью
относительно ячеек, составляющих AAL5 CPCS-PDU. Все ячейки OAM,
независимо от их типа, которые поступают при повторной сборке
Мартини и др. Стандарты Track [Страница 26]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
одиночный AAL5 CPCS-PDU немедленно отправляется по псевдопроводу с использованием
Инкапсуляция ячеек N-к-одному, за которой следует полезная нагрузка AAL5.Следовательно, служба VCC полезной нагрузки AAL5 не подходит для ATM.
приложения, требующие строгого упорядочивания ячеек OAM (например,
приложения для мониторинга производительности и безопасности).
10.1. Прозрачная инкапсуляция кадров SDU AAL5
Перед CPCS-SDU AAL5 идет следующий заголовок:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Res | T | E | C | U | Res | Длина | Порядковый номер (необязательно) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| "|
| Ячейка ATM или AAL5 CPCS-SDU |
| "|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 11: Инкапсуляция AAL5 CPCS-SDU
Инкапсуляция службы полезной нагрузки AAL5 требует контрольного слова ATM.Биты флага описаны ниже.
* Res (Зарезервировано)
Эти биты зарезервированы и ДОЛЖНЫ быть установлены в 0 при передаче.
и игнорируется при приеме.
* T (транспортный тип) бит
Бит (T) контрольного слова указывает, содержит ли пакет
ячейка администратора банкомата или полезная нагрузка AAL5. Если T = 1, пакет
содержит ячейку администратора банкомата, инкапсулированную в соответствии с N-to-
инкапсуляция реле в одну ячейку, рис. 4. Если не задано, PDU
содержит полезную нагрузку AAL5.Возможность транспортировки ячейки банкомата
в режиме AAL5 SDU предназначен для обеспечения возможности включения
административные функции через AAL5 VCC (хотя и
не стремиться сохранить пользовательскую ячейку и админ-ячейку
прибытие / заказ транспорта).
* Бит E (EFCI)
Входному маршрутизатору PE1 СЛЕДУЕТ установить этот бит в 1, если бит EFCI
последней ячейки из тех, которые транспортировали AAL5 CPCS-SDU, составляет
установлен в 1, или если бит EFCI отдельной ячейки ATM должен быть
транспортируемый в пакете установлен на 1.В противном случае этот бит
Мартини и др. Стандарты Track [Страница 27]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
ДОЛЖЕН быть установлен на 0. Выходной маршрутизатор PE2 ДОЛЖЕН установить EFCI.
бит всех ячеек, которые транспортируют AAL5 CPCS-SDU к значению
содержится в этом поле.
* C (CLP) Бит
Входному маршрутизатору PE1 СЛЕДУЕТ установить этот бит в 1, если бит CLP
любой из ячеек ATM, которые транспортировали AAL5 CPCS-SDU, установлен
в 1, или если бит CLP единственной ячейки ATM для транспортировки
в пакете установлен на 1.В противном случае этот бит ДОЛЖЕН быть установлен в
0. Выходной маршрутизатор PE2 ДОЛЖЕН установить бит CLP для всех ячеек.
которые транспортируют AAL5 CPCS-SDU к значению, содержащемуся в этом
поле.
* U (поле команды / ответа) бит
При взаимодействии услуг FRF.8.1 Frame Relay / ATM PVC [RFC3916]
трафик транспортируется, младший бит CPCS-UU
(LSB) CPCS-PDU AAL5 может содержать бит Frame Relay C / R.
Входной маршрутизатор PE1 ДОЛЖЕН скопировать этот бит в бит U
контрольное слово.Выходной маршрутизатор PE2 ДОЛЖЕН скопировать бит U в
младший значащий бит (LSB) CPCS-UU PDU CPCS AAL5.
11. Режим кадра PDU AAL5
Служба PDU полезной нагрузки AAL5 НЕОБЯЗАТЕЛЬНА.
11.1. Прозрачная инкапсуляция кадров PDU AAL5
В этом режиме входящий PE инкапсулирует весь CPCS-PDU.
включая ПОДКЛАДКУ и прицеп.
Этот режим МОЖЕТ поддерживать процедуры фрагментации, описанные в
Раздел «Фрагментация» ниже, чтобы поддерживать ячейку OAM
последовательность действий.
Как и служба VCC полезной нагрузки ATM AAL5, прозрачный VCC AAL5
служба предназначена быть более эффективной, чем передача ячеек VCC
услуга.Однако прозрачная служба VCC AAL5 несет в себе
весь AAL5 CPCS-PDU, включая PAD и трейлер. Обратите внимание, что
AAL5 CPCS-PDU не обрабатывается, т.е. кадр AAL5 с недопустимым
CRC или поле длины будут перенесены. Одна из причин этого в том, что
может быть агент безопасности, который скремблировал ячейку банкомата
полезные данные, которые образуют AAL5 CPCS-PDU.
Эта служба поддерживает все потоки ячеек OAM с использованием фрагментации
процедура, которая гарантирует, что ячейки OAM не будут перемещены относительно
до композитных ячеек AAL5.Мартини и др. Стандарты Track [Страница 28]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
Прозрачная служба VCC AAL5 является ДОПОЛНИТЕЛЬНОЙ.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Транспортный заголовок PSN (при необходимости) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок псевдопроводов |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0 0 0 0 | Resvd | Необязательный порядковый номер | M | V | Res | U | E | C |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| "|
| AAL5 CPCS-PDU |
| (n * 48 байт) |
| "|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 12: Прозрачная инкапсуляция службы AAL5
Общее контрольное слово вставляется после заголовка псевдопроводов.Наличие контрольного слова ОБЯЗАТЕЛЬНО.
Биты M, V, Res и C определены ранее для VCC One-to-one.
сотовый режим.
* U бит
Это поле указывает, содержит ли этот кадр последнюю ячейку
PDU AAL5 и представляет значение бита ATM User-to-User
для последней ячейки ATM кадра PSN. Примечание. Пользователь банкомата - к
Пользовательский бит - это младший бит поля PTI в банкомате.
заголовок. Это поле используется для поддержки фрагментации
функциональность, описанная далее в этом разделе.* E (EFCI) бит
Это поле используется для передачи состояния EFCI ячеек ATM.
Состояние EFCI указывается в среднем бите каждой ячейки ATM.
Поле ПТИ.
Направление ATM-PSN (вход): поле EFCI элемента управления.
byte устанавливается в состояние EFCI последней ячейки PDU AAL5 или
Фрагмент AAL5.
Направление PSN-ATM (исходящий): состояние EFCI всех составляющих
ячеек PDU AAL5 или фрагмента AAL5 устанавливается значение
Поле EFCI в контрольном байте.Мартини и др. Стандарты Track [Страница 29]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
* C (CLP) бит
Это поле используется для передачи приоритета потери ячеек банкомата.
клетки.
Направление ATM-PSN (вход): поле CLP управляющего байта.
устанавливается в 1, если любая из составляющих ячеек PDU AAL5 или
У фрагмента AAL5 бит CLP установлен в 1; в противном случае это поле
установлен на 0.Направление PSN-ATM (выход): бит CLP всех составляющих
ячеек для PDU AAL5 или фрагмента AAL5 устанавливается значение
Поле CLP в байте управления. Полезная нагрузка состоит из
повторно собранный AAL5 CPCS-PDU, включая прокладку AAL5 и
трейлер или фрагмент AAL5.
11.2. Фрагментация
Входной PE не всегда может собрать полный AAL5.
Рамка. Это может быть связано с тем, что PDU AAL5 превышает MTU псевдопроводной сети.
или потому что ячейки OAM прибывают во время повторной сборки PDU AAL5.В
В этих случаях PDU AAL5 должен быть фрагментирован. Кроме того,
фрагментация может быть желательной для ограничения задержки ячейки ATM.
Когда происходит фрагментация, процедуры, описанные ниже
подразделы должны соблюдаться.
11.2.1. Процедуры в направлении ATM-PSN
При фрагментировании PDU AAL5 должны применяться следующие процедуры:
- Фрагментация всегда должна происходить на границах ячеек в пределах
AAL5 PDU.
- Установите бит UU в значение бита ATM User-to-User в
заголовок ячейки ATM, полученной последней.- Биты E и C фрагмента должны быть установлены, как определено в
Раздел 9.
- Если прибывающая ячейка является ячейкой OAM или RM, отправьте текущий
Кадр PSN, а затем отправьте ячейку OAM или RM с использованием однозначного соединения
инкапсуляция одной ячейки (VCC).
Мартини и др. Стандарты Track [Страница 30]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
11.2.2. Процедуры в направлении PSN-ATM
Применяются следующие процедуры:
- 3-битное поле PTI каждого заголовка ячейки ATM построено как
следует:
-я.Самый старший бит установлен в 0, что указывает на данные пользователя.
клетка.
-ii. Средний бит устанавливается равным значению бита E фрагмента.
-iii. Наименьший значащий бит последней ячейки ATM в PSN
frame устанавливается в значение бита UU на рисунке 12.
-iv. Младший бит PTI установлен в 0 для всех остальных
ячеек в кадре PSN.
- Бит CLP каждого заголовка ячейки ATM устанавливается в значение C
бит контрольного байта на рисунке 12.- Когда фрагмент получен, каждая составляющая ячейка ATM отправляется в
правильный заказ.
12. Сопоставление классов обслуживания ATM и PSN.
Этот раздел предназначен для информационных целей и для руководства.
Только. Этот раздел не следует рассматривать как часть стандарта.
предложено в этом документе.
Когда служба ATM PW настроена через PSN, служба ATM
Категория соединения ДОЛЖНА быть сопоставлена с совместимым классом
обслуживание в сети PSN. Совместимый класс обслуживания поддерживает
целостность обслуживания от начала до конца.Например, ЦБ РФ
категория обслуживания ДОЛЖНА быть сопоставлена с классом обслуживания с
строгие требования к потерям и задержкам. Если PSN реализует IP
Фреймворк Diffserv, класс обслуживания на базе EF PHB - хороший
кандидат.
Кроме того, категории услуг банкоматов поддерживают несколько
определения соответствия [TM4.0]. Некоторые из них являются слепыми по CLP (например, CBR),
означает, что цели QoS применяются к совокупному CLP0 + 1
соответствующий клеточный поток. Некоторые из них имеют значение CLP (например, VBR.3),
означает, что цели QoS применяются к ячейке, соответствующей CLP0.
только поток.
Когда PSN основан на MPLS, отображение между битом CLP и EXP
поле может быть выполнено, чтобы обеспечить видимость потери ячеек
Мартини и др. Стандарты Track [Страница 31]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
приоритет в сети MPLS. Фактическое значение должно быть отмечено в
Поле EXP зависит от категории услуги ATM, соответствия ATM
определение и тип используемого туннельного LSP (E-LSP или L-LSP).В
подробности этого сопоставления выходят за рамки этого документа.
Операторы могут разработать конкретное отображение, которое
удовлетворяет их собственные требования.
В обоих направлениях ATM-to-PSN и PSN-to-ATM метод, используемый для
передавать информацию CLP и EFCI отдельных ячеек в
специфичное для ATM поле или флаги пакета PW описано в
подробно в разделах с 6 по 9 для каждого режима инкапсуляции.
13. Поддержка ILMI
Edge PE MPLS МОЖЕТ обеспечивать интегрированное локальное управление ATM
Интерфейс (ILMI) к пограничному коммутатору банкомата.Если входящий PE получает
сообщение ILMI, указывающее, что пограничный коммутатор ATM удалил виртуальный канал,
или если физический интерфейс выходит из строя, он ДОЛЖЕН отправить статус PW
сообщение с уведомлением для всех PW, связанных с ошибкой. Когда
Отображение метки PW отозвано или сообщение с уведомлением о статусе PW
получен, выходной PE ДОЛЖЕН уведомить своего клиента об этой ошибке,
удаление ВК с помощью ILMI.
14. Под-TLV параметров интерфейса, специфичных для ATM
TLV параметра интерфейса определено в [RFC4447], а IANA
реестр с начальными значениями для подтипов TLV параметров интерфейса
определено в [RFC4446], но параметр интерфейса ATM PW
указаны следующим образом:
- 0x02 Максимальное количество объединенных ячеек ATM.2-октетное значение, определяющее максимальное количество конкатенированных банкоматов.
ячейки, которые могут обрабатываться выходным PE как единый PDU. An
входящий PE, передающий объединенные ячейки на этом PW, может
объединить количество ячеек до значения этого параметра,
но НЕ ДОЛЖЕН превышать его. Этот параметр применим только к PW
типы 3, 9, 0x0a, 0xc, [RFC4446] и 0xd и ТРЕБУЕТСЯ для
эти типы PWC. Этот параметр не обязательно должен совпадать в обоих
направления конкретного ПВ.15. Контроль перегрузки
Как поясняется в [RFC3985], PSN, несущий PW, может подлежать
перегрузка, с характеристиками перегрузки в зависимости от типа PSN,
сетевая архитектура, конфигурация и загрузка. Во время заторов
в PSN может наблюдаться потеря пакетов, что повлияет на предоставляемую услугу.
банкоматом PW. Кроме того, поскольку PW банкоматов несут в себе различные
Мартини и др. Стандарты Track [Страница 32] RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. сервисов через PSN, включая TCP / IP, но не ограничиваясь им, они может или не может вести себя дружественным к TCP образом, предписанным [RFC2914].При наличии сервисов, снижающих передачу скорости, банкоматные PW могут, таким образом, потреблять больше, чем их справедливая доля, и в этом дело ДОЛЖНО быть остановлено. По возможности, PW ATM следует запускать через PSN, спроектированные для трафика. обеспечение механизмов распределения полосы пропускания и управления доступом. Домены с поддержкой IntServ, предоставляющие Гарантированное обслуживание (GS) или Домены с поддержкой Diffserv, использующие EF (ускоренная пересылка), являются примерами PSN, созданных с использованием трафика. Такие PSN минимизируют потери и задержки. обеспечивая некоторую степень изоляции эффектов PW банкомата от соседние ручьи.Следует отметить, что при транспортировке банкоматов Diffserv-enabled домены могут использовать AF (гарантированная пересылка) и / или DF (по умолчанию Пересылка) вместо EF, чтобы снизить нагрузку на сети и получить дополнительное преимущество статистического мультиплексирования. В в частности, Таблица 1 Приложения «V» в [ATM-MPLS] содержит подробные отображение между классами ATM и классами Diffserv. PE ДОЛЖНЫ отслеживать перегрузку (используя явную перегрузку). уведомление, [VCCV], или путем измерения потери пакетов), чтобы гарантировать что услуга, использующая ATM PW, может поддерживаться.Когда ЧП обнаруживает значительную перегрузку при получении PDU PW, PE МОЖЕТ использовать ячейки RM для соединений ABR для уведомления удаленного PE. Если PW был настроен с использованием протокола, определенного в [RFC4447], тогда процедуры, указанные в [RFC4447] для уведомления о статусе, могут быть используется для отключения передачи пакетов на входящем PE от выходного ЧП. PW может быть перезапущен вручную или автоматически. означает после соответствующего времени ожидания. 16. Соображения безопасности В этом документе указаны только инкапсуляции, а не используемые протоколы. для передачи инкапсулированных пакетов через PSN.Каждый такой протокол может иметь собственный набор проблем безопасности [RFC4447] [RFC3985], но эти указанные здесь инкапсуляции не влияют на проблемы. Примечание что безопасность перевозимого банкомата будет только на таком высоком уровне как безопасность PSN. Этот уровень безопасности может быть меньше более строгий, чем собственный банкомат. Мартини и др. Стандарты Track [Страница 33]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
17.Нормативные ссылки
[RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения
Уровни требований », BCP 14, RFC 2119, март 1997 г.
[RFC4447] Мартини, Л., Розен, Э., Эль-Аавар, Н., Смит, Т., и Г.
Херон, "Настройка и обслуживание псевдопроводов с помощью метки"
Протокол распространения (LDP) », RFC 4447, апрель 2006 г.
[RFC3032] Розен, Э., Таппан, Д., Федорков, Г., Рехтер, Ю.,
Фариначчи, Д., Ли, Т., и А. Конта, "Стек этикеток MPLS"
Кодирование », RFC 3032, январь 2001 г.[RFC4446] Мартини, Л., «Распределение IANA для псевдопроводов от края до края.
Emulation (PWE3) ", BCP 116, RFC 4446, апрель 2006 г.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Управляющее слово Pseudowire Emulation Edge-to-Edge (PWE3) для
Использование через MPLS PSN », RFC 4385, февраль 2006 г.
18. Информативные ссылки
[FBATM] Спецификация форума банкоматов af-fbatm-0151.000 (2000), "Frame
ATM на основе транспорта SONET / SDH (FAST) »
[TM4.0] ATM Forum Specification af-tm-0121.000 (1999), «Трафик
Спецификация управления версии 4.1 "
[I.371] Рекомендация МСЭ-Т I.371 (2000 г.), «Управление трафиком и
контроль перегрузки в B-ISDN ».
[I.610] Рекомендация МСЭ-Т I.610, (1999 г.), «Работа B-ISDN и
принципы и функции обслуживания ".
[Y.1411] Рекомендация ITU-T Y.1411 (2003 г.), Сеть ATM-MPLS
Взаимодействие - пользователь в режиме ячейки Взаимодействие на плоскости
[Y.1412] Рекомендация ITU-T Y.1412 (2003 г.), сеть ATM-MPLS
interworking - Взаимодействие плоскости пользователя в кадровом режиме
[RFC3985] Брайант, С. и П. Пэйт, «Эмуляция псевдопроводов от края до края.
Edge (PWE3) Architecture », RFC 3985, март 2005 г.
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Требования к
Сквозная эмуляция псевдопроводов (PWE3) », RFC 3916,
Сентябрь 2004 г.
Мартини и др. Стандарты Track [Страница 34]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г.
[RFC4026] Андерссон, Л.и Т. Мэдсен, "Виртуальный
Терминология частных сетей (VPN) », RFC 4026, март 2005 г.
[VCCV] Надо, Т., Пигнатаро, К., и Р. Аггарвал, "Псевдопровод
Проверка подключения виртуального канала (VCCV) ", Работа в
Прогресс, июнь 2006 г.
[RFC2992] Хоппс, К., "Анализ равноправной многопутевости.
Алгоритм », RFC 2992, ноябрь 2000 г.
[ATM-MPLS] Спецификация форума ATM af-aic-0178.001, "Сеть ATM-MPLS
Версия взаимодействия 2.0 ", август 2003 г.
[RFC2914] Флойд, С., «Принципы контроля перегрузки», BCP 41, RFC
2914, сентябрь 2000 г.
[RFC2684] Гроссман, Д. и Дж. Хейнанен, «Многопротокольная инкапсуляция.
over ATM Adaptation Layer 5 ", RFC 2684, сентябрь 1999 г.
Мартини и др. Стандарты Track [Страница 35] RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. 19. Важные участники Джайлс Херон Tellabs Abbey Place 24-28 Истон-стрит Хай Викомб Баксов HP11 1NT Соединенное Королевство Электронная почта: Джайлз[email protected] Димитри Страттон Влахос Mazu Networks, Inc. 125 Cambridgepark Drive Кембридж, Массачусетс 02140 Электронная почта: [email protected] Дэн Таппан Cisco Systems, Inc. 1414 Массачусетс-авеню Боксборо, Массачусетс 01719 Электронная почта: [email protected] Эрик К. Розен Cisco Systems, Inc. 1414 Массачусетс-авеню Боксборо, Массачусетс 01719 Электронная почта: [email protected] Стив Фогельсанг ECI Telecom Корпоративный центр Омега 1300 Омега Драйв Питтсбург, Пенсильвания 15205 Электронная почта: Стивен[email protected] Джеральд де Грейс ECI Telecom Корпоративный центр Омега 1300 Омега Драйв Питтсбург, Пенсильвания 15205 Электронная почта: [email protected] Мартини и др. Стандарты Track [Страница 36]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. Джон Ширрон ECI Telecom Корпоративный центр Омега 1300 Омега Драйв Питтсбург, Пенсильвания 15205 Электронная почта: [email protected] Эндрю Дж. Малис Verizon Communications Дорога Сильвана, 40 Уолтем, Массачусетс Электронная почта: Андрей[email protected] Телефон: 781-466-2362 Винай Сиркай Redback Networks 300 Holger Way Сан-Хосе, Калифорния 95134 Электронная почта: [email protected] Крис Лильенстолпе Alcatel 11600 Салли Мэй Др. 9-й этаж Рестон, Вирджиния, 20193 Электронная почта: [email protected] Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Саннивейл, Калифорния, 94089 Электронная почта: [email protected] Джон Фишер Alcatel 600 March Rd Каната, Онтарио, Канада. K2K 2E6 Электронная почта: john.fischer@alcatel.ком Мартини и др. Стандарты Track [Страница 37]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. Мустафа Айссауи Alcatel 600 March Rd Каната, Онтарио, Канада. K2K 2E6 Электронная почта: [email protected] Том Уолш Lucent Technologies 1 Роббинс-роуд Вестфорд, Массачусетс 01886 США Электронная почта: [email protected] Джон Рутемиллер Marconi Networks 1000 Маркони Драйв Warrendale, PA 15086 Электронная почта: Джон[email protected] Рик Уайлдер Alcatel 45195 Деловой суд Люкс Loudoun Gateway II 300 М / С СТЕРВ-СМАЭ Стерлинг, Вирджиния, 20166 Электронная почта: [email protected] Лаура Доминик Qwest Communications, Inc. 600 Stinson Blvd. Миннеаполис, Миннесота 55413 Электронная почта: [email protected] Мартини и др. Стандарты Track [Страница 38]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. Адреса авторов Лука Мартини Cisco Systems, Inc.9155 Ист Николс Авеню, офис 400 Энглвуд, Колорадо 80112 Электронная почта: [email protected] Джаякумар Джаякумар Cisco Systems, Inc. 225 Э.Тасман, MS-SJ3 / 3 Сан-Хосе, Калифорния 95134 Электронная почта: [email protected] Мэтью Боччи Alcatel Grove House, Waltham Road Rd Уайт Уолтем, Беркс, Великобритания. SL6 3TN Электронная почта: [email protected] Насер Эль-Аавар Уровень 3 Коммуникации, ООО. 1025 Eldorado Blvd. Брумфилд, Колорадо 80021 Электронная почта: [email protected] Джереми Брейли ECI Telecom Inc.Корпоративный центр Омега 1300 Омега Драйв Питтсбург, Пенсильвания 15205 Электронная почта: [email protected] Гассем Колейни Nortel Networks P O Box 3511, Station C Оттава, Онтарио, K1Y 4H7 Канада Электронная почта: [email protected] Мартини и др. Стандарты Track [Страница 39]
RFC 4717 Инкапсуляция для ATM через MPLS, декабрь 2006 г. Полное заявление об авторских правах Авторские права (C) IETF Trust (2006 г.). На этот документ распространяются права, лицензии и ограничения. содержится в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права.Этот документ и содержащаяся в нем информация размещены на Принцип "КАК ЕСТЬ" и ПОСТАВЩИК, ОРГАНИЗАЦИЯ, ПРЕДСТАВЛЯЕМЫЕ ОН / ОНА ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЕСТЬ) ИНТЕРНЕТ-ОБЩЕСТВОМ, IETF TRUST, И ИНТЕРНЕТ-ИНЖИНИРИНГ ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯ НИКАКОЙ ГАРАНТИИ, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЕННОЙ ИНФОРМАЦИИ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ЛЮБЫХ ПРАВ. ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОГО ЦЕЛЬ.Интеллектуальная собственность IETF не занимает никакой позиции относительно действительности или объема каких-либо Права на интеллектуальную собственность или другие права, которые могут быть заявлены на относятся к реализации или использованию технологии, описанной в этот документ или степень, в которой любая лицензия на такие права может быть, а может и нет; и не означает, что предпринял какие-либо независимые усилия для выявления любых таких прав. Информация о процедурах в отношении прав в документах RFC может быть найдено в BCP 78 и BCP 79.Копии раскрытия информации о правах интеллектуальной собственности в секретариат IETF и гарантии предоставления лицензий или результат попытка получить генеральную лицензию или разрешение на использование такие права собственности разработчиков или пользователей этого спецификацию можно получить в он-лайн репозитории IETF IPR по адресу http://www.ietf.org/ipr. IETF приглашает любую заинтересованную сторону довести до ее сведения любые авторские права, патенты или заявки на патенты или другие проприетарные права, которые могут распространяться на технологии, которые могут потребоваться для реализации этот стандарт.Пожалуйста, направьте информацию в IETF по адресу [email protected]. Подтверждение Финансирование функции редактора RFC в настоящее время обеспечивается Интернет-сообщество. Мартини и др. Стандарты Track [стр. 40]
rfc3948
Сетевая рабочая группа А. Хуттунен
Запрос комментариев: 3948 F-Secure Corporation
Категория: Стандарты Track B.Swander
Microsoft
В. Вольпе
Cisco Systems
Л. ДиБурро
Nortel Networks
М. Стенберг
Январь 2005 г.
UDP-инкапсуляция пакетов IPsec ESP
Статус этого меморандума
Этот документ определяет протокол отслеживания стандартов Интернета для
Интернет-сообщество и просит обсуждения и предложения по
улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
Официальные стандарты протокола »(STD 1) для состояния стандартизации
и статус этого протокола. Распространение этой памятки не ограничено.
Уведомление об авторских правах
Авторские права (C) The Internet Society (2005).
Абстрактный
Эта спецификация протокола определяет методы инкапсуляции и
декапсулировать пакеты полезной нагрузки IP-инкапсуляции (ESP) внутри
Пакеты UDP для прохождения трансляторов сетевых адресов. ESP
инкапсуляция, как определено в этом документе, может использоваться как в IPv4
и сценарии IPv6.При каждом согласовании используется инкапсуляция с
Обмен ключами в Интернете (IKE).
Huttunen, et al. Стандарты Track [Страница 1]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
Оглавление
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Форматы пакетов. . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Формат заголовка ESP, инкапсулированный в UDP. . . . . . . . . .. 3
2.2. Формат заголовка IKE для порта 4500. . . . . . . . . . . . 4
2.3. Формат пакета NAT-Keepalive. . . . . . . . . . . . . . 4
3. Процедуры инкапсуляции и декапсулирования. . . . . . . . . . 5
3.1. Вспомогательные процедуры. . . . . . . . . . . . . . . . . . 5
3.1.1. Процедура декапсуляции NAT в туннельном режиме. . . . 5
3.1.2. Процедура NAT декапсуляции транспортного режима. . . 5
3.2. Инкапсуляция ESP в транспортном режиме. . . . . .. . . . . . 6
3.3. Декапсуляция ESP в транспортном режиме. . . . . . . . . . . . 6
3.4. Инкапсуляция ESP в туннельном режиме. . . . . . . . . . . . . 7
3.5. Декапсуляция ESP в туннельном режиме. . . . . . . . . . . . . 7
4. Процедура проверки активности NAT. . . . . . . . . . . . . . . . . . . 7
5. Соображения безопасности. . . . . . . . . . . . . . . . . . . 8
5.1. Конфликт туннельного режима. . . . . . . . . . . . . . . . . . 8
5.2. Конфликт транспортного режима. . . . .. . . . . . . . . . . 9
6. Рекомендации IAB. . . . . . . . . . . . . . . . . . . . . . 10
7. Благодарности. . . . . . . . . . . . . . . . . . . . . . . 11
8. Ссылки. . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . 11
8.2. Информативные ссылки. . . . . . . . . . . . . . . . . 11
A. Разъяснение возможных решений NAT для нескольких клиентов. . . 12
Адреса авторов. . . . . .. . . . . . . . . . . . . . . . 14
Полное заявление об авторских правах. . . . . . . . . . . . . . . . . . . 15
1. Введение
Эта спецификация протокола определяет методы инкапсуляции и
декапсулировать пакеты ESP внутри пакетов UDP для прохождения по сети
Трансляторы адресов (NAT) (см. [RFC3715], раздел 2.2, случай i). В
Номера портов UDP такие же, как и для трафика IKE, так как
определено в [RFC3947].
Совместное использование номеров портов для IKE и UDP-инкапсулированных ESP
трафик был выбран, потому что он предлагает лучшее масштабирование (только один NAT
отображение в NAT; не нужно отправлять отдельные сообщения поддержки активности IKE), проще
конфигурация (в брандмауэрах настраивается только один порт) и
более простая реализация.Потребности клиента должны определять, будет ли транспортный режим или туннель.
должен поддерживаться режим (см. [RFC3715], Раздел 3, «Дистанционный
сценарий "). Клиенты L2TP / IPsec ДОЛЖНЫ поддерживать режимы, определенные в
[RFC3193]. Клиенты туннельного режима IPsec ДОЛЖНЫ поддерживать туннельный режим.
Huttunen, et al. Стандарты Track [Страница 2]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
Реализация IKE, поддерживающая эту спецификацию протокола, НЕ ДОЛЖНА
используйте ноль поля ESP SPI для пакетов ESP.Это гарантирует, что IKE
пакеты и пакеты ESP можно отличить друг от друга.
Как определено в этом документе, UDP-инкапсуляция пакетов ESP
написано в терминах заголовков IPv4. Нет технической причины, почему
заголовок IPv6 не может использоваться как внешний заголовок и / или как
внутренний заголовок.
Поскольку защита внешних IP-адресов в IPsec AH
изначально несовместимый с NAT, IPsec AH был исключен из
объем данной спецификации протокола. Этот протокол также предполагает
что IKE (IKEv1 [RFC2401] или IKEv2 [IKEv2]) используется для согласования
IPsec SA.Ручной ввод не поддерживается.
Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
«ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
документ следует интерпретировать, как описано в [RFC2119].
2. Форматы пакетов
2.1. UDP-инкапсулированный формат заголовка ESP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Исходный порт | Порт назначения |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Длина | Контрольная сумма |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок ESP [RFC2406] |
~ ~
| |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Заголовок UDP - это стандартный заголовок [RFC0768], где
o порт источника и порт назначения ДОЛЖНЫ быть такими же, как используемые
по трафику IKE,
o Контрольная сумма IPv4 UDP ДОЛЖНА передаваться как нулевое значение, и
o приемники НЕ ДОЛЖНЫ зависеть от нулевого значения контрольной суммы UDP.Поле SPI в заголовке ESP НЕ ДОЛЖНО быть нулевым значением.
Huttunen, et al. Стандарты Track [Страница 3]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
2.2. Формат заголовка IKE для порта 4500
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Исходный порт | Порт назначения |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Длина | Контрольная сумма |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Маркер без ESP |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок IKE [RFC2409] |
~ ~
| |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Заголовок UDP является стандартным заголовком [RFC0768] и используется в соответствии с определением.
в [RFC3947].Этот документ не устанавливает никаких новых требований к
обработка контрольной суммы пакета IKE.
Маркер без ESP - это 4 байта с нулевым значением, совпадающие с полем SPI.
пакета ESP.
2.3. Формат пакета NAT-Keepalive
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Исходный порт | Порт назначения |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Длина | Контрольная сумма |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0xFF |
+ - + - + - + - + - + - + - + - +
Заголовок UDP - это стандартный заголовок [RFC0768], где
o порт источника и порт назначения ДОЛЖНЫ быть такими же, как и используемые
Инкапсуляция UDP-ESP раздела 2.1,
o Контрольная сумма IPv4 UDP ДОЛЖНА передаваться как нулевое значение, и
o приемники НЕ ДОЛЖНЫ зависеть от нулевой контрольной суммы UDP.
ценить.
Отправитель ДОЛЖЕН использовать полезную нагрузку длиной в один октет со значением 0xFF.
Получателю СЛЕДУЕТ игнорировать полученный пакет NAT-keepalive.
Huttunen, et al. Стандарты Track [Страница 4]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
3. Процедуры инкапсуляции и декапсулирования.
3.1. Вспомогательные процедуры
3.1.1. Процедура декапсуляции NAT в туннельном режиме
Если для передачи пакетов использовался туннельный режим (см. [RFC3715],
раздел 3, критерии «Поддержка режима» и «Сценарий удаленного доступа»),
внутренний IP-заголовок может содержать адреса, не подходящие для
текущая сеть. Эта процедура определяет, как эти адреса должны
быть преобразованы в подходящие адреса для текущей сети.
В зависимости от локальной политики ДОЛЖНО быть выполнено одно из следующих действий:
1. Если в политике определено допустимое пространство IP-адресов источника.
для инкапсулированных пакетов от однорангового узла убедитесь, что источник
IP-адрес внутреннего пакета действителен в соответствии с политикой.2. Если адрес был назначен удаленному узлу, убедитесь, что
исходный IP-адрес, используемый во внутреннем пакете, является назначенным IP-адресом.
адрес.
3. Для пакета выполняется NAT, что делает его пригодным для транспортировки.
в локальной сети.
3.1.2. Процедура декапсуляции NAT в транспортном режиме
Когда транспортный режим использовался для передачи пакетов, содержащих
Заголовки TCP или UDP будут иметь неверные контрольные суммы из-за изменения
части заголовка IP во время передачи. Эта процедура определяет, как
исправьте эти контрольные суммы (см. [RFC3715], раздел 2.1, случай б).
В зависимости от локальной политики ДОЛЖНО быть выполнено одно из следующих действий:
1. Если заголовок протокола после заголовка ESP является заголовком TCP / UDP
и реальный исходный и целевой IP-адрес однорангового узла были
полученные в соответствии с [RFC3947], постепенно пересчитайте
Контрольная сумма TCP / UDP:
* Вычтите IP-адрес источника в полученном пакете из
контрольная сумма.
* Добавьте реальный IP-адрес источника, полученный через IKE, в
контрольная сумма (получена из NAT-OA)
* Вычтите IP-адрес получателя из полученного пакета
от контрольной суммы.* Добавьте реальный IP-адрес назначения, полученный через IKE, в
контрольная сумма (получена из NAT-OA).
Примечание: если полученный и реальный адрес совпадают для данного
адрес (например, адрес источника), операции отменяются и
не нужно выполнять.
Huttunen, et al. Стандарты Track [Страница 5]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
2. Если заголовок протокола после заголовка ESP является заголовком TCP / UDP,
пересчитайте поле контрольной суммы в заголовке TCP / UDP.3. Если заголовок протокола после заголовка ESP является заголовком UDP, установите
нулевое значение поля контрольной суммы в заголовке UDP. Если протокол
после заголовка ESP идет заголовок TCP, и если есть опция
чтобы отметить стек, что контрольная сумма TCP не должна быть
вычислен, то этот флаг МОЖЕТ использоваться. Это ДОЛЖНО быть сделано только
для транспортного режима, и если пакет защищен целостностью.
Контрольные суммы TCP в туннельном режиме ДОЛЖНЫ быть проверены. (Это не
нарушение духа раздела 4.2.2.7 в [RFC1122], поскольку
контрольная сумма генерируется отправителем и проверяется
получатель. Эта контрольная сумма - целостность пакета.
выполняется IPsec.)
Кроме того, реализация МОЖЕТ исправить любые содержащиеся в ней протоколы, которые
были нарушены NAT (см. [RFC3715], раздел 2.1, случай g).
3.2. Инкапсуляция ESP в транспортном режиме
ПЕРЕД ПРИМЕНЕНИЕМ ESP / UDP
----------------------------
IPv4 | исходный IP hdr | | |
| (любые варианты) | TCP | Данные |
----------------------------
ПОСЛЕ ПРИМЕНЕНИЯ ESP / UDP
-------------------------------------------------- -----
IPv4 | исходный IP hdr | UDP | ESP | | | ESP | ESP |
| (любые варианты) | Hdr | Hdr | TCP | Данные | Трейлер | Auth |
-------------------------------------------------- -----
| <----- зашифровано ----> |
| <------ аутентифицировано -----> |
1.Используется обычная процедура инкапсуляции ESP.
2. Правильно отформатированный заголовок UDP вставляется туда, где показано.
3. Поля "Общая длина", "Протокол" и "Контрольная сумма заголовка" (для IPv4).
в заголовке IP редактируются, чтобы соответствовать полученному IP-пакету.
3.3. Декапсуляция ESP в транспортном режиме
1. Заголовок UDP удаляется из пакета.
2. Поля "Общая длина", "Протокол" и "Контрольная сумма заголовка (для IPv4)".
в новом IP-заголовке редактируются, чтобы соответствовать результирующему IP-пакету.
3. Применяется обычная процедура декапсуляции ЭЦН.4. Используется процедура NAT декапсуляции транспортного режима.
Huttunen, et al. Стандарты Track [Страница 6]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
3.4. Инкапсуляция ESP в туннельном режиме
ПЕРЕД ПРИМЕНЕНИЕМ ESP / UDP
----------------------------
IPv4 | исходный IP hdr | | |
| (любые варианты) | TCP | Данные |
----------------------------
ПОСЛЕ ПРИМЕНЕНИЯ ESP / UDP
-------------------------------------------------- ------------
IPv4 | новый h.| UDP | ESP | orig IP hdr | | | ESP | ESP |
| (опционы) | Hdr | Hdr | (любые варианты) | TCP | Данные | Трейлер | Auth |
-------------------------------------------------- ------------
| <------------ зашифровано -----------> |
| <------------- аутентифицирован ------------> |
1. Используется обычная процедура инкапсуляции ESP.
2. Правильно отформатированный заголовок UDP вставляется туда, где показано.
3. Поля "Общая длина", "Протокол" и "Контрольная сумма заголовка" (для IPv4).
в новом IP-заголовке редактируются, чтобы соответствовать результирующему IP-пакету.3.5. Декапсуляция ESP в туннельном режиме
1. Заголовок UDP удаляется из пакета.
2. Поля "Общая длина", "Протокол" и "Контрольная сумма заголовка (для IPv4)".
в новом IP-заголовке редактируются, чтобы соответствовать результирующему IP-пакету.
3. Применяется обычная процедура декапсуляции ЭЦН.
4. Используется процедура NAT декапсуляции туннельного режима.
4. Процедура проверки активности NAT
Единственная цель отправки пакетов NAT-keepalive - сохранить NAT
сопоставления живы на время соединения между одноранговыми узлами
(см. [RFC3715], раздел 2.2, случай j). Прием NAT-keepalive
пакеты НЕ ДОЛЖНЫ использоваться для определения наличия соединения.
Одноранговый узел МОЖЕТ отправить пакет NAT-keepalive, если одна или несколько фаз I или
SA фазы II существуют между одноранговыми узлами, или если такая SA существовала в
самое N минут назад. N - это локально настраиваемый параметр с
значение по умолчанию 5 минут.
Одноранговый узел ДОЛЖЕН отправить пакет NAT-keepalive, если в этом есть необходимость.
обнаружен согласно [RFC3947], и если нет другого пакета для однорангового узла
было отправлено через M секунд.M - параметр, настраиваемый локально.
со значением по умолчанию 20 секунд.
Huttunen, et al. Стандарты Track [Страница 7]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
5. Соображения безопасности
5.1. Конфликт туннельного режима
Разработчики предупреждаются, что удаленные узлы могут
согласовывать записи, которые перекрываются в SGW (шлюз безопасности), проблема
влияющие на туннельный режим (см. [RFC3715], раздел 2.1, случай д).
+ ---- + \ /
| | ------------- | ---- \
+ ---- + / \ \
НАТ Ари 1 \
Ноутбук \
10.1.2.3 \
+ ---- + \ / \ + ---- + + ---- +
| | ------------- | ---------- + ------ | | ---------- | |
+ ---- + / \ + ---- + + ---- +
NAT 2 Боба SGW Suzy's
Портативный сервер
10.1.2.3
Поскольку теперь SGW увидит две возможные SA, ведущие к 10.1.2.3, она
может запутаться в том, куда отправлять пакеты, исходящие от Сюзи
сервер. Разработчики ДОЛЖНЫ разработать способы предотвращения этого
происходит.
РЕКОМЕНДУЕТСЯ, чтобы SGW назначила локально уникальные IP-адреса.
к ноутбуку Ари и Боба (с помощью протокола, такого как DHCP поверх
IPsec) или используйте NAT, чтобы изменить исходный IP-адрес ноутбука Ари и Боба.
адреса на эти локально уникальные адреса перед отправкой пакетов
вперед к серверу Сюзи.Это покрывает критерии «масштабирования»
раздел 3 в [RFC3715].
См. Приложение A.
Huttunen, et al. Стандарты Track [Страница 8]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
5.2. Конфликт транспортного режима
Еще одна похожая проблема может возникнуть в транспортном режиме с 2 клиентами,
Ари и Боб, за одним NAT, безопасно разговаривают с одним и тем же сервером
(см. [RFC3715], раздел 2.1, случай e).
Клифф хочет открыто поговорить с тем же сервером.+ ---- +
| |
+ ---- + \
Ари \
Ноутбук \
10.1.2.3 \
+ ---- + \ / + ---- +
| | ----- + ----------------- | |
+ ---- + / \ + ---- +
NAT-сервер Боба
Ноутбук /
10.1.2.4 /
/
+ ---- + /
| | /
+ ---- +
Клиффа
Ноутбук
10.1.2.5
Теперь транспортные SA на сервере будут выглядеть так:
To Ari: Server to NAT, , UDP encap <4500, Y>
Бобу: с сервера на NAT, , UDP encap <4500, Z>
Трафик Клиффа открыт, поэтому нет SA.
- информация о протоколе и порте. Инкапция UDP
порты - это порты, используемые в инкапсулированном в UDP формате ESP раздела
2.1. Y, Z - динамические порты, назначаемые NAT во время IKE.
Переговоры.Итак, трафик IKE с ноутбука Ари уходит по UDP.
<4500,4500>. Он достигает сервера как UDP , где Y - это
динамически назначаемый порт.
Если перекрывается , тогда простой фильтр
поиска может быть недостаточно, чтобы определить, какой SA должен использоваться для
отправить трафик. Реализации ДОЛЖНЫ обрабатывать эту ситуацию, либо
запрещение конфликтующих подключений или другими способами.
Huttunen, et al. Стандарты Track [Страница 9] RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г. Предположим теперь, что Клифф хочет подключиться к серверу в открытом виде.Это будет сложно настроить, поскольку на сервере уже есть политика (от Сервера до внешнего адреса NAT) для защиты. Для полностью неперекрывающихся описаний трафика, это возможно. Пример политики сервера может быть следующим: To Ari: сервер в NAT, все UDP, безопасный Бобу: с сервера на NAT, весь TCP, безопасный To Cliff: с сервера на NAT, ВСЕ ICMP, открытый текст Обратите внимание, что эта политика также позволяет Ари и Бобу отправлять открытый текст ICMP на сервер.Сервер видит всех клиентов за NAT как один и тот же IP-адрес, поэтому настройка разных политик для одного и того же дескриптора трафика находится в принцип невозможно. Проблемный пример конфигурации на сервере выглядит следующим образом: Сервер для NAT, TCP, безопасный (для Ари и Боба) Сервер к NAT, TCP, очистить (для Cliff) Сервер не может обеспечить соблюдение его политики, поскольку возможно, что некорректное поведение Боб передает трафик в открытом виде. Это неотличим от того, когда Клифф посылает трафик в открытом виде.Так что невозможно гарантировать безопасность от некоторых клиентов за NAT, при этом разрешая открытый текст от разных клиентов за ОДНИМ NAT. Однако, если политика безопасности сервера допускает это, он может максимальная безопасность: если клиент из-за NAT инициирует безопасность, его соединение будет защищено. Если он пришлет ясное, сервер все равно примет этот открытый текст. Для гарантий безопасности описанный выше проблемный сценарий НЕ ДОЛЖЕН быть разрешено на серверах.Для обеспечения максимальной безопасности этот сценарий МОЖЕТ быть использовал. См. Приложение A. 6. Соображения IAB Вопросы UNSAF [RFC3424] решаются IPsec-NAT. документ требований совместимости [RFC3715]. Huttunen, et al. Стандарты Track [Страница 10]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г.
7. Благодарности
Спасибо Теро Кивинену и Уильяму Диксону, которые активно участвовали в
этот документ.Спасибо Joern Sierwald, Tamir Zegman, Tatu Ylonen и Santeri
Пааволайнен, внесший вклад в ранние документы о NAT
обход.
8. Ссылки
8.1. Нормативные ссылки
[RFC0768] Постел, Дж., «Протокол дейтаграмм пользователя», STD 6, RFC 768,
Август 1980 г.
[RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения
Уровни требований », BCP 14, RFC 2119, март 1997 г.
[RFC2401] Кент, С. и Р. Аткинсон, "Архитектура безопасности для
Интернет-протокол », RFC 2401, ноябрь 1998 г.[RFC2406] Кент, С. и Р. Аткинсон, "Безопасность инкапсуляции IP
Payload (ESP) », RFC 2406, ноябрь 1998 г.
[RFC2409] Харкинс, Д. и Д. Каррел, "Обмен ключами в Интернете"
(IKE) ", RFC 2409, ноябрь 1998 г.
[RFC3947] Кивинен, Т., "Согласование NAT-Traversal в IKE",
RFC 3947, январь 2005 г.
8.2. Информативные ссылки
[RFC1122] Брейден Р., «Требования к Интернет-хостам -
Уровни связи », STD 3, RFC 1122, октябрь 1989 г.[RFC3193] Патель, Б., Абоба, Б., Диксон, В., Цорн, Г., и С. Бут,
«Защита L2TP с помощью IPsec», RFC 3193, ноябрь 2001 г.
[RFC3424] Дейгл, Л. и IAB, "Рекомендации IAB для односторонних
Самостоятельная фиксация адреса (UNSAF) по всему сетевому адресу
Перевод », RFC 3424, ноябрь 2002 г.
[RFC3715] Абоба, Б. и У. Диксон, «Трансляция IPsec-сетевых адресов.
(NAT) Compatibility Requirements », RFC 3715, март 2004 г.
[IKEv2] Кауфман, К., "Протокол обмена ключами в Интернете (IKEv2)",
Работа в процессе, октябрь 2004 г.Huttunen, et al. Стандарты Track [Страница 11] RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г. Приложение A. Разъяснение возможных решений NAT для нескольких клиентов В этом приложении даются пояснения о возможных решениях проблема нескольких клиентов одновременно за одним NAT подключение к тому же IP-адресу назначения. В разделах 5.1 и 5.2 говорится, что вы ДОЛЖНЫ избегать этой проблемы. Как это это не вопрос проводного протокола, а вопрос локальной реализации, механизмы не относятся к самой спецификации протокола.Вместо этого они перечислены в этом приложении. Выбор варианта, вероятно, будет зависеть от сценария, для которого он использует / поддерживает IPsec NAT-T. Этот список не является исчерпывающим, поэтому могут существовать другие решения. Сначала мы опишем общий выбор которые решают проблему для всех протоколов верхнего уровня. Общие варианты транспортного режима ESP: Tr1) Реализуйте встроенный NAT (преобразование сетевых адресов) выше Декапсуляция IPsec. Tr2) Реализуйте встроенный NAPT (трансляция сетевых адресов и портов) выше декапсуляции IPsec.Tr3) Инициатор может решить не запрашивать транспортный режим после NAT. обнаружен и может вместо этого запросить SA туннельного режима. Это может быть повторить попытку после того, как ответчик отклонил транспортный режим, или Инициатор может сначала предложить туннельную SA. Это не сложнее, чем знать, предлагать ли транспортный вид или туннельный режим без NAT. Если по какой-то причине респондент предпочитает или требуется туннельный режим для прохождения NAT, он должен отклонять быстрый режим Предложение SA для вида транспорта.Общие варианты туннельного режима ESP: Tn1) То же, что и Tr1. Tn2) То же, что и Tr2. Tn3) Этот вариант возможен, если инициатору может быть назначен адрес через свой туннельный SA, а ответчик использует DHCP. В инициатор может первоначально запросить внутренний адрес через Метод DHCP-IPsec, независимо от того, знает ли он, что находится за NAT. Он может повторно инициировать согласование быстрого режима IKE для SA туннеля DHCP. после того, как отвечающая сторона отказывает в предложении транспортного режима SA быстрого режима.Это происходит либо при отправке полезной нагрузки NAT-OA, либо потому, что она Huttunen, et al. Стандарты Track [Страница 12]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г. обнаруживает от NAT-D, что инициатор находится за NAT и его локальный конфигурация / политика будет принимать только NAT-соединение, когда назначил адрес через DHCP-IPsec. Есть также варианты реализации, которые предлагают ограниченные совместимость.Разработчики должны указать, какие приложения или протоколы должны работать, если выбраны эти параметры. Обратите внимание, что ни Tr4, ни Tn4, как описано ниже, не будут работать с TCP-трафик. Ограниченные возможности взаимодействия для транспортного режима ESP: Tr4) Реализуйте осведомленность протокола верхнего уровня о входящем и исходящий IPsec SA, чтобы он не использовал исходный IP-адрес и исходный порт в качестве идентификатора сеанса (например, идентификатор сеанса L2TP, сопоставленный с пара IPsec SA, которая не использует порт источника UDP или источник IP-адрес для уникальности однорангового узла).Tr5) Реализуйте интеграцию приложения с инициированием IKE, чтобы оно может повторно подключиться к другому исходному порту, если SA быстрого режима IKE предложение отклонено ответчиком; тогда он может перепредложить новый Селектор QM. Ограниченные возможности взаимодействия для туннельного режима ESP: Tn4) То же, что Tr4. Huttunen, et al. Стандарты Track [Страница 13]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г. Адреса авторов Ари Хуттунен F-Secure Corporation Tammasaarenkatu 7 ХЕЛЬСИНКИ FIN-00181 FI Электронная почта: Ари[email protected] Брайан Свандер Microsoft Один путь Microsoft Редмонд, WA 98052 нас Электронная почта: [email protected] Виктор Вольпе Cisco Systems 124 Grove Street Люкс 205 Франклин, Массачусетс 02038 нас Электронная почта: [email protected] Ларри ДиБурро Nortel Networks Центральная улица, 80 Боксборо, Массачусетс 01719 нас Электронная почта: [email protected] Маркус Стенберг FI Электронная почта: [email protected] Huttunen, et al. Стандарты Track [Страница 14]
RFC 3948 UDP-инкапсуляция пакетов IPsec ESP, январь 2005 г. Полное заявление об авторских правах Авторские права (C) The Internet Society (2005).На этот документ распространяются права, лицензии и ограничения. содержится в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права. Этот документ и содержащаяся в нем информация размещены на Принцип "КАК ЕСТЬ" и ПОСТАВЩИК, ОРГАНИЗАЦИЯ, ПРЕДСТАВЛЯЕМЫЕ ОН / ОНА ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЕСТЬ) ИНТЕРНЕТ-ОБЩЕСТВОМ И ИНТЕРНЕТОМ ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯ ГАРАНТИЮ, ЧТО ИСПОЛЬЗОВАНИЕ ПРИСУТСТВУЮЩАЯ ИНФОРМАЦИЯ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Интеллектуальная собственность IETF не занимает никакой позиции относительно действительности или объема каких-либо Права на интеллектуальную собственность или другие права, которые могут быть заявлены на относятся к реализации или использованию технологии, описанной в этот документ или степень, в которой любая лицензия на такие права может быть, а может и нет; и не означает, что предпринял какие-либо независимые усилия для выявления любых таких прав. Информация о процедурах IETF в отношении прав в документах IETF может можно найти в BCP 78 и BCP 79.Копии раскрытия информации о правах интеллектуальной собственности в секретариат IETF и гарантии предоставления лицензий или результат попытка получить генеральную лицензию или разрешение на использование такие права собственности разработчиков или пользователей этого спецификацию можно получить в он-лайн репозитории IETF IPR по адресу http://www.ietf.org/ipr. IETF приглашает любую заинтересованную сторону довести до ее сведения любые авторские права, патенты или заявки на патенты или другие проприетарные права, которые могут распространяться на технологии, которые могут потребоваться для реализации этот стандарт.Пожалуйста, направьте информацию в IETF по адресу ietf- [email protected]. Подтверждение Финансирование функции редактора RFC в настоящее время обеспечивается Интернет-сообщество. Huttunen, et al. Стандарты Track [Страница 15]
Общие сведения о режиме туннеля VPN IPSec и транспортном режиме IPSec
Целью протоколаIPSec является предоставление услуг безопасности для IP-пакетов, таких как шифрование конфиденциальных данных, аутентификация, защита от повторного воспроизведения и конфиденциальность данных.
Как указано в нашей статье о протоколе IPSec, инкапсуляция данных безопасности (ESP) и заголовок аутентификации (AH) — это два протокола безопасности IPSec, используемые для предоставления этих услуг безопасности. Анализ протоколов ESP и AH выходит за рамки этой статьи, однако вы можете обратиться к нашей статье IPSec, где вы найдете подробный анализ и диаграммы пакетов, которые помогут прояснить концепцию.
Общие сведения о режимах IPSec — туннельный и транспортный режим
IPSec можно настроить для работы в двух различных режимах: туннельном и транспортном.Использование каждого режима зависит от требований и реализации IPSec.
Туннельный режим IPSec
Туннельный режимIPSec — это режим по умолчанию . В туннельном режиме весь исходный IP-пакет защищен IPSec. Это означает, что IPSec обертывает исходный пакет, шифрует его, добавляет новый IP-заголовок и отправляет его на другую сторону туннеля VPN (одноранговый узел IPSec).
Туннельный режим чаще всего используется между шлюзами (маршрутизаторами Cisco или межсетевыми экранами ASA) или между конечной станцией и шлюзом, при этом шлюз выступает в качестве прокси для хостов, находящихся за ним.
Туннельный режим используется для шифрования трафика между безопасными шлюзами IPSec, например, двумя маршрутизаторами Cisco, подключенными через Интернет через IPSec VPN. Конфигурация и настройка этой топологии подробно описаны в нашей статье Site-to-Site IPSec VPN. В этом примере каждый маршрутизатор действует как шлюз IPSec для своей локальной сети, обеспечивая безопасное подключение к удаленной сети:
Другим примером туннельного режима является туннель IPSec между клиентом Cisco VPN и шлюзом IPSec (например,g ASA5510 или межсетевой экран PIX). Клиент подключается к шлюзу IPSec. Трафик от клиента зашифровывается, инкапсулируется в новый IP-пакет и отправляется на другой конец. После расшифровки брандмауэром исходный IP-пакет клиента отправляется в локальную сеть.
В туннельном режиме заголовок IPSec ( AH или заголовок ESP ) вставляется между заголовком IP и протоколом верхнего уровня. Между AH и ESP ESP чаще всего используется в конфигурации туннеля IPSec VPN.
На диаграмме пакетов ниже показан режим туннеля IPSec с заголовком ESP :
ESP идентифицируется в заголовке New IP с идентификатором протокола IP , равным 50.
На диаграмме пакетов ниже показан режим туннеля IPSec с заголовком AH :
AH может применяться отдельно или вместе с ESP, когда IPSec находится в туннельном режиме.Задача AH — защитить весь пакет. AH не защищает все поля в новом IP-заголовке, потому что при передаче происходят некоторые изменения, и отправитель не может предсказать, как они могут измениться. AH защищает все, что не меняется при транспортировке. AH идентифицируется в заголовке New IP с идентификатором протокола IP , равным 51.
Транспортный режим IPSec
Транспортный режим IPSec используется для сквозной связи, например, для связи между клиентом и сервером или между рабочей станцией и шлюзом (если шлюз рассматривается как хост).Хорошим примером может служить зашифрованный сеанс Telnet или удаленного рабочего стола от рабочей станции к серверу.
Транспортный режим обеспечивает защиту наших данных, также известных как IP Payload, и состоит из заголовка TCP / UDP + данных через заголовок AH или ESP. Полезная нагрузка инкапсулируется заголовками и трейлерами IPSec. Исходные заголовки IP остаются неизменными, за исключением того, что поле протокола IP изменяется на ESP (50) или AH (51), а исходное значение протокола сохраняется в трейлере IPsec для восстановления при расшифровке пакета.
Транспортный режим IPSec обычно используется, когда другой протокол туннелирования (например, GRE) используется для первой инкапсуляции пакета данных IP, а затем IPSec используется для защиты пакетов туннеля GRE. IPSec защищает трафик туннеля GRE в транспортном режиме.
На приведенной ниже диаграмме пакетов показан транспортный режим IPSec с заголовком ESP :
Обратите внимание, что исходный IP-заголовок перемещен на передний план. Размещение IP-заголовка отправителя впереди (с незначительными изменениями идентификатора протокола) доказывает, что транспортный режим не обеспечивает защиту или шифрование исходного IP-заголовка, а ESP идентифицируется в заголовке New IP с идентификатором протокола IP . из 50 .
На диаграмме пакетов ниже показан транспортный режим IPSec с заголовком AH :
AH может применяться отдельно или вместе с ESP, когда IPSec находится в транспортном режиме. Задача AH состоит в том, чтобы защитить весь пакет, однако IPSec в транспортном режиме не создает новый заголовок IP перед пакетом, а помещает копию оригинала с некоторыми незначительными изменениями в идентификаторе протокола, поэтому не обеспечивает существенной защиты для сведения, содержащиеся в заголовке IP (IP-адрес источника, IP-адрес назначения и т. д.).AH идентифицируется в заголовке New IP с идентификатором протокола IP из 51 .
В обоих случаях ESP и AH с транспортным режимом IPSec отображается заголовок IP.
Назад к разделу сетевых протоколов
vxlans Режим инкапсуляции vni — PICOS-4.1_Configuration_Guide
Пользователь может настроить режим инкапсуляции для vxlan vni.
ПРИМЕЧАНИЕ. Коммутаторы платформы
Trident3 не поддерживают следующие команды VXLAN:
set vxlans vni
set vxlans vni
set vxlans vni
установить vxlans vni <текст> режим инкапсуляции
установить vxlans текст> режим инкапсуляции
Синтаксис команды
set vxla ns vni <текст> режим инкапсуляции
Параметр
• <текст> Идентификатор сегмента VXLAN, диапазоны десятичного формата 1-16777215 или обозначение с разделением на точки 100.100.200
• < encapsulation-mode > Настройте режим инкапсуляции туннеля vxlan. Обязательный выбор:
- нет : Ничего не изменится, нетегированные пакеты останутся нетегированными, помеченные пакеты останутся помеченными.
- service-vlan-add : Добавьте тег 802.1Q для нетегированных пакетов, и ничего не изменится с теговыми пакетами. Требуется инкапсуляция vlan.
- service-vlan-add-delete : Добавить тег 802.1Q для нетегированных пакетов и удалить тег для тегированных пакетов.Требуется инкапсуляция vlan.
- service-vlan-add-replace : добавить тег 802.1Q для нетегированных пакетов и заменить тег для тегированных пакетов. Требуется инкапсуляция vlan.
- service-vlan-delete : Удалите тег 802.1Q для помеченных пакетов, и ничего не изменится с нетегированными пакетами. Это значение по умолчанию согласно RFC 7348.
- service-vlan-replace : Заменить идентификатор vlan тега 802.