CCAMP Working Group JL Le Roux
Internet Draft JY Mazeas
France Telecom
JP Vasseur
Sami Boutros
Cisco Systems
Category: Standard Track
Expires: July 2005 February 2005
Procedure to handle (G)MPLS-TE control plane saturation
draft-leroux-ccamp-ctrl-saturation-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or IPR claims of which I am aware have been disclosed, or will
be disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Le Roux, et al. Standard Track - Expires July 2005 [Page 1]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
Abstract
This document defines extensions to RSVP-TE (Resource Reservation
Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
signal control plane resources saturation, when an LSR runs out of
control plane resources available to support a new LSP. Such
notification may serve as trigger for the impacted Head-end LSR to
take appropriate actions.
Table of Contents
1. Introduction................................................3
2. Terminology.................................................4
3. RSVP-TE Saturation..........................................4
4. Signalling extensions.......................................5
4.1. New RSVP Error Code.........................................5
4.2. Mode of operations..........................................5
4.2.1. Procedures for a saturated LSR (Transit or Tail)............5
4.2.2. Procedures for a Head-End LSR...............................5
5. Routing extensions..........................................6
5.1. Encoding of the Saturation TLV..............................6
5.2. Elements of procedure.......................................7
6. Security Considerations.....................................7
7. Acknowledgements............................................7
8. Intellectual Property Statement.............................7
8.1. IPR Disclosure Acknowledgement..............................8
9. References.................................................8
9.1. Normative references........................................8
9.2. Informative references......................................9
10. Authors' Address:...........................................9
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.
Le Roux, et al. Standard Track - Expires July 2005 [Page 2]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
1. Introduction
Many service providers have deployed RSVP-TE [RFC3209] to setup TE-
LSPs and achieve Traffic Engineering objectives.
In some circumstances, MPLS-TE deployments in large networks may
require maintaining a high number of TE-LSPs on transit LSRs and thus
instantiating a high number of RSVP states, and consuming a large
amount of LSR resources such as memory and CPU.
Control plane capacities of an LSR (such as CPU or memory) are of
course not infinite, and there may be some circumstances whereby an
LSR may run out of a specific resource such as memory or CPU
available for the RSVP process; such resource shortage may lead to
the inability for the LSR to support signalling of new LSPs. For
instance, the LSR has no longer enough memory to instantiate a new
RSVP state block (PSB, RSB [RFC2209]), and thus cannot maintain a new
LSP. In such situation, the saturated LSR should properly reject the
LSP setup, and notify the head-end LSR about its saturation.
Note that it may also be useful to allow the operator to limit (by
configuration) the maximum number of RSVP-TE sessions that can be
maintained by an LSR, at Ingress, Transit or Egress.
This allows controlling the impact of RSVP-TE on other control plane
entities.
This document defines a particular state for an RSVP node, called the
"Saturated" state. An RSVP node is said saturated, when it cannot
support an additional TE-LSP, either because the maximum number of
RSVP sessions configured by the operator is reached or because there
is no longer enough resources (CPU, memory,à) allocated to the RSVP
process, to instantiate and maintain a new session state block. There
may be cases, particularly in large scale RSVP-TE deployments, where
an LSR receives a Path message for a new LSP, while it is saturated.
This document specifies:
- a RSVP-TE extension allowing a saturated RSVP node to reject any
new LSP and notify (using a new Error code and a set of sub-codes
carried in a Path Error message) the head-end LSR about its
saturation.
- IGP extensions (that complement the RSVP-TE extension) in order for
a LSR to advertise its current saturation state (saturated or not).
This allows head-end LSRs avoiding the set up of new TE LSP through
saturated nodes and also allows reoptimizing TE-LSPs when a given
node is no longer saturated.
Le Roux, et al. Standard Track - Expires July 2005 [Page 3]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
2. Terminology
LSR: Label Switching Router
TE-LSP: MPLS Traffic Engineering Label Switched Path
RSVP-TE Saturation: State of an LSR that cannot accept any new TE-LSP
due to control plane limitations
3. RSVP-TE Saturation
Some RSVP-TE deployment scenarios may generate a high number of RSVP
sessions on transit LSRs, and consume a significant amount of
resources (such as memory and CPU). Depending on LSR control plane
capacities, there may be cases where an LSR is not able to support
any new TE LSPs for a specific amount of time. Of course, note that
such state may be transitional and this document proposes mechanism
to signal that the node is no longer in such state by means of
routing extensions.
An RSVP node enters the saturated state when it runs out of a
specific resource such as the memory or CPU (globally or for the RSVP
process) or some other constraints are reached (for the sake of
illustration, this can be the number of transiting LSPs which can
influence the rerouting time in case of failure with some network
recovery techniques).
A saturated LSR MUST reject the setup of a new TE-LSP, and SHOULD
maintain already established TE-LSPs.
Note that it is recommended to introduce some hysteresis for
saturation state transition, in order to avoid oscillations.
For instance in case the number of TE-LSPs is bounded, two thresholds
could be configured:
The upper-threshold: An LSR enters the saturated when the number
of TE-LSPs reaches the upper-threshold.
The lower-threshold: An LSR leaves the saturated state when the
number of TE-LSPs goes below the lower-threshold.
Le Roux, et al. Standard Track - Expires July 2005 [Page 4]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
4. Signalling extensions
4.1. New RSVP Error Code
This document specifies a new Error Code (suggested value
to be confirmed by IANA) for the RSVP ERROR_SPEC object:
26 Control Plane Saturation
The following defines error values sub-codes for the new Control
Plane Saturation Error Code:
1 Saturation unspecified
2 Memory saturation
3 CPU saturation
100-255 Proprietary
Procedures are detailed in section 4.2 below.
4.2. Mode of operations
4.2.1. Procedures for a saturated LSR (Transit or Tail)
On receipt of a Path message for a new LSP, a saturated LSR compliant
with this document MUST reject the LSP setup and send back a Path
Error Message with the Error Code "Saturation" and optionally a sub-
code mentioning the reasons for the saturation.
The Error node address carried within the ERROR_SPEC object MUST be
set to the TE router id.
4.2.2. Procedures for a Head-End LSR
On receipt of a Path Error message with the Error Code "Saturation"
and with the PSR flag not set, the Head-End LSR SHOULD send a Path
Tear message for the LSP.
The head-end LSR should trigger the computation of a new path
avoiding the saturated node, and it may also choose to avoid the
saturated node for future LSPs. An implementation may decide to
signal some of its TE LSPs along the saturated node upon the
expiration of some timer.
The head-end should not reroute already established LSPs passing
through the saturated node.
Le Roux, et al. Standard Track - Expires July 2005 [Page 5]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
5. Routing extensions
It is obviously desirable to augment the signaling extensions by
routing notifications ([ISIS-TE], [OSPF-TE]) that would allow an LSR
to advertise the state of its RSVP process (saturated or not). This
information could then be taken into account by all LSRs (and not
only LSRs on the path of a rejected LSPs), in order to avoid a
saturated node when computing the path of a new TE-LSP, and also to
automatically discover when a node is no longer saturated and
potentially trigger appropriate TE-LSP reoptimisation.
A new TLV is defined for OSPF and ISIS, named the ôSaturation TLVö,
to be included in the Router Information LSA for OSPF [OSPF-CAP] and
in the CAPABILITY TLV for ISIS [ISIS-CAP].
This TLV contains a set of 32 bit flags. Currently only one flag is
defined, to indicate if the LSR is saturated or not.
5.1. Encoding of the Saturation TLV
This document defines a new TLV, the Saturation TLV, allowing an LSR
advertising if its control plane is saturated or not, where,
-With OSPF, the Saturation TLV is a TLV of the Router Information
LSA defined in [OSPF-CAP], and its TLV type is TBD.
-With ISIS, the Saturation TLV is a sub-TLV of the ISIS CAPABILITY
TLV defined in [ISIS-CAP], and its sub-TLV type is TBD.
All relevant generic TLV encoding rules (including TLV format,
padding and alignment, as well as IEEE floating point format
encoding) defined in [OSPF] and [ISIS] are applicable to this new
sub-TLV.
The Saturation TLV is a series of 32 bit flags. Its format is
illustrated below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only one bit is currently defined:
-S bit: When set this indicates that the node is saturated and
cannot support new TE-LSPs. When not set this indicates that the node
is not saturated and can support new TE-LSPs.
New flags may be defined in the future to indicate the reasons for
the saturation.
Le Roux, et al. Standard Track - Expires July 2005 [Page 6]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
5.2. Elements of procedure
A router MUST originate a new IS-IS LSP/OSPF LSA whenever a
saturation state change occurs or whenever required by the
regular IS-IS/OSPF procedure (LSP/LSA refresh).
A saturated node MUST originate LSPs/LSAs with the S bit of the
Saturation TLV set.
Note that a head-end LSR computing a path of a TE-LSP should avoid
saturated nodes. Note also that when a head-end LSR detects that a
node on the path of an already established TE-LSP, becomes saturated,
it should not reroute this TE-LSP.
Once an LSR leaves the saturation state, the condition of which are
implementation specific, it MUST originate LSPs/LSAs with the S bit
of the Saturation TLV cleared. An implementation may decide to
originate an LSP/LSP with the S bit of its Saturation TLV cleared for
a configurable amount of time and then decide not to include the
saturation TLV in its LSA/LSP.
Note that when a head-End LSR detects that an LSR is no longer
saturated it may try to reoptimize TE-LSPs, should the path along the
no-longer saturated node be optimal. This procedure may be delayed,
potentially using some LSP setup jittering between head-end LSRs, in
order to avoid a signalling storm that may again saturate the node,
that is, to avoid TE-LSP routing oscillations.
6. Security Considerations
This document does not raise any new security issue.
7. Acknowledgements
We would like to thank Thomas Morin and Bruno Decraene for the really
useful comments and suggestions, and Muthurajah Sivabalan, Rudy
Figaro, David Ward, Reshad Rahman, and Stefano Previdi for their
input and contributions to the IGP extensions.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Le Roux, et al. Standard Track - Expires July 2005 [Page 7]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
8.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
9. References
9.1. Normative references
[RFC] Bradner, S., 'Key words for use in RFCs to indicate
requirements levels', RFC 2119, March 1997.
[RFC3667] Bradner, S., 'IETF Rights in Contributions', BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., 'Intellectual Property Rights in IETF
Technology', BCP 79, RFC 3668, February 2004.
[TE-REQ] Awduche et. al., 'Requirements for Traffic Engineering
over MPLS', RFC2702.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
'Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification', RFC 2205, September 1997.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, 'RSVP-TE: Extensions
to RSVP for LSP Tunnels', RFC 3209, December 2001.
[RFC2209] Braden, R., Zhang, L., 'Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules', RFC2209,
September 1997.
Le Roux, et al. Standard Track - Expires July 2005 [Page 8]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
[ISIS] "Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol " ISO 10589.
[ISIS-TE] Smit, H., Li, T., 'Intermediate System to Intermediate
System (IS-IS)Extensions for Traffic Engineering (TE)',
RFC3784, June 2004
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPF-TE] Katz, D., Kompella, K., Yeung, D., 'Traffic Engineering
(TE) Extensions to OSPF Version 2', RFC3630, September 2003
9.2. Informative references
[ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N. et al. "IS-IS
extensions for advertising router information", draft-
vasseur-isis-caps-02.txt, work in progress.
[OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur,
J.P., "Extensions to OSPF for advertising Optional Router
Capabilities", draft-ietf-ospf-cap-05.txt, work in progress.
10. Authors' Address:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
jeanlouis.leroux@francetelecom.com
Jean-Yves Mazeas
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
jeanyves.mazeas@francetelecom.com
Jean-Philippe Vasseur
CISCO Systems, Inc.
300 Beaver Brook
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Sami Boutros
Cisco Systems
Le Roux, et al. Standard Track - Expires July 2005 [Page 9]
Internet Draft draft-leroux-ccamp-ctrl-saturation-00.txt February 2005
2000 Innovation Drive, Kanata,
Ontario, Canada K2K 3E8
sboutros@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Le Roux, et al. Standard Track - Expires July 2005 [Page 10]