idnits 2.17.1 draft-mjsraman-rtgwg-inter-as-psp-06.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 -- The document date (April 28, 2013) is 4009 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 200 == Missing Reference: '12' is mentioned on line 932, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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 IIT Madras 6 April 28, 2013 8 Reducing Power Consumption using BGP 9 draft-mjsraman-rtgwg-inter-as-psp-06 11 Abstract 13 In this paper, we propose a framework to reduce the aggregate power 14 consumption of the Internet using a collaborative approach between 15 Autonomous Systems (AS). We identify the low-power paths among the AS 16 and then use Traffic Engineering (TE) techniques to route the packets 17 along the paths. Such low-power paths can be identified by using the 18 consumed-power-to-available-bandwidth (PWR) ratio as an additional 19 constraint in the Constrained Shortest Path First (CSPF) algorithm. 20 For re-routing the data traffic through these low-power paths, the 21 Inter-AS Traffic Engineered Label Switched Path (TE-LSP) that spans 22 multiple AS can be used. Extensions to the Border Gateway Protocol 23 (BGP) can be used to disseminate the PWR ratio metric among the AS 24 thereby creating a collaborative approach to reduce the power 25 consumption. Since calculating the low-power paths can be 26 computationally intensive, a graph-labeling heuristic is also 27 proposed. This heuristic reduces the computational complexity but may 28 provide a sub-optimal low-power path. The feasibility of our 29 approaches is illustrated by applying our algorithm to a subset of 30 the Internet. The techniques proposed in this paper for the Inter-AS 31 power reduction require minimal modifications to the existing 32 features of the Internet. The proposed techniques can be extended to 33 other levels of Internet hierarchy, such as Intra-AS paths, through 34 suitable modifications. 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 . . . . . . . . . . . 6 80 2.1.1 Constructing network topology using BGP strands . . . . 6 81 2.1.2 PWR ratio calculation . . . . . . . . . . . . . . . . . 7 82 2.1.2.1 Earlier method of computing numerator of PWR 83 ratio. . . . . . . . . . . . . . . . . . . . . . . . 9 84 2.1.3 Explicit routing using TE-LSPs . . . . . . . . . . . . . 10 85 2.2 LOW-POWER PATHS . . . . . . . . . . . . . . . . . . . . . . 11 86 2.2.0.1 Algorithm 1 ASBR low-power path algorithm . . . . . 12 87 2.2.0.2 Algorithm 2 PCE low-power path algorithm . . . . . . 12 88 2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . 12 89 2.2.3 Equivalence class with total ordering . . . . . . . . . 13 90 2.2.3.1 Algorithm 3 PCE low-power path algorithm with 91 graph labeling . . . . . . . . . . . . . . . . . . . 14 92 2.3 Implementation notes and Discussion . . . . . . . . . . . . 15 93 2.4 Applicability within ASes within a single Admin Domain . . . 18 94 2.4.1 PWR_SESSION . . . . . . . . . . . . . . . . . . . . . . 18 95 2.4.2 Power profiles of Routers and Switches . . . . . . . . . 19 96 2.4.2.1 Concave and Convex power curves . . . . . . . . . . 21 97 2.4.2.3 Need to advertise both available power and 98 consumed power . . . . . . . . . . . . . . . . . . . 22 99 2.5 Conclusion and Future Work . . . . . . . . . . . . . . . . . 23 100 2.6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 101 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 27 102 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 103 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 5.1 Normative References . . . . . . . . . . . . . . . . . . . 27 105 5.2 Informative References . . . . . . . . . . . . . . . . . . 27 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 108 1 Introduction 110 Estimates of power consumption for the Internet predict a 300% 111 increase, as access speeds increase from 10 Mbps to 100 Mbps [3], 112 [8]. Access speeds are likely to increase as new video, voice and 113 gaming devices get added to the Internet. Various approaches have 114 been proposed to reduce the power consumption of the Internet such as 115 designing low-power routers and switches, and optimizing the network 116 topology using traffic engineering methods [2]. 118 1.1 Low-power routers and switches 120 Low-power router and switch design aim at reducing the power consumed 121 by hardware architectural components such as transmission link, 122 lookup tables and memory. In [4] it is shown that the router's link 123 power consumption can vary by 20 Watts between idle and traffic 124 scenarios. Hence the authors suggest having more line cards and 125 running them to capacity: operating the router at full throughput 126 will lead to less power per bit, and hence larger packet lengths will 127 consume lower power. The two important components in routers that 128 have received attention for high power consumption are buffers and 129 TCAMs. Buffers are built using dynamic RAM (DRAM) or static RAM 130 (SRAM). SRAMs are limited in size and consume more power, but have 131 low access times. Guido [1] states that a 40Gb/s line card would 132 require more than 300 SRAM chips and consume 2:5kW. DRAM access times 133 prevent them from being used on high speed line cards. Sometimes the 134 buffering of packets in DRAM is done at the back end, while SRAM is 135 used at the front end for fast data access. But these schemes cannot 136 scale with increasing line speeds. Some variants of TCAMs have been 137 proposed for increasing line speeds and for reduced power consumption 138 [7]. 140 1.2 Power reduction using routing and traffic engineering 142 At the Internet level, creating a topology that allows route 143 adaptation, capacity scaling and power-aware service rate tuning, 144 will reduce power consumption. In [8] the author has proposed a 145 technique to traffic engineer the data packets in such a way that the 146 link capacity between routers is optimized. Links which are not 147 utilized are moved to the idle state. Power consumption can be 148 reduced by trading off performance related measures like latency. For 149 example, power savings while switching from 1 Gbps to 100 Mbps is 150 approximately 4 W and from 100 Mbps to 10 Mbps around 0:1 Watts. 151 Hence instead of operating at 1 Gbps the link speed could be reduced 152 to a lower bandwidth under certain conditions for reduced power 153 consumption. 155 Multi layer traffic engineering based methods make use of parameters 156 such as resource usage, bandwidth, throughput and QoS measures, for 157 power reduction. In [6] an approach for reducing Intra-AS power 158 consumption for optical networks that uses Djikstra's shortest path 159 algorithm is proposed. The input to this method assumes the existence 160 of a network topology using which an auxiliary graph is constructed. 161 Power optimization is done on the auxiliary graph and traffic is 162 routed through the low-power links. However, the algorithm expects 163 the topology to be available for getting the auxiliary graph. This 164 topology is easy to obtain for Intra-AS scenario, but not for Inter- 165 AS cases. In our approach, we propose a collaborative approach by AS 166 in power reduction. The core of the Internet at the Inter-AS level, 167 uses the Multi-Protocol Label Switching (MPLS) technology. MPLS label 168 switched paths that traverse multiple AS carry traffic from a head- 169 end to a tail-end. The AS use the Border Gateway Protocol (BGP) for 170 exchanging routing and topology related information. One of the 171 attributes of BGP namely, AS-PATH-INFO is used to derive the topology 172 of the Internet at the AS level. The CSPF algorithm is run on this AS 173 level topology with the consumed-power-to-available-bandwidth (PWR) 174 ratio as a constraint, to determine the low-power path from the head- 175 end to the tail-end. The PWR ratio can be exchanged among the 176 collaborating AS using BGP. Explicit routing can be achieved between 177 the head-end and the tail-end through the low-power paths connecting 178 the AS using the Inter-AS Traffic Engineered Label Switched Path (TE- 179 LSP) that span multiple AS. 181 Calculation of such low-power paths can be computationally intensive 182 and hence certain heuristics may be needed to reduce the computation 183 time. A graph-labeling heuristic is proposed to reduce the 184 computation time, which may lead to sub-optimal low-power paths. We 185 illustrate our approaches by applying it to a subset of the Internet 186 topology. The rest of the paper is organized as follows: In Section 187 II, we discuss in detail the pre-requisites for the algorithm. 188 Section III introduces the proposed technique which uses the CSPF 189 algorithm to calculate the low-power paths. We also show that by 190 using a graph-labeling technique, we can reduce the computational 191 complexity of the low-power path algorithm, but may obtain a sub- 192 optimal low-power path. In Section IV, we discuss the implementation 193 issues. We present our conclusion and future work in Section V. 195 1.1 Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in RFC 2119 [RFC2119]. 201 2. Methodology 202 204 2.1 Pre-requisites for the Proposed Method 206 In this section we discuss the pre-requisites for the implementation 207 of the proposed scheme. 209 2.1.1 Constructing network topology using BGP strands 211 The Inter-AS topology can be modeled as a directed graph G = (V; E; 212 f) where the vertices (V) are mapped to AS and the edges (E) map the 213 link that connect the neighboring AS. The direction (f) on the edge, 214 represents the data flow from the head-end to the tail-end AS. To 215 obtain the Inter-AS topology, the approach proposed in [5] is used. 216 In this approach, it is shown that a sub-graph of the Internet 217 topology, can be obtained by collecting several prefix updates in 218 BGP. This is illustrated in Figure 1 which shows the different graph 219 strands of AS that are recorded from the BGP packets. Each vertex in 220 this graph is assigned a weight according to the consumed-power-to- 221 available-bandwidth (PWR) ratio of the AS, as seen by an Autonomous 222 System Border Router (ASBR) that acts as an entry point to the AS. 223 Figure 2 shows the strands merged together to form the topology sub- 224 graph. In this figure, the weight of the vertices are mapped to the 225 ingress edges. A reference AS level topology derived from 100 strands 226 of AS-PATH-INFO received by an AS in the Internet is presented in 227 Figure 3 in [9]. 229 0.2 0.05 0.1 230 (A) ----> (B) ----> (D) 232 0.1 0.03 0.2 233 (D) ----> (G) ----> (H) 235 0.03 0.5 0.3 236 (G) ----> (E) ----> (X) 238 0.5 0.5 0.5 0.1 239 (C) ----> (B) ----> (H) ----> (X) 241 0.05 0.5 0.3 242 (B) ----> (E) ----> (X) 244 Figure 1: Different strands obtained from BGP updates, where vertices 245 A,B,C,D and G represent the head-end AS. D,H and X form the tail-end 246 AS. The vertex weights refer to the PWR ratio of the AS, and the 247 direction of the link shows the next AS hop. 249 0.5 250 (C) +----------------+ 251 0.5| / | 252 | / | 253 0.05 V/ 0.1 0.03 0.2 V 254 (A)--->(B)--->(D)--->(G)--->(H) 255 | | | 256 | 0.5| | 0.1 257 | V V 258 +----------->(E)--->(X) 259 0.5 0.3 261 Figure 2:Combining the strands to get the topology of the Internet. 262 The PWR ratio is mapped to the the ingress link of the ASBR and not 263 to the AS. 265 2.1.2 PWR ratio calculation 267 In the topology sub-graph, each AS is expected to share its PWR 268 ratio. In order to calculate this ratio we need to calculate the 269 consumed power in the AS and the maximum bandwidth available with an 270 ASBR. 272 In this proposal each AS is expected to share its PWR ratio from as 273 many ASBRs (Autonomous System Border Routers) that it has. 274 Intuitively in order to calculate this ratio we need to calculate the 275 consumed power representative of the AS and the maximum bandwidth 276 available with an ASBR on its egress links into the AS. The entry 277 point to the AS is through the ASBRs that advertise the prefixes 278 reachable through the AS. Hence the numerator of the PWR ratio is 279 calculated for the AS at each ingress ASBR. We first obtain the 280 summation of power consumed at the Provider (P) and the Provider Edge 281 (PE) routers within an AS. The numerator of the PWR ratio is 282 calculated by summing up the consumed power of all the routers to be 283 taken into account and then dividing this sum by the number of 284 routers. A more intuitive approach would be to use a weighted average 285 method by assigning routers to categories and having appropriate co- 286 efficients for each of these categories, thus arriving at a weighted 287 average which is more accurate. One of these alternatives can be used 288 to arrive at the numerator of the PWR ratio. Yet another alternative 289 would have been to sum up the total consumed power of all routers in 290 the AS and represent that as the numerator of the PWR ratio. 292 This average consumed power is divided by the maximum bandwidth 293 available at each of the ASBR's egress link. This step is necessary 294 as the requested bandwidth for any path from the head-end to the 295 tail-end using the ASBR is limited by the bandwidth available in the 296 ASBR's egress links. The highest available bandwidth amongst the 297 egress links of the ASBR is used as the denominator in the PWR ratio 298 computation. If the entry point to the AS is through a different ASBR 299 then the PWR ratio assigned to the ingress link of the ASBR might 300 vary. Hence, an head-end AS might see different PWR ratios for an 301 intermediate AS, if the intermediate AS has different ASBRs as its 302 entry point. 304 The PWR ratio must be computed and disbursed much ahead of time 305 before the Inter-AS TE-LSP explicit path or route is computed using 306 the CSPF algorithm. The correctness of this ratio is of importance to 307 compute the Inter-AS TE-LSP route through the green AS. If the entry 308 point to the AS is through a different ASBR then the PWR ratio 309 assigned to the ingress link of the ASBR might vary. Hence, an head- 310 end AS might see different PWR ratios for an intermediate AS, if the 311 intermediate AS has different ASBRs as its entry point. 313 We now illustrate the PWR ratio calculation. Consider an AS X which 314 is one of the AS in the vicinity of another AS Y . Let this ASBR of X 315 have 3 egress links into X denoted as E(1), E(2) and E(3), and 2 316 ingress links labeled I(1) and I(2). We now calculate the PWR ratio 317 for I(1) and I(2). Assume that the routers in X have average consumed 318 power of 200K Watts per hour. From figure 4 we can calculate the PWR 319 ratio for I(1) and I(2) as 200K Watts / (60 * 60 * 1.5 Gigb = 3.7037 320 * (10 raised to -8) We could scale this to 0.37087 by multiplying 321 with a base value of 10 raised to the 7th power. 323 .__________________ 324 ( 325 ( E(1) 326 \ ( +--------->(Core router) 327 \ +-------+ / 1Gb 328 +------>| |/ E(2) 329 200KW / (60*60*1.5Gb) | ASBR |------------>(Core router) 330 +------>| of |\ 1Gb 331 / | AS 100| \ 332 / +-------+ \ E(3) 333 ( +-------->(Core router) 334 ( 1.5Gb 335 .__________________ 337 Figure 4:Calculation of PWR ratio by an ASBR associated with an AS. 338 The I represents ingress links and E represents egress links. 200KW 339 is the average consumed power in the AS. 1.5Gb is the maximum 340 available bandwidth of the egress link in an ASBR. 342 Note that this ratio is actually a mapping function that is defined 343 for each of the ingress links of the ASBR associated with an AS. For 344 the head-end AS this mapping function does not exist as there is no 345 ingress link. The PWR ratio can then be advertised to the other 346 neighboring AS using the control plane through BGP extensions. BGP 347 ensures that the information is percolated to other AS beyond the 348 immediate neighbors. On receipt of these power metrics to the AS at 349 the far-ends of the Internet, the overall AS level PWR ratio based 350 Internet topology can be constructed. This view of the Internet is 351 available with each of the routers without using any other complex 352 discovery mechanism. Some sample link weights shown in Figure 2 is 353 obtained by using such a mapping function on the ingress links. 355 2.1.2.1 Earlier method of computing numerator of PWR ratio. 357 Earlier in the previous versions of this document in order to 358 calculate this PWR ratio we needed to calculate the available power 359 and the maximum bandwidth available with an ASBR. The entry point to 360 the AS is through ASBRs that advertise the prefixes reachable through 361 the AS. Hence, the numerator of the PWR ratio is calculated for the 362 AS at each ingress ASBR. We first obtained the summation of power 363 consumed at the major Provider (P) and Provider Edge (PE) routers 364 within an AS. The average available power is obtained by subtracting 365 the consumed power from the maximum power rating and summing the 366 values for all the routers and then dividing the result by the number 367 of routers. As an alternative, one could use a weighted average for 368 more accuracy depending on the category of the router advertising the 369 consumed power. Yet another alternative is to take the average or sum 370 of the maximum power rating of all the routers within an AS without 371 taking into account the consumed power. One of these alternatives was 372 chosen to calculate the numerator of the PWR ratio. 374 Intuition however drives us towards consumed power as a better 375 numerator since the lesser the power consumed the lesser the 376 numerator and hence lesser the ratio if enough bandwidth is available 377 at the ingress ASBR. The amount of consumed power per bit of 378 information ought to be low for the shortest path to work out 379 properly. One more aspect is that lesser the power consumed per 380 available bit of bandwidth it could be a sign that routers are more 381 optimal in their power consumption as they take on more traffic. This 382 is a very crucial point to be considered. 384 However additional research seems to indicate that both Available and 385 Consumed Power for a router be advertised. The need that arises for 386 such a proposition is that there exist power profiles of routers 387 which is dealt in later sections (section 2.4.2). Please refer 388 section 2.4.2.1 onwards for more analysis and research on this 389 subject. 391 2.1.3 Explicit routing using TE-LSPs 393 We assume that the head-end and the tail-end may reside in different 394 AS and the path is along multiple intervening AS. The way to generate 395 this path is by using Traffic Engineered Label Switched Paths (TE- 396 LSPs). TE-LSPs can influence the exact path (at the AS level) that 397 the traffic will pass through. This path can then be realized by 398 providing these set of low-power consuming AS to a protocol like 399 Resource Reservation Protocol (RSVP). RSVP-TE then creates TE-LSPs or 400 tunnels, using its label assigning procedure. The routers use these 401 low-power paths created by the explicit routing method rather than 402 using the conventional shortest path to the destination. By this way, 403 we can influence exclusion of a number of high power AS on the way 404 from the head-end to the tail-end AS. For example, the dotted line in 405 Figure 5 represents the explicit route that is chosen by making use 406 of such TE-LSPs from head-end AS A to the tail-end AS X. Note that if 407 number of hop was the metric used by CSPF, then the route chosen is 408 the path with 3 hops. 410 0.5 411 (C) +----------------+ 412 0.5| / | 413 | / | 414 0.05 V/ 0.1 0.03 0.2 V 415 (A)...>(B)...>(D)...>(G)...>(H) 416 | | . 417 | 0.5| . 0.1 418 | V V 419 +----------->(E)--->(X) 420 0.5 0.3 422 Figure 5:Low-power path is represented by the dotted lines. This low- 423 power path has a longer number of hops than the conventional shortest 424 path. 426 2.2 LOW-POWER PATHS 428 In this section we present the low-power path algorithm. The 429 algorithm consists of two sub-algorithms: the first algorithm is 430 executed by all the ASBRs in the network and the second by all the 431 Path Computation Elements (PCEs) in their respective AS. The 432 algorithms for the ASBRs and PCEs are given as Algorithm 1, 2 and 3. 434 2.2.0.1 Algorithm 1 ASBR low-power path algorithm 436 Require: Weighted Topology Graph T=(AS, E, f) 438 1: Begin 439 2: if ROUTER == ASBR then 440 3: /* As part of IGP-TE */ 441 4: Trigger exchange of available bandwidth on bandwidth change, 442 to the AS internal neighbors; 443 5: BEGIN PARALLEL PROCESS 1 444 6: while PWR ratio changes do 445 7: Assign the PWR ratio to the Ingress links; 446 8: Exchange the PWR ratio with its external neighbors; 447 9: Exchange the PWR ratio with AS's (internal) ASBRs; 448 10: end while 449 11: END PARALLEL PROCESS 1 450 ,br 12: BEGIN PARALLEL PROCESS 2 451 13: while RSVP packets arrive do 452 14: Send and Receive TE-LSP reservations in the explicit path; 453 15: Update routing table with labels for TE-LSP; 454 16: end while 455 17: END PARALLEL PROCESS 2 456 18: end if 457 19: End 459 2.2.0.2 Algorithm 2 PCE low-power path algorithm 460 Require: Weighted Topology Graph T=(AS, E, f) 461 Require: Source and Destination for Inter-AS TE LSP with sufficient 462 bandwidth 463 1: Begin 464 2: if ROUTER == PCE then 465 3: Calculate the shortest paths from the head-end to the 466 tail-end using CSPF with PWR ratio as the metric; 467 4: if no path available then 468 5: Signal error; 469 6: end if 470 7: if path exists then 471 8: Send explicit path to head-end to construct path; 472 9: end if 473 10: Continue passively listening to BGP updates to update 474 T=(AS, E, f); 475 11: end if 476 12: End 478 2.2.1 Illustration 480 We now illustrate the proposed technique with a simple example. 482 Consider the AS level topology sub-graph shown in Figure 5 483 constructed using the strands shown in Figure 1. The PWR ratio 484 calculated at an ASBR which represents the metric for the AS is 485 assigned to the ingress link. For example, AS H has two edges coming 486 into it: one from B and the other from G. Note that the power metrics 487 for the two strands are different as G to H is lower than that of B 488 to H. This means that the lower power metric into H is better if the 489 path from G to H is chosen rather than the one from B to H. This is 490 illustrated in the Figure 5 using dotted lines. To construct a path 491 with A as the head-end AS and X as the tail-end AS, from the AS level 492 topology we see that the path A, B, H, X and A, B, E, X have the 493 shortest number of hops. However by using CSPF with the PWR ratio 494 metric as the constraint, we see that the path A, B, D, G, H, X is 495 power efficient. The routing choice will however be based on the 496 reservation of the bandwidth on this path. Given that available 497 bandwidth exists to setup a TE-LSP, the explicit path A, B, D, G, H, 498 X is chosen. The Resource Reservation Protocol (RSVP) adheres to its 499 usual operation and tries to setup a path. If bandwidth is not 500 available in the low-power path thus calculated, then we may fall 501 back to other paths like A, B, H, X or A, B, E, X provided there is 502 available bandwidth in these paths. The low-power path algorithm 503 given as Algorithm 2 is executed by the PCE. Algorithm 1 prepares the 504 topology and feeds it as input to the PCE as a weighted topology 505 graph. Using the CSPF algorithm to calculate a route from a source to 506 destination could be time consuming for a large networks. But the 507 topology is dynamically updated and hence the computation of the 508 shortest paths can be triggered based on need. We now give a 509 heuristic method based on graph-labeling that reduces the computation 510 time but could trade-off the optimal low-power path. 512 2.2.3 Equivalence class with total ordering 514 The heuristic is based on avoiding high PWR ratios. The approach 515 partitions the weighted links into equivalence classes based on a 516 range of PWR values. For each partition a labeling is applied such 517 that each link in the partition has the same label. A total ordering 518 relationship is then defined on the equivalence class. The heuristic 519 then starts including partitions with minimum label value iteratively 520 until we get a connected component, which includes the head-end and 521 tail-end AS. We apply the CSPF algorithm with the weights as label 522 values on this sub-graph to obtain the low-power path. The modified 523 algorithm which uses this scheme is given in Algorithm 3. It should 524 be noted that this algorithm could provide sub-optimal power paths as 525 the intermediate steps carry incomplete Internet topology 526 information. 528 2.2.3.1 Algorithm 3 PCE low-power path algorithm with graph labeling 529 Require: Weighted Topology Graph T=(AS, E, f) 530 Require: Source and Destination for Inter-AS TE LSP with 531 sufficient bandwidth 532 1: Begin 533 2: if ROUTER == PCE then 534 3: Group the links into N partitions with a label for 535 each partition depending on the PWR ratio 536 4: Sort the labels in ascending order. 537 5: repeat 538 6: Include the links that have the least label value; 539 7: Remove the partition with this label; 540 8: until there is a path from the head-end to tail-end AS 541 9: Calculate the low-power path using labels from the 542 head-end to the tail-end using CSPF ; 543 10: if no path available then 544 11: Signal error; 545 12: end if 546 13: if path exists then 547 14: Send explicit path to head-end to construct path; 548 15: end if 549 16: Continue passively listening to BGP updates to 550 update T=(AS, E); 551 17: end if 552 18: End 553 +------(1245)-----+ 554 / G / \G 555 / / Y \ 556 V / Y \ 557 (1339) + (6785)<------(1377)----+ 558 | | | / | 559 | G | G | + G V R 560 | | V V (2485) 561 V | (1006) (3426)--+ | 562 (34234) | Y | G | | | R 563 | | V V | V 564 | G | (11229) (4563) | (5677) 565 V | Y | | V | R 566 (23411) | V Y +-->(7786)<-+ 567 | +-->(1485)<--------/ | 568 | Y | | R 569 | V V 570 | (15467) (8298) 571 | G G | | R 572 | | | 573 | V V 574 +--------->(16578)<-------(9732) 576 Figure 6:Application of the graph-labeling heuristic. We consider 3 577 labels "G" < "Y" < "R". Using algorithm 3 the "G" path from the head- 578 end AS 1245 to the tail-end AS 16578 is chosen in the first 579 iteration. 581 2.2.4 Illustration of graph labeling 583 We briefly illustrate the graph-labeling algorithm using Figure 6. In 584 this diagram we have categorized the links into three partitions 585 based on the PWR ratio. PWR ratio less than 0:1 are labeled as G, 586 between 0:1 to 0:3 are labeled as Y and the rest as R. The total 587 ordering is defined as G < Y < R, where the G links have low PWR 588 ratios than the Y links. The path could be established through the AS 589 that have G as the ingress link; the path being 1245, 1339, 34234, 590 23411 and 16578. 592 2.3 Implementation notes and Discussion 594 In this section we present some notes on feasibility of 595 implementation of our scheme in a live network. First, the requested 596 bandwidth should be available on the low-power path, but the CSPF 597 algorithm is run with multiple constraints, one of which is the 598 bandwidth requirement for the flows to be transported through the TE- 599 LSP. The PWR ratio can then be applied to the available paths thus 600 computing the low-power paths. Second, as we are using traffic 601 engineering with link state routing protocols, there is a reliable 602 flooding process that are triggered when updates about the change in 603 characteristic arise. We propose addition of some attributes with no 604 change to the protocol implementation. There may be a time lag when 605 the far ends of the Internet receive the attribute and the time it 606 originated. This however cannot be avoided as with other attributes 607 and metrics. 609 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 610 +-------------------------------------------------------------+ 611 | Owning 32 bit Autonomous System Number | 612 +-------------------------------------------------------------+ 613 | Other 32 bit Autonomous System Number | 614 +-------------------------------------------------------------+ 615 | PWR Ratio for the AS (Consumed PWR) | 616 +-------------------------------------------------------------+ 617 | PWR Ratio for the AS (Available PWR) | 618 +-------------------------------------------------------------+ 619 | Advertising ASBR's IP router ID | 620 +-------------------------------------------------------------+ 621 | Peer ASBR's IP router ID | 622 +-------------------------------------------------------------+ 623 | 64 bit sequence number for restarts, aging | 624 | and comparison of current PWR Ratio. | 625 +-------------------------------------------------------------+ 627 Figure 7: Proposed PDU format with an added attribute for AS-PATH- 628 POWER-METRIC 630 The additions to the above Attribute have been added to optimize and 631 correctly correlate the connecting ASes and the inter-AS links among 632 them. For the traffic direction into the Advertising AS the above 633 information will be easier to correlate than the previous version 634 which did not advertise the peer AS which had the ingress links into 635 the advertising Router. 637 In MPLS-TE when the TE metrics are modified, there is a reliable 638 flooding process within an Interior Gateway Protocol (IGP). Such 639 triggered updates apply to the PWR ratio as well. The proposed PWR 640 ratio is advertised to the neighboring AS and the information 641 percolated to all the AS, in a AS-PATH-POWER-METRIC attribute. This 642 attribute can be implemented as shown in Figure 7. The frequency of 643 the updates for this attribute should be fixed to avoid network 644 flooding. 646 The AS-PATH-POWER-METRIC for each ASBR is calculated, and advertised 647 as the PWR ratio for the AS. This AS-PATH-POWER-METRIC is filled into 648 the appropriate optional transitive non-discretionary attribute and 649 inserted into a unique vector for a set of prefixes advertised from 650 the AS. Such advertised prefixes may have originated from the AS or 651 be the transit prefixes. The filled vector is sent to the ASBR of the 652 neighboring AS and the information propagates to all the ASBRs. If 653 the elements denoting AS in a vector of AS-PATH-INFO is not the same 654 as the ones that need to be advertised in a AS-PATH-POWER-METRIC, 655 then a suitable subset of AS-PATH-POWER-METRIC is identified and sent 656 in the BGP updates. A vector of size 1 also can be employed if the AS 657 in question is the only one for which PWR ratio has changed in the 658 originating AS. The collation can be done depending on availability 659 of such metrics and their mapping to a valid AS-PATH-INFO metric. 661 The power consumed by each router may fluctuate over short time 662 intervals. In order to dampen these fluctuations which can cause 663 unnecessary updates, power can be measured when falling within 664 intervals of suitable size (say a range of values). This is as 665 opposed to measuring power as a discrete quantity. This method of 666 power measurement reduces the frequency of triggered updates from the 667 routers due to power change. 669 0.1 0.2 0.1 670 (A) ---> (B) ---> (D) 672 0.1 0.2 0.02 0.2 673 (A) ---> (C) ---> (E) ---> (D) 675 0.1 0.2 676 (D) ---> (X) 678 Figure 8: Example of strands where more than one PWR ratio is 679 advertised by "D" 681 0.2 0.1 0.2 682 (A).....>(B).....>(D).....>(X) 683 | ^ 684 |0.2 0.02 | 0.2 685 +--->(C)-------->(E) 687 Figure 9:Choice of low-power path derived using the algorithm which 688 uses lower value of the ingress link but through the same AS 690 A use case of multiple ASBRs advertising differing PWR ratio shows 691 that an AS may be seen as green through one ingress link and not 692 through the other. Consider the case of multiple ASBRs that belong to 693 the same AS, advertising PWR ratios that differ. This could lead to 694 power values that belong to different classes of ratios with many 695 intervening classes in between. These advertised PWR ratios could 696 lead to one ASBR being preferred over the other thus taking a 697 different path from head-end to tail-end. This also entails that 698 there may be multiple paths to the AS through these different ASBRs. 700 Consider Figure 8 which shows a set of strands that derive a topology 701 as in Figure 9. Here D is reachable via two paths but the PWR ratios 702 differ. This illustrates the case where the better metric wins out. 703 The average power consumed would not have an effect but the bandwidth 704 available on these ASBR egress links would definitely influence the 705 path. 707 2.4 Applicability within ASes within a single Admin Domain 709 As per [draft-ietf-idr-aigp] there are deployments in which a single 710 administration runs a network which has been sub-divided into 711 multiple, contiguous ASes, each running BGP. There are several 712 reasons why a single administrative domain may be broken into several 713 ASes (which, in this case, are not really "autonomous".) It may be 714 that the existing IGPs do not scale well in the particular 715 environment; it may be that a more generalized topology is desired 716 than could be obtained by use of a single IGP domain; it may be that 717 a more finely grained routing policy is desired than can be supported 718 by an IGP. In such deployments, it can be useful to allow BGP to 719 make its routing decisions based on the IGP metric, so that BGP 720 chooses the "shortest" path between two nodes, even if the nodes are 721 in two different ASes within that same administrative domain. The 722 authors refer to the set of ASes in a common administrative domain as 723 an "AIGP Administrative Domain". 725 A combination of the AIGP administrative metric and the graph 726 heuristic algorithm could be combined to arrive at a set of a 727 suitable number k power-shortest paths and then use a tie-break 728 amongst such k power-shortest-paths with the least AIGP metric. This 729 is provided the set of ASes where the decision is being made all fall 730 under a AIGP Administrative domain. This provides a trade-off of 731 power shortest paths and least number of hops (link wise) to get from 732 source to destination across these ASes. 734 2.4.1 PWR_SESSION 736 An implementation that supports the PWR attribute CAN support a per- 737 session configuration item, PWR_SESSION, that indicates whether the 738 PWR attribute is enabled or disabled for use on that session. 740 - The default value of PWR_SESSION, for EBGP sessions, between 741 providers (distinct operators) CAN be "disabled". 743 - The default value of PWR_SESSION, for IBGP and confederation- 744 EBGP sessions, MUST be "enabled." 746 The PWR attribute MUST NOT be sent on any BGP session for which 747 PWR_SESSION is disabled. 749 If an PWR attribute is received on a BGP session for which 750 PWR_SESSION is disabled, the attribute MUST be treated exactly as if 751 it were an unrecognized transitive attribute. That is, " The 752 handling of an unrecognized optional attribute is determined by the 753 setting of the Transitive bit in the attribute flags octet. Paths 754 with unrecognized transitive optional attributes SHOULD be accepted. 755 If a path with an unrecognized transitive optional attribute is 756 accepted and passed to other BGP peers, then the unrecognized 757 transitive optional attribute of that path MUST be passed, along with 758 the path, to other BGP peers with the Partial bit in the Attribute 759 Flags octet set to 1. If a path with a recognized, transitive 760 optional attribute is accepted and passed along to other BGP peers 761 and the Partial bit in the Attribute Flags octet is set to 1 by some 762 previous AS, it MUST NOT be set back to 0 by the current AS". 764 This helps in confining the distribution of the attribute and use in 765 calculation of the power shortest paths only amongst ASes that have 766 trust relationships with other ASes. Of course, this includes and 767 promotes the use of PWR attribute within a AIGP administrative 768 domain. 770 2.4.2 Power profiles of Routers and Switches 772 It has been experimented and from several sources found that there 773 exist routers which have different power profiles. The power profile 774 of a router is the curve of power consumption to available bandwidth. 775 Mentioned below are a few of these prominent ones that have to be 776 taken into consideration. 778 The first profile that we will consider is the flattening curve. The 779 power consumed to available bandwidth curve takes the shape of a 780 steep one initially and then tapers off to a plateau. The point at 781 which it begins to give a delta-C (delta in Power Consumed) to delta- 782 B (Available Bandwidth exhausted) is the inflection point that tapers 783 off to a plateau. Here the delta-C/delta-B begins to slow down or 784 decrease rapidly. The more the traffic that is added onto the device 785 the lesser it draws power. 787 ^ 788 | 789 P | . 790 o | . 791 w | . 792 e | . 793 r | . 794 | . 795 c | . 796 o | . 797 n | . 798 s | . 799 u.| . 800 ------------------------------------> 801 | Available Bandwidth exhausted 803 The second profile that we will consider is the exponential curve. 804 The power consumed to available bandwidth curve takes the shape of an 805 ever increasing steep curve as shown below. Here the delta-C/delta-B 806 begins to increase as more traffic is thrown onto it as the Available 807 bandwidth exhausted increases. This power curve beyond a point is 808 intolerable with respect to power guzzling. 810 ^ 811 | 812 P | . 813 o | . 814 w | . 815 e | . 816 r | . 817 | . 818 c | . 819 o | . 820 n | . 821 s | . 822 u.| . 823 ------------------------------------> 824 | Available Bandwidth exhausted 826 The third profile that we will consider is a linear curve. In other 827 words just a straight line. Here delta-C/delta-B is a constant. 829 ^ 830 | 831 P | . 832 o | . 833 w | . 834 e | . 835 r | . 836 | . 837 c | . 838 o | . 839 n | . 840 s | . 841 u.| . 842 ------------------------------------> 843 | Available Bandwidth exhausted 845 2.4.2.1 Concave and Convex power curves 847 Given that there are 3 kinds of major profiles in the router power 848 consumption, what line would we like to pick. This is an important 849 point when choosing the metric to pick the low power paths. 851 (a) If the confrontation is between 2 first profile routers the lower 852 of the 2 would be considered as shown below. The lower curve offers 853 better power savings for each GB of bandwidth transported. 855 ^ 856 | 857 P | . 858 o | . 859 w | . . 860 e | . . 861 r | . . 862 | . . 863 c | . . 864 o | . . 865 n | . . 866 s | . . 867 u.| . 868 ------------------------------------> 869 | Available Bandwidth exhausted 871 (b) If the confrontation is between 2 second profile routers the 872 upper curve offers more power savings per GB of bandwidth. 874 ^ 875 | 876 P | . . 877 o | . . 878 w | . . 879 e | . . 880 r | . . 881 | . . 882 c | . . 883 o | . . 884 n | . . 885 s | . 886 u.| . 887 ------------------------------------> 888 | Available Bandwidth exhausted 890 (c) When the confrontation is between a first profile curve and a 891 second profile curve, it would be optimal to pick (as shown below) 892 the lower of the curves because it gives us lesser power consumed for 893 every GB of traffic routed / switched. Here the exponential curve is 894 the one that offers lesser amount of power consumed per GB of traffic 895 is chosen. But when it gets to a point that the two curves intersect 896 it would be more optimal to pick the tapering curve. Thus at the 897 meeting point of the 2 curves the exponential curve becomes more 898 costly and the tapering one gives us more GB for the power buck. Thus 899 this switchover from one curve to the other (in other words from the 900 exponential curve to the tapering one) does the trick in terms of 901 finding an optimal solution. 903 ^ . 904 | . 905 P | . . 906 o | (*) 907 w | . . 908 e | . . 909 r | . . 910 | . . 911 c | . . 912 o | . . 913 n | . . 914 s | . . 915 u.| .. 916 ------------------------------------> 917 | Available Bandwidth exhausted 918 (*) Metric switchover point from Consumed Power to Available Power. 920 2.4.2.3 Need to advertise both available power and consumed power 921 Thus the above sections have shown that both the available power and 922 the consumed power MUST be advertised so that case (c) can be 923 deciphered and the switchover of the curves be done and the 924 appropriate router be chosen for the rest of the bandwidth to be 925 switched over to. 927 Thus there will exist Consumed-Power to Available Bandwidth ratio and 928 the Available Power to Available Bandwidth ratio. Both the ratios are 929 computed and the lower value chosen. The Available Power can be 930 judged from the calibration process such as the one carried out by 931 independent test organizations as in [12]. An example of their 932 calibration is referred to in [12]. 934 2.5 Conclusion and Future Work 936 In this paper, we proposed a scheme for reducing the power 937 consumption of the Internet using collaborative effort between AS. 938 The topology of the Internet is represented using a graph model and 939 derived using the strands obtained from the AS-PATH attribute of the 940 BGP updates. CSPF algorithm is run on this topology by using the PWR 941 ratio as a constraint. The PWR ratio is advertised through the 942 ingress links of the ASBRs associated with AS using BGP updates. The 943 CSPF algorithm finds out the low-power consuming AS that can route 944 data packets from a head-end to a tail-end. Explicit routing is 945 handled through the use of TE-LSPs. This entails adopting routes by 946 choosing entry points to an AS that give energy saving paths. Since 947 using CSPF can be time consuming a heuristic algorithm to derive the 948 low-power paths using graph-labeling was proposed. Our work 949 complements the current schemes for reducing power consumption within 950 a router such as switching off or bringing to power-idle-state 951 certain select components within the forwarding and lookup 952 mechanisms. 954 This Power shortest Path calculation can be taken care of a Path 955 Computation Element (PCE) unit that could be either be a process 956 running on a linecard on a ASBR, or even a core router or an offline 957 engine that is passively listening to the BGP updates within the AS 958 without spitting out any routes of its own. The PCE architecture has 959 already been proposed in the ietf and even has a separate working 960 group for itself. 962 These offline or linecard engines are currently being sold in the 963 market by the networking majors and other companies that develop 964 hardware and software for the PCE. All the PCE needs to do is to 965 accept configuration and passively listen to BGP updates from various 966 peers or even be a client for a route reflector, thus 967 a) Accepting these BGP updates 969 b) Extracting the AS PATH information from these updates 971 c) Then constructing the inter-AS topology 973 d) Apply the PWR metric that comes along in these BGP updates to the 974 edges of the graph 976 e) Then compute the power shortest path as required by the 977 configuration. 979 Normally the ASes have SLA agreements between each other to carry X 980 amount of traffic from say a provider A. If the AS representing the 981 ISP then advertises fake figures to carry more traffic than is 982 mandated by the SLA agreement with other providers, then it is to 983 that ISPs detriment since by advertising a better PWR ratio it 984 invites more traffic through it thus getting paid less and carrying 985 more traffic. This is not in the best interest of the ISP. This is so 986 because in the final analysis the Power Shortest Path computed would 987 include it regardless of the amount of traffic to be carried thus 988 causing it to invite more traffic through it than it has accepted, 989 even much more than its capacity. Hence it would be advisable for 990 that ISP to advertise proper PWR ratios and NOT on the lower side of 991 the spectrum. If it advertises HIGHER PWR ratios it would not be 992 chosen, and hence that could be a policy measure NOT to accept any 993 traffic at all since its capacity may be filled up with existing 994 traffic. So advertising on the LOWER side would lead to lesser amount 995 of benefit with respect to dollar per bit transported, and on the 996 HIGHER side would be to exclude it from carrying any traffic that 997 wanted to use the Power Shortest Path. 999 We also propose that there be a governing body in the IETF or outside 1000 it or sponsored by the IETF to verify the power ratios advertised are 1001 indeed valid or approximately closer to the actual consumption. A 1002 link up for each ISP with a power application level gateway to ensure 1003 proper ratios are advertised could be mandated amongst at least the 1004 co-operating ISPs (ASes). 1006 The points on which this proposal by us innovates is as follows. 1008 a) There has been no effort prior to this to build an inter-AS 1009 topology with a weighted graph based on a PWR ratio. On this point it 1010 breaks a new path that would lead to inter-AS co-operation that 1011 contributes to power reduction overall in the internet. The paper 1012 suggested for OSPF by [10] deals with intra-Autonomous-system 1013 scenario rather than an inter-AS one. It is also to be noted that the 1014 IGP such as OSPF / IS-IS or any other link-state protocol for that 1015 matter is expected to capture the energy consumption of each router 1016 within the Autonomous system as in paper [10] to help get a hold on 1017 the overall average within the AS, or even sum up the total of all 1018 the power consumption within the AS with such intra-AS IGP LSA. This 1019 contributes to the PWR ratio proposed in our idea. Thus the intra-AS 1020 metric contributes to the PWR ratio. [10] proposal deals with 1021 primarily paths setup within an AS and not inter-AS paths. Thus the 1022 fundamental problem it solves is different while the problem we solve 1023 relates to the inter-AS paths which run across ASes from a head-end 1024 AS to a tail-end one. 1026 b) The other aspect of innovation is to use BGP as the piggyback 1027 protocol upon which this scheme stands. There has been no effort 1028 earlier to approach the internet power reduction problem with BGP as 1029 the mode of transport of the energy ratios and coupling it with the 1030 inter-AS topology built with AS-PATH-INFO information. 1032 The above 2 are key aspects of innovation. 1034 When links and switches are gated or put into low-power state within 1035 an AS, the power-consumption automatically drops at the aggregate 1036 level, as a result of which the PWR ratio would be a lower figure 1037 advertised through BGP and thus this AS would attract more Power 1038 Shortest Path traffic through it. Thus the links within the AS and 1039 the switches within it would function more optimally if it had more 1040 traffic that went along paths that were originally put in low-power 1041 state thus utilizing the paths more effectively, when attracting PSP 1042 traffic. 1044 There exist MIBs today that have object identifier for power consumed 1045 in a router. Maybe all the related components within it may NOT be 1046 listed with regards to power consumed. But the overall power consumed 1047 by the Router / Switch is gettable. Once it is advertised in a opaque 1048 Link-State-Advertisement say in the form of a TLV and the LSAs are 1049 flooded through the network in an AS, all routers get a uniform 1050 picture of which router consumes what power. This method already 1051 exists for Traffic engineering Database LSAs that are advertised as 1052 LSAs for the purpose of traffic engineering within an AS. We are 1053 merely piggybacking on this capability to calculate the PWR ratio at 1054 the ASBR which amongst others is yet another Router / Switch of the 1055 AS. 1057 Our future work includes looking into computing low-power paths 1058 within AS as well. Further it can be noted that the proposed 1059 algorithms might lead to increased latency as the number of hops 1060 increase, which could be critical for time sensitive applications. 1061 Since the PWR ratio could vary dynamically with traffic, the impact 1062 of traffic on the algorithm would also be of interest. 1064 2.6 Acknowledgements 1066 Shankar Raman would like to acknowledge the support by BT Public 1067 Limited (UK) under the BT IITM PhD Fellowship award. Balaji Venkat 1068 and Gaurav Raina would like to acknowledge the UK EPSRC Digital 1069 Economy Programme and the Government of India Department of Science 1070 and Technology (DST) for funding given to the IU-ATC. We would like 1071 to acknowledge that a version of this paper has been accepted in 1072 IARIA conference ENERGY 2012. 1074 3 Security Considerations 1076 No specific security considerations apart from the usual 1077 considerations with respect to authenticating BGP messages / updates 1078 from BGP neighbors is necessary for this scheme. 1080 4 IANA Considerations 1082 A new optional transitive non-discretionary attribute needs to be 1083 provided by IANA for carrying the PWR ratio across the Internet in 1084 the specified format in BGP. 1086 5 References 1088 5.1 Normative References 1090 5.2 Informative References 1092 REFERENCES 1094 [1] G. Appenzeller, Sizing router buffers, Doctoral 1095 Thesis, Department of Electrical Engineering, Stanford 1096 University, 2005. 1098 [2] A. P. Bianzino, C. Chaudet, D. Rossi and J. L. 1099 Rougier, A survey of green networking research, IEEE 1100 Communications and Surveys Tutorials, preprint. 1102 [3] J. Baliga, K. Hinton and R. S. Tucker, Energy 1103 consumption of the internet, Proc. of joint international 1104 conference on optical internet, June 2007, pp. 1-3. 1106 [4] J. Chabarek, J. Sommers, P. Barford, C. Estan, D. 1107 Tsiang and S. Wright, Power awareness in network design 1108 and routing, Proc. of the IEEE INFOCOM 2008, April 2008, 1109 pp. 457-465. 1111 [5] B. Venkat et.al, Constructing disjoint and partially 1112 disjoint InterAS TE-LSPs, USPTO Patent 7751318, Cisco 1113 Systems, 2010. 1115 [6] M. Xia et. al., Greening the optical backbone network: 1116 A traffic engineering approach, IEEE ICC Proceedings, May 1117 2010, pp. 1-5. 1119 [7] W. Lu and S. Sahni, Low-power TCAMs for very large 1120 forwarding tables, IEEE/ACM Transactions on Computer 1121 Networks, June 2010, vol. 18, no. 3, pp. 948-959. 1123 [8] B. Zhang, Routing Area Open Meeting, Proceedings of 1124 the IETF 81, Quebec, Canada, July 2011. 1126 [9] M.J.S Raman, V.Balaji Venkat, G.Raina, Reducing Power 1127 consumption using the Border Gateway Protocol, IARIA 1128 conferences ENERGY 2012. 1130 [10] A.Cianfrani et al., An OSPF enhancement for energy 1131 saving in IP Networks, IEEE INFOCOM 2011 Workshop on Green 1132 Communications and Networking 1134 [draft-ietf-idr-aigp] P. Mohapatra et.al, The Accumulated 1135 IGP metric attribute for BGP, 1136 https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/, 1137 November 2012. 1139 Authors' Addresses 1141 Shankar Raman 1142 Department of Computer Science and Engineering 1143 IIT Madras, 1144 Chennai - 600036 1145 TamilNadu, 1146 India. 1148 EMail: mjsraman@cse.iitm.ac.in 1150 Balaji Venkat Venkataswami 1151 Department of Electrical Engineering, 1152 IIT Madras, 1153 Chennai - 600036, 1154 TamilNadu, 1155 India. 1157 EMail: balajivenkat299@gmail.com 1158 Prof.Gaurav Raina 1159 Department of Electrical Engineering, 1160 IIT Madras, 1161 Chennai - 600036, 1162 TamilNadu, 1163 India. 1165 EMail: gaurav@ee.iitm.ac.in