RFC 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks

1. Введение

Псевдопровод Ethernet позволяет передавать Ethernet/802.3 [802.3] PDU через сеть MPLS¹ [MPLS-ARCH]. Для решения вопросов, связанных с передачей Ethernet PDU через сеть с коммутацией пакетов (PSN²) в этом документе предполагается возможность организации псевдопровода (PW) с помощью протоколов управления таких, как описаны в [PWE3-CTRL]. Устройство псевдопровода Ethernet, описанное в этом документе, соответствует архитектуре PW, заданной в [RFC3985]. Предполагается, что читатели знакомы с RFC 3985.

Сквозная эмуляция псевдопровода PWE3³ для Ethernet PDU включает поля Destination Address, Source Address, Length/Type, MAC Client Data и заполнение из кадра MAC, как конкатенацию октетов в исходном порядке [PDU].

В дополнение к формату Ethernet PDU, используемому в псевдопроводе, этот документ рассматривает:

• процедуры применения PW для предоставления паре краевых абонентских маршрутизаторов CE⁴ эмулируемых услуг Ethernet (точка-точка), включая процедуры обработки PE⁵-bound и CE-bound Ethernet PDU [RFC3985];

• относящиеся к Ethernet вопросы качества обслуживания (QoS⁶) и безопасности;

• вопросы междоменной транспортировки Ethernet PW.

На рисунках 1 и 2 представлены эталонные модели (взяты из [RFC3985]) поддержки эмулируемых услуг Ethernet PW.

      |<------------- Эмулируемые службы --------------->|
      |                                                  |
      |          |<------ Псевдопровод ------>|          |
      |          |                            |          |
      |          |    |<-- Псевдопровод ->|    |          |
      | PW End   V    V                  V    V  PW End  |
      V Service  +----+                  +----+  Service V
+-----+    |     | PE1|==================| PE2|     |    +-----+
|     |----------|............PW1.............|----------|     |
| CE1 |    |     |    |                  |    |     |    | CE2 |
|     |----------|............PW2.............|----------|     |
+-----+  ^ |     |    |==================|    |     | ^  +-----+
      ^  |       +----+                  +----+     | |  ^
      |  |   Provider Edge 1         Provider Edge 2  |  |
      |  |                                            |  |
Customer |                                            | Customer
Edge 1   |                                            | Edge 2
         |                                            |
         |                                            |
Устройство подключения (AC)                  Устройство подключения (AC)
к естественному сервису Ethernet             к естественному сервису Ethernet

Рисунок 1. Конфигурация эталонного интерфейса PWE3 Ethernet/VLAN.

Показанные на рисунке 1 «эмулируемые службы» строго говоря являются ЛВС на основе мостов – PE имеют MAC-интерфейсы, воспринимают кадры управления MAC и т. п. Однако описываемые здесь процедуры поддерживают лишь ЛВС из двух CE. Поэтому такой сервис называется «emulated point-to-point Ethernet». Спецификация процедур использования псевдопроводов для эмуляции ЛВС с большим числом CE выходит за рамки этого документа.

+---------------+                                +---------------+
|  Эмуляция     |                                |  Эмуляция     |
|  Ethernet     |                                |  Ethernet     |
| (включая      |       Эмулируемые службы       | (включая      |
|  VLAN)        |<==============================>|  VLAN)        |
|               |                                |               |
+---------------+          Псевдопровод          +---------------+
|Демультиплексор|<==============================>|Демультиплексор|
+---------------+                                +---------------+
|    PSN        |          Псевдопровод          |    PSN        |
|   MPLS        |<==============================>|   MPLS        |
+---------------+                                +---------------+
|Физическ. уров.|                                |Физическ. уров.|
+------+--------+                                +------+--------+

Рисунок 2. Эталонная модель стека протоколов Ethernet PWE3.

В этом документе входной маршрутизатор обозначается PE1, выходной – PE2. L2 PDU будут приниматься PE1, инкапсулироваться им, транспортироваться, декапсулироваться PE2 и передаваться подключенному к PE2 устройству.

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

На рисунке 3 представлена эталонная модель точек завершения на каждой стороне PW внутри PE.

PW завершается в логической точке внутри PE, помеченной B на рисунке 3 внизу. Эта точка обеспечивает сервис Ethernet MAC, который будет доставлять каждый кадр Ethernet, полученный в точке A, без изменений в точку A соответствующего PE на другом конце псевдопровода PW.

Функция естественной обработки (NSP⁷) включает обработку, которая требуется для кадров Ethernet, пересылаемых в точку завершения PW. Это может включать вырезание, переписывание или добавление тегов VLAN, мультиплексирование и демультиплексирование физических портов, функции моста PW-PW, инкапсуляцию L2, формирование, правила и т. п. Эти функции относятся к Ethernet и могут не требоваться для службы эмуляции PW.

        +-----------------------------------+
        |                PE                 |
+---+   +-+  +-----+  +------+  +------+  +-+
|   |   |P|  |     |  |Завер-|  | PSN  |  |P|
|   |<==|h|<=| NSP |<=|шение |<=|Tunnel|<=|h|<== Из PSN
|   |   |y|  |     |  |PW    |  |      |  |y|
| C |   +-+  +-----+  +------+  +------+  +-+
| E |   |                                   |
|   |   +-+  +-----+  +------+  +------+  +-+
|   |   |P|  |     |  |Завер-|  | PSN  |  |P|
|   |==>|h|=>| NSP |=>|шение |=>|Tunnel|=>|h|==> В PSN
|   |   |y|  |     |  | PW    |  |      |  |y|
+---+   +-+  +-----+  +------+  +------+  +-+
        |                                   |
        +-----------------------------------+
                    ^         ^         ^
                    |         |         |
                    A         B         C

Рисунок 3. Эталонная модель PW.

Точки слева от A, включая физический уровень между CE и PE, а также любые функции адаптации (NSP) между этой точкой и завершением PW выходят за рамки PWE3 и не определяются здесь.

«Завершение PW» между A и B представляет операции для организации и поддержки PW, а также для инкапсуляции и декапсуляции кадров Ethernet при передаче через сеть MPLS.

Ethernet PW работает в одном из двух режимов – raw или tagged. В режиме с тегами каждый кадр должен включать хотя бы один тег 802.1Q [802.1Q] VLAN и значение тега важно для NSP в точках завершения PW. Т. е. две точки завершения PW должны иметь некое соглашение (заданное в конфигурации или через сигнализацию) по части обработки тега. В raw-режиме PW кадр может включать тег 802.1Q VLAN, но в этом случае тег не имеет значения для NSP и просто передается между ними.

Дополнительные термины, относящиеся к псевдопроводам и L2 VPN⁸ приведены в [RFC4026].

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119].

3. Заявление о применимости

Эмуляция Ethernet PW позволяет сервис-провайдерам предлагать связь между портами Ethernet через сети MPLS PSN, а эмуляция Ethernet VLAN PW позволяет организовывать через сети MPLS PSN сервис «Ethernet VLAN to VLAN».

Ethernet PW или Ethernet VLAN PW обладают рядом перечисленных ниже характеристик естественных служб.

• Ethernet PW соединяет два устройства подключения Ethernet AC⁹, а Ethernet VLAN PW – два устройства подключения Ethernet VLAN AC с поддержкой двухсторонней доставки кадров Ethernet переменных размеров. Входная функция NSP вырезает преамбулу и контрольную сумму FCS¹⁰ из кадра Ethernet и транспортирует кадр целиком через PW. Это выполняется независимо от наличия в кадре тега 802.1Q. Выходная функция NSP принимает кадр Ethernet и PW, а также восстанавливает для него преамбулу и FCS до пересылки кадра в присоединенное устройство. Поскольку значение FCS не передается через (Ethernet и Ethernet VLAN) PW, сквозной контроль целостности теряется. Можно использовать описанный в [FCS] необязательный метод сквозного контроля целостности для (Ethernet и Ethernet VLAN) PW.

• Для Ethernet VLAN PW тег VLAN может быть изменен NSP выходным PE, но это выходит за рамки документа.

• (Ethernet или Ethernet VLAN) PW может поддерживать передачу через псевдопровод только однотипных кадров Ethernet – обе стороны PW должны работать в одном из режимов (с тегами или без тегов). Функциональность NSP для поддержки разнотипных кадров выходит за рамки документа.

• Информация о состоянии порт Ethernet или Ethernet VLAN обеспечивается с использованием PW Status TLV¹¹ в сообщениях LDP¹² о состоянии. Потеря связности между PE может быть обнаружена по закрытию сессии LDP или с помощью механизмов [VCCV]. PE может возвращать эту информацию подключенным системам.

• Максимальный размер поддерживаемых кадров ограничивается PSN MTU за вычетом размера заголовка MPLS, если не применяет фрагментация и сборка [FRAG].

• В сети с коммутацией пакетов пакеты могут менять порядок, дублироваться, теряться или отбрасываться без уведомления. На (Ethernet или Ethernet VLAN) PW может применяться упорядочение для обнаружения потери, дублирования или нарушения порядка пакетов на уровне PW.

• Качество услуг (Ethernet или Ethernet VLAN) PW может быть повышено за счет использования функций QoS в PE и базовой PSN (см. параграф 4.7. Вопросы QoS).

4. Детали отдельных эмулируемых служб

4.1. Режим Ethernet Tagged

Кадры Ethernet инкапсулируются в соответствии с определенными ниже процедурами для режима с тегами (tagged). Следует отметить, что при изменении тега VLAN выходным PE, протокол Ethernet STP¹³ может работать некорректно. Если это важно, идентификатор VLAN должен выбираться так, чтобы он соответствовал присоединенным устройствам на обеих сторонах PW.

Если PE обнаруживает отказ физического порта Ethernet или порт отключен административно, должно передаваться уведомление о статусе PW для всех PW, связанных с этим портом.

В этом режиме используются теги разграничения служб (service-delimiting) для сопоставления входящих кадров Ethernet с PW и он соответствует PW типа 0x0004 «Ethernet Tagged Mode» [IANA].

4.2. Режим Ethernet Raw

Кадры Ethernet инкапсулируются в соответствии с определенными ниже процедурами для режима raw. Если PE обнаруживает отказ физического порта Ethernet или порт отключен административно, устройство PE должно передать уведомление о статусе PW соответствующему удаленному PE.

В этом режиме все кадры Ethernet, принимаемые на подключенном устройстве PE1, будут передаваться PE2 по одному псевдопроводу PW. Этот режим соответствует PW типа 0x0005 «Ethernet» [IANA].

4.3. LDP суб-TLV с параметрами интерфейса

Этот LDP суб-TLV [LDP] задает параметры интерфейса. Когда это применимо, параметр должен использоваться для проверки того, что оба PE, а также входной и выходной порт на выходе устройства имеют возможности, требуемые для взаимодействия. TLV параметров интерфейса определен в [PWE3-CTRL], начальные значения для типов суб-TLV указаны в реестре IANA [IANA], а относящиеся к Ethernet параметры интерфейса описаны ниже.

• 0x06 – суб-TLV для запроса VLAN ID

  Необязательное 16-битовое значение, указывающее запрошенный идентификатор VLAN ID. Этот параметр должен использоваться PE, не способным переписать на выходе тег 802.1Q Ethernet VLAN. Если входной PE получает такой запрос, он должен переписать значение VLAN ID во входящем теге VLAN в соответствии с запрошенным VLAN ID. Если это невозможно и VLAN ID не соответствует настроенному входному VLAN ID, превдопровод PW должен быть отключен. Параметр применим только для PW типа 0x0004.

4.4. Базовые процедуры

Когда NSP/Forwarder передает кадр функции завершения PW, выполняются перечисленные ниже действия.

• Вырезается преамбула (при наличии) и FCS.

• При необходимости перед кадром добавляется управляющее слово, определенное в параграфе 4.6. Управляющее слово CW. Условия, при которых управляющее слово не используется, указаны ниже.

• Перед полученным в результате пакетом помещается метка демультиплексирования псевдопровода.

• Перед полученным в результате пакетом помещаются данные инкапсуляции в туннель.

• Пакет передается.

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

Туннельная инкапсуляция зависит от организации MPLS PSN. Она может выполняться с меткой или без метки, а также с множеством меток. Для демультиплексирования псевдопровода используется метка MPLS, значение которой определяется протоколами организации и поддержки PW.

При поступлении пакета через PW туннельная инкапсуляция и метка демультиплексирования PW вырезаются. При наличии слова управления оно обрабатывается и вырезается. Полученный в результате кадр передается Forwarder/NSP. За регенерацию FCS отвечает NSP.

4.4.1. Режимы Raw и Tagged

Когда PE получает кадр Ethernet с тегом VLAN, возможны два случая, описанных ниже.

1. Тег указывает сервис (service-delimiting). Это означает, что тег был помещен в кадр неким элементом операторского оборудования и используется сервис-провайдером для того, чтобы различать трафик. Например, ЛВС разных абонентов могут подключаться к одному коммутатору сервис-провайдера, который использует теги VLAN, чтобы различать трафик каждого абонента при пересылке кадров в направлении PE.

2. Тег не указывает сервиса. Это значит, что тег помещен в кадр элементом абонентского оборудования и не имеет значения для PE.

Является ли тег указывающим сервис, зависит от локальной конфигурации PE.

Если Ethernet PW работает в режиме raw, указывающие сервис теги никогда не передаются через PW. При наличии тега в кадре, полученном PE от присоединенного устройства, тег должен быть вырезан (функцией NSP) из кадра до его передачи в PW.

Если Ethernet PW работает а режиме tagged, каждый переданный в PW кадр должен иметь указывающий сервис тег VLAN. Если полученный PE от присоединенного устройства кадр не имеет указывающего сервис тега VLAN, устройство PE должно добавить перед кадром «фиктивный» тег VLAN до отправки кадра в PW. Этот режим применяется по умолчанию и является единственным требуемым режимом.

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

В обоих режимах указывающий сервис тег имеет лишь логическую значимость, т. е. он важен только для конкретного интерфейса PE-CE. В режиме tagged устройство PE, получившее кадр от PW, может изменить значение тега, вырезать тег целиком или сохранить его без изменений, в зависимости от конфигурации. В режиме raw получившее кадр устройство PE может добавить указывающий сервис тег перед отправкой кадра присоединенному устройству, однако оно должно сохранить имеющиеся теги.

В таблице приведены операции, которые могут применяться на входе от присоединенного устройства.

4.4.2. Управление MTU на каналах PE/CE

Ethernet PW недопустимо включать, пока нет уверенности в том, что значения MTU на каналах CE-PE по обе стороны PW совпадают. Если выходной маршрутизатор получает инкапсулированные L2 PDU, где размер данных (payload), т. е. размер самого PDU без заголовков инкапсуляции, превышает MTU на целевом интерфейсе L2, PDU должен быть отброшен.

4.4.3. Порядок кадров

В общем случае приложения, работающие на базе Ethernet, не требуют строго порядка доставки кадров. Однако определение IEEE 802.3 [802.3] требует соблюдения порядка кадров одного «разговора» в контексте агрегирования каналов (параграф 43). Кроме того, в общем случае PSN не может обеспечивать сохранение порядка доставки кадров. Ethernet PW может за счет применения управляющего слова обеспечить строгое упорядочение кадров. Если эта опция включена, все кадры, доставленные с нарушением порядка в PSN, должны отбрасываться или упорядочиваться заново принимающей стороной PW. Если для конкретного PW нужен строгий порядок, эта опция должны быть включена.

4.4.4. Обработка ошибок в кадрах

Инкапсулированный кадр Ethernet при прохождении через псевдопровод может быть отброшен, поврежден или доставлен с нарушением порядка. Как описано в [PWE3-REQ], потеря, повреждение и нарушение порядка рассматриваются как «обобщенные битовые ошибки» (generalized bit error) в псевдопроводе. Поврежденные кадры PW детектируются на уровне PSN и отбрасываются.

На входе PW должен быть включен естественный механизм обработки ошибок в кадрах Ethernet. Поэтому, если устройство PE получает кадр Ethernet с ошибкой CRC¹⁴, ошибкой кадрирования или слишком короткий (runt), кадр должен быть отброшен на входе. Отметим, что определение этой обработки является частью функции NSP и выходит за рамки документа.

4.4.5. Управление потоком IEEE 802.3x между сетями

В стандартной сети Ethernet управление потоком данных не обязательно и обычно настраивается между парой узлов на соединениях «точка-точка» (например, между CE и PE). Кадры IEEE 802.3x PAUSE недопустимо передавать через PW. Управление потоком данных CE-PE описано в Приложении A.

4.5. Управление

Модель управления Ethernet PW следует общей модели управления PW, определенной в [RFC3985] и [PWE3-MIB]. Здесь представлено много общих средств управления PW без учета специфики Ethernet. Относящиеся к Ethernet параметры определены в отдельном модуле MIB [PW-MIB].

4.6. Управляющее слово CW¹⁵

Управляющее слово, определенное в этом параграфе, основано на Generic PW MPLS Control Word из [PWE3-CW]. Оно обеспечивает возможность упорядочить отдельные кадры в PW, а также избежать распределения пакетов между равноценными путями (ECMP) [RFC2992] и применения механизмов OAM¹⁶, включая VCCV [VCCV].

В [PWE3-CW] сказано «Если PW реагирует на нарушение порядка пакетов и передается через MPLS PSN с использованием содержимого данных MPLS (payload) для выбора пути ECMP, псевдопровод может реализовать механизм предотвращения нарушений порядка пакетов». Это требуется для того, чтобы реализации ECMP могли проверить первый полубайт после стека меток MPLS для определения принадлежности пакета к протоколу IP. Если MAC-адрес отправителя в кадре Ethernet, передаваемом через PW без управляющего слова, начинается с 0x4 или 0x6, он будет ошибочно сочтен пакетом IPv4 или IPv6. В зависимости от конфигурации и топологии сети MPLS это может приводить к ситуации, где пакеты данного PW будут передаваться по разным путям. В результате может возрасти число кадров с нарушением порядка доставки в данном PW или пакеты OAM пойдут по пути, отличающемуся от пути обычного трафика (см. параграф 4.4.3 Порядок кадров).

Функции, предоставляемые управляющим словом, могут не требоваться для данного Ethernet PW. Например, ECMP может не быть или не использоваться в данной сети MPLS, соблюдение порядка кадров может не требоваться и пр. В таких случаях роль слова управления невелика и оно может не использоваться. Ранние реализации Ethernet PW развертывались без CW и возможности обрабатывать слово управления при его наличии. Для совместимости со старыми версиями будущие реализации должны быть способны передавать и принимать кадры без CW.

Во всех случаях выходной PE должен знать, будет ли входной PE передавать слово управления для конкретного PW. Это можно обеспечить с помощью настройки PE или сигнализации, определенной в [PWE3-CTRL].

Формат слова управления показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|   Reserved            |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Первые 4 бита должны иметь значение 0 для указания данных PW. Следующие 12 битов зарезервированы на будущее. Они должны устанавливаться в 0 при передаче и должны игнорироваться получателем.

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

Пространство порядковых номеров имеет размер 16 битов, номера не содержат знака и используются в круговом режиме. Номер 0 указывает, что алгоритм проверки порядковых номеров не применяется. Алгоритм обработки номеров описан в [PWE3-CW].

4.7. Вопросы QoS

Входной PE может учитывать поле пользовательского приоритета (PRI) [802.1Q] в теге VLAN при определении значения поля QoS в протоколе инкапсуляции (например, в полях EXP стека меток MPLS). Аналогично, выходной PE может учитывать поле QoS протокола инкапсуляции (например, поля EXP в стеке меток MPLS) при постановке кадра в очередь для передачи CE.

PE должен поддерживать возможность передачи Ethernet PW как сервиса best-effort через сеть MPLS PSN. Биты PRI сохраняются неизменными между устройствами PE, независимо от поддержки QoS в PSN.

Если PE добавляет тег 802.1Q VLAN, должна поддерживаться установка по умолчанию PRI = 0, рекомендуется поддерживать заданное в конфигурации значение или значение может отображаться из поля QoS в PSN, как сказано выше.

PE может обеспечивать дополнительную поддержку QoS с использованием одного или нескольких методов:

1. один класс обслуживания (CoS¹⁷) на PWES¹⁸ отображается на один CoS PW в PSN;

2. множество CoS на PWES отображается на один PW с множеством CoS в PSN;

3. множество CoS на PWES отображается на PW в PSN.

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

Гарантированная скорость PW на уровне MPLS PSN определяется политикой сервис-провайдера PW на основе соглашения с абонентом и может отличаться от скорости физического порта Ethernet.

5. Вопросы безопасности

К псевдопроводам Ethernet применимы общие вопросы безопасности, рассмотренные в [RFC3985] и [PWE3-CTRL].

Псевдопровод Ethernet проходит через MPLS PSN, поэтому безопасность PW будет обеспечиваться лишь при хорошей защите MPLS PSN. Различные методы защиты MPLS PSN описаны в [MPLS-ARCH].

Защита, обеспечиваемая контролем доступа по MAC-адресам, выходит за рамки документа. Дополнительные требования безопасности для использования PW в коммутируемой среде (виртуальные мосты) выходят за рамки документа и не рассматриваются здесь.

6. Требования PSN MTU

Сеть MPLS PSN должна быть настроена с MTU, достаточно большим для доставки кадров Ethernet максимального размера со словом управления, меткой демульиплексирования и туннельной инкапсуляцией. При использовании MPLS в качестве протокола туннелирования, например, к максимальному размеру кадра добавляется не менее 8 байтов. Можно использовать методологию, описанную в [FRAG], для фрагментирования инкапсулированных кадров с учетом PSN MTU. Однако, если [FRAG] не применяется и входной маршрутизатор видит, что инкапсулированные L2 PDU превосходят размер MTU в туннеле PSN, куда они будут переданы, такие PDU должны отбрасываться.

7. Нормативные документы

[PWE3-CW] Bryant, S., Swallow, G., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN”, RFC 4385, February 2006.

[IANA] Martini, L., “IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)”, BCP 116, RFC 4446, April 2006.

[PWE3-CTRL] Martini, L., El-Aawar, N., Heron, G., Rosen, E., Tappan, D., and T. Smith, “Pseudowire Setup and Maintenance using the Label Distribution Protocol (LDP)”, RFC 4447, April 2006.

[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture”, RFC 3031, January 2001.

[802.3] IEEE802.3-2005, ISO/IEC 8802-3: 2000 (E), “IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications”, 2005.

[802.1Q] ANSI/IEEE Standard 802.1Q-2005, “IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks”, 2005.

[PDU] IEEE Std 802.3, 1998 Edition, “Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications” figure 3.1, 1998

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

8. Дополнительная литература

[RFC3985] Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture”, RFC 3985, March 2005.

[PW-MIB] Zelig, D. and T. Nadeau, “Ethernet Pseudo Wire (PW) Management Information Base”, Work in Progress¹⁹, February 2006.

[PWE3-REQ] Xiao, X., McPherson, D., and P. Pate, “Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)”, RFC 3916, September 2004.

[PWE3-MIB] Zelig, D., Ed. and T. Nadeau, Ed., “Pseudo Wire (PW) Management Information Base”, Work in Progress²⁰, February 2006.

[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, “LDP Specification”, RFC 3036²¹, January 2001.

[FRAG] Malis, A. and W. Townsley, “PWE3 Fragmentation and Reassembly”, Work in Progress²², February 2005.

[FCS] Malis, A., Allan, D., and N. Del Regno, “PWE3 Frame Check Sequence Retention”, Work in Progress²³, September 2005.

[VCCV] Nadeau, T., Ed. and R. Aggarwal, Ed., “Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)”, Work in Progress, August 2005.

[RFC2992] Hopps, C., “Analysis of an Equal-Cost Multi-Path Algorithm”, RFC 2992, November 2000.

[RFC4026] Andersson, L. and T. Madsen, “Provider Provisioned Virtual Private Network (VPN) Terminology”, RFC 4026, March 2005.

[L2TPv3] Lau, J., Townsley, M., and I. Goyret, “Layer Two Tunneling Protocol – Version 3 (L2TPv3)”, RFC 3931, March 2005.

9. Основные участники работы

Andrew G. Malis

Tellabs

90 Rio Robles Dr.

San Jose, CA 95134

EMail: Andy.Malis@tellabs.com

Dan Tappan

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

EMail: tappan@cisco.com

Steve Vogelsang

ECI Telecom

Omega Corporate Center

1300 Omega Drive

Pittsburgh, PA 15205

EMail: stephen.vogelsang@ecitele.com

Vinai Sirkay

Reliance Infocomm

Dhirubai Ambani Knowledge City

Navi Mumbai 400 709

India

EMail: vinai@sirkay.com

Vasile Radoaca

Nortel Networks

600 Technology Park

Billerica MA 01821

EMail: vasile@nortelnetworks.com

Chris Liljenstolpe

Alcatel

11600 Sallie Mae Dr.

9th Floor

Reston, VA 20193

EMail: chris.liljenstolpe@alcatel.com

Kireeti Kompella

Juniper Networks

1194 N. Mathilda Ave

Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Tricci So

Nortel Networks 3500 Carling Ave.,

Nepean, Ontario,

Canada, K2H 8E9.

EMail: tso@nortelnetworks.com

XiPeng Xiao

Riverstone Networks

5200 Great America Parkway

Santa Clara, CA 95054

EMail: xxiao@riverstonenet.com

Christopher O. Flores

T-Systems

10700 Parkridge Boulevard

Reston, VA 20191

USA

EMail: christopher.flores@usa.telekom.de

David Zelig

Corrigent Systems

126, Yigal Alon St.

Tel Aviv, ISRAEL

EMail: davidz@corrigent.com

Raj Sharma

Luminous Networks, Inc.

10460 Bubb Road

Cupertino, CA 95014

EMail: raj@luminous.com

Nick Tingle

TiMetra Networks

274 Ferguson Drive

Mountain View, CA 94043

EMail: nick@timetra.com

Sunil Khandekar

TiMetra Networks

274 Ferguson Drive

Mountain View, CA 94043

EMail: sunil@timetra.com

Loa Andersson

TLA-group

EMail: loa@pi.se

Приложение A. Рекомендации по совместимости

A.1. Конфигурационные опции

Ниже приведен список опций конфигурации для Ethernet PW «точка-точка» в опорных точках, показанных на рисунке 3.

Рисунок 4. Опции конфигурации.

Разрешенные комбинации приведены ниже.

Сервис Raw не разрешено использовать вместе с другими услугами на одном виртуальном порту NSP (A). Все другие комбинации разрешены, если нет конфликтов VLAN в точке (A). Отметим, что в большинстве приложений PW «точка-точка» виртуальный порт NSP совпадает с физическим портом.

A.2. Управление потоком данных IEEE 802.3x

Если приемный узел перегружен, он может передать специальный кадр PAUSE узлу-отправителю на противоположной стороне соединения. Реализация должна обеспечивать механизм локальной обработки кадров PAUSE (например, в локальном PE). Это должно происходить так – кадры PAUSE, принятые на локальном порту Ethernet, следует использовать для перевода устройства PE в режим буферизации или отбрасывания последующих кадров Ethernet для этого порта, пока условие PAUSE не будет снято. Опционально PE может просто отбрасывать кадры PAUSE.

Если устройство PE хочет приостановить прием кадров на локальном порту Ethernet (возможно в результате нехватки локальных буферов или уведомления о перегрузке в PSN), оно может передать кадр PAUSE в локальный порт Ethernet, но должно снять это условие, когда сможет продолжить прием данных.

Приложение B. Детали QoS

В параграфе 4.7. Вопросы QoS описаны разные режимы поддержки PW QOS в сети PSN. Примеры для услуг VLAN «точка-точка» приведены ниже.

• Классификация PW на основе поля VLAN, но с отображением пользовательских битов PRI на другую маркировку CoS (и поведение сети) на уровне PW. Примером служит отображение PW на E-LSP в сети MPLS.

• Классификация PW на основе поля VLAN и битов PRI, но с отображением кадров с разными битами PRI на разные PW. Примером служит отображение PWES на разные L-LSP в сети MPLS PSN для поддержки множества CoS в сети с поддержкой L-LSP или отображение PWES на множество сессий L2TPv3 [L2TPv3].

  Конкретные значения, выделяемые в PSN для разных CoS, выходят за рамки этого документа.

B.1. Передача 802.1Q CoS в PSN CoS

Не требуется использовать в PSN определение CoS в соответствии с [802.1Q], а отображение 802.1Q CoS на PSN CoS зависит от приложения и соглашения между абонентом и оператором PW. Однако приведенные ниже принципы из таблицы 8-2 в 802.1Q должны соблюдаться при использовании набора PSN CoS на базе пользовательских битов PRI.

Рисунок 5. Отображение IEEE 802.1Q CoS.

B.2. Предпочтение при отбрасывании

Стандарт 802.1P не поддерживает предпочтений при отбрасывании, поэтому с точки зрения PW PE-bound отображения не требуется. Однако иожно пометить разные предпочтения при отбрасывании для разных кадров PW на основе политики оператора и требуемого поведения сети. Эта функциональность здесь не рассматривается.

Поддержка PSN QoS и сигнализации QoS выходят за рамки этого документа.

Адреса авторов

Luca Martini, Editor

Cisco Systems, Inc.

9155 East Nichols Avenue, Suite 400

Englewood, CO, 80112

EMail: lmartini@cisco.com

Nasser El-Aawar

Level 3 Communications, LLC.

1025 Eldorado Blvd.

Broomfield, CO, 80021

EMail: nna@level3.net

Giles Heron

Tellabs

Abbey Place

24-28 Easton Street

High Wycombe

Bucks

HP11 1NT

UK

EMail: giles.heron@tellabs.com

Eric C. Rosen

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

EMail: erosen@cisco.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждения

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).