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]