datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
RFC 4920

Document type: RFC - Proposed Standard (July 2007; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4920 (Proposed Standard)
Responsible AD: Ross Callon
Send notices to: ccamp-chairs@tools.ietf.org

Network Working Group                                     A. Farrel, Ed.
Request for Comments: 4920                            Old Dog Consulting
Category: Standards Track                               A. Satyanarayana
                                                     Cisco Systems, Inc.
                                                                A. Iwata
                                                               N. Fujita
                                                         NEC Corporation
                                                                  G. Ash
                                                                    AT&T
                                                               July 2007

       Crankback Signaling Extensions for MPLS and GMPLS RSVP-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 IETF Trust (2007).

Abstract

   In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date.  This means
   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
   requests may be blocked by links or nodes without sufficient
   resources.  Crankback is a scheme whereby setup failure information
   is returned from the point of failure to allow new setup attempts to
   be made avoiding the blocked resources.  Crankback can also be
   applied to LSP recovery to indicate the location of the failed link
   or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in
   "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
   Functional Description", RFC 3473.  These extensions mean that the
   LSP setup request can be retried on an alternate path that detours
   around blocked links or nodes.  This offers significant improvements

Farrel, et al.              Standards Track                     [Page 1]
RFC 4920             Crankback Signaling Extensions            July 2007

   in the successful setup and recovery ratios for LSPs, especially in
   situations where a large number of setup requests are triggered at
   the same time.

Table of Contents

Section A: Problem Statement

1. Introduction and Framework ......................................4
   1.1. Background .................................................4
   1.2. Control Plane and Data Plane Separation ....................5
   1.3. Repair and Recovery ........................................5
   1.4. Interaction with TE Flooding Mechanisms ....................6
   1.5. Terminology ................................................7
2. Discussion: Explicit versus Implicit Re-Routing Indications .....7
3. Required Operation ..............................................8
   3.1. Resource Failure or Unavailability .........................8
   3.2. Computation of an Alternate Path ...........................8
        3.2.1. Information Required for Re-Routing .................9
        3.2.2. Signaling a New Route ...............................9
   3.3. Persistence of Error Information ..........................10
   3.4. Handling Re-Route Failure .................................11
   3.5. Limiting Re-Routing Attempts ..............................11
4. Existing Protocol Support for Crankback Re-Routing .............11
   4.1. RSVP-TE ...................................................12
   4.2. GMPLS-RSVP-TE .............................................13

Section B: Solution

5. Control of Crankback Operation .................................13
   5.1. Requesting Crankback and Controlling In-Network
        Re-Routing ................................................13
   5.2. Action on Detecting a Failure .............................14
   5.3. Limiting Re-Routing Attempts ..............................14
        5.3.1. New Status Codes for Re-Routing ....................15
   5.4. Protocol Control of Re-Routing Behavior ...................15
6. Reporting Crankback Information ................................15
   6.1. Required Information ......................................15
   6.2. Protocol Extensions .......................................16
   6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs .................20
        6.3.1. General Principles .................................20

[include full document text]