RFC: 3034
Оригинал: Use of Label Switching on Frame Relay Networks Specification
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Мельников Дмитрий Анатольевич

Оглавление

1. Введние

Существует возможность использования коммутаторов на основе ретрансляции кадров (Frame Relay switch, FR) в качестве маршрутизаторов на основе маркеров потоков (Label Switching Router, LSR). Такие FR-коммутаторы реализуют алгоритмы маршрутизации сетевого уровня (например, OSPF, IS-IS и др.), и поэтому они осуществляют доставку на основе результатов такой маршрутизации. В этой связи, нет необходимости использовать FR-маршрутизацию.

Если FR-коммутатор используется для обеспечения коммутации на основе маркеров, то верхний в наборе маркер, на основании которого принимается решение о дальнейшей доставке, размещается в DLCI-поле (Data Link Connection Identifier, идентификатор канала передачи данных/соединения канального уровня) заголовка FR-кадра (канального уровня). Вся дополнительная информация транслируется вместе с верхним маркером в наборе маркеров (если IP-пакет помечен несколько раз), но при этом она не обрабатывается FR-коммутатором. Сам же маркер (вместе с набором других маркеров) располагается между протокольным FR-заголовком канального уровня протокольным IP-заголовком сетевого уровня (рис. 1).

Расположение набора маркеров

Рис. 1. Расположение набора маркеров

Постоянные виртуальные FR-каналы (Frame Relay permanent virtual circuit, PVC) могут быть настроены для доставки трафика на основе маркеров потока. DLCI-идентификаторы можно использовать в качестве MPLS-маркеров, тогда FR-коммутаторы могли бы стать FR/LSR-коммутаторами (Frame Relay Label Switching Routers, FR-LSR), а MPLS-трафик можно было бы обрабатывать в соответствие с данным стандартом, и доставлять его на основе служебной (маршрутной) информации сетевого (IP-) уровня.

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

  • LSR-маршрутизатор (Label Switching Router)

    MPLS-узел, который обеспечивает обработку и доставку реальных IP-пакетов (сетевого уровня).

  • LC/FR-интерфейс (label switching controlled Frame Relay interface)

    FR-интерфейс, управляемый программным MPLS-модулем. IP-пакеты, доставляемые через LC/FR-интерфейс, содержат маркеры потоков в DLCI-поле.

  • FR/LSR-коммутатор

    LSR-маршрутизатор, имеющий один или более LC/FR-интерфейсов, и который транслирует FR-кадры между двумя такими интерфейсами, используя для этого маркеры потока, расположенные в DLCI-поле.

  • Сетевой FR/LSR-сегмент (FR-LSR domain)

    Совокупность FR/LSR-коммутаторов, которые взаимодействуют между собой через LC/FR-интерфейсы.

  • Граничные LSR-маршрутизаторы сетевого FR/LSR-сегмента (edge set of an FR-LSR domain)

    Совокупность LSR-маршрутизаторов, которые соединены с сетевым FR/LSR-сегментом через LC/FR-интерфейсы.

  • Вставка маркера потока при доставке (forwarding encapsulation)

    Тип MPLS-вставки при ретрансляции IP-пакета (Frame Relay, ATM, универсальная MPLS-вставка), который определяет MPLS-доставку IP-пакета, или когда имеет место вставка маркера на сетевом уровне, если такой IP-пакет доставляется на основе данных, содержащихся в заголовке сетевого уровня (IP-уровень и др.).

  • Вставка маркера потока на входе (input encapsulation)

    Тип MPLS-вставки при ретрансляции IP-пакета (Frame Relay, ATM, универсальная MPLS-вставка), когда такой пакет поступил на интерфейс LSR-маршрутизатора, или когда имеет место вставка маркера на сетевом уровне (IP-уровень и др.), если такой IP-пакет не ретранслировался с использованием MPLS-вставки.

  • Вставка маркера потока на выходе (output encapsulation)

    Тип MPLS-вставки при ретрансляции IP-пакета (Frame Relay, ATM, универсальная MPLS-вставка), когда такой пакет передан на интерфейс LSR-маршрутизатора, или когда имеет место вставка маркера на сетевом уровне (IP-уровень и др.), если такой IP-пакет не ретранслировался с использованием MPLS-вставки.

  • Входное TTL-значение (input TTL)

    TTL-значение в MPLS-вставке (в верхнем маркере из набора), когда помеченный IP-пакет поступил на LSR-интерфейс, или, когда IP-пакет не помечен, то — TTL-значение в заголовке IP-пакета (сетевого уровня).

  • Выходное TTL-значение (output TTL)

    TTL-значение в MPLS-вставке (в верхнем маркере из набора), когда помеченный IP-пакет передан на LSR-интерфейс, или, когда IP-пакет не помечен, то — TTL-значение в заголовке IP-пакета (сетевого уровня).

3. Специализированные свойства FR-коммутаторов

Несмотря на то, что MPLS-архитектура допускает большое разнообразие программных LSR-модулей (маршрутизаторов), функционирование FR/LSR-коммутатора определяется характеристиками (возможно заранее установленными) аппаратной части и ограничивается некоторыми объективными условиями, например, формат FR-кадра, устанавливаемыми стандартами FR-архитектуры (например, RFC-2427, FR-форум — FRF, и др.). Это связано с тем, что некоторые условия предопределяют наличие и применение некоторых специализированных процедур, необходимых для FR/LSR-коммутаторов. К некоторым ключевым свойствам FR-маршрутизаторов, которые определяют их функционирование как LSR-маршрутизаторов, относятся следующие:

  • Функция замены маркеров реализуется по отношению к DLCI-полям в заголовке FR-кадра. А это устанавливает размер и место маркера(ов) в пакете. Длина DLCI-поля может быть 10 бит (в режиме «по умолчанию») или 23 бита, для чего может понадобиться 2 или 4 байта в заголовке.

  • В общем, функция уменьшения TTL-значения на единицу не предусмотрена, в то время как в обычных маршрутизаторах такая функция реализована.

  • Контроль и управление перегрузкой реализуется каждым сетевым узлом на основе переданных в фазе установления соединения параметров. Перед заголовками FR-кадров могут быть использованы последовательности флагов (рис. 1) вследствие, например, перегрузки, или превышения согласованных значений параметров соединения.

  • Несмотря на то, что стандартный коммутатор может быть настроен на сквозное сходящееся соединение (multipoint-to-point circuit), когда на входе коммутатора несколько входных интерфейсов с различными DLCI-идентификаторами, а на выходе — один выходной интерфейс с одним DLCI-идентификатором, он, как правило, не поддерживает сквозное многоадресное соединение (multipoint-to-multipoint VC).

В данном документе представлены способы применения MPLS-коммутации в FR-коммутаторах, которые функционируют в рамках рассмотренных выше ограничений.

4. Вставка маркеров потока

В режиме «по умолчанию» все помеченные пакеты должны доставляться с универсальной MPLS-вставкой (RFC-3032) на основе применения способа пустой FR-вставки (рис.2).

Расположение маркер потока

Рис. 2. Расположение маркер потока

Значение n определяет длину адреса (Q.922) и может иметь значение 2 или 4 октета. На рис. 3 представлены форматы 2- и 4-октетного DLCI-идентификаторов (с указанием порядка следования бит).

Форматы 2- и 4-октетного DLCI-идентификаторов

Рис. 3. Форматы 2- и 4-октетного DLCI-идентификаторов

Использование пустой FR-вставки означает, что маркеры в неявной форме отображают тип сетевого протокола. Правила формирования набора маркеров и процедуры при обнаружении ошибок определены в RFC-3032.

Универсальная MPLS-вставка содержит n маркеров для набора маркеров глубиной n , в котором верхняя запись содержит соответствующие значения: собственно маркер, бит «S » (окончание набора маркеров) и TTL-поле, но не в интересах маркера, доставляемого в DLCI-поле заголовка FR-кадра, закодированном в формате Q.922 (рис. 3).

5. Обработка сообщений FR/LSR-коммутаторов

5.1. Использование DLCI-идентификаторов

MPLS-коммутация реализуется путём привязки маркеров к маршрутам, а также на основе использования значения маркера для доставки пакетов, включая определение значения любого заменяемого маркера. При использовании FR/LSR-коммутаторов верхний (текущий) MPLS-маркер доставляется в DLCI-поле заголовка FR-кадра. Верхний маркер содержит информацию в неявной форме о протоколе сетевого уровня.

Если два FR/LSR-коммутатора соединены друг с другом, то для функционирования LDP-протокола (Label Distribution Protocol) должно быть организовано полностью дуплексное соединение. DLCI-идентификатору, используемого в интересах виртуального соединения (Virtual Circuit, VC) LDP-протокола, присваивается значение с помощью процедуры настройки, аналогично настройке DLCI-идентификатора, используемого между коммутаторами при функционировании протоколов IP-маршрутизации.

За исключением этого настраиваемого значения параметра, значения DLCI-идентификатора, используемого в MPLS-системах в обоих направлениях канала передачи данных, могут рассматриваться как относящиеся к двум независимым диапазонам, т.е. каждое направление имеет свой собственный DLCI-идентификатор (VC-соединения могут быть полудуплексными).

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

5.2. Однородные LSP-маршруты

Если <LSR1 , LSR2 , LSR3 > является LSP-маршрутом, то можно предположить, что LSR1 , LSR2 и LSR3 будут использовать один и тот же способ кодирования при доставке IP-пакета P от LSR1 до LSR2 и далее до LSR3 . Такой LSP-маршрут является однородным.

5.3. Неоднородные LSP-маршруты

Если <LSR1 , LSR2 , LSR3 > является LSP-маршрутом, то можно предположить, что LSR1 будет использовать один способ кодирования при доставке IP-пакета P от LSR1 до LSR2 , а LSR2 — другой способ кодирования при доставке IP-пакета P до LSR3 . В целом, MPLS-архитектура допускает использование LSP-маршрутов с различными видами кодирования на разных ретрансляционных участках. После получения помеченного IP-пакета, LSR-маршрутизатор обязан декодировать его с целью определения текущего значения в наборе маркеров, а затем — проанализировать набор маркеров с целью определения значение нового маркера для набора, после чего — закодировать соответствующим образом значение нового маркера, и в последующем — отправить помеченный IP-пакет на следующий ретрансляционный участок.

Естественно, существуют MPLS-сети, в которых функционируют комбинированные FR/LSR-коммутаторы и обычные LSR-маршрутизаторы, при этом последние использовать различные типы MPLS-вставки, например, универсальная MPLS-вставка (заголовок с MPLS-вставкой) или ATM-вставка. В таких сетях могут функционировать LSR-маршрутизаторы, имеющие FR-интерфейсы и интерфейсы для универсальной MPLS-вставки (MPLS shim). Примером сказанного является LSR-маршрутизатор, реализующий различные способы кодирования маркеров потока на разных ретрансляционных участках одного и того же LSP-маршрута. Такой LSR-маршрутизатор может удалить кодовый FR-маркер на входном интерфейсе, а на выходном интерфейсе вставить универсальную MPLS-вставку.

5.4. Обнаружение и предотвращение петлевых LSP-маршрутов

FR/LSR-коммутаторы должны взаимодействовать со свободными FR/LSR-коммутаторами или FR-сегментами LSP-маршрутов, приводящими к петлевым маршрутам. Более того, FR/LSR-коммутаторы должны использовать соответствующие способы и средства выявления и предотвращения петлевых маршрутов.

5.4.1. Обнаружение FR/LSR-коммутаторов, приводящих к петлевым маршрутам (обработка TTL-времени в MPLS-системах)

В MPLS-системах TTL-значение, содержащееся в наборе маркеров, представляет собой способ, который используется для:

  1. предотвращения петлевых маршрутов;
  2. ограничения области действия IP-пакета.

Когда IP-пакет следует по LSP-маршрутe, он должен завершить маршрут с таким же TTL-значением, которое он мог бы иметь, если бы проследовал через такую же последовательность маршрутизаторов, но не использующих MPLS-коммутацию. Если IP-пакет следует по иерархической совокупности LSP-маршрутов, то общее число ретрансляционных LSR-участков должно отображаться в TTL-значении этого IP-пакета, когда последний покидает такой иерархический маршрут.

В MPLS-системах начальное TTL-значение размещается в новой записи, вставляемой в набор маркеров. Это начальное TTL-значение изымается из предшествующего (ранее используемого) TTL-поля, которое было представлено, либо в заголовке сетевого уровня, если набор маркеров ранее отсутствовал, либо из ранее существовавшей записи на более низком уровне в наборе маркеров.

FR/LSR-коммутаторы, транслируя помеченные IP-пакеты с помощью маркеров одного уровня, не уменьшают значение в TTL-поле. Последовательность таких FR/LSR-коммутаторов образует сетевой сегмент без контроля TTL-поля (non-TTL segment).

Когда IP-пакет выходит из сетевого сегмента, не контролирующего TTL-поле, тогда всё-таки целесообразно отобразить в TTL-поле число ретрансляционных LSR-участков, пройденных этим IP-пакетом. В случае использования однонаправленного адреса, это можно обеспечить путём распространения реальной протяжённости LSP-маршрута или протяжённость сетевого LSP/FR-сегмента до выходных FR/LSR-узлов, способных уменьшить значение в TTL-поле, прежде чем IP-пакеты будут доставлены в сетевой сегмент, не контролирующий TTL-поле.

Если входной FR/LSR-коммутатор, при уменьшении TTL-значения в рамках MPLS-системы, определит, что TTL-значение соответствующего IP-пакета будет просрочено ещё до его выхода из сетевого сегмента, не контролирующего TTL-поле, то FR/LSR-коммутатор обязан не транслировать этот IP-пакет с помощью MPLS-коммутации, а следовать рекомендациям, представленным в RFC-3032, и попытаться направить ответное сообщение об ошибке IP-узлу отправителю этого IP-пакета, т.е.:

  1. Он интерпретирует IP-пакет, как просроченный, и направляет ответное ICMP-сообщение отправителю этого просроченного IP-пакета.

  2. Он транслирует далее IP-пакет, как не помеченный, и содержащий TTL-значение, которое соответствует TTL-значению, указанному в заголовке сетевого уровня.

Если входное TTL-значение равно единице, то реализуется только первое правило, рассмотренное выше.

В случае групповой адресации, реальная протяжённость LSP-маршрута или протяжённость сетевого LSP/FR-сегмента распространяется до выходного FR/LSR-узла, который способен уменьшить значение в TTL-поле, прежде чем IP-пакеты будут доставлены в сетевой сегмент, не контролирующий TTL-поле.

5.4.2. Вычисление TTL-времени в MPLS-системах

Вычисление входного TTL-значение (input TTL), которое в последующем становится выходным TTL-значением (output TTL), зависит от:

  1. входной вставки (input encapsulation);
  2. доставляемой вставки (forwarding encapsulation);
  3. выходной вставки (output encapsulation).

Связь между этими тремя значениями может быть представлена как функция D от входной (ie ), доставляемой (fe ) и выходной вставок (oe ). Соответственно, вычисление входного TTL-значение (TTLвх ), которое в последующем преобразуется в выходное TTL-значение (TTLвых ), может быть определено следующим образом:

TTLвых
 = TTLвх
 – D(ie, fe, oe)

или в краткой форме:

TTLвых
 = TTLвх
 – d

где d может принимать три значения: «0», «1» или число ретрансляционных участков в сегменте LSP-маршрута.

В таблице №1 представлены значения d для передачи с использованием однонаправленного адреса.

d Тип повторного обрамления на входе Тип повторного обрамления при доставке Тип повторного обрамления на выходе
0 Ретрансляция кадров Ретрансляция кадров Ретрансляция кадров
1 Любое Универсальная MPLS-вставка Универсальная MPLS-вставка
Число ретрансляционных участков в сегменте LSP-маршрута Любое Универсальная MPLS-вставка или IP-протокол (сетевой уровень) Ретрансляция кадров
Таблица №1

Число ретрансляционных участков в сегменте LSP-маршрута представляет собой значение «счётчика ретрансляционных участков», которое добавляется в маркер потока, используемый при доставке IP-пакета. Если LDP-протокол обеспечивает функцию «счётчик ретрансляционных участков», то значение последнего доставляется в составе маркера потока по LSP-маршруту (т.е. в составе LDP-сообщение имеется поле «hop count object»). Если же LDP-протокол не обеспечивает функцию «счётчика ретрансляционных участков» или обеспечивает поддержку «неизвестного значения» (unknown value), то значение «счётчика ретрансляционных участков в сегменте LSP-маршрута» равно единице.

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

В таблице №2 представлены значения d для передачи с использованием групповой адресации.

d Тип повторного обрамления на входе Тип повторного обрамления при доставке Тип повторного обрамления на выходе
0 Ретрансляция кадров Ретрансляция кадров Ретрансляция кадров
1 Любое Универсальная MPLS-вставка или IP-протокол (сетевой уровень) Ретрансляция кадров
Число ретрансляционных участков в сегменте LSP-маршрута Ретрансляция кадров Универсальная MPLS-вставка или IP-протокол (сетевой уровень) Любое
Таблица №2

Обозначим доставляемую вставку (forwarding encapsulation) символом «I » при использовании IP-сетей (сетевой уровень), «G » при использовании универсальной MPLS-вставки и «F » при использовании MPLS-коммутации на основе FR-сетей. Аналогично, обозначим LSR-интерфейс символом «i », если входная или выходная вставка относится к сетевому уровню (IP-сеть) и не откосится к MPLS-вставке, «g », если входная или выходная вставка является универсальной MPLS-вставкой, «f », если используется MPLS-коммутация на основе FR-сети, «a », если используется MPLS-коммутация на основе ATM-сети. Кроме этого, в дальнейшем будем использовать следующие символы «iIf », «gGf », «fFf » и т.п. для обозначения LSR-маршрутизаторов, которые осуществляют необходимые входные, доставляемые и выходные вставки, имеющие рассмотренное выше кодирование.

На рис. 4 и 5 представлены примеры однородного (homogeneous) и не однородного (heterogeneous) LSP-маршрутов (соответственно), в которых используется рассмотренное выше кодирование.

Пример однородного LSP-маршрута

Рис. 4. Пример однородного LSP-маршрута

Пример не однородного LSP-маршрута

Рис. 5. Пример не однородного LSP-маршрута

На рис. 6 и 7 приведены примеры расчёта TTL-значения на входе LSP-маршрута на базе FR-сети при использовании однонаправленного адреса и на выходе LSP-маршрута на базе FR-сети при использовании групповой адресации, соответственно.

Пример расчёта TTL-значения на входе LSP-маршрутов на базе FR-сети при использовании однонаправленного адреса

Рис. 6. Пример расчёта TTL-значения на входе LSP-маршрутов на базе FR-сети при использовании однонаправленного адреса

Пример расчёта TTL-значения на выходе LSP-маршрутов на базе FR-сети при использовании групповой адресации

Рис. 7. Пример расчёта TTL-значения на выходе LSP-маршрутов на базе FR-сети при использовании групповой адресации

5.5. Обработка маркеров потока входными FR/LSR-коммутаторами

Если IP-пакет впервые «попадает» в сетевой MPLS-сегмент, то он отправляется с помощью стандартных процедур доставки сетевого уровня, за исключением выходной вставки набора MPLS-маркеров, включающего, по крайней мере, одну запись (RFC-3032).

«Нулевая» FR-вставка содержит информацию о протоколе сетевого уровня, которая в неявном виде транслируется в составе маркера потока. При этом последний должен быть связан только с указанным сетевым протоколом.

TTL-поле, расположенное в верхней записи набора маркеров, заполняется в соответствие с аналогичным полем в заголовке сетевого уровня (либо «TTL», либо «Hop Limit»), значение которого было получено после доставки (и обработки IP-заголовка) на сетевом уровне (RFC-3032). Последующая обработка FR/LSR-коммутатором идентична в двух следующих возможных случаях:

  1. Однородный LSP-маршрут — только FR-сеть — FR/LSR-коммутатор является входным.

  2. Не однородный LSP-маршрут — LSP-маршрут формируется из сетевых FR-, PPP-, ATM-, Ethernet- и других сегментов — FR/LSR-коммутатор является входом в сетевой FR-сегмент.

Для IP-пакетов с однонаправленными адресами, TTL-значение в MPLS-системах должно уменьшаться на число ретрансляционных участков, либо однородного LSP-маршрута на основе FR-сети, либо сетевого FR-сегмента неоднородного LSP-маршрута. Программный LDP-модуль (LDP-протокол), отвечающий за формирование LSP-маршрута, обязан направлять входному FR/LSR-коммутатору всю необходимую информацию, касающуюся числа ретрансляционных участков сетевого сегмента, не контролирующего TTL-поле.

Для IP-пакетов с групповой адресацией, TTL-значение в MPLS-системах должно уменьшаться на единицу. Программный LDP-модуль, отвечающий за формирование LSP-маршрута, обязан направлять выходному FR/LSR-коммутатору всю необходимую информацию, касающуюся числа ретрансляционных участков сетевого сегмента, не контролирующего TTL-поле.

В дальнейшем, IP-пакет, «помещённый» в FR-кадр, который используется в MPLS-системе, направляется по каналу передачи данных, и при этом FR-кадр включает верхний маркер, расположенный в поле выходного DLCI-идентификатора. FR-кадр, используемый в MPLS-системе и содержащий IP-пакет, доставляется по виртуальному FR-соединению следующему LSR-маршрутизатору.

5.6. Обработка маркеров потока магистральными FR/LSR-коммутаторами

На выходе FR/LSR-коммутатора текущий (верхний) MPLS-маркер размещается в DLCI-поле заголовка FR-кадра. Также как и в стандартной FR-сети, поступивший на интерфейс FR-кадр содержит в своём заголовке входной DLCI-идентификатор, который просматривается в DLCI-БД (база данных, содержащая информацию о DLCI-идентификаторах), и затем заменяется на выходной DLCI-идентификатор. И после этого, вновь сформированный FR-кадр транслируется через выходной интерфейс (доставляется по ретрансляционному участку на следующий сетевой узел).

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

5.7. Обработка маркеров потока выходными FR/LSR-коммутаторами

Когда FR-кадр достигает конечной точки LSP-маршрута, FR/LSR-коммутатор удаляет набор маркеров. Если удалённый маркер был последним маркером, то необходимо определить соответствующий протокол сетевого уровня, пакет которого транслировался по LSP-маршруту. Набор маркеров не содержит информации в явной форме, по которой можно определить протокол сетевого уровня. Это должно следовать из значения маркера, который удаляется из набора маркеров.

Если удалённый маркер не был последним маркером, то предыдущее TTL-значение верхнего уровня набора MPLS-маркеров отображается в новой верхней записи этого набора.

Если FR/LSR-коммутатор является выходом сетевого FR-сегмента гибридного LSP-маршрута, и в тоже время конечная точка сетевого FR-сегмента не является конечной точкой LSP-маршрута, то MPLS-пакет будет обработан на основе NHLFE-записи (Next Hop Label Forwarding Entry) с целью его дальнейшей доставки по следующему ретрансляционному участку LSP-маршрута (RFC-3031). Значение выходного маркера также извлекается из NHLFE-записи, а TTL-значение MPLS-системы уменьшается на соответствующую величину, зависящую от выходного интерфейса или типа ретрансляционной процедуры. Далее MPLS-пакет доставляется в соответствие с MPLS-требованиями для конкретного канала связи следующего ретрансляционного участка (сетевого сегмента) LSP-маршрута.

Для IP-пакетов с однонаправленными адресами, TTL-значение в MPLS-системах должно уменьшаться на единицу, если выходной интерфейс является универсальным MPLS-интерфейсом, или на число ретрансляционных участков следующего сетевого ATM-сегмента неоднородного LSP-маршрута, если выходной интерфейс является ATM-интерфейсом, не контролирующим TTL-поле (non-TTL).

Для IP-пакетов с групповой адресацией, TTL-значение в MPLS-системах должно уменьшаться на число ретрансляционных участков сетевого FR-сегмента, являющегося выходным. Программный LDP-модуль, отвечающий за формирование LSP-маршрута, обязан направлять выходному FR/LSR-коммутатору всю необходимую информацию, касающуюся числа ретрансляционных участков сетевого FR-сегмента, не контролирующего TTL-поле.

6. Модуль MPLS-управления для FR-сетей

Для обеспечения MPLS-коммутации FR-коммутатор обязан иметь встроенный модуль управления MPLS-коммутацией, который, в первую очередь, реализует процедуры распределения (размещения) и обработки маркеров потока. Информация о привязке маркера может быть доставлена несколькими способами, одним из которых является протокол распределения маркеров потока (Label Distribution Protocol, LDP, RFC-3036 / RFC-5036).

Так как модуль управления MPLS-коммутацией использует информацию, которая напрямую поступает от программных модулей маршрутизации сетевого уровня, это предполагает, что коммутатор выступает одной из сторон при информационном взаимодействии в соответствие с такими протоколами (например, OSPF, IS-IS).

В отдельных случаях LSR-маршрутизаторы могут использовать и другие протоколы (например, RSVP, PIM, BGP) для распространения данных о привязках маркеров. В таких случаях FR/LSR-коммутатор должен участвовать в процедурах информационного взаимодействия, реализуемых в соответствие с такими протоколами.

В случае, когда FR-соединения формируются с помощью, либо LDP-протокола, либо RSVP-протокола, либо иного протокола, без использования обычных FR-способов, предполагается, что согласуемая информация при формировании соединения (например, максимальный размер входного/выходного кадра, запрашиваемое/подтверждаемое значение входной/выходной пропускной способности, доступное значение входной/выходной пропускной способности, входное/выходное значение фрагментации, входная/выходная скорость передачи кадров), используемая в последующем при передаче, и данные для управления перегрузками могут доставляться FR/LSR-коммутаторам с помощью процедур информационного обмена, реализуемых в соответствие с RSVP-протоколом. С учётом сказанного выше, считается, что FR-соединения могут формироваться и в статическом режиме. Также предполагается, что управление перегрузками и маркирование заголовка кадра, как результат перегрузки, могло бы осуществляться FR/LSR-коммутаторами в таком же режиме, как и при обычных FR-соединениях. С целью имитации наилучшего функционирования маршрутизатора в режиме «по умолчанию», т.е. параметров виртуального соединения в режиме «по умолчанию», при отсутствии LDP- и RSVP-модулей, либо иных средств, участвующих в настройке необходимых параметров, целесообразно, чтобы значение «CIR» (Committed Information Rate, согласованная скорость передачи информации) было нулевым, вследствие чего входной модуль управления будет устанавливать бит «DE» в значение «1» в принимаемых кадрах, но не уничтожать эти кадры.

Данные управления и о состоянии соединений, основанных на MPLS-коммутации, могут доставляться с помощью LDP-протокола.

Обеспечение MPLS-коммутации FR-коммутатором требует согласования только кадровой синхронизации, процедуры бит-стаффинга, формата заголовков, алгоритма вычисления и длины поля проверочной суммы, исключая процедуры сигнализации по управлению PVC-соединением и настройку интерфейса локального управления и сигнализации (Local Management Interface — LMI). Система сигнализации, определяемая Рекомендацией ITU-T Q.933, для PVC- и/или SVC-соединений (Switched Virtual Circuit, коммутируемое виртуальное соединение) также не требуется. Система сигнализации для PVC- и/или SVC-соединений может использоваться для PVC- и/или SVC-соединений, не предназначенных для MPLS-коммутации (стандартная FR-коммутация), когда обе системы реализованы на одном и том же MPLS-интерфейсе.

6.1. Гибридные коммутаторы (корабли в ночи, «Ships in the Night»)

Наличие в FR-коммутаторе модуля MPLS-управления не устраняет возможности применения модуля FR-управления, описание которого представлено в международных стандартах ITU-T и FRF (Frame Relay Forum). Два модуля MPLS- и FR-управления могут функционировать независимо.

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

7. Процедуры распределения и обработки маркеров

Процедурная и логическая характеристики LDP-протокола представлены в RFC-3031 и RFC-3036 (RFC-5036). Рассматриваемый ниже способ распределения и обработки маркера «нисходящий поток по требованию» (downstream-on-demand) должен использоваться FR/LSR-коммутаторами, которые не поддерживают функцию слияния (объединения) VC-соединений (этот способ используется для доставки трафика с поузловой маршрутизацией).

7.1. Функционирование граничного LSR-маршрутизатора

Рассмотрим функционирование граничного LSR-маршрутизатора из группы граничных LSR-маршрутизаторов, входящих в сетевой FR/LSR-сегмент. Предположим, что в результате его маршрутных вычислений он выбрал FR/LSR-коммутатор в качестве следующего ретрансляционного участка некоторого маршрута (FEC-класс), и что следующий ретрансляционный участок подключён через LC/FR-интерфейс. Будем считать, что на противоположной стороне следующего ретрансляционного участка расположен FR/LSR-коммутатор, который является участником (одной из сторон) информационного взаимодействия по LDP-протоколу (LDP-peer). Граничный LSR-маршрутизатор отправляет LDP-запрос (request) LSRНП для привязки маркера к следующему ретрансляционному участку. Когда этот граничный LSR-маршрутизатор получает ответ от LSRНП (LDP-сообщение «отображение», mapping), в котором содержится информация о привязке маркера, он сохраняет маркер в соответствующей БД (Label Information Base, LIB) в качестве выходного маркера для данного FEC-класса. Принятое LDP-сообщение «отображение» может включать поле «счётчик ретрансляционных участков», содержащее число ретрансляционных участков, на которое следует уменьшить TTL-значение после прохождения IP-пакетом сетевого FR/LSR-сегмента до выходного FR/LSR-коммутатора при использовании данного маркера. Такая информация может храниться для последующих расчётов TTL-значений. После того, как всё это будет выполнено, LSR-маршрутизатор может использовать MPLS-коммутацию для трансляции IP-пакетов данного FEC-класса.

Когда граничный LSR-маршрутизатор из группы граничных LSR-маршрутизаторов, входящих в сетевой FR/LSR-сегмент, получает LDP-запрос от FR/LSR-коммутатора в интересах определённого FEC-класса, это означает, что данный граничный LSR-маршрутизатор является выходным FR/LSR-коммутатором. По получении LDP-запроса, он формирует и сохраняет маркер, т.е. делает новую запись в своей LIB-базе и помещает в неё (в специальное поле «входящий маркер») этот маркер. После этого, данный LSR-маршрутизатор отправляет ответное LDP-сообщение («отображение»), содержащее сформированный маркер, назад по направлению восходящего потока противоположной стороне сквозного LDP-соединения, передавшей запрос. Ответное LDP-сообщение («отображение») содержит поле «счётчик ретрансляционных участков» со значением «1»

Когда в результате маршрутизационных вычислений граничному LSR-маршрутизатору необходимо изменить следующий ретрансляционный участок маршрута, а предыдущий ретрансляционный участок находился в сетевом FR/LSR-сегменте, граничный LSR-маршрутизатор должен оповестить противоположную сторону предыдущего ретрансляционного участка (с помощью LDP-сообщения «разъединение», release), что данные о привязке маркера, относительно данного маршрута, больше не нужны.

Когда FR/LSR-коммутатор получает LDP-запрос (сообщение «запрос») в интересах определённого маршрута (FEC-класса) от противоположной стороны LDP-соединения, установленного с этим FR/LSR-коммутатором через LC/FR-интерфейс, тогда FR/LSR-коммутатор выполняет следующие действия:

  • Формирует и сохраняет маркер, т.е. делает новую запись в своей LIB-базе и помещает в неё (в специальное поле «входящий маркер») этот маркер;

  • Направляет LDP-сообщение «запрос» LSR-маршрутизатору, расположенному на противоположной стороне следующего ретрансляционного участка, по направлению нисходящего потока для данного маршрута (FEC-класса).

В режиме «регулируемого управления LSP-маршрутом» (RFC-3031) FR/LSR-коммутатор будет ожидать команду на отправку своего «запроса», на который он в последствие получит ответ от LSRНП , содержащий сообщение «отображение», прежде чем отправит ответное сообщение «отображение» LSRВП на запрос последнего. В данном случае FR/LSR-коммутатор уменьшит на единицу число ретрансляционных участков, полученное от LSRНП , и будет использовать это значение в ответных сообщениях «отображение», направляемых LSRВП .

В качестве альтернативы, FR/LSR-коммутатор может направить LSRВП данные о привязке маркера, не дожидаясь получения данных о привязке маркера от LSRНП (режим «управления LSP-маршрутом»). В этом случае, FR/LSR-коммутатор использует зарезервированное значение числа ретрансляционных участков в отправляемом сообщении «отображение», указывая в последнем, что это число ему не известно. Корректное значение числа ретрансляционных участков будет отправлено позднее, как это определено ниже.

Так как оба режима управления LSP-маршрутом (регулируемое и независимое) имеют свои преимущества и недостатки, то право выбор режима остаётся за конкретной реализацией системы или субъектом настройки параметров системы.

После того, как FR/LSR-коммутатор получит от противоположной стороны следующего ретрансляционного участка ответное LDP-сообщение («отображение»), он размещает маркер потока в специальном поле «исходящий маркер» LIB-записи.

Следует заметить, что FR/LSR-коммутатор или граничный LSR-маршрутизатор из группы граничных LSR-маршрутизаторов, входящих в сетевой FR/LSR-сегмент, может получить несколько запросов на данные о привязке для одного и того же маршрута (FEC-класса) от одного и того же FR/LSR-коммутатора. Тогда он должен сформировать новое ответное сообщение «отображение» с маркером потока для каждого запроса (полагая, что для этого достаточно ресурсов) и сохранить любой(ые) существующей(ие) маркер(ы) потока. Также целесообразно, чтобы FR/LSR-коммутатор для каждого полученного запроса сформировал новый запрос на данные о привязке к следующему ретрансляционному участку маршрута (FEC-класса).

Когда в результате маршрутизационных вычислений FR/LSR-коммутатору необходимо изменить следующий ретрансляционный участок маршрута (FEC-класса), FR/LSR-коммутатор должен оповестить противоположную сторону предыдущего ретрансляционного участка (с помощью LDP-сообщения «разъединение»), что данные о привязке маркера, относительно данного маршрута, больше не нужны.

Когда LSR-маршрутизатор получает извещение о том, что соответствующие данные о привязке маркера больше не нужны, он может открепить маркер от FEC-класса, а саму привязку уничтожить. Этот режим называется «консервативным режимом сохранения маркера потока» (conservative label retention mode, RFC-3031). Там, где LSR-маршрутизатор получает извещение и уничтожает привязку, ему целесообразно оповестить противоположную сторону следующего ретрансляционного участка, что данные о привязке маркера больше не нужны. Если же LSR-маршрутизатор не уничтожает привязку маркера потока (FR/LSR-коммутатор функционирует в «свободном режиме сохранения маркера потока», liberal label retention mode), то он может повторно использовать эту привязку, но только тогда, когда он получит запрос относительно одного и того же маршрута и с одним и тем же значением счётчика ретрансляционных участков, как если бы он получил запрос от противоположной стороны ретрансляционного участка на формирование привязки маркера потока.

При изменении маршрута, привязки маркеров потока должны повторно формироваться, причём с той точки, в которой «уклонился» от предыдущего маршрута. LSRВП в такой точке «не обращает внимание» на произошедшее изменение (за одним исключением, рассмотренным ниже). Всякий раз, когда LSR-маршрутизатор изменяет свой следующий ретрансляционный участок соответствующего маршрута, и если на его противоположной стороне размещён FR/LSR-коммутатор или граничный LSR-маршрутизатор из группы граничных LSR-маршрутизаторов, подключённый через LC/FR-интерфейс, то для каждой своей LIB-записи, относящейся к маршруту, LSR-маршрутизатор должен отправить запрос (используя LDP-соединение) на получение данных о привязке от противоположной стороны нового ретрансляционного участка.

Когда FR/LSR-коммутатор получает данные о привязке маркера от соседнего LSRНП , он возможно уже имеет подготовленный соответствующий маркер для данного маршрута до соседнего LSRВП . Это может быть следствием, либо того, что FR/LSR-коммутатор функционирует в режиме независимого управления LSP-маршрутом, либо того, что данные о новой привязке маркера, полученные от LSRНП , являются результатом изменения маршрута. В таком случае, целесообразно извлечь из данных о новой привязке маркера значение счётчика ретрансляционных участков и увеличить его на единицу. Если новое значение счётчика ретрансляционных участков отличается от того, которое было ранее отправлено соседнему LSRВП (включая случай, когда соседний LSRВП получил значение «не известно»), FR/LSR-коммутатор обязан сообщить об этом изменении соседнему LSRВП . Каждый FR/LSR-коммутатор в последовательности LSP-маршрута увеличивает значение счётчика ретрансляционных участков и отправляет его LSRВП , причём до тех пор, пока оно не достигнет входного граничного LSR-маршрутизатора.

Всякий раз, когда FR/LSR-коммутатор направляет запрос на данные о привязке маркера LSR-маршрутизатора на противоположной стороне следующего ретрансляционного участка, вследствие приёма запроса на данные о привязке маркера от другого LSRВП , и этот отправленный LSR-маршрутизатору на противоположной стороне следующего ретрансляционного участка не был удовлетворён, FR/LSR-коммутатор, в ответ на принятый запрос, должен уничтожить сформированную привязку и проинформировать об этом запрашивающую сторону, используя для этого LDP-сообщение «изъятие» (withdraw).

Когда LSR-маршрутизатор установит, что LDP-соединение с другим LSR-маршрутизатором прервано, он выполняет следующие действия:

  • Обязан уничтожить любые данные о привязке, полученные по этому соединению;

  • Любые данные о привязках маркеров, которые были сформированы в результате приёма запросов на данные о привязках маркеров от противоположной стороны соединения, могут быть уничтожены LSR-маршрутизатором (последний также может открепить маркеры от FEC-классов, связанные с этими привязками).

7.2. Эффективное использование диапазона маркеров — функция слияния, реализуемая FR/LSR-коммутаторами

В предыдущем параграфе 7.1 предполагалось, что граничный LSR-маршрутизатор будет запрашивать по одному маркеру потока для каждого префикса из своей маршрутной таблицы, который отображает следующий ретрансляционный участок в сетевом FR/LSR-сегменте. Фактически, имеется возможность существенно уменьшить необходимое число маркеров за счёт использования одного маркера для нескольких маршрутов вместо запроса граничного LSR-маршрутизатора. Использование сходящихся (many-to-one) отображений между маршрутами (префиксы IP-адресов) и маркерами на основе эквивалентных классов доставки[?] (Forwarding Equivalence Classes, FEC-классы) позволяет (представляет собой способ) уменьшить/сохранить число используемых маркеров.

Следует заметить, что уменьшение диапазона маркеров (объединение VC-соединений) может быть ограничено в том случае, когда последовательность кадров (трафик) требует FR-фрагментации. Проблема в том, что FR-фрагменты должны передаваться последовательно, т.е. фрагменты разных кадров не должны быть перемежающимися. Если FR/LSR-коммутатор, реализующий функцию фрагментации, гарантирует, что передача последовательности всех фрагментов кадра будет осуществляться без перемежения с фрагментами других кадров, то можно говорить об уменьшении (сохранении) числа маркеров (объединение VC-соединений).

Если реализуется способ уменьшения (сохранения) числа маркеров, и если FR/LSR-коммутатор получает запрос на данные о привязке маркера от для соответствующего FEC-класса и он уже имеет привязку исходящего маркера для этого же FEC-класса, то ему нет необходимости направлять LSRНП запрос на данные о привязке. Вместо этого, FR/LSR-коммутатор может зафиксировать (разместить в своей LIB-базе) входящий маркер и отправить этот маркер в составе сообщения о привязке обратно LSRВП , который прислал запрос. IP-пакеты, принятые от LSRВП , который присылал запрос, и содержащие маркер на верхнем уровне набора маркеров, будут доставляться дальше после замены этого маркера на существующий исходящий маркер для данного FEC-класса. Если FR/LSR-коммутатор не обладает исходящим маркером, привязанным к данному FEC-классу, но имеет неисполненный запрос для этого FEC-класса, то ему нет необходимости отправлять другой запрос. Это означает, что в случае уменьшения (сохранения) числа маркеров, FR/LSR-коммутатор обязан отправить ответ, содержащий данные о новой привязке маркера, на каждый запрос от LSRВП , но ему может понадобиться передать LSRНП всего лишь один запрос на данные о привязке.

В случае уменьшения (сохранения) числа маркеров, и если изменения в маршрутной таблице «вынуждают» FR/LSR-коммутатор выбрать новый ретрансляционный участок для одного из своих FEC-классов, то он может удалить привязку этого маршрута от «старого» ретрансляционного участка. Если же FR/LSR-коммутатор ещё не имеет данных о соответствующей привязке для нового ретрансляционного участка, то он обязан их запросить (необходимо заметить, что выбор нового ретрансляционного участка зависит от режима сохранения маркера потока, RFC-3031).

Если данные о новой привязке получены, и они включают значение счётчика ретрансляционных участков, отличающееся от значения в старых данных о привязке, то FR/LSR-коммутатор обязан выполнить следующие действия:

  • Увеличить это значение на единицу, если оно не является «неизвестным»;

  • Уведомить о новом значении счётчика ретрансляционных участков соседние LSRВП , которые имеют привязки маркеров для этого FEC-класса.

Для обеспечения гарантированного обнаружения петлевых маршрутов, в случае, когда новое значение счётчика ретрансляционных участков превысило «максимальное» значение, соответствующие маркеры для данного FEC-класса должны быть отозваны у всех соседних LSRВП , которым ранее высылались данные о привязке этих маркеров.

7.3. LDP-сообщения для FR-сетей

LDP-сообщения, которыми обмениваются два FR/LSR-коммутатора, являющиеся взаимодействующими сторонами LDP-соединения, могут содержать специализированную информацию в интересах FR-сетей. К такой информации относится:

  1. Диапазон FR-маркеров (Frame Relay Label Range)

    | 0             6 | 7   8 | 9                                      31 |
+-----------------+-------+-------------------------------------------+
| Зарезервировано | Длина | Минимальное значение DLCI-идентификатора  |
+-----------------+-------+-------------------------------------------+
|     Зарезервировано     | Максимальное значение DLCI-идентификатора |
+-------------------------+-------------------------------------------+
Рис. 8. Формат блока данных «диапазон FR-маркеров»

    На рис. 8 представлен формат блока данных «диапазон FR-маркеров», который включает следующие поля:

    • «Зарезервировано»

      Эти поля являются резервными. Они должны заполняться нулями при передаче и игнорироваться при приёме.

    • «Длина»

      Это поле определяет число бит DLCI-идентификатора. Оно может принимать следующие значения:

      1. «0» — 10-битовый DLCI-идентификатор;
      2. «2» — 23-битовый DLCI-идентификатор;
      3. «1» и «3» — зарезервированы для будущего использования;

    • «Минимальное значение DLCI-идентификатора» (Minimum DLCI)

      Это 23-битовое поле содержит двоичное значение нижней границы диапазона DLCI-идентификаторов, которое поддерживается FR/LSR-коммутатором. Минимальное значение DLCI-идентификатора должно правильно размещаться в этом поле, а все предшествующие биты должны быть нулевыми.

    • «Максимальное значение DLCI-идентификатора» (Maximum DLCI)

      Это 23-битовое поле содержит двоичное значение верхней границы диапазона DLCI-идентификаторов, которое поддерживается FR/LSR-коммутатором. Максимальное значение DLCI-идентификатора должно правильно размещаться в этом поле, а все предшествующие биты должны быть нулевыми.

  1. Объединение VC-соединений в FR-сети (Frame Relay Merge)

    Данная информация необходима для определения функциональности FR/LSR-коммутатора: способен ли он объединять VC-соединения или нет.

    | 0             6 | 7 |
+-----------------+---+
| Зарезервировано | M |
+-----------------+---+
Рис. 9. Формат блока данных «объединение VC-соединений в FR-сети»

    На рис. 9 представлен формат блока данных «объединение VC-соединений в FR-сети», который включает следующие поля:

    • «Зарезервировано»

      Это поле является резервными. Оно должно заполняться нулями при передаче и игнорироваться при приёме.

    • «Объединение VC-соединений» («М»)

      Это 1-битовое поле определяет функциональность FR/LSR-коммутатора. Оно может принимать следующие значения:

      1. «0» — FR/LSR-коммутатор не способен объединять VC-соединения;
      2. «1» — FR/LSR-коммутатор способен объединять VC-соединения;

      • FR-LSR-коммутатор, который способен объединять VC-соединения, обязан гарантировать, что фрагментируемые кадры с входящими DLCI-идентификаторами не будут перемежаться на выходе с фрагментами кадров, имеющих иные исходящие DLCI-идентификаторы.

    • Маркер в FR-сети (Frame Relay Label)

      | 0             6 | 7   8 | 9                                      31 |
+-----------------+-------+-------------------------------------------+
| Зарезервировано | Длина |            DLCI-идентификатор             |
+-----------------+-------+-------------------------------------------+
Рис. 10. Формат блока данных «маркер в FR-сети»

      На рис. 10 представлен формат блока данных «маркер в FR-сети», который включает следующие поля:

      • «Зарезервировано»

        Это поле является резервными. Оно должно заполняться нулями при передаче и игнорироваться при приёме.

      • «Длина»

        Это поле определяет число бит DLCI-идентификатора. Оно может принимать следующие значения:

        1. «0» — 10-битовый DLCI-идентификатор;
        2. «2» — 23-битовый DLCI-идентификатор;
        3. «1» и «3» — зарезервированы для будущего использования;

      • «DLCI-идентификатор»

        Это двоичная величина FR-маркера. Соответствующее число бит (10 или 23) значения маркера отображают DLCI-идентификатор, который является часть заголовка FR-кадра канального уровня (параграф 4).

8. Проблемы обеспечения безопасности

К наиболее важным проблемам обеспечения информационной безопасности относятся:

  1. Безопасность потока кадров (FR-трафик).

  2. Безопасность распределения маркеров потока.

MPLS-вставка не влияет на аутентифицированные или зашифрованные пакеты сетевого уровня, т.е. IP-пакеты, которые были аутентифицированы или зашифрованы, не будут подвержены каким-либо изменениям.

MPLS-протокол не имеет каких-либо собственных средств для защиты от ложного перенаправления IP-пакетов или «маскарада», устроенного захваченного нарушителем LSR-маршрутизатором, вследствие возникновения нештатной ситуации или злого умысла.

Изменение информации вследствие нештатной ситуации или подделки существующего маркера в DLCI-поле заголовка FR-кадра, а также вследствие модификации одного или более полей, за которыми может следовать набор маркеров, приводит к нарушению доставки этого кадра.

Способ и средства распространения и доставки маркеров потока могут быть защищены на основе применения процедур аутентификации или шифрования на соответствующем уровне архитектуры безопасности по отношению к базовому протоколу, обеспечивающему доставку данные о маркерах потока (RFC-3036 / RFC-5036).

Ссылки

[MIFR] Bradley, T., Brown, C. и A. Malis, «Многопротокольные соединения через Frame Relay», RFC 2427, Сентябрь 1998.
[ARCH] Rosen, E., Callon, R. и A. Vishwanathan, «Архитектура многопротокольной коммутации на основе маркеров потока (MPLS)», RFC 3031, Январь 2001.
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. и R. Thomas, «Label Distribution Protocol», RFC 3036, Январь 2001.
[STACK] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. и A. Conta, «Кодирование набора маркеров в MPLS-системах», RFC 3032, Январь 2001.
[ATM] Davie, B., Lawrence, J., McCloghrie, M., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, «Применение MPLS-коммутации в сетях с асинхронным режимом доставки», RFC 3035, Январь 2001.
[ITU] International Telecommunications Union, «ISDN Data Link Layer Specification for Frame Mode Bearer Services», ITU-T Recommendation Q.922, 1992.
[FRF] Frame Relay Forum, User-to-Network Implementation Agreement (UNI), FRF 1.1, Январь 19, 1996.
2007 - 2022 © Русские переводы RFC, IETF, ISOC.