idnits 2.17.1 draft-mjsraman-rtgwg-bgp-power-path-04.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 : ---------------------------------------------------------------------------- ** There are 20 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2013) is 4015 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: None ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 179 == Missing Reference: '12' is mentioned on line 847, but not defined == Unused Reference: '5' is defined on line 970, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 985, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 989, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group Shankar Raman 3 Internet-Draft Balaji Venkat Venkataswami 4 Intended Status: Experimental RFC Gaurav Raina 5 Expires: October 30, 2013 Vasan Srini 6 IIT Madras 7 April 28, 2013 9 Reducing Power Consumption using BGP path selection 10 draft-mjsraman-rtgwg-bgp-power-path-04 12 Abstract 14 In this paper, we propose a framework to reduce the aggregate power 15 consumption of the Internet using a collaborative approach between 16 Autonomous Systems (AS). We identify the low-power paths among the AS 17 and then use suitable modifications to the BGP path selection 18 algorithm to route the packets along the paths. Such low-power paths 19 can be identified by using the consumed-power-to-available-bandwidth 20 (PWR) ratio as an additional parameter in the BGP Path Selection 21 Algorithm. For re-routing the data traffic through these low-power 22 paths, the power based best path is selected and advertised as per 23 the modified algorithm proposed in this document. Extensions to the 24 Border Gateway Protocol (BGP) can be used to disseminate the PWR 25 ratio metric among the AS thereby creating a collaborative approach 26 to reduce the power consumption. The feasibility of our approaches is 27 illustrated by applying our algorithm to a subset of the Internet. 28 The techniques proposed in this paper for the Inter-AS power 29 reduction require minimal modifications to the existing features of 30 the Internet. The proposed techniques can be extended to other levels 31 of Internet hierarchy, such as Intra-AS paths, through suitable 32 modifications. A recent addition is the use of this method in AIGP 33 domains and also the use of power source data in the calculation of 34 low power paths using the BGP path selection algorithm. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as 44 Internet-Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/1id-abstracts.html 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 Copyright and License Notice 59 Copyright (c) 2013 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1 Low-power routers and switches . . . . . . . . . . . . . . . 4 76 1.2 Power reduction using routing and traffic engineering . . . 4 77 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1 Pre-requisites for the Proposed Method . . . . . . . . . . . 5 80 2.1.1 PWR ratio calculation . . . . . . . . . . . . . . . . . 5 81 2.1.1.1 Power Sources as additional factor . . . . . . . . . 7 82 2.1.1.2 Earlier method of computing numerator of PWR 83 ratio. . . . . . . . . . . . . . . . . . . . . . . . 8 84 2.2 LOW-POWER PATHS . . . . . . . . . . . . . . . . . . . . . . 9 85 2.2.0.1 Current BGP Best Path Selection Algorithm . . . . . 10 86 2.2.0.2 Algorithm 1 on ASBR . . . . . . . . . . . . . . . . 12 87 2.2.0.3 Modified Algorithm 0 on all BGP routers . . . . . . 13 88 2.3 Implementation notes and Discussion . . . . . . . . . . . . 14 89 2.4 Applicability within ASes within a single Admin Domain . . . 16 90 2.4.1 PWR_SESSION . . . . . . . . . . . . . . . . . . . . . . 16 91 2.4.2 Power profiles of Routers and Switches . . . . . . . . . 17 92 2.4.2.1 Concave and Convex power curves . . . . . . . . . . 19 93 2.4.2.3 Need to advertise both available power and 94 consumed power . . . . . . . . . . . . . . . . . . . 20 95 2.4.3 Conclusion and Future Work . . . . . . . . . . . . . . . 21 96 2.5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 97 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 98 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 99 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 5.1 Normative References . . . . . . . . . . . . . . . . . . . 23 101 5.2 Informative References . . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 104 1 Introduction 106 Estimates of power consumption for the Internet predict a 300% 107 increase, as access speeds increase from 10 Mbps to 100 Mbps [3], 108 [8]. Access speeds are likely to increase as new video, voice and 109 gaming devices get added to the Internet. Various approaches have 110 been proposed to reduce the power consumption of the Internet such as 111 designing low-power routers and switches, and optimizing the network 112 topology using traffic engineering methods [2]. 114 1.1 Low-power routers and switches 116 Low-power router and switch design aim at reducing the power consumed 117 by hardware architectural components such as transmission link, 118 lookup tables and memory. In [4] it is shown that the router's link 119 power consumption can vary by 20 Watts between idle and traffic 120 scenarios. Hence the authors suggest having more line cards and 121 running them to capacity: operating the router at full throughput 122 will lead to less power per bit, and hence larger packet lengths will 123 consume lower power. The two important components in routers that 124 have received attention for high power consumption are buffers and 125 TCAMs. Buffers are built using dynamic RAM (DRAM) or static RAM 126 (SRAM). SRAMs are limited in size and consume more power, but have 127 low access times. Guido [1] states that a 40Gb/s line card would 128 require more than 300 SRAM chips and consume 2:5kW. DRAM access times 129 prevent them from being used on high speed line cards. Sometimes the 130 buffering of packets in DRAM is done at the back end, while SRAM is 131 used at the front end for fast data access. But these schemes cannot 132 scale with increasing line speeds. Some variants of TCAMs have been 133 proposed for increasing line speeds and for reduced power consumption 134 [7]. 136 1.2 Power reduction using routing and traffic engineering 138 At the Internet level, creating a topology that allows route 139 adaptation, capacity scaling and power-aware service rate tuning, 140 will reduce power consumption. In [8] the author has proposed a 141 technique to traffic engineer the data packets in such a way that the 142 link capacity between routers is optimized. Links which are not 143 utilized are moved to the idle state. Power consumption can be 144 reduced by trading off performance related measures like latency. For 145 example, power savings while switching from 1 Gbps to 100 Mbps is 146 approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts. 147 Hence instead of operating at 1 Gbps the link speed could be reduced 148 to a lower bandwidth under certain conditions for reduced power 149 consumption. 151 Multi layer traffic engineering based methods make use of parameters 152 such as resource usage, bandwidth, throughput and QoS measures, for 153 power reduction. In [6] an approach for reducing Intra-AS power 154 consumption for optical networks that uses Djikstra's shortest path 155 algorithm is proposed. The input to this method assumes the existence 156 of a network topology using which an auxiliary graph is constructed. 157 Power optimization is done on the auxiliary graph and traffic is 158 routed through the low-power links. However, the algorithm expects 159 the topology to be available for getting the auxiliary graph. This 160 topology is easy to obtain for Intra-AS scenario, but not for Inter- 161 AS cases. In our approach, we propose a collaborative approach by AS 162 in power reduction. The core of the Internet at the Inter-AS level, 163 uses the BGP best path selection algorithm. The AS use the Border 164 Gateway Protocol (BGP) for exchanging routing related information. 165 One of the attributes of BGP namely, AS-PATH-INFO is used to derive 166 the topology of the Internet at the AS level. In this document we 167 propose that the BGP best path selection algorithm is run in each AS 168 at an appropriate BGP router with the consumed-power-to-available- 169 bandwidth (PWR) ratio as a parameter, to determine the low-power 170 paths from the head-end to the tail-end AS in order to reach a prefix 171 or a set of prefixes. The PWR ratio can be exchanged among the 172 collaborating AS using BGP attributes. 174 1.1 Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 2. Methodology 182 184 2.1 Pre-requisites for the Proposed Method 186 In this section we discuss the pre-requisites for the implementation 187 of the proposed scheme. 189 2.1.1 PWR ratio calculation 191 In this proposal each AS is expected to share its PWR ratio from as 192 many ASBRs (Autonomous System Border Routers) that it has. 193 Intuitively in order to calculate this ratio we need to calculate the 194 consumed power representative of the AS and the maximum bandwidth 195 available with an ASBR on its egress links into the AS. The entry 196 point to the AS is through the ASBRs that advertise the prefixes 197 reachable through the AS. Hence the numerator of the PWR ratio is 198 calculated for the AS at each ingress ASBR. We first obtain the 199 summation of power consumed at the Provider (P) and the Provider Edge 200 (PE) routers within an AS. The numerator of the PWR ratio is 201 calculated by summing up the consumed power of all the routers to be 202 taken into account and then dividing this sum by the number of 203 routers. A more intuitive approach would be to use a weighted average 204 method by assigning routers to categories and having appropriate co- 205 efficients for each of these categories, thus arriving at a weighted 206 average which is more accurate. One of these alternatives can be used 207 to arrive at the numerator of the PWR ratio. Yet another alternative 208 would have been to sum up the total consumed power of all routers in 209 the AS and represent that as the numerator of the PWR ratio. 211 This average consumed power is divided by the maximum bandwidth 212 available at each of the ASBR's egress link. This step is necessary 213 as the requested bandwidth for any path from the head-end to the 214 tail-end using the ASBR is limited by the bandwidth available in the 215 ASBR's egress links. The highest available bandwidth amongst the 216 egress links of the ASBR is used as the denominator in the PWR ratio 217 computation. If the entry point to the AS is through a different ASBR 218 then the PWR ratio assigned to the ingress link of the ASBR might 219 vary. Hence, an head-end AS might see different PWR ratios for an 220 intermediate AS, if the intermediate AS has different ASBRs as its 221 entry point. 223 We now illustrate the PWR ratio calculation. Consider an AS X which 224 is one of the AS in the vicinity of another AS Y . Let this ASBR of X 225 have 3 egress links into X denoted as E(1), E(2) and E(3), and 2 226 ingress links labeled I(1) and I(2). We now calculate the PWR ratio 227 for I(1) and I(2). Assume that the routers in X have average consumed 228 power of 200K Watts per hour. From figure 4 we can calculate the PWR 229 ratio for I(1) and I(2) as 200K Watts / (60 * 60 * 1.5 Gigb = 3.7037 230 * (10 raised to -8) We could scale this to 0.37087 by multiplying 231 with a base value of 10 raised to the 7th power. 233 .__________________ 234 ( 235 ( E(1) 236 \ ( +--------->(Core router) 237 \ +-------+ / 1Gb 238 +------>| |/ E(2) 239 200KW / (60*60*1.5Gb) | ASBR |------------>(Core router) 240 +------>| of |\ 1Gb 241 / | AS 100| \ 242 / +-------+ \ E(3) 243 ( +-------->(Core router) 244 ( 1.5Gb 245 .__________________ 247 Figure 1:Calculation of PWR ratio by an ASBR associated with an AS. 248 The I represents ingress links and E represents egress links. 200KW 249 is the average consumed power in the AS. 1.5Gb is the maximum 250 available bandwidth of the egress link in an ASBR. 252 Note that this ratio is actually a mapping function that is defined 253 for each of the ingress links of the ASBR associated with an AS. For 254 the head-end which is the BGP Path selection running AS this mapping 255 function does not exist as there is no ingress link. The PWR ratio 256 can then be advertised to the other neighboring AS using the control 257 plane through BGP extensions. BGP ensures that the information is 258 percolated to other AS beyond the immediate neighbors. On receipt of 259 these power metrics to the AS at the far-ends of the Internet, the 260 overall AS level PWR ratio based Internet topology can be 261 constructed. This view of the Internet is available with each of the 262 routers without using any other complex discovery mechanism. Some 263 sample link weights shown in Figure 1 is obtained by using such a 264 mapping function on the ingress links. 266 2.1.1.1 Power Sources as additional factor 268 It is envisaged that the power sources of the Autonomous system using 269 which the routers in the AS are powered should be declared as a 270 metric which is further incorporated in the PWR ratio. 272 A suitable weight is provided to each type of source and the 273 following table which is not claimed as totally exhaustive can be 274 used to add this metric in the equation to compute the PWR ratio. 276 A formal classification of power sources and their weights is a topic 277 to be considered later. For now we will deal with 2 main categories. 278 Renewable sources of energy and non-renewable sources. There would be 279 multiple categories under each of these major categories. Each such 280 power source is assigned a weight. 282 Renewable Sources of Energy : 284 Wind - HighWeightOne 285 Solar - HighWeightTwo 286 Hydro - HighWeightThree 287 etc... 289 Non-renewable Sources of Energy : 291 Natural Gas - LowWeightOne 292 Petroleum and Diesel - LowWeightTwo 293 Nuclear - LowWeightThree 294 etc... 296 The PWR-SOURCE ratio is calculated in the proportion of how the above 297 sources are combined to power the routers and its coolant systems and 298 ancillary facilities in the AS. 300 Thus PWR-RATIO = ( Consumed-Power / Available-Bandwidth) 301 * (1 / Weighted Average of Power Sources) 303 This compound metric could be used as the PWR metric in the 304 calculations specified in this draft. 306 2.1.1.2 Earlier method of computing numerator of PWR ratio. 308 Earlier in the previous versions of this document in order to 309 calculate this PWR ratio we needed to calculate the available power 310 and the maximum bandwidth available with an ASBR. The entry point to 311 the AS is through ASBRs that advertise the prefixes reachable through 312 the AS. Hence, the numerator of the PWR ratio is calculated for the 313 AS at each ingress ASBR. We first obtained the summation of power 314 consumed at the major Provider (P) and Provider Edge (PE) routers 315 within an AS. The average available power is obtained by subtracting 316 the consumed power from the maximum power rating and summing the 317 values for all the routers and then dividing the result by the number 318 of routers. As an alternative, one could use a weighted average for 319 more accuracy depending on the category of the router advertising the 320 consumed power. Yet another alternative is to take the average or sum 321 of the maximum power rating of all the routers within an AS without 322 taking into account the consumed power. One of these alternatives was 323 chosen to calculate the numerator of the PWR ratio. 325 Intuition however drives us towards consumed power as a better 326 numerator since the lesser the power consumed the lesser the 327 numerator and hence lesser the ratio if enough bandwidth is available 328 at the ingress ASBR. The amount of consumed power per bit of 329 information ought to be low for the shortest path to work out 330 properly. One more aspect is that lesser the power consumed per 331 available bit of bandwidth it could be a sign that routers are more 332 optimal in their power consumption as they take on more traffic. This 333 is a very crucial point to be considered. 335 However additional research seems to indicate that both Available and 336 Consumed Power for a router be advertised. The need that arises for 337 such a proposition is that there exist power profiles of routers 338 which is dealt in later sections (section 2.4.2). Please refer 339 section 2.4.2.1 onwards for more analysis and research on this 340 subject. 342 2.2 LOW-POWER PATHS 344 In this section we present the low-power path BGP best path selection 345 algorithm. The algorithm consists of two sub-algorithms: the first 346 algorithm is executed by all the ASBRs in the network and the second 347 by all the BGP routers in their respective AS. The algorithms for the 348 ASBRs and BGP routers are given as Algorithm 1 and 2. The algorithm 349 in 2.2.0.1 is the current BGP best path algorithm and is titled 350 Algorithm 0. 352 2.2.0.1 Current BGP Best Path Selection Algorithm 354 As taken from [11] the following is the current BGP Best Path 355 Selection Algorithm. 357 Algorithm 0 : BEGIN 359 BGP assigns the first valid path as the current best path. BGP then 360 compares the best path with the next path in the list, until BGP 361 reaches the end of the list of valid paths. This list provides the 362 rules that are used to determine the best path: 364 1) Prefer the path with the highest WEIGHT. 366 2) Prefer the path with the highest LOCAL_PREF. 368 3) Prefer the path that was locally originated via a network or 369 aggregate BGP subcommand or through redistribution from an IGP. 371 Local paths that are sourced by the network or redistribute commands 372 are preferred over local aggregates that are sourced by the 373 aggregate-address command. 375 4) Prefer the path with the shortest AS_PATH. 377 An AS_SET counts as 1, no matter how many ASs are in the set. 379 The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the 380 AS_PATH length. 382 5) Prefer the path with the lowest origin type. 384 Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is 385 lower than INCOMPLETE. 387 6) Prefer the path with the lowest multi-exit discriminator (MED). 389 7) Prefer eBGP over iBGP paths. 391 If bestpath is selected, go to Step 9 (multipath). 393 Note: Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are 394 local to the confederation. Therefore, these paths are treated as 395 internal paths. There is no distinction between Confederation 396 External and Confederation Internal. 398 8) Prefer the path with the lowest IGP metric to the BGP next hop. 400 Continue, even if bestpath is already selected. 402 9) Determine if multiple paths require installation in the routing 403 table for BGP Multipath. 405 Continue, if bestpath is not yet selected. 407 10) When both paths are external, prefer the path that was received 408 first (the oldest one). 410 This step minimizes route-flap because a newer path does not displace 411 an older one, even if the newer path would be the preferred route 412 based on the next decision criteria (Steps 11, 12, and 13). 414 Skip this step if any of these items is true: 416 You have enabled the bgp best path compare-routerid command. 418 The router ID is the same for multiple paths because the routes were 419 received from the same router. 421 There is no current best path. 423 The current best path can be lost when, for example, the neighbor 424 that offers the path goes down. 426 11) Prefer the route that comes from the BGP router with the lowest 427 router ID. 429 The router ID is the highest IP address on the router, with 430 preference given to loopback addresses. Also, you can use the bgp 431 router-id command to manually set the router ID. 433 Note: If a path contains route reflector (RR) attributes, the 434 originator ID is substituted for the router ID in the path selection 435 process. 437 12) If the originator or router ID is the same for multiple paths, 438 prefer the path with the minimum cluster list length. 440 This is only present in BGP RR environments. It allows clients to 441 peer with RRs or clients in other clusters. In this scenario, the 442 client must be aware of the RR-specific BGP attribute. 444 13) Prefer the path that comes from the lowest neighbor address. 446 This address is the IP address that is used in the BGP neighbor 447 configuration. The address corresponds to the remote peer that is 448 used in the TCP connection with the local router. 450 Algorithm 0: END 452 2.2.0.2 Algorithm 1 on ASBR 454 1: Begin 455 2: if ROUTER == ASBR then 456 3: /* As part of IGP-TE */ 457 4: Trigger exchange of available bandwidth on bandwidth change, 458 to the AS internal neighbors; 459 5: BEGIN PROCESS 1 460 6: while PWR ratio changes do 461 7: Assign the PWR ratio to the Ingress links; 462 8: Exchange the PWR ratio with its external neighbors; 463 9: Exchange the PWR ratio with AS's (internal) ASBRs; 464 10: end while 465 11: END PROCESS 1 466 12: End 468 2.2.0.3 Modified Algorithm 0 on all BGP routers 470 1: Begin 471 2: If ROUTER is Configured with BGP then 473 3: Run all steps from 1 to 3 in BGP regular path selection algorithm; 474 /* when comparing AS_PATHS (MODIFICATION HERE) */ 475 4: Check if there are no multiple AS_PATHS then goto regular step 476 (4); 477 5: if PWR metric based path selection is configured then 478 6: For each AS_PATH(1..n) in this set in step (4) 479 7: if there exists a PWR metric for all 480 elements in AS_PATH then 481 8: PWR_SUM[i] = sum the PWR 482 metrices for that AS_PATH; 483 9: else 484 10: ignore the AS_PATH; 485 11: endif 486 12: endFor 488 13: If there exists multiple PWR_SUM[i] then 489 14: Choose the AS_PATH / AS_PATHS with 490 least PWR_SUM; 491 15: if multiple least PWR_SUMs (equal valued) 492 exist then 493 16: Take up the set of such 494 AS_PATHS and goto step 5; 495 17: endif 496 18: else 497 19: if there exist no PWR_SUM because of 498 exclusion then 499 20: do regular step(4) 500 to select best paths; 501 21: endif 502 22: endif 503 23: else 505 24: Do regular step(4); 507 25: endif 509 26: Run all steps from 5 to 13 in BGP regular path selection 510 algorithm; 511 27: endif 512 28: End 513 It is to be noted that the PWR metric based path selection will ensue 514 only if the modified steps are activated as a result of specific user 515 configuration. 517 2.3 Implementation notes and Discussion 519 We propose addition of some BGP attributes with no change to the 520 protocol implementation. There may be a time lag when the far ends of 521 the Internet receive the attribute and the time it originated. This 522 however cannot be avoided as with other attributes and metrics. 524 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 525 +-------------------------------------------------------------+ 526 | Owning 32 bit Autonomous System Number | 527 +-------------------------------------------------------------+ 528 | Other 32 bit Autonomous System Number | 529 +-------------------------------------------------------------+ 530 | PWR Ratio for the AS (Consumed PWR) | 531 +-------------------------------------------------------------+ 532 | PWR Ratio for the AS (Available PWR) | 533 +-------------------------------------------------------------+ 534 | Advertising ASBR's IP router ID | 535 +-------------------------------------------------------------+ 536 | Peer ASBR's IP router ID | 537 +-------------------------------------------------------------+ 538 | 64 bit sequence number for restarts, aging | 539 | and comparison of current PWR Ratio. | 540 +-------------------------------------------------------------+ 542 Figure 2: Proposed PDU format with an added attribute for AS-PATH- 543 POWER-METRIC 545 The additions to the above Attribute have been added to optimize and 546 correctly correlate the connecting ASes and the inter-AS links among 547 them. For the traffic direction into the Advertising AS the above 548 information will be easier to correlate than the previous version 549 which did not advertise the peer AS which had the ingress links into 550 the advertising Router. 552 In MPLS-TE for example, when the TE metrics are modified, there is a 553 reliable flooding process within an Interior Gateway Protocol (IGP). 554 Such triggered updates apply to the PWR ratio in BGP as well. The 555 proposed PWR ratio is advertised to the neighboring AS and the 556 information percolated to all the AS, in a AS-PATH-POWER-METRIC 557 attribute. This attribute can be implemented as shown in Figure 2. 558 The frequency of the updates for this attribute should be fixed to 559 avoid network flooding. 561 The AS-PATH-POWER-METRIC for each ASBR is calculated, and advertised 562 as the PWR ratio for the AS. This AS-PATH-POWER-METRIC is filled into 563 the appropriate transitive non-discretionary attribute and inserted 564 into a unique vector for a set of prefixes advertised from the AS. 565 Such advertised prefixes may have originated from the AS or be the 566 transit prefixes. The filled vector is sent to the ASBR of the 567 neighboring AS and the information propagates to all the ASBRs. If 568 the elements denoting AS in a vector of AS-PATH-INFO is not the same 569 as the ones that need to be advertised in a AS-PATH-POWER-METRIC, 570 then a suitable subset of AS-PATH-POWER-METRIC is identified and sent 571 in the BGP updates. A vector of size 1 also can be employed if the AS 572 in question is the only one for which PWR ratio has changed in the 573 originating AS. The collation can be done depending on availability 574 of such metrics and their mapping to a valid AS-PATH-INFO metric. 576 The power consumed by each router may fluctuate over short time 577 intervals. In order to dampen these fluctuations which can cause 578 unnecessary updates, power can be measured when falling within 579 intervals of suitable size (say a range of values). This is as 580 opposed to measuring power as a discrete quantity. This method of 581 power measurement reduces the frequency of triggered updates from the 582 routers due to power change. 584 0.1 0.2 0.1 585 (A) ---> (B) ---> (D) 587 0.1 0.2 0.02 0.2 588 (A) ---> (C) ---> (E) ---> (D) 590 0.1 0.2 591 (D) ---> (X) 593 Figure 4: Example of strands where more than one PWR ratio is 594 advertised by "D" 596 0.2 0.1 0.2 597 (A).....>(B).....>(D).....>(X) 598 | ^ 599 |0.2 0.02 | 0.2 600 +--->(C)-------->(E) 602 Figure 5:Choice of low-power path derived using the algorithm which 603 uses lower value of the ingress link but through the same AS 605 A use case of multiple ASBRs advertising differing PWR ratio shows 606 that an AS may be seen as green through one ingress link and not 607 through the other. Consider the case of multiple ASBRs that belong to 608 the same AS, advertising PWR ratios that differ. This could lead to 609 power values that belong to different classes of ratios with many 610 intervening classes in between. These advertised PWR ratios could 611 lead to one ASBR being preferred over the other thus taking a 612 different path from head-end to tail-end. This also entails that 613 there may be multiple paths to the AS through these different ASBRs. 615 Consider Figure 4 which shows a set of strands that derive a topology 616 as in Figure 5. Here D is reachable via two paths but the PWR ratios 617 differ. This illustrates the case where the better metric wins out. 618 The average power consumed would not have an effect but the bandwidth 619 available on these ASBR egress links would definitely influence the 620 path. 622 2.4 Applicability within ASes within a single Admin Domain 624 As per [draft-ietf-idr-aigp] there are deployments in which a single 625 administration runs a network which has been sub-divided into 626 multiple, contiguous ASes, each running BGP. There are several 627 reasons why a single administrative domain may be broken into several 628 ASes (which, in this case, are not really "autonomous".) It may be 629 that the existing IGPs do not scale well in the particular 630 environment; it may be that a more generalized topology is desired 631 than could be obtained by use of a single IGP domain; it may be that 632 a more finely grained routing policy is desired than can be supported 633 by an IGP. In such deployments, it can be useful to allow BGP to 634 make its routing decisions based on the IGP metric, so that BGP 635 chooses the "shortest" path between two nodes, even if the nodes are 636 in two different ASes within that same administrative domain. The 637 authors refer to the set of ASes in a common administrative domain as 638 an "AIGP Administrative Domain". 640 A combination of the AIGP administrative metric and the Path 641 selection algorithm could be combined to arrive at a set of a 642 suitable number of equal k power-shortest paths and then use a tie- 643 break amongst such k power-shortest-paths with the least AIGP metric. 644 This is provided the set of ASes where the decision is being made all 645 fall under a AIGP Administrative domain. This provides a trade-off of 646 power shortest paths and least number of hops (link wise) to get from 647 source to destination across these ASes. 649 2.4.1 PWR_SESSION 651 An implementation that supports the PWR attribute CAN support a per- 652 session configuration item, PWR_SESSION, that indicates whether the 653 PWR attribute is enabled or disabled for use on that session. 655 - The default value of PWR_SESSION, for EBGP sessions, between 656 providers (distinct operators) CAN be "disabled". 658 - The default value of PWR_SESSION, for IBGP and confederation- 659 EBGP sessions, MUST be "enabled." 661 The PWR attribute MUST NOT be sent on any BGP session for which 662 PWR_SESSION is disabled. 664 If an PWR attribute is received on a BGP session for which 665 PWR_SESSION is disabled, the attribute MUST be treated exactly as if 666 it were an unrecognized transitive attribute. That is, " The 667 handling of an unrecognized optional attribute is determined by the 668 setting of the Transitive bit in the attribute flags octet. Paths 669 with unrecognized transitive optional attributes SHOULD be accepted. 670 If a path with an unrecognized transitive optional attribute is 671 accepted and passed to other BGP peers, then the unrecognized 672 transitive optional attribute of that path MUST be passed, along with 673 the path, to other BGP peers with the Partial bit in the Attribute 674 Flags octet set to 1. If a path with a recognized, transitive 675 optional attribute is accepted and passed along to other BGP peers 676 and the Partial bit in the Attribute Flags octet is set to 1 by some 677 previous AS, it MUST NOT be set back to 0 by the current AS". 679 This helps in confining the distribution of the attribute and use in 680 calculation of the power shortest paths only amongst ASes that have 681 trust relationships with other ASes. Of course, this includes and 682 promotes the use of PWR attribute within a AIGP administrative 683 domain. 685 2.4.2 Power profiles of Routers and Switches 687 It has been experimented and from several sources found that there 688 exist routers which have different power profiles. The power profile 689 of a router is the curve of power consumption to available bandwidth. 690 Mentioned below are a few of these prominent ones that have to be 691 taken into consideration. 693 The first profile that we will consider is the flattening curve. The 694 power consumed to available bandwidth curve takes the shape of a 695 steep one initially and then tapers off to a plateau. The point at 696 which it begins to give a delta-C (delta in Power Consumed) to delta- 697 B (Available Bandwidth exhausted) is the inflection point that tapers 698 off to a plateau. Here the delta-C/delta-B begins to slow down or 699 decrease rapidly. The more the traffic that is added onto the device 700 the lesser it draws power. 702 ^ 703 | 704 P | . 705 o | . 706 w | . 707 e | . 708 r | . 709 | . 710 c | . 711 o | . 712 n | . 713 s | . 714 u.| . 715 ------------------------------------> 716 | Available Bandwidth exhausted 718 The second profile that we will consider is the exponential curve. 719 The power consumed to available bandwidth curve takes the shape of an 720 ever increasing steep curve as shown below. Here the delta-C/delta-B 721 begins to increase as more traffic is thrown onto it as the Available 722 bandwidth exhausted increases. This power curve beyond a point is 723 intolerable with respect to power guzzling. 725 ^ 726 | 727 P | . 728 o | . 729 w | . 730 e | . 731 r | . 732 | . 733 c | . 734 o | . 735 n | . 736 s | . 737 u.| . 738 ------------------------------------> 739 | Available Bandwidth exhausted 741 The third profile that we will consider is a linear curve. In other 742 words just a straight line. Here delta-C/delta-B is a constant. 744 ^ 745 | 746 P | . 747 o | . 748 w | . 749 e | . 750 r | . 751 | . 752 c | . 753 o | . 754 n | . 755 s | . 756 u.| . 757 ------------------------------------> 758 | Available Bandwidth exhausted 760 2.4.2.1 Concave and Convex power curves 762 Given that there are 3 kinds of major profiles in the router power 763 consumption, what line would we like to pick. This is an important 764 point when choosing the metric to pick the low power paths. 766 (a) If the confrontation is between 2 first profile routers the lower 767 of the 2 would be considered as shown below. The lower curve offers 768 better power savings for each GB of bandwidth transported. 770 ^ 771 | 772 P | . 773 o | . 774 w | . . 775 e | . . 776 r | . . 777 | . . 778 c | . . 779 o | . . 780 n | . . 781 s | . . 782 u.| . 783 ------------------------------------> 784 | Available Bandwidth exhausted 786 (b) If the confrontation is between 2 second profile routers the 787 upper curve offers more power savings per GB of bandwidth. 789 ^ 790 | 791 P | . . 792 o | . . 793 w | . . 794 e | . . 795 r | . . 796 | . . 797 c | . . 798 o | . . 799 n | . . 800 s | . 801 u.| . 802 ------------------------------------> 803 | Available Bandwidth exhausted 805 (c) When the confrontation is between a first profile curve and a 806 second profile curve, it would be optimal to pick (as shown below) 807 the lower of the curves because it gives us lesser power consumed for 808 every GB of traffic routed / switched. Here the exponential curve is 809 the one that offers lesser amount of power consumed per GB of traffic 810 is chosen. But when it gets to a point that the two curves intersect 811 it would be more optimal to pick the tapering curve. Thus at the 812 meeting point of the 2 curves the exponential curve becomes more 813 costly and the tapering one gives us more GB for the power buck. Thus 814 this switchover from one curve to the other (in other words from the 815 exponential curve to the tapering one) does the trick in terms of 816 finding an optimal solution. 818 ^ . 819 | . 820 P | . . 821 o | (*) 822 w | . . 823 e | . . 824 r | . . 825 | . . 826 c | . . 827 o | . . 828 n | . . 829 s | . . 830 u.| .. 831 ------------------------------------> 832 | Available Bandwidth exhausted 833 (*) Metric switchover point from Consumed Power to Available Power. 835 2.4.2.3 Need to advertise both available power and consumed power 836 Thus the above sections have shown that both the available power and 837 the consumed power MUST be advertised so that case (c) can be 838 deciphered and the switchover of the curves be done and the 839 appropriate router be chosen for the rest of the bandwidth to be 840 switched over to. 842 Thus there will exist Consumed-Power to Available Bandwidth ratio and 843 the Available Power to Available Bandwidth ratio. Both the ratios are 844 computed and the lower value chosen. The Available Power can be 845 judged from the calibration process such as the one carried out by 846 independent test organizations as in [12]. An example of their 847 calibration is referred to in [12]. 849 2.4.3 Conclusion and Future Work 851 In this paper, we proposed a scheme for reducing the power 852 consumption of the Internet using collaborative effort between AS. 853 The BGP best path algorithm is run with suitable modifications in 854 step (4) as described by using the PWR ratio as a parameter. The PWR 855 ratio is advertised through the ingress links of the ASBRs associated 856 with AS using BGP updates. The Modified BGP Best Path Selection 857 Algorithm finds out the low-power consuming AS that can route data 858 packets for a set of prefixes. This entails adopting routes by 859 choosing entry points to an AS that give energy saving paths. Our 860 work complements the current schemes for reducing power consumption 861 within a router such as switching off or bringing to power-idle-state 862 certain select components within the forwarding and lookup 863 mechanisms. 865 Normally the ASes have SLA agreements between each other to carry X 866 amount of traffic from say a provider A. If the AS representing the 867 ISP then advertises fake figures to carry more traffic than is 868 mandated by the SLA agreement with other providers, then it is to 869 that ISPs detriment since by advertising a better PWR ratio it 870 invites more traffic through it thus getting paid less and carrying 871 more traffic. This is not in the best interest of the ISP. This is so 872 because in the final analysis the Power Shortest Path computed would 873 include it regardless of the amount of traffic to be carried thus 874 causing it to invite more traffic through it than it has accepted, 875 even much more than its capacity. Hence it would be advisable for 876 that ISP to advertise proper PWR ratios and NOT on the lower side of 877 the spectrum. If it advertises HIGHER PWR ratios it would not be 878 chosen, and hence that could be a policy measure NOT to accept any 879 traffic at all since its capacity may be filled up with existing 880 traffic. So advertising on the LOWER side would lead to lesser amount 881 of benefit with respect to dollar per bit transported, and on the 882 HIGHER side would be to exclude it from carrying any traffic that 883 wanted to use the Power Shortest Path. 885 We also propose that there be a governing body in the IETF or outside 886 it or sponsored by the IETF to verify the power ratios advertised are 887 indeed valid or approximately closer to the actual consumption. A 888 link up for each ISP with a power application level gateway to ensure 889 proper ratios are advertised could be mandated amongst at least the 890 co-operating ISPs (ASes). 892 The aspect of innovation in this proposal is to use BGP as the 893 piggyback protocol upon which this scheme stands. 895 When links and switches are gated or put into low-power state within 896 an AS, the power-consumption automatically drops at the aggregate 897 level, as a result of which the PWR ratio would be a lower figure 898 advertised through BGP and thus this AS would attract more Power 899 Shortest Path traffic through it. Thus the links within the AS and 900 the switches within it would function more optimally if it had more 901 traffic that went along paths that were originally put in low-power 902 state thus utilizing the paths more effectively, when attracting 903 traffic. 905 There exist MIBs today that have object identifier for power consumed 906 in a router. Maybe all the related components within it may NOT be 907 listed with regards to power consumed. But the overall power consumed 908 by the Router / Switch is gettable. Once it is advertised in a opaque 909 Link-State-Advertisement say in the form of a TLV (Type Length Value) 910 and the LSAs (Link State Advertisements) are flooded through the 911 network in an AS, all routers get a uniform picture of which router 912 consumes what power. This method already exists for Traffic 913 engineering Database LSAs that are advertised as LSAs for the purpose 914 of traffic engineering within an AS. We are merely piggybacking on 915 this capability to calculate the PWR ratio at the ASBR which amongst 916 others is yet another Router / Switch of the AS. 918 Our future work includes looking into computing low-power paths 919 within AS as well. 921 2.5 Acknowledgements 923 Shankar Raman would like to acknowledge the support by BT Public 924 Limited (UK) under the BT IITM PhD Fellowship award. Balaji Venkat 925 and Gaurav Raina would like to acknowledge the UK EPSRC Digital 926 Economy Programme and the Government of India Department of Science 927 and Technology (DST) for funding given to the IU-ATC. Vasan Srini 928 would like to thank Dr.(Prof).Kamakoti of the Computer Science and 929 Engineering department for his support. 931 3 Security Considerations 933 No specific security considerations apart from the usual 934 considerations with respect to authenticating BGP messages / updates 935 from BGP neighbors is necessary for this scheme. 937 4 IANA Considerations 939 A new optional transitive non-discretionary attribute needs to be 940 provided by IANA for carrying the PWR ratio across the Internet in 941 the specified format in BGP. 943 5 References 945 5.1 Normative References 947 TBD 949 5.2 Informative References 951 REFERENCES 953 [1] G. Appenzeller, Sizing router buffers, Doctoral 954 Thesis, Department of Electrical Engineering, Stanford 955 University, 2005. 957 [2] A. P. Bianzino, C. Chaudet, D. Rossi and J. L. 958 Rougier, A survey of green networking research, IEEE 959 Communications and Surveys Tutorials, preprint. 961 [3] J. Baliga, K. Hinton and R. S. Tucker, Energy 962 consumption of the internet, Proc. of joint international 963 conference on optical internet, June 2007, pp. 1-3. 965 [4] J. Chabarek, J. Sommers, P. Barford, C. Estan, D. 966 Tsiang and S. Wright, Power awareness in network design 967 and routing, Proc. of the IEEE INFOCOM 2008, April 2008, 968 pp. 457-465. 970 [5] B. Venkat et.al, Constructing disjoint and partially 971 disjoint InterAS TE-LSPs, USPTO Patent 7751318, Cisco 972 Systems, 2010. 974 [6] M. Xia et. al., Greening the optical backbone network: 975 A traffic engineering approach, IEEE ICC Proceedings, May 976 2010, pp. 1-5. 978 [7] W. Lu and S. Sahni, Low-power TCAMs for very large 979 forwarding tables, IEEE/ACM Transactions on Computer 980 Networks, June 2010, vol. 18, no. 3, pp. 948-959. 982 [8] B. Zhang, Routing Area Open Meeting, Proceedings of 983 the IETF 81, Quebec, Canada, July 2011. 985 [9] M.J.S Raman, V.Balaji Venkat, G.Raina, Reducing Power 986 consumption using the Border Gateway Protocol, IARIA 987 conferences ENERGY 2012. 989 [10] A.Cianfrani et al., An OSPF enhancement for energy 990 saving in IP Networks, IEEE INFOCOM 2011 Workshop on Green 991 Communications and Networking 993 [11] http://www.cisco.com/en/US/tech/tk365/ 994 technologies_tech_note09186a0080094431.shtml, BGP best 995 path selection algorithm. 997 [draft-ietf-idr-aigp] P. Mohapatra et.al, The Accumulated 998 IGP metric attribute for BGP, 999 https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/, 1000 November 2012. 1002 Authors' Addresses 1004 Shankar Raman 1005 Department of Computer Science and Engineering 1006 IIT Madras 1007 Chennai - 600036 1008 TamilNadu 1009 India. 1011 EMail: mjsraman@cse.iitm.ac.in 1013 Balaji Venkat Venkataswami 1014 Department of Electrical Engineering 1015 IIT Madras 1016 Chennai - 600036 1017 TamilNadu 1018 India. 1020 EMail: balajivenkat299@gmail.com 1022 Prof.Gaurav Raina 1023 Department of Electrical Engineering 1024 IIT Madras 1025 Chennai - 600036 1026 TamilNadu 1027 India. 1029 EMail: gaurav@ee.iitm.ac.in 1031 Vasan Srini 1032 Department of Computer Science and Engineering 1033 IIT Madras 1034 Chennai - 600036 1035 TamilNadu 1036 India. 1038 Email: vasan.vs@gmail.com