Internet DRAFT - draft-qin-teas-sl-rsvp
draft-qin-teas-sl-rsvp
Network Working Group J. Qin
Internet-Draft D. Sun
Intended status: Informational J. Dong
Expires: July 1, 2017 X. Wei
M. Chen
Huawei Technologies
December 28, 2016
Architecture for Stateless RSVP
draft-qin-teas-sl-rsvp-00
Abstract
RSVP takes a "soft state" scheme to manage the reservation states in
routers and hosts, the soft states are created and periodically
refreshed by Path and Resv messages. Soft state scheme gives a
simple way to maintain the state synchonization between neighbors,
but also introduces scalability issue. This document provides a
framework that describes and discusses the architecture for stateless
RSVP (SL-RSVP), which disabled the soft-state scheme to improve the
protocol scalability and the other processes of RSVP are kept. This
document does not describe specific protocols or protocol extensions
needed to realize this architecture.
Requirements Language
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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."
This Internet-Draft will expire on July 1, 2017.
Qin, et al. Expires July 1, 2017 [Page 1]
Internet-Draft SL-RSVP December 2016
Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of SL-RSVP . . . . . . . . . . . . . . . . . . . . 3
2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Basic Idea of SL-RSVP . . . . . . . . . . . . . . . . . . 4
2.3. Responsbility of the Controller . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Generic Architecture . . . . . . . . . . . . . . . . . . 5
3.2. Deployment Considerations . . . . . . . . . . . . . . . . 6
4. Operation Overview . . . . . . . . . . . . . . . . . . . . . 6
4.1. LSP States Collection . . . . . . . . . . . . . . . . . . 6
4.2. Procedures of LSP States Deletion . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
RSVP (TE) protocol[RFC2205] [RFC3209] is designed to establish
constraint-based LSP or QoS supported LSP that guarantee subscriber's
quality requriements or apply network operator's policy. The soft
state scheme in the protocol gives a simple way to maintain the state
synchronization between neighbors, but introduces scalability issue.
It is found that with the increase of the number of LSPs the
processing overhead becomes considerable. In extreme cases it is
possible that the bandwidth guarantee of some LSPs may not be kept
and that some packets are dropped even if the total bandwidth
requirements are smaller than the available bandwidth.
[RFC2961] standardizes an RSVP extension which is referred to as
Refresh Overhead Reduction to improve the soft-state scalability.
Qin, et al. Expires July 1, 2017 [Page 2]
Internet-Draft SL-RSVP December 2016
Although the refresh reduction approaches may substantially improve
the scalability issue, however, it has also been observed that under
the circumstance of huge number of LSPs (tens of thousands), the size
of the Srefresh may become very large, and analysis of existing
implementations [RFC5439] indicates that the processing required may
still cause significant disruption to an LSR.
[RFC3175] proposes to aggregate multiple reservations into a single
RSVP reservation across a transit domain or a routing region.
However, as explained in the document, aggregated RSVP sessions are
merely fatter RSVP reservations, when the number of session increases
same scalability problem as ordinary RSVP [RFC2205] will be induced.
Increasing the refresh time is another approach
[I-D.ietf-teas-rsvp-te-scaling-rec], but it should be noted that
regular refreshing is the nature of the soft-state scheme, when the
refresh interval is increasing, a degree of functionality is lost
[RFC5439]. Although the methods in
[I-D.ietf-teas-rsvp-te-scaling-rec] increases the referesh interval
into a fairly large value, however, the periodically refreshing is
not totally abolished, the protocol still relies on refreshing.
This document provides a framework that describes and discusses the
architecture for stateless RSVP (SL-RSVP), in the framework soft-
state scheme is disabled , the periodically refreshing of Path and
Resv messages will be abolished. Meanwhile, the central controller
(which may already exist in the network) is used to solve the
possibly caused problems due to the removing of the periodically
refreshing. It is known that, SDN provides flexibility and
programmability for the network to dynamically adapt to a wide range
of customer's requirements. Taking into account the smooth
transition from existing network to the new SDN enabled network, it
is a good choice to reuse the centralized controller of SDN. It not
only achieves the goal of realizing the centralized control, but also
leverages the existing network architecture and components. The
reliable message delivery mechanism specified in [RFC2961] is the
basis of SL-RSVP.
The case with TE fast reroute is not considered in SL-RSVP, it is out
of scope of this document. This document does not describe specific
protocols or protocol extensions needed to realize the framework.
2. Definition of SL-RSVP
Qin, et al. Expires July 1, 2017 [Page 3]
Internet-Draft SL-RSVP December 2016
2.1. Motivation
RSVP protocol has been widely depolyed in IP core, DCI and GMPLS
networks. Using RSVP network operators could achieve end-to-end LSP
tunnel management and performance guarantee. Traffic monitoring and
priority distinction can also be performed on intermediate nodes.
However, Observations of existing implementations indicate that there
maybe a threshold of around tens of thousands of LSPs above which an
LSR struggles to achieve sufficient processing to maintain LSP state.
As some operators' analysis, to make the PE nodes of the DCI cover
the main cities of the country, considering the full mesh of LSPs
across the PE nodes, the intermediate P nodes need to support the
processing of at least tens of thousands LSPs. It is a big challenge
to maintain the successful processing of this scale of LSPs with the
existing soft-state scheme. To meet the processing requirements of
huge number of LSPs in the near future, it is quite impending to
promote the scalability of RSVP.
2.2. Basic Idea of SL-RSVP
To relieve the processing burden of RSVP protocol, stateless RSVP
(SL-RSVP) is proposed, in which stateless means that the traditional
soft-state scheme in RSVP is disabled, there's no periodically
refreshing of Path and Resv messages and the corresponding cleanup
time interval is not needed. The value of the cleanup time could be
set zero or infinity. SL-RSVP turns RSVP from "soft-state" into
"hard-state". Path and Resv messges will be send only in the
situation that there's new changes in LSP states or requested message
retransmission. SL-RSVP is based on acknowledgement and reliable
RSVP message transmissions as defined in [RFC2961]. Meanwhile,
leveraging the existing central controller like the controller in SDN
network to solve the possibly caused problems when the refreshing is
removed. The central controller in SL-RSVP only do the compensating
works, the signaling process is not the work of the controller.
Signaling will be executed in every node along the LSP as traditional
RSVP does.
2.3. Responsbility of the Controller
In RSVP protocol, with soft-state approach, the LSP states on every
LSR will be periodically refreshed by Path and Resv messages. After
a state change or at the expiration of each "refresh timeout", RSVP
scans its states to forward or build Path and Resv refresh messages
to succeeding hops. The functionality of soft-state scheme is to
keep states consistency on each LSR along the LSP. When the soft-
state scheme is disabled in SL-RSVP, the problem need to handle is
the potential inconsistency of states that caused by the occasional
message losses during the transmission. The controller will be used
Qin, et al. Expires July 1, 2017 [Page 4]
Internet-Draft SL-RSVP December 2016
to solve this problem. In the case of Path or Resv message loss,
when the retransmission limit Rl as specified in section 6[RFC2961]
has been reached, the router may start periodic retransmission of
these messages. This periodic retransmission should continue until
an appropriate acknowledgement of the retransmitted Path/Resv message
is received, during this time the controller need no action. When
PathTear or ResvTear message is lost, it will cause residual states
on the nodes that behind the lost position. Usually these residual
states will be deleted after the expiration of the cleanup timeout
interval in RSVP, but when there's no refresh and cleanup timeout
interval, these residual states could not be deleted. In SL-RSVP, it
is the responsibility of the controller to help with the deletion of
the residual RSVP states on the nodes along the LSP.
In SL-RSVP, by leveraging the controller, the LSRs can be released
from soft-state maintenance. As the signaling is still based on
RSVP, so it is easy to meet the requirements of network evolution.
3. Architecture
This section gives the architecture of SL-RSVP, the considerations
and conclusions described in the previous section lead to the
architecture described in this section.
3.1. Generic Architecture
The following diagram illustrates the SL-RSVP architecture. The
controller locates external to the requesting network nodes, its
functionality is to help deleting the residual RSVP states on the
nodes. There's no periodically refreshing between neighbor LSRs
while keeping the other process of RSVP. When the controller
perceives the failure of one LSP, it will issue deleting instructions
to every LSR of the LSP, so it needs to have logical sessions with
each of the node in the network to enable the deleting process. In
the controller, LSP-Database and TE-Database are maintained.
Qin, et al. Expires July 1, 2017 [Page 5]
Internet-Draft SL-RSVP December 2016
+------------------------------------------------+
| SL-RSVP controller |
| +-------------------------------------+ |
| | +---------+ +---------+ | |
| | | LSP-DB | | TE-DB | | |
| | +---------+ +---------+ | |
| ^-------------------------------------^ |
| | | | |
| V V V |
| +------+ RSVP +------+ RSVP +------+ |
| |Node 1| ........ |Node 2| ........ |Node 3| |
| +------+ no refresh+------+ no refresh+------+ |
+------------------------------------------------+
Figure 1. Architecture of SL-RSVP
3.2. Deployment Considerations
There exists different kinds of depolyment architecture in network
which differs in reliability and deployment complexity. No matter
using which kind architecture, message acknowledgement scheme is
needed to ensure the reliable communication between the controller
and the LSRs.
4. Operation Overview
4.1. LSP States Collection
Using RSVP protocol, the LSPs can be created by the head-end LSR or
the controller (like PCE [I-D.ietf-pce-pce-initiated-lsp]). No
matter in which situation, LSP states reporting process is
compulsory, both the head-end LSR and the other nodes along the LSP
should report the LSPs' states to the controller, only the controller
have the LSPs' states information it can help deleting the residual
states on LSP nodes. The report of LSP states may be based on
existing protocols such as BGP-LS[RFC7752], PCEP[RFC5440], etc. By
comparing the states reported by the head-end LSR and the other LSRs
the controller can know the location of the residual states.
4.2. Procedures of LSP States Deletion
The capability of deleting the LSP states needs to be negotiated at
the beginning of the session between the controller and the nodes to
determine whether the controller can help with the deletion. When
there's failure on an LSP, the LSP initiator may try to tear the LSP.
Due to the failure, PathTear/ResvTear messages may not be
successfully delivered, it could cause residual states on some nodes
of the LSP. In this situation, when the controller perceives the LSP
failure and gets the permission of deletion by the LSP initiator, it
Qin, et al. Expires July 1, 2017 [Page 6]
Internet-Draft SL-RSVP December 2016
identifies the nodes which contain residual states and then send the
deletion messages. The LSP failure can be perceived by the
controller through interior gateway protocol, OAM or intermediate
nodes reporting. When the residual states on the nodes has been
successfully deleted, acknowledgement messages need to be sent to the
controller. To keep the reliability of the session between the
controller and the intermediate nodes of the LSPs, survivability
schemes need to be used.
The controller could do the deletion process later after perceiving
the LSP failure. In other words, the LSP state deletion could be
delayed by the controller. The delay time can be determined by
operator. Delay deleting is helpful to avoid the performance
bottleneck of the controller caused by numerous concurrent deleting
request.
In the situation of session failure between the controller and the
LSRs or unexpected breakdown of the controller or LSRs, a state
synchronization process is indispensable after the recovery. The
residual states found after synchornization will be deleted. In
normal cases, when finding residual LSP states the controller will
send deletion messages to the LSRs of the LSP directly to delete the
residual states.
5. Security Considerations
TBD.
6. Acknowledgements
TBD.
7. Informative References
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-07 (work in
progress), July 2016.
[I-D.ietf-teas-rsvp-te-scaling-rec]
Beeram, V., Minei, I., Shakir, R., Pacella, D., and T.
Saad, "Implementation Recommendations to Improve the
Scalability of RSVP-TE Deployments", draft-ietf-teas-rsvp-
te-scaling-rec-03 (work in progress), October 2016.
Qin, et al. Expires July 1, 2017 [Page 7]
Internet-Draft SL-RSVP December 2016
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<http://www.rfc-editor.org/info/rfc2961>.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, DOI 10.17487/RFC3175, September 2001,
<http://www.rfc-editor.org/info/rfc3175>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of
Scaling Issues in MPLS-TE Core Networks", RFC 5439,
DOI 10.17487/RFC5439, February 2009,
<http://www.rfc-editor.org/info/rfc5439>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.
Authors' Addresses
Qin, et al. Expires July 1, 2017 [Page 8]
Internet-Draft SL-RSVP December 2016
Jun Qin
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: qinjun4@huawei.com
Dongzhi Sun
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: sundongzhi@huawei.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Xiugang Wei
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: weixiugang@huawei.com
Mach Chen
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: mach.chen@huawei.com
Qin, et al. Expires July 1, 2017 [Page 9]
