Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
RFC 4206
|
| Document |
Type |
|
RFC - Proposed Standard
(October 2005; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4206 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Scott Bradner
|
|
Send notices to |
|
(None)
|
Network Working Group K. Kompella
Request for Comments: 4206 Y. Rekhter
Category: Standards Track Juniper Networks
October 2005
Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE)
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.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
To improve scalability of Generalized Multi-Protocol Label Switching
(GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by
creating a hierarchy of such LSPs. A way to create such a hierarchy
is by (a) a Label Switching Router (LSR) creating a Traffic
Engineering Label Switched Path (TE LSP), (b) the LSR forming a
forwarding adjacency (FA) out of that LSP (by advertising this LSP as
a Traffic Engineering (TE) link into the same instance of ISIS/OSPF
as the one that was used to create the LSP), (c) allowing other LSRs
to use FAs for their path computation, and (d) nesting of LSPs
originated by other LSRs into that LSP (by using the label stack
construct).
This document describes the mechanisms to accomplish this.
Kompella & Rekhter Standards Track [Page 1]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
Table of Contents
1. Overview ........................................................2
2. Specification of Requirements ...................................3
3. Routing Aspects .................................................4
3.1. Traffic Engineering Parameters .............................4
3.1.1. Link Type (OSPF Only) ...............................5
3.1.2. Link ID (OSPF Only) .................................5
3.1.3. Local and Remote Interface IP Address ...............5
3.1.4. Local and Remote Link Identifiers ...................5
3.1.5. Traffic Engineering Metric ..........................5
3.1.6. Maximum Bandwidth ...................................5
3.1.7. Unreserved Bandwidth ................................5
3.1.8. Resource Class/Color ................................5
3.1.9. Interface Switching Capability ......................6
3.1.10. SRLG Information ...................................6
4. Other Considerations ............................................6
5. Controlling FA-LSPs Boundaries ..................................7
5.1. LSP Regions ................................................7
6. Signalling Aspects ..............................................8
6.1. Common Procedures ..........................................8
6.1.1. RSVP-TE .............................................8
6.1.2. CR-LDP ..............................................9
6.2. Specific Procedures .......................................10
6.3. FA-LSP Holding Priority ...................................11
7. Security Considerations ........................................11
8. Acknowledgements ...............................................12
9. Normative References ...........................................12
10. Informative References ........................................13
1. Overview
An LSR uses Generalized MPLS (GMPLS) TE procedures to create and
maintain an LSP. The LSR then may (under local configuration
control) announce this LSP as a Traffic Engineering (TE) link into
the same instance of the GMPLS control plane (or, more precisely, its
ISIS/OSPF component) as the one that was used to create the LSP. We
call such a link a "forwarding adjacency" (FA). We refer to the LSP
as the "forwarding adjacency LSP", or just FA-LSP. Note that an FA-
LSP is both created and used as a TE link by exactly the same
instance of the GMPLS control plane. Thus, the concept of an FA is
applicable only when an LSP is both created and used as a TE link by
exactly the same instance of the GMPLS control plane. Note also that
an FA is a TE link between two GMPLS nodes whose path transits zero
or more (G)MPLS nodes in the same instance of the GMPLS control
plane.
Kompella & Rekhter Standards Track [Page 2]
Show full document text