diff options
Diffstat (limited to 'doc/rfc/rfc6719.txt')
| -rw-r--r-- | doc/rfc/rfc6719.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc6719.txt b/doc/rfc/rfc6719.txt new file mode 100644 index 0000000..9f5b3a0 --- /dev/null +++ b/doc/rfc/rfc6719.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) O. Gnawali +Request for Comments: 6719 University of Houston +Category: Standards Track P. Levis +ISSN: 2070-1721 Stanford University + September 2012 + + + The Minimum Rank with Hysteresis Objective Function + +Abstract + + The Routing Protocol for Low-Power and Lossy Networks (RPL) + constructs routes by using Objective Functions that optimize or + constrain the routes it selects and uses. This specification + describes the Minimum Rank with Hysteresis Objective Function + (MRHOF), an Objective Function that selects routes that minimize a + metric, while using hysteresis to reduce churn in response to small + metric changes. MRHOF works with additive metrics along a route, and + the metrics it uses are determined by the metrics that the RPL + Destination Information Object (DIO) messages advertise. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6719. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + + + +Gnawali & Levis Standards Track [Page 1] + +RFC 6719 MRHOF September 2012 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The Minimum Rank with Hysteresis Objective Function . . . . . 4 + 3.1. Computing the Path Cost . . . . . . . . . . . . . . . . . 4 + 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5 + 3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6 + 3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6 + 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8 + 3.5. Working without Metric Containers . . . . . . . . . . . . 8 + 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9 + 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 + 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10 + 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + +1. Introduction + + An Objective Function specifies how RPL [RFC6550] selects paths. For + example, if an RPL instance uses an Objective Function that minimizes + hop count, RPL will select paths with a minimum hop count. RPL + requires that all nodes in a network use a common Objective Function; + relaxing this requirement may be a subject of future study. + + The nodes running RPL might use a number of metrics to describe a + link or a node [RFC6551] and make these metrics available for route + selection. RPL advertises metrics in RPL Destination Information + Object (DIO) messages with a Metric Container suboption. An + Objective Function can use these metrics to choose routes. + + To decouple the details of an individual metric or Objective Function + from forwarding and routing, RPL describes routes through a value + called Rank. Rank, roughly speaking, corresponds to the distance + associated with a route. RPL defines how nodes decide on paths based + + + + + +Gnawali & Levis Standards Track [Page 2] + +RFC 6719 MRHOF September 2012 + + + on Rank and advertise their Rank. An Objective Function defines how + nodes calculate Rank, based on the Rank of its potential parents, + metrics, and other network properties. + + This specification describes the Minimum Rank with Hysteresis + Objective Function (MRHOF), an Objective Function for RPL, which uses + hysteresis while selecting the path with the smallest metric value. + The metric that MRHOF uses is determined by the metrics in the DIO + Metric Container. For example, the use of MRHOF with the latency + metric allows RPL to find stable minimum-latency paths from the nodes + to a root in the Directed Acyclic Graph (DAG) instance [RFC6550]. + The use of MRHOF with the Expected Transmission Count (ETX) metric + [RFC6551] allows RPL to find the stable minimum-ETX paths from the + nodes to a root in the DAG instance. In the absence of a metric in + the DIO Metric Container or of a DIO Metric Container, MRHOF defaults + to using ETX to compute Rank, as described in Section 3.5. + + Because MRHOF seeks to minimize path costs as described by metrics, + it can only be used with additive metrics. MRHOF does not support + metrics that are not additive. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + + The terminologies used in this document are consistent with the + terminologies described in [ROLL-TERM] and [RFC6551]. + + The terminologies used in this document are also consistent with the + terminologies described in [RFC6550], except the term Rank. In this + document, Rank refers to the value of the Rank field, not DAGRank as + in [RFC6550]. + + This document introduces three terms: + + Selected metric: The metric chosen for path selection by the network + operator. MRHOF supports using a single metric for path + selection. The decision to use a metric (other than ETX) as the + selected metric is indicated by the presence of the chosen metric + in the DIO Metric Container. The selection of the ETX metric is + indicated by the absence of the Metric Container, in which case + ETX is advertised as Rank. + + + + + + +Gnawali & Levis Standards Track [Page 3] + +RFC 6719 MRHOF September 2012 + + + Path cost: Path cost quantifies a property of an end-to-end path. + Path cost is obtained by each node summing up the selected link + metric to the path cost advertised by the parent. Path cost can + be used by RPL to compare different paths. + + Worst parent: The node in the parent set with the largest path cost. + +3. The Minimum Rank with Hysteresis Objective Function + + The Minimum Rank with Hysteresis Objective Function, MRHOF, is + designed to find the paths with the smallest path cost while + preventing excessive churn in the network. It does so by using two + mechanisms. First, it finds the minimum cost path, i.e., path with + the minimum Rank. Second, it switches to that minimum Rank path only + if it is shorter (in terms of path cost) than the current path by at + least a given threshold. This second mechanism is called + "hysteresis". + + MRHOF may be used with any additive metric listed in [RFC6551] as + long as the routing objective is to minimize the given routing + metric. Nodes MUST support at least one of these metrics: hop count, + latency, or ETX. Nodes SHOULD support the ETX metric. MRHOF does + not support non-additive metrics. + +3.1. Computing the Path Cost + + Root nodes (Grounded or Floating) set the variable cur_min_path_cost + to the metric value that computes to a Rank of MinHopRankIncrease. + + If a non-root node does not have metrics to compute the path cost + through any of the candidate neighbors, it MUST join one of the + candidate neighbors as a RPL Leaf. + + Otherwise, nodes compute the path cost for each candidate neighbor + reachable on an interface. The path cost of a neighbor represents + the cost of the path, in terms of the selected metric, from a node to + the root of the Destination-Oriented DAG (DODAG) through that + neighbor. A non-root node computes a neighbor's path cost by adding + two components: + + 1. If the selected metric is a link metric, the selected metric for + the link to the candidate neighbor. If the selected metric is a + node metric, the selected metric for the node. + + + + + + + + +Gnawali & Levis Standards Track [Page 4] + +RFC 6719 MRHOF September 2012 + + + 2. The value of the selected metric in the Metric Container in the + DIO sent by that neighbor. In case the Metric Container is + empty, ETX is the selected metric -- use the Rank advertised by + that neighbor as the second component. See Section 3.5 for + details on how an ETX metric is used in MRHOF. + + A node SHOULD compute the path cost for the path through each + candidate neighbor reachable through an interface. If a node cannot + compute the path cost for the path through a candidate neighbor, the + node MUST NOT select the candidate neighbor as its preferred parent. + However, if the node cannot compute the path cost through any + neighbor, it may join the candidate neighbor as a Leaf, as described + above. + + If the selected metric is a link metric and the metric of the link to + a neighbor is not available, the path cost for the path through that + neighbor SHOULD be set to MAX_PATH_COST. This cost value will + prevent this path from being considered for path selection. + + If the selected metric is a node metric, and the metric is not + available, the path cost through all the neighbors SHOULD be set to + MAX_PATH_COST. + + The path cost corresponding to a neighbor SHOULD be recomputed each + time any of the following conditions are met: + + 1. The selected metric of the link to the candidate neighbor is + updated. + + 2. The selected metric is a node metric and the metric is updated. + + 3. A node receives a new metric advertisement from the candidate + neighbor. + + This computation SHOULD also be performed periodically. While it is + harmless to delay this computation up to a minimum Trickle interval + [RFC6550], longer delays in updating the path cost after the metric + is updated or a new metric advertisement is received can lead to + stale information. + +3.2. Parent Selection + + After computing the path cost for all the candidate neighbors + reachable through an interface for the current DODAG iteration + [RFC6550], a node selects the preferred parent. This process is + called "parent selection". To allow hysteresis, parent selection + maintains a variable, cur_min_path_cost, which is the path cost of + the current preferred parent. + + + +Gnawali & Levis Standards Track [Page 5] + +RFC 6719 MRHOF September 2012 + + +3.2.1. When Parent Selection Runs + + A MRHOF implementation SHOULD perform Parent Selection each time: + + 1. The path cost for an existing candidate neighbor, including the + preferred parent, changes. This condition can be checked + immediately after the path cost is computed. + + 2. A new candidate neighbor is inserted into the neighbor table. + + If, despite the above, it is necessary to defer the parent selection + until a later time (e.g., up to the Trickle minimum interval + [RFC6550]), note that doing so can delay the use of better paths + available in the network. + +3.2.2. Parent Selection Algorithm + + If the selected metric for a link is greater than MAX_LINK_METRIC, + the node SHOULD exclude that link from consideration during parent + selection. + + A node MUST select the candidate neighbor with the lowest path cost + as its preferred parent, except as indicated below: + + 1. A node MAY declare itself as a Floating root, and hence have no + preferred parent, depending on system configuration. + + 2. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY + declare itself as a Floating root. + + 3. If the smallest path cost for paths through the candidate + neighbors is smaller than cur_min_path_cost by less than + PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current + preferred parent. This is the hysteresis component of MRHOF. + + 4. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the + node does not have a preferred parent and MUST set + cur_min_path_cost to MAX_PATH_COST. + + If there are multiple neighbors that share the smallest path cost, a + node MAY use a different selection criteria to select which of these + neighbors should be considered to have the lowest cost. + + A node MAY include up to PARENT_SET_SIZE-1 additional candidate + neighbors in its parent set. The cost of the path through the nodes + in the parent set is smaller than or equal to the cost of the paths + through any of the nodes that are not in the parent set. If the cost + + + + +Gnawali & Levis Standards Track [Page 6] + +RFC 6719 MRHOF September 2012 + + + of the path through the preferred parent and the worst parent is too + large, a node MAY keep a smaller parent set than PARENT_SET_SIZE. + + Once the preferred parent is selected, the node sets its + cur_min_path_cost variable to the path cost corresponding to the + preferred parent. The value of the cur_min_path_cost is carried in + the Metric Container corresponding to the selected metric when DIO + messages are sent. + +3.3. Computing Rank + + DAG roots set their Rank to MinHopRankIncrease. + + Once a non-root node selects its parent set, it can use the following + table to covert the path cost of a parent (written as Cost in the + table) to a Rank value: + + +------------------+------------+ + | Node/link Metric | Rank | + +------------------+------------+ + | Hop-Count | Cost | + | Latency | Cost/65536 | + | ETX | Cost | + +------------------+------------+ + + Table 1: Conversion of Metric to Rank + + If MRHOF is used with other metrics, the Rank is undefined. If the + Rank is undefined, the node must join one of the neighbors as a RPL + Leaf node according to [RFC6550]. + + MRHOF uses this Rank value to compute the Rank it associates with the + path through each member of the parent set. The Rank associated with + a path through a member of the parent set is the maximum of two + values. The first is the corresponding Rank value calculated with + the table above, the second is that nodes' advertised Rank plus + MinHopRankIncrease. + + A node sets its Rank to the maximum of three values: + + 1. The Rank calculated for the path through the preferred parent. + + 2. The Rank of the member of the parent set with the highest + advertised Rank, rounded to the next higher integral Rank, i.e., + to MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)). + + 3. The largest calculated Rank among paths through the parent set, + minus MaxRankIncrease. + + + +Gnawali & Levis Standards Track [Page 7] + +RFC 6719 MRHOF September 2012 + + + The first case is the Rank associated with the path through the + preferred parent. The second case covers requirement 5 of Rank + advertisements in Section 8.2.1 of [RFC6550]. The third case ensures + that a node does not advertise a Rank, which then precludes it from + using members of its parent set. + + Note that the third case means that a node advertises a conservative + Rank value based on members of its parent set. This conservative + value might be significantly higher than the Rank calculated for the + path through the preferred parent. Accordingly, picking a parent set + whose paths have a large range of Ranks will likely result in + subptimal routing: nodes might not choose good paths because they are + advertised as much worse than they actually are. The exact selection + of a parent set is an implementation decision. + +3.4. Advertising the Path Cost + + Once the preferred parent is selected, the node sets its + cur_min_path_cost variable to the path cost corresponding to its + preferred parent. It then calculates the metric it will advertise in + its metric container. This value is the path cost of the member of + the parent set with the highest path cost. Thus, while + cur_min_path_cost is the cost through the preferred parent, a node + advertises the highest cost path from the node to the root through a + member of the parent set. The value of the highest cost path is + carried in the metric container corresponding to the selected metric + when DIO messages are sent. + + If ETX is the selected metric, a node MUST NOT advertise it in a + metric container. Instead, a node MUST advertise an approximation of + its ETX in its advertised Rank value, following the rules described + in Section 3.3. If a node receives a DIO with a Metric Container + holding an ETX metric, MRHOF MUST ignore the ETX metric value in its + Rank calculations. + + DODAG Roots advertise a metric value that computes to a Rank value of + MinHopRankIncrease. + +3.5. Working without Metric Containers + + In the absence of a Metric Container, MRHOF uses ETX as its metric. + It locally computes the ETX of links to its neighbors and adds this + value to their advertised Rank to compute the associated Rank of + routes. Once parent selection and rank computation is performed + using the ETX metric, the node advertises the Rank and MUST NOT + include a metric container in its DIO messages. While assigning Rank + in this case, use the representation of ETX described in [RFC6551], + i.e., assign Rank equal to ETX * 128. + + + +Gnawali & Levis Standards Track [Page 8] + +RFC 6719 MRHOF September 2012 + + +4. Using MRHOF for Metric Maximization + + MRHOF cannot be directly used for parent selection using metrics that + require finding paths with a maximum value of the selected metric, + such as path reliability. It is possible to convert such a metric + maximization problem to a metric minimization problem for some + metrics and use MRHOF provided: + + There is a fixed and well-known maximum metric value corresponding + to the best path. This is the path cost for the DAG root. For + example, the logarithm of the best link reliability has a value of + 0. + + The metrics in the maximization problem are all negative. The + logarithm of the link reliability is always negative. + + For metrics meeting the above conditions, the problem of maximizing + the metric value is equivalent to minimizing the modified metric + value, e.g., logarithm of link reliability. MRHOF is not required to + work with these metrics. + +5. MRHOF Variables and Parameters + + MRHOF uses the following variable: + + cur_min_path_cost: The cost of the path from a node through its + preferred parent to the root computed at the last parent + selection. + + MRHOF uses the following parameters: + + MAX_LINK_METRIC: Maximum allowed value for the selected link + metric for each link on the path. + + MAX_PATH_COST: Maximum allowed value for the path metric of a + selected path. + + PARENT_SWITCH_THRESHOLD: The difference between the cost of the + path through the preferred parent and the minimum cost path in + order to trigger the selection of a new preferred parent. + + PARENT_SET_SIZE: The number of candidate parents, including the + preferred parent, in the parent set. + + ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a + floating root. + + + + + +Gnawali & Levis Standards Track [Page 9] + +RFC 6719 MRHOF September 2012 + + + The parameter values are assigned depending on the selected metric. + The best values for these parameters are determined by the + requirement of the specific RPL deployment. For instance, if we use + ETX as the selected metric and UDP as the transport protocol, we + should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link- + layer retransmissions are sufficient to provide a good chance of end- + to-end reliability. + + The working group has extensive experience routing with the ETX + metric [Hui08b]. Based on those experiences, the following values + are RECOMMENDED when ETX is the selected metric: + + MAX_LINK_METRIC: 512. Disallow links with greater than 4 expected + transmission counts on the selected path. + + MAX_PATH_COST: 32768. Disallow paths with greater than 256 + expected transmission counts. + + PARENT_SWITCH_THRESHOLD: 192. Switch to a new path only if it is + expected to require at least 1.5 fewer transmissions than the + current path. + + PARENT_SET_SIZE: 3. If the preferred parent is not available, two + candidate parents are still available without triggering a new + round of route discovery. + + ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating + root. + +6. Manageability + + Section 18 of [RFC6550] depicts the management of RPL. This + specification inherits from that section and its subsections, with + the exception that metrics as specified in [RFC6551] are not used and + do not require management. + +6.1. Device Configuration + + An implementation SHOULD allow the following parameters to be + configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, + PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. + An implementation MAY allow these parameters to be configured + dynamically at run time once a network has been deployed. + + A MRHOF implementation MUST support the DODAG Configuration option as + described in [RFC6550] and apply the parameters it specifies. Care + should be taken in the relationship between the MRHOF + PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease + + + +Gnawali & Levis Standards Track [Page 10] + +RFC 6719 MRHOF September 2012 + + + parameter. For example, if MaxRankIncrease is smaller than + PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a + situation in which its current preferred parent causes the node's + Rank to increase more than MaxRankIncrease but MRHOF does not change + preferred parents. This could cause the node to leave the routing + topology even though there may be other members of the parent set + that would allow the node's Rank to remain within MaxRankIncrease. + + Unless configured otherwise, a MRHOF implementation SHOULD use the + default parameters as specified in Section 5. + + Because of the partially coupled relationship between Rank and metric + values, networks using MRHOF require care in setting + MinHopRankIncrease. A large MinHopRankIncrease will cause MRHOF to + be unable to select paths with different hop counts but similar + metric values. If MinHopRankIncrease is large enough that its + increment is greater than that caused by link cost, then metrics will + be used to select a preferred parent, but the advertised Rank will be + a simple hop count. This behavior might be desirable, but it also + might be unintended; care is recommended. + + With ETX as the selected metric, RPL's Rank advertisement rules can + require a DODAG Root to advertise a Rank higher than its + corresponding ETX value, as a DODAG Root advertises a Rank of + MinHopRankIncrease. Because all DODAG Roots within a DODAG Version + advertise the same Rank, this constant value typically does not + affect route selection. Nevertheless, it means that if a DODAG + Version has a MinHopRankIncrease of M and a path has an advertised + ETX of E, then the actual ETX of the path is likely closer to a value + of E-M than a value of E. + +6.2. Device Monitoring + + A MRHOF implementation should provide an interface for monitoring its + operation. At a minimum, the information provided should include: + + DAG information as specified in Section 6.3.1 of [RFC6550], + including the DODAGID, the RPLInstanceID, the Mode of Operation, + the Rank of this node, the current Version Number, and the value + of the Grounded flag. + + A list of neighbors indicating the preferred parent. The list + should indicate, for each neighbor, the Rank, the current Version + Number, the value of the Grounded flag, and associated metrics. + + + + + + + +Gnawali & Levis Standards Track [Page 11] + +RFC 6719 MRHOF September 2012 + + +7. Acknowledgements + + Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, + and Phoebus Chen for their comments. Thanks to Barry Leiba, Brian + Haberman, Martin Stiemerling, Ralph Droms, Robert Sparks, Russ + Housley, Stephen Farrell, Wesley Eddy, Miguel A. Garcia, Mukul Goyal, + and Michael Richardson for their feedback during the publication + phase of this document. + +8. IANA Considerations + + Per this document, IANA has allocated value 1 from the "Objective + Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power + and Lossy Networks (RPL)" registry. + +9. Security Considerations + + This specification makes simple extensions to RPL and so is + vulnerable to and benefits from the security issues and mechanisms + described in [RFC6550] and [ROLL-SEC]. This document does not + introduce new flows or new messages, and thus requires no specific + mitigation for new threats. + + MRHOF depends on information exchanged in a number of RPL protocol + elements. If those elements were compromised, then an implementation + of MRHOF might generate the wrong path for a packet, resulting in it + being misrouted. Therefore, deployments are RECOMMENDED to use RPL + security mechanisms if there is a risk that routing information might + be modified or spoofed. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., + Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. + Alexander, "RPL: IPv6 Routing Protocol for Low-Power and + Lossy Networks", RFC 6550, March 2012. + + [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. + Barthel, "Routing Metrics Used for Path Calculation in + Low-Power and Lossy Networks", RFC 6551, March 2012. + + + + + + +Gnawali & Levis Standards Track [Page 12] + +RFC 6719 MRHOF September 2012 + + +10.2. Informative References + + [Hui08b] Hui, J. and D. Culler, "IP is dead, long live IP for + wireless sensor networks", Proceedings of the 6th ACM + Conference on Embedded Networked Systems SenSys 2008, + November 2008, + <http://portal.acm.org/citation.cfm?id=1460412.1460415>. + + [ROLL-SEC] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. + Lozano, "A Security Framework for Routing over Low Power + and Lossy Networks", Work in Progress, January 2012. + + [ROLL-TERM] Vasseur, J., "Terminology in Low power And Lossy + Networks", Work in Progress, September 2011. + +Authors' Addresses + + Omprakash Gnawali + University of Houston + PGH 577, University of Houston + Houston, TX 77204 + USA + + Phone: +1 713 743 3356 + EMail: gnawali@cs.uh.edu + + + Philip Levis + Stanford University + 412 Gates Hall, Stanford University + Stanford, CA 94305 + USA + + EMail: pal@cs.stanford.edu + + + + + + + + + + + + + + + + + +Gnawali & Levis Standards Track [Page 13] + |