RFC 2917 A Core MPLS IP VPN Architecture

Network Working Group                                    K. Muthukrishnan
Request for Comments: 2917                            Lucent Technologies
Category: Informational                                          A. Malis
                                                    Vivace Networks, Inc.
                                                           September 2000

 

Архитектура ядра MPLS IP VPN

A Core MPLS IP VPN Architecture

PDF

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

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов Internet и может распространяться свободно.

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

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

Тезисы

В этом документе представлена модель построения ядра службы Виртуальных Частных Сетей (VPN1) в сети MPLS сервис-провайдера. Эта модель использует многопротокольную коммутацию меток (MPLS2) в опорной сети для предоставления более высокого качества услуг. Основной задачей сервис-провайдера является предоставление заказчикам услуг виртуальных маршрутизаторов. Основными преимуществами этой архитектуры является простота настройки, защита пользователей, безопасность сети, динамическое обнаружение соседей, масштабирование и использование существующих протоколов маршрутизации без необходимости их изменения.

1. Используемые сокращения

ARP — протокол преобразования адресов (Address Resolution Protocol)

CE — краевой маршрутизатор пользователя (Customer Edge router)

LSP — путь коммутации меток (Label Switched Path)

PNA — администратор частной сети (Private Network Administrator)

SLA — соглашение об уровне обслуживания (Service Level Agreement)

SP — сервис провайдер (Service Provider)

SPED — краевое устройство сервис-провайдера (Service Provider Edge Device)

SPNA — администратор сети сервис-провайдера (SP Network Administrator)

VMA — групповой адрес VPN (VPN Multicast Address)

VPNID — идентификатор VPN (VPN Identifier)

VR — виртуальный маршрутизатор (Virtual Router)

VRC — консоль виртуального маршрутизатора (Virtual Router Console)

2. Введение

В этом документе представлена модель построения ядра службы Виртуальных Частных Сетей (VPN3) в сети MPLS сервис-провайдера. Возможны два варианта построения ядра — оверлейная модель и модель на основе виртуальных маршрутизаторов. Оверлейная модель основана на расширение семантики существующих протоколов маршрутизации для передачи информации о доступности (сетей). В этом документе основное внимание уделено модели на основе виртуальных маршрутизаторов.

Представленная здесь модель не требует изменения существующих протоколов маршрутизации. Обнаружение соседей осуществляется за счет использования эмулируемых ЛВС и протокола преобразования адресов ARP. В этом документе проводится линия раздела между SP и PNA — SP владееет услугами уровней 1 и 2, а также управляет ими, а услуги уровня 3 относятся к PNA и управляются им. За счет поддержки логически полностью независимых доменов маршрутизации PNA получает гибкость использования незарегистрированных и приватных адресов. За счет применения приватных LSP и инкапсуляции VPNID с использованием стеков меток в разделяемых LSP предотвращаются проблемы с защитой данных.

Описанная здесь модель отличается от варианта RFC 2547 [Rosen1] тем, что не задается конкретный протокол маршрутизации для переноса маршрутов VPN. В RFC 2547 определены изменения протокола BGP, которые требуется внести для передачи индивидуальных (unicast) маршрутов VPN через опорную сеть SP. Для передачи групповых маршрутов потребуются дополнительные исследования архитектуры.

3. Виртуальные маршрутизаторы

Виртуальный маршрутизатор представляет собой набор статических или динамических «нитей» (thread), обеспечивающий услуги маршрутизации и пересылки, подобно физическому маршрутизатору. Для виртуального маршрутизатора не требуется (хотя может использоваться) отдельный процесс в операционной системе — просто создается иллюзия существования реального маршрутизатора, удовлетворяющего потребности сетей, к которым он подключен. Виртуальный маршрутизатор, подобно своему физическому аналогу, является элементом домена маршрутизации. Другие маршрутизаторы этого домена могут быть физическими или виртуальными. Из того, что виртуальный маршрутизатор соединен с конкретным (логически отделенным) доменом маршрутизации, а физический маршрутизатор может поддерживать множество виртуальных маршрутизаторов, следует, что один физический маршрутизатор может поддерживать множество (логически отделенных) доменов маршрутизации.

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

К числу аспектов, которые требуется эмулировать в виртуальных маршрутизаторах, относятся:

  1. поддержка любых комбинаций протоколов маршрутизации;

  2. мониторинг сети;

  3. поиск неисправностей.

Каждая сеть VPN представляет собой логически независимый домен маршрутизации. Это расширяет возможности SP в части предоставления заказчикам услуг маршрутизации без необходимости установки отдельного маршрутизатора для каждой сети VPN. В результате инвестиции SP в оборудование (а именно, в маршрутизаторы и каналы между ними), могут служить множеству заказчиков.

4. Задачи

  1. Простая, масштабируемая конфигурация оконечных точек VPN в сети сервис-провайдера. Для добавления CE должно требоваться не более одного элемента конфигурации.

  2. Отказ от использования ресурсов SP, являющихся уникальными в глобальном масштабе и дефицитными (таких, как адреса и подсети IP).

  3. Динамическое обнаружение VR (виртуальных маршрутизаторов в «сетевом облаке» SP. Это требование не является обязательным, но его выполнение очень важно в целях обеспечения простоты.

  4. Для VR следует обеспечить сетевым администраторам VPN полные возможности настройки и мониторинга. Это позволит PNA самостоятельно настраивать VPN или передавать эту задачу на аутсорсинг SP.

  5. Настройку качества пересылки данных следовать обеспечивать на уровне VPN-VPN. Уровни качества должны представлять собой ряд (возможно, дискретный) последовательных значений. Примерами уровней качества обслуживания могут служить best effort (по возможности), dedicated bandwidth (выделенная полоса), QOS, policy based forwarding (пересылка на основе правил).

  6. Настройку диференцированных услуг следует обеспечивать на уровне VPN-VPN (возможно, с использованием LSP, организованных исключительно для пересылки трафика в VPN).

  7. Защита маршрутизаторов Internet распространяется на виртуальные маршрутизаторы. Это означает, что функции пересылки и маршрутизации в виртуальных маршрутизаторах должны быть столь же защищены, как аналогичные функции в выделенном, физическом маршрутизаторе. Не следует допускать непреднамеренной утечки информации (пользовательских данных и информации о доступности сетей) из одного домена маршрутизации в другой.

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

  9. Не должно требоваться специальных расширений для существующих протоколов маршрутизации типа BGP, RIP, OSPF, ISIS и т. п. Это имеет очень важное значение с точки зрения будущих расширений или введения новых типов сервиса (например, NHRP или групповой адресации). В дополнение к сказанному, улучшения и расширения существующих протоколов маршрутизации (такие, как управление трафиком в ISIS и OSPF) должны легко встраиваться в реализации VPN.

5. Архитектурные требования

В сети сервис-провайдера должна работать та или иная форма групповой маршрутизации для всех узлов, имеющих соединения VPN, и узлов, которые должны пересылать групповые дейтаграммы для обнаружения виртуальных маршрутизаторов. Конкретный протокол групповой маршрутизации не задается. SP может выбрать MOSPF, DVMRP или любой другой протокол.

6. Основы архитектуры

  1. Каждой сети VPN выделяется идентификатор VPNID, который уникален в масштабе сети SP. Этот идентификатор позволяет однозначно связать VPN с пакетами и соединениями. Нулевое значение VPNID зарезервировано для представления публичной сети Internet. Рекомендуется (но не требуется) выделять идентификаторы VPN в соответствии с RFC 2685 [Fox].

  2. Услуги VPN предоставляются в форме «виртуального маршрутизатора». Эти VR остаются в SPED и относятся, таким образом к краю облака SP. Виртуальные маршрутизаторы будут использовать сеть SP для пересылки пакетов данных и управления, но во всех остальных аспектах остаются невидимыми за пределами SPED.

  3. Контрактный «размер» VR для VPN в данном устройстве SPED выражается количеством ресурсов IP (интерфейсы, маршрутные фильтры, записи и т. п.). Это значение полностью контролируется SP и обеспечивает гранулярность, требуемую SP для виртуально неограниченного числа уровней обслуживания VR для каждого устройства SPED. [Например, одно устройство SPED может быть точкой агрегирования (скажем, центральный офис корпорации) для данной VPN, а множество других SPED могут служить точками доступа (офисы филиалов). В этом случае устройство SPED, подключенное в центральном офисе, может обеспечивать более мощный VR, а SPED в филиалах могут использовать меньшие (возможно, оконечные) VR]. Такое решение также позволяет SP создавать сети с распределением нагрузки между разными маршрутизаторами.

  4. Одним из индикаторов размера VPN является число устройств SPED в сети SP, имеющих подключения к маршрутизаторам CPE в данной VPN. В этом смысле VPN со множеством сайтов, которым требуется подключение, образуют «большую» сеть VPN, а при незначительном числе сайтов — «малую» VPN. Кроме того, можно предполагать изменение размеров VPN с течением времени. Сети VPN могут также объединяться в результате слияния или покупки компаний, а также при заключении партнерских соглашений. Данная архитектура легко адаптируется к подобным изменениям, поскольку для VPN уникальные в глобальном масштабе ресурсы IP не присваиваются и не выделяются. Число устройств SPED не ограничивается какими-либо искусственными конфигурационными пределами.

  5. SP владеют и управляют сетевыми объектами уровней 1 и 2. Говоря более конкретно, SP управляют физическими коммутаторами и маршрутизаторами, физическими соединениями, логическими каналами уровня 2 (DLCI в сетях Frame Relay и VPI/VCI в ATM) и LSP (и их привязками к конкретным VPN). В контексте VPN сервис-провайдеры SP отвечают за согласование и выделение сетевых элементов уровня 2 для конкретных VPN.

  6. Элементы уровня 3 относятся к частным сетям и управляются администраторами этих сетей (PNA). Примеры таких элементов включают IP-интерфейсы, выбор протоколов динамической маршрутизации или статических маршрутов, а также интерфейсов для маршрутизации. Отметим, что хотя конфигурационные параметры уровня 3 входят в зону ответственности PNA, эти администраторы не всегда обязаны поддерживать их. Достаточно часто PNA передают администрирование IP на уровень виртуальных маршрутизаторов SP. Независимо от того, кто отвечает за настройку и мониторинг, это приближение обеспечивает администраторам PNA полную картину маршрутизации и позволяет им строить сети в соответствии с их реальными задачами.

  7. Сетями VPN можно управлять, как физическими маршрутизаторами, а не развернутыми виртуальными маршрутизаторами (VR). Следовательно, для управления может применяться протокол SNMP или аналогичные методы, а также прямое управление с консоли VR (VRC).

  8. Стандартные средства поиска неисправностей (ping, traceroute и т. п.) разработаны для доменов маршрутизации, состоящих исключительно из выделенных физических маршрутизаторов. Следовательно, для мониторинга и поиска неисправностей могут применяться эти стандартные методы, а также SNMP и аналогичные средства. В этом случае может также использоваться консоль VRC как на физических маршрутизаторах.

  9. Поскольку консоли VRC доступны пользователям, нужно обеспечить проверку прав пользователей VPN на доступ к ресурсам уровня 3 в данной VPN и полностью запрещать доступ к физическим ресурсам маршрутизаторов. Большинство маршрутизаторов реализуют такую возможность с помощью разных представлений баз данных.

  10. Консоли VRC доступны и для SP. Если функции настройки и мониторинга переданы SP, сервис-провайдер может использовать VRC для решения этих задач, принимая на себя функции PNA.

  11. Маршрутизаторы VR в устройствах SPED формируют VPN в сети SP. Совместно эти элементы образуют виртуальный домен маршрутизации. Динамическое обнаружение элементов реализуется путем эмуляции ЛВС в сети SP.

Каждой VPN в сети SP присваивается один (и только один) групповой адрес, выбираемый из диапазона 239.192/14 [Meyer]. Единственным требованием в данном случае является уникальность адреса для конкретной VPN. Эта задача легко решается маршрутизаторами путем использования простой функции однозначного отображения VPNid на групповой адрес. Подписка на данный групповой адрес позволяет виртуальным маршрутизаторам обнаруживать другие VR и быть доступными для обнаружения другими VR. Важно отметить, что групповой адрес не является настраиваемым параметров.

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

    1. LSP с характеристиками best-effort, доступный для использования всеми VPN;

    2. LSP, выделенный для VPN и построения трафика заказчиком VPN;

    3. приватный LSP с поддержкой дифференциации;

    4. пересылка в соответствии с правилами на выделенном виртуальном устройстве L2.

Выбор метода пересылки согласуется между SP и пользователем VPN, составляя, возможно, часть SLA-соглашения между ними. Это позволяет SP предлагать разные типы обслуживания для различных VPN.

Естественно, обычная поэтапная (hop-by-hop) пересылка поддерживается для пакетов маршрутизации и пользовательских пакетов данных в периоды организации LSP и при возникновении отказов.

  1. Эта модель не требует запуска отдельных задач для каждого протокола маршрутизации в операционной системе для каждого VR на устройствах SPED. Для использования на каждом SPED могут быть адаптированы конкретные реализации. Поддержка раздельных баз маршрутных данных и таблиц пересылки для каждого VR является одним из путей обеспечения максимальной производительности для данного устройства SPED.

7. Масштабируемая конфигурация

Предполагается, что типовые VPN в облаке SP будут включать сотни или тысячи конечных станций. Следовательно, сложность конфигурации должна зависеть от числа конечных точек не сильнее, чем линейно от числа. Более конкретно, администратор должен добавлять незначительное число элементов в конфигурационные файлы при подключении нового пользовательского сайта к множеству VR, образующих конкретную VPN. В противном случае задача становится для сервис-провайдеров слишком обременительной. В описываемой архитектуре от сервис-провайдера требуется лишь выделение и настройка входящих/исходящих физических соединений (например, Frame Relay DLCI или ATM VPI/VCI) и виртуальные соединения между VR и эмулируемыми ЛВС.

8. Динамическое обнаружение соседей

VR данной VPN реализуются на множестве устройств SPED в сети. Эти VR должны знать друг о друге и быть соединены между собой.

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

Возникает потребность в обеспечении маршрутизаторам VR возможности автоматически детектировать друг друга. Обнаружение соседей выполняется за счет предоставления каждой VPN ограниченной эмулируемой ЛВС, которая может использоваться разными способами.

  1. Преобразование адресов (ARP) в ЛВС позволяет определить (приватный) IP-адрес следующего интервала, связанного с другими VR.

  2. Протоколы маршрутизации (например, RIP или OSPF) используют эту ограниченную эмулируемую ЛВС для обнаружения соседей и передачи маршрутных обновлений.

ЛВС на уровне VPN эмулируются с использованием групповых адресов IP. С целью сохранения публичного адресного пространства и по причине того, что эти групповые адреса видны только в сети SP, мы будем пользоваться адресами с областью видимости Organizational (организация) из блока 239.192/14, как описано в [Meyer]. Каждой VPN выделяется адрес из этого диапазона. Для автоматической настройки конфигурации адреса определяются на основе VPNID.

9. Конфигурация домена VPN IP

            151.0.0.1
            ################
           #              #
          #  ROUTER 'A'  #
         #              #
        ################
             #       #
            #         #
           #           #
          #             #
     #############    ###############
    #           #    #             #
   # ROUTER 'B'#    # ROUTER 'C'  #
  #           #    #             #
 #           #    #             #
#############    ###############
152.0.0.2         153.0.0.3

Рисунок 1: Физический домен маршрутизации

На рисунке 1 показан физический домен в сети SP. В этой сети физические маршрутизаторы A, B и C соединены между собой и каждому маршрутизатору присвоен «публичный» адрес IP. Эти адреса являются уникальными идентификаторами маршрутизаторов в сети SP.

Каждый виртуальный маршрутизатор настраивается PNA, как будто он является частным физическим маршрутизатором. Естественно, SP ограничивает ресурсы, которые такой VR может потреблять на уровне устройств SPED. Каждая VPN имеет множество физических (с маршрутизаторами CPE) и логических (с эмулируемой ЛВС) соединений. Каждое соединение поддерживает IP и может быть настроено на использование любой комбинации стандартных протоколов маршрутизации и маршрутных политик в соответствии с задачами корпоративной сети.

На рисунке 24 три маршрутизатора VR сети VPN 1 размещаются на трех устройствах SPED. Маршрутизатор A поддерживает VR-A, маршрутизатор B — VR-B, а маршрутизатор C — VR-C. Виртуальные маршрутизаторы VR-C и VR-B имеют по одному физическому соединении с оборудованием CPE, а VR-A имеет 2 физических соединения. Каждый из этих VR имеет поддерживающие IP соединения с эмулируемой ЛВС. VR-A имеет (физические) соединения с центральным офисом компании и поддерживает для них протокол OSPF. Следовательно, он может маршрутизировать пакеты в сети 172.150.0/18 и 172.150.128/18. На маршрутизаторе VR-B работает протокол RIP в рамках сети филиала (через физическое соединение) и этот же протокол используется (через логическое соединение) для экспорта префикса 172.150.64/18 маршрутизатору VR-A. VR-A анонсирует используемый по умолчанию маршрут через логическое соединение маршрутизатору VR-B. VR-C служит extranet-соединением для подключения базы данных на узле 172.150.128.1. Следовательно, VR-C анонсирует используемый по умолчанию маршрут через логическое соединение маршрутизатору VR-A. VR-A экспортирует только адрес 175.150.128.1 маршрутизатору VR-C. Это позволяет предотвратить проблемы с безопасностью остальной части корпоративной сети.

         172.150.0/18                                172.150.128/18
 -----------------------             ---------------------------|
             |                                       |          |
             |                                       |     172.150.128.1
             |               ROUTER 'A' (151.0.0.1)  |       |---------|
             |               #############           |       |Parts DB |
             |           ---#-----------#            |       /---------/
             |    OSPF   | #           #     ISIS    |      /----------/
             ------------|#  VR - A   #|--------------
                         #-------|---#-|
                        #############10.0.1/24
             |----|------------#-#---------------|-----|
                  |10.0.0.2/24#   #              |10.0.0.3/24
           |------|-------|  #     #    ---------|-------|
           |  ###############       #   |############### |
           | #  VR - B    |#         #  #    VR - C   #  |
           |#-------------# ROUTER 'B'##|------------#----
(152.0.0.2)###############            ############### (153.0.0.3)
      -------------------------       ROUTER 'C' |   Extranet
            172.150.64/18                        V
                                              Vendors

Рисунок 2: Виртуальный домен маршрутизации

Администратор сети будет настраивать приведенную ниже конфигурацию.

  1. Соединения OSPF с сетями 172.150.0/18 и 172.150.128/18 на VR-A.

  2. Соединения RIP с VR-B и VR-C на VR-A.

  3. Маршрутная политика на VR-A для анонсирования только маршрута по умолчанию в VR-B.

  4. Маршрутная политика на VR-A для анонсирования только 172.159.128.1 в VR-C.

  5. RIP на VR-B для VR-A.

  6. RIP на VR-C для анонсирования маршрута по умолчанию в VR-A.

10. Пример обнаружения соседа

На рисунке 25 устройство SPED, на котором базируется VR-A (SPED-A) , использует публичный адрес 150.0.0.1/24, SPED-B — 150.0.0.2/24 и SPED-C — 150.0.0.3/24. Как отмечено выше, соединения между VR осуществляются через эмулируемую ЛВС. В приведенном примере VR-A использует адрес 10.0.0.1/24, VR-B — 10.0.0.2/24, VR-C — 10.0.0.3/24.

Предположим, что VR-A передает пакет VR-B. Для получения адреса VR-B (адрес SPED-B’) VR-A отправляет ARP-запрос с адресом VR-B (10.0.0.2) в поле логического адреса. Логическим адресом отправителя будет 10.0.0.1, а «аппаратным» — 151.0.0.1. Запрос ARP инкапсулируется в групповой пакет данной VPN и передается. Копии этого пакета получают устройства SPED B и SPED-C. Устройство SPED-B распознает адрес 10.0.0.2 в контексте VPN 1 и передает отклик с «аппаратным» адресом 152.0.0.2. Этот отклик передается по групповому адресу VPN, чтобы результат ARP был доступен во всей сети (это обеспечивает снижение трафика).

Если обнаружения соседей не используется, нужна будет ручная настройка конфигурации. В приведенном примере на VR-A будет создана статическая запись ARP для VR-B с логическим адресом 10.0.0.1 и «аппаратным» адресом 152.0.0.2.

11. Пересылка

Как было отмечено выше при рассмотрении архитектуры, пересылка данных может осуществляться несколькими способами. Во всех вариантах, за исключением поэтапной (Hop-by-Hop) пересылки пакетов маршрутизации и управления, используемый метод задается конфигурацией. Наиболее быстрое обслуживание обеспечивается при рассылке на основе правил, наименее быстрое — при пересылке best effort через LSP общего пользования. Порядок предпочтений для методов пересылки показан ниже:

  1. пересылка на основе правил;

  2. пересылка через приватные LSP;

  3. пересылка через публичные LSP (Best-effort).

11.1 Приватные LSP

Такие LSP могут настраиваться на уровне VPN. Обычно для таких LSP резервируется некая (отличная от 0) полоса пропускания и/или конкретный класс дифференцированного обслуживания или QOS. При доступности такого LSP он используется для передачи пользовательских данных и пересылки внутренних данных управления VPN.

11.2 Публичные LSP

Пакеты данных VPN пересылаются с использованием таких LSP, если приватные LSP с заданной полосой пропускания и/или параметрами QoS не организованы или не доступны по иным причинам. Такой LSP используется для выходного маршрутизатора в VPN 0. Значение VPNID из заголовка служит для демультиплексирования пакетов данных разных VPN на выходном маршрутизаторе.

12. Дифференцированные услуги

Организация приватных LSP для VPN позволяет сервис-провайдерам (SP) предлагать своим коммерческим заказчикам дифференцированные услуги. Такие приватные LSP могут связываться с любыми доступными L2 QoS или кодами Diff-Serv. В рамках VPN может быть организовано множество приватных LSP с разными классами обслуживания и профилями для распределения пакетов между этими LSP. Эта возможность, вкупе с масштабированием виртуальных маршрутизаторов позволяет SP обеспечивать реально дифференцируемые услуги пользователям VPN.

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

13.1 Безопасность маршрутизации

Использование стандартных протоколов маршрутизации (таких, как OSPF и BGP) в неизменном виде означает, что все методы шифрования и защиты (такие, как аутентификация соседей с применением MD5) полностью применимы для VR. Ответственность за отсутствие непредусмотренной утечки маршрутов из одной VPN в другую лежит на разработчиках. Одним из способов предотвращения таких утечек является поддержка раздельных таблиц маршрутизации и пересылки.

13.2 Безопасность данных

Это позволяет SP гарантировать заказчикам VPN, что пакеты данных одной VPN никогда не будут попадать в другие. С точки зрения маршрутизации это может быть достигнуто за счет поддержки раздельных маршрутных баз данных для каждого виртуального маршрутизатора. С точки зрения пересылки данных использование стеков меток в случае разделяемых LSP [Rosen2] [Callon] или использование приватных LSP гарантирует приватность данных. Дополнительно могут использоваться пакетные фильтры.

13.3 Безопасность конфигурации

Виртуальные маршрутизаторы с точки зрения PNA выглядят как физические устройства. Это означает, что PNA может настраивать их конфигурацию для обеспечения связности между корпоративными офисами. Обычно SP гарантирут, что доступ к VR на устройствах SPED имеют только PNA и указанные ими лица. Поскольку консоль виртуального маршрутизатора функционально эквивалентна консоли физического устройства, доступны все методы аутентификации пользователей, применяемые для физических консолей (пароли, RADIUSаутентификация и т.п.).

13.4 Безопасность физической сети

При подключении PNA к устройству SPED для настройки или мониторинга VPN, администратор получает доступ к VR для VPN. PNA предоставлены только возможности настройки и мониторинга уровня только 3 в VR. В частности, PNA не имеет возможности настраивать конфигурацию физической сети. Это обеспечивает SP гарантии того, что администраторы VPN не могут нечаянно или осознанно воздействовать на сеть SP.

14. Мониторинг виртуального маршрутизатора

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

15. Производительность

В целях обсуждения вопросов производительности и масштабирования современные маршрутизаторы можно рассматривать в двух плоскостях: маршрутизация (управление) и пересылка.

В плане маршрутизации большинство современных протоколов маршрутизации использует ту или иную методологию оптимизации расчетов для определения кратчайшего пути (путей) к конечным получателям. Например, в протоколах OSPF и ISIS применяется алгоритм Djikstra, а BGP использует Decision Process (процесс принятия решения). Эти алгоритмы основаны на разборе базы маршрутных данных и вычислении наилучшего пути к конечным получателям. Параметры производительности любого из этих алгоритмов основываются на топологических характеристиках (ISIS и OSPF) или числе AS на пути к получателям (BGP). Следует подчеркнуть, что связанные с расчетами накладные расходы в современных маршрутизаторах весьма малы. Это обусловлено тем, что используемые в расчетах «базы данных» в реальности являются структурами данных в оперативной памяти маршрутизатора.

Следовательно, можно сделать ряд заключений:

  1. начало расчета маршрутов для домена маршрутизации не представляет собой ничего иного, кроме организации некоторых регистров для указания на объекты базы данных;

  2. с учетом п. 1 производительность данного алгоритма не ухудшается значительно издержками на его организацию;

  3. из п. 2 следует, что при расчете физическими маршрутизатором множества маршрутов для множества виртуальных маршрутизаторов сложность такого расчета определяется суммой издержек, связанных с маршрутными расчетами для отдельного виртуального маршрутизатора;

  4. из п. 3 следует, что при использовании модели с наложением (overlay) или развертывании виртуальных маршрутизаторов параметры производительности маршрутизатора полностью определяются его аппаратными возможностями и выбором структур данных и алгоритмов.

Для иллюстрации предположим, что на физическом маршрутизаторе поддерживается N сетей VPN, для каждой из которых применяется некий протокол маршрутизации RP. Пусть средняя производительность алгоритма маршрутных расчетов в RP составляет f(X,Y), где X и y — параметры, определяющие производительность алгоритма в протоколе маршрутизации. Например, для алгоритма Djikstra, используемого в OSPF, X может задавать число узлов в области, а Y — число каналов. Производительность VPN с номером n выражается f(Xn, Yn). Производительность (физического) маршрутизатора будет представлять собой сумму f(Xi, Yi) для всех значений i в диапазоне 0 <= i <= N. Это заключение не зависит от выбора модели VPN (виртуальный маршрутизатор или наложение).

В обычной ситуации уровень пересылки использует два типа входных данных — таблицу маршрутизации и заголовки пакетов. Основным параметром производительности будет алгоритм поиска6. Очень быстрый поиск в таблице маршрутизации IP обеспечивается за счет организации таблицы в форме дерева и использования двоичных методов поиска. Производительность этого алгоритма составляет O(log n).

Следовательно, при использовании для виртуальных маршрутизаторов независимых таблиц производительность будет определяться постоянной величиной, связанной с выбором таблицы, и значением O(log n) для поиска в этой таблице маршрута. Это не хуже и не отличается от производительности любого маршрутизатора, а также не отличается от производительности маршрутизаторы, использующего для VPN модель наложения. Однако при интеграции маршрутизатором в модели с наложением таблиц маршрутизации множества VPN производительность будет задаваться O(log m*n), где m — число VPN, для которых поддерживаются таблицы маршрутизации.

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

Авторы благодарят Dave Ryan из Lucent Technologies за неоценимую глубину обзора этой версии документа.

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

[Callon] Callon R., et al., «A Framework for Multiprotocol Label Switching», Work in Progress.

[Fox] Fox, B. and B. Gleeson,»Virtual Private Networks Identifier», RFC 2685, September 1999.

[Meyer] Meyer, D., «Administratively Scoped IP Multicast», RFC 2365, July 1998.

[Rosen1] Rosen, E. and Y. Rekhter, «BGP/MPLS VPNs», RFC 2547, March 1999.

[Rosen2] Rosen E., Viswanathan, A. and R. Callon, «Multiprotocol Label Switching Architecture», Work in Progress7.

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

Karthik Muthukrishnan

Lucent Technologies

1 Robbins Road

Westford, MA 01886

Phone: (978) 952-1368

EMail: mkarthik@lucent.com

Andrew Malis

Vivace Networks, Inc.

2730 Orchard Parkway

San Jose, CA 95134

Phone: (408) 383-7223

EMail: Andy.Malis@vivacenetworks.com

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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2000). 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.

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

Финансирование функций RFC Editor обеспечено Internet Society.


1Virtual Private Network

2Multiprotocol Label Switching

3Virtual Private Network

4В оригинале ошибочно указан рисунок 1. Прим. перев.

5 В оригинале ошибочно указан рисунок #1. Прим. перев.

6В таблице маршрутизации. Прим. перев.

7Работа завершена и опубликована в RFC 3031. Прим. перев.




RFC 2890 Key and Sequence Number Extensions to GRE

Network Working Group                                          G. Dommety
Request for Comments: 2890                                  Cisco Systems
Category: Standards Track                                  September 2000

Расширения GRE для полей Key и Sequence Number

Key and Sequence Number Extensions to GRE

PDF

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

Этот документ содержит проект стандартного протокола для сообщества Internet и служит приглашением к дискуссии в целях совершенствования и развития протокола. Текущее состояние стандартизации и статус протокола можно посмотреть в документе Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.

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

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

Тезисы

GRE1 задает протокол для инкапсуляции любого протокола с использованием произвольного протокола сетевого уровня. Этот документ описывает расширение, с помощью которого два поля Key и Sequence Number могут передаваться в заголовке GRE [1].

1. Введение

Текущая спецификация GRE [1] задает протокол для инкапсуляции любого протокола в произвольный протокол сетевого уровня. Этот документ описывает расширение, с помощью которого два поля Key и Sequence Number могут передаваться в заголовке GRE [1]. Поле Key предназначено для идентификации отдельного потока трафика в туннеле. Поле Sequence Number служит для поддержки упорядочения пакетов в туннеле GRE.

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

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

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

Silently discard – отбрасывание без уведомления

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

2. Расширение заголовка GRE

Формат заголовка пакета GRE [1] показан ниже.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|       Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (необязательно) |     Reserved1 (необязательно) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Предлагаемый заголовок GRE имеет обновленный формат.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S| Reserved0       | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (необязательно) |     Reserved1 (необязательно) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (необязательно)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Sequence Number (необязательно)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key Present (бит 2)

Если флаг Key Present установлен (1), это говорит о наличии поля Key в заголовке GRE. В остальных случаях поле Key не включается в заголовок GRE.

Sequence Number Present (бит 3)

Установленный (1) флаг Sequence Number говорит о наличии поля Sequence Number в заголовке. В противном случае поле Sequence Number field не включается в заголовок GRE.

Позиции флагов Key Present и Sequence Present выбраны для обеспечения совместимости с RFC 1701 [2].

2.1. Поле Key (4 октета)

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

2.2. Порядковый номер (4 октета)

Четырехбайтовое значение поля Sequence Number задается инкапсулятором при установленном в заголовке флаге Sequence Number Present. Поле Sequence Number должно использоваться получателем для восстановления порядка передачи пакетов от инкапсулятора к получателю. Поле Sequence Field предназначено для обеспечения негарантированной, но упорядоченной доставки пакетов. Если установлен флаг Key present (бит 2), порядковые номера относятся к потоку, указанному полем Key. Отметим, что пакеты без флага порядкового номера могут чередоваться с пакетами, где этот флаг установлен.

Порядковые номера принимают значения от 0 до 232-1. Первая дейтаграмма передается с номером 0. Порядковый номер определяется счетчиком по модулю 232. Получатель хранит значение порядкового номера последнего декапсулированного пакета. При организации туннеля GRE для этого номера следует устанавливать значение 232-1.

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

Если пакет принят без нарушения порядка доставки, он декапсулируется. Пакет считается соблюдающим порядок доставки, если его номер на 1 (по модулю 232) больше номера последнего декапсулированного пакета или пакет не имеет порядкового номера (флаг S не установлен).

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

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

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

Отметим, что порядковый номер служит для обнаружения потери пакетов и/или восстановления исходного их порядка (при наличии буферизации) при его нарушении в процессе доставки. Опция порядковых номеров должна применяться подобающим образом — в частности, имеет смысл отказаться от нее при работе с туннелирования, имеющими вышележащий уровень с упорядоченной доставкой или устойчивый к нарушению порядка. Если только часть протоколов, передаваемых в туннеле GRE, требует упорядоченной доставки, устанавливать флаг S в заголовке GRE следует лишь для соответствующих пакетов.

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

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

Этот документ описывает расширение, с помощью которого два необязательных поля Key и Sequence Number могут включаться в заголовок GRE [1]. При использовании поля Sequence number возможна вставка пакетов с произвольными номерами и организация DoS-атаки2. Для защиты от таких атак должны применяться протоколы IPsec [4], защищающие заголовок GRE и туннелируемые данные. Для защиты заголовка GRE должен применяться протокол ESP3 [5] или AH4 [6]. Протокол ESP обеспечивает защиту данных (payload) IP, которые включают заголовок GRE. При использовании AH обеспечивается аутентификация всего пакета, за исключением изменяемых полей. Отметим, что поле Key не участвует в какой-либо сортировке или защите (несмотря на его название).

4. Взаимодействие с IANA

Этот документ не требует выделения значений агентством IANA и не требует согласования с IANA.

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

Этот документ создан на основе исходных идей авторов RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David Meyer, Yingchun Xu, Ajoy Singh и многие другие внесли свой вклад в обсуждение. Автор благодарен всем этим людям.

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

[1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, March 2000.

[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, «Generic Routing Encapsulation», RFC 1701, October 1994.

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

[4] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 24015, November 1998.

[5] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 24066, November 1998.

[6] Kent, S., and R. Atkinson, » IP Authentication Header», RFC 24027, November 1998.

Адрес автора

Gopal Dommety

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134

EMail: gdommety@cisco.com

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (2000). 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.

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

Финансирование функций RFC Editor обеспеченоInternet Society.

1Generic Routing Encapsulation — базовая инкапсуляция маршрутных данных.

2Denial of Service — отказ в обслуживании.

3Encapsulating Security Payload.

4Authentication Header.

5Этот документ заменен RFC 4301. Прим. перев.

6Этот документ заменен RFC 4303 и RFC 4305. Прим. перев.

7Этот документ заменен RFC 4302 и RFC 4305. Прим. перев.




RFC 2918 Route Refresh Capability for BGP-4

Network Working Group                                        E. Chen
Request for Comments: 2918                          Redback Networks
Category: Standards Track                             September 2000

Возможность обновления маршрутов для BGP-4

Route Refresh Capability for BGP-4

PDF

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

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

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

Copyright (C) The Internet Society (2000).

Тезисы

В этом документе определена новая возможность протокола BGP1, обозначаемая термином ‘Route Refresh Capability’, которая обеспечит возможность динамического обмена запросами на обновление маршрутов между узлами BGP и последующее реанонсирование соответствующей Adj-RIB-Out. Другим возможным применением новой функции является облегчение неразрушающего изменения политики маршрутизации.

1. Введение

В настоящее время в протоколе BGP-4 [BGP-4] отсутствует механизм запросов на повторное анонсирование Adj-RIB-Out партнером BGP. При изменении для партнера политики маршрутизации на входе (inbound routing policy) все префиксы от данного партнера требуется тем или иным способом сделать доступными и заново проверить с учетом новой политики. Для решения этой задачи общепринятым методом является “мягкая реконфигурация” (‘soft-reconfiguration’), которая заключается в постоянном хранении всех маршрутов от данного партнера даже при отсутствии частых изменений политики маршрутизации (обычно не более пары раз в день). Для поддержки таких маршрутов требуется дополнительная память и ресурсы CPU.

В этом документе предлагается другое решение, которое избавляет от дополнительный расходов на обслуживание. Точнее говоря, документ определяет новую возможность BGP, названную ‘Route Refresh Capability’2, которая позволяет организовать динамический обмен запросами на обновление маршрутов между узлами BGP и последующее реанонсирование соответствующих Adj-RIB-Out.

2. Route Refresh Capability

Для анонсирования партнеру Route Refresh Capability узел BGP использует BGP Capabilities Advertisement [BGP-CAP]. Эта функция анонсируется с использованием Capability-кода 2 и размера Capability, равного 0.

Анонсируя Route Refresh Capability своему партнеру, узел BGP сообщает тому, что он способен принимать от него и корректно обрабатывать сообщения ROUTE-REFRESH (см. раздел 3).

3. Сообщение ROUTE-REFRESH

Сообщение ROUTE-REFRESH является новым типом сообщений BGP и определяется следующим образом:

Тип: 5 — ROUTE-REFRESH

Формат сообщения: одна пара <AFI, SAFI>, представляемая следующим образом

0       7       15      23      31
+-------+-------+-------+-------+
|      AFI      | Res.  | SAFI  |
+-------+-------+-------+-------+

Значение, использование и представление поля <AFI, SAFI> совпадает с аналогичным полем, определенным в [BGP-MP, разд. 7]. Поля имеют следующие значения:

AFI3 — идентификатор семейства адресов (16 битов).

Res. — резервное поле (8 битов). Отправитель устанавливает для этого поля значение 0, а получатель игнорирует его.

SAFI4 – дополнительный идентификатор семейства адресов (8 битов).

4. Механизм работы

Узлу BGP, который пожелал принимать сообщения ROUTE-REFRESH от своего партнера, следует анонсировать тому Route Refresh Capability, используя анонс BGP Capabilities [BGP-CAP].

Узел BGP может передать сообщение ROUTE-REFRESH своему партнеру, если он получил от этого партнера сообщение Route Refresh Capability. Паре <AFI, SAFI> в таком сообщении следует быть одной из пар <AFI, SAFI>, которые партнер анонсировал узлу во время организации сеанса при анонсировании своих возможностей.

Если узел BGP принимает от своего партнера сообщение ROUTE-REFRESH с парой <AFI, SAFI>, которую этот узел не анонсировал партнеру во время организации сеанса при анонсировании своих возможностей, узлу следует игнорировать такое сообщение. В остальных случаях узлу BGP следует заново анонсировать этому партнеру Adj-RIB-Out для пары <AFI, SAFI>, указанной в сообщении, основываясь на своей политике исходящей маршрутизации.

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

Данное расширение BGP не оказывает влияния на основные вопросы безопасности.

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

Предложенная концепция Route Refresh подобна одной из используемых в протоколе IDRP.

Автор благодарит Yakov Rekhter, Ravi Chandra, Srihari Ramachandra и Bruce Cole за просмотр документа и комментарии.

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

[BGP-4] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 2858, June 2000.

[BGP-CAP] Chandra, R. and J. Scudder, «Capabilities Advertisement with BGP-4», RFC 2842, May 2000.

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

Enke Chen

Redback Networks Inc.

350 Holger Way

San Jose, CA 95134

EMail: enke@redback.com


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2000). 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.

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

Финансирование функций RFC Editor обеспечено Internet Society.

1Border Gateway Protocol

2Функция обновления маршрутов

3Address Family Identifier

4Subsequent Address Family Identifier




RFC 2914 Congestion Control Principles

Network Working Group                                         S. Floyd
Request for Comments: 2914                                       ACIRI
BCP: 41                                                 September 2000
Category: Best Current Practice

Принципы контроля перегрузок

Congestion Control Principles

PDF

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

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

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

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

Тезисы

Целью этого документа является разъяснение необходимости механизмов контроля перегрузок в Internet и обсуждение пригодных способов такого контроля. Одной из конкретных целей является разъяснение опасности пренебрежения контролем насыщения. Другой целью является обсуждение роли IETF в стандартизации новых протоколов контроля перегрузок.

1. Введение

Этот документ основан на более ранних RFC и в некоторых случаях просто включает значительные фрагменты текста из [RFC2309, RFC2357]. Много заимствований сделано также из ранних обсуждений необходимости сквозного контроля перегрузок [FF99].

2. Существующие стандарты контроля перегрузок

Стандарты IETF в части сквозного контроля перегрузок сфокусированы на конкретных протоколах (например, TCP [RFC2581], протоколы с гарантированной доставкой и поддержкой групповой адресации [RFC2357]), синтаксисе и семантике обмена между оконечными узлами и маршрутизаторами информацией о насыщении в сети (например, ECN1 [RFC2481]) или желаемом качестве обслуживания (diff-serv). Роль сквозного контроля перегрузок рассматривается также в информационном RFC «Recommendations on Queue Management and Congestion Avoidance in the Internet» [RFC2309]. Этот документ рекомендует развертывание механизмов активного управления очередями в маршрутизаторах и продолжение разработки для маршрутизаторов механизмов работы с потоками, безотносительно к уведомлениям о перегрузках. Мы заимствовали из RFC 2309 некоторые аспекты общего обсуждения сквозного контроля перегрузок.

В отличие от перечисленных выше RFC, этот документ является более общим в части принципов контроля перегрузок. Одним из важных факторов обеспечения работы Internet являются механизмы предотвращения перегрузок TCP. Хотя протокол TCP продолжает доминировать на транспортном уровне Internet, он не применяется повсеместно и все больше приложений по той или иной причине отказывается от TCP. Это относится не только к групповому (multicast), но и к индивидуальному трафику типа потоков multimedia, которым не требуются гарантии доставки, а также трафику DNS и протоколов маршрутизации, который представляет собой короткие передачи, играющие важнейшую роль в работе сети. Значительная часть такого трафика не использует никаких форм резервирования пропускной способности или сквозного контроля насыщения. Продолжающееся использование сквозного контроля насыщения обычным (best-effort) трафиком крайне важно для поддержки стабильности Internet.

В этом документе также рассмотрена общая роль IETF в стандартизации новых протоколов контроля перегрузок.

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

3. Разработка сквозного контроля перегрузок

3.1. Предотвращение коллапса насыщения

Архитектура протоколов Internet основана на сквозном обслуживании пакетов без организации явных соединений с использованием протокола IP. Преимущества работы без организации явных соединений в форме гибкости и отказоустойчивости продемонстрированы наглядно. Однако эти преимущества не достаются даром — требуется серьезная работа по проектированию сети для обеспечения высокого качества обслуживания при значительных нагрузках. Фактически, недостаточное внимание к динамической пересылке пакетов может приводить к деградации сервиса или «обвалу» Internet. Это явление впервые наблюдалось на ранней стадии расширения сети Internet в середине 1980-х [RFC896] и получило название «коллапс насыщения» (congestion collapse).

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

Исходное решение проблемы «обвала» Internet предложил Van Jacobson. Начиная с 1986, Jacobson разработал механизмы предотвращения перегрузок, которые стали обязательными для реализаций TCP [Jacobson88, RFC 2581]. Эти механизмы работают на хостах, заставляя соединения TCP «отступать» (back off) во время перегрузки. Мы говорим, что поток TCP «отвечает» за передачу сигналов о перегрузке из сети (например, пуетм отбрасывания пакетов). Именно эти алгоритмы предотвращения перегрузок TCP не позволяют коллапсировать современной сети Internet.

Однако на этом история не заканчивается. С 1988 года были выполнены важные исследования динамики роста Internet и этот рост продолжается до настоящего времени. Стало ясно, что механизмы предотвращения перегрузки TCP [RFC2581] необходимы и весьма мощны, но их не достаточно для обеспечения качественного сервиса в любых обстоятельствах. В дополнение к разработке новых механизмов контроля насыщения для конечных точек [RFC2357], создаются основанные на маршрутизации механизмы контроля перегрузок.

Важнейшей и до сих пор полностью не решенной проблемой является возможность коллапса Internet в будущем по причине того, что для потоков не используется сквозного контроля перегрузок. В RFC 896 [RFC896] еще в 1984 году предложено шлюзам детектировать и «подавлять» некорректно работающие хосты: «Отказ откликаться на сообщения ICMP Source Quench следует считать основанием для шлюза «отключить» соответствующий хост. Детектирование таких отказов является непростой задачей и представляет область для дальнейшего исследования». В современных публикациях все еще встречаются представления о том, что маршрутизаторы детектируют и «наказывают» потоки, для которых не реализован подходящий механизм сквозного контроля насыщения [FF99].

3.2. Беспристрастность

Кроме озабоченности коллапсом насыщения возникает беспокойство по части беспристрастности применительно к трафику best-effort. Поскольку TCP «схлопывается» во время перегрузок, множество соединений TCP могут проходить через общий сильно загруженный канал так, что пропускная способность будет делиться примерно поровну между «близко расположенными» потоками. Равномерность распределения полосы между потоками зависит от использования всеми потоками общего механизма контроля перегрузок. Для протокола TCP это означает соответствие алгоритмов контроля насыщения действующим спецификациям TCP [RFC793, RFC1122, RFC2581].

Важность вопроса беспристрастности по отношению к одновременным потокам растет по нескольким причинам. Во-первых, за счет масштабирования окна [RFC1323] отдельные потоки TCP могут получить высокую пропускную способность даже на путях со значительными задержками. Во-вторых, с ростом числа web-приложений у пользователей Internet возросли потребности в пропускной способности с малыми задержками, по сравнению с потребностями в сравнительно медленной передаче больших файлов в фоновом режиме. Рост трафика best-effort, для которого не применяется протокол TCP, дополнительно усиливает озабоченность беспристрастным распределением ресурсов между одновременными потоками обычного (best-effort) трафика в периоды перегрузок.

Популярность Internet вызвала рост числа реализаций TCP. Некоторые из них могут сталкиваться с отказами при реализации механизмов контроля перегрузок TCP в результате неполного соответствия [RFC2525]. В других может сознательно применяться более агрессивный контроль насыщения в части использования пропускной способности по сравнению с другими реализациями TCP — это позволяет разработчикам заявлять, что их TCP «быстрее других». Ожидаемым последствием появления таких реализаций является спираль все более агрессивных реализаций TCP или возрастающей агрессивности транспортных протоколов, что в конце концов приведет к возврату во времена, когда протоколов контроля перегрузок еще не было и хроническое насыщение было естественным состоянием Internet.

Есть общеизвестный способ повышения агрессивности даже без изменения транспортного протокола — просто сменить уровень дискретности — открывается множество «параллельных» соединений с одним узлом, как это делали в прошлом некоторые Web-браузеры. В результате вместо спирали роста агрессивности транспортных протоколов возникает спиральный рост агрессивности браузеров или других приложений.

Это поднимает вопрос о подходящей детализации потока, где термином «поток» обозначается уровень детализации, приемлемый для приложений контроля перегрузок и беспристрастного распределения ресурсов. В RFC 2309 сказано: «Есть несколько «естественных» ответов — 1) соединение TCP или UDP (адрес и порт отправителя — адрес и порт получателя), 2) пара «отправитель-получатель» или 3) данный порт отправителя и данный порт получателя. Мы предполагаем, что пара «отправитель-получатель» обеспечивает во многих случаях подходящий уровень детализации. Детализация потоков для контроля перегрузок, по крайней мере частично, является вопросом политики, который должен решаться в более широком сообществе IETF.»

Снова заимствуя из RFC 2309, мы используем термин TCP-совместимый для потока, который в условиях насыщения ведет себя, подобно потоку TCP. Такой поток отвечает за уведомление о перегрузке и в установившемся состоянии не использует более широкой полосы по сравнению с потоком TCP в сравнимых условиях (потери, RTT, MTU и т. п.)

Потоки удобно делить на три класса: (1) TCP-совместимые, (2) «безответственные», которые не снижают скорости при возникновении перегрузки и (3) потоки, которые реагируют на перегрузку иначе, нежели TCP. Два последних класса включают агрессивные потоки, которые создают значительные угрозы работе Internet, как описано ниже.

В дополнение к беспристрастности для установившихся состояний представляет интерес и беспристрастность на начальном этапе замедленного старта. Одной из проблем является побочное влияние на другие потоки со стороны потока с чрезмерно агрессивной процедурой slow-start. Производительность замедленного старта очень важна для короткоживущих потоков, которые передают лишь незначительный объем данных.

3.3. Оптимизация пропускной способности, задержки и потерь

В дополнение к предотвращению коллапса насыщения и решению проблемы беспристрастности использование сквозного контроля насыщения в потоке позволяет оптимизировать производительность этого потока в части пропускной способности, задержки и потерь. В некоторых случаях (например, в средах со статистическим мультплексированием) задержка и потери в потоке в значительной степени независимы от скорости этого потока. Таким образом, поток может использовать свой контроль перегрузок для снижения задержки и числа теряемых пакетов. Отметим однако, что в средах типа современной сети Internet с обслуживанием класса best-effort, вопросы коллапса насыщения и беспристрастности для одновременных потоков ограничивают доступные потоку возможности контроля перегрузки.

4. Роль процесса стандартизации

При стандартизации транспортного протокола принимаются во внимание не только аспекты совместимости (например, информационный обмен между оконечными узлами), но и механизмы, влияющие на производительность работы (например, снижение размера окна насыщения TCP в ответ на отбрасывание пакета). В то же время, конкретные детали реализации и другие аспекты транспортного протокола, не влияющие на взаимодействие и не нарушающие существенно производительность, не требуют стандартизации. Аспекты TCP, не требующие стандартизации, включают детали процедуры Fast Recovery после Fast Retransmit [RFC2582]. В приложении используются примеры TCP для более подробного рассмотрения роли процесса стандартизации в разработке контроля насыщения.

4.1. Разработка новых транспортных протоколов

В дополнение к вопросам предотвращения коллапса насыщения при стандартизации новых транспортных протоколов должна приниматься во внимание возможность «перетягивания одеяла» между конкурирующими протоколами. Например, в RFC 2357 [RFC2357] руководитель направления TSV и его аппарат описывают критерии публикации проектов Internet-Draft в качестве RFC для групповых протоколов с гарантированной доставкой. В документе [RFC2357] сказано: «Особое беспокойство IETF вызывает вопрос влияния гарантированной доставки группового трафика на остальной трафик Internet во время перегрузок и, в частности, конкуренция гарантированной доставки multicast-трафика с трафиком TCP… Задачей IETF является стимулирование исследований и внедрения гарантированной доставки группового трафика для обеспечения максимально быстрого удовлетворения потребности приложений в гарантированной доставке группового трафика, обеспечивая при этом защиту Internet от катастроф и коллапсов насыщения, которые могут быть связаны с широким распространением неподходящих механизмов гарантированной доставки группового трафика.»

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

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

4.2. Прикладные вопросы, влияющие на контроль перегрузок

Конкретная проблема браузеров, открывающих множество соединений с одним адресатом, была рассмотрена в RFC 2616 [RFC2616], где в параграфе 8.1.4 сказано: «Клиентам, использующим постоянные соединения, следует ограничивать количество одновременных соединений, которые могут поддерживаться для данного сервера. Однопользовательским клиентам не следует поддерживать более 2 одновременных соединений с сервером или прокси.»

4.3. Стандартизируемые новинки

Наиболее очевидными разработками в рамках IETF, которые будут влиять на развитие контроля перегрузок, являются дифференцированные и интегрированные услуги [RFC2212, RFC2475], а также явные уведомления о перегрузке (ECN) [RFC2481]. Однако некоторые менее значимые разработки также будут оказывать влияние на контроль перегрузок.

Одним из таких направлений является разработка контроля перегрузок в оконечных точках (ECM2) [BS00] для обеспечения общего состояния контроля насыщения для множества потоков от одного отправителя к одному получателю. Позволяя множеству одновременных соединений с одним адресатом функционировать, подобно одному потоку, менеджер перегрузок (Congestion Manager) может разрешить для некоторых соединений замедленный старт, что позволяет воспользоваться преимуществами наличия сквозной информации о состоянии насыщения на пути. Кроме того, использование менеджера перегрузок может устранить опасность открытия множества «сессий» контроля перегрузок для одной пары «отправитель-получатель» и может позволить браузерам создавать множество соединений с одним адресатом.

5. Описание коллапса насыщения

В этом разделе рассматриваются некоторые детали коллапса насыщения, вызываемого недоставленными пакетами, и показано как не контролирующие перегрузку потоки могут влиять на коллапс насыщения в Internet. Раздел в значительной мере базируется на работе [FF99].

Неформально коллапс насыщения возникает, когда рост нагрузки в сети приводит к уменьшению объема полезной работы, которую сеть способная выполнить. Как описано в разделе 3, коллапс насыщения был впервые отмечен в середине 1980-х годов [RFC896] и был обусловлен неоправданными повторами передачи пакетов TCP, которые еще находились в пути или уже были приняты получателем. Такой коллапс насыщения мы называем классическим. Этот коллапс стабилен и может приводить к многократному снижению пропускной способности сети [RFC896]. Проблема классического коллапса насыщения была в основном решена за счет улучшения таймеров и добавления механизмов контроля перегрузки в современных реализациях TCP [Jacobson88].

Другой возможный вариант коллапса насыщения связан с недоставленными пакетами. Такой коллапс возникает в тех случаях, когда пропускная способность сети впустую тратится на передачу пакетов, которые будут отброшены на пути к конечному получателю. Вероятно, это наиболее серьезная из нерешенных проблем, связанных с коллапсом насыщения, в современной сети Internet. Разные сценарии могут приводить к различному уровню коллапса в части доли пропускной способности сети, остающейся для продуктивной работы. Опасность этого вида коллапса обусловлена ростом числа приложений с открытым контуром (open-loop), не использующих сквозного контроля перегрузок. Еще большую опасность представляют обычные приложения, которые «увеличивают» скорость передачи в ответ на рост потерь (например, автоматически повышая уровень FEC3).

В таблице 1 приведены результаты сценария с возникновением коллапса насыщения из-за недоставленных пакетов, когда дефицитная пропускная способность расходуется на передачу пакетов, не доходящих до адресата. Для моделирования использовался сценарий с тремя потоками TCP и одним потоком UDP, передаваемыми через один сильно загруженный канал 1,5 Мбит/с. Для подключения всех узлов использовались соединения 10 Мбит/с, за исключением получателя потока UDP, который был подключен по каналу 128 Кбит/с, что составляет лишь 9% от пропускной способности общего канала. Когда скорость отправки пакетов UDP превышает 128 Кбит/с, значительная часть пакетов UDP будет отбрасываться на выходном порту в этот оконечный канал 128 Кбит/с.

Таблица 1. Модель с тремя потоками TCP и одним потоком UDP.

Скорость поступления UDP от отправителя

Полезная пропускная способность для UDP

Полезная пропускная способность для TCP

Общая полезная пропускная способность

0,7

0,7

98,5

99,2

1,8

1,7

97,3

99,1

2,6

2,6

96

98,6

5,3

5,2

92,7

97,9

8,8

8,4

87,1

95,5

10,5

8,4

84,8

93,2

13,1

8,4

81,4

89,8

17,5

8,4

77,3

85,7

26,3

8,4

64,5

72,8

52,6

8,4

38,1

46,4

58,4

8,4

32,8

41,2

65,7

8,4

28,5

36,8

75,1

8,4

19,7

28,1

87,6

8,4

11,3

19,7

105,1

8,4

3,4

11,8

131,5

8,4

2,4

10,7

В таблице 1 указана скорость поступления пакетов UDP от источника, полезная полоса UDP (пропускная способность, для реально доставленных данных), полезная полоса TCP (данные, доставленные пользователям TCP) и агрегатная полезная полоса для насыщенного канала 1,5 Мбит/с. В каждой строке указана доля от общей пропускной способности загруженного канала. По мере роста скорости источника UDP полезная пропускная способность TCP уменьшается почти линейно, а полезная пропускная способность UDP остается почти постоянной. Таким образом, рост потока UDP приводит лишь к ухудшению пропускной способности для TCP и падению суммарной полезной пропускной способности. На перегруженном канале поток UDP в конечном счете отнимает полосу, использовавшуюся для потоков TCP, и снижает пропускную способность сети в целом до весьма незначительной доли пропускной способности канала.

Таблица 1 показывает как отсутствие беспристрастности, так и коллапс насыщения. Как рассмотрено в [FF99], контроль перегрузок не является единственным способом обеспечения беспристрастности, планирование на уровне потоков в загруженных маршрутизаторах обеспечивает другой механизм гарантии беспристрастности. Однако, как было отмечено в [FF99], такое планирование не помогает предотвратить коллапс насыщения.

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

Вторым вариантом предотвращения коллапса по причине недоставки пакетов может быть гарантия со стороны сети доставки воспринятых перегруженным узлом пакетов конечному получателю [RFC2212, RFC2475]. Отметим, что выбор одного из этих вариантов не препятствует одновременному использованию другого варианта. Например, для части трафика может применяться сквозной контроль насыщения, а для остального — сетевые гарантии доставки.

6. Формы сквозного контроля перегрузок

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

6.1. Сквозной контроль для предотвращения коллапса насыщения

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

Хотелось бы отметить, что добавление явных уведомлений о перегрузке (ECN) в архитектуру IP само по себе не устраняет проблему коллапса насыщения для трафика best-effort. ECN позволяет маршрутизаторам устанавливать битовый флаг в заголовках пакетов для индикации перегрузки оконечным узлам вместо использования в качестве такого индикатора фактов отбрасывания пакетов. Однако маркировку ECN можно использовать вместо отбрасывания пакетов при возникновении незначительной перегрузки. При существенной перегрузке, когда буферное пространство маршрутизатора полностью заполнено, у него не остается иного выхода, кроме отбрасывания пакетов.

6.2. Сквозной контроль насыщения для беспристрастности с TCP.

Высказанные в [RFC2357] опасения относительно беспристрастности к TCP накладывают существенные ограничения на выбор решений для сквозного контроля перегрузок применительно к трафику best-effort. Среда с планированием на уровне отдельного потока изолирует потоки друг от друга и снимает требование совместимости механизма контроля насыщения с TCP. Среда с дифференцированными услугами, где потоки маркируются по неким классам diff-serv, будет выполнять планирование независимо от трафика best-effort и это может приводить к тому, что совместимость с TCP не будет требоваться для целого класса diff-serv. Аналогично, управляемая по ценам среда или класс diff-serv со своей ценовой парадигмой могут забыть о вопросе беспристрастности для TCP. Однако в современной среде Internet, где другой трафик best-effort может полностью занимать очереди FIFO пакетами TCP, отсутствие беспристрастности для TCP может приводить к тому, что один поток будет отнимать ресурсы остальных в моменты высокой загрузки, как было показано выше с таблице 1.

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

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

Значительная часть этого документа заимствована из предшествующих RFC, посвященных сквозному контролю перегрузок. Этот документ является попыткой обобщения идей, обсуждаемых в течение ряда лет с участием множества людей. В частности, следует отметить участников групп End-to-End Research и Reliable Multicast Research, а также направления Transport Area. Этот документ был существенно развит, благодаря дискуссиям и откликам в рабочей группе Transport Area. Отдельная благодарность Mark Allman за отклики на ранние версии этого документа.

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

[BS00] Balakrishnan H. and S. Seshan, «The Congestion Manager», Work in Progress5.

[DMKM00] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, «End-to-end Performance Implications of Slow Links», Work in Progress6.

[FF99] Floyd, S. and K. Fall, «Promoting the Use of End-to-End Congestion Control in the Internet», IEEE/ACM Transactions on Networking, August 1999. URL http://www.aciri.org/floyd/end2end-paper.html

[HPF00] Handley, M., Padhye, J. and S. Floyd, «TCP Congestion Window Validation», RFC 2861, June 2000.

[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM ’88, August 1988.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC896] Nagle, J., «Congestion Control in IP/TCP», RFC 896, January 1984.

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

[RFC1323] Jacobson, V., Braden, R. and D. Borman, «TCP Extensions for High Performance», RFC 1323, May 1992.

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

[RFC2212] Shenker, S., Partridge, C. and R. Guerin, «Specification of Guaranteed Quality of Service», RFC 2212, September 1997.

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

[RFC2357] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, «IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols», RFC 2357, June 1998.

[RFC2414] Allman, M., Floyd, S. and C. Partridge, «Increasing TCP’s Initial Window», RFC 2414, September 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[RFC2481] Ramakrishnan K. and S. Floyd, «A Proposal to add Explicit Congestion Notification (ECN) to IP», RFC 2481, January 1999.

[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J. and B. Volz, «Known TCP Implementation Problems», RFC 2525, March 1999.

[RFC2581] Allman, M., Paxson, V. and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

[RFC2582] Floyd, S. and T. Henderson, «The NewReno Modification to TCP’s Fast Recovery Algorithm», RFC 2582, April 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.

[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan, Mark Stemm, and Randy H. Katz, TCP Behavior of a Busy Internet Server: Analysis and Improvements, IEEE Infocom, March 1998. Доступен по ссылке http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz.

[TCPF98] Dong Lin and H.T. Kung, TCP Fast Recovery Strategies: Analysis and Improvements, IEEE Infocom, March 1998. Доступен по ссылке http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf.

9. Связанные с TCP вопросы

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

9.1. Замедленный старт

Отправитель TCP не может создать новое соединение путем передачи большого объема данных (например, размером в анонсированное получателем окно) сразу. Отправитель TCP ограничен небольшим начальным значением окна насыщения. В течение замедленного старта (slow-start) отправитель TCP может увеличивать свою скорость передачи не более, чем вдвое за каждый период кругового обхода. Процедура замедленного старта завершается при обнаружении перегрузки или в случае, когда размер окна насыщения на стороне отправителя становится больше порога замедленного старта ssthresh.

Проблема, способная повлиять на глобальный контроль перегрузок, и по этой причине явно рассматриваемая в процессе стандартизации, включает увеличение размера начального окна [RFC2414,RFC2581].

К проблемам, которые не будут решаться в процессе стандартизации и в общем случае отнесены к не требующим стандартизации, относятся такие вопросы, как использование (или отказ от него) задания темпа на основе скорости или механизмы ускоренного завершения процедуры slow-start до того, как размер окна достигнет ssthresh. Такие механизмы приводят к поведению процедуры slow-start, столь же или более консервативному по сравнению со стандартным TCP.

9.2. Аддитивный рост, мультипликативное снижение

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

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

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

9.3. Таймеры повтора передачи

Отправитель TCP устанавливает таймер повторной передачи, чтобы определять отбрасывание пакетов в сети. Когда отсчет этого таймера завершается, отправитель делает вывод о потере пакета, устанавливает для ssthresh значение в половину размера текущего окна и заново передает потерянный пакет. Если отсчет таймера завершается до того, как придет подтверждение доставки повторно переданного пакета, значение этого таймера для следующего отсчета увеличивается вдвое.

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

9.4. Ускоренный повтор и быстрое восстановление

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

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

Вопрос, который не был решен в процессе стандартизации и не считается требующим стандартизации, связан с предложением передавать «новый» или предположительно потерянный пакет в ответ на дубликат подтверждения или частичное подтверждение, если размер окна насыщения это позволяет. Примером этого может служить передача нового пакета в ответ на получение одного дубликата подтверждения, чтобы сохранить «часы подтверждений», если дальнейших подтверждений не будет. Такое предложение является примером благоприятного изменения, не затрагивающего интероперабельность и не влияющего на глобальный контроль насыщения, которое, следовательно, может быть реализовано производителями без вмешательства процесса стандартизации IETF (этот вопрос был фактически решен в [DMKM00], где сказано: «исследователи могут пожелать провести эксперименты с отправкой нового трафика в сеть при получении дубликатов подтверждений, как описано в [TCPB98] и [TCPF98]»).

9.5. Другие аспекты контроля перегрузок TCP

К другим вопросам контроля насыщения в TCP, не затронутым выше, относится восстановление после простоя или ограниченного приложением периода [HPF00].

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

Этот документ посвящен рискам, связанным с контролем перегрузок или его отсутствием. В параграфе 3.2 рассмотрена возможная утрата беспристрастности при отсутствии в одновременных потоках совместимых методов контроля насыщения, а раздел 5 посвящен опасностям, связанным с коллапсом насыщения в тех случаях, когда потоки не используют сквозного контроля перегрузок.

Поскольку в этом документе не предлагается каких-либо конкретных механизмов контроля насыщения, в него не требуется включать какие-то конкретные меры, связанные с контролем перегрузок. Однако следует отметить наличие широкого спектра вопросов безопасности, связанных с контролем перегрузок, которые нужно рассмотреть в документах IETF.

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

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

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


Адрес автора

Sally Floyd

AT&T Center for Internet Research at ICSI (ACIRI)

Phone: +1 (510) 642-4274 x189

EMail: floyd@aciri.org

URL: http://www.aciri.org/floyd/


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

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

nmalykh@gmail.com


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

Copyright (C) The Internet Society (2000). 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.


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

Финансирование функций RFC Editor обеспечено Internet Society.

1Explicit Congestion Notification — явное уведомление о насыщении (перегрузке).

2Endpoint Congestion Management.

3Упреждающий контроль ошибок.

4Additive-Increase Multiplicative-Decrease — адаптивный рост, мультипликативное снижение.

5Работа завершена и опубликована в RFC 3124. Прим. перев.

6Работа завершена и опубликована в RFC 3150. Прим. перев.