Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance
О документе
Рабочая группа сети G. Choudhury, ред.
Запрос комментариев: 4222 AT&T
BCP: 112 Октябрь 2005
Категория: Лучшая современная практика
Приоритетная обработка отдельных пакетов OSPF версии 2
и предотвращение перегрузки
1. Введение
В настоящем документе OSPF означает OSPFv2 [Ref1]. Описанные здесь методы
улучшения масштабируемости и стабильности также могут применяться к
OSPFv3 [Ref2], но для этого потребуются дальнейшее изучение и опыт
эксплуатации.
В крупной сети, работающей по протоколу OSPF, иногда может происходить
одновременное или почти одновременное обновление большого числа объявлений
о состоянии канала, или LSA. Это особенно характерно при использовании
расширения OSPF для управления трафиком [Ref3], которое может значительно
увеличить число LSA в сети. Мы называем такое событие штормом LSA; оно
может быть вызвано незапланированным отказом или плановым событием
технического обслуживания. Отказ может иметь аппаратный, программный или
процедурный характер.
Шторм LSA приводит к высокой загрузке процессора и памяти на маршрутизаторе,
вследствие чего входящие пакеты задерживаются или отбрасываются. Задержанные
подтверждения (сверх значения таймера повторной передачи) приводят к
повторным передачам, а задержанные пакеты Hello (сверх интервала
router-dead) приводят к объявлению смежностей с соседями неработоспособными.
Повторные передачи и дополнительное создание LSA приводят к дальнейшему
потреблению процессора и памяти, по существу вызывая петлю положительной
обратной связи, которая в предельном случае может привести сеть в
нестабильное состояние.
Значение по умолчанию для таймера повторной передачи составляет 5 секунд,
а для интервала router-dead — 40 секунд. Однако в последнее время возник
большой интерес к существенному сокращению времени сходимости OSPF. В рамках
этого плана были предложены гораздо более короткие (менее секунды) интервалы
Hello и router-dead [Ref4]. В таком сценарии будет более вероятно, что
пакеты Hello будут задерживаться сверх интервала router-dead во время
перегрузки сети, вызванной штормом LSA.
Для улучшения масштабируемости и стабильности сетей мы рекомендуем меры по
приоритизации критически важных пакетов OSPF и предотвращению перегрузки.
Подробности рекомендаций приведены в разделе 2. В [Ref13] описано
имитационное исследование, количественно характеризующее явление перегрузки
и его влияние. В нём также исследуются несколько рекомендаций и показано,
что они действительно улучшают масштабируемость и стабильность сетей,
использующих протокол OSPF. [Ref13] предоставляется по запросу при
обращении к редактору или одному из авторов.
В приложении A более подробно объясняются сценарии шторма LSA, их влияние,
а также приводится несколько реальных примеров штормов управляющих
сообщений. Приложение B содержит список переменных, используемых в
рекомендациях, и их примеры значений. Приложение C содержит несколько
дополнительных рекомендаций и предложений со сходными целями.
2. Рекомендации
Приведённые ниже рекомендации предназначены для улучшения масштабируемости
и стабильности крупных сетей, использующих протокол OSPF. В периоды
перегрузки сети они уменьшили бы количество повторных передач,
предотвратили бы объявление смежности неработоспособной из-за задержки
пакетов Hello сверх RouterDeadInterval и предприняли бы другие меры по
предотвращению перегрузки. Рекомендации не упорядочены, кроме того, что
рекомендацию 2 следует реализовывать только в случае, если рекомендация 1
не реализована.
(1) Классифицируйте все пакеты OSPF на два класса: класс «высокого
приоритета», включающий пакеты OSPF Hello и пакеты Link State
Acknowledgement, и класс «низкого приоритета», включающий все прочие
пакеты. Классификация выполняется путём изучения заголовка пакета OSPF.
При приёме пакета от соседа и при передаче пакета соседу старайтесь
обработать пакет «высокого приоритета» раньше пакета «низкого
приоритета».
Приоритетная обработка при передаче может привести к тому, что пакеты
OSPF от соседа будут приняты не по порядку. Если используется
Cryptographic Authentication (AuType = 2) (как определено в [Ref1]),
то последовательные принятые действительные пакеты OSPF от соседа
должны иметь неубывающий «Cryptographic sequence number». Для
соблюдения этого требования мы рекомендуем, чтобы при использовании
Cryptographic Authentication (AuType = 2) [Ref1] приоритетная обработка
не выполнялась у передатчика. Это позволит избежать прибытия пакетов к
приёмнику не по порядку. Однако после завершения обработки безопасности
у приёмника (включая проверку номера последовательности) пакеты OSPF
могут помещаться в очередь «высокого приоритета» или очередь «низкого
приоритета» в зависимости от их класса и обрабатываться
соответствующим образом. Польза от приоритетной обработки явно выше при
отсутствии Cryptographic Authentication, поскольку в таком случае
приоритизация может быть реализована как у передатчика, так и у
приёмника. Однако даже при Cryptographic Authentication будет полезно
иметь приоритизацию только у приёмника (после обработки безопасности).
(2) Если рекомендация 1 не может быть реализована, то сбрасывайте таймер
неактивности для смежности всякий раз, когда по этой смежности получен
любой одноадресный пакет OSPF или любой пакет OSPF, отправленный на
AllSPFRouters по двухточечной линии связи, вместо сброса таймера
неактивности только при получении пакета Hello. Таким образом, OSPF
объявлял бы смежность неработоспособной, только если в течение периода,
равного или превышающего RouterDeadInterval, по этой смежности не было
получено одноадресных пакетов OSPF или пакетов OSPF, отправленных на
AllSPFRouters по двухточечной линии связи. Причина, по которой это
предложение не рекомендуется совместно с рекомендацией 1, состоит в
предотвращении возможных нежелательных побочных эффектов. Одним из
таких эффектов является задержка обнаружения неработоспособного
состояния смежности в случае, когда пакеты Hello высокого приоритета не
принимаются, но таймер неактивности сбрасывается другими устаревшими
пакетами в очереди низкого приоритета.
(3) Используйте алгоритм экспоненциальной отсрочки для определения значения
интервала повторной передачи LSA (RxmtInterval). Пусть R(i)
представляет значение RxmtInterval, используемое при i-й повторной
передаче LSA. Используйте следующий алгоритм для вычисления R(i).
R(1) = Rmin
R(i+1) = Min(KR(i),Rmax) for i>=1
где K, Rmin и Rmax — константы, а функция Min(.,.) представляет
минимальное значение двух своих аргументов. Примерами значений K, Rmin
и Rmax могут быть соответственно 2, 5 и 40 секунд. Обратите внимание,
что пример значения Rmin, начального интервала повторной передачи,
совпадает с примером значения RxmtInterval в [Ref1].
Эта рекомендация основана на наблюдении, что во время события перегрузки
сети, вызванного управляющими сообщениями, одним из главных источников
поддержания перегрузки являются повторные передачи LSA. Использование
алгоритма экспоненциальной отсрочки для интервала повторной передачи
LSA снижает частоту повторных передач LSA, пока сеть испытывает
перегрузку (во время которой более вероятны многократные повторные
передачи одного и того же LSA). Это, в свою очередь, помогает сети
выйти из состояния перегрузки.
(4) Неявное обнаружение перегрузки и действия на его основе: если на
маршрутизаторе имеется перегрузка управляющими сообщениями, его соседи
не знают об этом явно. Однако они могут неявно обнаружить её по числу
неподтверждённых LSA, направленных этому маршрутизатору. Если это число
превышает определённую «верхнюю отметку», то частоту, с которой LSA
отправляются этому маршрутизатору, следует постепенно снижать с помощью
механизма экспоненциальной отсрочки, но не ниже определённой минимальной
частоты. В дальнейшем, если число неподтверждённых LSA, направленных
этому маршрутизатору, опустится ниже определённой «нижней отметки», то
частоту отправки LSA этому маршрутизатору следует постепенно повышать,
вновь с помощью механизма экспоненциальной отсрочки, но не выше
определённой максимальной частоты. Полный алгоритм приведён ниже.
Обратите внимание, что этот алгоритм применяется независимо к каждому
соседу и только для одноадресных LSA, отправляемых соседу, либо LSA,
отправляемых на AllSPFRouters по двухточечной линии связи.
Пусть:
U(t) = Число неподтверждённых LSA, направленных соседу в момент времени t.
H = Верхняя отметка (в единицах числа неподтверждённых
LSA).
L = Нижняя отметка (в единицах числа неподтверждённых LSA).
G(t) = Интервал между отправкой последовательных LSA соседу в момент
времени t.
F = Коэффициент, на который указанный выше интервал увеличивается во
время перегрузки и уменьшается после выхода из перегрузки.
T = Минимальное время, которое должно пройти, прежде чем существующий
интервал будет рассматриваться для изменения.
Gmin = Минимально допустимое значение интервала.
Gmax = Максимально допустимое значение интервала.
Приведённое ниже уравнение показывает, как должен изменяться интервал
после истечения времени T с момента последнего изменения:
_
|
| Min(FG(t),Gmax) if U(t+T) > H
G(t+T) = | G(t) if H >= U(t+T) >= L
| Max(G(t)/F,Gmin) if U(t+T) < L
|_
Min(.,.) и Max(.,.) представляют соответственно минимальное и
максимальное значения двух аргументов.
Примеры значений различных параметров алгоритма таковы: H = 20, L = 10,
F = 2, T = 1 секунда, Gmin = 20 ms, Gmax = 1 секунда.
Рекомендации 3 и 4 обе замедляют отправку LSA перегруженным соседям на
основе неявного обнаружения перегрузки, но имеют существенные различия.
Рекомендация 3 постепенно замедляет последовательные повторные передачи
одного и того же LSA, тогда как рекомендация 4 постепенно замедляет все
LSA (новые или повторно передаваемые), направляемые перегруженному
соседу.
(5) Ограничение числа одновременно устанавливаемых смежностей: если
маршрутизатор пытается одновременно установить смежность с большим
числом своих соседей, то это может вызвать серьёзную перегрузку из-за
действий по синхронизации базы данных и рассылке LSA. Рекомендуется,
чтобы в такой ситуации одновременно устанавливалось не более «n»
смежностей. После успешного установления подмножества смежностей могут
устанавливаться новые смежности, если число одновременно устанавливаемых
смежностей не превышает «n». Подходящее значение «n» будет зависеть от
вычислительной мощности маршрутизатора, общей полосы пропускания,
доступной для трафика плоскости управления, и задержки распространения.
Значение «n» следует сделать настраиваемым.
При наличии ограничения важным вопросом является порядок формирования
смежностей. Мы рекомендуем политику First Come First Served (FCFS),
основанную на порядке поступления запросов на формирование смежности.
Запросы могут поступать от соседей либо генерироваться самим
маршрутизатором. Среди самостоятельно сгенерированных запросов для
определения порядка, в котором должны выполняться запросы, может
использоваться список приоритетов. Однако после начала процесса
формирования смежности он не должен прерываться, за исключением
необычных обстоятельств, таких как ошибки или истечение времени
ожидания.
В некоторых приведённых выше рекомендациях мы ссылаемся на соединения
точка-точка. Эти ссылки также должны включать случаи, когда широковещательная
сеть должна рассматриваться как соединение точка-точка с точки зрения
IP-маршрутизации [Ref5]
3. Соображения безопасности
Эта памятка не создаёт никаких новых проблем безопасности для протокола
OSPF.
4. Благодарности
Мы хотели бы выразить признательность за поддержку и полезные замечания
председателям рабочей группы OSPF Rohit Dube, Acee Lindem и John Moy;
директорам области маршрутизации Alex Zinin и Bill Fenner; а также
рецензентам IESG. Мы выражаем признательность Vivek Dube, Mitchell Erblich,
Mike Fox, Tony Przygienda и Krishna Rao за замечания к предыдущим версиям
документа. Мы также выражаем признательность Margaret Chiosi, Elie Francis,
Jeff Han, Beth Munson, Roshan Rao, Moshe Segal, Mike Wardlow и Pat Wirth за
сотрудничество и поддержку в наших усилиях по повышению масштабируемости
сетей на основе протоколов состояния каналов.
5. Нормативные ссылки
[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Ref2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
6. Справочные ссылки
[Ref3] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[Ref4] C. Alaettinoglu, V. Jacobson and H. Yu, "Towards Millisecond
IGP Convergence", Work in Progress.
[Ref5] N. Shen, A. Lindem, J. Yuan, A. Zinin, R. White and S.
Previdi, "Point-to-point operation over LAN in link-state
routing protocols", Work in Progress.
[Ref6] Pappalardo, D., "AT&T, customers grapple with ATM net
outage", Network World, February 26, 2001.
[Ref7] "AT&T announces cause of frame-relay network outage," AT&T
Press Release, April 22, 1998.
[Ref8] Cholewka, K., "MCI Outage Has Domino Effect", Inter@ctive
Week, August 20, 1999.
[Ref9] Jander, M., "In Qwest Outage, ATM Takes Some Heat", Light
Reading, April 6, 2001.
[Ref10] A. Zinin and M. Shand, "Flooding Optimizations in Link-State
Routing Protocols", Work in Progress.
[Ref11] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction in
Stable Topologies", RFC 4136, July 2005.
[Ref12] G. Ash, G. Choudhury, V. Sapozhnikova, M. Sherif, A. Maunder,
V. Manral, "Congestion Avoidance & Control for OSPF
Networks", Work in Progress.
[Ref13] G. Choudhury, G. Ash, V. Manral, A. Maunder and V.
Sapozhnikova, "Prioritized Treatment of Specific OSPF Packets
and Congestion Avoidance: Algorithms and Simulations", AT&T
Technical Report, August 2003.
[Ref14] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition
of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers", RFC 2474, December 1998.
Приложение A. Шторм LSA: причины и воздействие
Шторм LSA может быть инициирован по многим причинам. Ниже приведены
некоторые примеры:
(a) один или несколько отказов каналов вследствие обрывов волоконно-оптических
линий,
(b) один или несколько отказов маршрутизаторов по некоторой причине, например
из-за сбоя программного обеспечения или некоторого типа бедствия (включая
отключение электроэнергии) в офисном комплексе, где размещено много
маршрутизаторов,
(c) неустойчивость состояния канала/маршрутизатора,
(d) необходимость отключить, а позднее вернуть в работу много маршрутизаторов
во время обновления программного/аппаратного обеспечения,
(e) почти синхронное периодическое обновление LSA с периодом 1800 секунд для
подмножества LSA,
(f) обновление всех LSA в системе при изменении версии программного
обеспечения,
(g) введение в OSPF большого числа внешних маршрутов вследствие процедурной
ошибки,
(h) изменения Router ID, вызывающие повторное создание большого числа LSA
(возможно, также удаление LSA в зависимости от реализации).
В дополнение к LSA, созданным непосредственно в результате отказов
канала/маршрутизатора, могут существовать и другие косвенные LSA. Одним из
примеров в сетях MPLS являются LSA инженерии трафика [Ref3], создаваемые на
других каналах вследствие существенных изменений зарезервированной полосы
пропускания. Они возникают вследствие перенаправления Label Switched Paths
(LSP), которые отказали во время отказа канала/маршрутизатора. Шторм LSA
вызывает высокую загрузку процессора и памяти процессора маршрутизатора,
из-за чего входящие пакеты задерживаются или отбрасываются. Задержанные
подтверждения (сверх значения таймера повторной передачи) приводят к
повторным передачам, а задержанные пакеты Hello (сверх интервала Router-Dead)
приводят к объявлению каналов неработающими. Событие отказа магистрального
канала вызывает создание router LSA его оконечными маршрутизаторами. Если
LSA инженерии трафика используются для каждого канала, то LSA этого типа
также будут создаваться оконечными маршрутизаторами и, возможно, также в
других местах вследствие существенных изменений зарезервированных полос
пропускания на других каналах, вызванных отказом и перенаправлением LSP,
первоначально использовавших отказавшую магистраль. В конечном счёте, когда
канал восстановится, это также вызовет дополнительные router LSA и LSA
инженерии трафика.
Повторные передачи и дополнительное создание LSA приводят к дальнейшему
использованию процессора и памяти, по сути образуя петлю положительной
обратной связи. Мы определяем размер шторма LSA как число LSA в исходном
шторме, не учитывая дополнительные LSA, возникающие из-за описанной выше
петли обратной связи. Если шторм LSA слишком велик, то упомянутая выше петля
положительной обратной связи может быть достаточно большой, чтобы
неопределённо долго поддерживать высокую загрузку процессора и памяти на
многих маршрутизаторах в сети, тем самым приводя сеть в неустойчивое
состояние. В прошлом сообщалось о событиях отказа сети в IP- и ATM-сетях,
использующих протоколы состояния каналов, такие как OSPF, Intermediate System
to Intermediate System (IS-IS), Private Network-Network Interface (PNNI) или
некоторые проприетарные варианты. См., например, [Ref6-Ref9]. Во многих из
этих примеров крупномасштабное распространение LSA или других аналогичных
управляющих сообщений (либо естественное, либо вызванное некоторой ошибкой
или ненадлежащей процедурой) было частично или полностью ответственным за
неустойчивость и отказ сети.
В [Ref13] используется имитационная модель, показывающая, что существует
определённый порог размера шторма LSA, выше которого сеть может проявлять
неустойчивое поведение, вызванное большим числом повторных передач, отказами
каналов вследствие пропущенных пакетов Hello и последующими восстановлениями
каналов. Также показано, что размер шторма LSA, вызывающий неустойчивость,
может быть существенно увеличен путём предоставления приоритетной обработки
пакетам Hello и LSA Acknowledgment, а также с помощью алгоритма экспоненциальной
задержки для определения интервала повторной передачи LSA. Если невозможно
установить приоритет пакетов Hello, то сброс таймера неактивности при получении
любых допустимых пакетов OSPF также может обеспечить тот же эффект. Кроме
того, если мы устанавливаем приоритет пакетам Hello, то даже когда сеть
работает несколько выше порога устойчивости, каналы не объявляются
неработающими вследствие пропущенных пакетов Hello. Это означает, что, хотя
из-за большого числа повторных передач имеется перегрузка плоскости управления,
плоскость данных остаётся работоспособной и новые LSA не создаются (помимо
LSA в исходном шторме и обновлений). Эти наблюдения подтверждают первые три
рекомендации в разделе 2. Авторы этого документа также провели моделирование,
чтобы подтвердить, что другие рекомендации в разделе 2 помогают избежать
перегрузки и обеспечивают плавный выход из перегруженного состояния.
Можно утверждать, что проблему масштабируемости крупных сетей следует решать
исключительно иерархическим разделением сети на несколько областей, чтобы
распространение LSA оставалось локализованным внутри областей. Однако этот
подход увеличивает сложность управления и проектирования сети и может привести
к менее оптимальной маршрутизации между областями. Кроме того, Autonomous
System External (ASE) LSA распространяются по всей AS, и это может быть
проблемой при их большом количестве. Более того, через области может
потребоваться распространять большое число summary LSA, и их количество
значительно увеличилось бы, если бы
для обеспечения надёжности использовалось несколько Area Border Routers.
Следовательно, важно позволить сети увеличиваться до настолько большого
размера, насколько возможно в пределах одной области.
Рекомендации в документе синергичны с более широким набором предложений по
повышению масштабируемости и устойчивости. [Ref10] предлагает уменьшение
накладных расходов распространения в случае, когда более одного интерфейса
подключается к одному и тому же соседу. [Ref11] предлагает механизм для
значительного сокращения обновлений LSA в стабильных топологиях.
[Ref12] предлагает широкий набор механизмов управления перегрузкой и
восстановления после отказов (некоторые из этих идей рассматриваются в этом
документе, но [Ref12] содержит и другие идеи, не рассмотренные здесь).
Приложение B. Список переменных и значений
F = Коэффициент, на который увеличивается интервал между отправкой
последовательных LSA соседу во время перегрузки и уменьшается после
выхода из перегрузки (используется в рекомендации 4). Пример значения: 2.
G(t) = Интервал между отправкой последовательных LSA соседу в момент времени t
(используется в рекомендации 4).
Gmax = Максимально допустимое значение интервала между отправкой
последовательных LSA соседу (используется в рекомендации 4). Пример
значения: 1 секунда.
Gmin = Минимально допустимое значение интервала между отправкой
последовательных LSA соседу (используется в рекомендации 4). Пример
значения: 20 мс.
H = Верхняя отметка (в единицах числа неподтверждённых LSA). Превышение
этой отметки вызвало бы возможное увеличение интервала между отправкой
последовательных LSA соседу. (используется в рекомендации 4). Пример
значения: 20.
K = Мультипликативная константа, используемая при увеличении значения
RxmtInterval, применяемого во время последовательных повторных передач
одного и того же LSA (используется в рекомендации 3). Пример значения: 2.
L = Нижняя отметка (в единицах числа неподтверждённых LSA). Падение ниже
этой отметки вызвало бы возможное уменьшение интервала между отправкой
последовательных LSA соседу. (используется в рекомендации 4). Пример
значения: 10.
n = Верхний предел числа смежностей, одновременно переводимых в состояние
установления (используется в рекомендации 5).
R(i) = Значение RxmtInterval, используемое при i-й повторной передаче LSA
(используется в рекомендации 3).
Rmax = Максимально допустимое значение RxmtInterval (используется в
рекомендации 3). Пример значения: 40 секунд.
Rmin = Минимально допустимое значение RxmtInterval (используется в
рекомендации 3). Пример значения: 5 секунд.
T = Минимальное время, которое должно пройти, прежде чем существующий
интервал между отправкой последовательных LSA соседу будет рассмотрен
для изменения (используется в рекомендации 4). Пример значения: 1
секунда.
U(t) = Число неподтверждённых LSA для соседа в момент времени t (используется
в рекомендации 4).
Приложение C. Другие рекомендации и предложения
(1) Явная маркировка: В разделе 2 мы рекомендовали классифицировать пакеты
OSPF в классы приоритета "high" и "low" на основе проверки заголовка
пакета OSPF. В некоторых случаях (в частности, у получателя) эта проверка
может быть вычислительно затратной. Альтернативой было бы использование
различных настроек полей TOS/Precedence для двух классов приоритета.
[Ref1] рекомендует устанавливать поле TOS в 0, а поле Precedence — в 6
для всех пакетов OSPF. Мы рекомендуем те же настройки для пакетов OSPF
с приоритетом "low" и другие настройки для пакетов OSPF с приоритетом
"high", чтобы иметь возможность классифицировать их раздельно без
необходимости проверять заголовок пакета OSPF. Ниже приведены два примера:
Пример 1: Для пакетов с приоритетом "low" установить поле TOS в 0,
а поле Precedence — в 6; для пакетов с приоритетом "high"
установить поле TOS в 4, а поле Precedence — в 6.
Пример 2: Для пакетов с приоритетом "low" установить поле TOS в 0,
а поле Precedence — в 6; для пакетов с приоритетом "high"
установить поле TOS в 0, а поле Precedence — в 7.
Обратите внимание, что биты TOS/Precedence были переопределены Diffserv
(RFC 2474, [Ref14]). Также обратите внимание, что предложенные выше
различные настройки полей TOS/Precedence должны быть согласованы только
между системами на канале. Эту рекомендацию не требуется выполнять, если
заголовок пакета OSPF легко проверить и тем самым отдельно классифицировать
пакеты с приоритетами "high" и "low".
(2) Дальнейшая приоритизация пакетов OSPF: Помимо пакетов,
обозначенных как имеющие «высокий» приоритет в Рекомендации 1
раздела 2, может возникнуть потребность в дальнейшем разделении
приоритетов среди пакетов OSPF с «низким» приоритетом. Мы
рекомендуем использовать три класса приоритета: «высокий»,
«средний» и «низкий». При получении пакета от соседа и при
передаче пакета соседу старайтесь обрабатывать пакет «высокого
приоритета» раньше пакетов «среднего» и «низкого» приоритета, а
пакет «среднего» приоритета — раньше пакетов «низкого»
приоритета. Пакеты «высокого» приоритета определены в
Рекомендации 1 раздела 2. Ниже мы приводим два возможных примера
пакетов «среднего» приоритета. Все пакеты OSPF, не отнесённые к
«высокому» или «среднему» приоритету, имеют «низкий» приоритет.
Если используется криптографическая аутентификация (AuType = 2)
(как определено в [Ref1]), то приоритетная обработка должна
предоставляться только на стороне получателя и после обработки
безопасности, но не на стороне отправителя, поскольку это может
привести к поступлению пакетов не по порядку и нарушить
требования «Autype = 2».
Один пример пакета «среднего» приоритета — пакет Database
Description (DBD) от ведомого маршрутизатора (во время процесса
синхронизации базы данных), используемый как подтверждение.
Второй пример — LSA, содержащий информацию об изменении
топологии внутри области (это может инициировать вычисление SPF
и перемаршрутизацию Label Switched Paths, поэтому быстрая
обработка этого пакета может улучшить время сходимости
OSPF/Label Distribution Protocol (LDP)). Однако, если стоимость
обработки для идентификации и отдельной постановки в очередь LSA
в этом примере считается высокой, то реализатор может принять
решение не делать этого.
(3) Обработка большого количества очисток LSA: Иногда некоторые
события в сети, например изменения идентификатора маршрутизатора,
могут приводить к большому количеству повторных порождений LSA и
очисток LSA. В таком сценарии можно рассмотреть обработку LSA в
другом порядке, например обработку очисток LSA раньше порождений
LSA. Однако мы не рекомендуем обработку LSA не по порядку по
нескольким причинам. Во-первых, определение типа LSA до
постановки в очередь может быть вычислительно затратным.
Обработка не по порядку также может вызвать трудноуловимые
ошибки. Мы не хотим рекомендовать существенное изменение
парадигмы обработки LSA для относительно редкого события, такого
как изменение идентификатора маршрутизатора. Однако маршрутизатор
с изменяющимся идентификатором может постепенно очищать старые
LSA, не вызывая шторма.