Skip to main content

RSVP-TE Scalability - Recommendations
draft-beeram-mpls-rsvp-te-scaling-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Vishnu Pavan Beeram , Ina Minei , Yakov Rekhter , Ebben Aries , Dante Pacella
Last updated 2015-03-07
Replaced by draft-beeram-teas-rsvp-te-scaling-rec
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-beeram-mpls-rsvp-te-scaling-00
Network Working Group                               Vishnu Pavan Beeram 
 Internet Draft                                         Juniper Networks 
 Intended status: Informational                                Ina Minei 
                                                             Google, Inc 
                                                           Yakov Rekhter         
                                                        Juniper Networks 
                                                             Ebben Aries 
                                                                Facebook 
                                                           Dante Pacella 
                                                                 Verizon 
                                                                                     
 Expires: September 07, 2015                              March 07, 2015 
                                         
      
                    RSVP-TE Scalability - Recommendations 
                    draft-beeram-mpls-rsvp-te-scaling-00 

 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), its areas, and its working groups.  Note that 
    other groups may also distribute working documents as Internet-
    Drafts. 
         
    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." 
         
    The list of current Internet-Drafts can be accessed at 
    http://www.ietf.org/ietf/1id-abstracts.txt 
         
    The list of Internet-Draft Shadow Directories can be accessed at 
    http://www.ietf.org/shadow.html 
         
    This Internet-Draft will expire on September 07, 2015. 
         
 Copyright Notice 

    Copyright (c) 2015 IETF Trust and the persons identified as the 
    document authors. All rights reserved.  
         
    This document is subject to BCP 78 and the IETF Trust's Legal 
    Provisions Relating to IETF Documents  

      
      
      
      
 Beeram, et al         Expires September 07, 2015               [Page 1] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
         

    (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. 
          
 Abstract 

    RSVP-TE [RFC3209] describes the use of standard RSVP [RFC2205] to 
    establish Label Switched Paths (LSPs). As such, RSVP-TE inherited 
    some properties of RSVP that adversely affect its control plane 
    scalability. Specifically these properties are (a) reliance on 
    periodic refreshes for state synchronization between RSVP neighbors 
    and for recovery from lost RSVP messages, (b) reliance on refresh 
    timeout for stale state cleanup, and (c) lack of any mechanisms by 
    which a receiver of RSVP messages can apply back pressure to the 
    sender(s) of these messages. 

    Subsequent to [RFC2205] and [RFC3209] further enhancements to RSVP 
    and RSVP-TE have been developed. In this document we describe how an 
    implementation of RSVP-TE can use these enhancements to address the 
    above mentioned properties to improve RSVP-TE control plane 
    scalability.  

 Conventions used in this document 

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
    document are to be interpreted as described in RFC-2119 [RFC2119]. 
        

 Table of Contents 

    1. Introduction...................................................3 
       1.1. Reliance on refreshes and refresh timeouts................3 
       1.2. Lack of back pressure.....................................4 
    2. Recommendations................................................5 
       2.1. Eliminating reliance on refreshes and refresh timeouts....5 
       2.2. Providing the ability to apply back pressure..............6 
       2.3. Making Acknowledgements mandatory.........................6 
       2.4. Clarifications on reaching Rapid Retry Limit (Rl).........7 
       2.5. Avoiding use of Router Alert IP Option....................7 
       2.6. Checking Data Plane readiness.............................8 
    3. Security Considerations........................................8 
     
      
      
 Beeram, et al         Expires September 07, 2015               [Page 2] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
         

    4. IANA Considerations............................................8 
    5. Normative References...........................................8 
    6. Acknowledgments................................................9 
        
 1. Introduction 

    RSVP-TE [RFC3209] describes the use of standard RSVP [RFC2205] to 
    establish Label Switched Paths (LSPs). As such, RSVP-TE inherited 
    some properties of RSVP that adversely affect its control plane 
    scalability. Specifically these properties are (a) reliance on 
    periodic refreshes for state synchronization between RSVP neighbors 
    and for recovery from lost RSVP messages, (b) reliance on refresh 
    timeout for stale state cleanup, and (c) lack of any mechanisms by 
    which a receiver of RSVP messages can apply back pressure to the 
    sender(s) of these messages. The following elaborates on this. 

 1.1. Reliance on refreshes and refresh timeouts 

    Standard RSVP [RFC2205] maintains state via the generation of RSVP 
    Path/Resv 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 two operational problems.  The first 
    relates to scaling, the second relates to the reliability and 
    latency of RSVP signaling. 

    The scaling problem is linked to the control plane resource 
    requirements of running RSVP-TE. The resource requirements increase 
    proportionally with the number of LSPs established by RSVP-TE. Each 
    such LSP requires the generation, transmission, reception and 
    processing of RSVP Path and Resv messages per refresh period. 
    Supporting a large number of LSPs and the corresponding volume of 
    refresh messages, presents a scaling problem for the RSVP-TE control 
    plane. 

    The reliability and latency problem occurs when a triggered (non-
    refresh) RSVP message such as Path, Resv, or PathTear 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, and thus the 
    end-to-end latency of RSVP-TE signaled LSP establishment, is tied to 
    the refresh interval of the Label Switch Router(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 an RSVP-TE 
    signaled LSP may be beyond the range of what is acceptable in 
    practice. This is because RSVP-TE ultimately controls establishment 
      
      
      
 Beeram, et al         Expires September 07, 2015               [Page 3] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
         

    of the forwarding state required to realize RSVP-TE signaled LSPs. 
    Thus delay incurred in the establishment or the change of such LSPs 
    results in delaying the data plane convergence, which in turn 
    adversely impacts the services that rely on the data plane. 

    One way to address the scaling problem caused by the refresh volume 
    is to increase the refresh period, "R" as defined in Section 3.7 of 
    [RFC2205]. Increasing the value of R provides linear improvement on 
    RSVP-TE signaling overhead, but at the cost of increasing the time 
    it takes to synchronize state. For the reasons mentioned in the 
    previous paragraph, in the context of RSVP-TE signaled LSPs, 
    increasing the time to synchronize state is not an acceptable 
    option.   

    One way to address the reliability and latency of RSVP signaling is 
    to decrease the refresh period R. Decreasing the value of R 
    increases the probability that state will be installed in the face 
    of message loss, but at the cost of increasing refresh message rate 
    and associated processing requirements, which in turn adversely 
    affects RSVP-TE control plane scalability. 

    An additional problem is the time to clean up the stale state after 
    a tear message is lost. RSVP does not retransmit ResvTear or 
    PathTear messages. If the sole tear message transmitted is lost, the 
    stale state will only be cleaned up once the refresh timeout has 
    expired. This may result in resources associated with the stale 
    state being allocated for an unnecessary period of time. Note that 
    even when the refresh period is adjusted, the refresh timeout must 
    still expire since tear messages are not retransmitted. Decreasing 
    the refresh timeout by decreasing the refresh interval will speed up 
    timely stale state cleanup, but at the cost of increasing refresh 
    message rate, which in turn adversely affects RSVP-TE control plane 
    scalability. 

 1.2. Lack of back pressure 

    In standard RSVP, an RSVP speaker sends RSVP messages to a peer with 
    no regard for whether the peer's RSVP control plane is busy. There 
    is no control plane mechanism by which an RSVP speaker may apply 
    back pressure to the peer by asking the peer to reduce the rate of 
    RSVP messages that the peer sends to the speaker. RSVP-TE inherited 
    this from standard RSVP. Lack of such a mechanism could result in 
    RSVP-TE control plane congestion.  

    RSVP-TE control plane is especially susceptible to congestion during 
    link/node failures, as such failures produce bursts of RSVP-TE 
     
      
      
 Beeram, et al         Expires September 07, 2015               [Page 4] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
         

    messages: Path/Resv for re-routing LSPs affected by the failures, 
    Path/Resv for setup of new backup LSPs (as required by RSVP-TE Fast 
    Reroute [RFC4090]), Tear/Error messages for the affected LSPs. Note 
    that the load on the RSVP-TE control plane caused by these bursts is 
    in addition to the load due to the periodic refreshes of Path/Resv 
    messages for the LSPs not affected by the failures.  

    RSVP-TE control plane congestion may result in loss of RSVP 
    messages, which in turn have detrimental effects on the overall 
    system behavior. Path/Resv refreshes lost by a peer's busy control 
    plane will cause refresh timeout for some or all of its existing 
    RSVP-TE state on the peer, thus inadvertently deleting existing LSPs 
    and disrupting traffic carried over these LSPs. Triggered Path/Resv 
    lost by a peer's busy control plane may result in failure to 
    establish new backup LSPs used by RSVP-TE Fast Reroute [RFC4090] 
    before the state for the corresponding protected primary LSPs times 
    out, thus defeating the whole purpose of RSVP-TE Fast Reroute. 

 2. Recommendations 

    Subsequent to the publication of [RFC2205] and [RFC3209] further 
    enhancements to RSVP and RSVP-TE have been developed. In this 
    section we describe how these enhancements could be used to address 
    the problems listed in Section 1. 

 2.1. Eliminating reliance on refreshes and refresh timeouts 

    To eliminate reliance on refreshes for both state synchronization 
    between RSVP neighbors and for recovery from lost RSVP messages, as 
    well as to address both the refresh volume and the reliability 
    issues with RSVP mechanisms other than adjusting refresh rate, this 
    document RECOMMENDS the following: 

    -  Implement reliable delivery of Path/Resv messages using the 
    procedures specified in [RFC2961]. 

    -  Indicate support for RSVP Refresh Overhead Reduction Extensions 
    (as specified in Section 2 of [RFC2961] by default, with the ability 
    to override the default via configuration. 

    -  Make the value of the refresh interval configurable with the 
    default value of 20 minutes. 

    To eliminate reliance on refresh timeouts, in addition to the above, 
    this document RECOMMENDS the following: 

     
      
      
 Beeram, et al         Expires September 07, 2015               [Page 5] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
         

    -  Implement reliable delivery of Tear/Err messages using the 
    procedures specified in [RFC2961] 

    -  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 clean up the LSP state for all LSPs affected by the failed 
    adjacency. The LSP state is the combination of "path state" 
    maintained as Path State Block and "reservation state" maintained as 
    Reservation State Block (see Section 2.1 of [RFC2205]).   

    -  Use of Node-ID based Hello session ([RFC3209], [RFC4558]) for 
    detection of RSVP-TE signaling adjacency failures. Make the value of 
    the node hello_interval [RFC3209] configurable; increase the default 
    value from 5 ms (as specified in Section 5.3 of [RFC3209]) to 9 
    seconds.  

    -  Implement procedures specified in [draft-chandra-mpls-enhanced-
    frr-bypass] which describes methods to facilitate FRR that works 
    independently of the refresh-interval. 

 2.2. Providing the ability to apply back pressure 

    To provide an RSVP speaker with the ability to apply back pressure 
    to its peer(s) to reduce/eliminate RSVP-TE control plane congestion, 
    in addition to the above, this document RECOMMENDS the following: 

    -  Use lack of ACKs from a peer as an indication of peer's RSVP-TE 
    control plane congestion, in which case the local system SHOULD 
    throttle RSVP-TE messages to the affected peer. This has to be done 
    on a per-peer basis. 

    -  Retransmit of all RSVP-TE messages using exponential backoff, as 
    specified in Section 6 of [RFC2961]. 

    -  Increase the Retry Limit (Rl), as defined in Section 6.2 of 
    [RFC2961], from 3 to 7. 

    -  Prioritize Tear/Error over trigger Path/Resv sent to a peer when 
    the local system detects RSVP-TE control plane congestion in the 
    peer. 

 2.3. Making Acknowledgements mandatory 

    The reliable message delivery mechanism specified in [RFC2961] 
    states that "Nodes receiving a non-out of order message containing a 
      
      
      
 Beeram, et al         Expires September 07, 2015               [Page 6] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
        

    MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with 
    a MESSAGE_ID_ACK object." To improve predictability of the system in 
    terms of reliable message delivery this document RECOMMENDS that 
    nodes receiving a non-out of order message containing a MESSAGE_ID 
    object with the ACK_Desired flag set, MUST respond with a 
    MESSAGE_ID_ACK object. 

 2.4. Clarifications on reaching Rapid Retry Limit (Rl) 

    According to section 6 of [RFC2961] "The staged retransmission will 
    continue until either an appropriate MESSAGE_ID_ACK object is 
    received, or the rapid retry limit, Rl, has been reached." The 
    following clarifies what actions, if any, a router should take once 
    Rl has been reached. 

    If it is the retransmission of Tear/Err messages and Rl has been 
    reached, the router need not take any further actions. 

    If it is the retransmission of Path/Resv messages and Rl has been 
    reached, then the router starts periodic retransmission of these 
    messages every 30 seconds. The retransmitted messages MUST carry 
    MESSAGE_ID object with ACK_Desired flag set. This periodic 
    retransmission SHOULD continue until an appropriate MESSAGE_ID ACK 
    object is received indicating acknowledgement of the (retransmitted) 
    Path/Resv message. 

 2.5. Avoiding use of Router Alert IP Option 

    In RSVP-TE the Path message is carried in an IP packet that is 
    addressed to the tail end of the LSP that is signaled using this 
    message. To make all the intermediate/transit LSRs process this 
    message, the IP packet carrying the message includes the Router 
    Alert IP option. The same applies to the PathTear message. 

    An alternative to relying on the Router Alert IP option is to carry 
    the Path or PathTear message as a sub-message of a Bundle message 
    [RFC2961], as Bundle messages are "addressed directly to RSVP 
    neighbors" and "SHOULD NOT be sent with the Router Alert IP option 
    in their IP headers" [RFC2961]. Notice that since a Bundle message 
    could contain only a single sub-message, this approach could be used 
    to send just a single Path or PathTear message. This document 
    RECOMMENDS implementing support for Bundle messages [RFC2961], and 
    carrying Path and PathTear message(s) as sub-message(s) of a Bundle 
    message. 

      
      
      
 Beeram, et al         Expires September 07, 2015               [Page 7] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
         

 2.6. Checking Data Plane readiness 

    In certain scenarios, like Make-Before-Break (MBB), a router needs 
    to move traffic from an existing LSP to a new LSP in the least 
    disruptive fashion. To accomplish this the data plane of the new LSP 
    must be operational before the router moves the traffic.  

    A possible mechanism by which the router can determine whether the 
    data plane of the new LSP is operational is specified in [draft-
    bonica-mpls-self-ping]. This document RECOMMENDS implementing this 
    mechanism and using it whenever the ingress of an LSP needs to check 
    whether the data plane of the LSP is operational. 

 3. Security Considerations 

    This document does not introduce new security issues. The security 
    considerations pertaining to the original RSVP protocol [RFC2205] 
    and RSVP-TE [RFC3209] remain relevant. 

 4. IANA Considerations 

    This document makes no request of IANA. 

    Note to RFC Editor: this section may be removed on publication as an 
    RFC 

 5. Normative References 

    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate 
                Requirement Levels", BCP 14, RFC 2119, March 1997. 
         
    [RFC2205]   Braden, R., "Resource Reservation Protocol (RSVP)",  
                RFC 2205, September 1997. 
         
    [RFC2961]   Berger, L., "RSVP Refresh Overhead Reduction  
                Extensions", RFC 2961, April 2001. 
         
    [RFC3209]   Awduche, D., "RSVP-TE: Extensions to RSVP for LSP  
                Tunnels", RFC 3209, December 2001. 
         
    [RFC4090]   Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP             
                Tunnels", RFC 4090, May 2005. 
         
    [RFC4558]   Ali, Z., "Node-ID Based Resource Reservation (RSVP)  
                Hello: A Clarification Statement", RFC 4558, June 2006. 
         
      
      
      
 Beeram, et al         Expires September 07, 2015               [Page 8] 
 

 Internet-Draft     Network Assigned Upstream Label           March 2015 
         

    [draft-bonica-mpls-self-ping] Ron Bonica, et al., "LSP Self-Ping",  
                draft-bonica-mpls-self-ping, (work in progress) 
         
    [draft-chandra-mpls-enhanced-frr-bypass] Chandra Ramachandran, et   
                al., "Refresh Interval Independent FRR Facility  
                    Protection", draft-chandra-mpls-enhanced-frr-bypass,  
                    (work in progress) 
         

 6. Acknowledgments 
         
    Most of the text in Section 1.1 has been taken almost verbatim from 
    [RFC2961]. 
         
 Authors' Addresses 

    Vishnu Pavan Beeram 
    Juniper Networks 
    Email: vbeeram@juniper.net 
         
    Ina Minei 
    Google, Inc 
    Email: inaminei@google.com 
         
    Yakov Rekhter 
    Juniper Networks 
    Email: yakov@juniper.net 
      
    Ebben Aries 
    Facebook 
    Email: exa@fb.com 
      
    Dante Pacella 
    Verizon 
    Email: dante.j.pacella@verizon.com 
         
    Markus Jork 
    Juniper Networks 
    Email: mjork@juniper.net 

      
      
      
 Beeram, et al         Expires September 07, 2015               [Page 9]