Network Working Group (Editor)Srikanth Chavali INTERNET DRAFT Vasile Radoaca Expiration Date: February 2004 Paul Knight Nortel Networks, Inc. Luyuan Fang AT&T Susan Hares NextHop Technologies September 2003 Peer Prefix Limits Exchange in BGP draft-chavali-bgp-prefixlimit-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes a mechanism to allow BGP peers to coordinate the setting of a limit on the number of prefixes which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding of routes, which can occur when a maximum prefix limit is configured on the "receiving" peer, and the "sending" peer exceeds the limit. Srikanth Chavali et.al. Expires February 2004 [Page 1] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. In this document we use the term "BGP sender" to refer to a BGP speaker which is advertising prefixes to its peer. We use the term "BGP receiver" to refer to a BGP speaker which is receiving prefixes from its peer. Although it is clear that in reality each peer is usually both a "BGP sender" and a "BGP receiver", we emphasize a unidirectional relationship in this document for clarity. 2. Introduction There are many scenarios where BGP [BGP-4] peering may be established between two speakers in which there is an expectation that some limited number of prefixes will be announced by a given speaker. Several of these scenarios are described in the following section. In these scenarios, if the expected number of prefixes is exceeded, then the peering session may be disrupted. The disruption may be due to a specific configuration which is functioning properly in order to prevent an overload condition, or it may occur when the receiving BGP speaker becomes overloaded and suffers various consequences. Note that in this document we use the term "BGP sender" (or "sender")to refer to a BGP speaker which is advertising prefixes to its peer. We use the term "BGP receiver" (or "receiver") to refer to a BGP speaker which is receiving prefixes from its peer. A BGP speaker will typically be both a BGP sender and receiver, but we focus on a unidirecitonal relationship for clarity. Several implementations of BGP offer a configuration option that allows a BGP receiver to provision a limit to the number of prefixes it will accept from a specific peer. When the limit is exceeded, then there are generally two options: the prefixes exceeding the limit can be dropped by the BGP receiver, or the peering session may be terminated by the BGP receiver and restarted at a later time. Neither of these options is desirable. Dropping prefixes leads to network unreliability, since the dropped prefixes will be unreachable through the BGP receiver. Terminating the BGP session is probably worse, since all traffic between the peers will typically be disrupted, even for those prefixes which were advertised before the limit was reached. Other undesirable effects include resource utilization on the peers from restarting the peering session, and the processing load and bandwidth utilization from withdrawing and re- advertising the prefixes throughout the Internet. Srikanth Chavali et.al. Expires February 2004 [Page 2] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 In many cases, the result of not limiting the number of received BGP prefixes can be much worse than either case just mentioned. If the BGP receiver becomes overloaded, it can fail and affect many or all of its peers. The effects of the disruptions caused by lost peering sessions and device failures propagate through the Internet, leading to instability as described in detail in [BGP-STUDY]. Although there are a variety of conditions which can cause a BGP sender to announce more prefixes than expected, the root cause of the problems described above is that the BGP sender is not aware of the limits set by the BGP receiver, and does not have a specific mechanism to restrict the number of announced prefixes to the number allowed by the receiver. This proposal addresses most of these issues in a manner which minimizes the likelihood for severe disturbances to network service when the BGP sender exceeds the allowed number of prefixes. 2.1 Background In the basic BGP protocol, BGP speaker have announce all routes permitted by bgp policy to peers. With the introduction of Virtual Private Networks (VPN) services using additional private routes comes a potential for unexpected route overload based on misconfiguration or true addition of routes. Another source of unexpected route increases are denial of service attacks based in sending additional more specific routes or virtual private network routes. Close cooperation between the operators of two peered BGP speakers can coordinate the configurations of the two devices and avoid many issues. However, network changes, misconfigurations, miscommunications, or other factors frequently result in situations where the number of prefixes advertised from a BGP sender to the receiver exceeds the expected number, and the configurations must be revised. Until the configurations can be modified, various disruptions can result. The intent of this proposal is to provide a mechanism by which both peers can become aware of a prefix limit. If the number of prefixes approaches the known limit, both peers can provide warning to their respective operators, and even if the limit is reached, both devices can behave in a manner to preserve network stability until the operators can address the cause of the excessive prefix condition. In addition, the option to terminate the session is retained in order to protect the BGP receiver, if the BGP sender ignores the limit. Srikanth Chavali et.al. Expires February 2004 [Page 3] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 The basic function proposed here is for a BGP receiver which implements a limit on the number of prefixes which it will accept (a "maximum prefix limit") to send an advertisement of that limit to its peer BGP sender, at the time the peering session is initiated. That is, a BGP receiver configured with a maximum-prefix limit notifies its peer BGP sender of the limit, so that the sender should automatically restrict the number of prefixes it announces, in order to comply with the limit. 2.2 Current Service Provider Perspective We provide an example to illustrate a typical Service Provider's (SP) practice with maximum prefix limit. The provider may set two levels of threshold on the BGP receivers at the network edge: - low water mark as warning threshold - high water mark as dropping threshold. When the warning threshold is triggered, SNMP traps are transmitted by the SP's BGP receiver (router) to the SP's management system. The operator needs to contact the customer upon receiving the trap. When the dropping threshold with maximum prefix limit is reached, the BGP session may be dropped by the BGP receiver. Again it would generate traps on the provider side. (Some implementation may not drop the session, but drop the customer's routes or prefixes silently.) Then the operator needs to work with the customer to correct the problem and restart the session. There are several issues around this process: - First, the provider has to prove to the customer that the session drop was due to customer violating the agreed maximum prefix limit rather than being due to the operator's network condition causing the session drop. - Secondly, the operator has to work with customer to locate the root cause, and more likely manually bring back the BGP peering session at an agreed time. This is labor intensive for the operator and the customer. - Finally, the customer may be unhappy about the session drop regardless of the reason. Due to the above reasons, as todays common practice, a provider may choose not to use the maximum prefix limit feature for their Internet services to avoid these complications. But the same provider may choose to use the maximum prefix limit feature in their MPLS VPN services for customer connection, due to edge device resource management needs which are particularly associated with VPN services. The issues of where to use and not to use the maximum prefix limit feature are beyond the scope of this draft. In this draft, we are promoting a proactive approach to dealing with Srikanth Chavali et.al. Expires February 2004 [Page 4] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 maximum prefix limit issues. With reference to the example above on the relation of provider and customer edge devices, we propose to engage the customer edge devices (BGP senders) to participate in the process as well. When the maximum prefix limit with multiple thresholds is first set on the provider edge device, it is immediately communicated to the customer edge devices device through BGP signaling, and both sides communicate dynamically whenever an unexpected event triggers any of the threshold levels. We propose to set three levels of threshold: - The first level triggers the warning on both provider and customer edge devices, so customer should act on it without waiting for the provider to call. - The second level triggers the customer edge device to stop sending routes, as it is reaching the agreed max prefix limit. This may also result in traps being issued on both customer and provider side. The idea is to have the customer take action to fix the problem without dropping the session, thereby requiring less human intervention from the provider side. - The third level triggers the session drop action from the provider side. This is used as safeguard for the providers network in case the customer edge device did not behave as expected and is continuing to send routes after exceeding the second level threshold. We believe this feature can help both providers and customers to proactively manage their BGP connections by dynamic signaling, monitoring and taking corrective actions before any drastic action is necessary. In many cases, this can help avoid service interruption, avoid finger-pointing when sessions are dropped, lower operation cost, and increase customers satisfaction. In general, this feature can be applied to provider - provider peering connections as well, with similar advantages. 3. Analysis of Prefix Limit Scenarios This section describes some scenarios in which it is desirable to limit the number of prefixes advertised between BGP speakers, and the operation of the proposed mechanism in the scenario. It should be noted here that this feature is not just restricted to these scenarios. 3.1 ISP and Customer with VPN Consider the following scenario where BGP peering session is established between the CE and the PE. +--------+ +--------+ | CE | <-----------------> | PE | +--------+ +--------+ Srikanth Chavali et.al. Expires February 2004 [Page 5] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 Both the PE and the CE need to support this functionality. In this case both the CE and PE exchange prefix limits as an optional capability parameter in OPEN message. When CE runs into a situtaion where it has routes to advertise and the maximum prefix limit condition is encountered it stops sending new UPDATES. This helps the CE and PE take corrective measures without affecting itself and the PE, thus saving service disruption. Both the PE and CE get benefitted from this. In the options provided by several implementations the CE would continue to send routes even after exceeding the maximum prefixes. It could be stopped only after a manual intervention at CE at that very instant. PE after detecting the excess routes recieved would either discard routes or would reset the peering session. The effects of these have already been introduced in section 2. 3.2 Two ISPs and Multi-homed Customer AS1 AS2 +--------+ +--------+ | R1 |---------------------| R3 | +--------+ +--------+ |_____________ _______________| _____________X_______________ | | +--------+ +--------+ | R2 |---------------------| R4 | +--------+ +--------+ In the above multihoming scenario service provider managing AS2 routers R3 and R4 would be able to predic the routes they can receive from R1 and R2 in AS1. This will enhance their ability to better plan and optimize their resources through configurations in such a way that it will increase their revenues and provide uninterrupted service. Similar advantages hold true for this scenario described section 2, however in this case both the service providers of AS1 and AS2 get benefitted. 4. Definition of Prefix limit Prefix limit is encoded as an optional capability parameter [BGP-CAP] in the BGP OPEN message [BGP-4] by each BGP speaker as shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |code | length | AFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Srikanth Chavali et.al. Expires February 2004 [Page 6] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 | SAFI |sub code 1 | length | warning - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix limit |w| sub code 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | length | maximum prefix - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | limit |s| sub code 3 | length | reset - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix limit |r|sub code-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | length | current Rx | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | routes | sub code 5 | length | curr - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ent Tx routes | Resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Meaning for each of the bitwise indicated capability fields above is as follows: Code: code identifying this capability (TBD) Length: length of the capability value field is 34 octets Address Family Identifier AFI: This along with the Subsequent Address Family Indentifier field identifies the Network Layer Protocol associated with the Network Address. Subsequent Address Family Identifier SAFI: This along with the Address Family Identifier field identifies the Network Layer Protocol associated with the Network Address. sub code 1: It is used to identify the number of routes sent before raising warning. This is done by the BGP speaker that detects it. warning prefix limit: Number of routes sent by the BGP sender. The value for this field is dependent on the maximum prefix limit and SHOULD be always less than Srikanth Chavali et.al. Expires February 2004 [Page 7] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 it. w (Warning Indicator): This field can be assigned a value of 1 or 0. A value of 1 means the warning indication is necessary and SHOULD be used by the sender when its route advertisement equals the number of sent routes. A value of 0 means that the sender SHOULD NOT raise any warning. The warning mechanisms are described in the operation section of this draft. sub code 2: It is used to identify the number of routes sent before the sender BGP speaker needs to stop advertising routes to its receiving BGP speaker. maximum prefix limit: Number of routes sent by the sender BGP speaker. s (Stop Advertisement): This field is always assigned a value of 1. This means that the route advertisement MUST be stopped by the BGP speaker. It is implicit here that the BGP speaker that encounters this situation will stop route advertisement to its receiving BGP speaker. sub code 3: It is used to identify the number of routes received after which the BGP speaker will reset the peering session. It MUST be noted here that this situation will never be encountered if adhered to the draft. In other words this happens only during error conditions. The error conditions are beyond the scope of this document. reset prefix limit: Number of routes sent by the sender BGP speaker. The value for this field is dependent on the maximum prefix limit and SHOULD be always greater than it. r (Reset Peering): This field is always assigned a value of 1. This means that the receiving BGP speaker will reset the peering session if the route advertising BGP speaker advertises routes exceeding value of number of sent routes to its peer. Srikanth Chavali et.al. Expires February 2004 [Page 8] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 sub code 4: The receiving BGP speaker uses this sub-code to indicate to its sender BGP speaker the current count of the routes received from it. current Rx routes: Number of routes received by the BGP speaker from its sender BGP speaker. The value of this field SHOULD always be less than or equal to the maximum prefix limit configured to receive from the sender BGP speaker. sub code 5: The receiving BGP speaker uses this sub-code to indicate to its peer the current count of the routes sent to it. current Tx routes: Number of routes sent by the sender BGP speaker to its receiving BGP speaker. The value of this field SHOULD always be less than or equal to the maximum prefix limit it received from the sender BGP speaker in the capability. Resv: The value of this field SHOULD be set to 0 when sending the capability and SHOULD be ignored when receiving it. We refer to the warning prefix limit, maximum prefix limit and the reset prefix limit as prefix limits in this document for the ease of illustration. 5. Operation 5.1 Exchanging the configured prefix limits BGP speakers exchange the prefix limits as an optional capability parameter [BGP-CAP] as described in section 4. +--------+ +--------+ | A | <-----------------> | B | +--------+ +--------+ Figure 1 In figure 1 both BGP speakers A and B exchange the prefix limits to indicate the support for this capability. Each of A and B set the Srikanth Chavali et.al. Expires February 2004 [Page 9] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 warning prefix limit, maximum prefix limit and reset prefix limit along with the actions associated with each of them in the capability message before exchanging them. The warning prefix limit and reset limit values are determined based on the configured maximum prefix limit. They are typically a percentage value of the maximum prefix limit. The exact percentage values are beyond the scope of this document. The maximum prefix limit configured on A for the peer B implies the maximum number of prefixes that A expects to receive from B. B informs this in the new capability described in section 4. The same interpretation applies to B too. 5.2 Route processing after prefix limits exchange In figure 1 both A and B maintain a count of the routes that they receive from each other. Route processing operation is illustrated using the case where B sends route advertisements to A. The same operational procedures apply for the other case of A sending route advertisements to B. B as shown in figure 1 applies the out bound route policies on the Adjacent-Rib-Out followed by the condition of the prefix limits before route advertisements. +--------+ +--------+ | A | <-----------------> | B | +--------+ +--------+ B detects warning prefix limit <------ generates dynamic capability message to A Figure 2 In figure 2 it can be seen in due course of route advertisements to A, B generates a dynamic capability [BGP-DYN-CAP] destined to A. B sends the count of received and sent routes to A in current Rx routes and current Tx routes of the capability message. The reason B sends this message in this case is that it detects the warning limit at the time of route advertisements earlier than A. In other words either A or B or both of them could generate this message depending on timing of warning limit detection. B and A MAY choose to raise internal warning when this condition is detected. Following the warnings both A and B continue advertising routes normally to each other. +--------+ +--------+ | A | <-----------------> | B | +--------+ +--------+ B detects maximum Srikanth Chavali et.al. Expires February 2004 [Page 10] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 prefix limit <------ generates dynamic capability message to A and stop route advertisement to A Figure 3 In figure 3, B during route advertisement detects that the maximum prefix limit for route advertisement is reached. It SHOULD stop further route advertisements to A. In other words in this condition it SHOULD implicitly mean to B that the announce policy to A is stop/deny. B then SHOULD send a Dynamic Capability [BGP-DYN-CAP] to A indicating the latest count of routes sent to A in currrent Tx routes and the received routes from A current Rx routes of the capability. As in the case of warning prefix limit condition either A or B or both could send dynamic capability [BGP-DYN-CAP]. Any route withdrawal to A is automatically recorded and SHOULD result in restoring the announce policy to the configured one (if any configured) implicitly. This helps in, preserving the incremental nature of the protocol and avoiding processing of routes by peers such as B, which get discarded by speakers such as A when the limit is reached. In addition to these network bandwidth consumption by the route UPDATES can be avoided. It is expected that conformance to this document will not lead to any further route advertisements to A by B unless there exists an unforseen error. Under such situation A can reset the peering session as indicated in the maximum prefix limit to B during the capability negotiation. 5.3 Prefix limit changes If a need for prefix limits change arises, each BGP speaker A whose configuration changes for its peer B, SHOULD dynamically [BGP-DYN- CAP] inform the corresponding peer of this change. Such changes SHOULD be handled as described in the following sub-sections. 5.3.1 Processing when maximum prefix limit is increased When the prefix limits are increased in the configuration of A in figure 1, it SHOULD inform B about it as described in 5.3. B SHOULD then restart the route advertisements and it MAY either choose to do so from the Adjacent-Rib-Out for A incrementally or make use of Route Refresh mechanism [BGP-RREFRESH], if it has stopped because of reaching the maximum prefix limit. The former methodology is similar to the approach taken prior to the introduction of Route Refresh. In other words it can be handled in the way policy changes were handled prior to the availability of Route Refresh mechanism, with a minor change of just sending the routes that were rejected due to the prefix limit. In doing so the restart of BGP peering and the Srikanth Chavali et.al. Expires February 2004 [Page 11] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 associated network traffic and service disruption with it, is avoided. If the maximum prefix limit is not reached and increased prefix limits are received by the peer B, then peer B SHOULD note this and continue with its advertisements to A until these limits are reached. 5.3.2 Processing when the maximum prefix limit is decreased When the prefix limits are decreased in the configuration of A (refer figure 1), then B SHOULD be informed about it as described in 5.3. B then SHOULD note this information and SHOULD stop route advertisement immediately if the number of route adtverisments exceeds this new maximum prefix limit for A. By doing so B can avoid processing the routes which will be discarded by A when it detects the maximum prefix limit condition. A does this even before adding the routes to its Adjacent-Rib-In for the peer or in some cases restarting of the peering session. Additionally, network bandwidth consumption by the routing UPDATES can be avoided this way. B at that point follows the process described in 4.2 for route processing. 6. Error Handling New error codes along with the sub-codes are defined (TBD). If a BGP peer does not support this capability and receives it, then the peer sends a NOTIFICATION with the appropriate error code and the sub-code. The BGP speaker then SHOULD re-initiate the peering session without the unsupported capability. 7. Security Considerations This document does not change the underlying security issues in the BGP protocol. It however, does provide an additional mechanism to protect against Denial of service attacks based on exceeding configured maximum prefix limits. 8. References [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", draft-ietf-idr-bgp4-20.txt. Work in progress. [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", RFC 3392, May 2000. [BGP-RREFRESH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. [BGP-DYN-CAP] Chen, E., Sangli, S. R., "Dynamic Capability for BGP- 4", draft-ietf-idr-dynamic-cap-03.txt. Work in progress. Srikanth Chavali et.al. Expires February 2004 [Page 12] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 [BGP-STUDY] Chang, D., Govindan, R., Heidemann, J., "An Empirical Study of Router Response to Large BGP Routing Table Load", ACM SIGCOMM Internet Measurement Workshop, pp. 203-208, Marseille, France, November 2002. 9. Acknowledgements The editor would like to thank George Matey, Marten Terpstra, Yakov Rekhter, Dan Joyal, Rajesh Saluja and Elwyn Davies for their review and comments. 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Author's Addresses: Srikanth Chavali Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 7789 Email: schavali@nortelnetworks.com Srikanth Chavali et.al. Expires February 2004 [Page 13] Internet Draft draft-chavali-bgp-prefixlimits-00.txt September 2003 Vasile Radoaca Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 6097 Email: vasile@nortelnetworks.com Paul Knight Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 6414 Email: paul.knight@nortelnetworks.com Luyuan Fang ATT Labs 200 Laurel Avenue, Room C2-3B35, Middletown, NJ 07748 Phone: +1 732 420 1921 Email: luyuanfang@att.com Susan Hares NextHop Technologies 825 Victors Way Suite 100 Ann Arbor, MI 48108 Phone: +1 734 222 1610 Email: skh@nexthop.com Srikanth Chavali et.al. Expires February 2004 [Page 14]