idnits 2.17.1 draft-jiachen-icn-pubsub-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2014) is 3585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Arumaithurai 3 Internet-Draft J. Chen 4 Intended status: Informational X. Fu 5 Expires: January 4, 2015 University of Goettingen 6 K. Ramakrishnan 7 University of California, Riverside 8 J. Seedorf 9 NEC 10 July 3, 2014 12 Enabling Publish/Subscribe in ICN 13 draft-jiachen-icn-pubsub-00 15 Abstract 17 Information-Centric Networks (ICN) provide substantial flexibility 18 for users to obtain information without regard to the source of the 19 information or its current location. Publish/subscribe (pub/sub) 20 systems have gained popularity in society to provide the convenience 21 of removing the temporal dependency of the user having to indicate an 22 interest each time he or she wants to receive a particular piece of 23 related information. Such an "information-centric" communication 24 model should be supported in the new ICN network paradigm. This 25 document outlines some research directions for ICN with respect to 26 enhancing the inherently pull-based ICN approaches for achieving 27 efficient pub/sub capability. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 4, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Pub/Sub Communication . . . . . . . . . . . . . . . . . . . . 3 65 3. Scenarios of Pub/Sub Architecture . . . . . . . . . . . . . . 4 66 3.1. Online Social Networks and RSS Feeds . . . . . . . . . . 4 67 3.2. Online Gaming and Audio/Video Conferencing . . . . . . . 4 68 3.3. Notification Systems in Disaster . . . . . . . . . . . . 5 69 4. Requirements of an Efficient Pub/Sub Architecture . . . . . . 5 70 5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. IP/Overlay Multicast . . . . . . . . . . . . . . . . . . 7 72 5.2. Named-Data Networking (NDN) . . . . . . . . . . . . . . . 7 73 5.3. Content-Oriented Publish/Subscribe(COPSS) . . . . . . . . 8 74 5.4. Other Related Works . . . . . . . . . . . . . . . . . . . 8 75 6. Standardisation Considerations . . . . . . . . . . . . . . . 9 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 7.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This document points out the need to support publish/subscribe (pub/ 85 sub) capabilities in ICN and the problems with the existing 86 solutions. Further, the document discusses potential directions for 87 enhancing Information Centric Networking (ICN) to achieve efficient 88 pub/sub. 90 Section 2 describes the pub/sub systems and the challenges of such 91 systems to the current Internet. Section 3 demonstrates the use of 92 pub/sub systems in different scenarios. Section 4 outlines the 93 requirements of an efficient pub/sub architecture and Section 5 94 discusses the related works and some possible shortcomings. In 95 Section 6 we brief our standardisation considerations. 97 2. Pub/Sub Communication 99 Users increasingly desire access to information, ranging from news, 100 financial markets, healthcare, to disaster relief and beyond, 101 independent of who published it, where it is located, and often, when 102 it was published. Typical representation of these usages are 103 microblogs, RSS feed, social network, search engines, etc. A 104 consumer may not wish (or it may even be infeasible) to receive all 105 of the "channels" belonging to a myriad of information providers that 106 disseminate items of interest, either on demand (such as web, 107 twitter, blogs and social networks), or tune to a broadcast channel 108 (e.g., television, radio, newspaper). In these cases, the consumer 109 would rather prefer obtaining the data based on Content Descriptors 110 (CD) such as a keyword, a tag, or a property of the content 111 (publisher identity, published date etc.). 113 Publish/subscribe (pub/sub) systems are particularly suited for such 114 kind of large scale content-oriented information dissemination, and 115 provide the exibility for users to subscribe to information of 116 interest, without being intimately tied to when that information is 117 made available by publishers. With the use of an appropriate 118 interface, users can select and filter the information desired so 119 that they receive only what they are interested in, often 120 irrespective of the publisher. 122 Intelligent end-systems and information aggregators (e.g., Google 123 News and Yahoo! News, cable and satellite providers) have 124 increasingly adapted their interfaces to provide a content-oriented 125 pub/sub-based delivery method. However, these mechanisms are built 126 on top of a centralized server based framework and can also result in 127 a waste of network resources as shown in 128 [Ramasubramanian2006][Katsaros2011], since the Internet protocol 129 suite is focused on end-to-end delivery of data. Furthermore, issues 130 of "coverage" and "timeliness" still exist in such forms of 131 dissemination, where the aggregator may be selective in what 132 information is made available. 134 Information-Centric Networks (ICN) is a new network paradigm that 135 intendeds to achieve large scale data delivery with greater ease for 136 users, greater scalability in terms of the amount of information 137 disseminated as well as number of producers and consumers of 138 information, and greater efficiency in terms of network and server 139 resource utilization. 141 It is also desirable for such a network to assist the pub/sub 142 communication model that delivers the information from any of the 143 producers to all subscribers. Moreover, it is desirable for the 144 network to assist in delivering fine-grained information to the 145 subscriber. 147 Recently, works such as 148 [Schmidt2012],[Carzaniga2011],[Chen2011],[Chen2012] have also 149 highlighted the need for ICN to support a pub/sub like communication 150 model. 152 3. Scenarios of Pub/Sub Architecture 154 In this section, we list several use cases of pub/sub architectures 155 in ICN. They help us to understand the requirements of an efficient 156 pub/sub architecture and why the existing solutions fall short. 158 3.1. Online Social Networks and RSS Feeds 160 Online social networks (e.g., Twitter, Facebook, etc.) and Rich Site 161 Summary (RSS) feeds are typical use cases for a content-centric pub/ 162 sub system. In such systems, the receivers receive messages either 163 from friends, followees, or from some information aggregators. They 164 do not care which exact machine is sending the message (content- 165 centric), nor do they know when and what is the name of the next 166 message they are going to receive (temporal separation). 168 To prevent the receivers from polling all the possible providers, 169 existing systems use web servers as rendezvous points: the publishers 170 send new messages to the servers and the receivers/subscribers poll 171 the server periodically. This still causes great wastage for the 172 (HTTP) servers answering "304 - Not Modified" repeatedly since the 173 message update frequency is usually lower than the polling frequency. 175 3.2. Online Gaming and Audio/Video Conferencing 177 Massively multiplayer online role-playing games (MMORPGs, e.g., 178 Counter-Strike, Quake, World of Warcraft, etc.) and audio/video 179 conferencing (e.g., Skype meeting, Web Whiteboard, Etherpad, etc.) is 180 another kind of content-centric pub/sub systems. Similar to the 181 social network scenario, users in such systems only care about the 182 content, either the area of interest (AoI) or the conference 183 partners, and they do not know when and from where the next message 184 will come. But different from the previous scenario, such systems 185 require real-time update (message) delivery and these messages are 186 usually smaller in size compared to the online social networks. 188 Many of these systems choose to use HTTPS or direct TCP connection 189 between the server and the users to enable the capability of server 190 "pushing" the updates to the user. But maintaining such links are 191 costly. MMORPGs usually limit the number of players in a same game 192 which greatly reduces the interesting of these games. 194 3.3. Notification Systems in Disaster 196 Disasters have often disrupted communications because of damages to 197 critical infrastructure. For instance in the aftermath of the 198 Japanese Earthquake in 2011, approximately 1,200,000 fixed telephone 199 lines and 15,000 base-stations were not functioning. On average, 22% 200 (with peaks up to 65% in some areas) of the base-stations had to shut 201 down due to the lack of power or damages to the infrastructure. 203 Contradictory to the loss of available hardware capacity, during and 204 in the aftermath of a disaster, there is a substantial increase in 205 the amount of traffic generated because of the natural anxiety and 206 panic among people and the need to organize rescue and emergency 207 services. Many of these traffic are in the form of a pub/sub 208 communication model, e.g., the government needs to publish some 209 notifications (recovery status, new shelter locations, etc.), the 210 refugees need to notify their friends about their safety, or people 211 needs to ask for help from ambulances or fire brigade. In the 212 Japanese case, the congestion caused by such traffic resulted in 213 restrictions in voice traffic up to 95%, including emergency priority 214 calls. 216 4. Requirements of an Efficient Pub/Sub Architecture 218 Given a pub/sub communication model as described in Section 2, on a 219 high-level one can derive the following (incomplete) list of basic 220 requirements: 222 o Push enabled dissemination: To ensure that subscribers receive 223 information in a timely manner, the target system must provide the 224 ability for publishers to push information to online subscribers 225 interested in it. Such timely dissemination is useful in many 226 scenarios such as disaster (e.g., Tsunami) warnings, stock market 227 information, news and gaming. 229 o Decouple publishers and subscribers: As the number of publishers 230 and subscribers increases, it is important for the network to be 231 content-centric (using content names rather than addresses for 232 routing), while still providing the appropriate association 233 between them (publishers need not know who the subscribers are, 234 and vice versa). Furthermore, each subscriber may be a publisher 235 as well (e.g., Twitter allows users to be both subscribers and 236 publishers of data). 238 o Scalability: The target system must handle a large number of 239 publishers and subscribers. Minimizing the amount of state 240 maintained in the network, ensuring the load on the publisher 241 grows slowly (sub-linearly) with the number subscribers, the load 242 on subscribers also grows slowly with the number of publishers 243 (e.g., dealing with the burden of duplicate elimination). 244 Importantly, the load on the network should not grow significantly 245 with the growth in the number of publishers and subscribers. We 246 also recognize the need to accommodate a very large range in the 247 amount of information that may be disseminated, and the need for 248 all elements of the target system in a content centric environment 249 to scale in a manageable way. 251 o Efficiency: The system must utilize network and server resources 252 efficiently. It is desirable that content is not transmitted 253 multiple times by a server or on a link. Furthermore, the 254 overhead on publisher and subscriber end-points to query 255 unnecessarily for information must be minimized. 257 Additionally, to support a full-fledge pub-sub environment, it is 258 desirable that the target system support the following additional 259 features: 261 o Support hierarchies and context in naming content: We believe it 262 is desirable to be able to exploit both context and hierarchies in 263 identifying content. Hierarchical naming has been recognized by 264 NDN as well. Exploiting context enables a richer identification 265 of content (in both subscriptions and published information), as 266 noted in the database community (and adopted in [Fenner2005]). 268 o Supporting two-step dissemination for policy control and 269 efficiency: We recognize the need for pub/sub environments to 270 support a two-step dissemination process both for reasons of 271 policy and access control at the publisher as well as managing 272 delivery of large volume content. In such a scenario, the target 273 system would be designed to publish only a snippet of the data 274 (containing a description of the content and the method how to 275 obtain it) to subscribers. 277 o Subscriber offline support: Another typical characteristic of pub- 278 sub environments is that subscribers could be offline at the time 279 the data is published. There is clearly a need for asynchronous 280 delivery of information in a pub/sub environment in an efficient, 281 seamless and scalable manner. The system needs to allow users who 282 were online to retrieve the data that they have missed. It should 283 also allow new subscribers to retrieve previously published 284 content that they are interested in. We envisage a server that 285 stores all the content published. 287 5. Related Work 289 5.1. IP/Overlay Multicast 291 IP multicast [RFC1112] is a candidate solution for efficiently 292 delivering content to multiple receivers. A sender sends data to a 293 multicast group address that subscribers could join. Multicast 294 routing protocols such as PIM-SM [RFC4601] construct and maintain a 295 tree from each sender to all receivers of a multicast group. 296 However, IP multicast isn't an efficient pub/sub delivery mechanism 297 for several reasons: 1) IP multicast is designed for delivery of 298 packets to connected end-points. Dealing with disconnected operation 299 (when subscribers are online) would have to be an application layer 300 issue. Overlay multicast solutions such as 301 [Jannotti2000][Chu2002][Banerjee2002] are agnostic of the underlying 302 network topology, usually relying on multiple unicasts in the 303 underlay path and are therefore also inefficient as a pub/sub 304 delivery mechanism. 2) The somewhat limited multicast group address 305 space makes it difficult to support a direct mapping of CDs to IP 306 multicast addresses. 3) Current IP multicast is not able to exploit 307 relationships between information elements, such as CDs. CDs may be 308 hierarchical or may have a contextual relationship, which enables 309 multiple CDs to be mapped to a group. For example, consider a 310 publisher that sends a message to all the subscribers interested in 311 football, and subscribers who are interested in receiving messages 312 about all sports. The message from the publisher will have to be 313 sent to two distinct IP multicast groups. If there happens to be a 314 subscriber of messages on sports and football, (s)he will receive the 315 same message twice and will have to perform redundancy elimination in 316 the application layer. The result is a waste in network traffic and 317 processing at both ends. 319 5.2. Named-Data Networking (NDN) 321 CCN/NDN has limited intrinsic support for pub/sub systems, a critical 322 need in a content centric environment. The aggregation of pending 323 Interests at routers achieves efficient dissemination of information 324 from NDN nodes. But this aggregation is similar to a cache hit in a 325 content distribution network (CDN) cache, which occurs only if 326 subscribers send their Interests with some temporal locality. Thus 327 it avoids multiple Interest queries having to be processed directly 328 by the content provider. Note however that this is still a pull- 329 based information delivery method and depends both on temporal 330 locality of interests and a large enough cache to achieve effective 331 caching in the (content centric) network. On the other hand, native 332 multicast support allows for a much more scalable push-based pub/sub 333 environment, since it is not sensitive to issues such as the cycling 334 of the cache when a large amount of information is disseminated. 336 5.3. Content-Oriented Publish/Subscribe(COPSS) 338 COPSS enhances CCN/NDN with a push-based delivery mechanism using 339 multicast in a content-centric framework. It is designed to satisfy 340 the requirements mentioned above, especially to provide temporal 341 separation between subscription (or expression of Interest) and 342 publication. At the content-centric network layer, COPSS uses a 343 multiple-sender, multiple-receiver multicast capability, in much the 344 same manner as PIM-SM. 346 5.4. Other Related Works 348 Here we list the other related works we are considering. The list 349 might not be complete and we intend to add to it based on feedback 350 received in further revisions. 352 o A. Carzaniga, M. Rutherford, A. Wolf, A routing scheme for 353 content-based networking, in: INFOCOM, 2004. 355 o B. Segall, D. Arnold, J. Boot, M. Henderson, T. Phelps, 356 Content Based Routing with Elvin, in: AUUG2K, 2000. 358 o C. Esteve, F. Verdi, M. Magalhaes, Towards a new generation of 359 information-oriented Internetworking architectures, in: ReArch, 360 2008. 362 o G. Chockler, R. Melamed, Y. Tock, R. Vitenberg, SpiderCast: a 363 scalable interest-aware overlay for topic-based pub/sub 364 communication, in: DEBS, 2007. 366 o H. Eriksson, Mbone: the multicast backbone, Commun. ACM 37 (8) 367 (1994) 54-60. 369 o M. Ott, L. French, R. Mago, D. Makwana, Xml-based semantic 370 multicast routing: an overlay network architecture for future 371 information services, in: GLOBECOM, 2004. 373 o P. T. Eugster, P. A. Felber, R. Guerraoui, A.-M. Kermarrec, 374 The many faces of publish/subscribe, ACM Comput. Surv. 35 (2) 375 (2003) 114-131. 377 o R. Baldoni, R. Beraldi, V. Quema, L. Querzoni, S. Tucci- 378 Piergiovanni, TERA: topic-based event routing for peer-to-peer 379 architectures, in: DEBS, 2007. 381 o R. V. Renesse, K. P. Birman, W. Vogels, Astrolabe: A Robust 382 and Scalable Technology for Distributed System Monitoring, 383 Management, and Data Mining, ACM TOCS 21 (2001) 66-85. 385 o S. Voulgaris, E. Riviere, A.-M. Kermarrec, M. Van Steen, Sub- 386 2-Sub: Self-Organizing Content-Based Publish and Subscribe for 387 Dynamic and Large Scale Collaborative Networks, Research report, 388 INRIA (December 2005). 390 o T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. 391 Kim, S. Shenker, I. Stoica, A data-oriented (and beyond) network 392 architecture, in: SIGCOMM, 2007. 394 o V. Ramasubramanian, R. Peterson, E. G. Sirer, Corona: a high 395 performance publish-subscribe system for the world wide web, in: 396 NSDI, 2006. 398 o V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, 399 N. H. Briggs, R. L. Braynard, Networking Named Content, in: 400 CoNEXT, 2009. 402 o Y. Cui, B. Li, K. Nahrstedt, ostream: asynchronous streaming 403 multicast in application-layer overlay networks, JSAC 22 (1) 404 (2004) 91-106. 406 o Y. Diao, S. Rizvi, M. J. Franklin, Towards an internet-scale 407 XML dissemination service, in: VLDB, 2004. 409 And some related projects: 411 o Named Data Networking (NDN) Project 413 o Pursuit Project, http://www.fp7-pursuit.eu/ 415 o NetInf Project, http://www.netinf.org 417 6. Standardisation Considerations 419 Future versions of this document will outline a concrete protocol 420 specification for pub/sub support for ICN. Below some initial 421 standardisation considerations are outlined. 423 An initial list of details that need to be specified is the 424 following: 426 o Pub/Sub related interfaces/APIs 428 o Pub/Sub related data structure modification to existing ICN 429 proposals 431 We are also considering to write a survey paper that accumulates all 432 the Pub/sub related work. 434 7. References 436 7.1. Normative References 438 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 439 RFC 1112, August 1989. 441 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 442 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 443 Protocol Specification (Revised)", RFC 4601, August 2006. 445 7.2. Informative References 447 [Banerjee2002] 448 Banerjee, S., Bhattacharjee, B., and C. Kommareddy, 449 "Scalable application layer multicast", SIGCOMM, 2002, . 451 [Carzaniga2011] 452 Carzaniga, A., Papalini, M., and A. Wolf, "Content-based 453 Publish/Subscribe Networking and Information-centric 454 Networking", Proceedings of the ACM SIGCOMM workshop on 455 Information-centric networking, ACM, 2011, . 457 [Chen2011] 458 Chen, J., Arumaithurai, M., Fu, X., and K. Ramakrishnan, 459 "COPSS: An Efficient Content Oriented Publish/Subscribe 460 System", ACM/IEEE 7th Symposium on Architectures for 461 Networking and Communications Systems (ANCS), 2011, . 463 [Chen2012] 464 Chen, J., Arumaithurai, M., Fu, X., and K. Ramakrishnan, 465 "G-COPSS: A Content Centric Communication Infrastructure 466 for Gaming Applications", IEEE 32nd International 467 Conference on Distributed Computing Systems (ICDCS), 2012, 468 . 470 [Chu2002] Chu, Y., Rao, S., Seshan, S., and H. Zhang, "A case for 471 end system multicast", IEEE Journal on Selected Areas in 472 Communications 20, no. 8 (2002): 1456-1471, . 474 [Fenner2005] 475 Fenner, W., Rabinovich, M., Ramakrishnan, K., Srivastava, 476 D., and Y. Zhang, "XTreeNet: Scalable overlay networks for 477 XML content dissemination and querying (synopsis)", 10th 478 International Workshop on Web Content Caching and 479 Distribution (WCW), 2005, . 481 [Jannotti2000] 482 Jannotti, J., Gifford, D., Johnson, K., and M. Kaashoek, 483 "Overcast: reliable multicasting with on overlay network", 484 Proceedings of the 4th conference on Symposium on 485 Operating System Design & Implementation-Volume 4, pp. 486 14-14. USENIX Association, 2000, . 488 [Katsaros2011] 489 Katsaros, K., Xylomenos, G., and G. Polyzos, "MultiCache: 490 An overlay architecture for information-centric 491 networking", Computer Networks 55.4 (2011): 936-947, . 493 [Ramasubramanian2006] 494 Ramasubramanian, V., Peterson, R., and E. Sirer, "Corona: 495 A High Performance Publish-Subscribe System for the World 496 Wide Web", NSDI. Vol. 6. 2006, . 498 [Schmidt2012] 499 Schmidt, T. and M. Waehlisch, "Why We Shouldn t Forget 500 Multicast in Name-oriented Publish/Subscribe", arXiv 501 preprint arXiv:1201.0349 (2012), . 503 Appendix A. Acknowledgment 505 This document has been supported by the GreenICN project (GreenICN: 506 Architecture and Applications of Green Information Centric Networking 507 ), a research project supported jointly by the European Commission 508 under its 7th Framework Program (contract no. 608518) and the 509 National Institute of Information and Communications Technology 510 (NICT) in Japan (contract no. 167). The views and conclusions 511 contained herein are those of the authors and should not be 512 interpreted as necessarily representing the official policies or 513 endorsements, either expressed or implied, of the GreenICN project, 514 the European Commission, or NICT. 516 Authors' Addresses 517 Mayutan Arumaithurai 518 University of Goettingen 519 Goldschmidt Str. 7 520 Goettingen 37077 521 Germany 523 Phone: +49 551 39 172046 524 Fax: +49 551 39 14416 525 Email: arumaithurai@informatik.uni-goettingen.de 527 Jiachen Chen 528 University of Goettingen 529 Goldschmidt Str. 7 530 Goettingen 37077 531 Germany 533 Phone: +49 551 39 172051 534 Fax: +49 551 39 14416 535 Email: jiachen@informatik.uni-goettingen.de 537 Xiaoming Fu 538 University of Goettingen 539 Goldschmidt Str. 7 540 Goettingen 37077 541 Germany 543 Phone: +49 551 39 172023 544 Fax: +49 551 39 14416 545 Email: fu@informatik.uni-goettingen.de 547 K. K. Ramakrishnan 548 University of California, Riverside 549 900 University Ave 550 Riverside CA 92521 551 USA 553 Email: kkramakrishnan@yahoo.com 554 Jan Seedorf 555 NEC 556 Kurfuerstenanlage 36 557 Heidelberg 69115 558 Germany 560 Phone: +49 6221 4342 221 561 Fax: +49 6221 4342 155 562 Email: seedorf@neclab.eu