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

RFC 3034, Страница 19 из 22

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

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

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

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

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

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

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

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

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

Страница 19 из 22

2007 - 2022 © Русские переводы RFC, IETF, ISOC.