idnits 2.17.1 draft-lijo-6lo-expiration-time-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 3, 2017) is 2489 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) == Unused Reference: 'I-D.vilajosana-6tisch-minimal' is defined on line 507, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-09 ** Downref: Normative reference to an Informational draft: draft-ietf-6tisch-terminology (ref. 'I-D.ietf-6tisch-terminology') == Outdated reference: A later version (-07) exists of draft-brockners-inband-oam-data-05 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-03 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-15 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Lijo Thomas 3 Internet-Draft C-DAC 4 Intended status: Standards Track P. Akshay 5 Expires: January 4, 2018 Indian Institute of Science 6 Satish Anamalamudi 7 Huaiyin Institute of Technology 8 S.V.R.Anand 9 Malati Hegde 10 Indian Institute of Science 11 C. Perkins 12 Futurewei 13 July 3, 2017 15 Packet Delivery Deadline time in 6LoWPAN Routing Header 16 draft-lijo-6lo-expiration-time-04 18 Abstract 20 This document specifies a new type for the 6LoWPAN routing header 21 containing the delivery deadline time for data packets. The deadline 22 time enables forwarding and scheduling decisions for time critical 23 IoT M2M applications that need deterministic delay guarantees over 24 constrained networks and operate within time-synchronized networks. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 4, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 63 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 3 64 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 4 65 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 6 66 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non- 67 storing mode. . . . . . . . . . . . . . . . . . . . . . . 6 68 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 69 Technologies. . . . . . . . . . . . . . . . . . . . . . . 7 70 6.3. Scenario 3: Packet transmission across different DODAGs 71 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Low Power and Lossy Networks (LLNs) are likely to be deployed for 83 real time industrial applications requiring end-to-end delay 84 guarantees [I-D.grossman-detnet-use-cases]. A Deterministic Network 85 ("detnet") typically requires some data packets to reach their 86 receivers within strict time bounds. Intermediate nodes use the 87 deadline information to make appropriate packet forwarding and 88 scheduling decisions to meet the time bounds. 90 The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN 91 Routing Header (6LoRH), compression schemes for RPL routing (source 92 routing) operation [RFC6554], header compression of RPL Packet 93 Information [RFC6553], and IP-in-IP encapsulation. This document 94 specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, 95 so that the deadline time of data packets can be included within the 96 6LoWPAN routing header. This document also specifies handling of the 97 deadline time when packets traverse through time-synchronized 98 networks operating in different timezones or distinct reference 99 clocks. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 This document uses terminology consistent with the terminology used 109 in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this 110 document, the terms "expiration time", "delivery deadline time", and 111 "deadline" are used interchangeably with the same meaning. 113 3. 6LoRHE Generic Format 115 Note: this section is not normative. It is included for convenience, 116 and may be deleted in a later revision of this document. The generic 117 header format of the 6LoRHE is specified in 118 [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE 119 generic format. 121 0 1 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 124 |1|0|1| Length | Type | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 126 <-- length --> 128 Figure 1: 6LoRHE format 130 o Length: Length of the 6LoRHE expressed in bytes, excluding the 131 first 2 bytes. This enables a node to skip a 6LoRHE if the Type 132 is not recognized/supported. 134 o Type: Type of the 6LoRHE. 136 o length: variable 138 4. Deadline-6LoRHE 140 The Deadline-6LoRHE (see Figure 2) is an elective 6LoRH (i.e., a 141 6loRHE) that provides the deadline time (DT) for an IPv6 datagram in 142 a compressed form. Along with the deadline, the header can include 143 the packet Origination Time (OT), to enable a close estimate of the 144 total delay incurred by a packet. The OT field is initialized by the 145 sender using the current time at the outgoing network interface 146 through which the packet is forwarded. 148 The deadline field contains the value of the delivery deadline time 149 for the packet. The packet SHOULD be delivered to the Receiver 150 before this time. 152 packet_deadline_time = packet_origination_time + max_delay 154 All nodes within the network SHOULD process the Deadline-6LoRHE in 155 order to support delay-sensitive deterministic applications. The 156 packet deadline time (DT) and origination time (OT) are represented 157 in time units determined by a scaling parameter in the routing 158 header. One of the time units is the Network ASN (Absolute Slot 159 Number) which can be used in case of a time slotted synchronized 160 network, for instance a 6TiSCH network, where global time is 161 maintained in the units of slot lengths of a certain resolution. 163 The delay experienced by packets in the network is a useful metric 164 for network diagnostics and performance monitoring. Whenever the 165 packets crosses into a network using a different reference clock, the 166 Origination Time field is updated to represent the same Origination 167 Time as expressed using the reference clock of the outgoing interface 168 into the new network. This is the same as the current time when the 169 packet is transmitted into the new network, minus the delay already 170 experienced by the packet, say 't'. In effect, to the newly entered 171 network, the packet will appear to have originated 't' time units 172 earlier with respect to the reference clock of the new network. 174 Origination Time in new network = current_time_in_new_network - 175 delay_already_experienced_in_previous_network(s) 177 5. Deadline-6LoRHE Format 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |1|0|1| Length | 6LoRH Type |O|D| DTL | OTL | TU| EXP | Rsv | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | DT (variable length) | OT(variable length)(optional) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 2: Deadline-6LoRHE format 189 Length (5 bits): Length represents the total length of the Deadline- 190 6LoRHE type measured in octets. 192 6LoRH Type: TBD 194 O flag (1bit): Indicates the presence of Origination Time field. '1' 195 means the OT field is present, and '0' means it is absent. 197 D flag (1 bit): The 'D' flag, set by the Sender, indicates the action 198 to be taken when a 6LR detects that the deadline time has elapsed. 199 If 'D' bit is 1, then the 6LR SHOULD drop the packet if the deadline 200 time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore the 201 deadline time and forward the packet. 203 DTL (3 bits): Length of DT field. 205 OTL (3 bits) : Length of OT field. 207 For example, DTL = 000 means the deadline time in the 6LoRHE is 1 208 octet (8 bits) long. Similarly, OTL = 111 means the origination 209 time is 8 octets (64 bits) long. 211 TU (2 bits) : Indicates the time units for DT and OT fields 213 00 : Time represented in microseconds 214 01 : Time represented in seconds 215 10 : Network ASN 216 11 : Reserved 218 EXP (3 bits) : Multiplication factor expressed as exponent of 10. 220 The value of the DT field is multiplied by 10 to this power, to 221 get the actual deadline time in the units represented by TU. The 222 default value of EXP is 000, so that the DT field is unaffected. 224 Rsv (3 bits) : Reserved 226 DT Value (8..64-bit) : Deadline Time value 228 OT Value (8..64-bit) : Origination Time value 230 Whenever a sender initiates the IP datagram, it includes the 231 Deadline-6LoRHE along with other 6LoRH information. 233 Example: Consider a 6TiSCH network with time-slot length of 10ms. 234 Let the current ASN when the packet is originated be 54400, and the 235 maximum allowable delay (max_delay) for the packet delivery is 1 236 second from the packet origination, then: 238 deadline_time = packet_origination_time + max_delay 239 = 55400 + 100 (in Network ASNs) 240 = 55500(Network ASNs) 242 Deadline-6LoRHE encoding with 'O' flag set to 1 : 244 DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A 246 6. Deadline-6LoRHE in Three Network Scenarios 248 In this section, Deadline-6LoRHE operation is described for 3 network 249 scenarios. Figure 3 depicts a constrained time-synchronized LLN that 250 has two subnets N1 and N2, connected through LBRs 251 [I-D.ietf-6lo-backbone-router] with different reference clock times 252 T1 and T2. 254 +-------------------+ 255 | Time Synchronized | 256 | Network | 257 +---------+---------+ 258 | 259 | 260 | 261 +--------------+--------------+ 262 | | 263 +-----+ +-----+ 264 | | Backbone | | Backbone 265 o | | router | | router 266 +-----+ +-----+ 267 o o o 268 o o o o o o o o o 269 o LLN o o LLN o o 270 o o o o o o o o o 271 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 273 Figure 3: Intra-network Timezone Scenario 275 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode. 277 In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram 278 to be routed to a Receiver 'R' within the same DODAG. For the route 279 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by 280 encoding the deadline time contained in the inband-OAM header 281 extension. Then 6LR begins hop-by-hop operation to forward the 282 packet towards the 6LBR. Once 6LBR receives the IP datagram, it 283 generates a IPv6-in-IPv6 encapsulated packet when sending the packet 284 downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR 285 copies the Deadline-6LoRHE from the Sender originated IP header to 286 the outer IP header. The Deadline-6LoRHE contained in the inner IP 287 header is elided. 289 +-------+ 290 ^ | 6LBR | | 291 | | | | 292 | +-------+ | 293 Default | (F)/ /| \ | IP-in-IP 294 routing | / \ / | \ | Encapsulation 295 | / \ (C) | (D) | 296 | (A) (B) / | / |\ | 297 | /|\ |\: (E) : R | 298 S : : : / \ V 300 Figure 4: End points within same DODAG(subnet N1) 302 At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Deadline- 303 6LoRHE is copied back from the outer header to inner header, and the 304 inner IP packet is delivered to 'R'. 306 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 308 In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG 309 1) has IP datagram to be routed to a Receiver 'R' over a time- 310 synchronized IPv6 network. For the route segment from 'S' to 6LBR, 311 'S' includes a Deadline-6LoRHE. Subsequently, 6LR will perform hop- 312 by-hop operation to forward the packet towards the 6LBR. Once the IP 313 datagram reaches 6LBR of DODAG1, it encodes the deadline time (and, 314 if available, the origination time) into the In-band OAM header 315 extension, [I-D.brockners-inband-oam-data] and passes the datagram to 316 the IPv6 layer for further routing. 318 +----------------+ 319 | Time | 320 | synchronized |------R 321 | Network | 322 +----------------+ 323 | 324 | 325 ----------+----------- 326 ^ | 327 | +---+---+ 328 | | 6LBR | 329 Default | | | 330 routing | +------++ 331 | (F)/ /| \ 332 | / \ / | \ 333 | / \ (C) | (D) 334 : (A) (B) / | / |\ 335 /|\ |\: (E) : 336 S : : : / \ 337 : : 339 Figure 5: Packet transmission in Dissimilar L2 Technologies or 340 Internet 342 The IP datagram is routed to another time synchronized deterministic 343 network following its own distinct reference clock, so the deadline 344 time in In-band OAM has to be updated according to the measurement of 345 the current time in the new network. 347 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to 348 N2). 350 Consider the scenario depicted in Figure 6, in which the Sender 'S' 351 (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' 352 belonging to another DODAG (DODAG 2). The operation of this scenario 353 can be decomposed into combination of case 1 and case 2 scenarios. 354 For the route segment from 'S' to 6LBR, 'S' includes the Deadline- 355 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to 356 forward the packet towards the 6LBR. Once the IP datagram reaches 357 6LBR1 of DODAG1, it applies the same rule as described in Case 2 358 while routing the packet to LBR2 over a (likely) time synchronized 359 wired backhaul. The wired side of LBR2 can be mapped to receiver of 360 Case 2. Once the packet reaches LBR2, it updates the Deadline-6LoRHE 361 by adding the current time of DODAG2. Further, it generates an IPv6- 362 in-IPv6 encapsulated packet when sending the packet downstream to the 363 Receiver [I-D.ietf-roll-useofrplinfo]. 365 Time Synchronized Network 366 -+---------------------------+- 367 | | 368 DODAG1 +---+---+ +---+---+ DODAG2 369 Instance 1 | 6LBR1 | | 6LBR2 | Instance 2 370 | | | | | 371 +-------+ +-------+ | 372 (F)/ /| \ (F)/ /| \ | 373 / \ / | \ / \ / | \ | 374 / \ (C) | (D) / \ (C) | (D) |IP-in-IP 375 (A) (B) / | / |\ (A) (B) / | / |\ | Encapsulation 376 /|\ |\: (E) : : /|\ |\: (E) : :| 377 S : : : / \ : : : : / \ | 378 : : : R V 379 Network N1, time zone T1 NetWork N2, time zone T2 381 Figure 6: Packet transmission in different DODAGs(N1 to N2) 383 Consider an example of a 6TiSCH network in which S in DODAG1 384 generates the packet at ASN 20000 to R in DODAG2. Let the maximum 385 allowable delay be 1 second. The time-slot length in DODAG1 and 386 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in 387 Deadline-6LoRHE, the packet is forwarded to LBR of DODAG1. Suppose 388 the packet reaches LBR of DODAG1 at ASN 20050. 390 current_time = ASN at LBR * slot_length_value 392 remaining_time = deadline_time - current_time 393 = ((packet_origination_time + max_delay) - current time) 394 = (20000 + 100) - 20050 395 = 50 (in Network ASNs) 396 = 50 * 10^3 milliseconds. 398 The remaining time is encoded in In-Band OAM (see Case 2) and 399 forwarded to LBR2 over a different L2-interface, typically wired. 400 Once the packet reaches LBR2, the deadline time in Deadline-6LoRHE is 401 adjusted by adding or subtracting the difference between the 402 reference clocks of the two networks, before forwarding the packet to 403 its connected 6TiSCH network. 405 7. IANA Considerations 407 This document defines a new 6LoWPAN Timestamp Header Type, and 408 assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space. 410 6LoRH Type Value 411 +------------------+--------+ 412 | Deadline-6LoRHE | TBD | 413 +------------------+--------+ 415 Figure 7: Deadline-6LoRHE type 417 8. Security Considerations 419 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 420 apply. Using a compressed format as opposed to the full in-line 421 format is logically equivalent and does not create an opening for a 422 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 424 9. Acknowledgements 426 The authors thank Pascal Thubert for suggesting the idea and 427 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 428 were instrumental in extending the timing information to 429 heterogeneous networks. The authors acknowledge the 6TiSCH WG 430 members for their inputs on the mailing list. Special thanks to 431 Jerry Daniel,Shalu Rajendran, Seema Kumar, Avinash Mohan and Anita 432 Varghese for their support and valuable feedback. 434 10. References 436 10.1. Normative References 438 [I-D.ietf-6tisch-terminology] 439 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 440 "Terminology in IPv6 over the TSCH mode of IEEE 441 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 442 progress), June 2017. 444 [I-D.ietf-roll-routing-dispatch] 445 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 446 "6LoWPAN Routing Header", draft-ietf-roll-routing- 447 dispatch-05 (work in progress), October 2016. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 455 "Transmission of IPv6 Packets over IEEE 802.15.4 456 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 457 . 459 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 460 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 461 DOI 10.17487/RFC6282, September 2011, 462 . 464 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 465 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 466 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 467 Low-Power and Lossy Networks", RFC 6550, 468 DOI 10.17487/RFC6550, March 2012, 469 . 471 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 472 Power and Lossy Networks (RPL) Option for Carrying RPL 473 Information in Data-Plane Datagrams", RFC 6553, 474 DOI 10.17487/RFC6553, March 2012, 475 . 477 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 478 Routing Header for Source Routes with the Routing Protocol 479 for Low-Power and Lossy Networks (RPL)", RFC 6554, 480 DOI 10.17487/RFC6554, March 2012, 481 . 483 10.2. Informative References 485 [I-D.brockners-inband-oam-data] 486 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 487 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 488 P., <>, R., and d. daniel.bernier@bell.ca, "Data Fields 489 for In-situ OAM", draft-brockners-inband-oam-data-05 (work 490 in progress), May 2017. 492 [I-D.grossman-detnet-use-cases] 493 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 494 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y. 495 Zha, "Deterministic Networking Use Cases", draft-grossman- 496 detnet-use-cases-01 (work in progress), November 2015. 498 [I-D.ietf-6lo-backbone-router] 499 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 500 backbone-router-03 (work in progress), January 2017. 502 [I-D.ietf-roll-useofrplinfo] 503 Robles, I., Richardson, M., and P. Thubert, "When to use 504 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 505 useofrplinfo-15 (work in progress), June 2017. 507 [I-D.vilajosana-6tisch-minimal] 508 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 509 Configuration", draft-vilajosana-6tisch-minimal-00 (work 510 in progress), October 2013. 512 Authors' Addresses 514 Lijo Thomas 515 C-DAC 516 Trivandrum 695033 517 India 519 Email: lijo@cdac.in 521 P.M. Akshay 522 Indian Institute of Science 523 Bangalore 560012 524 India 526 Email: akshaypm@ece.iisc.ernet.in 528 Satish Anamalamudi 529 Huaiyin Institute of Technology 530 No.89 North Beijing Road, Qinghe District 531 Huaian 532 China 534 Email: satishnaidu80@gmail.com 536 S.V.R Anand 537 Indian Institute of Science 538 Bangalore 560012 539 India 541 Email: anand@ece.iisc.ernet.in 543 Malati Hegde 544 Indian Institute of Science 545 Bangalore 560012 546 India 548 Email: malati@ece.iisc.ernet.in 549 Charles E. Perkins 550 Futurewei 551 2330 Central Expressway 552 Santa Clara 95050 553 Unites States 555 Email: charliep@computer.org