[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                             J. Gao
INTERNET-DRAFT                                                    J. Dai
Intended Status: Proposed Standard
Expires: October 30, 2020
                                                   Fiberhome Telecom LTD
                                                          April 30, 2020


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



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 October 30, 2020               [Page 1]


INTERNET DRAFT     State-updating mechanism in RSVP-TE    April 30, 2020


   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 October 30, 2020               [Page 2]


INTERNET DRAFT     State-updating mechanism in RSVP-TE    April 30, 2020


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
   message is lost in transmission.  Standard RSVP [RFC2205] recovers
   from a lost message via RSVP refresh messages.  In the face of
   transmission loss of RSVP messages, the end-to-end latency of RSVP
   signaling is tied to the refresh interval of the node(s) experiencing
   the loss.  When end-to-end signaling is limited by the refresh
   interval, the delay incurred in the establishment or the change of a
   reservation may be beyond the range of what is acceptable for some
   applications.

   This document proposes to disable RSVP refresh messages to solve
   soft-state scaling problems. The reliable message delivery mechanism
   specified in [RFC2961] states that "Nodes receiving a non-out of
   order message containing a MESSAGE_ID object with the ACK_Desired
   flag set, SHOULD respond with a MESSAGE_ID_ACK object.". When RSVP
   refresh messages are disabled, the time to deallocate resources
   after a tear message is lost is an issue. To solve this problem,
   MUST make use of the Hello session based on the Node-ID
   ([RFC3209][RFC4558]) for detection of RSVP-TE signaling adjacency
   failures. MUST implement coupling the state of individual LSPs
   with the state of the corresponding RSVP-TE signaling adjacency.
   When an RSVP-TE speaker detects RSVP-TE signaling adjacency
   failure, the speaker MUST act as if all the Path and Resv states
   learned via the failed signaling adjacency have timed out. To
   avoid compatibility problems, a flag bit in the RSVP message
   header is extended to disable RSVP refresh messages.

2.  Terminology

2.1.   Terms Used in This Document



Gao, et al.              Expires October 30, 2020               [Page 3]


INTERNET DRAFT     State-updating mechanism in RSVP-TE    April 30, 2020


    Refresh messages: represent previously advertised state and contain
      exactly the same objects and same information as a previously
      transmitted message, and are sent over the same path.  Only Path and
      Resv messages can be refresh messages.  Refresh messages are
      identical to the corresponding previously transmitted message, with
      some possible exceptions.

   Trigger messages: Trigger messages are those RSVP messages that
     advertise state or any other information not previously
     transmitted. Trigger messages include messages advertising new
     state, a route change that alters a reservation path, or a
     modification to an existing RSVP session or reservation.

2.2.  Abbreviations

   The following abbreviations are used in this document:
     RSVP: Resource ReserVation Protocol.
     RSVP-TE: Resource ReserVation Protocol - Traffic Engineering.

3  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4  State-updating mechanism in RSVP for MPLS network

   To indicate support for the refresh message disable extensions, an
   additional capability bit is added to the common RSVP header, which
   is defined in [RFC2205].



















Gao, et al.              Expires October 30, 2020               [Page 4]


INTERNET DRAFT     State-updating mechanism in RSVP-TE    April 30, 2020


       0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Vers | Flags |   Msg Type    |         RSVP Checksum         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Send_TTL    |  (Reserved)   |         RSVP Length           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Figure 1 RSVP header

       Flags: 4 bits

            0x02: Refresh message disable

              When set, indicates that this node is willing and capable of
              supporting the refresh message disable extensions described in
              this document.  This bit is meaningful only between RSVP neighbors.

      Nodes supporting the refresh message disable extensions must also
      take care to recognize when a next hop stops sending RSVP messages
      with the Refresh-Message-Disable bit set.  To cover this case,
      nodes supporting the refresh message disable extensions MUST
      examine the flags field of each received RSVP message.  If the flag
      changes from indicating support to indicating non-support then,
      unless configured otherwise, MUST NOT stop state refreshes to that
      neighbor.

      Note: Refresh messages can only be disabled if the neighbor node must
      support both reliable RSVP message delivery in [RFC2961] and Hello message
      extension in [RFC3209] [RFC4558]. When RSVP refresh messages are disabled,
      both reliable RSVP message delivery in [RFC2961] and Hello message
      extension in [RFC3209] [RFC4558] must be enabled.

4.1.  Reliable RSVP message delivery

      Refresh messages are used to both synchronize state between RSVP neighbors
      and to recover from lost RSVP messages. The reliability and latency problem
      occurs when a non-refresh RSVP message is lost in transmission.

      An implementation that supports the techniques discussed in this document
      must support the functionality described in [RFC2961] as follows:

      o  It MUST support reliable delivery of Path/Resv and the
         corresponding Tear/Err messages (as specified in Section 4 of
         [RFC2961]).

      o  It MUST support retransmission of all unacknowledged RSVP-TE
         messages using exponential backoff (as specified in Section 6 of
         [RFC2961]).



Gao, et al.              Expires October 30, 2020               [Page 5]


INTERNET DRAFT     State-updating mechanism in RSVP-TE    April 30, 2020


 4.2.  Hello Extension for tear message

      When RSVP refresh messages are disabled, the time to deallocate resources
      after a tear message is lost is an issue. To solve this problem, MUST make
      use of the Hello session based on the Node-ID ([RFC3209][RFC4558]) for
      detection of RSVP-TE signaling adjacency failures.

      An implementation that supports the techniques discussed in this document
      must support the functionality as follows:

       o  MUST make use of the Hello session based on the Node-ID ([RFC3209]
         [RFC4558]) for detection of RSVP-TE signaling adjacency failures.
         A default value of 9 seconds is RECOMMENDED by this document for
         the configurable node hello interval (as opposed to the default
         value of 5 milliseconds proposed in Section 5.3 of [RFC3209]).
         The Hello message format is as follows:
               <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
                                 <HELLO>
         The HELLO Object formats is as follows:


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Src_Instance                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Dst_Instance                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 2 Format for hello object
        Src_Instance: 32 bits

         a 32 bit value that represents the sender's instance.  The
         advertiser maintains a per neighbor representation/value.  This
         value MUST change when the sender is reset, when the node reboots,
         or when communication is lost to the neighboring node and
         otherwise remains the same.  This field MUST NOT be set to zero
         (0).

        Dst_Instance: 32 bits

         The most recently received Src_Instance value received from the
         neighbor.  This field MUST be set to zero (0) when no value has
         ever been seen from the neighbor.


       o  MUST implement coupling the state of individual LSPs with the
         state of the corresponding RSVP-TE signaling adjacency.  When an
         RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the
         speaker MUST act as if all the Path and Resv states learned via
         the failed signaling adjacency have timed out.



Gao, et al.              Expires October 30, 2020               [Page 6]


INTERNET DRAFT     State-updating mechanism in RSVP-TE    April 30, 2020


5.  Security Considerations

   This document does not introduce additional security requirements and
   mechanisms. Implementation of the mechanism follows the security
   specification of [RFC2205].


6.  IANA Considerations

   This document makes no IANA requests.


7.  Normative References


   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

   [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, DOI 10.17487/RFC2961, April 3001,
              <https://www.rfc-editor.org/info/rfc2961>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC4558]  Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou,
              "Node-ID Based Resource Reservation Protocol (RSVP) Hello:
              A Clarification Statement", RFC 4558,
              DOI 10.17487/RFC4558, June 2006,
              <https://www.rfc-editor.org/info/rfc4558>.

   [RFC8370]  Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D.,
              and T. Saad, "Techniques to Improve the Scalability of
              RSVP-TE Deployments", RFC 8402, DOI 10.17487/RFC8370,
              May 2018, <https://www.rfc-editor.org/info/rfc8370>.











Gao, et al.              Expires October 30, 2020               [Page 7]


INTERNET DRAFT     State-updating mechanism in RSVP-TE    April 30, 2020


Authors' Addresses


   Jun Gao
     Fiberhome Telecom LTD.
     Gaoxin 4th Road 6#
     Wuhan, Hubei 430079
     China

     Email: jgao@fiberhome.com

   Jinyou Dai
     Fiberhome Telecom LTD.
     Gaoxin 4th Road 6#
     Wuhan, Hubei 430079
     China

     Email: djy@fiberhome.com



































Gao, et al.              Expires October 30, 2020               [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/