Network Working Group S. Okamoto Internet Draft Keio University Intended status: Informational June 27, 2011 Expires: December 2011 Requirements of GMPLS Extensions for Energy Efficient Traffic Engineering draft-okamoto-ccamp-midori-gmpls-extension-reqs-00.txt 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), 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 This Internet-Draft will expire on December 27, 2011. Copyright Notice Copyright (c) 2011 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. Abstract Okamoto Expires December 27, 2011 [Page 1] Internet-Draft Energy Efficient Traffic Engineering June 2011 This document discusses some of extensions required in existing GMPLS OSPF routing protocol, RSVP signaling protocol, and LMP to support the energy efficient traffic engineering technology. Table of Contents 1. Introduction ................................................ 2 1.1. Conventions used in this document ....................... 3 2. Energy efficient traffic engineering extensions .............. 3 2.1. TE link status ......................................... 3 2.2. LSP status ............................................. 4 2.3. Link power on/off control ............................... 4 3. Security Considerations ...................................... 5 4. IANA Considerations ......................................... 5 5. References .................................................. 5 5.1. Normative References .................................... 5 5.2. Informative References .................................. 6 6. Acknowledgments ............................................. 6 1. Introduction The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] protocol suite is designed to provide a control plane for a range of network technologies including packet/frame switching networks including MPLS routers and Ethernet switches, optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. In GMPLS controlled networks, the network is described by label switch routers (LSRs) and traffic engineering (TE) links. A TE link is advertised as an adjunct to a "physical" link. When the link is up, both the regular Internal Gateway Protocol (IGP) properties of the link (basically, the Shortest Path First (SPF) metric) and the TE properties of the link (such as bandwidth and switching capability) are then advertised. Therefore, basically, if the link is down then the TE link is also down. A TE link is not only defined between IGP neighbors but also defined on a Forwarding Adjacency (FA) label switched path (LSP). An LSP is composed with cross-connection of TE links. Therefore, if the composed TE link is down then the LSP is also down. Energy efficient traffic engineering technology is discussed in [1, 2]. Under the energy efficient traffic engineering, LSPs are rerouted to use lest number of links, then some links are physically shutdown to reduce power consumption of equipment. In traditional GMPLS Okamoto Expires December 27, 2011 [Page 2] Internet-Draft Energy Efficient Traffic Engineering June 2011 networks, TE links associated in shutdown links are also down. Therefore, when emergency occurred, such as traffic explosion and link/equipment failure, downed TE links are not able to use for calculating protection LSP and LSP rerouting. This document defines requirements for extending GMPLS protocols to support the energy efficient traffic engineering features. 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 RFC-2119 [RFC2119]. 2. Energy efficient traffic engineering extensions Protocol extensions of OSPF, RSVP, and Link Management Protocol (LMP) are required to support new TE link status, new LSP status, and link power on/off capability. 2.1. TE link status [RFC2328] defines Interface states for describing "Interface State changes" and "Interface State Machine". A link status "Up" and "Down" can be get from the Interface states. [RFC3630] defines the Traffic Engineering properties of TE links and defines Link Type/Length/Value (TLV) for TE link properties advertisement. A Link-TLV has some sub-TLVs, however, there is no TE link status information. [RFC4203] adds some sub-TLVs to the Link-TLV in support of GMPLS. As a conclusion, a TE link does not have any status indication. If Link becomes down then value(s) of the Traffic Engineering Metric sub-TLV, and/or the Maximum bandwidth sub-TLV, and/or the Maximum Reservable Bandwidth sub-TLV in associated TE links are changed according with the network operator's policy. Under the energy efficient TE environment, the link down by administrative operation or link failure, and link power down by the energy efficient TE should be distinguished in the route calculation system such as Constraint Shortest Path First (CSPF) and Path Computation Entity (PCE). A TE link state sub-TLV which indicates power off state of the TE link is required. Okamoto Expires December 27, 2011 [Page 3] Internet-Draft Energy Efficient Traffic Engineering June 2011 2.2. LSP status [RFC3471], [RFC3473], and [RFC4974] defines the Administrative Status Information in the Admin_Status object. The defined status bits are Reflect (R), Testing (T), Administratively down (A), Deletion in progress (D), and Call Management (C). In the energy efficient TE environment, an LSP which includes power off TE link(s) as LSP component can be defined. This LSP can be assigned as a backup LSP. The backup LSP which does not contain power of link(s) can be used as 1+1 protection, 1:N protection w/wo extra traffic, shared protection, and restoration. On the other hand, the backup LSP which contains power off link(s) can be used as 1:N protection wo extra traffic, shared protection, and restoration. When activating the LSP, power up of link(s) is required. To distinguish the backup LSP which contains the power off link(s) or not, new LSP status should be defined in the Admin_Status object. 2.3. Link power on/off control The energy efficient TE requires link power on/off control function. There are two possible implementation, one is using LMP the other is using RSVP. When using LMP, power on (or off) initiator LSR sends power on (or off) request to the neighbor LSR. The neighbor LSR sends Ack to the initiator LSR and power on (or off) the link and changes the TE link status. Then the initiator LSR receives Ack and power on (or off) the link and changes the TE link status. The power control should be included to the LMP. Note: to apply the power on procedure, IP control channel (IPCC) should be always up. Therefore, a dedicated IPCC is required to apply the LMP control. When using RSVP, sequentially concatenated TE links can be controlled. There are two procedure candidates in the power off procedure. [Power On] All TE links along with the LSP are power on. [Power Off] 1. All TE links along with the LSP are power off. If other LSPs share the TE links then the LSPs should be rerouted. Okamoto Expires December 27, 2011 [Page 4] Internet-Draft Energy Efficient Traffic Engineering June 2011 2. All TE links but not shared by other LSPs are power off. Both procedures are used according with the network operator's policy. Power control request may be implemented in the Admin_Status object. 3. Security Considerations TBD 4. IANA Considerations TBD 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3945] Mannie, E. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Enginnering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4203] Kompella, K., and Rekhter, Y. (Editors), "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4974] Papadimitriou, D., and Farrel, A., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions", RFC 4974, August 2007. Okamoto Expires December 27, 2011 [Page 5] Internet-Draft Energy Efficient Traffic Engineering June 2011 5.2. Informative References [1] Yonezu, H., Kikuta, K., Ishii, D., Okamoto, S., Oki, E., and Yamanaka, N., "QoS Aware Energy Optimal Network Topology Design and Dynamic Link Power Management", Proc. ECOC 2010 Tu.3.D.4. [2] Cerutiti I., Sambo, N., and Castoldi, P., "Distributed support of link sleep mode foe energy efficient GMPLS networks", Proc. ECOC 2010 P5.11. 6. Acknowledgments The author would like to thank Prof. Naoaki Yamanaka for their useful comments and suggestions. Author's Addresses Satoru Okamoto Keio University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Email: okamoto@ieee.org Okamoto Expires December 27, 2011 [Page 6]