A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link
RFC 5330
Network Working Group JP. Vasseur, Ed.
Request for Comments: 5330 Cisco Systems, Inc
Category: Standards Track M. Meyer
BT
K. Kumaki
KDDI R&D Labs
A. Bonda
Telecom Italia
October 2008
A Link-Type sub-TLV to Convey the Number of
Traffic Engineering Label Switched Paths Signalled with
Zero Reserved Bandwidth across a Link
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
Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined
for Open Shortest Path First (OSPF) and Intermediate System to
Intermediate System (IS-IS) in the context of Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE), in order to advertise some
link characteristics such as the available bandwidth, traffic
engineering metric, administrative group, and so on. By making
statistical assumptions about the aggregated traffic carried onto a
set of TE Label Switched Paths (LSPs) signalled with zero bandwidth
(referred to as "unconstrained TE LSP" in this document), algorithms
can be designed to load balance (existing or newly configured)
unconstrained TE LSP across a set of equal cost paths. This requires
knowledge of the number of unconstrained TE LSPs signalled across a
link. This document specifies a new Link-type Traffic Engineering
sub-TLV used to advertise the number of unconstrained TE LSPs
signalled across a link.
Vasseur, et al. Standards Track [Page 1]
RFC 5330 Sub-TLV for Unconstrained TE LSP October 2008
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. Protocol Extensions .............................................4
3.1. IS-IS ......................................................4
3.2. OSPF .......................................................4
4. Elements of Procedure ...........................................5
5. IANA Considerations .............................................5
6. Security Considerations .........................................5
7. Acknowledgements ................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
1. Introduction
It is not uncommon to deploy MPLS Traffic Engineering for the sake of
fast recovery, relying on a local protection recovery mechanism such
as MPLS TE Fast Reroute (see [RFC4090]). In this case, a deployment
model consists of deploying a full mesh of TE LSPs signalled with
zero bandwidth (also referred to as unconstrained TE LSP in this
document) between a set of LSRs (Label Switching Routers) and
protecting these TE LSPs against link, SRLG (Shared Risk Link Group),
and/or node failures with pre-established backup tunnels. The
traffic routed onto such unconstrained TE LSPs simply follows the IGP
shortest path, but is protected with MPLS TE Fast Reroute. This is
because the TE LSP computed by the path computation algorithm (e.g.,
CSPF) will be no different than the IGP (Interior Gateway Protocol)
shortest path should the TE metric be equal to the IGP metric.
When a reoptimization process is triggered for an existing TE LSP,
the decision on whether to reroute that TE LSP onto a different path
is governed by the discovery of a lower cost path satisfying the
constraints (other metrics, such as the percentage of reserved
bandwidth or the number of hops, can also be used). Unfortunately,
metrics such as the path cost or the number of hops may be
ineffective in various circumstances. For example, in the case of a
symmetrical network with ECMPs (Equal Cost Multi-Paths), if the
network operator uses unconstrained TE LSP, this may lead to a poorly
Show full document text