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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 12

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
   load balanced traffic; indeed, several paths between a source and a
   destination of a TE LSP may exist that have the same cost, and the