idnits 2.17.1 draft-lee-hmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 351 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 435 looks like a reference -- Missing reference section? '2' on line 439 looks like a reference -- Missing reference section? '3' on line 444 looks like a reference -- Missing reference section? '7' on line 460 looks like a reference -- Missing reference section? '4' on line 448 looks like a reference -- Missing reference section? '5' on line 453 looks like a reference -- Missing reference section? '6' on line 457 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Seoung-Bum Lee 2 INTERNET-DRAFT Jiyoung Cho 3 draft-lee-hmp-00.txt Andrew T. Campbell 4 Expires: March 2004 Columbia University 5 October 2003 7 Hotspot Mitigation Protocol (HMP) 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of 26 Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Abstract 33 This draft specifies a Hotspot Mitigation Protocol (HMP) for 34 mobile ad hoc networks that use on-demand routing protocols and 35 the IEEE 802.11 MAC. Hotspots represent transient but highly 36 congested regions in wireless ad hoc networks that result in 37 increased packet loss, end-to-end delay, and out-of-order 38 packets delivery. Using HMP, mobile nodes independently monitor 39 local conditions (e.g., buffer occupancy, packet loss, and MAC 40 contention and delay) in a fully distributed manner, and take 41 local actions in response to the emergence of hotspots, such as, 42 suppressing new route requests and rate controlling TCP flows. 43 As a result, HMP improves end-to-end throughput, delay, and 44 packet loss, balances the resource consumption among neighboring 45 nodes, and finally, improves the network connectivity by 46 preventing premature network partitions. 48 Table of Contents 50 1. Introduction .............................................. 2 51 2. Hotspots .................................................. 3 52 2.1 Existence of Hotspots ..................................... 4 53 2.2 Hotspot Detection ......................................... 4 54 2.2.1 MAC-delay violation .................................... 5 55 2.2.3 Packet Loss ............................................ 6 56 2.2.3 Buffer Occupancy ....................................... 6 57 2.3 Hotspot Region ............................................ 6 58 3. Hotspot Mitigation Protocol ............................... 6 59 3.1 HMP Operation ............................................. 8 60 3.2 Congestion Levels ......................................... 9 61 3.3 Energy-awareness .......................................... 9 62 3.4 Protocol Sensitivity ..................................... 10 63 4. Acknowledgement .......................................... 10 64 5. Reference ................................................ 11 65 6. Author's Addresses ....................................... 11 67 1. Introduction 69 Hotspots are often created in regions of mobile ad hoc networks 70 (MANETs) where flows converge and intersect with each other. 71 Hotspots are defined as nodes that experience flash congestion 72 conditions or excessive contention over longer time-scales (e.g., 73 order of seconds). Under such conditions nodes typically consume 74 more resources (e.g., energy) and attempt to receive, process, and 75 forward packets but the performance of the packet forwarding and 76 signaling functions is considerably diminished and limited during 77 hotspot periods. This is the result of excessive contention of the 78 shared media wireless access, and due to flash loading at hotspot 79 nodes, and importantly, at neighboring nodes that are in the region 80 of hotspots. Hotspots are often transient in nature because the 81 mobility of nodes in the network continuously creates, removes, and 82 to some degree, migrates hotspots because node mobility changes the 83 network topology and causes flows to be rerouted. Hotspots are 84 characterized by excessive contention, congestion, and resource 85 exhaustion in these networks. In other words, hotspots appear when 86 excessive contention exists, prompting congestion when insufficient 87 resources are available to handle the increased traffic load. 89 Hotspots are intrinsic to many on-demand MANET routing protocols 90 because most on-demand routing protocols [1][2][3] utilize shortest 91 path (or hop count) as their primary route creation metric. Most 92 on-demand routing protocols allow an intermediate node to reply to a 93 route query using cached route information, causing traffic to 94 concentrate at certain nodes. Although many on-demand routing 95 protocols prove to be effective in routing packets in these 96 networks they also have a propensity to create hotspots, where these 97 hotspots consume a disproportionate amount of resources (e.g., energy) 98 [7]. Other researchers have made similar observations [4][5][6]. 100 Ideally, establishing routes through non-congested 101 areas of the network and rerouting active flows away 102 from congested areas to non- congested areas would be the best 103 approach to hotspot mitigation. However, this requires extensive 104 collaboration between nodes to establish load-aware routes and 105 sophisticated algorithms to update time-varying loading conditions. 106 Such an approach is unscalable and not practical in mobile ad hoc 107 networks. 109 This draft specifies a Hotspot Mitigation Protocol (HMP) for 110 mobile ad hoc networks that use on-demand routing protocols and 111 the IEEE 802.11 MAC. Hotspots represent transient but highly 112 congested regions in wireless ad hoc networks that result in 113 increased packet loss, end-to-end delay, and out-of-order 114 packets delivery. Using HMP, mobile nodes independently monitor 115 local conditions, and take local actions in response to the 116 emergence of hotspots. As a result, HMP improves end-to-end 117 throughput, delay, and packet loss, balances the resource 118 consumption among neighboring nodes, and finally, improves the 119 network connectivity by preventing premature network partitions. 120 HMP represents a fully distributed and scalable protocol where nodes 121 independently monitor local conditions and take local actions: 123 o to declare a node to be a hotspot if a combination of MAC 124 contention/delays, packet loss, buffer occupancy, and remaining 125 energy reserves exceed certain predefined system thresholds; 127 o to suppress new route requests at hotspots to ensure that routed 128 traffic does not compound congestion problems; and 130 o to throttle traffic locally at hotspots to force TCP flows to 131 slow down. 133 2. Hotspots 135 2.1 Existence of Hotspots 137 Hotspots are generally created when traffic converges to a node or 138 small cluster of nodes. Flows traversing multiple wireless hops from 139 various locations intersect with each other and create transient 140 hotspot conditions. Hotspot nodes and nodes in the vicinity of 141 hotspots (i.e., in hotspot regions) are prone to consume more 142 resources than others. Left unchecked such unbalanced resource 143 consumption is detrimental to mobile ad hoc networks because 144 overtaxed nodes would prematurely exhaust their energy reserves 145 before other nodes. As a consequence the network connectivity can be 146 unnecessarily impacted. 148 In addition, it is observed that hotspot nodes are often responsible 149 for generating a large amount of routing overhead. In general, as 150 the traffic load increases more hotspots appear and conditions in 151 hotspots (or hotspot regions) become aggravated. For detail 152 on the evaluation of hotspots in MANETs see [7]. 154 2.2 Hotspot Detection 156 A number of system parameters are used by HMP to identify hotspots. 157 These per-node parameters, which are associated with MAC-delays, 158 packet loss, and buffer occupancy, can be configured to make HMP's 159 hotspot detection mechanism more or less aggressive in its 160 declaration of hotspots. In current version of HMP implementation, 161 hotspots are detected using 3 criteria: 163 1. MAC-delay Violations 164 2. Packet Loss 165 3. Buffer Occupancy 167 2.2.1 MAC-delay Violation 169 The MAC_DELAY_THRESH parameter is used by the protocol to detect 170 MAC-delay violations. If the measured MAC-delay exceeds the 171 MAC_DELAY_THRESH then HMP considers this a MAC-delay violation. If 172 the number of these violations exceeds a predefined value called 173 N_THRESH then the protocol takes a number of actions discussed 174 below. We define the MAC-delay as the measured time for the 175 successful transmission of a data packet at the MAC layer. This 176 includes the time taken for the RTS-CTS-DATA-ACK message exchange 177 over the air. As shown in Figure 1, the MAC-delay measurement represents 178 the time between T_(j) and T_(i). Because IEEE 802.11 defines up to 179 7 possible retransmissions of a data packet the measured MAC-delay 180 could represent up to a maximum of 7 RTS-CTS-DATA-ACK cycles in the 181 case were packet loss occurs. 183 Node(A) Node(B) 184 | | 185 send RTS at T_(i) | ------- RTS -------> | 186 | <------ CTS -------- | 187 | ------- DATA-------> | 188 receive ACK at T_(j) | <------ ACK -------- | 190 MAC-delay = T_(j) - T_(i) 192 Figure 1: MAC Delay Measurement 194 Each node continuously monitors the on-going MAC-delay and compares 195 it to the MAC_DELAY_THRESH value. The N_THRESH parameter is used to 196 control the sensitivity of the protocol to the measured MAC-delays. 197 N_THRESH defines how many consecutive MAC-delay violations can be 198 tolerated before a node is declared a hotspot. This parameter 199 essentially determines how aggressive HMP is in declaring hotspots. 200 In other words, a node is identified as a hotspot when the 201 MAC_DELAY_THRESH parameter is consecutively violated more than 202 N_THRESH times. 204 2.2.2 Packet Loss 206 Hotspot detection also needs to consider the case of packet loss. In 207 the case where there is an intermittent packet loss between two 208 consecutive MAC-delay violations, HMP takes account of this 209 condition during hotspot detection; that is, a node is also 210 considered a hotspot when the MAC_DELAY_THRESH parameter is violated 211 (N_THRESH - (k)) times, where k is defined as the number of 212 intermittent packet losses during a hotspot detection interval. Note 213 that HMP monitors packet losses at MAC layer during RTS-CTS-DATA-ACK 214 exchange. 216 A hotspot detection interval starts when the first MAC-delay 217 violation is observed and lasts until the node either declares 218 itself a hotspot based on the criteria described above or a data 219 packet is successfully delivered without a MAC-delay violation. The 220 MAC-delay violation count maintained by HMP during the hotspot 221 detection interval is reset at the beginning of a new interval. Note 222 that many MANET routing protocols consider that three consecutive 223 packet losses represents link or route failure. Any link failure or 224 route error also resets all associated counters/parameters used by 225 HMP's hotspot detection. 227 2.2.3 Buffer Occupancy 229 HMP also monitors buffer occupancy to identify hotspots. If a node 230 detects that the buffer occupancy exceeds a predefined threshold 231 called BUFFER_THRESH then it will check for MAC-delay violations. 232 The BUFFER_THRESH parameter is set to a buffer level that is less 233 than the buffer overflow mark. If BUFFER_THRESH is exceeded and 234 there is at least one MAC-delay violation within current hotspot 235 detection interval then the node declares itself a hotspot. HMP 236 adopt this hybrid approach to hotspot detection because buffer 237 occupancy information alone is insufficient to declare a hotspot 238 unless the buffer overflow mark is exceeded. As a result HMP 239 combines buffer occupancy with MAC-delay violations to make the 240 approach more accurate. 242 2.3 Hotspot Regions 244 A node belongs to a hotspot region if it is a hotspot or it is an 245 immediate neighbor of a hotspot node. 247 3. Hotspot Mitigation Protocol 249 3.1 Protocol Operations 251 HMP utilizes MAC-delay measurements, packet loss, buffer occupancy 252 information, neighbor status information and other resource 253 monitoring mechanisms (i.e., energy) to detect hotspots. HMP does 254 not limit the scope of monitoring and detection mechanisms, however. 255 Operators are free to introduce additional mechanisms and algorithms 256 according to their needs. In fact, it is envisioned that a HMP 257 network would embody diverse mechanisms operating concurrently. HMP 258 utilizes measured information to respond to conditions by executing 259 the most appropriate algorithms to alleviate the condition at hand. 260 The measured conditions are expressed by a multi-metric parameter 261 called STATUS, which consists of two components: symptom and 262 severity. 264 Symptom describes the dominant condition a node is experiencing 265 while severity expresses the degree of the symptom. For example, a 266 node may declare its status as MODERATE_CONGESTION while another 267 node may declare its status as CRITICAL_ENERGY. 269 HMP piggybacks this status information in the IP option field and 270 neighboring nodes operating in promiscuous mode learn the status of 271 transmitters by eavesdropping their packets. The eavesdropped 272 information is used to create and update a Neighborhood Status Table 273 (NST). This status information is cached and locally maintained and 274 updated at each node. 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |Version| IHL |Type of Service| Total Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 ` | Identification |Flags| Fragment Offset | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Time to Live | Protocol | Header Checksum | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Source Address | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Destination Address | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Options (Used for HMP Options) | Padding | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 2. IP Header 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | STATUS (Symtom, Severity) |PI | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * PI = PATH_INDICATOR 298 Figure 3. HMP IP Option 300 A NST caches a list of immediate neighbors and their status. It is 301 primarily used to manipulate new-route-creation decisions at nodes. 302 A node refers to its NST to ensure that it is not aggravating the 303 conditions of neighboring nodes by creating new routes through them. 305 It is assumed that there exist only a finite number of neighboring 306 nodes surrounding any node, which in effect defines the size of the 307 NST at a node. Naive suppression of new route creation may prevent 308 the use of the only possible path between two hosts and may yield 309 poor connectivity in the network, or even cause network partitions. 310 To avoid this, the 'new-route-suppression-mechanism' is used, if and 311 only if, there exists a sufficient number of non-hotspot neighbors 312 within its transmission range. HMP also makes sure that preceding 313 nodes en-route also have enough non-hotspot neighbors. 315 The notion of enough neighbors is defined by the NUM_ENOUGH_NEIGHBOR 316 parameter. This parameter has a direct impact on the network 317 connectivity. If NUM_ENOUGH_NEIGHBOR is too small, HMP manifests low 318 connectivity and may fail to provide useful routes. 320 HMP also ensures that it is not inadvertently denying the only 321 possible path between two end hosts by utilizing an indicator called 322 the 'PATH_INDICATOR', which is carried in the IP option field of 323 Route Request messages. A node that has only a few non-hotspot 324 neighbors (i.e., number of neighbors less than NUM_ENOUGH_NEIGHBOR) 325 sets this indicator (PATH_INDICATOR = 1) and upstream nodes that 326 receive the Route Request messages check this indicator and avoid 327 suppressing new routes if it is set. Nodes receiving packets with 328 this indicator set know that at least one preceding node explicitly 329 requested no new-route-suppression. This is a valuable HMP feature 330 because it provides a safeguard against potential over-suppression 331 of new route creation that may result in limited connectivity. 333 3.2 Congestion Levels 335 Main objective of congestion avoidance algorithms is preventing 336 further build up of traffic at hotspots. HMP distinguishes two 337 levels of congestion (i.e., levels 1 and 2) and adopts two 338 corresponding algorithms to support this view. 340 The first algorithm is activated when HMP determines the current 341 status of a node is in a moderately congested condition (i.e., level 342 1). This algorithm simply suppresses creation of additional routes 343 at hotspots by discarding new route request packets. As mentioned 344 previously, HMP ensures not to deny the only route between two 345 hosts. 347 The second algorithm is more aggressive and executes when nodes 348 encounter substantial congestion (i.e., level 2). This algorithm is 349 executed when a node experiences severe hotspot conditions without 350 any non-hotspot neighbors. This algorithm not only suppresses new 351 route creation but also throttles best effort TCP flows traversing 352 the node in an attempt to reduce the load using rate control 353 mechanisms. TCP flows are bandwidth hungry and unless controlled can 354 easily occupy all remaining wireless medium bandwidth. Throttling 355 TCP rates locally in this manner does not necessarily hurt TCP 356 sessions but can effectively relieve congestion bottlenecks. Users 357 and operators are free to introduce other schemes to relieve 358 congestion conditions, e.g., one simple policy is dropping TCP 359 packets at bottleneck nodes. 361 HMP attacks the congestion at the point of congestion as opposed to 362 a traditional end-to-end approach. Although congestion is an 363 end-to-end issue where it is detected and controlled (e.g., as in 364 the case of TCP), traditional remedies for end-to-end congestion 365 control are not effective in mobile ad hoc networks. In fact, such 366 traditional control mechanisms may limit the utilization of the 367 wireless medium that is constrained by hotspots. We argue that we 368 can avoid such shortcomings if we tackle the problem at the point of 369 congestion rather than responding on end-to-end basis. 371 3.3 Energy-awareness 373 Mobile ad hoc networks are essentially energy-limited networks and 374 are likely to be comprised of heterogeneous nodes with diverse 375 energy constraints. Some mobile devices will have large energy 376 reserves in comparison to others. There exist various energy-aware 377 power-conserving protocols for mobile ad hoc networks. The common 378 objective of these protocols lie in conserving energy as much as 379 possible to prolong the lifetime of the network or extend the 380 lifetime of individual nodes. Although energy conservation is not a 381 primary concern of HMP, the protocol provides a simple mechanism to 382 conserve energy through its status declaration mechanism. A node 383 with limited energy reserves can declare itself a hotspot when its 384 energy reserves are marginally or critically low. 386 A node with energy concerns is acknowledged by neighboring nodes and 387 new route creation through such a node is avoided if possible. On 388 the other hand, a node with critical energy immediately relinquishes 389 its role as a router and functions strictly as an end host in order 390 to conserve energy (maximize its lifetime) unless it is identified 391 as the only intermediate node between two communicating end hosts. 393 3.4 Protocol Sensitivity 395 Three key parameters govern the HMP system control mechanisms. These 396 are, MAC_DELAY_THRESH, N_THRESH and NUM_ENOUGH_NEIGHBOR. A 397 sensitivity analysis is provided in [7]. 399 For example, if the MAC_DELAY_THRESH value is too small HMP becomes 400 aggressive and may declare too many hotspots. A small increase in 401 the MAC-delay measurement (or jitter) may falsely be recognized as 402 congestion with many nodes being claimed as hotspots. In contrast, 403 if the MAC_DELAY_THRESH value is too large HMP may not identify any 404 hotspots in the network and relegate itself to the baseline system. 406 The second parameter N_THRESH is used to prevent HMP from reacting 407 to transient behavior. A momentary increase in the MAC-delay 408 measurement and buffer occupancy are not necessarily a product of 409 congestion or excessive contention. Delay may be observed for a very 410 short period due to the rerouting of flows or a small burst of route 411 query packets. Reacting to such transitory phenomenon is not 412 beneficial because real hotspots cannot be distinguished from 413 transient events. 415 The third parameter is the NUM_ENOUGH_NEIGHBOR. Naive suppression of 416 new route creation at a hotspot node may prevent the use of the 417 'only possible path' between two hosts and may yield poor 418 connectivity in the network, or even cause network partitions. To 419 avoid this, a new-route-suppression mechanism is executed, if and 420 only if, there exists a sufficient number of non-hotspot neighbors 421 within its transmission range. The notion of 'sufficient number of 422 neighbors' is defined by the NUM_ENOUGH_NEIGHBOR parameter. This 423 information is piggybacked through PATH_INDICATOR to ensure that 424 preceding nodes en-route meet this 'sufficient number of neighbors' 425 condition when 'new-route-suppression' is executed. 427 4. Acknowledgement 429 This work is supported in part by the Army Research Office (ARO) 430 under Award DAAD19-99-1-0287 and with support from COMET Group 431 industrial sponsors. 433 5. Reference 435 [1] C. Perkins and E. Royer. "Ad hoc On-Demand Distance Vector Routing. 436 Proc. of the 2nd IEEE Workshop on Mobile Computing Systems and 437 Applications, New Orleans, LA, February 1999, pp. 90-100 439 [2] David B. Johnson, David A. Maltz, and Josh Broch. "DSR: The Dynamic 440 Source Routing Protocol for Multi-Hop WirelessAd Hoc Networks", in 441 Ad Hoc Networking, edited by Charles E. Perkins, Chapter 5, pp. 442 139-172, Addison-Wesley, 2001 444 [3] V. Park and S. Corson "A Highly Adaptive Distributed Routing 445 Algorithm for Mobile Wireless Networks, Proc. IEEE Infocom 1997, 446 Kobe, Japan 448 [4] Samir R. Das, Charles E. Perkins, and Elizabeth M. Royer. 449 "Performance Comparison of Two On-demand Routing Protocols for Ad 450 Hoc Networks." Proceedings of the IEEE Conference on Computer 451 Communications (INFOCOM), Tel Aviv, Israel, March 2000 453 [5] S.B Lee, G.S. Ahn, and A.T. Campbell, "Improving UDP and TCP 454 Performance in Mobile Ad Hoc Networks with INSIGNIA", June 2001, 455 IEEE Communication Magazine. 457 [6] S.J. Lee and M. Gerla "Dynamic Load-Aware Routing in Ad hoc 458 Networks" Proceedings of IEEE ICC 2001, Helsinki, Finland, June 2001 460 [7] Seoung-Bum Lee and Andrew T. Campbell, "HMP: Hotspot Mitigation 461 Protocol for Mobile Ad hoc networks", Ad Hoc Networks Journal, 462 Vol.1 No.1, March 2003 464 6. Author's Addresses 466 Seoung-Bum Lee, Jiyoung Cho, Andrew T. Campbell 468 Department of Electrical Engineering, 469 Columbia University, 470 500 W. 120th Street, Room 1312, New York, NY 10027 472 Phone : 1-212-854-0608 473 Fax : 1-212-316-9068 474 Email : sbl@comet.columbia.edu