idnits 2.17.00 (12 Aug 2021) /tmp/idnits22170/draft-dong-panet-requirement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o The transition between different energy modes SHOULD not cost a lot of energy, otherwise there will not be no much benefit of transiting between different energy modes. -- The document date (October 16, 2013) is 3132 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-eman-requirements' is defined on line 263, but no explicit reference was found in the text == Outdated reference: draft-ietf-eman-requirements has been published as RFC 6988 == Outdated reference: A later version (-03) exists of draft-retana-rtgwg-eacp-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: April 19, 2014 B. Zhang 6 The University of Arizona 7 M. Boucadair 8 France Telecom 9 October 16, 2013 11 Requirements for Power Aware Network 12 draft-dong-panet-requirement-02 14 Abstract 16 Energy consumption of networks is rising fast, which results in the 17 increase of network operational costs. There are emerging demands 18 from operators for power-aware networking (PANET) which could 19 adaptively reduce the network energy consumption when possible. This 20 document presents the requirements which should be considered in 21 building a power aware network. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 19, 2014. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements on Network Elements . . . . . . . . . . . . . . 3 64 3. Requirements on the Whole Network . . . . . . . . . . . . . . 3 65 4. Requirements on Network Control Plane . . . . . . . . . . . . 5 66 5. Requirements on Management Plane . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 9.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 With the increase of network services and exponential growth of 78 traffic volume, the network operators are expanding their 79 infrastructures with more high-capacity, full-featured network 80 devices, which also leads to the increase of network energy 81 consumption. Besides, today's service provider networks are mostly 82 designed for high performance and reliability, without much 83 consideration of energy efficiency. These networks usually have 84 redundant routers and links, over-provisioned link capacity, and 85 multiple paths for load-balancing and protection, which make the 86 networks far from energy efficient. As energy price continues to 87 rise, the increasing network energy consumption becomes a significant 88 portion of the network operational costs. The energy consumption 89 problem in service provider networks is detailed in 90 [I-D.zhang-panet-problem-statement]. Some use cases of reducing 91 network energy consumption are described in 92 [I-D.zhang-panet-use-cases]. 94 While energy consumption has become an important issue, network 95 operators are very cautious about energy conservation solutions due 96 to the concerns about the potential impacts on the network 97 performance and resiliency. 99 This document presents a set of requirements for building a Power 100 Aware NETwork (PANET) while meeting operators' requirements on 101 performance and resiliency. 103 2. Requirements on Network Elements 105 Today's network elements are mostly designed for high throughput and 106 availability. With the increase of throughput capacity, energy 107 consumption of network element is also rising accordingly. Since 108 most of time the network elements in the network would not work in 109 the full loaded state, if the energy consumption of network elements 110 could be proportional to the carried traffic load, energy 111 conservation could be achieved. Typically after a network element is 112 turned on, the base energy consumption is relatively high, and the 113 energy consumption of the device does not vary a lot from zero load 114 state to full loaded state. While there has been a lot of efforts 115 aiming at making the energy consumption of network device 116 proportional to the load it carries, it is not quite easy for the 117 network elements getting to this stage in the near term. 119 Thus for near term energy saving, In practical the network elements 120 should meet the following requirements: 122 o Network elements should support a set of energy saving modes (e.g. 123 sleeping mode, etc. as defined in IETF EMAN working group). The 124 energy consumption under energy saving modes should be much lower 125 than that under the normal mode. 127 o Network elements should support the report of energy consumption 128 and state information. 130 o The transition between different energy modes SHOULD not cost a 131 lot of energy, otherwise there will not be no much benefit of 132 transiting between different energy modes. 134 o Network elements should support the transition between different 135 energy modes within acceptable time period, e.g. subsecond. 137 o Network elements should support some approach of reducing the 138 packet loss during the transition of energy modes. 140 3. Requirements on the Whole Network 141 While energy awareness and conservation of individual network element 142 is fundamental, currently there are many limits in reducing the 143 energy consumption at network element level. Besides, different from 144 terminal devices like PC and mobile phones, network elements usually 145 cannot be shut down arbitrarily as this may affect the services 146 carried in the network. Thus mechanisms which could reduce the 147 energy consumption from the whole network point of view should also 148 be considered. 150 Most of the existing networks are over-provisioned for better service 151 performance and redundancy, which means they are not energy efficient 152 by default. In order to save energy, the entire network should 153 become power aware, then it can make appropriate decisions to save 154 energy when possible. Since in most time the network does not carry 155 the peak traffic volume, which means there is chance for the network 156 to coordinate network elements and create opportunity for some of the 157 network elements to enter energy saving modes. Meanwhile, reducing 158 energy consumption of the network should not undermine the 159 performance of services carried by the network. 161 For energy conservation of the whole network, the network should meet 162 the following requirements: 164 o The network should try to keep all the active network elements 165 with a reasonable utilization rate, network elements with low 166 utilization should be informed to enter energy saving modes. For 167 example, the network elements with utilization lower than specific 168 threshold may be put into low rate mode to reduce energy 169 consumption, or the traffic carried by these network elements may 170 be migrated to other paths such that these network elements could 171 be put into sleeping mode. 173 o With energy conservation, the network should retain enough network 174 availability and resiliency against node and link failures. In 175 other words, the redundancy of the network should be kept at a 176 reasonable level, e.g. 2-connected. 178 o Energy saving of the network should not induce increase of latency 179 nor induce traffic loss which exceed the tolerance of the services 180 in the network. QoS metrics such as end-to-end delay, loss and 181 jitter should be kept at a desired level. 183 o The network should reserve enough spare capacity or be able to 184 react quickly to absorb traffic spikes in order to minimize packet 185 loss due to congestions. 187 o The network stability should be preserved. Particularly, traffic 188 oscillation should be avoided. 190 o Energy saving should not conflict with other policies (e.g. 191 performance at the highest priority) in the network. 193 4. Requirements on Network Control Plane 195 Most of the existing network control protocols do not take energy 196 awareness or efficiency into consideration, and some protocols may 197 not work properly when some of the network elements in the network 198 are in energy saving modes. For example, when a network link is put 199 into sleeping mode, the protocols run on this link may be impacted. 201 For energy saving of the whole network, control plane should meet the 202 following requirements: 204 o Control plane should be able to work properly when some of the 205 network elements are in energy saving mode. 207 o Control plane should support the advertisement of energy related 208 information (e.g. current energy saving mode) of network elements 209 in the network. 211 o Control plane should be able to coordinate the energy saving 212 operations of network elements to achieve the overall network 213 energy saving. 215 o Control plane should be able to maximize the opportunity for 216 network elements to enter the energy saving modes. 218 o Control plane should be aware of the network elements in energy 219 saving modes, and should be able to calculate available paths 220 (e.g. which do not traverse the network elements in sleeping 221 mode). 223 o Control plane should be able to calculate the path set for all 224 services carried by the network in a way that energy conservation 225 of the whole network is achieved. 227 Some considerations on control plane when using energy saving 228 mechanism are also specified in [I-D.retana-rtgwg-eacp]. 230 5. Requirements on Management Plane 231 Management plane would also be necessary for building a power aware 232 network. IETF EMAN working group is working on the requirements 233 [I-D.ietf-eman-requirements]and mechanisms for energy management. 234 Such management requirements include identification of energy-managed 235 devices and their components, monitoring of a series of power states 236 and power properties. It may further includes controlling of the 237 power supply and power states of the managed devices. 239 6. IANA Considerations 241 This document makes no request of IANA. 243 Note to RFC Editor: this section may be removed on publication as an 244 RFC. 246 7. Security Considerations 248 TBD 250 8. Acknowledgements 252 TBD 254 9. References 256 9.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, March 1997. 261 9.2. Informative References 263 [I-D.ietf-eman-requirements] 264 Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and 265 B. Claise, "Requirements for Energy Management", draft- 266 ietf-eman-requirements-14 (work in progress), May 2013. 268 [I-D.retana-rtgwg-eacp] 269 Retana, A., White, R., and M. Paul, "A Framework and 270 Requirements for Energy Aware Control Planes", draft- 271 retana-rtgwg-eacp-01 (work in progress), February 2013. 273 [I-D.zhang-panet-problem-statement] 274 Zhang, B., Shi, J., Dong, J., Zhang, M., and M. Boucadair, 275 "Power-Aware Networks (PANET): Problem Statement", draft- 276 zhang-panet-problem-statement-03 (work in progress), 277 October 2013. 279 [I-D.zhang-panet-use-cases] 280 Zhang, M., Dong, J., Zhang, B., and B. Khargharia, "Use 281 Cases for Power-Aware Networks", draft-zhang-panet-use- 282 cases-03 (work in progress), October 2013. 284 Authors' Addresses 286 Jie Dong 287 Huawei Technologies 288 Beijing 100095 289 China 291 Email: jie.dong@huawei.com 293 Mingui Zhang 294 Huawei Technologies 295 Beijing 100095 296 China 298 Email: zhangmingui@huawei.com 300 Beichuan Zhang 301 The University of Arizona 302 USA 304 Email: bzhang@cs.arizona.edu 306 Mohamed Boucadair 307 France Telecom 308 France 310 Email: mohamed.boucadair@orange.com