State-updating mechanism in RSVP-TE for MPLS network
draft-gao-mpls-teas-rsvpte-state-update-00

Document Type Active Internet-Draft (individual)
Last updated 2019-11-02
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                             J. Gao
INTERNET-DRAFT                                                    J. Dai
Intended Status: Proposed Standard                                      
Expires: May 5, 2020                                                    
                                                   Fiberhome Telecom LTD
                                                        November 3, 2019

         State-updating mechanism in RSVP-TE for MPLS network 
               draft-gao-mpls-teas-rsvpte-state-update-00

Abstract

   RSVP-TE has the following advantages: source routing capability,   
   and the ability to reserve resources hop by hop along the LSP path.

      RSVP takes a "soft state" approach to managing the reservation  
   state in routers and hosts. The use of Refresh messages to cover   
   many possible failures has resulted in a number of operational   
   problems.  One problem relates to scaling, another relates to the   
   reliability and latency of RSVP Signaling.

      This document describes a number of mechanisms that can be used to
     reduce processing overhead requirements of refresh messages. These 
     extension present no backwards compatibility issues.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the  
   provisions of BCP 78 and BCP 79.

      Internet-Drafts are working documents of the Internet Engineering 
    Task Force (IETF).  Note that other groups may also distribute  
   working documents as Internet-Drafts.  The list of current Internet- 
    Drafts is at https://datatracker.ietf.org/drafts/current/.

      Internet-Drafts are draft documents valid for a maximum of six
   months   and may be updated, replaced, or obsoleted by other
   documents at any   time.  It is inappropriate to use Internet-Drafts
   as reference   material or to cite them other than as "work in
   progress."

Copyright and License Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
 

Gao, et al.              Expires April 30, 2020                 [Page 1]
INTERNET DRAFT     Using NETCONF over QUIC connection   November 1, 2019

   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.   Terms Used in This Document . . . . . . . . . . . . . . .  3
     2.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  4
   3  Requirements Language . . . . . . . . . . . . . . . . . . . . .  4
   4  State-updating mechanism in RSVP for MPLS network . . . . . . .  4
     4.1.  Reliable RSVP message delivery . . . . . . . . . . . . . .  5
      4.2.  Hello Extension for tear message  . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6 IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  7
   7  Normative References  . . . . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

 

Gao, et al.              Expires April 30, 2020                 [Page 2]
INTERNET DRAFT     Using NETCONF over QUIC connection   November 1, 2019

1.  Introduction

   Standard RSVP [RFC2205] maintains state via the generation of RSVP  
   refresh messages.  Refresh messages are used to both synchronize  
   state between RSVP neighbors and to recover from lost RSVP messages. 
    The use of Refresh messages to cover many possible failures has  
   resulted in a number of operational problems.  One problem relates to
     scaling, another relates to the reliability and latency of RSVP  
   Signaling.

      The scaling problems are linked to the resource requirements (in  
   terms of processing and memory) of running RSVP.  The resource  
   requirements increase proportionally with the number of sessions.  
   Each session requires the generation, transmission, reception and  
   processing of RSVP Path and Resv messages per refresh period.  
   Supporting a large number of sessions, and the corresponding volume  
   of refresh messages, presents a scaling problem.

      The reliability and latency problem occurs when a non-refresh RSVP
Show full document text