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

[rfc-editor@rfc-editor.org]

A new Request for Comments is now available in online RFC libraries.



        

        RFC 4920



        Title:      Crankback Signaling Extensions for MPLS 

                    and GMPLS RSVP-TE 

        Author:     A. Farrel, Ed.,

                    A. Satyanarayana, A. Iwata,

                    N. Fujita, G. Ash

        Status:     Standards Track

        Date:       July 2007

        Mailbox:    adrian@olddog.co.uk, 

                    asatyana@cisco.com, 

                    a-iwata@ah.jp.nec.com,  n-fujita@bk.jp.nec.com, 

                    gash5107@yahoo.com

        Pages:      38

        Characters: 88679

        Updates/Obsoletes/SeeAlso:   None



        I-D Tag:    draft-ietf-ccamp-crankback-06.txt



        URL:        http://www.rfc-editor.org/rfc/rfc4920.txt



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

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.  [STANDARDS TRACK]



This document is a product of the Common Control and Measurement Plane

Working Group of the IETF.



This is now a Proposed Standard Protocol.



STANDARDS TRACK: 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.



This announcement is sent to the IETF list and the RFC-DIST list.

Requests to be added to or deleted from the IETF distribution list

should be sent to IETF-REQUEST@IETF.ORG.  Requests to be

added to or deleted from the RFC-DIST distribution list should

be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.



Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 



help: ways_to_get_rfcs. For example:



        To: rfc-info@RFC-EDITOR.ORG

        Subject: getting rfcs



        help: ways_to_get_rfcs



Requests for special distribution should be addressed to either the

author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.



Submissions for Requests for Comments should be sent to

RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC

Authors, for further information.





The RFC Editor Team

USC/Information Sciences Institute



...