A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
RFC 5152
Networking Working Group JP. Vasseur, Ed.
Request for Comments: 5152 Cisco Systems, Inc.
Category: Standards Track A. Ayyangar, Ed.
Juniper Networks
R. Zhang
BT
February 2008
A Per-Domain Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs). In this document, a domain refers to a collection of
network elements within a common sphere of address management or path
computational responsibility such as Interior Gateway Protocol (IGP)
areas and Autonomous Systems.
Per-domain computation applies where the full path of an inter-domain
TE LSP cannot be or is not determined at the ingress node of the TE
LSP, and is not signaled across domain boundaries. This is most
likely to arise owing to TE visibility limitations. The signaling
message indicates the destination and nodes up to the next domain
boundary. It may also indicate further domain boundaries or domain
identifiers. The path through each domain, possibly including the
choice of exit point from the domain, must be determined within the
domain.
Vasseur, et al. Standards Track [Page 1]
RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. General Assumptions .............................................4
3.1. Common Assumptions .........................................4
3.2. Example of Topology for the Inter-Area TE Case .............6
3.3. Example of Topology for the Inter-AS TE Case ...............7
4. Per-Domain Path Computation Procedures ..........................8
4.1. Example with an Inter-Area TE LSP .........................11
4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
4.2. Example with an Inter-AS TE LSP ...........................13
4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
5. Path Optimality/Diversity ......................................14
6. Reoptimization of an Inter-Domain TE LSP .......................15
6.1. Contiguous TE LSPs ........................................15
6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
6.3. Path Characteristics after Reoptimization .................17
7. Security Considerations ........................................17
8. Acknowledgements ...............................................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
1. Introduction
The requirements for inter-domain Traffic Engineering (inter-area and
inter-AS TE) have been developed by the Traffic Engineering Working
Group and have been stated in [RFC4105] and [RFC4216]. The framework
for inter-domain MPLS Traffic Engineering has been provided in
[RFC4726].
Some of the mechanisms used to establish and maintain inter-domain TE
LSPs are specified in [RFC5151] and [RFC5150].
This document exclusively focuses on the path computation aspects and
defines a method for establishing inter-domain TE LSPs where each
node in charge of computing a section of an inter-domain TE LSP path
is always along the path of such a TE LSP.
When the visibility of an end-to-end complete path spanning multiple
domains is not available at the Head-end LSR (the LSR that initiated
the TE LSP), one approach described in this document consists of
Show full document text