Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric
О документе
Рабочая группа по сетям F. Le Faucheur
Запрос комментариев: 3785 R. Uppili
BCP: 87 Cisco Systems, Inc.
Категория: Лучшая современная практика A. Vedrenne
P. Merckx
Equant
T. Telkamp
Global Crossing
Май 2004
Использование метрики протокола внутренней маршрутизации (IGP)
в качестве второй метрики MPLS Traffic Engineering (TE)
1. Введение
Протоколы маршрутизации Interior Gateway Protocol (IGP) (OSPF и IS-IS),
равно как и протоколы сигнализации MultiProtocol Label Switching (MPLS)
(RSVP-TE и CR-LDP), были расширены (как определено в [ISIS-TE],
[OSPF-TE], [RSVP-TE] и [CR-LDP]) для поддержки функциональности Traffic
Engineering (TE), определённой в [TE-REQ].
Эти расширения протоколов маршрутизации IGP в настоящее время включают
объявление единственной дополнительной метрики MPLS TE, используемой для
маршрутизации на основе ограничений туннелей TE.
Однако цель управления трафиком состоит в оптимизации использования и
производительности сети. Поэтому представляется уместным, чтобы размещение
туннелей TE могло оптимизироваться согласно различным критериям
оптимизации. Например, некоторые поставщики услуг хотят выполнять
управление трафиком разных классов обслуживания раздельно, чтобы каждый
класс обслуживания передавался по отдельному туннелю TE. Одним из
побудительных примеров для этого является применение различных политик
быстрого восстановления к разным классам обслуживания. Другой пример
мотивации состоит в использовании раздельной маршрутизации на основе
ограничений для достижения различных целей качества обслуживания (QoS)
каждого класса обслуживания. В зависимости от целей QoS может
потребоваться либо (a) обеспечение посредством маршрутизации на основе
ограничений различных ограничений пропускной способности для различных
классов обслуживания, как определено в [DS-TE], либо (b) оптимизация по
иной метрике при маршрутизации на основе ограничений, либо (c) и то и
другое. В этом документе обсуждается, как при маршрутизации на основе
ограничений может быть достигнута оптимизация по иной метрике.
Наиболее распространённый сценарий использования иной метрики
предусматривает оптимизацию метрики, отражающей задержку (главным образом
задержку распространения), при маршрутизации на основе ограничений TE
Label Switched Paths (LSP), которые будут передавать голос, при
одновременной оптимизации более обычной метрики (например, отражающей
пропускную способность канала) при маршрутизации на основе ограничений TE
LSP, которые будут передавать данные.
Могли бы быть определены дополнительные расширения протокола IGP, чтобы в
IGP можно было объявлять несколько метрик TE (как, например, предложено в
[METRICS]), и они, таким образом, были бы доступны маршрутизации на основе
ограничений для оптимизации по иной метрике. Однако этот документ
описывает, как оптимизация по иной метрике может быть достигнута уже
сегодня существующими реализациями и развёртываниями без каких-либо
дополнительных расширений IGP сверх [ISIS-TE] и [OSPF-TE], фактически
используя метрику IGP как «вторую» метрику TE.
2. Распространённая практика
В текущих развёртываниях MPLS TE сетевые администраторы часто хотят,
чтобы маршрутизация на основе ограничений TE LSP, переносящих трафик
данных, основывалась на той же метрике, что и метрика, используемая для
маршрутизации по кратчайшему пути. В этом случае данная практика позволяет
алгоритму маршрутизации на основе ограничений, работающему на Head-End
LSR, использовать метрику IGP, объявленную в IGP, для вычисления путей
для TE LSP данных вместо объявленной метрики TE. Метрика TE затем может
использоваться для передачи
другой метрики (например, метрики, основанной на задержке), которую
алгоритм маршрутизации на основе ограничений на Head-End LSR может
использовать для вычисления пути для TE LSP с иными требованиями
(например, Voice TE LSP).
В некоторых сетях сетевые администраторы настраивают метрику IGP на
значение, учитывающее задержку распространения в канале. В таком случае
данная практика позволяет алгоритму маршрутизации на основе ограничений,
работающему на Head-End LSR, использовать метрику IGP, объявленную в IGP,
для вычисления путей для чувствительных к задержке TE LSP (например, Voice
TE LSP) вместо объявленной метрики TE. Метрика TE затем может
использоваться для передачи другой метрики (например, метрики на основе
пропускной способности), которую алгоритм маршрутизации на основе
ограничений может использовать для вычисления путей для TE LSP данных.
В более общем случае метрика TE может использоваться для переноса любой
произвольной метрики, которая может быть полезна для маршрутизации на
основе ограничений множества LSP, которым необходима оптимизация по иной
метрике, нежели метрика IGP.
2.1. Практика реализации Head-End LSR
Head-End LSR реализует текущую практику следующим образом:
(i) Позволяет настраивать для каждого подлежащего маршрутизации TE LSP,
должна ли алгоритмом маршрутизации на основе ограничений
использоваться метрика IGP или метрика TE.
(ii) Позволяет алгоритму маршрутизации на основе ограничений использовать
либо метрику TE, либо метрику IGP в зависимости от указанной выше
конфигурации для рассматриваемого TE-LSP.
2.2. Практика развёртывания сети
Поставщик услуг развёртывает эту практику следующим образом:
(i) Настраивает на каждом релевантном канале метрику TE так, чтобы она
отражала ту метрику, которая подходит (например, метрику на основе
задержки) для маршрутизации на основе ограничений некоторых LSP как
альтернативная метрика метрике IGP.
(ii) Настраивает для каждого TE LSP, должен ли этот LSP маршрутизироваться
на основе ограничений согласно метрике TE или метрике IGP.
2.3. Ограничения
Практика, описанная в этом документе, имеет следующие ограничения:
(i) она позволяет маршрутизировать туннели TE только по одной из двух
метрик (то есть не может позволить маршрутизировать туннели TE по
одной из трёх или большего числа метрик). В будущем при необходимости
могли бы быть определены расширения (например, такие как предложенные
в [METRICS]) для ослабления этих ограничений, но это находится вне
области действия данного документа.
(ii) она может использоваться только там, где метрика IGP подходит в
качестве одной из двух метрик, используемых для маршрутизации на
основе ограничений (то есть она не может позволить маршрутизировать
туннели TE по одной из двух метрик, одновременно позволяя IGP SPF
основываться на третьей метрике). В будущем при необходимости могли
бы быть определены расширения (например, такие как предложенные в
[METRICS]) для ослабления этих ограничений, но это находится вне
области действия данного документа.
(iii) она может использоваться только на каналах, поддерживающих смежность
IGP, чтобы для канала действительно объявлялась метрика IGP.
Например, эта практика не может использоваться для Forwarding
Adjacencies (см. [LSP-HIER]).
Следует отметить, что, как и [METRICS], эта практика не рекомендует, чтобы
метрика TE и метрика IGP использовались одновременно при вычислении пути
для данного LSP. Известно, что это NP-полная задача.
2.4. Совместимость
Когда вычисление пути полностью выполняется Head-End (например, при
внутриобластных операциях с вычислением пути на Head-end), эта практика не
создаёт никаких проблем совместимости между LSR, поскольку использование
той или иной метрики является вопросом, полностью локальным для Head-End
LSR.
Когда в вычислении пути участвует иной компонент, помимо Head-End
(например, при межобластных операциях, где вычисление пути разделено между
Head-End и Area Boundary Routers или сервером вычисления пути), эта
практика требует, чтобы метрика, по которой следует выполнять оптимизацию,
сигнализировалась вместе с прочими ограничениями (пропускной способностью,
сходством) для LSP. См. [PATH-COMP] как пример предложения о том, как
сигнализировать, по какой метрике следует выполнять оптимизацию, другому
компоненту, участвующему в вычислении пути, когда RSVP-TE используется в
качестве протокола для сигнализации информации о вычислении пути.
3. Соображения миграции
Поставщикам услуг необходимо рассмотреть, как выполнить миграцию с текущей
реализации на новую, поддерживающую эту практику.
Хотя головные маршрутизаторы действуют независимо друг от друга, некоторые
сценарии миграции могут потребовать обновления всех головных маршрутизаторов
до новой реализации во избежание каких-либо нарушений существующих TE-LSP
до того, как TE сможет фактически использовать две метрики. Причина состоит
в том, что от маршрутизаторов с текущей реализацией ожидается, что они
всегда будут использовать метрику TE для маршрутизации на основе
ограничений всех туннелей; поэтому, когда метрика TE перенастраивается так,
чтобы отражать «вторую метрику» (например, метрику на основе задержки) на
каналах сети, все TE-LSP будут маршрутизироваться на основе метрики
«второй метрики», тогда как намерение может состоять в том, чтобы на основе
«второй метрики» маршрутизировались только TE-LSP, явно настроенные таким
образом.
Возможный сценарий миграции мог бы выглядеть так:
1) обновить программное обеспечение на всех головных маршрутизаторах сети
для поддержки этой практики.
2) изменить конфигурацию TE-LSP на головных маршрутизаторах, чтобы для
маршрутизации на основе ограничений использовать метрику IGP (например,
основанную на пропускной способности), а не метрику TE.
3) настроить метрику TE на каналах так, чтобы она отражала «вторую
метрику» (например, основанную на задержке).
4) изменить конфигурацию LSP подмножества TE-LSP, которые необходимо
маршрутизировать на основе ограничений с использованием «второй
метрики» (например, основанной на задержке), и/или создать новые TE-LSP
с такой конфигурацией.
Желательно, чтобы шаг 2 был ненарушающим работу (то есть маршрутизация LSP
никак не будет затронута, а передача данных не будет прервана) при изменении
конфигурации LSP для использования «метрики IGP», пока фактическое значение
«метрики IGP» и «метрики TE» одинаково на каждом канале в момент
перенастройки LSP (как имело бы место на шаге 2 приведённого выше сценария
миграции, который предполагал, что метрика TE первоначально была равна
метрике IGP).
4. Соображения безопасности
Практика, описанная в этом документе, не создаёт специфических проблем
безопасности помимо присущих существующему TE. Они обсуждаются в
соответствующих разделах по безопасности [TE-REQ], [RSVP-TE] и [CR-LDP].
5. Благодарность
Этот документ выиграл от обсуждений с Jean-Philippe Vasseur.
6.1. Нормативные ссылки
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, Requirements for Traffic Engineering over MPLS,
RFC 2702, September 1999.
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE),
RFC 3784, May 2004.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
Girish, M., Gray, E., Heinanen, J., Kilty, T. and A.
Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
January 2002.
6.1. Информативные ссылки
[METRICS] Fedyk, et al., "Multiple Metrics for Traffic Engineering
with IS-IS and OSPF", Work in Progress, November 2000.
[DIFF-TE] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003.
[PATH-COMP] Vasseur, et al., "RSVP Path computation request and reply
messages", Work in Progress, June 2002.
[LSP-HIER] Kompella, et al., "LSP Hierarchy with Generalized MPLS
TE", Work in Progress, September 2002.
7. Адреса авторов
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
Телефон: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Ramesh Uppili
Cisco Systems,
2000 Innovation Drive
Kanata,
ONTARIO,
Canada - K2K 3E8
Телефон: 01-613-254 4578
Email: ruppili@cisco.com
Alain Vedrenne
Equant
Heraklion, 1041 route des Dolines, BP347
06906 Sophia Antipolis Cedex
FRANCE
Телефон: +33 4 92 96 57 22
EMail: alain.vedrenne@equant.com
Pierre Merckx
Equant
1041 route des Dolines - BP 347
06906 SOPHIA ANTIPOLIS Cedex
FRANCE
Телефон: +33 (0)492 96 6454
EMail: pierre.merckx@equant.com
Thomas Telkamp
Global Crossing, Ltd.
Croeselaan 148
NL-3521CG Utrecht
The Netherlands
Телефон: +31 30 238 1250
EMail: telkamp@gblx.net
8. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004). Настоящий документ
подпадает под действие прав, лицензий и ограничений, содержащихся в
BCP 78, и, за исключением предусмотренного в нём, авторы сохраняют
все свои права.
Настоящий документ и содержащаяся в нём информация предоставляются
на условиях «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА
ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ),
THE INTERNET SOCIETY И THE INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ИЛИ
ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.