RFC 2414 Increasing TCP’s Initial Window

Network Working Group                                          M. Allman
Request for Comments: 2414                  NASA Lewis/Sterling Software
Category: Experimental                                          S. Floyd
                                                                    LBNL
                                                            C. Partridge
                                                        BBN Technologies
                                                          September 1998

Увеличение начального окна TCP

Increasing TCP’s Initial Window

PDF

Статус документа

Этот документ описывает экспериментальный протокол (Experimental Protocol) для сообщества Internet и не задает каких-либо стандартов Internet. Документ служит приглашением к дискуссии в целях развития протокола и может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (1998). All Rights Reserved.

Тезисы

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

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

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

1. Изменение TCP

Этот документ задает возможность увеличения верхней границы размера начального окна TCP с одного сегмента до 2 — 4. В большинстве случаев это приводит к увеличению верхней границы размера начального окна приблизительно до 4 Кбайт (хотя при большом размере сегментов разрешенное начальное окно в два сегмента может быть существенно больше 4 Кбайт). Верхняя граница размера начального окна определяется уравнением (1).

          min (4*MSS, max (2*MSS, 4380 байт))               (1)

Эквивалентные уравнения для начального размера окна, основанном на максимальном размере сегмента (MSS1) приведены ниже.

        If (MSS <= 1095 байт)
            then win <= 4 * MSS;
        If (1095 bytes < MSS < 2190 байт)
            then win <= 4380;
        If (2190 bytes <= MSS)
            then win <= 2 * MSS;

Такое увеличение начального размера окна не является обязательным — TCP может начинать работу с большим размером окна, но не обязан делать это.

Эта верхняя граница начального размера окна отличается от указанной в RFC 2001 [S97], где сказано, что окно насыщения инициализируется с размеров один сегмент. Если опыт реализации этого предложения будет успешным, предполагается включить данное изменение при пересмотре RFC 2001.

Это изменение применяется к начальному окну соединения в первый период кругового обхода (RTT2) передачи, следующей за трехэтапным согласованием TCP. Ни SYN/ACK, ни его подтверждение (ACK) при трехэтапном согласовании не должны увеличивать начальный размер окна сверх значения, определяемого уравнением (1). Если пакет SYN или SYN/ACK теряется, начальное окно, используемое отправителем после корректно переданного пакета SYN должно быть размером в 1 сегмент.

Реализации TCP используют процедуру замедленного старта как минимум тремя разными способами: (1) для организации нового соединения (начальное окно), (2) для восстановления передачи после продолжительного бездействия (окно перезапуска) и (3) перезапуска после тайм-аута повтора (окно потерь). Предложенные в этом документе изменения влияют на размер начального окна. В дополнение к этому TCP может установить для окна перезапуска меньшее из значений начального окна и текущего cwnd (иными словами, использовать увеличенное окно перезапуска без увеличения размера cwnd). Предлагаемые изменений не затрагивают окна потерь, размер которого должен оставаться равным 1 сегменту (чтобы разрешить минимально возможный размер окна при сильной перегрузке).

2. Вопросы реализации

При использовании увеличенного начального окна вместе с Path MTU Discovery [MD90] и обнаружении слишком большого значения MSS, которое будет применяться, размер окна насыщения cwnd следует уменьшить для предотвращения больших всплесков сегментов малого размера. Значение cwnd следует на коэффициент, равный отношению старого размера сегмента к новомукас.

При использовании увеличенного начального окна вместе с Path MTU Discovery [MD90] возможна установка бита DF3 во всех сегментах начального окна или только в одном из сегментов. Выбор одного из этих вариантов является открытым вопросом — предполагается, что опыт реализации поможет выбрать лучший вариант. В первом случае при установки флага DF во всех сегментах все начальные пакеты слишком большого размера будут отброшены в сети. Во втором случае все слишком большие пакеты, за исключением помеченного флагом DF, будут фрагментированы в сети. Если в этом варианте флаг DF устанавливается для последнего сегмента начального окна, это обеспечивает снижение вероятности передачи ненужных повторов, когда размер начального сегмента оказывается слишком велик, поскольку минимизируется вероятность дубликатов подтверждений ACK, включающих механизм ускоренного повтора (Fast Retransmit). Однако в этом случае требуется более внимательно учитывать взаимодействие между увеличенным начальным окном и механизмом Path MTU Discovery.

Предложенное в этом документе увеличение размера начального окна не предназначено для поощрения web-браузеров к открытию множества одновременных соединений TCP с большими начальными окнами. Когда браузер открывает множество одновременных соединений TCP с одним адресатом, это работает против механизмов контроля перегрузок TCP [FF98], независимо от размера начального окна. Совмещение такого подхода с увеличением начального окна усугубляет ситуацию .

3. Преимущества большего окна

  1. Когда начальное окно имеет размер 1 сегмент, получатель, использующий отложенные подтверждения [Bra89], вынужден ждать тайм-аута прежде, чем генерировать ACK. При начальном окне в два сегмента и больше получатель будет генерировать ACK после прибытия второго сегмента данных. Это избавляет от необходимости ждать тайм-аут (зачастую до 200 мсек).

  2. Для соединений, передающих незначительный объем данных, увеличенное начальное окно уменьшает время передачи (в п редположении умеренной потери сегментов). Для многих почтовых транзакций (SMTP [Pos82]) и передачи web-страниц (HTTP [BLFN96, FJGFBL97]) объем данных составляет менее 4 Кбайт и увеличенное начальное окно будет снижать время передачи до одного периода RTT.

  3. Для соединений, которые способны использовать большое окно насыщения, предлагаемое изменение избавляет от ожидания трех интервалов RTT и тайм-аута отложенных подтверждений на начальной фазе замедленного старта (slow-start). Это преимущество особенно заметно на широкополосных каналах со значительными задержками (например, спутниковых).

4. Недостатки увеличенного окна для отдельного соединения

В средах с высоким уровнем насыщения, в частности, маршрутизаторах, предпочитающих ровный трафик сильным всплескам (типа маршрутизаторов с очередями Drop Tail4) соединения TCP иногда лучше начинать с окном размером в один сегмент. Существуют сценарии, в которых соединение TCP с замедленным стартом и начальным окном в один сегмент не будет сталкиваться с отбрасыванием сегментов, тогда как соединение TCP с начальным окном в 4 сегмента может столкнуться с неожиданными повторами передачи в результате неспособности маршрутизатора обрабатывать небольшие пики трафика. Это может приводить к неоправданным тайм-аутам повтора передачи. Для соединения с большим окном, которое может восстанавливаться без тайм-аута повтора, это будет приводить к слишком раннему переходу из фазы замедленного старта (slow-start) в фазу предотвращения перегрузки (congestion-avoidance) алгоритма управления окном. Такие преждевременные потери сегментов вряд ли будут происходить в слабо загруженных сетях с достаточной буферизацией или сетях со средним уровнем перегрузки, где перегруженные маршрутизаторы используют активное управление очередями(например, Random Early Detection [FJ93, RFC2309]).

Для некоторых соединений TCP увеличение размера начального окна будет повышать производительность даже в тех случаях, когда связанный с начальным окном пик трафика приводит к преждевременному отбрасыванию сегментов. Это верно, если (1) соединение TCP восстанавливается после потери сегмента без тайм-аута повтора и (2) соединение TCP вынуждено использовать небольшое окно насыщения по причине перегрузки сети или в соответствии с анонсированным получателем размером окна приема.

5. Недостатки увеличенного окна для сети

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

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

Дубликаты сегментов

Как описано в предыдущем параграфе, увеличение размера начального окна иногда может приводить к отбрасыванию сегмента из начального окна, если отправитель использует процедуру замедленного старта (slow-started) с начальным окном в один сегмент. Однако в Приложении A показано, что даже в таких случаях увеличение размера начального окна не приводит к росту числа передаваемых дубликатов сегментов.

Отброшенные в сети сегменты

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

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

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

Повышение уровня потерь

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

Упомянутые здесь потенциальные опасности для сети исследовались на моделях и в экспериментах, описанных ниже. Наше заключение состоит в том, что при наличии опасности коллапса перегрузки в современной сети Internet (см. [FF98], где рассматривается опасность коллапса насыщения в результате роста числа приложений UDP без сквозного контроля перегрузок),увеличение размера начального окна TCP до 4 Кбайт не создает дополнительной опасности.

6. Типичные уровни всплесков трафика для TCP

Увеличение начального окна TCP не приведет к резкому росту всплесков трафика TCP в современной сети Internet, поскольку этот трафик уже является достаточно «взрывным». Пики в 2 или 3 сегмента уже типичны для TCP [Flo97], отложенные подтверждения (покрывающие два еще не подтвержденных сегмента), полученные в период предотвращения перегрузки приводят к сдвигу окна насыщения и передаче двух сегментов. Те же самые отложенные пакеты ACK, полученные во время процедуры замедленного старта (slow start) сдвигают окно на два сегмента, увеличивая его на один сегмент, что ведет к всплеску из трех сегментов. Пики из 4 и 5 сегментов TCP не столь распространены, но достаточно часты. Для отложенных подтверждений один отброшенный пакет ACK приводит к последующему подтверждению, которое покрывает 4 еще не подтвержденных сегмента. Во время процедуры предотвращения перегрузки это вызывает передачу 4 сегментов, а во время замедленного старта — 5.

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

7. Результаты моделирования и экспериментов

7.1 Исследование соединений TCP с увеличенным начальным окном

В этом разделе рассмотрены модели и эксперименты, использованные для исследования влияния увеличенного начального окна TCP на применяющие это соединения. В первом наборе экспериментов исследовалась работа соединений через спутниковые каналы. Было показано, что увеличение начального размера окна повышает производительность соединений TCP через спутниковые каналы [All97b]. В этом исследовании начальное окно в 4 сегмента (512-байтовые MSS) приводило к росту производительности до 30% (в зависимости от суммарного объема передачи). В [KAGT98] показано, что использование увеличенного начального окна ведет к снижению времени передачи в тестах HTTP через спутниковые каналы ACTS. Исследование включало моделирование большого числа соединений HTTP на гибридных линиях HFC5, которое показало, что увеличение начального окна снижает вреся загрузки страниц WWW [Nic97].

Во второй группе экспериментов исследовалась производительность соединений TCP на модемных каналах через телефонную сеть. В экспериментах на канале 28,8 кбит/с6 [All97a, AHO98] 4-сегментное начальное окно снижало время передачи файла размером 16 Кбайт примерно на 10% без увеличения частоты отбрасывания пакетов. Особый интерес вызывали соединения TCP через низкоскоростные каналы (например, модемы на телефонных линиях) в комбинации с маршрутизаторами, имеющими малый размер буферов. В модельном исследовании [SP97] рассматривалось влияние увеличенного начального окна на хосте, подключенном через модем к маршрутизатору с буфером на 3 пакета. В этом случае увеличение размера начального окна не снижало производительности TCP. Были подняты вопросы о влиянии увеличенного начального окна на время передачи небольших объемов данных в такой среде, однако этот эффект не был определен количественно. Был также поднят вопрос влияния на другие соединения TCP через этот же канал.

7.2 Исследование сетей с увеличенным начальным окном

В этом параграфе рассматриваются модели и эксперименты по исследованию влияния увеличенного начального окна на другие соединения TCP, проходящие по тому же пути. Эксперименты [All97a, AHO98] показали, что при передаче 16-килобайтных блоков данных 100 хостам Internet 4-сегментное начальное окно приводит к незначительному росту частоты отбрасывания пакетов (0,04 сегмента на передачу). Частота потерь возрастала несущественно, а время передачи снижалось примерно на 25% для передач с использованием 4-сегментного (512-байтовый MSS) начального окна по сравнению с обычным окном в 1 сегмент.

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

В модельном исследовании [PN98] было рассмотрено влияние увеличенного начального окна на другой трафик, передаваемый в то же время. В этом исследовании потоки HTTP и FTP использовали общий загруженный шлюз (число одновременных потоков HTTP и FTP варьировалось). Для каждого набора параметров определялась агрегатная загрузка канала, частота отбрасывания пакетов, средняя задержка при загрузке web-страниц и скорость передачи FTP. Увеличение начального окна в общем случае повышало пропускную способность, незначительно увеличивало частоту потери пакетов и повышало общую производительность сети. За исключением одного сценария, увеличение размера начального окна повышало частоту потерь менее, чем на 1% по сравнению с оценкой для случая начального окна в 1 сегмент. Для упомянутого исключения частота потерь выросла от 3,5% для начального окна в 1 сегмент до 4,5% при 4-сегментном начальном окне. В результате дается заключение, что увеличение начального окна TCP до трех пакетов (или 4380 байтов) повышает воспринимаемую производительность.

Morris [Mor97] исследовал влияние увеличенного начального окна в сильно перегруженной сети, передавая блоки данных размером 20 Кбайт. Частота потерь в сетях, где все соединения TCP использовали 4-сегментное начальное окно, увеличивалась на 1-2% по сравнению с использованием начального окна в 1 сегмент. Это сохранялось для уровня загрузки, при котором частота потерь для 1-сегментного начального окна менялась от 1 до 11%. Кроме того, в сетях, где соединения использовали 4-сегментное начальное окно, соединения TCP тратили больше времени на ожидание тайм-аута повтора (RTO) для повторной передачи сегмента. Время ожидания тайм-аута RTO определяет период бездействия, когда через соединение не передается полезной информации. Эти результаты показывают, что в сильно загруженных средах, где доля каждого соединения в «узком месте» составляет около 1 сегмента, использование увеличенного начального окна может приводить к ощутимому росту частоты потерь и тайм-аутов повтора передачи.

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

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

9. Заключение

В этом документе предложено незначительное изменение протокола TCP, которое может обеспечить преимущества для краткосрочных соединений TCP, а также соединений, проходящих через каналы с большим временем кругового обхода RTT (обеспечивается экономия в несколько интервалов RTT для начальной фазы замедленного старта).

10. Благодарности

Авторы благодарны Vern Paxson, Tim Shepard, участникам почтовой рассылки End-to-End-Interest, а также членам рабочей группы IETF TCP Implementation за полезные дискуссии по затронутым в документе вопросам и отклики на этот документ.

11. Литература

[All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting — TCP Implementations WG. December, 1997. Washington, DC.

[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. Submitted to ACM Computer Communication Review. URL: «http://gigahertz.lerc.nasa.gov/~mallman/papers/initwin.ps«.

[All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master’s thesis, Ohio University, June 1997.

[BLFN96] Berners-Lee, T., Fielding, R., and H. Nielsen, «Hypertext Transfer Protocol — HTTP/1.0», RFC 1945, May 1996.

[Bra89] Braden, R., «Requirements for Internet Hosts – Communication Layers», STD 3, RFC 1122, October 1989.

[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.

[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking. URL «http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html«.

[FJGFBL97] Fielding, R., Mogul, J., Gettys, J., Frystyk, H., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2068, January 1997.

[FJ93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.

[Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.

[Flo96] Floyd, S., Issues of TCP with SACK. Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.

[Flo97] Floyd, S., Increasing TCP’s Initial Window. Viewgraphs, 40th IETF Meeting — TCP Implementations WG. December, 1997. URL «ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps«.

[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems. URL «http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps«.

[MD90] Mogul, J., and S. Deering, «Path MTU Discovery», RFC 1191, November 1990.

[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018, October 1996.

[Mor97] Robert Morris. Частное сообщение, 1997. Указано лишь для подтверждения и благодарности.

[Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Com21, Inc. Technical Report. Available from http://www.com21.com/pages/papers/068.pdf.

[PN98] Poduri, K., and K. Nichols, «Simulation Studies of Increased Initial TCP Window Size», RFC 2415, September 1998.

[Pos82] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 8217, August 1982.

[RF97] Ramakrishnan, K., and S. Floyd, «A Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP», Work in Progress8.

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

[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, «Recommendations on Queue Management and Congestion Avoidance in the Internet», RFC 2309, April 1998.

[S97] Stevens, W., «TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms», RFC 2001, January 1997.

[SP97] Shepard, T., and C. Partridge, «When TCP Starts Up With Four Packets Into Only Three Buffers», RFC 2416, September 1998.

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

Mark Allman

NASA Lewis Research Center/Sterling Software

21000 Brookpark Road

MS 54-2

Cleveland, OH 44135

EMail: mallman@lerc.nasa.gov

http://gigahertz.lerc.nasa.gov/~mallman/

Sally Floyd

Lawrence Berkeley National Laboratory

One Cyclotron Road

Berkeley, CA 94720

EMail: floyd@ee.lbl.gov

Craig Partridge

BBN Technologies

10 Moulton Street

Cambridge, MA 02138

EMail: craig@bbn.com


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

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

nmalykh@gmail.com

13. Приложение — дубликаты сегментов

В современной среде (без явных уведомлений о перегрузке ECN9 [Flo94] [RF97]) все реализации TCP применяют отбрасывание сегментов в качестве индикации выхода за пределы доступной пропускной способности. Мы утверждаем здесь, что увеличение размера начального окна не приведет к большому числу дубликатов, уже принятых получателем, среди передаваемых отправителем повторных сегментов.

При отбрасывании сегмента из начального окна есть три способа восстановления для TCP: (1) замедленный старт с окном в один сегмент как после тайм-аута повторной передачи или ускоренного повтора (Fast Retransmit) в Tahoe TCP, (2) ускоренное восстановление (Fast Recovery) без селективных подтверждений (SACK) как после трех дубликатов ACK в Reno TCP и (3) ускоренное восстановление с SACK для TCP, где отправитель и получатель поддерживают опцию SACK [MMFR96]. Во всех трех случаях при отбрасывании одного сегмента из начального окна дубликаты сегментов (т. е., сегменты уже принятые получателем) не передаются. Отметим, что для TCP, передающего четыре сегмента по 512 байтов в начальном окне отбрасывание одного сегмента не требует тайм-аута повторной передачи и восстановление возможно с использованием алгоритма ускоренного повтора (Fast Retransmit), если таймер повтора передачи не завершил отсчет до этого. При отбрасывании одного сегмента из трехсегментного начального окна возможно восстановление с использованием алгоритма ускоренного повтора в зависимости от того, какой из сегментов был отброшен и использования отложенных подтверждений. Например, при отбрасывании первого из трех сегментов начального окна всегда требуется ожидание тайм-аута. Однако при отбрасывании третьего сегмента всегда возможно восстановление с помощью алгоритма ускоренного повтора, если не было потери пакетов ACK.

Далее рассмотрим сценарии с начальным окном 2 — 4 сегмента и отбрасыванием по крайней мере двух из этих сегментов. Если отбрасываются все сегменты начального окна, очевидно, что дубликатов сегментов не передается, поскольку получатель не принял еще ни одного сегмента. (По-прежнему сохраняется вероятность того, что эти отброшенные сегменты использовали дефицитную пропускную способность — этот вопрос рассмотрен в разделе 5.)

Когда отбрасывается 2 сегмента из 3-сегментного начального окна, отправитель будет передавать дубликат лишь в том случае, если отброшены два первых сегмента из трех и отправитель не получил пакета с опцией SACK, подтверждающего прием третьего сегмента.

Когда отбрасывается 2 сегмента из 4-сегментного начального окна, проверка шести возможных вариантов (которую мы здесь не делаем) показывает, что в зависимости от номеров отброшенных сегментов при отсутствии SACK отправитель может передать один дубликат уже принятого сегмента. Вариантов с передачей двух дубликатов не возникает.

При отбрасывании 3 сегментов из 4-сегментного начального окна в отсутствие SACK возможна передача одного сегмента-дубликата в зависимости от номеров отброшенных сегментов.

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

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1The maximum segment size.

2Round trip time.

3Don’t Fragment — не фрагментировать.

4«Отрубание хвостов».

5Hybrid fiber coax — сеть на основе оптических и коаксиальных линий связи.

6В оригинале ошибочно указано бит/с.

7Этот документ признан устаревшим и заменен RFC 2821, а затем RFC 5321. Прим. перев.

8Работа была опубликована в RFC 2481, который был позже заменен RFC 3168. Прим. перев.

9Explicit Congestion Notification.




RFC 2427 Multiprotocol Interconnect over Frame Relay

Network Working Group                                       C. Brown
Request for Comments: 2427                                Consultant
STD: 55                                                     A. Malis
Obsoletes: 1490, 1294                    Ascend Communications, Inc.
Category: Standards Track                             September 1998

Многопротокольные соединения через Frame Relay

Multiprotocol Interconnect over Frame Relay

PDF

Статус документа

Этот документ содержит спецификации стандарта Internet для сообщества Internet и приглашает к обсуждению вопроса для дальнейшего развития стандарта. Статус документа вы можете найти в текущей редакции Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (1998). All Rights Reserved.

Тезисы

В этом документе описаны методы инкапсуляции для передачи межсетевого трафика через магистрали Frame Relay. В документе рассмотрены вопросы маршрутизации и организации мостов (Bridging).

Системы, способные поддерживать оба описанных pltcm метода инкапсуляции, а также иные методы, должны знать a-priori для каких виртуальных устройств используется тот или иной метод инкапсуляции. Инкапсуляция определенного типа может использоваться только для тех виртуальных устройств, которые настроены на такое использование.

Благодарности

Этот документ не был бы завершен без поддержки Terry Bradley из компании Avici Systems, Inc.. В документе содержатся результаты работы множества людей. Особо отметим вклад Ray Samora (Proteon), Ken Rehbehn (Visual Networks), Fred Baker и Charles Carvalho (Cisco Systems), Mostafa Sherif (AT&T). Отдельная благодарность выражается Dory Leifer (University of Michigan) за вклад в рассмотрение вопросов фрагментации (несмотря на то, что этот раздел был удален из окончательной версии документа), а также Floyd Backes и Laura Bridge (3Com) за их вклад в рассмотрение вопросов, связанных с мостами. Документ никогда бы не удалось завершить без использования опыта рабочих групп IETF «IP over Large Public Data Networks» и «IP over NBMA».

1. Терминология и сокращения

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

На схемах в документе биты выводятся слева направо по старшинству (младший бит слева)

  0   1   2   3   4   5   6 7 биты октета
+---+---+---+---+---+---+---+

+---------------------------+
|Флаг (7E шестнадцатеричное)|
+---------------------------+
|       Адрес Q.922         |
+--                       --+
|                           |
+---------------------------+
:                           :
:                           :
+---------------------------+

Для больших диаграмм в одной строке может размещаться изображение двух октетов. На некоторых рисунках старший бит показан слева (такие случаи указаны явно).

|---   октет 1       ---|---   октет 2    ---|
0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 

+--------------------------------------------+
| Уникальный идентификатор                   |
+--                     +--------------------+
| организации           | Идентификатор      |
+-----------------------+--------------------+
| протокола             |
+-----------------------+

Ниже приведен список основных сокращений, использованных в документе.

BECN Backward Explicit Congestion Notification — обратное уведомление о насыщении

BPDU Bridge Protocol Data Unit — единица данных протокола моста

C/R Command/Response bit — бит команда/отклик

DCE Data Communication Equipment — коммуникационное оборудование

DE Discard Eligibility bit — бит возможности отбрасывания

DTE Data Terminal Equipment — терминальное оборудование

FECN Forward Explicit Congestion Notification — прямое уведомление о насыщении

PDU Protocol Data Unit — единица данных протокола

PTT Postal Telephone & Telegraph (название компании)

SNAP Subnetwork Access Protocol — протокол доступа в подсеть.

2. Введение

Рассмотренные ниже вопросы относятся к устройствам, функционирующим в качестве конечных станций (end station, DTE) частных или публичных сетей Frame Relay. Поведение станций, являющихся частью сети Frame Relay (DCE), рассматриваться не будет, за исключением тех случаев, в которых от этого поведения зависит реакция устройств DTE.

Сеть Frame обеспечивает множество виртуальных устройств (virtual circuit), создающих основу для организации соединений между станциями, подключенными к одной сети Frame Relay. Набор соединенных между собой устройств формирует частную группу Frame Relay, члены которой могут быть соединены со всеми остальными (многосвязная сеть с использованием всех возможных соединений) или только с частью других станций. В любом случае каждое виртуальное устройство уникально идентифицируется на каждом интерфейсе Frame Relay с помощью DLCI (Data Link Connection Identifier — идентификатор соединения на канальном уровне). В большинстве случаев значения DLCI имеют локальную значимость в масштабах каждого интерфейса Frame Relay.

Рассматриваемые в этом документе спецификации применимы как к коммутируемым (switched), так и к постоянным (permanent) виртуальным устройствам.

3. Формат кадров

Все протоколы должны инкапсулировать свои пакеты в кадры Q.922 Annex A [1]. Кроме того, рекомендуется включать в кадры информацию, позволяющую идентифицировать протокол, передаваемый в PDU — это дает возможность приемнику корректно обрабатывать входящие пакеты. Формат пакетов показан ниже:

+---------------------------+
|Флаг (7E шестнадцатеричн.) |
+---------------------------+
| Адрес Q.922               |
+--                       --+
|                           |
+---------------------------+
| Control (UI = 0x03)       |
+---------------------------+
|Заполнение - необяз.(0x00) |
+---------------------------+
| NLPID                     |
+---------------------------+
| .                         |
| .                         |
| .                         |
| Данные                    |
| .                         |
| .                         |
+---------------------------+
| Контрольная сумма FCS     |
+--          .            --+
| (2 октета)                |
+---------------------------+
|Флаг (7E шестнадцатеричн.) |
+---------------------------+

Адреса Q.922 в соответствии с действующим стандартом являются 2-октетными и содержат 10-битовые идентификаторы DLCI. В некоторых сетях адреса Q.922 могут быть увеличены до 3 или 4 октетов.

Поле Control представляет собой поле управления Q.922. Если явно не оговорено иное, в качестве значения этого пол используется UI (0x03). Допустимо использование значения XID (0xAF или 0xBF), рассмотренного ниже.

Необязательное поле pad используется для выравнивания оставшейся части кадра по 2-октетной границе. Поле pad может содержать один или два октета; значение октетов заполнения должно быть нулевым. Далее будут приведены явные рекомендации по использованию пол заполнения.

Значения пол идентификатора протокола сетевого уровня NLPID (Network Level Protocol ID) распределяются ISO и ITU. Предусмотрены идентификаторы для множества распространенных протоколов, включая IP, CLNP и IEEE Subnetwork Access Protocol (SNAP) [10]. Это поле говорит принимающему устройству об используемом методе инкапсуляции и передаваемом протоколе. Возможные значения пол определены стандартом ISO/IEC TR 9577 [3]. Значение NLPID=0x00 определено в ISO/IEC TR 9577 как Null Network Layer или Inactive Set. Поскольку это значение невозможно отличить от заполнения, а в данной схеме инкапсуляции это значение просто не имеет смысла, при рассмотрении инкапсуляции Frame Relay значение NLPID=0x00 считается некорректным. В приложении A содержится список наиболее распространенных значений NLPID.

Для сетей Frame Relay не существует общепринятого нижнего порога для максимального размера кадров. Реальные сети, однако, должны поддерживать кадры размером, по крайней мере, 262 октета. В общем случае максимальный размер кадра больше или равен 1600 октетов, но каждый оператор Frame Relay может выбрать для своей сети наиболее подходящее значение. Устройства DTE в сетях Frame Relay, следовательно, должны обеспечивать возможность настройки значений максимального размера кадров.

Минимальный размер кадров Frame Relay требует наличия не менее 5 октетов между стартовым и закрывающим флагами с учетом 2-октетного поля адреса Q.922. Это значение возрастает до 6 октетов для 3-октетного адреса Q.922 и до 7 октетов в случае использования 4-октетного формата для адресов Q.922.

4. Межсетевые соединения

Существует два основных типа пакетов, передаваемых через сети Frame Relay — маршрутизируемые пакеты и пакеты, передаваемые с использованием мостов (bridged). Для этих пакетов используются различные форматы и, следовательно, должен обеспечиваться способ идентификации, позволяющий получателю корректно интерпретировать содержимое кадра. Индикатор типа помещается в поле NLPID и заголовок SNAP.

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

Заголовок SNAP имеет форму:

+--------------------------------------------+
| Уникальный идентификатор                   |
+--                     +--------------------+
| организации           | Идентификатор      |
+-----------------------+--------------------+
| протокола             |
+-----------------------+

Трехоктетное поле OUI (Organizationally Unique Identifier) указывает организацию, ответственную за администрирование последующего идентификатора протокола (PID). Значения OUI и PID совместно позволяют однозначно идентифицировать протокол. Отметим, что значение OUI=0x00-00-00 указывает, что поле PID имеет значение Ethertype.

4.1. Маршрутизируемые кадры

С некоторыми протоколами связаны значения NLPID, но ограниченность пространства номеров NLPID не позволяет выделить такие идентификаторы для всех протоколов. Когда пакеты протоколов, не имеющих идентификатора, маршрутизируются через сети Frame Relay, для таких пакетов используется значение NLPID=0x80 (оно говорит о наличии SNAP), за которым следует заголовок SNAP. Если для протокола выделено значение Ethertype, поле OUI имеет значение 0x00-00-00 (это значение говорит о наличии поля Ethertype) и поле PID принимает значение Ethertype для используемого протокола.

При наличии упомянутого выше заголовка SNAP используется один октет заполнения для выравнивания протокольных данных по 2-октетной границе, как показано ниже

Формат маршрутизируемых кадров с заголовком SNAP

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | pad 0x00      |
+---------------+---------------+
| NLPID 0x80    | OUI           |
+---------------+             --+
| OUI                           |
+-------------------------------+
| Идентификатор протокола (PID) |
+-------------------------------+
|                               |
| Протокольные данные           |
|                               |
+-------------------------------+
| FCS                           |
+-------------------------------+

В тех случаях, когда протокол имеет идентификатор NLPID (см. Приложение A), можно сократить заголовок на 48 битов за счет использования показанного ниже формата:

Формат маршрутизируемых кадров при наличии NLPID для протокола

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | NLPID         |
+---------------+---------------+
| Протокольные данные           |
+-------------------------------+
| FCS                           |
+-------------------------------+

Инкапсуляция NLPID не требует использовать заполнение, поэтому данное поле отсутствует в заголовке.

Для некоторых протоколов ISO значение NLPID рассматривается как первый октет данных протокола. В таких случаях нет необходимости дублировать поле NLPID. Один октет используется для демультиплексирования и в качестве данных протокола (см. параграф «Инкапсуляция других протоколов»). Другие протоколы (такие, как IP) имеют значение NLPID (для IP — 0xCC), но это значение не является частью протокольных данных.

Формат маршрутизируемой дейтаграммы IP

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | NLPID 0xCC    |
+---------------+---------------+
| Дейтаграмма IP                |
+-------------------------------+
| FCS                           |
+-------------------------------+

4.2. Кадры, передаваемые через мосты

Вторым типом трафика Frame Relay являются пакеты, передаваемые с использованием мостов (bridged packet). Такие пакеты инкапсулируются с использованием NLPID=0x80 (указывает наличие SNAP). Как и с другими протоколами, использующими SNAP-инкапсулцию, может добавляться один октет заполнения для выравнивания границы данных инкапсулированного кадра. Заголовок SNAP, который следует после NLPID, идентифицирует формат пакета, передаваемого с использованием мостов. Значение OUI, используемое для такой инкапсуляции, является кодом комитета IEEE 802.1 и имеет значение 0x00-80-C2. PID-часть заголовка SNAP (два байта вслед за OUI) указывает формат заголовка MAC, который следует сразу после заголовка SNAP. Кроме того, PID показывает наличие исходной контрольной суммы FCS в bridged-кадре.

Следуя практике RFC 1638 [4], будем использовать неканонические MAC-адреса получателей для инкапсуляции кадров IEEE 802.5 и FDDI; канонические MAC-адреса получателей будут использоваться для инкапсуляции иных кадров, рассматриваемых в данном параграфе.

Значения PID для OUI 0x00-80-C2

Среда

С сохранением FCS

Без сохранения FCS

0x00-01

0x00-07

802.3/Ethernet

0x00-02

0x00-08

802.4

0x00-03

0x00-09

802.5

0x00-04

0x00-0A

FDDI

0x00-0B

802.6

Комитет IEEE 802.1 зарезервировал для использования с Frame Relay следующие значения:

Кроме того, PID=0x00-0E при OUI=0x00-80-C2 указывает на модуль данных BPDU (Bridge Protocol Data Unit), как определено в стандарте 802.1d или 802.1g [12], а значение PID=0x00-0F идентифицирует Source Routing BPDU.

Пакеты, передаваемые с использованием мостов через сеть Frame Relay, будут, следовательно, иметь один из следующих форматов:

Формат кадров Bridged Ethernet/802.3

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | pad 0x00      |
+---------------+---------------+
| NLPID 0x80    | OUI 0x00      |
+---------------+             --+
| OUI 0x80-C2                   |
+-------------------------------+
| PID 0x00-01 или 0x00-07       |
+-------------------------------+
| MAC-адрес получателя          |
:                               :
|                               |
+-------------------------------+
| (остаток кадра MAC)           |
+-------------------------------+
| LAN FCS (если PID=0x00-01)    |
+-------------------------------+
| FCS                           |
+-------------------------------+

Формат кадров Bridged 802.4

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | pad 0x00      |
+---------------+---------------+
| NLPID 0x80    | OUI 0x00      |
+---------------+             --+
| OUI 0x80-C2                   |
+-------------------------------+
| PID 0x00-02 или 0x00-08       |
+---------------+---------------+
| pad 0x00      | Frame Control |
+---------------+---------------+
| MAC-адрес получателя          |
:                               :
|                               |
+-------------------------------+
| (остаток кадра MAC)           |
+-------------------------------+
| LAN FCS (если PID=0x00-02)    |
+-------------------------------+
| FCS                           |
+-------------------------------+

Формат кадров Bridged 802.5

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | pad 0x00      |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00         |
+---------------+             --+
| OUI 0x80-C2                   |
+-------------------------------+
| PID 0x00-03 или 0x00-09       |
+---------------+---------------+
| pad 0x00      | Frame Control |
+---------------+---------------+
| MAC-адрес получателя          |
:                               :
|                               |
+-------------------------------+
| (остаток кадра MAC)           |
+-------------------------------+
| LAN FCS (если PID=0x00-03)    |
|                               |
+-------------------------------+
| FCS                           |
+-------------------------------+

Формат кадров Bridged FDDI

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | pad 0x00      |
+---------------+---------------+
| NLPID 0x80    | OUI 0x00      |
+---------------+             --+
| OUI 0x80-C2                   |
+-------------------------------+
| PID 0x00-04 или 0x00-0A       |
+---------------+---------------+
| pad 0x00      | Frame Control |
+---------------+---------------+
| MAC-адрес получателя          |
:                               :
|                               |
+-------------------------------+
| (остаток кадра MAC)           |
+-------------------------------+
| LAN FCS (если PID=0x00-04)    |
|                               |
+-------------------------------+
| FCS                           |
+-------------------------------+

Формат кадров Bridged 802.6

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
| Control 0x03  | pad 0x00      |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00         |
+---------------+             --+
| OUI 0x80-C2                   |
+-------------------------------+
| PID 0x00-0B                   |
+---------------+---------------+ -------
| Резерв        | BEtag         |Заголовок
+---------------+---------------+Common
| BAsize                        |PDU
+-------------------------------+ -------
| MAC-адрес получателя          |
:                               :
+-------------------------------+
| (остаток кадра MAC)           |
+-------------------------------+
|                               |
+-     Трейлер Common PDU      -+
|                               |
+-------------------------------+
| FCS                           |
+-------------------------------+

Отметим, что для PDU мостов 802.6 возможно только одно значение PID, поскольку наличие контрольной суммы CRC-32 указывается битом CIB в заголовке кадра MAC.

Заголовок и трейлер общего модуля данных протокола CPDU (Common Protocol Data Unit) перемещаются для того, чтобы разрешить конвейерную обработку на выходном мосту в подсеть 802.6. В частности, заголовок CPDU содержит поле BAsize, указывающее длину PDU. Если это поле недоступно для выходного моста 802.6, этот мост не сможет начать передачу сегментированного PDU до тех пор, пока не будет получен PDU целиком, рассчитан размер и значение размера помещено в поле BAsize. Если это поле доступно, выходной мост 802.6 может определить размер по значению поля BAsize в заголовке Common PDU, вставить это значение в соответствующее поле первого сегмента и незамедлительно передать пакет в подсеть 802.6. Таким образом, мост может начать передачу 802.6 PDU до того, как PDU будет принят полностью.

Однако, следует отметить, что заголовок и трейлер Common PDU инкапсулированного кадра не должны просто копироваться в адресуемую подсеть 802.6, поскольку инкапсулированное значение BEtag может конфликтовать с предыдущим значением BEtag, переданным этим мостом.

Формат кадров BPDU

+-------------------------------+
| Адрес Q.922                   |
+-------------------------------+
| Control 0x03                  |
+-------------------------------+
| PAD 0x00                      |
+-------------------------------+
| NLPID 0x80                    |
+-------------------------------+
| OUI 0x00-80-C2                |
+-------------------------------+
| PID 0x00-0E                   |
+-------------------------------+
|                               |
| BPDU в соответствии с         |
| 802.1d или 802.1g[12]         |
|                               |
+-------------------------------+
| FCS                           |
+-------------------------------+

Формат кадров Source Routing BPDU

+-------------------------------+
| Адрес Q.922                   |
+-------------------------------+
| Control 0x03                  |
+-------------------------------+
| PAD 0x00                      |
+-------------------------------+
| NLPID 0x80                    |
+-------------------------------+
| OUI 0x00-80-C2                |
+-------------------------------+
| PID 0x00-0F                   |
+-------------------------------+
|                               |
| Source Routing BPDU           |
|                               |
|                               |
+-------------------------------+
| FCS                           |
+-------------------------------+

5. Согласование параметров канального уровня

Станции Frame Relay могут по своему выбору поддерживать идентификаторы обмена XID (Exchange Identification), определенные в приложении Appendix III к стандарту Q.922 [1]. Обмен идентификаторами XID позволяет согласовать ряд параметров при инициализации устройства (виртуального соединения) Frame Relay — максимальный размер кадра N201, таймер повторной передачи T200 и максимальное число отложенных информационных (I) кадров K (окно).

Станция может обозначить свое нежелание поддерживать режим мультикадрового окна с подтверждением, установив нулевое значение для максимального размера окна K.

Если такой обмен не используется, перечисленные параметры должны быть заданы статически при настройке для станции параметров соединения на канальном уровне DLC (Data Link Connection) или следует использовать принятые по умолчанию значения в соответствии с разделом 5.9 спецификации Q.922:

N201: 260 октетов
K:    3 для каналов 16 кбит/с,
      7 для каналов 64 кбит/с,
      32 для каналов 384 кбит/с,
      40 для каналов 1.536 и более кбит/с
T200: 1.5 сек [см. Q.922]

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

На рисунке показан процесс использования XID для отказа от использования мультикадрового окна с подтверждением.

Отказ от использования мультикадрового окна

+---------------+
| Адрес         | (2,3 или 4 октета)
|               |
+---------------+
| Control 0xAF  |
+---------------+
| Формат 0x82   |
+---------------+
| Group ID 0x80 |
+---------------+
| Group Length  | (2 октета)
| 0x00-0E       |
+---------------+
| 0x05          | PI = Размер кадра (передача)
+---------------+
| 0x02          | PL = 2
+---------------+
| Максимальный  | (2 октета)
| размер кадра  |
+---------------+
| 0x06          | PI = Размер кадра (прием)
+---------------+
| 0x02          | PL = 2
+---------------+
| Максимальный  | (2 октета)
| размер кадра  |
+---------------+
| 0x07          | PI = Размер окна
+---------------+
| 0x01          | PL = 1
+---------------+
| 0x00          |
+---------------+
| 0x09          | PI = Таймер повторной передачи
+---------------+
| 0x01          | PL = 1
+---------------+
| 0x00          |
+---------------+
| FCS           | (2 октета)
|               |
+---------------+

6. Преобразование адресов для PVC

В данном документе вопросы преобразования адресов рассматриваются только для постоянных соединений PVC. Работа с коммутируемыми соединениями SVC будет рассмотрена в других документах.

В некоторых ситуациях станциям Frame Relay может потребоваться динамическое преобразование протокольных адресов. Преобразование адресов может быть выполнено с помощью стандартного протокола ARP (Address Resolution Protocol) [6], инкапсулированного в пакетах Frame Relay со SNAP-кодированием:

+-----------------------+-----------------------+
| Адрес Q.922                                   |
+-----------------------+-----------------------+
| Control (UI) 0x03     | pad 0x00              |
+-----------------------+-----------------------+
| NLPID = 0x80          |                       | Заголовок SNAP
+-----------------------+ OUI = 0x00-00-00      + показывающий
|                                               | ARP
+-----------------------+-----------------------+
| PID 0x0806                                    |
+-----------------------+-----------------------+
| Пакет ARP                                     |
| .                                             |
| .                                             |
| .                                             |
+-----------------------+-----------------------+

Пакет ARP использует следующие форматы и значения:

Данные:

ar$hrd 16 битов тип оборудования (Hardware type)

ar$pro 16 битов тип протокола (Protocol type)

ar$hln 8 битов размер аппаратного адреса в октетах (n)

ar$pln 8 битов размер протокольного адреса в октетах (m)

ar$op 16 битов код операции (запрос или отклик)

ar$sha n октетов аппаратный адрес отправителя

ar$spa m октетов протокольный адрес отправителя

ar$tha n октетов аппаратный адрес получателя

ar$tpa m октетов протокольный адрес получателя

ar$hrd — для Frame Relay используется десятичное значение 15 (0x000F) [7].

ar$pro — см. номер протокола ID для использования ARP (0x0800).

ar$hln — размер адресного поля в байтах (2, 3 или 4)

ar$pln — размер протокольного адреса зависит от протокола (ar$pro); для IP ar$pln=4.

ar$op — 1 для запросов, 2 для откликов.

ar$sha — аппаратный адрес Q.922 для отправителя с C/R, FECN, BECN и DE, равными 0.

ar$tha — аппаратный адрес Q.922 для получателя с C/R, FECN, BECN и DE, равными 0.

Поскольку идентификаторы DLCI в большинстве сетей Frame Relay имеют лишь локальное значение, конечные станции не имеют в результате собственных (уникальных) идентификаторов DLCI. Следовательно, такие станции не имеют адреса, который можно было бы включить в запрос или отклик ARP. К счастью, в сетях Frame Relay существует способ получения корректных значений DLCI. Предложенное ниже решение для сетей Frame Relay с локальной адресацией будет также хорошо работать в сетях, где идентификаторы DLCI имеют глобальную значимость.

Значения DLCI, содержащиеся в заголовках Frame Relay, изменяются при передаче кадров через сеть. Когда пакет приходит к получателю, идентификатор DLCI может не совпадать со значением, установленным передавшей пакет станцией. Например, когда станция A (рисунок 1) передает сообщение станции B, она будет устанавливать в заголовке Frame Relay значение DLCI=50. Когда станция B получит это сообщение, значение DLCI будет изменено сетью (в приведенном примере DLCI=70).

                   ~~~~~~~~~~~~~~~
                  (                )
+-----+          (                  )             +-----+
|     |-50------(--------------------)---------70-|     |
|  A  |        (                      )           |  B  |
|     |-60-----(---------+            )           |     |
+-----+         (        |           )            +-----+
                 (       |          )
                  (      |         ) <--- сеть Frame Relay
                   ~~~~~~~~~~~~~~~~
                         80
                         |
                      +-----+
                      |     |
                      |  C  |
                      |     |
                      +-----+

Рисунок 1

Линии на рисунке 1 представляют виртуальные соединения (DLC), числа показывают локальные идентификаторы DLCI для каждого соединения.

Преобразование DLCI в адреса Q.922 для рисунка 1

DLCI (дес.)   адрес Q.922 (шестн.)
50            0x0C21
60            0x0CC1
70            0x1061
80            0x1401

Официальные сведения о соотношениях между DLCI и адресами Q.922 следует искать в спецификации Q.922 [1]. Здесь мы лишь напомним о том, что преобразование между DLCI и адресами Q.922 основано на 2-байтовой длине адреса с использованием формата кодирования Q.922, показанного ниже.

  8   7   6   5   4   3   2   1
+------------------------+---+--+
| DLCI (старшие биты)    |c/r|ea|
+--------------+----+----+---+--+
| DLCI (младш.)|FECN|BECN|DE |EA|
+--------------+----+----+---+--+

Для ARP и вариантов этого протокола значения битовых полей FECN, BECN, C/R и DE предполагаются нулевыми.

Когда сообщение ARP приходит к адресату, все аппаратные адреса в нем являются некорректными. Однако, адреса, определенные из заголовков кадров, остаются верными. Хотя это и нарушает чистоту деления по уровням, Frame Relay может использовать адреса из заголовков в качестве аппаратных адресов отправителей. Следует отметить, что аппаратные адреса получателей в запросах и откликах ARP также являются некорректными. Это не должно вызывать сложностей, поскольку ARP не использует эти поля и, фактически, для них можно задавать нулевые значения или просто игнорировать.

В качестве примера работы схемы замены адресов снова рассмотрим рисунок 1. Если станция A (протокольный адрес pA) хочет преобразовать адрес станции B (протокольный адрес pB), она должна сформировать запрос ARP со следующими значениями:

Запрос ARP от станции A

ar$op  1 (запрос)
ar$sha неизвестен
ar$spa pA
ar$tha не определен
ar$tpa pB

Поскольку станция A не имеет связанного с ней адреса отправителя, поле аппаратного адреса отправителя является некорректным. Следовательно, при получении запроса ARP корректный аппаратный адрес должен быть определен из заголовка Frame Relay и помещен в поле аппаратного адреса отправителя. В результате этого запрос ARP принимает форму:

Запрос ARP от станции A после изменения станцией B

ar$op  1 (запрос)
ar$sha 0x1061 (DLCI 70) иззаголовка Frame Relay
ar$spa pA
ar$tha не определен
ar$tpa pB

Протокол ARP на станции B может сейчас корректно сохранить протокольный адрес станции A и ее адрес Q.922 в таблице ARP. После этого станция B будет формировать отклик. Многие разработчики просто помещают адрес отправителя из запроса ARP в поле адреса получателя, а в поле адреса отправителя указывают свой адрес. В этом случае отклик ARP будет иметь вид:

Отклик ARP от станции B

ar$op  2 (отклик)
ar$sha неизвестен
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA

Аппаратный адрес отправителя по-прежнему остается неизвестным и при получении отклика станция A должна получить адрес из заголовка Frame Relay и поместить его в поле аппаратного адреса отправителя. После этой операции отклик имеет форму:

Отклик ARP от станции B после изменения его станцией A

ar$op  2 (отклик)
ar$sha 0x0C21 (DLCI 50)
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA

Станция A сейчас может корректно распознавать станцию B по ее протокольному адресу pB, связанному с адресом Q.922 — 0x0C21 (DLCI 50).

Обратное преобразование адресов (RARP) [8] будет выполняться по аналогии с прямым. Возвращаясь к рисунку 1, предположим, что станция C является сервером адресов. В этом случае произойдет следующий обмен пакетами RARP:

RARP-запрос от A         Запрос RARP после изменения станцией C
ar$op 3 (RARP-запрос)    ar$op 3 (RARP-запрос)
ar$sha неизвестен        ar$sha 0x1401 (DLCI 80)
ar$spa не определен      ar$spa не определен
ar$tha 0x0CC1 (DLCI 60)  ar$tha 0x0CC1 (DLCI 60)
ar$tpa pC                ar$tpa pC

Станция C будет искать протокольный адрес, соответствующий адресу Q.922 0x1401 (DLCI 80), и передавать отклик RARP.

RARP-отклик от C         Отклик RARP после изменения станцией A
ar$op 4 (отклик RARP)    ar$op 4 (отклик RARP)
ar$sha неизвестен        ar$sha 0x0CC1 (DLCI 60)
ar$spa pC                ar$spa pC
ar$tha 0x1401 (DLCI 80)  ar$tha 0x1401 (DLCI 80)
ar$tpa pA                ar$tpa pA

Это означает, что интерфейс Frame Relay должен включаться только в обработку входящих пакетов.

При отсутствии подходящего механизма групповой адресации (multicast) процедуру ARP все равно можно реализовать. Для решения этой задачи конечная станция просто должна передать копию запроса ARP с использованием всех имеющих отношение к делу DLC (это имитирует широковещательную рассылку).

Вопрос использования групповых адресов в среде Frame Relay, как указано в работе [19], рассматривается операторами Frame Relay. Отметим, что групповая адресация может оказаться полезной для передачи запросов ARP и других «широковещательных» сообщений.

По причине неэффективности эмуляции широковещания в среде Frame Relay, был разработан новый вариант преобразования адресов. Этот метод получил название Inverse ARP [11] (инверсное преобразование) и основан на определении протокольного адреса при известном аппаратном адресе. Для случая Frame Relay известным аппаратным адресом является идентификатор DLCI. Поддержка Inverse ARP не требуется для реализации данной спецификации, но она может оказаться весьма полезной для автоматической настройки конфигурационных параметров интерфейсов Frame Relay. Описание и примеры использования Inverse ARP для сетей Frame Relay приводятся в работе [11]

Станции должны быть способны отобразить несколько адресов IP из одной IP-подсети (префикс адреса CIDR) на один идентификатор DLCI интерфейса Frame Relay. Это требование порождается приложениями (типа систем удаленного доступа), в которых серверы должны функционировать как ARP-прокси для множества удаленных (dial-in) клиентов, каждый из которых использует собственный адрес IP при работе через одно соединение DLC. Динамическая природа таких приложений приводит к частым сменам адресных ассоциаций, которые не должны влиять на состояние DLC, сообщаемое системой сигнализации Frame Relay PVC Status Signaling.

Как и другие интерфейсы, использующие протокол ARP, станции могут обучаться, определяя ассоциации между IP-адресами и DLCI путем обработки запросовARP, поступающих в соединение DLC. Если одна станция (возможно, терминальный сервер или сервер удаленного доступа) хочет проинформировать станцию того же уровня (peer) на другой стороне Frame Relay DLC о новой связи между адресом IP и постоянным соединением PVC, такая станция должна передать по своей инициативе запрос ARP с IP-адресом отправителя, который совпадает с IP-адресом получателя, после чего обе станции будут знать о том, что в данном DLC используется новый IP-адрес. Это позволяет станции «анонсировать» новое клиентское подключение для отдельного DLCI. Принимающая станция должна сохранить новую ассоциацию и удалить (при необходимости) ассоциации для этого адреса с любыми другими DLCI на данном интерфейсе.

7. Передача IP через Frame Relay

Дейтаграммы IP [9] (IP) передаются через сеть Frame Relay с использованием описанной выше инкапсуляции. В этом контексте может использоваться два варианта инкапсуляции IP.

1. Значение NLPID указывает на IP

+-----------------------+-----------------------+
| Адрес Q.922                                   |
+-----------------------+-----------------------+
| Control (UI) 0x03     | NLPID = 0xCC          |
+-----------------------+-----------------------+
| IP-пакет              .                       |
|                       .                       |
|                       .                       |
+-----------------------+-----------------------+

2. Значение NLPID указывает на SNAP

+-----------------------+-----------------------+
| Адрес Q.922                                   |
+-----------------------+-----------------------+
| Control (UI) 0x03     | pad 0x00              |
+-----------------------+-----------------------+
| NLPID = 0x80          |                       | Заголовок SNAP,
+-----------------------+ OUI = 0x00-00-00      + указывающий
|                                               | IP
+-----------------------+-----------------------+
| PID = 0x0800                                  |
+-----------------------+-----------------------+
| IP-пакет                                      |
| .                                             |
| .                                             |
+-----------------------+-----------------------+

Хотя оба варианта поддерживаются описанной схемой инкапсуляции, лучше выбрать для инкапсуляции данных IP единственный метод. Следовательно, данные IP должны инкапсулироваться с использованием значения NLPID=0xCC, указывающего протокол IP (вариант 1). Этот вариант инкапсуляции обеспечивает большую эффективность (заголовок уменьшается на 48 битов) и согласуется с инкапсуляцией IP в сетях X.25.

8. Передача других протоколов через Frame Relay

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

В качестве примера рассмотрим протокол ISO CLNP, для которого определено NLPID=0x81.

Следовательно, поле NLPID будет указывать на протокол ISO CLNP и данные из пакета могут помещаться вслед за NLPID. Кадр будет иметь следующий формат:

+---------------------------------------------+
| Адрес Q.922                                 |
+----------------------+----------------------+
| Control (0x03)       | NLPID - 0x81 (CLNP)  |
+----------------------+----------------------+
| остаток пакета CLNP                         |
| .                                           |
| .                                           |
+---------------------------------------------+

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

Некоторые протоколы (например, IPX) не имеют значения NLPID. В соответствии со сказанным выше, протокол IPX должен инкапсулироваться с использованием заголовка SNAP. В этом случае кадр будет иметь формат:

+---------------------------------------------+
| Адрес Q.922                                 |
+----------------------+----------------------+
| Control 0x03         | pad 0x00             |
+----------------------+----------------------+
| NLPID - 0x80 (SNAP)  | OUI - 0x00 00 00     |
+----------------------+                      |
|                                             |
+---------------------------------------------+
| PID 0x8137                                  |
+---------------------------------------------+
| пакет IPX                                   |
| .                                           |
+---------------------------------------------+

9. Модель мостов для Frame Relay

Модель организации мостов в сетях Frame Relay идентична модели удаленных мостов, описанной в стандарте IEEE P802.1g Remote MAC Bridging [13], и поддерживает концепцию виртуальных портов (Virtual Port). Удаленные мосты с портами ЛВС принимают и передают MAC-кадры для (от) локальных сетей, к которым эти порты подключены. Мосты могут также передавать кадры MAC через виртуальные порты другим удаленным мостам или принимать кадры от таких мостов. Виртуальный порт может представлять абстракцию точки доступа удаленного моста к одному или нескольким другим удаленным мостам.

Удаленные мосты с помощью системы сетевого управления статически задаются в качестве членов группы удаленного моста. Все члены группы удаленного моста подключены к одному или нескольким виртуальным портам. Множество удаленных мостов MAC-уровня в группе удаленного моста обеспечивает реальное или «потенциальное» соединение MAC-уровн между множеством ЛВС и другими группами удаленных мостов, с которыми удаленные мосты (данной группы) соединены.

В сети Frame Relay должна присутствовать полносвязная (full mesh — каждый с каждым) сеть виртуальных соединений Frame Relay (VC) между мостами и группой удаленного моста. Если сеть Frame Relay не обеспечивает полной связности, сеть на базе мостов (bridge network) должна быть поделена на множество групп удаленных мостов (remote bridge group).

Виртуальные соединения Frame Relay, связывающие мосты из группы удаленного моста, могут комбинироваться или использоваться индивидуально для формирования одного или нескольких виртуальных портов моста. Это позволяет трактовать интерфейс Frame Relay как один виртуальный порт моста со всеми VC в группе или как множество портов моста (с индивидуальными или групповыми VC).

Когда один виртуальный порт моста обеспечивает соединения для всех мостов в данной группе удаленного моста (т. е. все VC объединены в один виртуальный порт), можно использовать стандартный алгоритм Spanning Tree для определения состояния виртуального порта. Если в данной группе удаленного моста определены несколько виртуальных портов, требуется использовать расширенный алгоритм Spanning Tree (это расширение определено в стандарте IEEE 802.1g [13]). Этот алгоритм работает так, что данный виртуальный порт переводится в резервное состояние (backup) только при наличии петель во внешней по отношению к группе удаленного моста сети.

Простейшей конфигурацией для моста в сети Frame Relay является вариант ЛВС (LAN view), при котором все VC объединены в один виртуальный порт. Кадры (такие, как BPDU), которые передаются в ЛВС как широковещательные, должны пересылаться (flood) в каждое виртуальное соединение VC (или должна использоваться групповая адресация, если она поддерживается для сервиса Frame Relay). Лавинная маршрутизация (Flooding) реализуется путем передачи пакета для каждого, имеющего отношение к делу DLC, связанного с интерфейсом Frame Relay. Виртуальные соединения VC в такой среде в общем случае невидимы для моста, т. е. мост передает кадр с лавинной маршрутизацией интерфейсу Frame Relay и «не видит», что кадр передается индивидуально в каждое виртуальное соединение (VC). Если все участвующие в этом процессе мосты соединены «каждый с каждым» (full mesh), для такой конфигурации достаточно стандартного алгоритма Spanning Tree.

Обычно мосты ЛВС определяют достижимость интерфейса конкретной конечной станции, связывая MAC-адрес с портом моста. В сети Frame Relay, настроенной на работу с одним bridge-портом типа моста ЛВС (или любым набором VC, объединенных для формирования одного bridge-порта), мост должен ассоциироваться не только с MAC-адресом bridge-порта, но и с идентификатором соединения. Для сетей Frame Relay в качестве идентификаторов соединений используются значения DLCI. Неразумно, а возможно и нереально, требовать статической настройки мостов для создания ассоциаций между всеми возможными MAC-адресами получателей и DLC. Следовательно, мосты в сетях Frame Relay, действующие по типу мостов ЛВС, должны обеспечивать механизм, позволяющий bridge-портам Frame Relay динамически создавать такие ассоциации. Для реализации автоматического обучения передаваемый с использованием мостов пакет должен соответствовать требованиям к инкапсуляции, описанным в разделе 4.2. В этом случае приемный интерфейс Frame Relay будет знать, как работать с пакетом, полученным через мост, для сбора требуемой информации.

Другое приближение для мостов Frame Relay (point-to-point view) трактует каждое виртуальное соединение Frame Relay VC как отдельный порт моста. В этом варианте лавинная маршрутизация и пересылка пакетов существенно упрощаются, поскольку каждый порт моста связан с единственным адресатом (destination). Нет необходимости организовывать искусственную лавинную маршрутизацию (flooding) или связывать DLCI с MAC-адресами получателей. В зависимости от топологии соединений (VC) может потребоваться использование расширенного алгоритма Spanning Tree для того, чтобы сохранялась активность всех портов, пока не возникает петель во внешней по отношению к группе удаленного моста.

Возможно также использовать комбинированную (LAN и point-to-point) модель для одного интерфейса Frame Relay. Для реализации такого подхода некоторые VC объединяются для формирования одного виртуального bridge-порта, а остальные VC образуют независимые порты мостов.

                                +-------+
             -------------------|   B   |
            /            -------|       |
           /            /       +-------+
          /             |
+-------+/              \       +-------+
|   A   |                -------|   C   |
|       |-----------------------|       |
+-------+\                      +-------+
          \
           \                    +-------+
            \                   |   D   |
             -------------------|       |
                                +-------+

На рисунке показаны различные варианты конфигурации мостов (пунктирные линии задают виртуальные соединения).

Поскольку в приведенном примере отсутствует полная связность (VC между каждой парой мостов), сеть должна быть разделена на несколько групп remote bridge. Разумно объединить мосты A, B и C в одну группу, а мосты A и D — в другую.

Конфигурация первой группы объединяет VC, соединяющие три моста (A, B, C) в один виртуальный порт. Это является примером LAN-конфигурации. Вторая группа также содержит один виртуальный порт, который просто соединяет мосты A и D. В этой конфигурации стандартного алгоритма Spanning Tree достаточно для обнаружения петель.

Альтернативный вариант конфигурации будет иметь 3 отдельных виртуальных порта, соответствующих VC, которые связывают мосты A, B и C. Поскольку применение стандартного алгоритма Spanning Tree в этой конфигурации будет приводить к обнаружению петли, для сохранения активности всех виртуальных портов требуется использовать расширенный алгоритм Spanning Tree. Отметим, что вторая группа по-прежнему содержит один виртуальный порт и может использовать стандартный алгоритм Spanning Tree.

Используя тот же пример (см. рисунок), мы можем создать конфигурацию удаленных мостов с тремя группами. Это будет примером конфигурации point-to-point. В этом случае виртуальные соединения VC, связывающие A и B, VC между A и C, а также VC между A и D являются bridge-группами с одним виртуальным портом.

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

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

В документе также рассматривается использование протоколов ARP и RARP в сетях Frame Relay, а эти протоколы имеет отношение к безопасности. Поскольку ARP не использует средств аутентификации, не возникает связанных с этим вопросов безопасности (например, возможность подмены хостов). При использовании протоколов ARP и RARP в сетях Frame Relay не применяется каких-либо дополнительных средств обеспечения безопасности.

11. Приложение A – NLPID и PID

Список наиболее часто используемых NLPID

0x00 Null Network Layer или Inactive Set (не используетсяс Frame Relay)
0x08 Q.933 [2]
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xB0 FRF.9 Data Compression [14]
0xB1 FRF.12 Fragmentation [18]
0xCC IPv4
0xCF PPP in Frame Relay [17]

Список PID для OUI=00-80-C2

С сохранением FCS Без сохранения FCS Среда
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
0x00-0D Фрагменты
0x00-0E BPDU в соответствии с 802.1(d) или 802.1(g)[12]

12. Приложение B — Ориентированные на соединения процедуры

Это приложение содержит дополнительные сведения и рекомендации по использованию ITU Q.933 и других стандартов ITU для инкапсуляции данных в сетях Frame Relay. Содержащаяся здесь информация подобна (в некоторых случаях идентична) сведениям, содержащимся в приложении Annex E к стандарту ITU Q.933. Первичным источником является стандарт, а в настоящем документе эти сведения приведены только для удобства.

Значения идентификаторов протокола сетевого уровня NLPID (Network Level Protocol ID) распределяются ISO и ITU. Список содержит идентификаторы для множества протоколов, включая IP, CLNP (ISO 8473) ITU Q.933, ISO 8208. На рисунке показаны общие методы инкапсуляции при передаче данных через сети Frame Relay. Гибкость приведенной схемы заключается в идентификации различных вариантов обозначения протоколов, используемых

  • системами сквозной передачи (end-to-end system)
  • мостами или маршрутизаторами, соединяющими ЛВС
  • или комбинированными системами

для передачи трафика через сети Frame Relay.

                          Q.922 control
                               |
                               |
          --------------------------------------------
          |                                          |
         UI                                       I Frame
          |                                          |
    ---------------------------------         --------------
    | 0x08    | 0x81      |0xCC     | 0x80    |..01....    |..10....
    |         |           |         |         |            |
   Q.933     CLNP        IP        SNAP     ISO 8208    ISO 8208
    |                               |       Modulo 8    Modulo 128
    |                               |
    --------------------           OUI
    |                  |            |
   L2 ID              L3 ID      -------
    |               User         |     |
    |               Specified    |     |
    |               0x70        802.3 802.6
    |
    ---------------------------
    |0x51 |0x4E |     |0x4C   |0x50
    |     |     |     |       |
   7776  Q.922 Others 802.2  User
                             Specified

Для тех протоколов, не имеющих идентификатора NLPID или не поддерживающих SNAP-инкапсулцию, следует использовать значение NLPID=0x08, указывающее на необходимость применять рекомендации ITU Q.933. 4 октета после поля NLPID включают идентификацию протоколов канального (2) и сетевого (3) уровня. Коды для большинства протоколов определены информационными элементами совместимости на нижних уровнях в стандарте ITU Q.933. Пользовательские коды (User Specified) описаны в стандарте in Frame Relay Forum FRF.3.1 [15]. Этот же стандарт содержит варианты для определения нестандартных протоколов.

Формат заголовка для других протоколов с использованием Q.933 NLPID

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | NLPID 0x08    |
+---------------+---------------+
| L2 Protocol ID                |
| октет 1       | октет 2       |
+-------------------------------+
| L3 Protocol ID                |
| октет 2       | октет 2       |
+-------------------------------+
| Протокольные данные           |
+-------------------------------+
| FCS                           |
+-------------------------------+

ISO 8802/2 с заданным пользователем уровнем 3

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | NLPID 0x08    |
+---------------+---------------+
| 802/2 0x4C    | 0x80          |
+-------------------------------+
|User Spec. 0x70| Примечание 1  |
+-------------------------------+
| DSAP          | SSAP          |
+-------------------------------+
| Control (Примечание 2)        |
+-------------------------------+
| Остаток PDU                   |
+-------------------------------+
| FCS                           |
+-------------------------------+

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

Примечание 2: Поле Control содержит два октета для кадров формата I и S (см. 88002/2)

Инкапсуляция с использованием I-кадра (уровень 2)

I-кадры Q.922 I используются для поддержки протоколов сетевого уровня, которые требуют подтверждений от канального уровня (например, ISO 8208). Бит C/R (адрес T1.618) будет использоваться для индикации команд и откликов.

Формат кадра ISO 8208 с модулем 8

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|   ....Control I frame         |
+---------------+---------------+
| Пакет 8208 (modulo 8) Прим. 3 |
|                               |
+-------------------------------+
| FCS                           |
+-------------------------------+

Примечание 3: Первый октет пакетов 8208 также идентифицирует NLPID (..01….).

Формат кадра ISO 8208 с модулем 128

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|   ....Control I frame         |
+---------------+---------------+
| Пакет 8208 (modulo 128)       |
| Примечание 4                  |
+-------------------------------+
| FCS                           |
+-------------------------------+

Примечание 4: Первый октет пакетов 8208 также идентифицирует NLPID (..10….).

13. Приложение C – Отличия от RFC 1490

Документ RFC 1490 получил широкое распространение, многократно реализован и учтен в стандартах Frame Relay Forum FRF.3.1 [15] и ITU Q.933 [2]. В этом разделе рассмотрены отличия настоящего документа от RFC 1490, внесенные в результате практического использования спецификации и накопленного опыта взаимодействия (интероперабельности) систем.

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

  1. Требование поддержки протоколов со SNAP-инкапсуляцией для протоколов, имеющих NLPID, было снято. В RFC 1490 сказано, что для протоколов, имеющих идентификатор NLPID (например, IP), должна использоваться NLPID-инкапсуляция. Ниже в том же документе было указано, что станции должны воспринимать эти протоколы и со SNAP-инкапсуляцией. Непоследовательность такого подхода очевидна. Станции должны передавать и воспринимать инкапсуляцию NLPID для таких протоколов и могут (но не обязаны) воспринимать также SNAP-инкапсуляцию.
  2. Удален раздел, посвященный фрагментации. К настоящему времени отсутствует интероперабельность для алгоритма фрагментации, предложенного в RFC 1490. Кроме того, некоторые элементы предложенного механизма фрагментации делают его неприемлемым для отдельных приложений Frame Relay. В результате рассмотрение вопросов фрагментации было исключено из данного документа и предлагается использовать фрагментацию в соответствии со стандартом FRF.12 [18].
  3. Механизм преобразования адресов, предложенный в RFC 1490, подходит только для постоянных соединений PVC и не может быть использован в средах с коммутируемыми соединениями SVC. Поэтому название раздела в данном документе было соответствующим образом изменено. Вопросы преобразования адресов в средах с коммутируемыми соединениями SVC рассматриваются рабочей группой ION.
  4. В данном документе дополнительно рассмотрена инкапсуляция Source Routing BPDU и соответствующее добавление было сделано в Приложении A.
  5. Более четко изложены вопросы использования канонических и неканонических MAC-адресов получателей.
  6. Описание протокола Inverse ARP было опущено в связи с выпуском спецификации Inverse ARP [11].
  7. Добавлен раздел, посвященный вопросам безопасности.

14. Литература

[1] International Telecommunication Union, «ISDN Data Link Layer Specification for Frame Mode Bearer Services», ITU-T Recommendation Q.922, 1992.

[2] International Telecommunication Union, «Signalling Specifications for Frame Mode Switched and Permanent Virtual Connection Control and Status Monitoring», ITU-T Recommendation Q.933, 1995.

[3] Information technology — Telecommunications and Information Exchange between systems — Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992.

[4] Baker, F., and R. Bowen, «PPP Bridging Control Protocol (BCP)», RFC 16381, June 1994.

[5] International Standard, Information Processing Systems — Local Area Networks — Logical Link Control, ISO 8802-22, ANSI/IEEE, Second Edition, 1994-12-30.

[6] Plummer, D., «An Ethernet Address Resolution Protocol — or — Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware», STD 37, RFC 826, November 1982.

[7] Reynolds, J., and J. Postel, «Assigned Numbers», STD 2, RFC 17004, October 1994. См. также: http://www.iana.org/numbers.html

[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, «A Reverse Address Resolution Protocol», STD 38, RFC 903, June 1984.

[9] Postel, J., and J. Reynolds, «A Standard for the Transmission of IP Datagrams over IEEE 802 Networks», RFC 1042, February 1988.

[10] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and architecture», IEEE Standard 802-19902.

[11] Bradley, T., Brown, C., and A. Malis, «Inverse Address Resolution Protocol», RFC 2390, September 1998.

[12] IEEE, «IEEE Standard for Local and Metropolitan Networks: Media Access Control (MAC) Bridges», IEEE Standard 802.1D-19902.

[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media Access Control (MAC) Bridging, March 12, 19972.

[14] Frame Relay Forum, «Data Compression Over Frame Relay Implementation Agreement», FRF.95, January 22, 1996.

[15] Frame Relay Forum, «Multiprotocol Encapsulation Implementation Agreement», FRF.3.15, June 22, 1995.

[16] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[17] Simpson, W., «PPP in Frame Relay», RFC 1973, June 1996.

[18] Frame Relay Forum, «Frame Relay Fragmentation Implementation Agreement», FRF.125, December 1997.

[19] Frame Relay Forum, «Frame Relay PVC Multicast Service and Protocol Implementation Agreement», FRF.75, October 21, 1994.

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

Caralyn Brown

Consultant

EMail: cbrown@juno.com

Andrew Malis

Ascend Communications, Inc.

1 Robbins Road

Westford, MA 01886

Phone: (978) 952-7414

EMail: malis@ascend.com


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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1Этот документ в настоящее время утратил силу и заменен RFC 2878. Прим. перев.

2Стандарты IEEE 802 доступны на сайте http://standards.ieee.org/getieee802. Прим. перев.

4В соответствии с RFC 3232 документ RFC 1700 утратил силу STD 2. Выделенные значения доступны в базе данных, указанной ссылкой. Прим. перев.

5Стандарты Frame Relay Forum доступны для загрузки с сайта http://www.mplsforum.com/frame/Approved/. Прим. перев.