RFC3785 · Использование метрики протокола внутренней маршрутизации (IGP) в качестве второй метрики MPLS Traffic Engineering (TE)
Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric
RFC 3785 описывает распространённую практику использования существующей метрики IGP как альтернативы метрике TE при маршрутизации MPLS TE-туннелей с учётом ограничений. Это позволяет оптимизировать разные TE LSP по разным критериям: например, LSP для данных — по пропускной способности, а голосовые LSP — по задержке распространения. Дополнительные расширения или изменения протоколов не требуются: используется выбор между уже рекламируемыми метриками IGP и TE. Практика ограничена двумя метриками, применима только к каналам с IGP-смежностью, требует пригодности метрики IGP как одной из двух метрик для маршрутизации с учётом ограничений и требует передачи выбранной метрики при распределённом вычислении пути. Документ фиксирует существующие реализации маршрутизаторов и практики развёртывания.
IETF · RFC
Назначение
Описать, как применять метрику IGP в качестве второй метрики TE для маршрутизации MPLS TE LSP с различными требованиями к оптимизации.
Применение
Применяйте в MPLS TE-сети, когда для каждого TE LSP на головном LSR можно выбрать метрику IGP либо TE, а метрика IGP пригодна как одна из двух метрик для маршрутизации с учётом ограничений. Настройте одну метрику для одного набора LSP, а другую — для LSP с иными требованиями. В некоторых сценариях миграции для предотвращения нарушений работы существующих TE-LSP может потребоваться обновить все головные маршрутизаторы до новой реализации; один из возможных сценариев затем переводит существующие LSP на метрику IGP, изменяет TE-метрику и настраивает нужное подмножество LSP на вторую метрику.
Это BCP 87, документирующий практику и не вводящий расширений протоколов. Подход поддерживает выбор только из двух метрик, применяется лишь там, где метрика IGP пригодна как одна из них, и не применяется к Forwarding Adjacencies. Он не рекомендует одновременно использовать метрики TE и IGP при вычислении пути одного LSP; RFC 3785 не обновляет и не отменяет другие RFC.
Официальная английская аннотация
This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
{
"id": "RFC3785",
"number": 3785,
"title_en": "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric",
"title_ru": "Использование метрики протокола внутренней маршрутизации (IGP) в качестве второй метрики MPLS Traffic Engineering (TE)",
"summary_ru": "RFC 3785 описывает распространённую практику использования существующей метрики IGP как альтернативы метрике TE при маршрутизации MPLS TE-туннелей с учётом ограничений. Это позволяет оптимизировать разные TE LSP по разным критериям: например, LSP для данных — по пропускной способности, а голосовые LSP — по задержке распространения. Дополнительные расширения или изменения протоколов не требуются: используется выбор между уже рекламируемыми метриками IGP и TE. Практика ограничена двумя метриками, применима только к каналам с IGP-смежностью, требует пригодности метрики IGP как одной из двух метрик для маршрутизации с учётом ограничений и требует передачи выбранной метрики при распределённом вычислении пути. Документ фиксирует существующие реализации маршрутизаторов и практики развёртывания.",
"purpose_ru": "Описать, как применять метрику IGP в качестве второй метрики TE для маршрутизации MPLS TE LSP с различными требованиями к оптимизации.",
"use_ru": "Применяйте в MPLS TE-сети, когда для каждого TE LSP на головном LSR можно выбрать метрику IGP либо TE, а метрика IGP пригодна как одна из двух метрик для маршрутизации с учётом ограничений. Настройте одну метрику для одного набора LSP, а другую — для LSP с иными требованиями. В некоторых сценариях миграции для предотвращения нарушений работы существующих TE-LSP может потребоваться обновить все головные маршрутизаторы до новой реализации; один из возможных сценариев затем переводит существующие LSP на метрику IGP, изменяет TE-метрику и настраивает нужное подмножество LSP на вторую метрику.",
"full_translation_path": "translations/rfc3785.html",
"full_translation_checked_at": "2026-10-04",
"full_translation_source_sha256": "95db04d6776800dc94fe34882fd7d00705f019d07b9be21083359481c9525434",
"architect_note_ru": "Это BCP 87, документирующий практику и не вводящий расширений протоколов. Подход поддерживает выбор только из двух метрик, применяется лишь там, где метрика IGP пригодна как одна из них, и не применяется к Forwarding Adjacencies. Он не рекомендует одновременно использовать метрики TE и IGP при вычислении пути одного LSP; RFC 3785 не обновляет и не отменяет другие RFC.",
"topics_ru": [],
"translation_state": "reviewed",
"verification_level": "primary_source_reviewed",
"verification_level_ru": "Проверено по первичному тексту и реестру RFC Editor",
"verification_note_ru": "Полный текст и карточка независимо сверены с первоисточником. 2026-10-04",
"abstract_en": "This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.",
"authors": [
"F. Le Faucheur",
"R. Uppili",
"A. Vedrenne",
"P. Merckx",
"T. Telkamp"
],
"organizations": [],
"publication_date": "2004-05-01",
"current_status": "BEST CURRENT PRACTICE",
"current_status_ru": "Лучшая современная практика",
"publication_status": "BEST CURRENT PRACTICE",
"publication_status_ru": "Лучшая современная практика",
"lifecycle": "active",
"lifecycle_ru": "Действующий",
"stream": "IETF",
"stream_ru": "IETF",
"area": "sub",
"area_ru": "sub",
"working_group": "tewg",
"source_draft": "draft-ietf-tewg-te-metric-igp-02",
"page_count": 8,
"doi": "10.17487/RFC3785",
"keywords": [
"IGP",
"Interior Gateway Protocol",
"MPLS",
"MultiProtocol Label Switching",
"TE",
"Traffic Engineering",
"link",
"bandwidth router"
],
"formats": [
"TXT",
"HTML"
],
"relations": {
"obsoletes": [],
"obsoleted_by": [],
"updates": [],
"updated_by": [],
"is_also": [
"BCP87"
],
"see_also": []
},
"links": {
"info": "https://www.rfc-editor.org/info/rfc3785/",
"html": "https://www.rfc-editor.org/rfc/rfc3785.html",
"txt": "https://www.rfc-editor.org/rfc/rfc3785.txt",
"datatracker": "https://datatracker.ietf.org/doc/rfc3785/"
}
}