idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-15.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2010) is 5054 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4347 (ref. '2') (Obsoleted by RFC 6347) == Outdated reference: A later version (-06) exists of draft-ietf-tsvwg-dtls-for-sctp-05 ** Obsolete normative reference: RFC 4960 (ref. '6') (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '9') (Obsoleted by RFC 9293) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-22 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft C. Dickmann 4 Intended status: Experimental University of Goettingen 5 Expires: December 27, 2010 J. Crowcroft 6 University of Cambridge 7 June 25, 2010 9 General Internet Signaling Transport (GIST) over Stream Control 10 Transmission Protocol (SCTP) and Datagram Transport Layer Security 11 (DTLS) 12 draft-ietf-nsis-ntlp-sctp-15.txt 14 Abstract 16 The General Internet Signaling Transport (GIST) protocol currently 17 uses TCP or Transport Layer Security (TLS) over TCP for connection 18 mode operation. This document describes the usage of GIST over the 19 Stream Control Transmission Protocol (SCTP) and Datagram Transport 20 Layer Security (DTLS). 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 27, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5 70 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Message Association Setup . . . . . . . . . . . . . . . . 5 72 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 6 74 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6 75 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 7 76 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7 77 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 8 79 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8 80 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8 81 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 9 82 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 9 83 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 This document describes the usage of the General Internet Signaling 95 Transport (GIST) protocol [1] and Datagram Transport Layer Security 96 (DTLS) [2]. 98 GIST, in its initial specification for connection mode operation, 99 runs on top of a byte-stream oriented transport protocol providing a 100 reliable, in-sequence delivery, i.e., using the Transmission Control 101 Protocol (TCP) [9] for signaling message transport. However, some 102 Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10] 103 context information has a definite lifetime, therefore, the GIST 104 transport protocol could benefit from flexible retransmission, so 105 stale NSLP messages that are held up by congestion can be dropped. 106 Together with the head-of-line blocking and multihoming issues with 107 TCP, these considerations argue that implementations of GIST should 108 support SCTP as an optional transport protocol for GIST. Like TCP, 109 SCTP supports reliability, congestion control and fragmentation. 110 Unlike TCP, SCTP provides a number of functions that are desirable 111 for signaling transport, such as multiple streams and multiple IP 112 addresses for path failure recovery. Furthermore, SCTP offers an 113 advantage of message-oriented transport instead of using the byte 114 stream oriented TCP where one has to provide its own framing 115 mechanisms. In addition, its Partial Reliability extension (PR-SCTP) 116 [3] supports partial retransmission based on a programmable 117 retransmission timer. Furthermore, DTLS provides a viable solution 118 for securing SCTP [4], which allows SCTP to use almost all its 119 transport features and its extensions. 121 This document defines the use of SCTP as the underlying transport 122 protocol for GIST and the use of DTLS as a security mechanism for 123 protecting GIST Messaging Associations and discusses the implications 124 on GIST state maintenance and API between GIST and NSLPs. 125 Furthermore, this document describes how GIST is transported over 126 SCTP and used by NSLPs in order to exploit the additional 127 capabilities offered by SCTP to deliver GIST C-mode messages more 128 effectively. More specifically: 129 o How to use the multiple streams feature of SCTP. 130 o How to use the PR-SCTP extension of SCTP. 131 o How to take advantage of the multi-homing support of SCTP. 133 GIST over SCTP described in this document do not require any changes 134 to the high level operation and structure of GIST. However, adding 135 new transport options requires additional interface code and 136 configuration support to allow applications to exploit the additional 137 transport when appropriate. In addition, SCTP implementions to 138 transport GIST MUST support the optional feature of fragmentation of 139 SCTP user messages. 141 Additionally, this document also specifies how to establish GIST 142 security using DTLS for use in combination with e.g., SCTP and UDP. 144 2. Terminology and Abbreviations 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [5]. Other 149 terminologies and abbreviations used in this document are taken from 150 related specifications ([1], [2], [6], [3]): 151 o SCTP - Stream Control Transmission Protocol 152 o PR-SCTP - SCTP Partial Reliability Extension 153 o MRM - Message Routing Method 154 o MRI - Message Routing Information 155 o SCD - Stack-Configuration-Data 156 o Messaging Association (MA) - a single connection between two 157 explicitly identified GIST adjacent peers, i.e. between a given 158 signalling source and destination address. A messaging 159 association may use a transport protocol; if security protection 160 is required, it may use a specific network layer security 161 association, or use a transport layer security association 162 internally. A messaging association is bi-directional; signaling 163 messages can be sent over it in either direction, referring to 164 flows of either direction. 165 o SCTP Association - A protocol relationship between SCTP endpoints, 166 composed of the two SCTP endpoints and protocol state information. 167 An association can be uniquely identified by the transport 168 addresses used by the endpoints in the association. Two SCTP 169 endpoints MUST NOT have more than one SCTP association between 170 them at any given time. 171 o Stream - A unidirectional logical channel established from one to 172 another associated SCTP endpoint, within which all user messages 173 are delivered in sequence except for those submitted to the 174 unordered delivery service. 176 3. GIST Over SCTP 178 This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for 179 using SCTP as GIST transport protocol. The use of DTLS in GIST is 180 defined in Section 7. 182 3.1. Message Association Setup 183 3.1.1. Overview 185 The basic GIST protocol specification defines two possible protocols 186 to be used in Messaging Associations, namely Forwards-TCP and TLS. 187 This information is a main part of the Stack Configuration Data (SCD) 188 [1]. This section adds "Forwards-SCTP" as another possible protocol 189 option. In Forwards-SCTP, analog to Forwards-TCP, connections 190 between peers are opened in the forwards direction, from the querying 191 node, towards the responder. 193 3.1.2. Protocol-Definition: Forwards-SCTP 195 The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP 196 between peers. Support for this protocol is OPTIONAL. If this 197 protocol is offered, MA-protocol-options data MUST also be carried in 198 the SCD object. The MA-protocol-options field formats are: 199 o in a Query: no information apart from the field header. 200 o in a Response: 2 byte port number at which the connection will be 201 accepted, followed by 2 pad bytes. 203 The connection is opened in the forwards direction, from the querying 204 node towards the responder. The querying node MAY use any source 205 address and source port. The destination for establishing the 206 message association MUST be derived from information in the Response: 207 the address from the interface- address from the Network-Layer- 208 Information object and the port from the SCD object as described 209 above. 211 Associations using Forwards-SCTP can carry messages with the transfer 212 attribute Reliable=True. If an error occurs on the SCTP connection 213 such as a reset, as can be reported by an SCTP socket API 214 notification[11], GIST MUST report this to NSLPs as discussed in 215 Section 4.1.2 of [1]. For the multi-homing scenario, when a 216 destination address of a GIST over SCTP peer encounters a change, the 217 SCTP API will notify GIST about the availability of different SCTP 218 endpoint addresses and possible change of the primary path. 220 3.2. Effect on GIST State Maintenance 222 As SCTP provides additional functionality over TCP, this section 223 discusses the implications of using GIST over SCTP on GIST State 224 Maintenance. 226 While SCTP defines uni-directional streams, for the purpose of this 227 document, the concept of a bi-directional stream is used. 228 Implementations MUST establish downstream and upstream (uni- 229 directional) SCTP streams always together and use the same stream 230 identifier in both directions. Thus, the two uni-directional streams 231 (in opposite directions) form a bi-directional stream. 233 Due to the multi-streaming support of SCTP, it is possible to use 234 different SCTP streams for different resources (e.g., different NSLP 235 sessions), rather than maintaining all messages along the same 236 transport connection/association in a correlated fashion as TCP 237 (which imposes strict (re)ordering and reliability per transport 238 level). However, there are limitations to the use of multi- 239 streaming. When an SCTP implementation is used for GIST transport, 240 all GIST messages for a particular session MUST be sent over the same 241 SCTP stream to assure the NSLP assumption of in-order delivery. 242 Multiple sessions MAY share the same SCTP stream based on local 243 policy. 245 The GIST concept of Messaging Association re-use is not affected by 246 this document or the use of SCTP. All rules defined in the GIST 247 specification remain valid in the context of GIST over SCTP. 249 3.3. PR-SCTP Support 251 A variant of SCTP, PR-SCTP [3] provides a "timed reliability" 252 service, which would be particularly useful for delivering GIST 253 Connection mode messages. It allows the user to specify, on a per 254 message basis, the rules governing how persistent the transport 255 service should be in attempting to send the message to the receiver. 256 Because of the chunk bundling function of SCTP, reliable and 257 partially reliable messages can be multiplexed over a single PR-SCTP 258 association. Therefore, an SCTP implementation for GIST transport 259 SHOULD attempt to establish a PR-SCTP association using "timed 260 reliability" service instead of a standard SCTP association, if 261 available, to support more flexible transport features for potential 262 needs of different NSLPs. 264 When using a normally reliable session (as opposed to a partially 265 reliable session), if a node has sent the first transmission before 266 the lifetime expires, then the message MUST be sent as a normal 267 reliable message. During episodes of congestion this is particularly 268 unfortunate, as retransmission wastes bandwidth that could have been 269 used for other (non-lifetime expired) messages. The "timed 270 reliability" service in PR-SCTP eliminates this issue and is hence 271 RECOMMENDED to be used for GIST over PR-SCTP. 273 3.4. API between GIST and NSLP 275 GIST specification defines an abstract API between GIST and NSLPs. 276 While this document does not change the API itself, the semantics of 277 some parameters have slightly different interpretation in the context 278 of SCTP. This section only lists those primitives and parameters, 279 that need special consideration when used in the context of SCTP. 280 The relevant primitives from [1] are as follows: 281 o The Timeout parameter in API "SendMessage": According to [1], this 282 parameter represents the "length of time GIST should attempt to 283 send this message before indicating an error." When used with PR- 284 SCTP, this parameter is used as the timeout for the "timed 285 reliability" service of PR-SCTP. 286 o "NetworkNotification": According to [1], this primitive "is passed 287 from GIST to a signalling application. It indicates that a 288 network event of possible interest to the signalling application 289 occurred." Here, if SCTP detects a failure of the primary path, 290 GIST SHOULD also indicate this event to the NSLP by calling this 291 primitive with Network-Notification-Type "Routing Status Change". 292 This notification should be done even if SCTP was able to retain 293 an open connection to the peer due to its multi-homing 294 capabilities. 296 4. Bit-Level Formats 298 4.1. MA-Protocol-Options 300 This section provides the bit-level format for the MA-protocol- 301 options field that is used for SCTP protocol in the Stack- 302 Configuration-Data object of GIST. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : SCTP port number | Reserved : 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 SCTP port number = Port number at which the responder will accept 311 SCTP connections 313 The SCTP port number is only supplied if sent by the responder. 315 5. Application of GIST over SCTP 317 5.1. Multi-homing support of SCTP 319 In general, the multi-homing support of SCTP can be used to improve 320 fault-tolerance in case of a path- or link-failure. Thus, GIST over 321 SCTP would be able to deliver NSLP messages between peers even if the 322 primary path is not working anymore. However, for the Message 323 Routing Methods (MRMs) defined in the basic GIST specification such a 324 feature is only of limited use. The default MRM is path-coupled, 325 which means, that if the primary path is failing for the SCTP 326 association, it most likely is also for the IP traffic that is 327 signaled for. Thus, GIST would need to perform a refresh to the NSIS 328 nodes to the alternative path anyway to cope with the route change. 329 When the two endpoints of a multi-homed SCTP association (but none of 330 the intermediate nodes between them) support NSIS, GIST over SCTP 331 provides a robust means for GIST to deliver NSLP messages even when 332 the primary path fails but at least one alternative path between 333 these (NSIS-enabled) endpoints of the multihomed path is available. 334 Additionally, the use of the multi-homing support of SCTP provides 335 GIST and the NSLP with another source to detect route changes. 336 Furthermore, for the time between detection of the route change and 337 recovering from it, the alternative path offered by SCTP can be used 338 by the NSLP to make the transition more smoothly. Finally, future 339 MRMs might have different properties and therefore benefit from 340 multi-homing more broadly. 342 5.2. Streaming support in SCTP 344 Streaming support in SCTP is advantageous for GIST. It allows better 345 parallel processing, in particular by avoiding head of line blocking 346 issue in TCP. Since a same GIST MA may be reused by multiple 347 sessions, using TCP as transport for GIST signaling messages 348 belonging to different sessions may be blocked if another message is 349 dropped. In the case of SCTP, this can be avoided as different 350 sessions having different requirements can belong to different 351 streams, thus a message loss or reordering in a stream will only 352 affect the delivery of messages within that particular stream, and 353 not any other streams. 355 6. NAT Traversal Issue 357 NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and 358 the GIST extensibility capabilities defined in [12]. This 359 specification does not define NAT traversal procedure for GIST over 360 SCTP, although an approach for SCTP NAT traversal is described in 361 [13]. 363 7. Use of DTLS with GIST 365 This section specifies a new MA-Protocol-ID "DTLS" for the use of 366 DTLS in GIST, which denotes a basic use of datagram transport layer 367 channel security, initially in conjunction with GIST over SCTP. It 368 provides server (i.e., GIST transport receiver) authentication and 369 integrity (as long as the NULL cipher suite is not selected during 370 cipher suite negotiation), as well as optionally replay protection 371 for control packets. The use of DTLS for securing GIST over SCTP 372 allows GIST to take the advantage of features provided by SCTP and 373 its extensions. The usage of DTLS for GIST over SCTP is similar to 374 TLS for GIST as specified in [1], where a stack-proposal containing 375 both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake 376 phase. 378 The usage of DTLS [2] for securing GIST over datagram transport 379 protocols MUST be implemented and SHOULD be used. 381 GIST message associations using DTLS may carry messages with transfer 382 attributes requesting confidentiality or integrity protection. The 383 specific DTLS version will be negotiated within the DTLS layer 384 itself, but implementations MUST NOT negotiate to protocol versions 385 prior to DTLS v1.0 and MUST use the highest protocol version 386 supported by both peers. NULL authentication and integrity ciphers 387 MUST NOT be negotiated for GIST nodes supporting DTLS. For 388 confidentiality ciphers, nodes can negotiate the NULL ciphersuites. 389 The same rules for negotiating TLS cipher suites as specified in 390 Section 5.7.3 of [1] apply. 392 DTLS renegotiation [7] may cause problems for applications such that 393 connection security parameters can change without the application 394 knowing it. Hence, it is RECOMMENDED that renegotiation be disabled 395 for GIST over DTLS. 397 No MA-protocol-options field is required for DTLS. The configuration 398 information for the transport protocol over which DTLS is running 399 (e.g. SCTP port number) is provided by the MA-protocol-options for 400 that protocol. 402 8. Security Considerations 404 The security considerations of [1], [6] and [2] apply. Additionally, 405 although [4] does not support replay detection in the DTLS over SCTP, 406 the SCTP replay protection mechanisms [6] [8] should be able to 407 protect NSIS messages transported using GIST over (DTLS over) SCTP 408 from replay attacks. 410 9. IANA Considerations 412 This specification requests the following codepoints (MA-Protocol- 413 IDs) be assigned in a registry created by [1]: 415 +---------------------+------------------------------------------+ 416 | MA-Protocol-ID | Protocol | 417 +---------------------+------------------------------------------+ 418 | 3 | SCTP opened in the forwards direction | 419 | | | 420 | 4 | DTLS initiated in the forwards direction | 421 +---------------------+------------------------------------------+ 423 Note that MA-Protocol-ID "DTLS" is never used alone but always 424 coupled with a transport protocol specified in the stack proposal. 426 10. Acknowledgments 428 The authors would like to thank John Loughney, Jukka Manner, Magnus 429 Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert 430 Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan 431 Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their 432 helpful suggestions. 434 11. References 436 11.1. Normative References 438 [1] Schulzrinne, H. and M. Stiemerling, "GIST: General Internet 439 Signalling Transport", draft-ietf-nsis-ntlp-20 (work in 440 progress), June 2009. 442 [2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 443 Security", RFC 4347, April 2006. 445 [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 446 "Stream Control Transmission Protocol (SCTP) Partial 447 Reliability Extension", RFC 3758, May 2004. 449 [4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 450 Transport Layer Security (DTLS) for Stream Control Transmission 451 Protocol (SCTP)", draft-ietf-tsvwg-dtls-for-sctp-05 (work in 452 progress), March 2010. 454 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 455 Levels", BCP 14, RFC 2119, March 1997. 457 [6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 458 September 2007. 460 [7] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport 461 Layer Security (TLS) Renegotiation Indication Extension", 462 RFC 5746, February 2010. 464 [8] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 465 "Authenticated Chunks for the Stream Control Transmission 466 Protocol (SCTP)", RFC 4895, August 2007. 468 11.2. Informative References 470 [9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 471 September 1981. 473 [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 474 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 475 June 2005. 477 [11] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, 478 "Sockets API Extensions for Stream Control Transmission 479 Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-22 (work in 480 progress), March 2010. 482 [12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and 483 Extending the NSIS Protocol Family", draft-ietf-nsis-ext-07 484 (work in progress), April 2010. 486 [13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 487 Transmission Protocol (SCTP) Network Address Translation", 488 draft-ietf-behave-sctpnat-02 (work in progress), December 2009. 490 Authors' Addresses 492 Xiaoming Fu 493 University of Goettingen 494 Institute of Computer Science 495 Goldschmidtstr. 7 496 Goettingen 37077 497 Germany 499 Email: fu@cs.uni-goettingen.de 500 Christian Dickmann 501 University of Goettingen 502 Institute of Computer Science 503 Goldschmidtstr. 7 504 Goettingen 37077 505 Germany 507 Email: mail@christian-dickmann.de 509 Jon Crowcroft 510 University of Cambridge 511 Computer Laboratory 512 William Gates Building 513 15 JJ Thomson Avenue 514 Cambridge CB3 0FD 515 UK 517 Email: jon.crowcroft@cl.cam.ac.uk