draft-ietf-teas-rsvp-te-scaling-rec-06.txt   draft-ietf-teas-rsvp-te-scaling-rec-07.txt 
TEAS Working Group V. Beeram, Ed. TEAS Working Group V. Beeram, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: February 11, 2018 R. Shakir Expires: March 31, 2018 R. Shakir
Google, Inc Google, Inc
D. Pacella D. Pacella
Verizon Verizon
T. Saad T. Saad
Cisco Systems Cisco Systems
August 10, 2017 September 27, 2017
Implementation Recommendations to Improve the Scalability of RSVP-TE Techniques to Improve the Scalability of RSVP Traffic Engineering
Deployments Deployments
draft-ietf-teas-rsvp-te-scaling-rec-06 draft-ietf-teas-rsvp-te-scaling-rec-07
Abstract Abstract
The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed At the time of writing, networks which utilize RSVP Traffic
is growing continually and the onus is on RSVP-TE implementations Engineering (RSVP-TE) Label Switched Paths (LSPs) are encountering
across the board to keep up with this increasing demand. limitations in the ability of implementations to support the growth
in the number of LSPs deployed.
This document introduces a couple of techniques - "Refresh-Interval This document defines two techniques, "Refresh-Interval Independent
Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that reduce the number
RSVP-TE deployments push the envelope on scaling. of processing cycles required to maintain RSVP-TE LSP state in Label
Switching Routers (LSRs) and hence allow implementations to support
larger scale deployments.
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.
Status of This Memo 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 11, 2018. This Internet-Draft will expire on March 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3 2. Requirement for RFC2961 Support . . . . . . . . . . . . . . . 3
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Required Functionality from RFC2961 to be Implemented . . 3
2.1. "RFC2961 Specific" Recommendations . . . . . . . . . . . 3 2.2. Making Acknowledgements Mandatory . . . . . . . . . . . . 4
2.1.1. Basic Prerequisites . . . . . . . . . . . . . . . . . 3 2.3. Clarifications On Reaching Rapid Retry Limit (Rl) . . . . 4
2.1.2. Making Acknowledgements Mandatory . . . . . . . . . . 4 3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5
2.1.3. Clarifications On Reaching Rapid Retry Limit (Rl) . . 4 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 6
2.2. Refresh-Interval Independent RSVP . . . . . . . . . . . . 5 3.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Capability Advertisement . . . . . . . . . . . . . . 5 4. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . . . 6
2.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . 6 4.1. Capability Advertisement . . . . . . . . . . . . . . . . 7
2.3. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . 6 4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Capability Advertisement . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Compatibility . . . . . . . . . . . . . . . . . . . . 7 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Capability Object Values . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Capability Object Values . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9 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 At the time of writing, networks which utilize RSVP Traffic
deployed is growing continually and there is considerable onus on Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are
RSVP-TE implementations across the board to keep up with this encountering limitations in the ability of implementations to support
increasing demand in scale. the growth in the number of LSPs deployed.
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 LSR. beyond a certain scale may still cause significant disruption to a
Label Switching Router (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 defines protocol extensions to help RSVP-TE
recommendations to help RSVP-TE deployments push the envelope further deployments push the envelope further on scaling by increasing the
on scaling - push higher the threshold above which an LSR struggles threshold above which an LSR struggles to achieve sufficient
to achieve sufficient processing to maintain LSP state. processing to maintain LSP state.
This document advocates the use of a couple of techniques - "Refresh-
Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" -
for significantly cutting down the amount of processing cycles
required to maintain LSP state. "RI-RSVP" helps completely eliminate
RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer
Flow-Control" enables a busy RSVP speaker to apply back pressure to
its peer(s). In order to reap maximum scaling benefits, it is
strongly RECOMMENDED that implementations support both the
techniques.
1.1. 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 [RFC2119].
2. Recommendations This document defines two techniques, "Refresh-Interval Independent
RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that cut down the number
of processing cycles required to maintain LSP state. "RI-RSVP" helps
completely eliminate RSVP's reliance on refreshes and refresh-
timeouts while "Per-Peer Flow-Control" enables a busy RSVP speaker to
apply back pressure to its peer(s). This document defines a unique
RSVP Capability [RFC5063] for each technique. Note that the "Per-
Peer Flow-Control" technique requires the "RI-RSVP" technique as a
prerequisite. In order to reap maximum scaling benefits, it is
strongly recommended that implementations support both the
techniques. Both the techniques are fully backward compatible and
can be deployed incrementally.
2.1. "RFC2961 Specific" Recommendations 2. Requirement for RFC2961 Support
The implementation recommendations discussed in this section are The techniques defined in Section 3 and Section 4 are based on
based on the proposals made in [RFC2961] and act as prerequisites for proposals made in [RFC2961]. Implementations of these techniques
implementing the techniques discussed in Sections 2.2 and 2.3. will need to support the RSVP messages and procedures defined in
[RFC2961] as set out in Section 2.1 with some minor modifications and
alterations to recommended time intervals and iteration counts as
defined in the remainder of this section.
2.1.1. Basic Prerequisites 2.1. Required Functionality from RFC2961 to be Implemented
An implementation that supports the techniques discussed in Sections An implementation that supports the techniques discussed in Section 3
2.2 and 2.3 must meet certain basic prerequisites. and Section 4 must support the functionality described in [RFC2961]
as follows:
o It MUST indicate support for RSVP Refresh Overhead Reduction o It MUST indicate support for RSVP Refresh Overhead Reduction
extensions (as specified in Section 2 of [RFC2961]). extensions (as specified in Section 2 of [RFC2961]).
o It MUST support receipt of any RSVP Refresh Overhead Reduction o It MUST support receipt of any RSVP Refresh Overhead Reduction
message as defined in [RFC2961]. message as defined in [RFC2961].
o It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms o It MUST initiate all RSVP Refresh Overhead Reduction mechanisms as
as defined in [RFC2961] (including the SRefresh message) with the defined in [RFC2961] (including the SRefresh message) with the
default behavior being to initiate the mechanisms but offering a default behavior being to initiate the mechanisms but offering a
configuration override. configuration override.
o It MUST support reliable delivery of Path/Resv and the o It MUST support reliable delivery of Path/Resv and the
corresponding Tear/Err messages (as specified in Section 4 of corresponding Tear/Err messages (as specified in Section 4 of
[RFC2961]). [RFC2961]).
o It MUST support retransmission of all unacknowledged RSVP-TE o It MUST support retransmission of all unacknowledged RSVP-TE
messages using exponential-backoff (as specified in Section 6 of messages using exponential-backoff (as specified in Section 6 of
[RFC2961]). [RFC2961]).
2.1.2. Making Acknowledgements Mandatory 2.2. Making Acknowledgements Mandatory
The reliable message delivery mechanism specified in [RFC2961] states The reliable message delivery mechanism specified in [RFC2961] 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 the techniques discussed in In an implementation that supports the techniques discussed in
Sections 2.2 and 2.3, nodes receiving a non-out of order message Section 3 and Section 4, nodes receiving a non-out of order message
containing a MESSAGE ID object with the ACK-Desired flag set, MUST containing a MESSAGE_ID object with the ACK-Desired flag set, MUST
respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can
be packed along with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects be packed along with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects
and sent in an Ack message (or piggy-backed in any other RSVP and sent in an Ack message (or piggy-backed in any other RSVP
message). This improvement to the predictability of the system in message). This improvement to the predictability of the system in
terms of reliable message delivery is key for being able to take any terms of reliable message delivery is key for being able to take any
action based on a non-receipt of an ACK. action based on a non-receipt of an ACK.
2.1.3. Clarifications On Reaching Rapid Retry Limit (Rl) 2.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 Rl has been reached for the retransmission of a message that is If Rl has been reached for the retransmission of a message that is
neither a Path nor a Resv message, then the router need not take any neither a Path nor a Resv message, then the router need not take any
further action. If Rl has been reached for the retransmission of a further action. If Rl has been reached for the retransmission of a
Path or a Resv message, then the router starts periodic Path or a Resv message, then the router starts periodic
retransmission of these on a slower timer. The retransmitted retransmission of these on a slower timer. The retransmitted
messages MUST carry MESSAGE_ID object with ACK_Desired flag set. messages MUST carry MESSAGE_ID object with ACK_Desired flag set.
This periodic retransmission SHOULD continue until an appropriate This periodic retransmission SHOULD continue until an appropriate
MESSAGE_ID_ACK object is received indicating acknowledgement of the MESSAGE_ID_ACK object is received indicating acknowledgement of the
(retransmitted) Path/Resv message. The configurable periodic (retransmitted) Path/Resv message. The configurable periodic
retransmission interval for this slower timer SHOULD be less than the retransmission interval for this slower timer SHOULD be less than the
regular refresh interval. A default periodic retransmission interval regular refresh interval. A default periodic retransmission interval
interval (for this slower timer) of 30 seconds is RECOMMENDED by this (for this slower timer) of 30 seconds is RECOMMENDED by this
document. document.
2.2. Refresh-Interval Independent RSVP 3. Refresh-Interval Independent RSVP (RI-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 of transmission
overhead, but also point out the degree of functionality that is lost overhead, but also point out the degree of functionality that is lost
by doing so. This section revisits this notion, but also proposes by doing so. This section revisits this notion, but also sets out
sufficient recommendations to make sure that there is no loss of additional requirements to make sure that there is no loss of
functionality incurred by increasing the value of the refresh functionality incurred by increasing the value of the refresh
interval. interval.
An implementation that supports RI-RSVP: An implementation that supports RI-RSVP:
o MUST support all the recommendations made in Section 2.1. o MUST support all the requirements specified in Section 2.
o 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.
o 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 all the Path and Resv states learnt via the speaker MUST act as if all the Path and Resv states learnt via the
failed signaling adjacency have timed out. failed signaling adjacency have timed out.
o 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]).
o MUST indicate support for RI-RSVP via the CAPABILITY object in o MUST indicate support for RI-RSVP via the CAPABILITY object
Hello messages. [RFC5063] in Hello messages.
2.2.1. Capability Advertisement 3.1. Capability Advertisement
An implementation supporting the RI-RSVP recommendations MUST set a An implementation supporting the RI-RSVP technique MUST set a new
new flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
messages. messages.
Bit Number TBA1 (TBA2) - RI-RSVP Capable (I-bit): Bit Number TBA1 (TBA2) - RI-RSVP Capable (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 the Refresh-Reduction-Capable bit in the common header of all
messages. If a peer sets the I-bit in the CAPABILITY object but does RSVP-TE messages. If a peer sets the I-bit in the CAPABILITY object
not set the Refresh-Reduction-Capable bit, then the RI-RSVP but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP
functionality MUST NOT be activated for that peer. functionality MUST NOT be activated for that peer.
2.2.2. Compatibility 3.2. Compatibility
The RI-RSVP functionality MUST NOT be activated with a peer that does The RI-RSVP functionality MUST NOT be activated with a peer that does
not indicate support for this functionality. not indicate support for this functionality.
2.3. Per-Peer RSVP Flow-Control 4. Per-Peer RSVP Flow-Control
The set of recommendations discussed in this section provide an RSVP The functionality discussed in this section provides an RSVP speaker
speaker with the ability to apply back pressure to its peer(s) to with the ability to apply back pressure to its peer(s) to reduce/
reduce/eliminate RSVP-TE control plane congestion. eliminate a significant portion of the RSVP-TE control message load.
An implementation that supports "Per-Peer RSVP Flow-Control": An implementation that supports "Per-Peer RSVP Flow-Control":
o MUST support all the recommendations made in Sections 2.1 and 2.2. o MUST support all the requirements specified in Section 2.
o MUST support "RI-RSVP" (Section 3).
o MUST treat lack of ACKs from a peer as an indication of peer's o MUST treat lack of ACKs from a peer as an indication of peer's
RSVP-TE control plane congestion. If congestion is detected, the RSVP-TE control plane congestion. If congestion is detected, the
local system MUST throttle RSVP-TE messages to the affected peer. local system MUST throttle RSVP-TE messages to the affected peer.
This MUST be done on a per-peer basis. (Per-peer throttling MAY This MUST be done on a per-peer basis. (Per-peer throttling MAY
be implemented by a traffic shaping mechanism that proportionally be 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.)
o 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).
o SHOULD prioritize Hello messages and messages carrying o SHOULD prioritize Hello messages and messages carrying
Acknowledgements over other RSVP messages. Acknowledgements over other RSVP messages.
o 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.
o MUST indicate support for all recommendations in this section via o MUST indicate support for this technique via the CAPABILITY object
the CAPABILITY object in Hello messages. [RFC5063] in Hello messages.
2.3.1. Capability Advertisement 4.1. Capability Advertisement
An implementation supporting the "Per-Peer Flow-Control" An implementation supporting the "Per-Peer Flow-Control" technique
recommendations MUST set a new flag "Per-Peer Flow-Control Capable" MUST set a new flag "Per-Peer Flow-Control Capable" in the CAPABILITY
in the CAPABILITY object signaled in Hello messages. object signaled in Hello messages.
Bit Number TBA3 (TBA4) - Per-Peer Flow-Control Capable (F-bit): Bit Number TBA3 (TBA4) - Per-Peer Flow-Control Capable (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 F-bit in its CAPABILITY object MUST also Any node that sets the new F-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. If a peer sets the F-bit in the CAPABILITY object but does messages. If a peer sets the F-bit in the CAPABILITY object but does
not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow- not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow-
Control functionality MUST NOT be activated for that peer. Control functionality MUST NOT be activated for that peer.
2.3.2. Compatibility 4.2. Compatibility
The Per-Peer Flow-Control functionality MUST NOT be activated with a The Per-Peer Flow-Control functionality MUST NOT be activated with a
peer that does not indicate support for this functionality. If a peer that does not indicate support for this functionality. If a
peer hasn't indicated that it is capable of participating in "Per- peer hasn't indicated that it is capable of participating in "Per-
Peer Flow-Control", then it SHOULD NOT be assumed that the peer would Peer Flow-Control", then it SHOULD NOT be assumed that the peer would
always acknowledge a non-out of order message containing a MESSAGE ID always acknowledge a non-out of order message containing a MESSAGE_ID
object with the ACK-Desired flag set. object with the ACK-Desired flag set.
3. Acknowledgements 5. Acknowledgements
The authors would like to thank Yakov Rekhter for initiating this The authors would like to thank Yakov Rekhter for initiating this
work and providing valuable inputs. They would like to thank work and providing valuable inputs. They would like to thank
Raveendra Torvi and Chandra Ramachandran for participating in the Raveendra Torvi and Chandra Ramachandran for participating in the
many discussions that led to the recommendations made in this many discussions that led to the techniques discussed in this
document. They would also like to thank Adrian Farrel and Lou Berger document. They would also like to thank Adrian Farrel and Lou Berger
for providing detailed review comments. for providing detailed review comments.
4. Contributors 6. Contributors
Markus Jork Markus Jork
Juniper Networks Juniper Networks
Email: mjork@juniper.net Email: mjork@juniper.net
Ebben Aries Ebben Aries
Juniper Networks Juniper Networks
Email: exa@juniper.net Email: exa@juniper.net
5. IANA Considerations 7. IANA Considerations
5.1. Capability Object Values 7.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 flags IANA is requested to assign two new Capability Object Value bit flags
as follows: as follows:
Bit Hex Name Reference Bit Hex Name Reference
Number Value Number Value
------------------------------------------------------------------ ------------------------------------------------------------------
TBA1 TBA2 RI-RSVP Capable (I) Section 2.2.1 TBA1 TBA2 RI-RSVP Capable (I) Section 3
TBA3 TBA4 Per-Peer Flow-Control Capable (F) Section 2.3.1 TBA3 TBA4 Per-Peer Flow-Control Capable (F) Section 4
6. Security Considerations 8. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205] and considerations pertaining to the original RSVP protocol [RFC2205] and
RSVP-TE [RFC3209] and those that are described in [RFC5920] remain RSVP-TE [RFC3209] and those that are described in [RFC5920] remain
relevant. relevant.
7. References 9. References
7.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<http://www.rfc-editor.org/info/rfc2961>. <https://www.rfc-editor.org/info/rfc2961>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou,
"Node-ID Based Resource Reservation Protocol (RSVP) Hello: "Node-ID Based Resource Reservation Protocol (RSVP) Hello:
A Clarification Statement", RFC 4558, A Clarification Statement", RFC 4558,
DOI 10.17487/RFC4558, June 2006, DOI 10.17487/RFC4558, June 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4558>. editor.org/info/rfc4558>.
[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
GMPLS Resource Reservation Protocol (RSVP) Graceful GMPLS Resource Reservation Protocol (RSVP) Graceful
Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
<http://www.rfc-editor.org/info/rfc5063>. <https://www.rfc-editor.org/info/rfc5063>.
7.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of
Scaling Issues in MPLS-TE Core Networks", RFC 5439, Scaling Issues in MPLS-TE Core Networks", RFC 5439,
DOI 10.17487/RFC5439, February 2009, DOI 10.17487/RFC5439, February 2009, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5439>. editor.org/info/rfc5439>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
Appendix A. Recommended Defaults Appendix A. Recommended Defaults
(a) Refresh-Interval (R)- 20 minutes (Section 2.2). (a) Refresh-Interval (R)- 20 minutes (Section 3).
Given that an implementation supporting RI-RSVP doesn't rely on Given that an implementation supporting RI-RSVP doesn't rely on
refreshes for state sync between peers, the function of RSVP refreshes for state sync between peers, the function of RSVP
refresh interval is analogous to that of IGP refresh interval (the refresh interval is analogous to that of IGP refresh interval (the
default of which is typically in the order of 10s of minutes). default of which is typically in the order of 10s of minutes).
Choosing a default of 20 minutes allows the refresh timer to be 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 randomly set to a value in the range [10 minutes (0.5R), 30
minutes (1.5R)]. minutes (1.5R)].
(b) Node Hello-Interval - 9 Seconds (Section 2.2). (b) Node Hello-Interval - 9 Seconds (Section 3).
[RFC3209] defines the hello timeout as 3.5 times the hello [RFC3209] defines the hello timeout as 3.5 times the hello
interval. Choosing 9 seconds for the node hello-interval gives a interval. Choosing 9 seconds for the node hello-interval gives a
hello timeout of 3.5*9 = 31.5 seconds. This puts the hello hello timeout of 3.5*9 = 31.5 seconds. This puts the hello
timeout value in the vicinity of the IGP hello timeout value. timeout value in the vicinity of the IGP hello timeout value.
(c) Retry-Limit (Rl) - 7 (Section 2.3). (c) Retry-Limit (Rl) - 7 (Section 4).
Choosing 7 as the retry-limit results in an overall rapid Choosing 7 as the retry-limit results in an overall rapid
retransmit phase of 31.5 seconds. This matches up with the 31.5 retransmit phase of 31.5 seconds. This matches up with the 31.5
seconds hello timeout. seconds hello timeout.
(d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3). (d) Periodic Retransmission Interval - 30 seconds (Section 2.3).
If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7 If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7
rapid retransmit steps to max out (The last delay from message 6 rapid retransmit steps to max out (The last delay from message 6
to message 7 is 16 seconds). After the 7 rapid retransmit steps to message 7 is 16 seconds). After the 7 rapid retransmit steps
are maxed out, the router starts periodic retransmission on a are maxed out, the router starts periodic retransmission on a
slower timer. This document recommends the use of the traditional slower timer. This document recommends the use of the traditional
default refresh interval value of 30 seconds for this periodic default refresh interval value of 30 seconds for this periodic
retransmission interval. retransmission interval.
Authors' Addresses Authors' Addresses
 End of changes. 61 change blocks. 
125 lines changed or deleted 141 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/