draft-ietf-teas-rsvp-te-scaling-rec-03.txt   draft-ietf-teas-rsvp-te-scaling-rec-04.txt 
TEAS Working Group Vishnu Pavan Beeram TEAS Working Group V. Beeram, Ed.
Internet Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Proposed Standard Ina Minei Intended status: Standards Track I. Minei
Google, Inc Expires: September 13, 2017 R. Shakir
Rob Shakir Google, Inc
Google, Inc D. Pacella
Dante Pacella Verizon
Verizon T. Saad
Tarek Saad Cisco Systems
Cisco Systems March 12, 2017
Expires: April 30, 2017 October 30, 2016 Implementation Recommendations to Improve the Scalability of RSVP-TE
Deployments
draft-ietf-teas-rsvp-te-scaling-rec-04
Implementation Recommendations to Improve the Scalability of RSVP-TE Abstract
Deployments
draft-ietf-teas-rsvp-te-scaling-rec-03
Status of this Memo The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
is growing continually and the onus is on RSVP-TE implementations
across the board to keep up with this increasing demand.
This document makes a set of implementation recommendations to help
RSVP-TE deployments push the envelope on scaling and advocates the
use of a couple of techniques - "Refresh-Interval Independent RSVP
(RI-RSVP)" and "Per-Peer Flow-Control" - for improving scaling.
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://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."
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 Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html 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."
This Internet-Draft will expire on April 30, 2017. This Internet-Draft will expire on September 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
is growing continually and the onus is on RSVP-TE implementations
across the board to keep up with this increasing demand.
This document makes a set of implementation recommendations to help
RSVP-TE deployments push the envelope on scaling and advocates the
use of a couple of techniques - "Refresh Interval Independent RSVP
(RI-RSVP)" and "Per-Peer flow-control" - for improving scaling.
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 Table of Contents
1. Introduction...................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Recommendations................................................3 1.1. Conventions used in this document . . . . . . . . . . . . 3
2.1. "RFC2961 specific" Recommendations........................3 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Basic Pre-Requisites.................................4 2.1. "RFC2961 specific" Recommendations . . . . . . . . . . . 3
2.1.2. Making Acknowledgements mandatory....................4 2.1.1. Basic Pre-Requisites . . . . . . . . . . . . . . . . 3
2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)....4 2.1.2. Making Acknowledgements mandatory . . . . . . . . . . 4
2.2. Refresh Interval Independent RSVP.........................5 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl) . . 4
2.2.1. Capability Advertisement.............................6 2.2. Refresh-Interval Independent RSVP . . . . . . . . . . . . 4
2.2.2. Compatibility........................................6 2.2.1. Capability Advertisement . . . . . . . . . . . . . . 5
2.3. Per-Peer RSVP Flow Control................................6 2.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Capability Advertisement.............................7 2.3. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . 6
2.3.2. Compatibility........................................7 2.3.1. Capability Advertisement . . . . . . . . . . . . . . 7
3. Security Considerations........................................8 2.3.2. Compatibility . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations............................................8 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Capability Object Values..................................8 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
5. References.....................................................8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References......................................8 5.1. Capability Object Values . . . . . . . . . . . . . . . . 8
5.2. Informative References....................................9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments................................................9 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Recommended Defaults..................................9 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Contributors.....................................................10 Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9
Authors' Addresses...............................................10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get
deployed is growing continually and there is considerable onus on deployed is growing continually and there is considerable onus on
RSVP-TE implementations across the board to keep up with this RSVP-TE implementations across the board to keep up with this
increasing demand in scale. increasing demand in scale.
The set of RSVP Refresh Overhead Reduction procedures [RFC2961] The set of RSVP Refresh Overhead Reduction procedures [RFC2961]
serves as a powerful toolkit for RSVP-TE implementations to help serves as a powerful toolkit for RSVP-TE implementations to help
cover a majority of the concerns about soft-state scaling. However, cover a majority of the concerns about soft-state scaling. However,
even with these tools in the toolkit, analysis of existing even with these tools in the toolkit, analysis of existing
implementations [RFC5439] indicates that the processing required implementations [RFC5439] indicates that the processing required
under certain scale may still cause significant disruption to an under certain scale may still cause significant disruption to an LSR.
LSR.
This document builds on the scaling work and analysis that has been This document builds on the scaling work and analysis that has been
done so far and makes a set of concrete implementation done so far and makes a set of concrete implementation
recommendations to help RSVP-TE deployments push the envelope recommendations to help RSVP-TE deployments push the envelope further
further on scaling - push higher the threshold above which an LSR on scaling - push higher the threshold above which an LSR struggles
struggles to achieve sufficient processing to maintain LSP state. to achieve sufficient processing to maintain LSP state.
This document advocates the use of a couple of techniques - "Refresh This document advocates the use of a couple of techniques - "Refresh-
Interval Independent RSVP (RI-RSVP)" and "Per-Peer flow-control" - Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" -
for significantly cutting down the amount of processing cycles for significantly cutting down the amount of processing cycles
required to maintain LSP state. "RI-RSVP" helps completely eliminate required to maintain LSP state. "RI-RSVP" helps completely eliminate
RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer
Flow-Control" enables a busy RSVP speaker to apply back pressure to Flow-Control" enables a busy RSVP speaker to apply back pressure to
its peer(s). In order to reap maximum scaling benefits, it is its peer(s). In order to reap maximum scaling benefits, it is
strongly RECOMMENDED that implementations support both the strongly RECOMMENDED that implementations support both the
techniques, but it is possible for an implementation to support just techniques, but it is possible for an implementation to support just
one but not the other. one but not the other.
2. Recommendations 1.1. Conventions used in this document
2.1. "RFC2961 specific" Recommendations 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 [RFC2119]
2. Recommendations
2.1. "RFC2961 specific" Recommendations
The implementation recommendations discussed in this section are The implementation recommendations discussed in this section are
based on the proposals made in [RFC2961] and act as pre-requisites based on the proposals made in [RFC2961] and act as pre-requisites
for implementing either or both of the techniques discussed in for implementing either or both of the techniques discussed in
Sections 2.2 and 2.3. Sections 2.2 and 2.3.
2.1.1. Basic Pre-Requisites 2.1.1. Basic Pre-Requisites
An implementation that supports either or both of the techniques An implementation that supports either or both of the techniques
discussed in Sections 2.2 and 2.3: discussed in Sections 2.2 and 2.3:
- SHOULD indicate support for RSVP Refresh Overhead Reduction o SHOULD indicate support for RSVP Refresh Overhead Reduction
extensions (as specified in Section 2 of [RFC2961]) by default, extensions (as specified in Section 2 of [RFC2961]) by default,
with the ability to override the default via configuration. with the ability to override the default via configuration.
- MUST support reliable delivery of Path/Resv and the corresponding o MUST support reliable delivery of Path/Resv and the corresponding
Tear/Err messages using the procedures specified in [RFC2961]. Tear/Err messages using the procedures specified in [RFC2961].
- MUST support retransmit of all RSVP-TE messages using exponential- o MUST support retransmit of all RSVP-TE messages using exponential-
backoff, as specified in Section 6 of [RFC2961]. backoff, as specified in Section 6 of [RFC2961].
2.1.2. Making Acknowledgements mandatory 2.1.2. Making Acknowledgements mandatory
The reliable message delivery mechanism specified in [RFC2961] The reliable message delivery mechanism specified in [RFC2961] states
states that "Nodes receiving a non-out of order message containing a that "Nodes receiving a non-out of order message containing a
MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with
a MESSAGE_ID_ACK object." a MESSAGE_ID_ACK object."
In an implementation that supports either or both of the techniques In an implementation that supports either or both of the techniques
discussed in Sections 2.2 and 2.3, nodes receiving a non-out of discussed in Sections 2.2 and 2.3, nodes receiving a non-out of order
order message containing a MESSAGE ID object with the ACK-Desired message containing a MESSAGE ID object with the ACK-Desired flag set,
flag set, MUST respond with a MESSAGE_ID_ACK object. This MUST respond with a MESSAGE_ID_ACK object. This improvement to the
improvement to the predictability of the system in terms of reliable predictability of the system in terms of reliable message delivery is
message delivery is key for being able to take any action based on a key for being able to take any action based on a non-receipt of an
non-receipt of an ACK. ACK.
2.1.3. Clarifications on reaching Rapid Retry Limit (Rl) 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)
According to section 6 of [RFC2961] "The staged retransmission will According to section 6 of [RFC2961] "The staged retransmission will
continue until either an appropriate MESSAGE_ID_ACK object is continue until either an appropriate MESSAGE_ID_ACK object is
received, or the rapid retry limit, Rl, has been reached." The received, or the rapid retry limit, Rl, has been reached." The
following clarifies what actions, if any, a router should take once following clarifies what actions, if any, a router should take once
Rl has been reached. Rl has been reached.
If it is the retransmission of Tear/Err messages and Rl has been 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 reached, the router need not take any further actions. If it is the
retransmission of Path/Resv messages and Rl has been reached, then retransmission of Path/Resv messages and Rl has been reached, then
the router starts periodic retransmission of these messages. The the router starts periodic retransmission of these messages. The
retransmitted messages MUST carry MESSAGE_ID object with ACK_Desired retransmitted messages MUST carry MESSAGE_ID object with ACK_Desired
flag set. This periodic retransmission SHOULD continue until an flag set. This periodic retransmission SHOULD continue until an
appropriate MESSAGE_ID ACK object is received indicating appropriate MESSAGE_ID ACK object is received indicating
acknowledgement of the (retransmitted) Path/Resv message. The acknowledgement of the (retransmitted) Path/Resv message. The
configurable periodic retransmission interval SHOULD be less than configurable periodic retransmission interval SHOULD be less than the
the regular refresh interval. A default periodic retransmission regular refresh interval. A default periodic retransmission interval
interval of 30 seconds is RECOMMENDED by this document. of 30 seconds is RECOMMENDED by this document.
2.2. Refresh Interval Independent RSVP 2.2. Refresh-Interval Independent RSVP
The RSVP protocol relies on periodic refreshes for state The RSVP protocol relies on periodic refreshes for state
synchronization between RSVP neighbors and for recovery from lost synchronization between RSVP neighbors and for recovery from lost
RSVP messages. It relies on refresh timeout for stale state cleanup. RSVP messages. It relies on refresh timeout for stale state cleanup.
The primary motivation behind introducing the notion of "Refresh The primary motivation behind introducing the notion of "Refresh
Interval Independent RSVP" (RI-RSVP) is to completely eliminate Interval Independent RSVP" (RI-RSVP) is to completely eliminate
RSVP's reliance on refreshes and refresh timeouts. This is done by RSVP's reliance on refreshes and refresh timeouts. This is done by
simply increasing the refresh interval to a fairly large value. simply increasing the refresh interval to a fairly large value.
[RFC2961] and [RFC5439] do talk about increasing the value of the [RFC2961] and [RFC5439] do talk about increasing the value of the
refresh-interval to provide linear improvement on transmission refresh-interval to provide linear improvement on transmission
overhead, but also point out the degree of functionality that is overhead, but also point out the degree of functionality that is lost
lost by doing so. This section revisits this notion, but also by doing so. This section revisits this notion, but also proposes
proposes sufficient recommendations to make sure that there is no sufficient recommendations to make sure that there is no loss of
loss of functionality incurred by increasing the value of the functionality incurred by increasing the value of the refresh
refresh interval. interval.
An implementation that supports RI-RSVP: An implementation that supports RI-RSVP:
- MUST support all the recommendations made in Section 2.1 o MUST support all the recommendations made in Section 2.1.
- MUST make the default value of the configurable refresh interval o MUST make the default value of the configurable refresh interval
be a large value (10s of minutes). A default value of 20 minutes be a large value (10s of minutes). A default value of 20 minutes
is RECOMMENDED by this document. is RECOMMENDED by this document.
- MUST implement coupling the state of individual LSPs with the o MUST implement coupling the state of individual LSPs with the
state of the corresponding RSVP-TE signaling adjacency. When an state of the corresponding RSVP-TE signaling adjacency. When an
RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the
speaker MUST act as if the all the Path and Resv state learnt via speaker MUST act as if the all the Path and Resv state learnt via
the failed signaling adjacency has timed out. the failed signaling adjacency has timed out.
- MUST make use of Node-ID based Hello Session ([RFC3209], o MUST make use of Node-ID based Hello Session ([RFC3209],
[RFC4558]) for detection of RSVP-TE signaling adjacency failures; [RFC4558]) for detection of RSVP-TE signaling adjacency failures;
A default value of 9 seconds is RECOMMENDED by this document for A default value of 9 seconds is RECOMMENDED by this document for
the configurable node hello interval (as opposed to the 5ms the configurable node hello interval (as opposed to the 5ms
default value proposed in Section 5.3 of [RFC3209]). default value proposed in Section 5.3 of [RFC3209]).
- MUST indicate support for RI-RSVP via the CAPABILITY object in o MUST indicate support for RI-RSVP via the CAPABILITY object in
Hello messages. Hello messages.
2.2.1. Capability Advertisement 2.2.1. Capability Advertisement
An implementation supporting the RI-RSVP recommendations MUST set a An implementation supporting the RI-RSVP recommendations MUST set a
new flag "RI-RSVP Capable" in the CAPABILITY object signaled in new flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
Hello messages. messages.
The new flag that will be introduced to CAPABILITY object is The new flag that will be introduced to CAPABILITY object is
specified below. specified below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(134)| C-Type (1) | | Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |I|T|R|S| | Reserved |I|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit I bit
Indicates that the sender supports RI-RSVP. Indicates that the sender supports RI-RSVP.
Any node that sets the new I-bit in its CAPABILITY object MUST also Any node that sets the new I-bit in its CAPABILITY object MUST also
set Refresh-Reduction-Capable bit in common header of all RSVP-TE set Refresh-Reduction-Capable bit in common header of all RSVP-TE
messages. messages.
2.2.2. Compatibility 2.2.2. Compatibility
The RI-RSVP functionality MUST be activated only between peers that The RI-RSVP functionality MUST be activated only between peers that
indicate their support for this functionality. indicate their support for this functionality.
2.3. Per-Peer RSVP Flow Control 2.3. Per-Peer RSVP Flow-Control
The set of recommendations discussed in this section provide an RSVP The set of recommendations discussed in this section provide an RSVP
speaker with the ability to apply back pressure to its peer(s) to speaker with the ability to apply back pressure to its peer(s) to
reduce/eliminate RSVP-TE control plane congestion. reduce/eliminate RSVP-TE control plane congestion.
An implementation that supports "Per-Peer RSVP Flow Control": An implementation that supports "Per-Peer RSVP Flow-Control":
- MUST support all the recommendations made in Section 2.1 o MUST support all the recommendations made in Section 2.1
- MUST use lack of ACKs from a peer as an indication of peer's RSVP- o MUST use lack of ACKs from a peer as an indication of peer's RSVP-
TE control plane congestion. If congestion is detected, the local TE control plane congestion. If congestion is detected, the local
system MUST throttle RSVP-TE messages to the affected peer. This system MUST throttle RSVP-TE messages to the affected peer. This
MUST be done on a per-peer basis. (Per-peer throttling MAY be MUST be done on a per-peer basis. (Per-peer throttling MAY be
implemented by a traffic shaping mechanism that proportionally implemented by a traffic shaping mechanism that proportionally
reduces the RSVP signaling packet rate as the number of reduces the RSVP signaling packet rate as the number of
outstanding Acks increases. And when the number of outstanding outstanding Acks increases. And when the number of outstanding
Acks decreases, the send rate would be adjusted up again.) Acks decreases, the send rate would be adjusted up again.)
- SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of
[RFC2961], suggests using 3). [RFC2961], suggests using 3).
- SHOULD prioritize Tear/Error over trigger Path/Resv (messages that o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that
bring up new LSP state) sent to a peer when the local system bring up new LSP state) sent to a peer when the local system
detects RSVP-TE control plane congestion in the peer. detects RSVP-TE control plane congestion in the peer.
- MUST indicate support for all recommendations in this section via o MUST indicate support for all recommendations in this section via
the CAPABILITY object in Hello messages. the CAPABILITY object in Hello messages.
2.3.1. Capability Advertisement 2.3.1. Capability Advertisement
An implementation supporting the "Per-Peer Flow Control" An implementation supporting the "Per-Peer Flow-Control"
recommendations MUST set a new flag "Per-Peer Flow Control Capable" recommendations MUST set a new flag "Per-Peer Flow-Control Capable"
in the CAPABILITY object signaled in Hello messages. in the CAPABILITY object signaled in Hello messages.
The new flag that will be introduced to CAPABILITY object is The new flag that will be introduced to CAPABILITY object is
specified below. specified below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(134)| C-Type (1) | | Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |F|I|T|R|S| | Reserved |F|I|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F bit F bit
Indicates that the sender supports Per-Peer RSVP Flow Control Indicates that the sender supports Per-Peer RSVP Flow-Control
Any node that sets the new I-bit in its CAPABILITY object MUST also Any node that sets the new I-bit in its CAPABILITY object MUST also
set Refresh-Reduction-Capable bit in common header of all RSVP-TE set Refresh-Reduction-Capable bit in common header of all RSVP-TE
messages. messages.
2.3.2. Compatibility 2.3.2. Compatibility
The "Per-Peer Flow Control" functionality MUST be activated only if The "Per-Peer Flow-Control" functionality MUST be activated only if
both peers support it. If a peer hasn't indicated that it is capable both peers support it. If a peer hasn't indicated that it is capable
of participating in "Per-Peer Flow Control", then it is risky to of participating in "Per-Peer Flow-Control", then it is risky to
assume that the peer would always acknowledge a non-out of order assume that the peer would always acknowledge a non-out of order
message containing a MESSAGE ID object with the ACK-Desired flag message containing a MESSAGE ID object with the ACK-Desired flag set.
set.
3. Security Considerations 3. Acknowledgements
This document does not introduce new security issues. The security The authors would like to thank Yakov Rekhter for initiating this
considerations pertaining to the original RSVP protocol [RFC2205] work and providing valuable inputs. They would like to thank
and RSVP-TE [RFC3209] and those that are described in [RFC5920] Raveendra Torvi and Chandra Ramachandran for participating in the
remain relevant. many discussions that led to the recommendations made in this
document. They would also like to thank Adrian Farrel for providing
detailed review comments.
4. IANA Considerations 4. Contributors
4.1. Capability Object Values Markus Jork
Juniper Networks
Email: mjork@juniper.net
Ebben Aries
Juniper Networks
Email: exa@juniper.net
5. IANA Considerations
5.1. Capability Object Values
IANA maintains all the registries associated with "Resource IANA maintains all the registries associated with "Resource
Reservation Protocol (RSVP) Paramaters" (see Reservation Protocol (RSVP) Paramaters" (see
http://www.iana.org/assignments/rsvp-parameters/rsvp- http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml). "Capability Object Values" Registry (introduced parameters.xhtml). "Capability Object Values" Registry (introduced
by [RFC5063]) is one of them. by [RFC5063]) is one of them.
IANA is requested to assign two new Capability Object Value bit IANA is requested to assign two new Capability Object Value bit flags
flags as follows: as follows:
Bit Hex Name Reference
Number Value
--------------------------------------------------------------------
TBA TBA RI-RSVP Capable (I) Section 2.2.1
TBA TBA Per-Peer Flow Control Capable (F) Section 2.3.1
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Bit Hex Name Reference
Requirement Levels", BCP 14, RFC 2119, March 1997. Number Value
------------------------------------------------------------------
TBA TBA RI-RSVP Capable (I) Section 2.2.1
TBA TBA Per-Peer Flow-Control Capable (F) Section 2.3.1
[RFC2205] Braden, R., "Resource Reservation Protocol (RSVP)", 6. Security Considerations
RFC 2205, September 1997.
[RFC2961] Berger, L., "RSVP Refresh Overhead Reduction This document does not introduce new security issues. The security
Extensions", RFC 2961, April 2001. considerations pertaining to the original RSVP protocol [RFC2205] and
RSVP-TE [RFC3209] and those that are described in [RFC5920] remain
relevant.
[RFC3209] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP 7. References
Tunnels", RFC 3209, December 2001.
[RFC4558] Ali, Z., "Node-ID Based Resource Reservation (RSVP) 7.1. Normative References
Hello: A Clarification Statement", RFC 4558, June 2006.
[RFC5063] Satyanarayana, A., "Extensions to GMPLS Resource [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Reservation Protocol Graceful Restart", RFC5063, October Requirement Levels", BCP 14, RFC 2119,
2007. DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
5.2. Informative 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, <http://www.rfc-editor.org/info/rfc2205>.
[RFC5439] Yasukawa, S., "An Analysis of Scaling Issues in MPLS-TE [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
Core Networks", RFC 5439, February 2009. and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<http://www.rfc-editor.org/info/rfc2961>.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Networks", RFC5920, July 2010. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
6. Acknowledgments [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,
<http://www.rfc-editor.org/info/rfc4558>.
The authors would like to thank Yakov Rekhter for initiating this [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
work and providing valuable inputs. They would like to thank GMPLS Resource Reservation Protocol (RSVP) Graceful
Raveendra Torvi and Chandra Ramachandran for participating in the Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
many discussions that led to the recommendations made in this <http://www.rfc-editor.org/info/rfc5063>.
document. They would also like to thank Adrian Farrel for providing
detailed review comments.
Appendix A. Recommended Defaults 7.2. Informative References
(a) Refresh-Interval (R)- 20 minutes (Section 2.2) [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of
Given that an implementation supporting RI-RSVP doesn't rely on Scaling Issues in MPLS-TE Core Networks", RFC 5439,
refreshes for state sync between peers, the RSVP refresh interval is DOI 10.17487/RFC5439, February 2009,
sort of analogous to IGP refresh interval, the default of which is <http://www.rfc-editor.org/info/rfc5439>.
typically in the order of 10s of minutes. Choosing a default of 20
minutes allows the refresh timer to be randomly set to a value in
the range [10 minutes (0.5R), 30 minutes (1.5R)].
(b) Node Hello-Interval - 9 Seconds (Section 2.2) [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
[RFC3209] defines the hello timeout as 3.5 times the hello interval. Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
Choosing 9 seconds for the node hello-interval gives a hello timeout <http://www.rfc-editor.org/info/rfc5920>.
of 3.5*9 = 31.5 seconds. This puts the hello timeout value to be in
the same ballpark as the IGP hello timeout value.
(c) Retry-Limit (Rl) - 7 (Section 2.3) Appendix A. Recommended Defaults
Choosing 7 as the retry-limit results in an overall rapid retransmit
phase of 31.5 seconds. This nicely matches up with the 31.5 seconds
hello timeout.
(d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3) (a) Refresh-Interval (R)- 20 minutes (Section 2.2) Given that an
If the Retry-Limit (Rl) is 7, then it takes about 30 (31.5 to be implementation supporting RI-RSVP doesn't rely on refreshes for
precise) seconds for the 7 rapid retransmit steps to max out. (The state sync between peers, the RSVP refresh interval is sort of
last delay from message 6 to message 7 is 16 seconds). The 30 analogous to IGP refresh interval, the default of which is
seconds interval also matches the traditional default refresh time. typically in the order of 10s of minutes. Choosing a default of
20 minutes allows the refresh timer to be randomly set to a value
in the range [10 minutes (0.5R), 30 minutes (1.5R)].
Contributors (b) Node Hello-Interval - 9 Seconds (Section 2.2) [RFC3209]
defines the hello timeout as 3.5 times the hello interval.
Choosing 9 seconds for the node hello-interval gives a hello
timeout of 3.5*9 = 31.5 seconds. This puts the hello timeout
value to be in the same ballpark as the IGP hello timeout value.
Markus Jork (c) Retry-Limit (Rl) - 7 (Section 2.3) Choosing 7 as the retry-
Juniper Networks limit results in an overall rapid retransmit phase of 31.5
Email: mjork@juniper.net seconds. This nicely matches up with the 31.5 seconds hello
timeout.
Ebben Aries (d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3)
Juniper Networks If the Retry-Limit (Rl) is 7, then it takes about 30 (31.5 to be
Email: exa@juniper.net precise) seconds for the 7 rapid retransmit steps to max out.
(The last delay from message 6 to message 7 is 16 seconds). The
30 seconds interval also matches the traditional default refresh
time.
Authors' Addresses Authors' Addresses
Vishnu Pavan Beeram (Ed) Vishnu Pavan Beeram (editor)
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Ina Minei Ina Minei
Google, Inc Google, Inc
Email: inaminei@google.com Email: inaminei@google.com
Rob Shakir Rob Shakir
Google, Inc Google, Inc
Email: rjs@rob.sh Email: rjs@rob.sh
Dante Pacella Dante Pacella
Verizon Verizon
Email: dante.j.pacella@verizon.com Email: dante.j.pacella@verizon.com
Tarek Saad Tarek Saad
Cisco Systems Cisco Systems
Email: tsaad@cisco.com Email: tsaad@cisco.com
 End of changes. 90 change blocks. 
261 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/