Internet Engineering Task Force (IETF) W. Wang
Request for Comments: 6956 Zhejiang Gongshang University
Category: Standards Track E. Haleplidis
ISSN: 2070-1721 University of Patras
K. Ogawa
NTT Corporation
C. Li
Hangzhou DPtech
J. Halpern
Ericsson
June 2013
Библиотека логических функциональных блоков ForCES
Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
Аннотация
Этот документ определяет базовые классы для логических функциональных блоков (LFB1) используемых в ForCES2. Базовые классы LFB определяются в соответствии с моделью элемента пересылки ForCES (FE3) и спецификацией протокола ForCES. Они привязаны к выполнению типовых функций маршрутизации и образуют базовую библиотеку LFB для ForCES. Библиотека включает описания LFB и определения XML.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF4 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG5. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc6956.
Авторские права
Авторские права (Copyright (c) 2010) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
[RFC3746] определяет модель разделения элементов управления и пересылки ForCES. В этой модели элементы управления CE (Control Element) настраивают и поддерживают один или множество элементов пересылки FE (Forwarding Element) внутри сетевого элемента NE (Network Element) с помощью протокола ForCES, спецификация которого приведена в [RFC5810]. Модель элемента пересылки определена в [RFC5812]. В этой модели ресурсы FE описываются классами логических функциональных блоков LFB. Модель FE определяет структуру и абстрактную семантику LFB, а также предоставляет схему XML для определения LFB.
Этот документ соответствует спецификации модели FE [RFC5812] и задает детальные определения классов LFB, включая подробные XML-определения LFB. Эти LFB формируют базовую библиотеку LFB для ForCES. Предполагается, что LFB в базовой библиотеке комбинируются для формирования топологии LFB в типовом маршрутизаторе для реализации пересылки IP. Следует подчеркнуть, что LFB является абстракцией функций и не включает деталей реализации. Целью определения LFB является представление функций для обеспечения взаимодействия между различными элементами CE и FE.
В будущем могут быть разработаны новые классы LFB с новыми функциями, которые будут документированы IETF. Производители также могут создавать фирменные LFB, как описано в модели FE [RFC5812].
2. Терминология и соглашения
2.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].
2.2. Определения
Этот документ следует терминологии, определенной протоколом ForCES в [RFC5810] и моделью ForCES FE в [RFC5812]. Ниже определения терминов повторены для удобства.
Control Element (CE) – элемент управления
Логический объект, который реализует протокол ForCES и инструктирует один или множество FE по части обработки пакетов. Функциональность CE включает исполнение протоколов управления и сигнализации.
Forwarding Element (FE) – элемент пересылки
Логический элемент, реализующий протокол ForCES. Элементы FE используют базовое оборудование для обработки каждого пакета и управляются (контролируются) одним или множеством CE по протоколу ForCES.
ForCES Network Element (NE) – элемент сети ForCES
Объект, состоящий из одного или множества CE и одного или множества FE. Для внешних наблюдателей NE представляется единой точкой управления и скрывает свою внутреннюю структуру от внешних наблюдателей.
Logical Function Block (LFB) – логический функциональный блок
Базовый блок, с которым работает протокол ForCES. LFB – это четко определенный, логически разделяемый функциональный блок, который размещается в FE и управляется CE по протоколу ForCES. LFB может размещаться в пути данных FE и обрабатывать потоки, а может быть чистым объектом управления и настройки FE, с которым работает CE. Отметим, что LFB является функционально точной абстракцией возможностей обработки FE, а не точным аппаратным представлением реализации FE.
FE Model – модель FE
Модель FE разработана для представления логических функций обработки элемента FE, как определено в модели ForCES FE [RFC5812]. Предложенная в этом документе модель FE включает три компоненты – модели LFB для отдельных блоков LFB (модель LFB), логических соединений между LFB (топология LFB) и атрибутов уровня FE, включая возможности FE. Модель FE обеспечивает основу для определения информационных элементов, передаваемых между CE и FE по протоколу ForCES [RFC5810].
FE Topology – топология FE
Представление соединений между множеством FE в одном NE. Иногда это называют внешней топологией FE, чтобы отличать от внутренней топологии FE (т. е. топологии LFB).
LFB Class and LFB Instance – класс и экземпляр LFB
LFB делятся на классы. Экземпляр LFB представляет существование класса (или типа) LFB. В FE может присутствовать множество экземпляров одного класса (или типа) LFB. Класс LFB представляется идентификатором класса и экземпляром LFB, представленным идентификатором экземпляра. В результате идентификатор класса и связанный с ним идентификатор экземпляра однозначно указывают наличие LFB.
LFB Meta Data – метаданные LFB
Метаданные служат для передачи информации о состоянии на уровне отдельного пакета из одного блока LFB в другой, но без передаче через сеть. Модель FE определяет для таких данных идентификацию, обработку, и восприятие (потребление) другими LFB. Модель определяет функциональность, но не задает представления метаданных внутри реализации.
LFB Component – компонента LFB
Рабочие параметры LFB, которые должны быть видимы для элементов CE и концептуально заданы моделью FE как компоненты LFB. Эти компоненты включают, например, флаги, аргументы отдельных параметров, комплексные аргументы и таблицы, которые элемент CE может читать и/или записывать по протоколу ForCES (см. ниже).
LFB Topology – топология LFB
Представление логических связей между экземплярами LFB и их размещения в пути данных внутри одного элемента FE. Иногда используется термин «внутренняя топология FE», но не следует путать ее с топологией соединений между FE (inter-FE topology).
Data Path – путь (передачи) данных
Концептуальный путь, по которому пакеты проходят через уровень пересылки внутри FE. Отметим, что в FE может существовать более одного пути данных.
ForCES Protocol – протокол ForCES
Хотя в рамках архитектуры ForCES может применяться множество протоколов, термины «протокол ForCES» и «протокол» относятся к опорным точкам Fp в модели ForCES [RFC3746]. Этот протокол не применяется к взаимодействиям между элементами CE, а также между элементами FE или между менеджерами FE и CE. В базовом варианте протокол ForCES работает в режиме «ведущий-ведомый» (master-slave), где элементы FE являются ведомыми, а CE – ведущими.
Physical Port – физический порт
Входной или выходной порт FE, соединенный с физической средой передачи. Физическим портам обычно назначаются идентификаторы, обозначаемые в форме PHYPortID. В этом документе в основном рассматриваются физические порты Ethernet.
Logical Port – логический порт
Виртуальный порт на канальном (L2) или сетевом (L3) уровне. Логическим портам обычно назначаются идентификаторы, обозначаемые LogicalPortID. Логические порты могут быть разделены по уровням L2 и L3. Логическому порту L2 может быть назначен идентификатор вида L2PortID, а логическому порту L3 – L3PortID. Порты VLAN уровня MAC относятся к логическим портам уровня L2.
LFB Port – порт LFB
Точка соединения, в которой один блок LFB может соединяться в другим внутри FE. Как указано в [RFC5812], элемент CE может соединять LFB между собой путем организации соединения между выходным портом одного экземпляра LFB и входным портом другого экземпляра. Более подробно это описано в параграфе 3.2 [RFC5812].
Singleton Port – одиночный порт
Именованный входной или выходной порт LFB. Такие порты указываются по именам. Когда контекст это позволяет, термин «одиночный» (singleton) используется для указания одиночного порта.
Group Port – групповой порт
Именованный набор входных или выходных портов LFB. Групповые порты указываются по именам. Групповой порт состоит из множества экземпляров портов, которые указываются комбинацией имени и индекса (номера).
LFB Class Library – библиотека классов LFB
Библиотека классов LFB представляет собой набор классов LFB, которые были определены как базовые функции для многих FE, и поэтому должны быть определены рабочей группой ForCES. Данный документ определяет библиотеку классов LFB.
3. Обзор
3.1. Область действия библиотеки
Предполагается, что описанные здесь классы LFB предназначены для выполнения функций типичного маршрутизатора. В [RFC1812] указано, что типичный маршрутизатор должен выполнять перечисленные ниже функции.
-
Интерфейс в пакетные сети и реализацию функций, требуемых этими сетями. Эти функции обычно включают:
-
инкапсуляцию и декапсуляцию дейтаграмм IP с кадрированием подключенной сети (например, заголовок и контрольная сумма Ethernet);
-
прием и передачу дейтаграмм IP вплоть до максимального размера, поддерживаемого сетью (MTU6);
-
трансляция IP-адреса получателя в подходящий адрес сетевого уровня для подключенной сети (например, в аппаратный адрес Ethernet) при необходимости;
-
отклик на сетевое управление потоком данных и индикацию ошибок (при их наличии).
-
Соответствие протоколам Internet, включая IP (IPv4 и/или IPv6), ICMP7 и другие требуемые протоколы.
-
Прием и пересылка дейтаграмм IP управлением буферами, контролем перегрузки и беспристрастностью.
-
Распознавание ошибок и генерация сообщений ICMP и другой информации при необходимости.
-
Отбрасывание дейтаграмм с истекшим сроком жизни (TTL = 0).
-
Фрагментирование дейтаграмм при необходимости в соответствии со значением MTU на следующем канале или интерфейсе.
-
Выбор следующего интервала (next-hop) на пути к адресату для каждой дейтаграммы IP на основе данных из таблицы маршрутов.
-
Обычно поддержка протокола IGP8 для поддержки распределенной маршрутизации и алгоритмов определения доступности с другими маршрутизаторами в своей автономной системе. В дополнение к этому некоторые маршрутизаторы должны поддерживать протокол EGP9 для обмена топологической информацией с другими автономными системами. Для всех маршрутизаторов важна возможность поддержки таблицы статических маршрутов.
-
Поддержка сетевого управления и системных функций, включая загрузку, отладку, отчеты о состоянии, запросы статистики, отчеты об исключительных ситуациях и управление.
Классический маршрутизатор IP, использующий схему ForCES, представляет собой CE, на котором работает управляющая функция IGP и/или EGP или некий набор статических маршрутов, а FE реализуются с помощью LFB, соответствующих спецификации модели FE [RFC5812]. CE в соответствии с протоколом ForCES [RFC5810] и моделью FE [RFC5812] указывает блокам LFB в FE способы обработки принимаемых и передаваемых пакетов.
Пакеты в маршрутизаторах IP принимаются и передаются в физическую среду через устройство, обычно называемое портом. Разные физические среду используют разные способы для инкапсуляции исходящих кадров и декапсуляции входящих. У различных сред будут также разные атрибуты, влияющие на поведение среды и инкапсуляцию-декапсуляцию кадров. В этом документе рассматриваются лишь физические среды Ethernet, а в будущем могут быть описаны и другие варианты. В этом документе портом называется также абстракция, включающая физический уровень (PHY) и уровень MAC10, которые описываются LFB EtherPHYCop, EtherMACIn и EtherMACOut.
Пакеты IP выходят из портов LFB и затем обрабатываются проверочными LFB до пересылки следующему LFB. После проверки пакет передается блоку LFB, где принимается решение о пересылке IP. В LFB пересылки IP применяются Longest Prefix Match LFB для поиска информации о получателе в пакете и выбора следующего интервала (next-hop) пересылки в направлении адресата. Блок next-hop LFB использует метаданные next-hop для создания нужного заголовка пакета IP и передачи пакета в нужный выход. Отметим, что рассмотрение обработки пакета IP в этом документе основано на модели «слабого хоста» (weak-host) [RFC1122], поскольку она лучше всего подходит для обработки пакетов в NE.
3.2. Обзор классов LFB в библиотеке
Важно разделить функциональные требования по разным классам LFB и создать типовую, но достаточно гибкую базовую библиотеку LFB для разных устройств пересылки IP.
3.2.1. Варианты устройства LFB
При выборе базовых LFB были учтены несколько принципов проектирования, приведенных ниже.
-
Если функцию можно реализовать в одном или нескольких LFB, выбирался вариант с несколькими LFB для повышения уровня гибкости.
-
В LFB следует максимально использовать независимость и минимальные привязки к другим LFB. Связывание LFB может задаваться определениями атрибутов, а также физическими реализациями.
-
При отсутствии явных различий в функциональности аналогичную обработку пакетов не следует представлять одновременно в нескольких LFB базовой библиотеки. Например, не следует определять два разных LFB для одной обработки next-hop, поскольку это будет осложнять совместимость и взаимодействие реализаций.
3.2.2. Группировки классов LFB
Этот документ определяет группы LFB в соответствии с потребностями типового маршрутизатора.
-
Группа LFB для обработки Ethernet определяется для абстрагирования обработки пакетов в средах Ethernet. Поскольку Ethernet является наиболее распространенным типом сред передачи с широкими возможностями обработки, эта группа LFB является логичным и естественным выбором. Определения обработки для портов иных типов сред, таких как POS11 и ATM12 могут быть добавлены в будущую версию документа или в отдельные документы. Для обработки Ethernet определены несколько LFB:
-
EtherPHYCop (параграф 5.1.1)
-
EtherMACIn (параграф 5.1.2)
-
EtherClassifier (параграф 5.1.3)
-
EtherEncap (параграф 5.1.4)
-
EtherMACOut (параграф 5.1.5)
-
Определена группа LFB для проверки пакетов IP:
-
IPv4Validator (параграф 5.2.1)
-
IPv6Validator (параграф 5.2.2)
-
Определена группа LFB для абстрагирования пересылки IP:
-
IPv4UcastLPM (параграф 5.3.1)
-
IPv4NextHop (параграф 5.3.2)
-
IPv6UcastLPM (параграф 5.3.3)
-
IPv6NextHop (параграф 5.3.4)
-
Определена группа LFB для абстрагирования перенаправления, т. е. пересылки пакетов между CE и FE:
-
RedirectIn (параграф 5.4.1)
-
RedirectOut (параграф 5.4.2)
-
Определена группа LFB для абстрагирования некоторых операций обработки общего назначения, которые обычно выполняются во многих местах топологии FE LFB:
-
BasicMetadataDispatch (параграф 5.5.1)
-
GenericScheduler (параграф 5.5.2)
3.2.3. Sample LFB Class Application
Хотя в разделе 7 будут представлены примеры использования LFB, определенных в этом документе, этот параграф также содержит простой пример использования класса LFB.
На рисунке 1 показан простой блок LFB для пути обработки пакетов Ethernet, приходящих из физических портов.
+-----+ +------+ | |EtherPHYIn | | от LFB, создающих | |<---------------|Ether |<---------- пакеты Ethernet | | |MACOut| | | | LFB | |Ether| +------+ |PHY | +------+ |Cop | | | |LFB |EtherPHYOut | Ether| в LFB, которые могут | |--------------->| MACIn|----------> классифицировать пакеты | | | LFB | Ethernet и выполнять | | | | обработку IP +-----+ +------+
Рисунок 1. Простой пример использования Sample LFB.
На этом рисунке пакеты Ethernet из внешних сетей приходят через EtherPHYCop LFB (параграф 5.1.1), описывающий свойства электрического интерфейса Ethernet (такие, как скорость) на физическом уровне. После обработки на физическом уровне пакеты Ethernet доставляются в EtherMACIn LFB (параграф 5.1.2) для описания функций обработки MAC-уровня (таких, как проверка локальности). После EtherMACIn LFB может потребоваться дополнительная обработка пакетов для реализации различных функций (таких, как пересылка IP), поэтому за EtherMACIn LFB в топологии могут следовать другие LFB, выполняющие такие функции.
Пакеты, созданные теми или иными LFB, может потребоваться передавать во внешние физические сети. Процесс описан на рисунке блоками EtherMACOut LFB (параграф 5.1.5) уровня MAC и EtherPHYCop LFB физического уровня.
3.3. Структура документа
Базовые определения типов, включая типы данных, кадров с пакетами и метаданных, представлены заранее для определения различных классов LFB. Раздел 4 содержит описания базовых типов, используемых этой библиотекой LFB. Для обеспечения возможности широкого использования этих базовых типов другими определениями классов LFB базовые типы заданы в отдельной библиотеке.
В каждой группе классов LFB определяются LFB для выполнения отдельных функций. В разделе 5 приведены описания отдельных LFB. Отметим, что для полного определения LFB нужно текстовое описание и определение XML.
Классы LFB окончательно определяются в XML со спецификациями и схемами, заданными в модели ForCES FE [RFC5812]. Раздел 6 содержит полные определения базовой библиотеки классов LFB.
В разделе 7 рассматриваются примеры реализации некоторых функций типового маршрутизатора на основе определенной в этом документе базовой библиотеки LFB.
4. Базовые типы
Модель FE [RFC5812] задает предопределенные (встроенные) неделимые (atomic) типы данных: char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], string, byte[N], boolean, octetstring[N], float16, float32 и float64.
Отметим, что в отличие от информационной модели SNMP13, называемой SMI14 [RFC2578], модель FE не определяет конкретных неделимых типов данных для целей учета. Для описания элементов LFB, относящихся к статистике пакетов, которым обычно нужны счетчики пакетов, приспособлены целые числа без знака, такие как uint32 или uint64. Этот документ указывает, что любой элемент LFB, определенный для целей подсчета, монотонно возрастает до достижения максимального значения, затем сбрасывается в 0 и снова монотонно возрастает. В документе также указано, что способы поддержки целочисленных элементов без знака может поддерживаться в случае разрыва или сброса счетчика определяются реализацией. Если предполагается, что CE придает значениям счетчиков больше смысла, чем указано выше, может потребоваться частное определение элемента между CE и FE.
На основе неделимых (atomic) типов данных можно определять типы кадров с пакетами, типы метаданных и новые типы данных с использованием элементов определения типов в схеме XML модели FE.
Для определения базовой библиотеки LFB с функциями типового маршрутизатора нужно задать базовые типы данных, типы кадров и метаданных. В этом разделе приводится краткое описание базовых типов и полное определение XML.
Определения XML для базовых типов представлены в отдельной библиотеке XML с именем BaseTypeLibrary, которую можно указать, как показано ниже.
<load library="BaseTypeLibrary" location="..."/>
4.1. Типы данных
Определенные в базовой библиотеке типы включают неделимые элементы, структуры и массивы.
4.1.1. Atomic
Ниже перечислены типы данных, определенные как неделимые (atomic) в базовой библиотеке.
|
Имя |
Описание |
|---|---|
|
IPv4Addr |
Адрес IPv4 |
|
IPv6Addr |
Адрес IPv6 |
|
IEEEMAC |
Адрес IEEE MAC |
|
LANSpeedType |
Скорость ЛВС |
|
DuplexType |
Режим дуплекса |
|
PortStatusType |
Возможные типы состояния порта (административного и рабочего) |
|
VlanIDType |
Идентификатор VLAN |
|
VlanPriorityType |
Приоритет VLAN |
|
SchdDisciplineType |
Дисциплина планирования |
4.1.2. Структуры
Ниже перечислены структурные типы данных, определенные в базовой библиотеке.
|
Имя |
Описание |
|---|---|
|
EtherDispatchEntryType |
Тип записи для таблицы диспетчеризации Ethernet |
|
VlanInputTableEntryType |
Тип записи для входной таблицы VLAN |
|
EncapTableEntryType |
Тип записи для таблицы инкапсуляции Ethernet |
|
MACInStatsType |
Тип статистики для EtherMACIn LFB |
|
MACOutStatsType |
Тип статистики для EtherMACOut LFB |
|
EtherClassifyStatsType |
Тип записи для таблицы статистики в EtherClassifier LFB |
|
IPv4PrefixInfoType |
Тип записи для таблицы префиксов IPv4 |
|
IPv6PrefixInfoType |
Тип записи для таблицы префиксов IPv6 |
|
IPv4NextHopInfoType |
Тип записи для таблицы next-hop IPv4 |
|
IPv6NextHopInfoType |
Тип записи для таблицы next-hop IPv6 |
|
IPv4ValidatorStatsType |
Тип статистики в IPv4validator LFB |
|
IPv6ValidatorStatsType |
Тип статистики в IPv6validator LFB |
|
IPv4UcastLPMStatsType |
Тип статистики в IPv4UcastLPM LFB |
|
IPv6UcastLPMStatsType |
Тип статистики в IPv6UcastLPM LFB |
|
QueueStatsType |
Тип записи для таблицы глубины очередей |
|
MetadataDispatchType |
Тип записи для таблицы диспетчеризации метаданных |
4.1.3. Массивы
Массивы чаще всего создаются на основе структур для использования в табличных компонентах LFB. Определенные в базовой библиотеке типы массивов перечислены ниже.
|
Имя |
Описание |
|---|---|
|
EtherClassifyStatsTableType |
Тип для таблицы статистики классификатора Ethernet |
|
EtherDispatchTableType |
Тип для таблицы диспетчеризации Ethernet |
|
VlanInputTableType |
Тип для входной таблицы VLAN |
|
EncapTableType |
Тип для таблицы инкапсуляции Ethernet |
|
IPv4PrefixTableType |
Тип для таблицы префиксов IPv4 |
|
IPv6PrefixTableType |
Тип для таблицы префиксов IPv6 |
|
IPv4NextHopTableType |
Тип для таблицы next-hop IPv4 |
|
IPv6NextHopTableType |
Тип для таблицы next-hop IPv6 |
|
MetadataDispatchTableType |
Тип записи для таблицы глубины очередей |
|
QueueStatsTableType |
Тип записи для таблицы диспетчеризации метаданных |
4.2. Типы кадров
В соответствии с моделью FE [RFC5812] типы кадров применяются в определениях LFB для задания пакетов, которые LFB ожидает на входных портах и передает в выходной. Для определения новых типов кадров служит элемент <frameDef> модели FE.
Определенные в базовой библиотеке типы кадров перечислены в таблице.
|
Имя |
Описание |
|---|---|
|
EthernetII |
Кадр Ethernet II |
|
ARP |
Кадр с пакетом ARP |
|
IPv4 |
Кадр с пакетом IPv4 |
|
IPv6 |
Кадр с пакетом IPv6 |
|
IPv4Unicast |
Кадр с индивидуальным пакетом IPv4 |
|
IPv4Multicast |
Кадр с групповым пакетом IPv4 |
|
IPv6Unicast |
Кадр с индивидуальным пакетом IPv6 |
|
IPv6Multicast |
Кадр с групповым пакетом IPv6 |
|
Arbitrary |
Кадр с пакетом произвольного типа |
4.3. Типы метаданных
Метаданные LFB служат для передачи связанных с пакетом состояний из одного блока LFB в другой. Для определения типов метаданных служит элемент <metadataDef> модели FE.
Определенные в базовой библиотеке типы метаданных перечислены в таблице.
|
Имя |
Идентификатор |
Описание |
|---|---|---|
|
PHYPortID |
1 |
Метаданные, указывающие идентификатор физического порта |
|
SrcMAC |
2 |
Метаданные, указывающие MAC-адрес отправителя |
|
DstMAC |
3 |
Метаданные, указывающие MAC-адрес получателя |
|
LogicalPortID |
4 |
Метаданные, указывающие идентификатор логического порта |
|
EtherType |
5 |
Метаданные, указывающие тип Ethernet |
|
VlanID |
6 |
Метаданные, указывающие идентификатор VLAN |
|
VlanPriority |
7 |
Метаданные, указывающие приоритет VLAN |
|
NextHopIPv4Addr |
8 |
Метаданные, указывающие адрес следующего интервала IPv4 |
|
NextHopIPv6Addr |
9 |
Метаданные, указывающие адрес следующего интервала IPv6 |
|
HopSelector |
10 |
Метаданные, указывающие селектор интервала |
|
ExceptionID |
11 |
Метаданные типов исключительных случаев при обработке LFB |
|
ValidateErrorID |
12 |
Метаданные типов ошибок при прохождении пакетом процесса проверки |
|
L3PortID |
13 |
Метаданные, указывающие идентификатор логического порта L3 |
|
RedirectIndex |
14 |
Метаданные, которые CE передает в RedirectIn LFB, указывая пакет, связанный с индексом выходной группы портов LFB |
|
MediaEncapInfoIndex |
15 |
Ключ пакета при поиске в таблице LFB для выбора типа инкапсуляции |
4.4. XML для библиотеки базовых типов
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseTypeLibrary">
<frameDefs>
<frameDef>
<name>EthernetAll</name>
<synopsis>Пакет с любым типом Ethernet</synopsis>
</frameDef>
<frameDef>
<name>EthernetII</name>
<synopsis>Пакет типа Ethernet II</synopsis>
</frameDef>
<frameDef>
<name>ARP</name>
<synopsis>Пакет ARP</synopsis>
</frameDef>
<frameDef>
<name>IPv4</name>
<synopsis>Пакет IPv4</synopsis>
</frameDef>
<frameDef>
<name>IPv6</name>
<synopsis>Пакет IPv6</synopsis>
</frameDef>
<frameDef>
<name>IPv4Unicast</name>
<synopsis>Индивидуальный пакет IPv4</synopsis>
</frameDef>
<frameDef>
<name>IPv4Multicast</name>
<synopsis>Групповой пакет IPv4</synopsis>
</frameDef>
<frameDef>
<name>IPv6Unicast</name>
<synopsis>Индивидуальный пакет IPv6</synopsis>
</frameDef>
<frameDef>
<name>IPv6Multicast</name>
<synopsis>Групповой пакет IPv6</synopsis>
</frameDef>
<frameDef>
<name>Arbitrary</name>
<synopsis>Любой тип пакета</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>IPv4Addr</name>
<synopsis>Адрес IPv4</synopsis>
<typeRef>byte[4]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IPv6Addr</name>
<synopsis>Адрес IPv6</synopsis>
<typeRef>byte[16]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IEEEMAC</name>
<synopsis>Адрес IEEE MAC</synopsis>
<typeRef>byte[6]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>LANSpeedType</name>
<synopsis>Скорость ЛВС</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000000">
<name>LAN_SPEED_NONE</name>
<synopsis>Ничего не подключено</synopsis>
</specialValue>
<specialValue value="0x00000001">
<name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LAN_SPEED_100M</name>
<synopsis>100M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>LAN_SPEED_1G</name>
<synopsis>1G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>LAN_SPEED_10G</name>
<synopsis>10G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000005">
<name>LAN_SPEED_40G</name>
<synopsis>40G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000006">
<name>LAN_SPEED_100G</name>
<synopsis>100G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000007">
<name>LAN_SPEED_400G</name>
<synopsis>400G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000008">
<name>LAN_SPEED_1T</name>
<synopsis>1T Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000009">
<name>LAN_SPEED_OTHER</name>
<synopsis>Другие скорости ЛВС</synopsis>
</specialValue>
<specialValue value="0x0000000A">
<name>LAN_SPEED_AUTO</name>
<synopsis>Автоматическое согласование скорости ЛВС</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>DuplexType</name>
<synopsis>Тип режима дуплекса</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>Auto</name>
<synopsis>Автоматическое согласование</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>HalfDuplex</name>
<synopsis>Полудуплекс</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>FullDuplex</name>
<synopsis>Полный дуплекс</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>PortStatusType</name>
<synopsis>
Тип для состояния порта (административного и рабочего).
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disabled</name>
<synopsis>Порт отключен</synopsis>
</specialValue>
<specialValue value="1">
<name>Up</name>
<synopsis>Порт активен</synopsis>
</specialValue>
<specialValue value="2">
<name>Down</name>
<synopsis>Порт не активен</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>MACInStatsType</name>
<synopsis>
Тип данных для статистики в EtherMACIn LFB.
</synopsis>
<struct>
<component componentID="1">
<name>NumPacketsReceived</name>
<synopsis>Число принятых пакетов</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>NumPacketsDropped</name>
<synopsis>Число отброшенных пакетов</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MACOutStatsType</name>
<synopsis>
Тип данных для статистики в EtherMACOut LFB.
</synopsis>
<struct>
<component componentID="1">
<name>NumPacketsTransmitted</name>
<synopsis>Число переданных пакетов</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>NumPacketsDropped</name>
<synopsis>Число отброшенных пакетов</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherDispatchEntryType</name>
<synopsis>
Тип данных для записи таблицы диспетчеризации Ethernet
в EtherClassifier LFB.
</synopsis>
<struct>
<component componentID="1">
<name>LogicalPortID</name>
<synopsis>Идентификатор логического порта</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>EtherType</name>
<synopsis>Тип Ethernet в пакете Ethernet.</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="3">
<name>Reserved</name>
<synopsis>
Пространство резервных битов в основном для
заполнения и эффективной упаковки.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="4">
<name>LFBOutputSelectIndex</name>
<synopsis>
Индекс пакета для выбора экземпляра в группе
выходных портов EtherClassifier LFB для вывода.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherDispatchTableType</name>
<synopsis>
Тип данных, определенный для таблицы диспетчеризации Ethernet
в EtherClassifier LFB. Таблица является массивом записей
с типом данных EtherDispatchEntryType.
</synopsis>
<array type="variable-size">
<typeRef>EtherDispatchEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>VlanIDType</name>
<synopsis>Тип данных для VLAN ID</synopsis>
<atomic>
<baseType>uint16</baseType>
<rangeRestriction>
<allowedRange min="0" max="4095"/>
</rangeRestriction>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>VlanPriorityType</name>
<synopsis>Тип данных для приоритета VLAN</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="7"/>
</rangeRestriction>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>VlanInputTableEntryType</name>
<synopsis>
Тип данных для записи входной таблицы VLAN в EtherClassifier
LFB. Каждая запись содержит идентификатор входного порта,
VLAN ID и идентификатор логического порта. Каждому входящему
пакету назначается идентификатор логического порта в соответствии
идентификатором входного порта и VLAN ID.
</synopsis>
<struct>
<component componentID="1">
<name>IncomingPortID</name>
<synopsis>Идентификатор входного порта</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>VlanID</name>
<synopsis>Идентификатор VLAN</synopsis>
<typeRef>VlanIDType</typeRef>
</component>
<component componentID="3">
<name>Reserved</name>
<synopsis>
Пространство резервных битов в основном для
заполнения и эффективной упаковки.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="4">
<name>LogicalPortID</name>
<synopsis>Идентификатор логического порта</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>VlanInputTableType</name>
<synopsis>
Тип данных для входной таблицы VLAN в EtherClassifier LFB.
Таблица является массивом записей VlanInputTableEntryType.
</synopsis>
<array type="variable-size">
<typeRef>VlanInputTableEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>EtherClassifyStatsType</name>
<synopsis>
Тип данных для записи таблицы статистики в EtherClassifier LFB.
</synopsis>
<struct>
<component componentID="1">
<name>EtherType</name>
<synopsis>Тип Ethernet для пакета Ethernet.</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="2">
<name>Reserved</name>
<synopsis>
Пространство резервных битов в основном для
заполнения и эффективной упаковки.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="3">
<name>PacketsNum</name>
<synopsis>Число пакетов</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherClassifyStatsTableType</name>
<synopsis>
Тип данных для таблицы статистики в EtherClassifier LFB.
</synopsis>
<array type="variable-size">
<typeRef>EtherClassifyStatsType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv4ValidatorStatsType</name>
<synopsis>
Тип данных для статистики в IPv4validator LFB.
</synopsis>
<struct>
<component componentID="1">
<name>badHeaderPkts</name>
<synopsis>Число пакетов с непригодным заголовком</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>
Число пакетов с некорректным общим размером
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badTTLPkts</name>
<synopsis>Число пакетов с некорректным TTL</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>badChecksumPkts</name>
<synopsis>Число пакетов с ошибкой контрольной суммы</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6ValidatorStatsType</name>
<synopsis>
Тип данных для статистики в IPv6validator LFB.
</synopsis>
<struct>
<component componentID="1">
<name>badHeaderPkts</name>
<synopsis>Число пакетов с непригодным заголовком</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>
Число пакетов с некорректным общим размером
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badHopLimitPkts</name>
<synopsis>
Число пакетов с некорректным TTL hop limit.
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixInfoType</name>
<synopsis>Тип данных для записей префиксов IPv4 в таблице
IPv4UcastLPM LFB. Адрес получателя IPv4 в каждом входном
пакете служит ключом поиска в таблице для определения
селектора следующего интервала пересылки.</synopsis>
<struct>
<component componentID="1">
<name>IPv4Address</name>
<synopsis>Адрес IPv4 для получателя</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>Prefixlen</name>
<synopsis>Размер префикса</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="32"/>
</rangeRestriction>
</atomic>
</component>
<component componentID="3">
<name>ECMPFlag</name>
<synopsis>Флаг ECMP</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>
ECMP false указывает, что для маршрута
нет множества next hop.
</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>
ECMP true указывает наличие для
маршрута множества next hop.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="4">
<name>DefaultRouteFlag</name>
<synopsis>Флаг заданного по умолчанию маршрута</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>
Default route false указывает, что маршрут
не является принятым по умолчанию.
</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>
Default route true указывает, что маршрут
является принятым по умолчанию.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="5">
<name>Reserved</name>
<synopsis>
Пространство резервных битов в основном для
заполнения и эффективной упаковки.
</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="6">
<name>HopSelector</name>
<synopsis>
HopSelector для префикса, соответствующего LFB,
который будет выдаваться в нисходящий LFB для
нахождения информации next-hop.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixTableType</name>
<synopsis>
Тип данных для таблицы префиксов IPv4 в IPv4UcastLPM LFB,
используемой для поиска максимального совпадения. Записи
таблицы имеют тип данных IPv4PrefixInfoType.
</synopsis>
<array type="variable-size">
<typeRef>IPv4PrefixInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv4UcastLPMStatsType</name>
<synopsis>
Тип данных для статистики в IPv4UcastLPM LFB.
</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>Число принятых на входе пакетов.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>Число пересланных пакетов.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>
Число пакетов с ненайденным маршрутом.
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6PrefixInfoType</name>
<synopsis>Тип данных для таблицы префиксов IPv6 в
IPv6UcastLPM LFB, служащей для поиска максимального совпадения.
Адрес получателя IPv6 служит ключом при поиске в таблице
селектора следующего интервала (next-hop).</synopsis>
<struct>
<component componentID="1">
<name>IPv6Address</name>
<synopsis>Адрес получателя IPv6</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="2">
<name>Prefixlen</name>
<synopsis>Размер префикса</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="128"/>
</rangeRestriction>
</atomic>
</component>
<component componentID="3">
<name>ECMPFlag</name>
<synopsis>Флаг ECMP</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>ECMP не используется</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>ECMP используется</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="4">
<name>DefaultRouteFlag</name>
<synopsis>Флаг принятого по умолчанию маршрута</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>Маршрут не используется по умолчанию</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>Маршрут используется по умолчанию</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="5">
<name>Reserved</name>
<synopsis>
Пространство резервных битов в основном для
заполнения и эффективной упаковки.
</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="6">
<name>HopSelector</name>
<synopsis>
HopSelector для префикса, соответствующего LFB,
который будет выдаваться в нисходящий LFB для
нахождения информации next-hop.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6PrefixTableType</name>
<synopsis>
Тип данных для таблицы префиксов IPv6 в IPv6UcastLPM LFB,
используемой для поиска максимального совпадения. Записи
таблицы имеют тип данных IPv6PrefixInfoType.
</synopsis>
<array type="variable-size">
<typeRef>IPv6PrefixInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv6UcastLPMStatsType</name>
<synopsis>Тип данных для статистики в IPv6UcastLPM LFB</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>Число принятых на входе пакетов</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>Число пересланных пакетов</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>
Число пакетов с ненайденным маршрутом.
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4NextHopInfoType</name>
<synopsis>
Тип данных для записей таблицы IPv4 next-hop в IPv4NextHop LFB.
Таблица использует селектор, полученный от восходящего LFB, в
качестве ключа для поиска индекса в таблице next-hop.
</synopsis>
<struct>
<component componentID="1">
<name>L3PortID</name>
<synopsis>
Идентификатор логического выходного порта для передачи
нисходящему LFB, указывающий, какой порт к соседу
определен уровнем L3.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MTU</name>
<synopsis>
Максимальный передаваемый блок (MTU) для выходного порта
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>NextHopIPAddr</name>
<synopsis>Адрес next-hop IPv4</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="4">
<name>MediaEncapInfoIndex</name>
<synopsis>
Индекс для передачи в нисходящий LFB инкапсуляции,
используемый в качестве ключа для поиска других
данных инкапсуляции.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>LFBOutputSelectIndex</name>
<synopsis>
Индекс для IPv4NextHop LFB, применяемый при выборе
экземпляра в группе выходных портов LFB для вывода.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4NextHopTableType</name>
<synopsis>
Тип данных для таблицы IPv4 next-hop в IPv4NextHop LFB.
Записи таблицы имеют тип IPv4NextHopInfoType.
</synopsis>
<array type="variable-size">
<typeRef>IPv4NextHopInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv6NextHopInfoType</name>
<synopsis>
Тип данных для записей таблицы IPv6 next-hop в IPv6NextHop LFB.
Таблица использует селектор, полученный от восходящего LFB, в
качестве ключа для поиска индекса в таблице next-hop.
</synopsis>
<struct>
<component componentID="1">
<name>L3PortID</name>
<synopsis>
Идентификатор логического выходного порта для передачи
нисходящему LFB, указывающий, какой порт к соседу
определен уровнем L3.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MTU</name>
<synopsis>
Максимальный передаваемый блок (MTU) для выходного порта
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>NextHopIPAddr</name>
<synopsis>Адрес next-hop IPv6</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="4">
<name>MediaEncapInfoIndex</name>
<synopsis>
Индекс для передачи в нисходящий LFB инкапсуляции,
используемый в качестве ключа для поиска других
данных инкапсуляции.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>LFBOutputSelectIndex</name>
<synopsis>
Индекс для IPv6NextHop LFB, применяемый при выборе
экземпляра в группе выходных портов LFB для вывода.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6NextHopTableType</name>
<synopsis>
Тип данных для таблицы IPv6 next-hop в IPv6NextHop LFB.
Записи таблицы имеют тип IPv6NextHopInfoType.
</synopsis>
<array type="variable-size">
<typeRef>IPv6NextHopInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>EncapTableEntryType</name>
<synopsis>
Тип данных для записи таблицы инкапсуляции Ethernet в
EtherEncap LFB. LFB использует MediaEncapInfoIndex от
восходящего LFB в качестве индекса для поиска в таблице
инкапсуляционной информации для каждого пакета.
</synopsis>
<struct>
<component componentID="1">
<name>DstMac</name>
<synopsis>
MAC-адрес получателя для Ethernet-инкапсуляции пакета.
</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="2">
<name>SrcMac</name>
<synopsis>
MAC-адрес отправителя для Ethernet-инкапсуляции пакета.
</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="3">
<name>VlanID</name>
<synopsis>VLAN ID для пакета</synopsis>
<typeRef>VlanIDType</typeRef>
</component>
<component componentID="4">
<name>Reserved</name>
<synopsis>
Пространство резервных битов в основном для
заполнения и эффективной упаковки.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="5">
<name>L2PortID</name>
<synopsis>
Идентификатор логического порта L2 для пакета.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EncapTableType</name>
<synopsis>
Тип данных для таблицы инкапсуляции Ethernet в EtherEncap
LFB. Записи таблицы имеют тип данных EncapTableEntryType.
</synopsis>
<array type="variable-size">
<typeRef>EncapTableEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>MetadataDispatchType</name>
<synopsis>
Тип данных для записи таблицы метаданных диспетчеризации
в BasicMetadataDispatch LFB. The LFB использует значение
метаданных как ключ поиска индекса в LFB группы портов
для вывода пакета.
</synopsis>
<struct>
<component componentID="1">
<name>MetadataValue</name>
<synopsis>Значение метаданных диспетчеризации</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>OutputIndex</name>
<synopsis>
Индекс группы выходных портов для исходящих пакетов.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MetadataDispatchTableType</name>
<synopsis>
Тип данных для таблицы метаданных диспетчеризации
в BasicMetadataDispatch LFB. Значение метаданных
определено также как поле ключа содержимого.
</synopsis>
<array type="variable-size">
<typeRef>MetadataDispatchType</typeRef>
<contentKey contentKeyID="1">
<contentKeyField>MetadataValue</contentKeyField>
</contentKey>
</array>
</dataTypeDef>
<dataTypeDef>
<name>SchdDisciplineType</name>
<synopsis>Тип дисциплины планирования</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="1">
<name>RR</name>
<synopsis>
Дисциплина планирования с круговым перебором
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>QueueStatsType</name>
<synopsis>
Тип данных для таблицы статистики очередей в GenericScheduler LFB.
</synopsis>
<struct>
<component componentID="1">
<name>QueueID</name>
<synopsis>Идентификатор входной очереди ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>QueueDepthInPackets</name>
<synopsis>Глубина текущей очереди в пакетах</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>QueueDepthInBytes</name>
<synopsis>Глубина текущей очереди в байтах</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>QueueStatsTableType</name>
<synopsis>
Тип данных для таблицы статистики очередей в GenericScheduler
LFB. Записи таблицы имеют тип QueueStatsType.
</synopsis>
<array type="variable-size">
<typeRef>QueueStatsType</typeRef>
</array>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>PHYPortID</name>
<synopsis>
Метаданные, указывающие идентификатор физического порта
</synopsis>
<metadataID>1</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>SrcMAC</name>
<synopsis>Метаданные, указывающие MAC-адрес отправителя</synopsis>
<metadataID>2</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>DstMAC</name>
<synopsis>
Метаданные, указывающие MAC-адрес получателя.
</synopsis>
<metadataID>3</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>LogicalPortID</name>
<synopsis>Метаданные идентификатора логического порта</synopsis>
<metadataID>4</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>EtherType</name>
<synopsis> Метаданные, указывающие тип Ethernet</synopsis>
<metadataID>5</metadataID>
<typeRef>uint16</typeRef>
</metadataDef>
<metadataDef>
<name>VlanID</name>
<synopsis>Метаданные VLAN ID</synopsis>
<metadataID>6</metadataID>
<typeRef>VlanIDType</typeRef>
</metadataDef>
<metadataDef>
<name>VlanPriority</name>
<synopsis> Метаданные VLAN priority</synopsis>
<metadataID>7</metadataID>
<typeRef>VlanPriorityType</typeRef>
</metadataDef>
<metadataDef>
<name>NextHopIPv4Addr</name>
<synopsis>
Метаданные, представляющие адрес next-hop IPv4
</synopsis>
<metadataID>8</metadataID>
<typeRef>IPv4Addr</typeRef>
</metadataDef>
<metadataDef>
<name>NextHopIPv6Addr</name>
<synopsis>
Метаданные, представляющие адрес next-hop IPv6
</synopsis>
<metadataID>9</metadataID>
<typeRef>IPv6Addr</typeRef>
</metadataDef>
<metadataDef>
<name>HopSelector</name>
<synopsis>Метаданные, указывающие селектор интервала</synopsis>
<metadataID>10</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>ExceptionID</name>
<synopsis>
Метаданные, указывающие тип исключения для исключительных
случаев в процессе обработки пакета.
</synopsis>
<metadataID>11</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0">
<name>AnyUnrecognizedExceptionCase</name>
<synopsis>Любые не распознанные исключения</synopsis>
</specialValue>
<specialValue value="1">
<name>ClassifyNoMatching</name>
<synopsis>
Исключительный случай - нет соответствия в таблице
EtherClassifier LFB.
</synopsis>
</specialValue>
<specialValue value="2">
<name>MediaEncapInfoIndexInvalid</name>
<synopsis>
Исключительный случай - значение MediaEncapInfoIndex
в пакете не приемлемо и не может быть назначено для
EncapTable в EtherEncap LFB.
</synopsis>
</specialValue>
<specialValue value="3">
<name>EncapTableLookupFailed</name>
<synopsis>
Исключительный случай - не удалось найти пакет в таблице
EncapTable блока EtherEncap LFB, хотя значение
MediaEncapInfoIndex корректно.
</synopsis>
</specialValue>
<specialValue value="4">
<name>BadTTL</name>
<synopsis>
Исключительный случай - пакет с просроченным TTL
</synopsis>
</specialValue>
<specialValue value="5">
<name>IPv4HeaderLengthMismatch</name>
<synopsis>
Исключительный случай - пакет с заголовком более 5 слов.
</synopsis>
</specialValue>
<specialValue value="6">
<name>RouterAlertOptions</name>
<synopsis>
Исключительный случай - пакет с опцией router alert
в заголовке IP.
</synopsis>
</specialValue>
<specialValue value="7">
<name>IPv6HopLimitZero</name>
<synopsis>
Исключительный случай - пакет с нулевым значением hop limit.
</synopsis>
</specialValue>
<specialValue value="8">
<name>IPv6NextHeaderHBH</name>
<synopsis>
Исключительный случай - пакет с next header = Hop-by-Hop.
</synopsis>
</specialValue>
<specialValue value="9">
<name>SrcAddressException</name>
<synopsis>
Исключительный случай - пакет с исключительный адресом
отправителя.
</synopsis>
</specialValue>
<specialValue value="10">
<name>DstAddressException</name>
<synopsis>
Исключительный случай - пакет с исключительный адресом
получателя.
</synopsis>
</specialValue>
<specialValue value="11">
<name>LPMLookupFailed</name>
<synopsis>
Исключительный случай - отказ при поиске LPM для пакета
в LFB сопоставления префикса.
</synopsis>
</specialValue>
<specialValue value="12">
<name>HopSelectorInvalid</name>
<synopsis>
Исключительный случай - непригодное значение HopSelector
для пакета.
</synopsis>
</specialValue>
<specialValue value="13">
<name>NextHopLookupFailed</name>
<synopsis>
Исключительный случай - отказ при поиске next-hop для
пакета при корректном HopSelector.
</synopsis>
</specialValue>
<specialValue value="14">
<name>FragRequired</name>
<synopsis>
Исключительный случай - требуется фрагментация пакета
</synopsis>
</specialValue>
<specialValue value="15">
<name>MetadataNoMatching</name>
<synopsis>
Исключительный случай - ничего не найдено при поиске
в таблице метаданных диспетчеризации в
BasicMetadataDispatch LFB.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>ValidateErrorID</name>
<synopsis>
Метаданные, указывающие типы ошибок при проверке пакета.
</synopsis>
<metadataID>12</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0">
<name>AnyUnrecognizedValidateErrorCase</name>
<synopsis>Нераспознанная ошибка при проверке.
</synopsis>
</specialValue>
<specialValue value="1">
<name>InvalidIPv4PacketSize</name>
<synopsis>
Ошибка - указанный канальным уровнем размер пакета
меньше 20 байтов.</synopsis>
</specialValue>
<specialValue value="2">
<name>NotIPv4Packet</name>
<synopsis>
Ошибка - пакет не относится к протоколу IP версии 4</synopsis>
</specialValue>
<specialValue value="3">
<name>InvalidIPv4HeaderLengthSize</name>
<synopsis>
Ошибка - в поле заголовка указан размер заголовка менее 5 слов.
</synopsis>
</specialValue>
<specialValue value="4">
<name>InvalidIPv4LengthFieldSize</name>
<synopsis>
Ошибка - пакет со значением общего размера менее 20 байтов.
</synopsis>
</specialValue>
<specialValue value="5">
<name>InvalidIPv4Checksum</name>
<synopsis>
Ошибка - пакет с ошибкой контрольной суммы.
</synopsis>
</specialValue>
<specialValue value="6">
<name>InvalidIPv4SrcAddr</name>
<synopsis>
Ошибка - пакет с некорректным адресом отправителя IPv4.
</synopsis>
</specialValue>
<specialValue value="7">
<name>InvalidIPv4DstAddr</name>
<synopsis>
Ошибка - пакет с некорректным адресом получателя IPv4.
</synopsis>
</specialValue>
<specialValue value="8">
<name>InvalidIPv6PacketSize</name>
<synopsis>
Ошибка - размер пакета меньше 40 байтов.
</synopsis>
</specialValue>
<specialValue value="9">
<name>NotIPv6Packet</name>
<synopsis>
Ошибка - пакет не относится к протоколу IP версии 6.
</synopsis>
</specialValue>
<specialValue value="10">
<name>InvalidIPv6SrcAddr</name>
<synopsis>
Ошибка - пакет с некорректным адресом отправителя IPv6.
</synopsis>
</specialValue>
<specialValue value="11">
<name>InvalidIPv6DstAddr</name>
<synopsis>
Ошибка - пакет с некорректным адресом получателя IPv6.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>L3PortID</name>
<synopsis>
Метаданные, указывающие идентификатор логического порта L3.
</synopsis>
<metadataID>13</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>RedirectIndex</name>
<synopsis>
Метаданные, которые CE передает RedirectIn LFB для указания индекса
LFB группы выходных портов.
</synopsis>
<metadataID>14</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>MediaEncapInfoIndex</name>
<synopsis>
Ключ, применяемый для поиска в таблице с целью выбора инкапсуляции.
</synopsis>
<metadataID>15</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
</LFBLibrary>
5. Описания классов LFB
В соответствии со спецификациями ForCES логический функциональный блок LFB представляет собой четко определенный, логически выделенный функциональный блок, который размещается в FE и является функционально точной абстракцией функций обработки в FE. Класс (тип) LFB – это шаблон, представляющий детализированный, логически отделяемый аспект обработки в FE. Большинство LFB относятся к обработке пакетов в пути данных. Классы LFB являются базовыми блоками для построения модели FE. Отметим, что в [RFC5810] уже определен FE Protocol LFB, представляющий собой логический модуль в каждом FE для управления протоколом ForCES. В [RFC5812] определен FE Object LFB, где представлена такая информация, как FE Name, FE ID, FE State, LFB Topology для FE.
Как отмечен в параграфе 3.1, этот документ посвящено базовой библиотеке LFB для реализации функций типового маршрутизатора, прежде всего в части функций пересылки IP. В результате все классы LFB в библиотеке являются базовыми LFB для реализации пересылки в маршрутизаторе.
В этом разделе применяются термины «восходящий» и «нисходящий» LFB по отношению к описываемому блоку LFB. Восходящим называется LFB, выходные порты которого подключены ко входным портам рассматриваемого LFB, т. е. данные (обычно пакеты с метаданными) могут передаваться от восходящего LFB к рассматриваемому. Нисходящим называется LFB, чьи входные порты подключены к выходным портам рассматриваемого LFB. Отметим, что в некоторых редких случаях один блок LFB может быть одновременно исходящим и нисходящим для данного LFB.
Следует также отметить, что в принятом по умолчанию для модели FE предложении [RFC5812] все метаданные, создаваемые восходящими LFB будут по умолчанию проходить через все нисходящие LFB без указания входных или выходных портов. LFB будет использовать (потреблять) лишь те метаданные, которые явно указаны на входе LFB как ожидаемые. Например, в нисходящем LFB блока LFB физического уровня даже при отсутствии конкретных ожиданий, метаданные типа PHYPortID, создаваемые LFB физического уровня, всегда будут проходить через все нисходящие LFB независимо от того, ожидаются ли они блоками LFB.
5.1. LFB для обработки Ethernet
Наиболее распространенным протоколом физического и канального уровня является Ethernet, поэтому возможность обработки пакетов данных Ethernet является базовым требованием к маршрутизаторам.
Существуют разные варианты формата Ethernet, такие как Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP, а также разные технологии ЛВС Ethernet, такие как VLAN, MACinMAC и т. д. Определенные здесь LFB для обработки Ethernet предназначены для работы со всеми вариантами технологии Ethernet.
Имеются также различные типы физических сред Ethernet, среди которых наиболее распространены электрические и оптические кабели. Будучи базовым определением LFB, данный документ рассматривает лишь среды Ethernet на основе электрических кабелей. Для других типов сред могут быть определены дополнительные LFB в будущих версиях библиотеки.
5.1.1. EtherPHYCop
EtherPHYCop LFB обеспечивает абстракцию физического уровня Ethernet для электрических кабелей.
5.1.1.1. Обработка данных
Этот LFB является интерфейсом в физическую среду Ethernet. LFB обрабатывает кадры Ethernet приходящие в FE и передаваемые из FE. Принимаемые и передаваемые кадры Ethernet включают все пакеты, инкапсулированные с разными вариантами протокола Ethernet, такими как Ethernet V2, 802.3 RAW, IEEE 802.3/802.2 и IEEE 802.3/802.2 SNAP, включая пакеты, инкапсулированные с использованием различных технологий ЛВС на базе Ethernet, таких как VLAN, MACinMAC и т. п. Поэтому в XML включен тип кадров EthernetAll.
Кадры Ethernet принимаются из физического порта и передаются нисходящим LFB, таким как EtherMACIn LFB, через одиночный выход EtherPHYOut. Метаданные PHYPortID, указывающие физический порт, через который был принят кадр извне, передаются вместе с кадром.
Пакеты Ethernet принимаются этим LFB от восходящих LFB, таких как EtherMacOut LFB, через одиночный вход EtherPHYIn для отправки вовне.
5.1.1.2. Компоненты
Компонента AdminStatus определена для CE с целью административного управления состоянием LFB. CE может включать и отключать LFB, меняя AdminStatus. По умолчанию установлено значение Down (отключено).
OperStatus фиксирует рабочее состояние физического порта. Определено событие PHYPortStatusChanged, что позволяет LFB информировать CE об изменении рабочего состояния физического порта.
PHYPortID служит для однозначного указания физического порта. Идентификаторы доступны только для чтения (read-only, устанавливается CE). Значения идентификаторов определяются FE. Компонента используется для создания метаданных PHYPortID на выходе LFB и связывания с каждым пакетом Ethernet, полученным LFB. Метаданные обрабатываются нисходящими LFB для использования PHYPortID.
Определена группа компонент для управления скоростью канала. AdminLinkSpeed используется CE для настройки скорости порта, а OperLinkSpeed позволяет CE запросить реальную скорость работы порта. По умолчанию для AdminLinkSpeed устанавливается автоматическое согласование скорости (auto-negotiation).
Определена группа компонент для управления режимом дуплекса. AdminDuplexMode используется CE для настройки режима порта, а OperDuplexMode позволяет CE запросить рабочий режим. По умолчанию для AdminDuplexMode устанавливается автоматическое согласование скорости (auto-negotiation).
CarrierStatus фиксирует состояние несущей и указывает реальное состояние канала на порту. По умолчанию CarrierStatus имеет значение false (нет сигнала).
5.1.1.3. Возможности
Информация о возможностях этого LFB включает скорости, поддерживаемые FE (SupportedLinkSpeed), а также режимы дуплекса (SupportedDuplexMode).
5.1.1.4. События
Генерируется несколько событий, одним из которых является уведомление о смене состояния физического порта (PhyPortStatusChanged). Уведомление сообщает о смене состояния и указывает новое состояния порта.
Другое событие фиксирует смену рабочей скорости соединения (LinkSpeedChanged) и уведомляет CE об изменении скорости, указывая новое согласованное значение рабочей скорости.
Еще одно событие связано с изменением режима дуплекса (DuplexModeChanged) и уведомляет CE о смене режима, указывая новый согласованный режим работы порта.
5.1.2. EtherMACIn
EtherMACIn LFB обеспечивает абстракцию порта Ethernet на канальном уровне MAC и описывает функции обработки Ethernet, такие как проверку местоположения MAC-адреса, принятие решения об использовании функций моста, управление потоком данных на уровне Ethernet и т. п.
5.1.2.1. Обработка данных
Предполагается, что этот LFB будет принимать все типы пакетов Ethernet (через одиночный вход EtherPktsIn), которые обычно будут приходить от того или иного LFB физического уровня Ethernet, такого как EtherPHYCop LFB, вместе с метаданными, указывающими идентификатор физического порта, на котором принят пакет.
В LFB определены два одиночных выходных порта. Все выходные пакеты выдаются в исходном формате Ethernet, полученном на входном порту, без изменений и включают все типы Ethernet.
Первый одиночный выход называется NormalPathOut и обычно выводит пакеты Ethernet в тот или иной LFB, такой как EtherClassifier LFB, для последующего процесса пересылки L3 вместе с метаданными PHYPortID, указывающими физический порт, принявший пакет.
Второй одиночный выход называется L2BridgingPathOut. Хотя библиотека LFB в этом документе рассчитана в основном на типичные маршрутизаторы, она пытается обеспечить совместимость с функциями будущих маршрутизаторов. Выход L2BridgingPathOut определен для выполнения требований функций мостов L2, которые могут одновременно поддерживать функции обработки L3 и некоторые L2 LFB, которые могут быть определены в будущем. Если FE поддерживает функции моста L2, CE сможет включать или отключать эти функции с помощью компоненты L2BridgingPathEnable в FE. При включенной функции создаются также некоторые экземпляры L2 LFB, следующие за L2BridgingPathOut, и FE будет выполнять функции моста L2. Выход L2BridgingPathOut будет выводить пакеты как и NormalPathOut.
Этот LFB может работать в неразборчивом (promiscuous) режиме, позволяющем всем пакетам проходить через LFB без отбрасывания. В обычном режиме выполняется проверка локальности MAC-адресов и все пакеты, которые не прошли эту проверку, будут отбрасываться.
Этот LFB может участвовать в управлении потоком данных Ethernet в кооперации с EtherMACOut LFB, но детали реализации этого не рассматриваются в данном документе. Документ также не описывает работу буферов, которые вызывают сообщения контроля потока данных, – предполагается наличие таких артефактов, но их описание выходит за рамки документа.
5.1.2.2. Компоненты
Компоента AdminStatus определена для CE с целью административного управления состоянием LFB. CE может административно запустить или отключить LFB, меняя значение AdminStatus. По умолнанию задано значение Down.
LocalMACAddresses задает локальные MAC-адреса по которым выполняется проверка местоположения. Это массив MAC-адресов с правами доступа для чтения и записи (read-write).
L2BridgingPathEnable указывает, установлен ли блок LFB для работы в качестве моста L2. FE, не поддерживающий функции моста, будет внутренними средствами устанавливать для этого флага значение false, а также устанавливать для него доступ лишь на чтение (read-only). По умолчанию устанавливается значение false.
PromiscuousMode указывает, установлен ли блок LFB для работы в неразборчивом (promiscuous) режиме. По умолчанию задано значение false.
TxFlowControl указывает, выполняет ли LFB управление потоком данных при передаче пакетов (по умолчанию false). Отметим что эта компонента указана как необязательная (optional). Если FE не реализует ее, а CE пытается настроить, FE может сообщить CE об ошибке с кодом 0x09 (E_COMPONENT_DOES_NOT_EXIST) или 0x15 (E_NOT_SUPPORTED), в зависимости от обработки FE. Подробности приведены в [RFC5810].
RxFlowControl указывает, выполняет ли LFB управление потоком данных при получении пакетов (по умолчанию false). Компонента помечена как необязательная (optional).
Структурная компонента MACInStats определяет набор параметров статистики для этого LFB, включая число принятых и отброшенных пакетов. Отметим, что компонента не является обязательной для реализации. Если CE пытается запросить эту компоненту, а она не реализована, возвращается ошибка 0x09 (E_COMPONENT_DOES_NOT_EXIST) или 0x15 (E_NOT_SUPPORTED) в зависимости от реализации FE.
5.1.2.3. Возможности
У этого LFB нет списка возможностей.
5.1.2.4. События
Этот LFB не задает каких-либо событий.
5.1.3. EtherClassifier
EtherClassifier LFB является абстракцией процесса декапсуляции пакетов Ethernet и последующей их классификации.
5.1.3.1. Обработка данных
LFB описывает процесс декапсуляции пакетов Ethernet и их классификации в соответствии с информацией из заголовок пакета Ethernet.
Предполагается, что LFB принимает все типы пакетов Ethernet (через отдельный вход EtherPktsIn), которые обычно выводятся восходящим LFB, таким как EtherMACIn LFB. Этот вход также поддерживает мультиплексирование, позволяющее подключать множество восходящих LFB. Например, при включенной функции моста L2 в EtherMACIn LFB могут применяться некоторые LFB мостов L2. В этом случае после обработки L2 некоторые пакеты Ethernet могут попадать на вход EtherClassifier LFB для классификации, тогда как пакетам, напрямую выходящим из EtherMACIn тоже может потребоваться вход в этот LFB. Данный вход способен обрабатывать такие случаи. Обычно все ожидаемые пакеты Ethernet будут связаны с метаданными PHYPortID, указывающими физический порт, из которого поступил пакет. В некоторых случаях (например, MACinMAC) может предполагаться связывание метаданных LogicalPortID с пакетом Ethernet для дополнительного указания логического порта, к которому относится пакет Ethernet. Отметим, что метаданные PHYPortID предполагаются всегда, а метаданные LogicalPortID являются необязательными.
В LFB определены два выходных порта.
Первый выход является групповым портом ClassifyOut. Типы пакетов протоколов сетевого уровня выводятся в экземпляры группы портов. Поскольку может быть много разных типов протоколов на выходных портах, создаваемый выходной кадр определяется как произвольный с возможностью расширения определения в будущем. Метаданные, для передачи вместе с пакетом создаются в этом LFB для использования нисходящими LFB. Передаваемые вниз метаданные включают PHYPortID, а также информацию о типе Ethernet, MAC-адреса отправителя и получателя и идентификатор логического порта. Если исходный пакет является пакетом VLAN и содержит значения идентификатора и приоритета, эти значения также передаются в метаданных в нисходящем направлении. В результате эти метаданные VLAN ID определены как условные (conditional).
Вторым выходом является отдельный выходной порт ExceptionOut, который будет выводить пакеты при отказе в процессе обработки вместе с дополнительными метаданными ExceptionID для указания причины отказа. В настоящее время определено одно исключение:
-
не найдено соответствия при классификации пакета.
Обычно порт ExceptionOut может не указывать никуда, что означает отбрасывание пакетов, но в некоторых случаях пакеты могут передаваться в CE для дополнительной обработки в зависимости от конкретной реализации.
5.1.3.2. Компоненты
Массив EtherDispatchTable определен в LFB для диспетчеризации каждого пакета Ethernet в выходную группу в соответствии с идентификатором логического порта, назначенным VlanInputTable для пакета, и типом Ethernet в заголовке. Каждая строка массива является структурой, содержащей идентификатор логического порта, EtherType и индекс выхода. При настройке таблицы диспетчеризации со стороны CE можно ожидать, что LFB будет классифицировать пакеты разных протоколов сетевого уровня и выводить их в разные выходные порты. Предполагается, что LFB будет классифицировать пакеты по протоколам, таким как IPv4, IPv6, MPLS, ARP, ND15 и т. п.
Массив VlanInputTable определен в LFB для классификации пакетов VLAN Ethernet. Каждая строка массива является структурой, включающей идентификатор входного порта, VLAN ID и идентификатор логического порта. В соответствии со спецификацией IEEE VLAN все пакеты Ethernet могут распознаваться как относящиеся к VLAN путем назначения пакетов без инкапсуляции VLAN к VLAN 0. Каждому входному пакету назначается новый LogicalPortID в соответствии и идентификатором входного порта и VLAN ID. Идентификатор входного порта определяется как идентификатор логического порта, если с пакетом связан логический порт, или как идентификатор физического порта, если логический порт не привязан к пакету. VLAN ID берется из пакета или назначается VLAN 0, если в пакете нет тега. Отметим, что идентификатор логического порта для пакета может быть изменен при обработке VlanInputTable.
Отметим, что упомянутые выше идентификаторы логического и физического порта изначально задаются CE и являются глобальными в рамках ForCES NE (элемент сети). Чтобы не путать идентификаторы логических и физических портов в поле идентификатора входного порта VlanInputTable, значения идентификаторов физических и логических портов должны назначаться из разных числовых диапазонов.
Массив EtherClassifyStats определяет набор параметров статистики для данного LFB, указываемых числом пакетов для каждого EtherType. Каждая строка массива является структурой, включающей EtherType и число пакетов. Отметим, что реализация этого массива необязательна.
5.1.3.3. Возможности
У этого LFB нет списка возможностей.
5.1.3.4. События
Этот LFB не задает каких-либо событий.
5.1.4. EtherEncap
EtherEncap LFB является абстракцией процесса замены заголовков Ethernet и добавления в пакет новых заголовков.
5.1.4.1. Обработка данных
LFB абстрагирует процесс встраивания (инкапсуляции) заголовков Ethernet в полученные пакеты. Инкапсуляция основана на передаче метаданных. Предполагается, что LFB принимает пакеты IPv4 и IPv6 через отдельный входной порт EncapIn, который может быть соединен с восходящим LFB типа IPv4NextHop, IPv6NextHop, BasicMetadataDispatch или иным LFB, которому нужно выводить пакеты для инкапсуляции Ethernet. LFB всегда ждет от восходящих LFB метаданные MediaEncapInfoIndex, которые служат ключом поиска в таблице инкапсуляции EncapTable. Входной пакет может также иметь метаданные VLAN priority, указывающие исходный приоритет для пакета. Значение приоритета может быть установлено в пакете снова при инкапсуляции. По умолчанию для приоритета VLAN задано значение 0.
Для LFB определены два отдельных выходных порта.
Первый одиночный выход называется SuccessOut. При успешном поиске в таблице MAC-адреса отправителя и получателя, а также логический порт среды (L2PortID) находятся в соответствующей записи таблицы. CE может установить VlanID в случае использования VLAN. По умолчанию применяется запись с VlanID 0 в соответствии с правилами IEEE [IEEE.802-1Q]. Независимо от значения VlanID, если во входных метаданных значение VlanPriority отлично от 0, пакет получает тен VLAN. Если VlanPriority и VlanID равны 0, тег VLAN не назначается пакету. После замены или добавления подходящих заголовков Ethernet пакет передается на выход SuccessOut для нисходящего экземпляра LFB вместе с метаданными L2PortID.
Второй одиночный выход называется ExceptionOut и предназначен для пакетов с отказом при поиске в таблице вместе с метаданными ExceptionID. В настоящее время определены два исключительных случая:
-
значение MediaEncapInfoIndex в пакете недействительно и отсутствует в EncapTable;
-
пакет не найден в таблице EncapTable, хотя значение MediaEncapInfoIndex действительно.
Восходящий LFB может программироваться CE для передачи вместе с MediaEncapInfoIndex, которого нет в EncapTable. Это позволит при необходимости распознавать заголовки на уровне инкапсуляции L2 через ARP или ND (или иной метод в зависимости от технологии канального уровня) при отсутствии записи в таблице.
Для распознания соседского заголовка L2 (исключение table miss) обрабатывающий LFB может передать пакет CE через LFB перенаправления, программу FE или другой экземпляр LFB. В таких случаях для обработки исключения передаются также метаданные NextHopIPv4Addr или NextHopIPv6Addr, генерируемые next-hop LFB. Такой адрес IP может применяться для выполнения таких операций, как ARP или ND, в обработчике, которому передан пакет.
Результатом распознавания L2 служит обновление EncapTable, а также next-hop LFB, чтобы для последующих пакетов поиск в EncapTable не завершался отказом. EtherEncap LFB не делает предположений о способе обновления EncapTable элементом CE (а также использовании ARP/ND или статического отображения).
Экземпляры нисходящих LFB могут иметь тип EtherMACOut или BasicMetadataDispatch. Если финальная обработка пакета L2 выполняется по портам сред, относящимся к разным FE, или нужно распознавание заголовка L2, модели имеет смысл принять BasicMetadataDispatch LFB для ответвления в разные экземпляры LFB. Если имеется прямой выходной порт, имеет смысл применение в качестве экземпляра нисходящего LFB блока EtherMACOut.
5.1.4.2. Компоненты
Этот LFB имеет единственную компоненту EncapTable, определенную как массив. Каждая строка массива является структурой, содержащей MAC-адреса получателя и отправителя, VLAN ID (по умолчанию 0) и идентификатор выходного логического порта L2.
5.1.4.3. Возможности
У этого LFB нет списка возможностей.
5.1.4.4. События
Этот LFB не задает каких-либо событий.
5.1.5. EtherMACOut
EtherMACOut LFB абстрагирует порт Ethernet на уровне MAC и описывает процесс вывода пакетов Ethernet. Выходные функции Ethernet тесно связаны со входными, поэтому многие компоненты этого LFB являются псевдонимами компонент EtherMACIn LFB.
5.1.5.1. Обработка данных
LFB предполагает получение всех типов пакетов Ethernet (через отдельный входной порт EtherPktsIn), которые обычно выходят и LFB инкапсуляции Ethernet вместе с метаданными, указывающими идентификатор физического порта, через который должен пройти пакет.
LFB определен с одиночным выходным портом EtherPktsOut. Все выходные пакеты имеют формат Ethernet, возможно различаясь типом Ethernet, и сопровождаются метаданными, указывающими идентификатор физического порта, через который пакет должен пройти. Это выходные каналы связаны с нисходящим LFB, которым служит LFB физического уровня Ethernet, подобный EtherPHYCop LFB.
Этот LFB может участвовать в управлении потоком данных Ethernet в кооперации с EtherMACIn LFB. Данный документ не описывает деталей этого процесса и не определяет поведения буферов для управления потоком данных. Предполагается такая возможность, но ее описание выходит за рамки документа.
Отметим, что в качестве базового определения такие функции, как множество виртуальных уровней MAC, не поддерживаются этой версией LFB. Они могут быть добавлены в будущем путем определения субкласса или новой версии этого LFB.
5.1.5.2. Компоненты
AdminStatus служит для того, чтобы CE мог административно управлять состоянием LFB, включая и выключая его путем установки значения AdminStatus (по умолчанию Down – отключено). Отметим, что эта компонента определена как псевдоним AdminStatus в EtherMACIn LFB. Это предполагает, что EtherMACOut LFB обычно сосуществует с EtherMACIn LFB и оба используют одинаковое административное управление состоянием со стороны CE. Свойства псевдонима, как определено в модели ForCES FE [RFC5812], будут применяться CE для задания целевой компоненты, к которой относится псевдоним, указывая целевой класс LFB, идентификаторы экземпляров, а также путь к целевой компоненте.
MTU определяет максимальный размер передаваемого блока.
Необязательная компонента TxFlowControl указывает, выполняется ли этим LFB управление потоком данных при передаче пакетов (по умолчанию false). Отметим, что эта компонента определена как псевдоним компоненты TxFlowControl в EtherMACIn LFB.
Необязательная компонента RxFlowControl указывает, выполняется ли этим LFB управление потоком данных на приеме (по умолчанию false). Отметим, что эта компонента определена как псевдоним компоненты RxFlowControl в EtherMACIn LFB.
Структурная компонента MACOutStats определяет набор статистики для данного LFB, включающей число переданных и отброшенных пакетов. Компонента не обязательна для реализации.
5.1.5.3. Возможности
У этого LFB нет списка возможностей.
5.1.5.4. События
Этот LFB не задает каких-либо событий.
5.2. LFB для проверки пакетов IP
Определены LFB для абстрагирования проверки пригодности пакетов IP – IPv4Validator LFB для IPv4 и IPv6Validator LFB для IPv6.
5.2.1. IPv4Validator
IPv4Validator LFB выполняет проверку пригодности пакетов IPv4.
5.2.1.1. Обработка данных
Этот LFB выполняет проверку пригодности пакетов IPv4 в соответствии с [RFC1812] и последующими обновлениями. Пакет IPv4 будет выводиться в соответствующий порт LFB, указывающий, относится пакет к индивидуальным или групповым и были ли отказы или исключительные ситуации при проверке.
Этот LFB всегда ожидает на входе пакеты, классифицированные как IPv4 восходящим LFB, таким как EtherClassifier LFB. Конкретные метаданные на входе LFB не ожидаются.
Для LFB определены 4 выходных порта.
Все прошедшие проверку индивидуальные пакеты IPv4 будут выводиться в одиночный порт IPv4UnicastOut, а групповые – в одиночный порт IPv4MulticastOut.
Одиночный порт ExceptionOut определен для вывода пакетов, которые прошли проверку как исключительные. Метаданные с идентификатором исключения создаются для указания причины исключения. Исключением считается случай, когда пакет требует дополнительной обработки перед обычной пересылкой. Определенные в настоящий момент типы исключений перечислены ниже.
-
Пакеты с нулевым TTL.
-
Пакеты с размером заголовка более 5 слов.
-
Пакеты с заголовком, включающим опцию router alert.
-
Пакеты с исключительным адресом отправителя.
-
Пакеты с исключительным адресом получателя.
Отметим, что проверка TTL выполняется в этом LFB, но операции с TTL (например, декремент) выполняются нисходящим LFB пересылки.
Одиночный порт FailOut служит для пакетов, при проверке которых возникли ошибки (отказ). Ошибкой считается случаи, когда пакет не пригоден для дальнейшей обработки или пересылки и должен отбрасываться. Связанный с пакетом идентификатор ошибки указывает причину. В настоящее время определено несколько причин отказа:
-
размер пакета меньше 20 байтов;
-
версия пакета отличается от IPv4;
-
размер заголовка в пакете меньше 5 слов;
-
поле общего размера пакета имеет значение меньше 20;
-
ошибка контрольной суммы;
-
недействительный адрес отправителя;
-
недействительный адрес получателя.
5.2.1.2. Компоненты
Этот LFB имеет единственную структурную компоненту IPv4ValidatorStatisticsType, определяющую параметры статистики для процесса проверки пригодности, включая число пакетов с некорректными заголовками, некорректным размером, непригодным TTL и ошибками в контрольной сумме. Эта компонента не обязательна для реализации.
5.2.1.3. Возможности
У этого LFB нет списка возможностей.
5.2.1.4. События
Этот LFB не задает каких-либо событий.
5.2.2. IPv6Validator
IPv6Validator LFB выполняет проверку пригодности пакетов IPv6.
5.2.2.1. Обработка данных
Этот LFB выполняет проверку пригодности пакетов IPv6 в соответствии с [RFC2460] и последующими обновлениями. Пакет IPv6 будет выводиться в соответствующий порт LFB, указывающий, относится пакет к индивидуальным или групповым и были ли отказы или исключительные ситуации при проверке.
Этот LFB всегда ожидает на входе пакеты, классифицированные как IPv6 восходящим LFB, таким как EtherClassifier LFB. Конкретные метаданные на входе LFB не ожидаются.
Как и в IPv4validator LFB для этого LFB определены 4 выходных порта, в которые пакеты передаются в соответствии с результатом проверки.
Все прошедшие проверку индивидуальные пакеты IPv6 будут выводиться в одиночный порт IPv6UnicastOut, а групповые – в одиночный порт IPv6MulticastOut.
Одиночный порт ExceptionOut определен для вывода пакетов, которые прошли проверку как исключительные. Метаданные с идентификатором исключения создаются для указания причины исключения. Исключением считается случай, когда пакет требует дополнительной обработки перед обычной пересылкой. Определенные в настоящий момент типы исключений перечислены ниже.
-
Пакеты с нулевым hop limit.
-
Пакеты с next header установленным в hop-by-hop.
-
Пакеты с исключительным адресом отправителя.
-
Пакеты с исключительным адресом получателя.
Одиночный порт FailOut служит для пакетов, при проверке которых возникли ошибки (отказ). Ошибкой считается случаи, когда пакет не пригоден для дальнейшей обработки или пересылки и должен отбрасываться. Связанный с пакетом идентификатор ошибки указывает причину. В настоящее время определено несколько причин отказа:
-
размер пакета меньше 40 байтов;
-
версия пакета отличается от IPv6;
-
недействительный адрес отправителя;
-
недействительный адрес получателя.
Отметим, что в базовой библиотеке типов определения идентификаторов метаданных исключений и ошибок применяются для IPv4Validator и IPv6Validator, т. е. эти два LFB используют общее определение метаданных с разными идентификаторами в нем.
5.2.2.2. Компоненты
Этот LFB имеет единственную структурную компоненту IPv6ValidatorStatisticsType, определяющую параметры статистики для процесса проверки пригодности, включая число пакетов с некорректными заголовками, некорректным размером, непригодным значением hop limit. Эта компонента не обязательна для реализации.
5.2.2.3. Возможности
У этого LFB нет списка возможностей.
5.2.2.4. События
Этот LFB не задает каких-либо событий.
5.3. LFB для пересылки IP
IP Forwarding LFB абстрагируют процессы пересылки IP. Для базовой библиотеки область определения LFB ограничивается пересылкой индивидуальных пакетов IP. Групповые пакеты IP могут быть рассмотрены в будущем.
Двумя фундаментальными задачами индивидуальной пересылки IP являются поиск информации в таблице пересылки для определения следующего интервала и применение найденной информации для выбора конкретных физических выходных портов. Этот документ моделирует процессы пересылки путем абстрагирования двух отмеченных задач. Поскольку документ описывает функциональные модели LFB, которые являются модульными, возможно множество способов реализации абстрактных моделей. Не предполагается ограничение реализаций представленными моделями LFB.
На основе абстракции пересылки IP определены два типовых блока индивидуальной пересылки IP – LFB для поиска LPM16 и LFB для применения next-hop. Оба LFB имеют варианты для протоколов IPv4 и IPv6.
5.3.1. IPv4UcastLPM
IPv4UcastLPM LFB абстрагирует процесс поиска LPM для индивидуальных адресов IPv4.
LFB также обеспечивает средства для упрощения маршрутизации по множеству равноценных путей (ECMP17) и пересылки по обратному пути (RPF18). Однако сам LFB не обеспечивает ECMP или RPF. Для реализации их будут определены специальные LFB, например ECMP LFB и RPF LFB.
5.3.1.1. Обработка данных
LFB выполняет поиск индивидуальных адресов IPv4 в таблице LPM. На входе всегда предполагаются индивидуальные пакеты IPv4 из одиночного входного порта PktsIn. LFB использует адрес получателя IPv4 в каждом пакете как ключ поиска в таблице префиксов IPv4 и создает селектор интервала (hop) в соответствии с результатом. Селектор передается как метаданные пакета нисходящим LFB и обычно служит в качестве поискового индекса для поиска дополнительной информации о следующем интервале (next-hop).
В LFB определены три одиночных выходных порта.
Первый одиночный порт NormalOut выводит индивидуальные пакеты IPv4, для которых найден LPM (и селектор интервала). Селектор связывается с пакетом как метаданные. Нисходящим для LPM LFB обычно является LFB следующего интервала пересылки, такой как IPv4NextHop LFB.
Второй одиночный порт ECMPOut определен для поддержки пользователей, желающих реализовать ECMP.
Флаг ECMP определен в таблице LPM для поддержки в LFB маршрутизации ECMP. Если этот флаг установлен для записи в таблице, это указывает, что запись предназначена лишь для ECMP. Пакеты, соответствующие такой записи, всегда будут выводиться через порт ECMPOut, а селектор интервала будет указывать результат поиска. Выходом обычно является нисходящий LFB для обработки ECMP, где селектор интервала позволяет создать одно или несколько значений next-hop для использования алгоритмами ECMP.
Флаг маршрута по умолчанию определен в таблице LPM для поддержки в LFB принятого по умолчанию маршрута, а также управления пересылкой RPF. При установленном флаге запись таблицы считается принятым по умолчанию маршрутом с запретом пересылки RPF. Если пользователь хочет реализовать RPF в FE, нужно определить конкретный блок RPF LFB. В таком RPF LFB может быть определена компонента, являющаяся псевдонимом компоненты IPv4PrefixTable в этом LFB, которая описана ниже.
Последний одиночный порт ExceptionOut в IPv4UcastLPM LFB определен для вывода пакетов с исключительными ситуациями при обработке вместе с метаданными ExceptionID, указывающими причину. Определена одна причина:
-
не найдено соответствия при поиске LPM в таблице префиксов.
Восходящим для этого LFB обычно служит IPv4Validator LFB. При использовании RPF это может быть RPF LFB, когда он будет определен.
Нисходящим LFB обычно является IPv4NextHop LFB. При использовании ECMP это может быть ECMP LFB, когда он будет определен.
5.3.1.2. Компоненты
Этот LFB имеет две компоненты.
IPv4PrefixTable является массивом, каждая строка которого содержит адрес IPv4, размер префикса, селектор интервала, флаги ECMP и маршрута по умолчанию. LFB использует адрес получателя IPv4 в каждом входящем пакете как ключ поиска в этой таблице для извлечения селектора next-hop. Флаг ECMP в LFB служит для поддержки ECMP, а флаг маршрута по умолчанию для поддержки такого маршрута и управления RPF.
Структурная компонента IPv4UcastLPMStats служит для сбора статистики, включая общее число принятых пакетов, число пакетов IPv4, пересланных этим LFB, а также число дейтаграмм IP отброшенных по причине отсутствия маршрута. Отметим, что эта компонента не обязательна для реализации.
5.3.1.3. Возможности
У этого LFB нет списка возможностей.
5.3.1.4. События
Этот LFB не задает каких-либо событий.
5.3.2. IPv4NextHop
Этот LFB абстрагирует процесс выбора IPv4 next-hop.
5.3.2.1. Обработка данных
LFB абстрагирует процесс применения данных о следующем интервале к пакетам IPv4. Он получает пакеты IPv4 с идентификатором следующего интервала (HopSelector) и применяет этот идентификатор как индекс таблицы для поиска подходящего выходного порта LFB.
LFB ожидает приема индивидуальных пакетов IPv4 через одиночный порт PktsIn вместе с метаданными HopSelector, которые служат индексом для поиска в таблице NextHop. Обработка данных включает уменьшение TTL и расчет контрольной суммы IP.
В LFB определены два выходных порта.
Первый порт является групповым и называется SuccessOut. При успешной обработке данных пакет передается из группового порта LFB в соответствии со значением LFBOutputSelectIndex, соответствующим записи в таблице. Пакет передается в нисходящий LFB с метаданными L3PortID и MediaEncapInfoIndex.
Вторым выходным портом является одиночный порт ExceptionOut, в который выводятся данные при возникновении исключительных ситуаций в процессе обработки вместе с метаданными ExceptionID, указывающими причину исключения. В настоящий момент определено несколько причин, приведенных ниже.
-
HopSelector для пакета не пригоден.
-
Отказ при поиске в таблице next-hop при корректном HopSelector.
-
MTU выходного интерфейса меньше размера пакета.
Экземпляры нисходящих LFB могут иметь тип BasicMetadataDispatch (параграф 5.5.1), используемый для распределения по разным экземплярам LFB, или связанный с инкапсуляций в среду тип, такой как EtherEncap или RedirectOut (параграф 5.4.2). Например при наличии Ethernet или другой туннельной инкапсуляции BasicMetadataDispatch LFB может использовать метаданные L3PortID (параграф 5.3.2.2) для диспетчеризации пакетов разным инкапсуляторам.
5.3.2.2. Компоненты
Этот LFB имеет одну компоненту – массив IPv4NextHopTable. Полученное значение HopSelector служит индексом массива IPv4NextHopTable для поиска строки с информацией next-hop. Структура строк массива описана ниже.
-
Идентификатор логического порта L3PortID, который передается экземпляру нисходящего LFB. Этот идентификатор указывает тип инкапсулирующего порта, который должен использовать сосед. Эта информация, полученная от L3, влияет на обработку L2 и поэтому должна основываться на метаданных, передаваемых между LFB. Обычно этот идентификатор применяется для LFB следующего интервала, чтобы различать пакеты, которым нужна разная инкапсуляция L2. Например, некоторым пакетам может требоваться базовая инкапсуляция Ethernet, а другим – туннельная инкапсуляция того или иного типа. В таких случаях пакетам назначаются разные L3PortID, которые передаются в виде метаданных нисходящему LFB. Блок BasicMetadataDispatch LFB (параграф 5.5.1) может служить таким нисходящим LFB для диспетчеризации пакетов экземплярам LFB с разной инкапсуляцией в соответствии с L3PortID.
-
MTU – максимальный размер блока на выходном порту.
-
NextHopIPAddr – адрес IPv4.
-
MediaEncapInfoIndex передается нисходящему LFB инкапсуляции и служит ключом поиска в таблице (обычно связанной с инкапсуляцией для разных сред). Отметим, что экземпляр LFB инкапсуляции, использующий эти метаданные, может не следовать непосредственно за данным LFB в процессе обработки. Метаданные MediaEncapInfoIndex добавляются к пакету и передаются через промежуточные LFB, пока не будут применены экземпляром LFB инкапсуляции. В зависимости от реализации CE может устанавливать для MediaEncapInfoIndex, передаваемого в нисходящем направлении, значение, которое будет приводить к отказу при поиске в целевом LFB инкапсуляции. Это будет говорить о том, что нужно дополнительное распознавание. Пример этого показан в параграфе 7.2, где обсуждается протокол ARP.
-
LFBOutputSelectIndex является индексом группового выходного порта LFB для выбора порта нисходящего LFB. Это значение указывает конкретный порт группы SuccessOut, через который будет выводиться пакет с найденной информацией next-hop.
5.3.2.3. Возможности
У этого LFB нет списка возможностей.
5.3.2.4. События
Этот LFB не задает каких-либо событий.
5.3.3. IPv6UcastLPM
IPv6UcastLPM LFB абстрагирует процесс поиска LPM для индивидуальных адресов IPv6. Определение этого LFB похоже на определение IPv4UcastLPM LFB, но адреса IP в нем относятся к IPv6.
LFB также обеспечивает средства для упрощения маршрутизации по множеству равноценных путей (ECMP) и пересылки по обратному пути (RPF). Однако сам LFB не обеспечивает ECMP или RPF. Для реализации их будут определены специальные LFB, например ECMP LFB и RPF LFB.
5.3.3.1. Обработка данных
LFB выполняет поиск индивидуальных адресов IPv6 в таблице LPM. На входе всегда предполагаются индивидуальные пакеты IPv6 из одиночного входного порта PktsIn. LFB использует адрес получателя IPv6 в каждом пакете как ключ поиска в таблице префиксов IPv6 и создает селектор интервала (hop) в соответствии с результатом. Селектор передается как метаданные пакета нисходящим LFB и обычно служит в качестве поискового индекса для поиска дополнительной информации о следующем интервале (next-hop).
В LFB определены три одиночных выходных порта.
Первый одиночный порт NormalOut выводит индивидуальные пакеты IPv6, для которых найден LPM (и селектор интервала). Селектор связывается с пакетом как метаданные. Нисходящим для LPM LFB обычно является LFB следующего интервала пересылки, такой как IPv6NextHop LFB.
Второй одиночный порт ECMPOut определен для поддержки пользователей, желающих реализовать ECMP.
Флаг ECMP определен в таблице LPM для поддержки в LFB маршрутизации ECMP. Если этот флаг установлен для записи в таблице, это указывает, что запись предназначена лишь для ECMP. Пакеты, соответствующие такой записи, всегда будут выводиться через порт ECMPOut, а селектор интервала будет указывать результат поиска. Выходом обычно является нисходящий LFB для обработки ECMP, где селектор интервала позволяет создать одно или несколько значений next-hop для использования алгоритмами ECMP.
Флаг маршрута по умолчанию определен в таблице LPM для поддержки в LFB принятого по умолчанию маршрута, а также управления пересылкой RPF. При установленном флаге запись таблицы считается принятым по умолчанию маршрутом с запретом пересылки RPF. Если пользователь хочет реализовать RPF в FE, нужно определить конкретный блок RPF LFB. В таком RPF LFB может быть определена компонента, являющаяся псевдонимом компоненты IPv6PrefixTable в этом LFB, которая описана ниже.
Последний одиночный порт ExceptionOut в IPv6UcastLPM LFB определен для вывода пакетов с исключительными ситуациями при обработке вместе с метаданными ExceptionID, указывающими причину. Определена одна причина:
-
не найдено соответствия при поиске LPM в таблице префиксов.
Восходящим для этого LFB обычно служит IPv6Validator LFB. При использовании RPF это может быть RPF LFB, когда он будет определен.
Нисходящим LFB обычно является IPv6NextHop LFB. При использовании ECMP это может быть ECMP LFB, когда он будет определен.
5.3.3.2. Компоненты
Этот LFB имеет две компоненты.
IPv6PrefixTable является массивом, каждая строка которого содержит адрес IPv6, размер префикса, селектор интервала, флаги ECMP и маршрута по умолчанию. Флаг ECMP в LFB служит для поддержки ECMP, а флаг маршрута по умолчанию для поддержки такого маршрута и управления RPF, как описано выше.
Структурная компонента IPv6UcastLPMStats служит для сбора статистики, включая общее число принятых пакетов, число пакетов IPv6, пересланных этим LFB, а также число дейтаграмм IP отброшенных по причине отсутствия маршрута. Отметим, что эта компонента не обязательна для реализации.
5.3.3.3. Возможности
У этого LFB нет списка возможностей.
5.3.3.4. События
Этот LFB не задает каких-либо событий.
5.3.4. IPv6NextHop
Этот LFB абстрагирует процесс выбора IPv6 next-hop.
5.3.4.1. Обработка данных
LFB абстрагирует процесс применения данных о следующем интервале к пакетам IPv6. Он получает пакеты IPv6 с идентификатором следующего интервала (HopSelector) и применяет этот идентификатор как индекс таблицы для поиска подходящего выходного порта LFB.
LFB ожидает приема индивидуальных пакетов IPv6 через одиночный порт PktsIn вместе с метаданными HopSelector, которые служат индексом для поиска в таблице next-hop.
В LFB определены два выходных порта.
Первый порт является групповым и называется SuccessOut. При успешной обработке данных пакет передается из группового порта LFB в соответствии со значением LFBOutputSelectIndex, соответствующим записи в таблице. Пакет передается в нисходящий LFB с метаданными L3PortID и MediaEncapInfoIndex.
Вторым выходным портом является одиночный порт ExceptionOut, в который выводятся данные при возникновении исключительных ситуаций в процессе обработки вместе с метаданными ExceptionID, указывающими причину исключения. В настоящий момент определено несколько причин, приведенных ниже.
-
HopSelector для пакета не пригоден.
-
Отказ при поиске в таблице next-hop при корректном HopSelector.
-
MTU выходного интерфейса меньше размера пакета.
Экземпляры нисходящих LFB могут иметь тип BasicMetadataDispatch, используемый для распределения по разным экземплярам LFB, или связанный с инкапсуляций в среду тип, такой как EtherEncap или RedirectOut. Например при наличии Ethernet или другой туннельной инкапсуляции BasicMetadataDispatch LFB может использовать метаданные L3PortID (см. ниже) для диспетчеризации пакетов разным инкапсуляторам.
5.3.4.2. Компоненты
Этот LFB имеет одну компоненту – массив IPv6NextHopTable. Полученное значение HopSelector служит индексом массива IPv6NextHopTable для поиска строки с информацией next-hop. Структура строк массива описана ниже.
-
Идентификатор логического порта L3PortID, который передается экземпляру нисходящего LFB. Этот идентификатор указывает тип инкапсулирующего порта, который должен использовать сосед. Эта информация, полученная от L3, влияет на обработку L2 и поэтому должна основываться на метаданных, передаваемых между LFB. Обычно этот идентификатор применяется для LFB следующего интервала, чтобы различать пакеты, которым нужна разная инкапсуляция L2. Например, некоторым пакетам может требоваться базовая инкапсуляция Ethernet, а другим – туннельная инкапсуляция того или иного типа. В таких случаях пакетам назначаются разные L3PortID, которые передаются в виде метаданных нисходящему LFB. Блок BasicMetadataDispatch LFB (параграф 5.5.1) может служить таким нисходящим LFB для диспетчеризации пакетов экземплярам LFB с разной инкапсуляцией в соответствии с L3PortID.
-
MTU – максимальный размер блока на выходном порту.
-
NextHopIPAddr – адрес IPv6.
-
MediaEncapInfoIndex передается нисходящему LFB инкапсуляции и служит ключом поиска в таблице (обычно связанной с инкапсуляцией для разных сред). Отметим, что экземпляр LFB инкапсуляции, использующий эти метаданные, может не следовать непосредственно за данным LFB в процессе обработки. Метаданные MediaEncapInfoIndex добавляются к пакету и передаются через промежуточные LFB, пока не будут применены экземпляром LFB инкапсуляции. В зависимости от реализации CE может устанавливать для MediaEncapInfoIndex, передаваемого в нисходящем направлении, значение, которое будет приводить к отказу при поиске в целевом LFB инкапсуляции. Это будет говорить о том, что нужно дополнительное распознавание. Пример этого показан в параграфе 7.2, где обсуждается протокол ARP.
-
LFBOutputSelectIndex является индексом группового выходного порта LFB для выбора порта нисходящего LFB. Это значение указывает конкретный порт группы SuccessOut, через который будет выводиться пакет с найденной информацией next-hop.
5.3.4.3. Возможности
У этого LFB нет списка возможностей.
5.3.4.4. События
Этот LFB не задает каких-либо событий.
5.4. LFB для перенаправления
LFB для перенаправления абстрагируют процесс транспортировки пакетов между CE и FE. Часть пакетов из некоторых LFB может доставляться в CE для дополнительной обработки, а некоторые пакеты, создаваемые CE, могут доставляться FE и далее в конкретные LFB пути обработки данных. В соответствии с [RFC5810] пакеты данных и связанные с ними метаданные инкапсулируются в сообщение ForCES (redirect) для транспортировки между CE и FE. Здесь определяются два LFB для абстрагирования этого процесса RedirectIn LFB и RedirectOut LFB. Обычно в топологии LFB элемента FE имеется один экземпляр RedirectIn LFB и один экземпляр RedirectOut LFB.
5.4.1. RedirectIn
RedirectIn LFB абстрагирует процесс вставки элементом CE пакетов данных в путь данных FE.
5.4.1.1. Обработка данных
RedirectIn LFB абстрагирует процесс вставки элементом CE пакетов данных в топологию FE LFB для их добавления в путь данных FE. С точки зрения топологии LFB блок RedirectIn LFB служит точкой входа пакетов данных от CE, поэтому RedirectIn LFB имеет один выходной порт LFB, но не имеет входных портов.
Единственный выходной порт LFB определен как групповой порт с именем PktsOut. Пакеты из этого порта могут иметь произвольный тип кадров, выбираемый CE, который создает эти пакеты. Эти кадры могут содержать пакеты протоколов IPv4, IPv6 или ARP. CE может связать с типом кадра те или иные метаданные, а также связать с пакетом метаданные, содержащие различную информацию о пакете. Среди них должны присутствовать метаданные RedirectIndex, которые указывают целочисленный индекс. Когда CE передает метаданные с пакетом в RedirectIn LFB, этот LFB будет выводить пакет в один из выходных портов группы в соответствии с индексом порта, указанным RedirectIndex. Все остальные метаданные будут передаваться в неизменном виде вместе с полученным от CE пакетом нисходящему LFB. Это означает, что метаданные RedirectIndex от CE будут «поглощаться» RedirectIn LFB без передачи нисходящему LFB. Отметим, что пакеты от CE без метаданных RedirectIndex будут отбрасываться этим LFB. Все метаданные, видимые LFB, должны быть глобальными и контролируются IANA. Пространства идентификаторов метаданных описаны в разделе 8 с указанием идентификаторов выделенных производителям и для частного применения.
5.4.1.2. Компоненты
Для сбора статистики числа принятых этим LFB от CE пакетов определена необязательная компонента. Других компонент этот LFB в текущей версии не имеет.
5.4.1.3. Возможности
У этого LFB нет списка возможностей.
5.4.1.4. События
Этот LFB не задает каких-либо событий.
5.4.2. RedirectOut
RedirectOut LFB абстрагирует процесс для LFB в FE, которые служат для доставки пакетов в CE.
5.4.2.1. Обработка данных
RedirectOut LFB абстрагирует процесс для LFB в FE, которые служат для доставки пакетов в CE. С точки зрения топологии LFB блок RedirectOut LFB действует как точка сбора пакетов данных, идущих в CE, поэтому RedirectOut LFB определен с одним входным портом и без выходных портов.
RedirectOut LFB имеет единственный одиночный вход PktsIn, но может получать пакеты от множества LFB с помощью мультиплексирования на этом порту. На входе принимаются любые типы кадров, поэтому тип может быть указан как произвольный. Принимаются также все типы метаданных. Все связанные с пакетом метаданные созданные (но не поглощенные) предыдущими LFB, следует доставлять CE в сообщения ForCES redirect [RFC5810]. CE может выбирать способ обработки пакета в соответствии со связанными метаданными. Например, пакет может быть перенаправлен из FE в CE в результате неспособности EtherEncap LFB распознать информацию L2. Метаданные ExceptionID, созданные EtherEncap LFB, передаются вместе с пакетом и элементу CE их должно быть достаточно для требуемой обработки и распознавания нужной записи L2. Отметим, что все метаданные, видимы LFB, должны быть глобальными и контролируемыми IANA. Пространства идентификаторов метаданных описаны в разделе 8 с указанием идентификаторов выделенных производителям и для частного применения.
5.4.2.2. Компоненты
Для сбора статистики числа переданных этим LFB элементу CE пакетов определена необязательная компонента. Других компонент этот LFB в текущей версии не имеет.
5.4.2.3. Возможности
У этого LFB нет списка возможностей.
5.4.2.4. События
Этот LFB не задает каких-либо событий.
5.5. LFB общего назначения
5.5.1. BasicMetadataDispatch
BasicMetadataDispatch LFB определен для абстрагирования процесса, в котором пакеты диспетчеризуются в тот или иной выходной путь на основании значения метаданных.
5.5.1.1. Обработка данных
BasicMetadataDispatch LFB имеет единственный одиночный вход PktsIn. С каждым пакетом следует связывать метаданные, которые LFB будет применять для диспетчеризации. Этот LFB содержит идентификатор метаданных и таблицу диспетчеризации MetadataDispatchTable, настраиваемые элементом CE. Идентификатор указывает метаданные, которые будут служить для диспетчеризации пакета. таблица MetadataDispatchTable содержит записи со значениями метаданных и OutputIndex, указывающим в какой экземпляр группы выходных портов этого LFB нужно передать пакет с таким значением метаданных.
В LFB определены два выходных порта.
Групповой порт PktsOut служит для передачи пакетов, по значению метаданных которых был найден OutputIndex, в порт с соответствующим индексом.
Вторым является одиночный порт ExceptionOut, куда выводятся данные, при обработке которых возник отказ, вместе с дополнительными метаданными ExceptionID, указывающими причину исключения. В настоящий момент определено одно исключение:
-
не найдено соответствия при поиске в таблице данных диспетчеризации.
Например, если CE решает диспетчеризовать пакеты по идентификатору физического порта (PHYPortID), CE может установить идентификатор метаданных PHYPortID первым в LFB. Кроме того, CE устанавливает действующие значения PHYPortID (значения метаданных) и назначает значения OutputIndex для них в таблице диспетчеризации LFB. При получении пакета считываются связанные с ним метаданные PHYPortID и значение идентификатора физического порта служит ключом поиска в таблице диспетчеризации для определения экземпляра выходного порта.
В настоящее время BasicMetadataDispatch LFB поддерживает в таблице диспетчеризации лишь целочисленные 32-битовые значения метаданных. В будущих версиях библиотеки могут быть определены более сложные метаданные. В этом LFB может поддерживаться множество наборов метаданных для диспетчеризации пакетов.
5.5.1.2. Компоненты
LFB имеет две компоненты – MetadataID и MetadataDispatchTable. Каждая запись таблицы диспетчеризации является структурой, содержащей значение метаданных и OutputIndex. Отметим, что в настоящее время поддерживаются лишь целочисленные 32-битовые значения метаданных. Значение метаданных служит также ключом содержимого таблицы, как указано в модели ForCES FE [RFC5812]. С помощью ключей содержимого CE может манипулировать таблицей, используя конкретное значение метаданных, а не только индекс таблицы. Информация о ключах содержимого и работе с ними приведена в модели ForCES FE [RFC5812] и спецификации протокола ForCES [RFC5810].
5.5.1.3. Возможности
У этого LFB нет списка возможностей.
5.5.1.4. События
Этот LFB не задает каких-либо событий.
5.5.2. GenericScheduler
Это предварительный LFB базового планировщика для процессов расписания.
5.5.2.1. Обработка данных
Имеется множество стратегий планирования с разными реализациями. Являясь базовой библиотекой, данный документ определяет лишь предварительный базовый планировщик для абстрагирования простого расписания. Пользователи могут применять этот LFB в качестве базы для создания более сложных LFB планировщиков с помощью «наследования», описанного в [RFC5812].
Пакеты с произвольным типом кадров принимаются групповым входом PktsIn без ожидания дополнительных метаданных. Групповой вход поддерживает множество экземпляров входных портов, каждый из которых может быть соединен со своим выходом восходящего LFB. Внутри LFB каждый входной порт абстрактно соединен с очередью, имеющей идентификатор, значение которого совпадает с индексом соответствующего экземпляра входного порта. Ко всем очередям и пакетам в них применяются дисциплины планирования. Свойство группового входного порта PortGroupLimits в ObjectLFB, определенное в модели ForCES FE [RFC5810], обеспечивает CE возможность запросить общее число очередей, поддерживаемых планировщиком. Затем CE может решить, сколько очередей может применяться при планировании.
Пакеты выводятся по расписанию через одиночный выходной порт PktsOut без соответствующих метаданных.
Могут быть определены более сложные LFB с комплексными дисциплинами планирования, следующие этому LFB. Например, можно определить LFB планировщика с поддержкой приоритета, следующий этому LFB, путем добавления компоненты для указания приоритета каждой входной очереди.
5.5.2.2. Компоненты
SchedulingDiscipline используется CE для задания дисциплины планирования данного LFB. В настоящее время поддерживается лишь стратегия циклического перебора (RR19), которая и применяется по умолчанию.
QueueStats позволяет CE запросить статус планировщика для каждой очереди. Это массив, каждая строка которого является структурой, содержащей идентификатор очереди. Определенное в данный момент стояние очереди включает размер очереди в пакетах и байтах. Используя идентификатор очереди в качестве индекса, CE может запросить текущий размер каждой очереди в пакетах и байтах. Отметим, что компонента QueueStats не обязательная для реализации.
5.5.2.3. Возможности
В настоящее время для GenericScheduler определена единственная возможность:
-
предельный размер для каждой очереди.
5.5.2.4. События
Этот LFB не задает каких-либо событий.
6. XML для библиотеки LFB
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseLFBLibrary">
<load library="BaseTypeLibrary"/>
<LFBClassDefs>
<LFBClassDef LFBClassID="3">
<name>EtherPHYCop</name>
<synopsis>
EtherPHYCop LFB описывает интерфейс Ethernet, который
ограничивает физические среды электрическими кабелями.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EtherPHYIn</name>
<synopsis>
Входной порт EtherPHYCop LFB, принимающий все типы
кадров Ethernet.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>EtherPHYOut</name>
<synopsis>
Выходной порт EtherPHYCop LFB. Выходной пакет имеет
тот же тип кадре Ethernet, который был у входного
пакета, связанного с метаданными, указывающими
идентификатор физического порта.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-only">
<name>PHYPortID</name>
<synopsis>Идентификация физического порта</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2" access="read-write">
<name>AdminStatus</name>
<synopsis>
Запрошенный административно статус порта
</synopsis>
<typeRef>PortStatusType</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="3" access="read-only">
<name>OperStatus</name>
<synopsis>Реальное рабочее состояние порта</synopsis>
<typeRef>PortStatusType</typeRef>
</component>
<component componentID="4" access="read-write">
<name>AdminLinkSpeed</name>
<synopsis>
Административно запрошенная скорость порта
</synopsis>
<typeRef>LANSpeedType</typeRef>
<defaultValue>LAN_SPEED_AUTO</defaultValue>
</component>
<component componentID="5" access="read-only">
<name>OperLinkSpeed</name>
<synopsis>Реальная рабочая скорость порта</synopsis>
<typeRef>LANSpeedType</typeRef>
</component>
<component componentID="6" access="read-write">
<name>AdminDuplexMode</name>
<synopsis>
Запрошенный административно режим дуплекса
</synopsis>
<typeRef>DuplexType</typeRef>
<defaultValue>Auto</defaultValue>
</component>
<component componentID="7" access="read-only">
<name>OperDuplexMode</name>
<synopsis>Реальный рабочий режим дуплекса</synopsis>
<typeRef>DuplexType</typeRef>
</component>
<component componentID="8" access="read-only">
<name>CarrierStatus</name>
<synopsis>Состояние несущей на порту</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportedLinkSpeed</name>
<synopsis>Список поддерживаемых портом скоростей</synopsis>
<array>
<typeRef>LANSpeedType</typeRef>
</array>
</capability>
<capability componentID="31">
<name>SupportedDuplexMode</name>
<synopsis>
Список поддерживаемых портом режимов дуплекса
</synopsis>
<array>
<typeRef>DuplexType</typeRef>
</array>
</capability>
</capabilities>
<events baseID="60">
<event eventID="1">
<name>PHYPortStatusChanged</name>
<synopsis>
Событие, указывающее смену рабочего состояния
физического порта.
</synopsis>
<eventTarget>
<eventField>OperStatus</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperStatus</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>LinkSpeedChanged</name>
<synopsis>
Событие, указывающее смену рабочей скорости
на физическом порту.
</synopsis>
<eventTarget>
<eventField>OperLinkSpeed</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperLinkSpeed</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>DuplexModeChanged</name>
<synopsis>
Событие, указывающее смену режима дуплекса
на физическом порту.
</synopsis>
<eventTarget>
<eventField>OperDuplexMode</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperDuplexMode</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="4">
<name>EtherMACIn</name>
<synopsis>
EtherMACIn LFB описывает порт Ethernet на уровне MAC.
LFB описывает функции обработки Ethernet при проверке
местоположения MAC-адреса, принятии решения о применении
функций моста Ethernet, управления потоком данных на
уровне Ethernet и т. п.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EtherPktsIn</name>
<synopsis>
Входной порт EtherMACIn LFB. Предполагаются любые
типы кадров Ethernet.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalPathOut</name>
<synopsis>
Выходной порт EtherMACIn LFB. Выводит пакеты Ethernet
в нисходящий LFB для обычной обработки, такой как
классификация Ethernet и обработка L3 IP.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>L2BridgingPathOut</name>
<synopsis>
Выходной порт EtherMACIn LFB. Выводит пакеты
Ethernet в нисходящие LFB для выполнения функций
моста L2. Этот порт включается и отключается
флагом L2BridgingPathEnable в LFB.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>AdminStatus</name>
<synopsis>
Административно запрошенное состояние LFB, имеющее такой
же тип данных как статус порта. По умолчанию Down.
</synopsis>
<typeRef>PortStatusType</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="2" access="read-write">
<name>LocalMACAddresses</name>
<synopsis>
Локальные MAC-адреса порта Ethernet, представленного LFB.
</synopsis>
<array>
<typeRef>IEEEMAC</typeRef>
</array>
</component>
<component componentID="3" access="read-write">
<name>L2BridgingPathEnable</name>
<synopsis>
Флаг, указывающий состояние выходного порта LFB L2
BridgingPath. По умолчанию порт выключен.
</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="4" access="read-write">
<name>PromiscuousMode</name>
<synopsis>
Флаг, указывающий состояние неразборчивого режима
LFB. По умолчанию выключен.
</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="5" access="read-write">
<name>TxFlowControl</name>
<synopsis>
Флаг, указывающий состояние управления потоком
данных на выходе. По умолчанию выключено.
</synopsis>
<optional/>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="6" access="read-write">
<name>RxFlowControl</name>
<synopsis>
Флаг, указывающий состояние управления потоком
данных на входе. По умолчанию выключено.
</synopsis>
<optional/>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="7" access="read-reset">
<name>MACInStats</name>
<synopsis>Статистика EtherMACIn LFB</synopsis>
<optional/>
<typeRef>MACInStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="5">
<name>EtherClassifier</name>
<synopsis>
EtherClassifier LFB описывает процесс декапсуляции пакетов
Ethernet и их классификации по протоколам сетевого уровня
в соответствии с заголовками Ethernet. Предполагается, что
LFB классифицирует пакеты IPv4, IPv6, MPLS, ARP, ND и т. п.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EtherPktsIn</name>
<synopsis>
Входной порт пакетов Ethernet. Метаданные PHYPortID
предполагаются всегда, а LogicalPortID - опциональны
для входящих пакетов Ethernet.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
<ref dependency="optional" defaultValue="0">
LogicalPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>ClassifyOut</name>
<synopsis>
Групповой порт для вывода результатов классификации
Ethernet.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
<ref>SrcMAC</ref>
<ref>DstMAC</ref>
<ref>EtherType</ref>
<ref availability="conditional">VlanID</ref>
<ref availability="conditional">VlanPriority</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
Отдельный порт для вывода всех пакетов Ethernet с
отказом при классификации. Метаданные ExceptionID
указывают причину отказа.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>EtherDispatchTable</name>
<synopsis>
Элемент массива EtherDispatchTable, определенного в
LFB для диспетчеризации каждого пакета Ethernet в
выходные порты по идентификатору логического порта
назначенному VlanInputTable в LFB и типу Ethernet в
заголовке пакета Ethernet.
</synopsis>
<typeRef>EtherDispatchTableType</typeRef>
</component>
<component access="read-write" componentID="2">
<name>VlanInputTable</name>
<synopsis>
Элемент массива VlanInputTable, определенного в LFB для
классификации пакетов VLAN Ethernet. Каждому входному
пакету назначается новый LogicalPortID в соответствии
с идентификатором входного порта и VLAN ID.
</synopsis>
<typeRef>VlanInputTableType</typeRef>
</component>
<component access="read-reset" componentID="3">
<name>EtherClassifyStats</name>
<synopsis>
Таблица статистики процесса классификации Ethernet
в LFB.
</synopsis>
<optional/>
<typeRef>EtherClassifyStatsTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="6">
<name>EtherEncap</name>
<synopsis>
EtherEncap LFB абстрагирует процесс инкапсуляции заголовков
Ethernet в принятые пакеты на основе полученных метаданных.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EncapIn</name>
<synopsis>
Входной порт, получающий пакеты IPv4 и/или IPv6 для
инкапсуляции. Ожидаются метаданные MediaEncapInfoIndex
для каждого пакета и могут присутствовать метаданные
приоритета VLAN.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameExpected>
<metadataExpected>
<ref>MediaEncapInfoIndex</ref>
<ref dependency="optional" defaultValue="0">
VlanPriority</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>SuccessOut</name>
<synopsis>
Выходной порт для пакетов, в которых найдена информация
Ethernet L2 и которые успешно инкапсулированы в пакеты
Ethernet. Для каждого выходного пакета создаются
метаданные L2PortID.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>L2PortID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
Выходной порт для пакетов с отказом при инкапсуляции в
LFB. метаданные ExceptionID указывают причину отказа.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
<ref>MediaEncapInfoIndex</ref>
<ref availability="conditional">VlanPriority</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>EncapTable</name>
<synopsis>
Таблица для поиска данных инкапсуляции Ethernet, каждая
строка которой содержит MAC-адреса отправителя и
получателя, VLAN ID, и идентификатор выходного
логического порта L2.
</synopsis>
<typeRef>EncapTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="7">
<name>EtherMACOut</name>
<synopsis>
EtherMACOut LFB абстрагирует порт Ethernet на уровне MAC и
описывает обработку пакетов Ethernet для вывода в физический
порт. Нисходящим LFB обычно является физический Ethernet
LFB, такой как EtherPHYCop LFB. Отметим, что выходные функции
Ethernet тесно связаны со входными, поэтому некоторые
компоненты этого LFB являются псевдонимами компонент EtherMACIn.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EtherPktsIn</name>
<synopsis>
Входной порт EtherMACOut LFB. Принимает все типы
кадров Ethernet.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>EtherPktsOut</name>
<synopsis>
Порт для вывода всех пакетов Ethernet, каждый из
которых имеет метаданные, указывающие идентификатор
физического порта, через который пакет должен пройти.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>AdminStatus</name>
<synopsis>
Административно запрошенное состояние LFB, совпадающее
по типу данных с состоянием порта. Компонента
определена как псевдоним AdminStatus из EtherMACIn LFB.
</synopsis>
<alias>PortStatusType</alias>
</component>
<component componentID="2" access="read-write">
<name>MTU</name>
<synopsis>максимальный передаваемый блок (MTU) </synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>TxFlowControl</name>
<synopsis>
Флаг, указывающий применение контроля потока данных при
передаче. Определен как псевдоним TxFlowControl из
EtherMACIn LFB.
</synopsis>
<optional/>
<alias>boolean</alias>
</component>
<component componentID="4" access="read-write">
<name>RxFlowControl</name>
<synopsis>
Флаг, указывающий применение контроля потока данных на
приеме. Определен как псевдоним RxFlowControl из
EtherMACIn LFB.
</synopsis>
<optional/>
<alias>boolean</alias>
</component>
<component componentID="5" access="read-reset">
<name>MACOutStats</name>
<synopsis>Статистика EtherMACOut LFB</synopsis>
<optional/>
<typeRef>MACOutStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="8">
<name>IPv4Validator</name>
<synopsis>
Этот LFB проверяет пакеты IPv4 в соответствии с RFC 1812 и
обновлениями. Пакет IPv4 будет выводиться в соответствующий
порт LFB, показывающий, является пакет индивидуальным или
групповым и возникли ли исключительные ситуации или отказы
при проверке.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>Входной порт для проверяемых пакетов</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>IPv4UnicastOut</name>
<synopsis>
Выходной порт для прошедших проверку индивидуальных пакетов IPv4
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>IPv4MulticastOut</name>
<synopsis>
Выходной порт для прошедших проверку групповых пакетов IPv4
</synopsis>
<product>
<frameProduced>
<ref>IPv4Multicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>
Выходной порт для всех пакетов с исключительными случаями
при проверке. Метаданные ExceptionID указывают тип
исключительного случая.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOut</name>
<synopsis>
Выходной порт для пакетов с отказом при проверке.
Метаданные ValidateErrorID указывают тип или причину отказа.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
<metadataProduced>
<ref>ValidateErrorID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>IPv4ValidatorStats</name>
<synopsis>Статистика для процесса проверки в LFB.</synopsis>
<optional/>
<typeRef>IPv4ValidatorStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="9">
<name>IPv6Validator</name>
<synopsis>
Этот LFB проверяет пакеты IPv6 в соответствии с RFC 2460 и
обновлениями. Пакет IPv6 будет выводиться в соответствующий
порт LFB, показывающий, является пакет индивидуальным или
групповым и возникли ли исключительные ситуации или отказы
при проверке.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>Входной порт для проверяемых пакетов</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>IPv6UnicastOut</name>
<synopsis>
Выходной порт для прошедших проверку индивидуальных пакетов IPv6
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>IPv6MulticastOut</name>
<synopsis>
Выходной порт для прошедших проверку групповых пакетов IPv6
</synopsis>
<product>
<frameProduced>
<ref>IPv6Multicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>
Выходной порт для всех пакетов с исключительными случаями
при проверке. Метаданные ExceptionID указывают тип
исключительного случая.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOut</name>
<synopsis>
Выходной порт для пакетов с отказом при проверке.
Метаданные ValidateErrorID указывают тип или причину отказа.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ValidateErrorID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>IPv6ValidatorStats</name>
<synopsis>
<synopsis>Статистика для процесса проверки в LFB.</synopsis>
</synopsis>
<optional/>
<typeRef>IPv6ValidatorStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="10">
<name>IPv4UcastLPM</name>
<synopsis>
IPv4UcastLPM LFB абстрагирует процесс IPv4 поиска LPM.
LFB поддерживает реализации маршрутизации ECMP и
пересылки по обратному пути (RPF).
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
Порт для получения обрабатываемых пакетов.
Предполагаются индивидуальные пакеты IPv4.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Unicast</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>
Порт для вывода индивидуальных пакетов IPv4, прошедших
поиск LPM. Создаются метаданные HopSelector для
привязки каждого выходного пакета в нисходящему LFB
для действия next-hop.
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ECMPOut</name>
<synopsis>
Порт для вывода пакетов, требующих дополнительной
обработки ECMP. За этим портом обычно следует
нисходящий LFB обработки ECMP. Если ECMP не требуется,
к порту не подключаться нисходящий LFB.
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
Порт для вывода всех пакетов с исключительными случаями
в процессе LPM. Метаданные ExceptionID указывают
причину исключения.
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IPv4PrefixTable</name>
<synopsis>
Таблица для максимального соответствия префикса IPv4
(LPM). Адрес получателя IPv4 каждого входного пакета
служит ключом поиска в таблице селектора next-hop.
</synopsis>
<typeRef>IPv4PrefixTableType</typeRef>
</component>
<component componentID="2" access="read-reset">
<name>IPv4UcastLPMStats</name>
<synopsis>
Статистика процесса LPM для индивидуальных адресов IPv4.
</synopsis>
<optional/>
<typeRef>IPv4UcastLPMStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="11">
<name>IPv6UcastLPM</name>
<synopsis>
IPv6UcastLPM LFB абстрагирует процесс поиска наиболее
длинного префикса (LPM) для индивидуального адреса IPv6.
LFB поддерживает реализацию ECMP и RPF.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
Порт для ввода пакетов на обработку.
Предполагаются индивидуальные пакеты IPv6.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv6Unicast</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>
Порт для вывода индивидуальных пакетов IPv6, прошедших
поиск LPM. Создаются метаданные HopSelector для
привязки каждого выходного пакета в нисходящему LFB
для действия next-hop.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ECMPOut</name>
<synopsis>
Порт для вывода пакетов, требующих дополнительной
обработки ECMP. За этим портом обычно следует
нисходящий LFB обработки ECMP. Если ECMP не требуется,
к порту не подключаться нисходящий LFB.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
Порт для вывода всех пакетов с исключительными случаями
в процессе LPM. Метаданные ExceptionID указывают
причину исключения.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IPv6PrefixTable</name>
<synopsis>
Таблица для максимального соответствия префикса IPv6
(LPM). Адрес получателя IPv6 каждого входного пакета
служит ключом поиска в таблице селектора next-hop.
</synopsis>
<typeRef>IPv6PrefixTableType</typeRef>
</component>
<component componentID="2" access="read-reset">
<name>IPv6UcastLPMStats</name>
<synopsis>
Статистика процесса LPM для индивидуальных адресов IPv6.
</synopsis>
<optional/>
<typeRef>IPv6UcastLPMStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="12">
<name>IPv4NextHop</name>
<synopsis>
IPv4NextHop LFB абстрагирует процесс обработки next-hop
применительно к пакетам IPv4. Он получает пакеты IPv4 с
идентификатором next-hop (HopSelector) и использует
идентификатор в качестве индекса для поиска в таблице
next-hop подходящего выходного порта. Обработка также
включает декремент TTL и пересчет контрольной суммы IP.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
Порт для ввода индивидуальных пакетов IPv4 с
метаданными HopSelector.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Unicast</ref>
</frameExpected>
<metadataExpected>
<ref>HopSelector</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>SuccessOut</name>
<synopsis>
Порт для вывода пакетов с найденным next-hop. С каждым
пакетом связаны те или иные метаданные.
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>L3PortID</ref>
<ref>NextHopIPv4Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
Выходной порт для пакетов с исключительными случаями.
ExceptionID указывает причину исключения.
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>IPv4NextHopTable</name>
<synopsis>
Компонента IPv4NextHopTable. HopSelector служит для
сопоставления с индексом таблицы при поиске строки,
содержащей информацию next-hop.
</synopsis>
<typeRef>IPv4NextHopTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="13">
<name>IPv6NextHop</name>
<synopsis>
Этот LFB абстрагирует процесс обработки next-hop
применительно к пакетам IPv6. Он получает пакеты IPv6 с
идентификатором next-hop (HopSelector) и использует
идентификатор в качестве индекса для поиска в таблице
next-hop подходящего выходного порта.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
Порт для ввода индивидуальных пакетов IPv6 с
метаданными HopSelector.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv6Unicast</ref>
</frameExpected>
<metadataExpected>
<ref>HopSelector</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>SuccessOut</name>
<synopsis>
Порт для вывода пакетов с найденным next-hop. С каждым
пакетом связаны те или иные метаданные.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>L3PortID</ref>
<ref>NextHopIPv6Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
Выходной порт для пакетов с исключительными случаями.
ExceptionID указывает причину исключения.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>IPv6NextHopTable</name>
<synopsis>
Компонента IPv6NextHopTable. HopSelector служит для
сопоставления с индексом таблицы при поиске строки,
содержащей информацию next-hop.
</synopsis>
<typeRef>IPv6NextHopTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="14">
<name>RedirectIn</name>
<synopsis>
RedirectIn LFB абстрагирует для ForCES CE процесс
вставки пакетов в ForCES FE LFB.
</synopsis>
<version>1.0</version>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>
Выходной порт RedirectIn LFB, являющийся групповым.
С точки зрения топологии LFB этот порт служит точкой
входа пакетов данных от CE, поэтому LFB определен с
одним выходным портом и не имеет входных портов.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>NumPacketsReceived</name>
<synopsis>Число пакетов, принятых от CE.</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="15">
<name>RedirectOut</name>
<synopsis>
RedirectOut LFB абстрагирует в LFB процесс передачи пакетов
из ForCES FE в ForCES CE.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
Входной порт RedirectOut LFB. С точки зрения топологии
LFB блок RedirectOut LFB служит точкой сбора пакетов
данных, идущих в CE, поэтому RedirectOut LFB определен
с одним входным портом (без выходных).
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<components>
<component componentID="1">
<name>NumPacketsSent</name>
<synopsis>Число пакетов, переданных CE.</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="16">
<name>BasicMetadataDispatch</name>
<synopsis>
BasicMetadataDispatch LFB определен как абстракция процесса
диспетчеризации пакетов в разные выходные пути на основе
метаданных. В настоящее время этот LFB поддерживает лишь
32-битовые целочисленные значения метаданных.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktsIn</name>
<synopsis>
Входной порт для диспетчеризации пакетов. Каждый входной
пакет должен быть связан с метаданными, которые будет
применяться LFB для диспетчеризации.
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
<metadataExpected>
<ref>Arbitrary</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>
Групповой выходной порт для вывода результатов
диспетчеризации. Пакет со связанными метаданными,
для которого найден OutputIndex в таблице
диспетчеризации, будет выведен в экземпляр группового
порта в соответствии с индексом.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
Выходной порт для пакетов с отказом при обработке.
Метаданные ExceptionID указывают причину исключения.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>MetadataID</name>
<synopsis>
Идентификатор метаданных для использования
при диспетчеризации пакетов.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-write" componentID="2">
<name>MetadataDispatchTable</name>
<synopsis>
Компонента MetadataDispatchTable, содержащая значение
метаданных и выходной индекс, указывающие, что пакет
с таким значением метаданных нужно передать через порт
с найденным индексом группового выходного порта LFB.
</synopsis>
<typeRef>MetadataDispatchTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="17">
<name>GenericScheduler</name>
<synopsis>
Предварительный базовый планировщик, абстрагирующий
простой процесс планирования, который может служить
базовым LFB для создания более сложных планировщиков.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>PktsIn</name>
<synopsis>
Групповой входной порт LFB. Внутри LFB каждый
экземпляр группового порта соединен с очередью,
идентификатор которой совпадает с индексом экземпляра.
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>PktsOut</name>
<synopsis>
Выходной порт для вывода пакетов из планировщика.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>SchedulingDiscipline</name>
<synopsis>
SchedulingDiscipline применяется CE для указания
LFB дисциплины планирования.
</synopsis>
<typeRef>SchdDisciplineType</typeRef>
<defaultValue>1</defaultValue>
</component>
<component access="read-only" componentID="2">
<name>QueueStats</name>
<synopsis>
QueueStats позволяет CE запросить статистику
каждой очереди в планировщике.
</synopsis>
<optional/>
<typeRef>QueueStatsTableType</typeRef>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>QueueLenLimit</name>
<synopsis>
Возможность QueueLenLimit указывает максимальный
размер каждой очереди в байтах.
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
7. Примеры использования классов LFB
В этом разделе приведены примеры использования классов LFB, определенной в разделе 6 базовой библиотеки LFB, для реализации некоторых типовых функций маршрутизации, включая:
-
пересылку IPv4;
-
обработку ARP.
Предполагается, что топология LFB в FE задана элементом CE и соответствует рассматриваемым примерам.
Рассмотренные здесь случаи являются просто примерами и не могут считаться единственным вариантом реализации функций маршрутизатора из LFB. На основе возможностей FE элемент CE должен быть способен выразить различные варианты реализации NE.
7.1. Пересылка IPv4
На рисунке 2 показан типичный путь обработки при пересылке индивидуальных пакетов IPv4 в среде с интерфейсами Ethernet на основе базовых классов LFB. Отметим, что на этом рисунке не показаны некоторые входы и выходы, не относящиеся напрямую к функции пересылки IPv4. Например, EtherClassifier LFB обычно имеет два выходных порта — групповой ClassifyOut и одиночный ExceptionOut, при этом групповой порт имеет множество разных экземпляров выходных портов в соответствии с классификацией пакетов (параграф 5.1.3). На рисунке показаны лишь выходные порты для пакетов IPv4 и IPv6, чтобы лучше проиллюстрировать функцию пересылки IPv4.
+-----+ +------+
| | | |
| |<---------------|Ether |<----------------------------+
| | |MACOut| |
| | | | |
|Ether| +------+ |
|PHY | |
|Cop | +---+ |
|#1 | +-----+ | |-----> Пакеты IPv6 |
| | | | | | |
| | |Ether| | | Пакеты IPv4 |
| |->|MACIn|-->| |-+ +----+ |
+-----+ | | | | | | |---> Групповые пакеты |
+-----+ +---+ | | | +-----+ +---+ |
Ether +->| |------->| | | | |
. Classifier| | |Индивид.|IPv4 | | | |
. | | |пакеты |Ucast|->| |--+ |
. | +----+ |LPM | | | | |
+---+ | IPv4 +-----+ +---+ | |
+-----+ | | | Validator IPv4 | |
| | | | | NextHop| |
+-----+ |Ether| | |-+ Пакеты IPv4 | |
| |->|MACIn|-->| | | |
| | | | | |-----> Пакеты IPv6 | |
|Ether| +-----+ +---+ | |
|PHY | Ether +----+ | |
|Cop | Classifier | | +-------+ | |
|#n | +------+ | | |Ether | | |
| | | | | |<--|Encap |<-+ |
| | | |<------| | | | |
| |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | |
| | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch |
+----------->-------------+
Рисунок 2. Пример использования LFB для пересылки IPv4.
В этом примере использования LFB множество экземпляров EtherPHYCop LFB (параграф 5.1.1) служит для описания функций физического уровня в портах. Метаданные PHYPortID создаются EtherPHYCop LFB и применяется всеми последующими нисходящими LFB. Блок EtherMACIn LFB (параграф 5.1.2), описывающий обработку на уровне MAC, следует за каждым EtherPHYCop LFB. Блок EtherMACIn LFB может проверять местоположение MAC-адресов, если CE настроит соответствующую компоненту EtherMACIn LFB.
Пакеты Ethernet из EtherMACIn LFB передаются в EtherClassifier LFB (параграф 5.1.3) для декапсуляции и классификации по протоколам сетевого уровня (IPv4, IPv6, ARP и т. п.). В приведенном примере каждый физический интерфейс Ethernet связан с одним интерфейсом Classifier. Здесь это не показано, но желательно связать все физические интерфейсы с единственным экземпляром Ethernet Classifier.
EtherClassifier использует метаданные PHYPortID, тип Ethernet из входящего пакета и VlanID (при наличии) для определения типа сетевого уровня и выходного порта LFB к нисходящему LFB. Блок EtherClassifier LFB также задает новые метаданные с идентификатором логического порта для последующего использования. EtherClassifier может создавать для каждого пакета дополнительные метаданные, включая EtherType, SrcMAC, DstMAC, LogicPortID и т. п., потребляемые нисходящими LFB.
Если пакет классифицирован как IPv4, он передается нисходящему IPv4Validator LFB (параграф 5.2.1) для проверки, где пакеты IPv4 просматриваются на предмет пригодности и классифицируются как индивидуальные или групповые. Индивидуальные пакеты передаются в нисходящий IPv4UcastLPM LFB (параграф 5.3.1).
В IPv4UcastLPM LFB находится самый длинный совпадающий префикс и выбирается next-hop. Метаданные с идентификатором next-hop создаются IPv4UcastLPM LFB и потребляются IPv4NextHop LFB (параграф 5.3.2).
IPv4NextHop LFB использует идентификатор метаданных для определения выходного порта, типа инкапсуляции в среду и т. п. IPv4NextHop LFB создает метаданные L3PortID , служащие для идентификации выходного физического или логического порта для данного next-hop. В примере выходной порт следующего интервала имеет тип Ethernet, поэтому пакет и метаданные идентификатора порта L3 передаются нисходящему EtherEncap LFB (параграф 5.1.4).
EtherEncap LFB инкапсулирует входящий пакет в кадр Ethernet. Блок BasicMetadataDispatch LFB (параграф 5.5.1) следует за EtherEncap LFB и выполняет окончательную диспетчеризацию пакетов по физическим или логическим портам на основе полученных метаданных L3PortID.
7.2. Обработка ARP
На рисунке 3 показан процесс обработки пакета ARP для случая функций реализации обработки ARP в CE. Это не единственный вариант обработки ARP, которая может выполняться и в FE, но это выходит за рамки документа.
+---+ +---+
| | Пакеты ARP | |
| |-------------->---------+--->| | В CE
...-->| | . | | |
| | . | +---+
| | . | RedirectOut
+---+ ^
Ether EtherEncap | Пакеты IPv4 без информации
Classifier +---+ | ARP
| | |
Пакеты, требующие| |--------->---+
...--------->| |
инкапсуляции L2 | |
+---+ | | +------+
| | +-->| |--+ +---+ |Ether |
| | | +---+ | | |--------->|MACOut|-->...
От CE| |--+ +-->| | . +------+
| |Пакеты ARP | | .
| |от CE | | . +------+
| | | |--------> |Ether |-->...
+---+ +---+ |MACOut|
RedirectIn BasicMetadata +------+
Dispatch
Рисунок 3. Пример использования LFB для ARP.
Имеется два пути запуска обработки ARP в CE, как показано на рисунке 3:
-
пакеты ARP, приходящие извне NE;
-
пакеты IPV4, не распознанные в FE.
Пакеты ARP от сетевых интерфейсов фильтруются EtherClassifier LFB. Классифицированные пакеты ARP и связанные с ними метаданные передаются нисходящему RedirectOut LFB (параграф 5.4.2) для пересылки CE.
EtherEncap LFB (параграф 5.1.4) получает пакеты, которым нужна инкапсуляция Ethernet L2. Когда EtherEncap LFB не может найти нужной информации L2 для инкапсуляции пакета, он выводит пакет в свой порт ExceptionOut LFB. Портом нисходящего для EtherEncap LFB блока ExceptionOut LFB является RedirectOut LFB, который передает пакет CE (параграф 5.1.4).
Для решения этой задачи CE нужно генерировать запросы и отклики ARP, а также передавать их во внешние сети (за пределы NE). Пакеты запросов и откликов ARP от CE передаются в FE с помощью RedirectIn LFB (параграф 5.4.1).
Как и в примере с пересылкой пакетов IPv4, исходящие пакеты ARP инкапсулируются в формат Ethernet блоком EtherEncap LFB, а затем диспетчеризуются по разным интерфейсам с помощью BasicMetadataDispatch LFB на основе метаданных L3PortID, включенных в каждый пакет ARP, переданный от CE.
8. Взаимодействие с IANA
Агентство IANA организовало реестр имен и идентификаторов ForCES LFB с размещением класса ForCES LFB в соответствии с правилами использования пространства имен.
Этот документ регистрирует уникальные имена и числовые идентификаторы LFB, перечисленные в разделе 8.1. Помимо этого документ определяет перечисленные ниже пространства имен.
-
Metadata ID (параграфы 4.3 и 4.4).
-
Exception ID (параграф 4.4).
-
Validate Error ID (параграф 4.4).
8.1. Имена и идентификаторы классов LFB
Классы LFB, определенные в этом документе, относятся к классам, определенным Standards Track RFC. В соответствии с правилами IANA используется процедура Standards Action для значений 0 – 65535 и First Come First Served для значений больше 65535.
Таблица 1. Имена и идентификаторы классов LFB.
|
Идентификатор класса LFB |
Имя класса LFB |
Описание |
Документ |
|---|---|---|---|
|
3 |
EtherPHYCop |
Определяет абстракцию порта Ethernet на физическом уровне. |
параграф 5.1.1 |
|
4 |
EtherMACIn |
Определяет входной порт Ethernet на уровне MAC. |
параграф 5.1.2 |
|
5 |
EtherClassifier |
Задает процесс декапсуляции Ethernet и классификации пакетов. |
параграф 5.1.3 |
|
6 |
EtherEncap |
Определяет процесс инкапсуляции пакетов IP в Ethernet. |
параграф 5.1.4 |
|
7 |
EtherMACOut |
Определяет выходной порт Ethernet на уровне MAC. |
параграф 5.1.5 |
|
8 |
IPv4Validator |
Выполняет проверку пригодности пакетов IPv4. |
параграф 5.2.1 |
|
9 |
IPv6Validator |
Выполняет проверку пригодности пакетов IPv6. |
параграф 5.2.2 |
|
10 |
IPv4UcastLPM |
Выполняет поиск самого длинного совпадающего префикса IPv4. |
параграф 5.3.1 |
|
11 |
IPv6UcastLPM |
Выполняет поиск самого длинного совпадающего префикса IPv6. |
параграф 5.3.3 |
|
12 |
IPv4NextHop |
Определяет процесс выбора действия IPv4 next-hop. |
параграф 5.3.2 |
|
13 |
IPv6NextHop |
Определяет процесс выбора действия IPv6 next-hop. |
параграф 5.3.4 |
|
14 |
RedirectIn |
Определяет процесс вставки CE пакетов данных в топологию LFB. |
параграф 5.4.1 |
|
15 |
RedirectOut |
Определяет процесс для LFB в FE по доставке пакетов CE. |
параграф 5.4.2 |
|
16 |
BasicMetadata |
Диспетчеризует пакеты по выходным портам на базе метаданных. |
параграф 5.5.1 |
|
17 |
GenericScheduler |
Определяет процесс предварительного базового планирования. |
параграф 5.5.2 |
8.2. Идентификаторы метаданных
Пространство имен Metadata ID имеет размер 32 бита. Рекомендации по распределению значений даны ниже.
Metadata ID из диапазона 0x00000001-0x7FFFFFFF выделяются по процедуре Specification Required [RFC5226] и должны быть документированы в RFC или других постоянно доступных документах.
Таблица 2. Идентификаторы метаданных.
|
Значение |
Имя |
Документ |
|---|---|---|
|
0x00000000 |
Reserved |
RFC 6956 |
|
0x00000001 |
PHYPortID |
RFC 6956, параграф 4.4 |
|
0x00000002 |
SrcMAC |
RFC 6956, параграф 4.4 |
|
0x00000003 |
DstMAC |
RFC 6956, параграф 4.4 |
|
0x00000004 |
LogicalPortID |
RFC 6956, параграф 4.4 |
|
0x00000005 |
EtherType |
RFC 6956, параграф 4.4 |
|
0x00000006 |
VlanID |
RFC 6956, параграф 4.4 |
|
0x00000007 |
VlanPriority |
RFC 6956, параграф 4.4 |
|
0x00000008 |
NextHopIPv4Addr |
RFC 6956, параграф 4.4 |
|
0x00000009 |
NextHopIPv6Addr |
RFC 6956, параграф 4.4 |
|
0x0000000A |
HopSelector |
RFC 6956, параграф 4.4 |
|
0x0000000B |
ExceptionID |
RFC 6956, параграф 4.4 |
|
0x0000000C |
ValidateErrorID |
RFC 6956, параграф 4.4 |
|
0x0000000D |
L3PortID |
RFC 6956, параграф 4.4 |
|
0x0000000E |
RedirectIndex |
RFC 6956, параграф 4.4 |
|
0x0000000F |
MediaEncapInfoIndex |
RFC 6956, параграф 4.4 |
|
0x80000000-0xFFFFFFFF |
Резерв для приватного использования |
RFC 6956 |
8.3. Exception ID
Пространство имен Exception ID имеет размер 32 бита. Рекомендации по распределению значений даны ниже.
Exception ID из диапазона 0x00000001-0x7FFFFFFF выделяются по процедуре Specification Required [RFC5226] и должны быть документированы в RFC или других постоянно доступных документах.
Таблица 3. Идентификаторы исключительных ситуаций.
|
Значение |
Имя |
Документ |
|---|---|---|
|
0x00000000 |
AnyUnrecognizedExceptionCase |
параграф 4.4 |
|
0x00000001 |
ClassifyNoMatching |
параграф 4.4 |
|
0x00000002 |
MediaEncapInfoIndexInvalid |
параграф 4.4 |
|
0x00000003 |
EncapTableLookupFailed |
параграф 4.4 |
|
0x00000004 |
BadTTL |
параграф 4.4 |
|
0x00000005 |
IPv4HeaderLengthMismatch |
параграф 4.4 |
|
0x00000006 |
RouterAlertOptions |
параграф 4.4 |
|
0x00000007 |
IPv6HopLimitZero |
параграф 4.4 |
|
0x00000008 |
IPv6NextHeaderHBH |
параграф 4.4 |
|
0x00000009 |
SrcAddressException |
параграф 4.4 |
|
0x0000000A |
DstAddressException |
параграф 4.4 |
|
0x0000000B |
LPMLookupFailed |
параграф 4.4 |
|
0x0000000C |
HopSelectorInvalid |
параграф 4.4 |
|
0x0000000D |
NextHopLookupFailed |
параграф 4.4 |
|
0x0000000E |
FragRequired |
параграф 4.4 |
|
0x0000000F |
MetadataNoMatching |
параграф 4.4 |
|
0x80000000-0xFFFFFFFF |
Резерв для приватного использования |
RFC 6956 |
8.4. Validate Error ID
Пространство имен Validate Error ID имеет размер 32 бита. Рекомендации по распределению значений даны ниже.
Validate Error ID из диапазона 0x00000000-0x7FFFFFFF из диапазона 0x00000001-0x7FFFFFFF выделяются по процедуре Specification Required [RFC5226] и должны быть документированы в RFC или других постоянно доступных документах.
Таблица 4. Идентификаторы ошибок при проверке пригодности.
|
Значение |
Имя |
Документ |
|---|---|---|
|
0x00000000 |
AnyUnrecognizedValidateErrorCase |
параграф 4.4 |
|
0x00000001 |
InvalidIPv4PacketSize |
параграф 4.4 |
|
0x00000002 |
NotIPv4Packet |
параграф 4.4 |
|
0x00000003 |
InvalidIPv4HeaderLengthSize |
параграф 4.4 |
|
0x00000004 |
InvalidIPv4LengthFieldSize |
параграф 4.4 |
|
0x00000005 |
InvalidIPv4Checksum |
параграф 4.4 |
|
0x00000006 |
InvalidIPv4SrcAddr |
параграф 4.4 |
|
0x00000007 |
InvalidIPv4DstAddr |
параграф 4.4 |
|
0x00000008 |
InvalidIPv6PacketSize |
параграф 4.4 |
|
0x00000009 |
NotIPv6Packet |
параграф 4.4 |
|
0x0000000A |
InvalidIPv6SrcAddr |
параграф 4.4 |
|
0x0000000B |
InvalidIPv6DstAddr |
параграф 4.4 |
|
0x80000000-0xFFFFFFFF |
Резерв для приватного использования |
RFC 6956 |
9. Вопросы безопасности
Документ, определяющий схему ForCES [RFC3746], содержит рассмотрение вопросов безопасности всей архитектуры ForCES. Например, подлинность элементов протокола ForCES должна проверяться в соответствии с требованиями ForCES до предоставления им доступа к информационным элементам, описанным в этом документе, по протоколу ForCES. Спецификация ForCES [RFC5810] включает полное описание механизмов защиты, которые реализации должны поддерживать. Основанный на SCTP уровень транспортного отображения (TML) для протокола ForCES [RFC5811] задает механизмы защиты для этого транспортного отображения ForCES. Определенные здесь LFB похожи на другие LFB модели FE [RFC5812] и имеют такие же проблемы безопасности. Поэтому вопросы безопасности протокола ForCES, рассмотренные в [RFC5810], применимы и к этому документу.
10. Литература
10.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, “Forwarding and Control Element Separation (ForCES) Protocol Specification”, RFC 5810, March 2010.
[RFC5811] Hadi Salim, J. and K. Ogawa, “SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol”, RFC 5811, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, “Forwarding and Control Element Separation (ForCES) Forwarding Element Model”, RFC 5812, March 2010.
10.2. Дополнительная литература
[IEEE.802-1Q] IEEE, “IEEE Standard for Local and metropolitan area networks — Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks”, IEEE Standard 802.1Q, 2011.
[RFC1122] Braden, R., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., “Requirements for IP Version 4 Routers”, RFC 1812, June 1995.
[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2)”, STD 58, RFC 2578, April 1999.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework”, RFC 3746, April 2004.
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
Приложение A. Благодарности
Авторы благодарны перечисленным ниже людям, внесшим свой вклад в подготовку этого документа.
Edward Crabbe
Adrian Farrel
Rong Jin
Bin Zhuge
Ming Gao
Jingjing Zhou
Xiaochun Wu
Derek Atkins
Stephen Farrell
Meral Shirazipour
Jari Arkko
Martin Stiemerling
Stewart Bryant
Richard Barnes
Приложение B. Участники работы
Авторы признательны Jamal Hadi Salim, Ligang Dong и Fenggen Jia за основной вклад в создание документа. Ligang Dong и Fenggen Jia были авторами ранних документов, ставших предшественниками данного документа.
Jamal Hadi Salim
Mojatatu Networks
Ottawa, Ontario
Canada
EMail: hadi@mojatatu.com
Ligang Dong
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R. China
EMail: donglg@zjsu.edu.cn
Fenggen Jia
National Digital Switching Center (NDSC)
Jianxue Road
Zhengzhou 452000
P.R. China
EMail: jfg@mail.ndsc.com.cn
Authors’ Addresses
Weiming Wang
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R. China
Phone: +86 571 28877751
EMail: wmwang@zjsu.edu.cn
Evangelos Haleplidis
University of Patras
Department of Electrical & Computer Engineering
Patras 26500
Greece
EMail: ehalep@ece.upatras.gr
Kentaro Ogawa
NTT Corporation
Tokyo
Japan
EMail: ogawa.kentaro@lab.ntt.co.jp
Chuanhuang Li
Hangzhou DPtech
6th Floor, Zhongcai Group, 68 Tonghe Road, Binjiang District
Hangzhou 310051
P.R. China
EMail: chuanhuang_li@zjsu.edu.cn
Joel Halpern
Ericsson
P.O. Box 6049
Leesburg, VA 20178
USA
Phone: +1 703 371 3043
EMail: joel.halpern@ericsson.com
Перевод на русский язык
Николай Малых
1Logical Function Block.
2Forwarding and Control Element Separation – разделение элементов пересылки и управления.
3Forwarding Element.
4Internet Engineering Task Force.
5Internet Engineering Steering Group.
6Maximum Transmission Unit – максимальный размер передаваемого блока.
7Internet Control Message Protocol – протокол управляющих сообщений Internet.
8Interior gateway protocol – протокол внутреннего шлюза.
9Exterior gateway protocol – протокол внешнего шлюза.
10Media Access Control – контроль доступа к среде.
11Packet over SONET – пакеты в SONET.
12Asynchronous Transfer Mode – асинхронный режим передачи.
13Simple Network Management Protocol – простой протокол сетевого управления.
14Structure of Management Information – структура управляющей информации.
15Neighbor Discovery – обнаружение соседей.
16Longest Prefix Match – наиболее длинное совпадение префикса.
17Equal-cost multipath.
18Reverse path forwarding.
19Round Robin.