idnits 2.17.00 (12 Aug 2021) /tmp/idnits6514/draft-bernardos-spawn-use-cases-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 : ---------------------------------------------------------------------------- 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 (March 25, 2019) is 1153 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) == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: draft-ietf-detnet-architecture has been published as RFC 8655 == Outdated reference: draft-ietf-detnet-problem-statement has been published as RFC 8557 == Outdated reference: draft-ietf-detnet-use-cases has been published as RFC 8578 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPAWN G. Papadopoulos 3 Internet-Draft IMT Atlantique 4 Intended status: Standards Track P. Thubert 5 Expires: September 26, 2019 Cisco 6 F. Theoleyre 7 CNRS 8 CJ. Bernardos 9 UC3M 10 March 25, 2019 12 SPAWN use cases 13 draft-bernardos-spawn-use-cases-00 15 Abstract 17 The wireless medium presents significant specific challenges to 18 achieve properties similar to those of wired deterministic networks. 19 At the same time, a number of use cases cannot be solved with wires 20 and justify the extra effort of going wireless. This document 21 presents some of these use-cases. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 26, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 4 60 2.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 5 62 2.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 6 63 3. Wireless for Industrial Applications . . . . . . . . . . . . 6 64 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 6 65 3.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 6 67 3.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 7 68 3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 7 69 3.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 8 70 4. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 8 72 4.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 9 74 4.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 9 75 5. UAV control . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 9 77 5.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 9 78 5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 10 79 5.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 10 80 6. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 10 81 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 10 82 6.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 11 83 6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 11 84 6.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 11 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 9. Informative References . . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Based on time, resource reservation, and policy enforcement by 93 distributed shapers, Deterministic Networking provides the capability 94 to carry specified unicast or multicast data streams for real-time 95 applications with extremely low data loss rates and bounded latency, 96 so as to support time-sensitive and mission-critical applications on 97 a converged enterprise infrastructure. 99 Deterministic Networking in the IP world is an attempt to eliminate 100 packet loss for a committed bandwidth while ensuring a worst case 101 end-to-end latency, regardless of the network conditions and across 102 technologies. It can be seen as a set of new Quality of Service 103 (QoS) guarantees of worst-case delivery. IP networks become more 104 deterministic when the effects of statistical multiplexing (jitter 105 and collision loss) are mostly eliminated. This requires a tight 106 control of the physical resources to maintain the amount of traffic 107 within the physical capabilities of the underlying technology, e.g., 108 by the use of time-shared resources (bandwidth and buffers) per 109 circuit, and/or by shaping and/or scheduling the packets at every 110 hop. 112 Key attributes of Deterministic Networking include: 114 o time synchronization on all the nodes, 116 o centralized computation of network-wide deterministic paths, and 118 o new traffic shapers within and at the edge to protect the network. 120 Wireless operates on a shared medium, and transmissions cannot be 121 fully deterministic due to uncontrolled interferences, including 122 self-induced multipath fading. Scheduling transmissions enables to 123 alleviate those effects by leveraging diversity in the spatial, time 124 and frequency domains, enabling Scheduled Predictable and Available 125 Wireless Networks (SPAWN). 127 The wireless and wired media are fundamentally different at the 128 physical level, and while the generic Problem Statement 129 [I-D.ietf-detnet-problem-statement] for DetNet applies to the wired 130 as well as the wireless medium, the methods to achieve SPAWN 131 necessarily differ from those used to support Time-Sensitive 132 Networking over wires. 134 So far, Open Standards for Deterministic Networking have prevalently 135 been focused on wired media, with Audio/Video Bridging (AVB) and Time 136 Sensitive Networking (TSN) at the IEEE and DetNet 137 [I-D.ietf-detnet-architecture] at the IETF. But wires cannot be used 138 in a number of cases, including mobile or rotating devices, 139 rehabilitated industrial buildings, wearable or in-body sensory 140 devices, vehicle automation and multiplayer gaming. 142 Purpose-built wireless technologies such as [ISA100], which 143 incorporates IPv6, were developed and deployed to cope for the lack 144 of open standards, but they yield a high cost in OPEX and CAPEX and 145 are limited to very few industries, e.g., process control, concert 146 instruments or racing. 148 This is now changing: 150 o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication 151 (URLLC) as a key functionality for the upcoming 5G, 153 o IEEE 802.11 is integrating real-time applications in the charter 154 of the Extreme High Throughput (EHT) Task Group (to be formed at 155 the time of this writing), and 157 o the IETF has produced an IPv6 stack for IEEE Std. 802.15.4 158 TimeSlotted Channel Hopping (TSCH) and an architecture 159 [I-D.ietf-6tisch-architecture] that enables Scheduled Predictable 160 and Available Wireless Networks (SPAWN) on a shared MAC. 162 This draft extends the "Deterministic Networking Use Cases" 163 [I-D.ietf-detnet-use-cases] and describes a number of additional use 164 cases which require deterministic flows over wireless links and 165 possibly complex multi-hop paths called Tracks. 167 2. Amusement Parks 169 2.1. Use Case Description 171 The digitalization of Amusement Parks is expected to decrease 172 significantly the cost for maintaining the attractions. By 173 monitoring in real-time the machines, predictive maintenance will 174 help to reduce the repairing cost as well as the downtime. Besides, 175 the attractions may use wireless transmissions to interconnect 176 sensors and actuators, to privileged reconfigurability, and 177 standardization. 179 Attractions may comprise a large set of sensors and actuators, which 180 react in real time. Typical applications (ordered by criticality in 181 descending order) are: 183 o emergency: safety has to be preserved. An attraction has to be 184 stopped if a failure is detected; 186 o real-time control: real-time applications embedded in the 187 attraction need to trigger an action when an event is detected. 188 For instance, a photograph can be taken when a car crosses an 189 actuator, combined with a wireless ID that the tourists wear; 191 o predictive maintenance: statistics are collected to predict the 192 future failures, or to compute later more complex statistics about 193 the attraction's usage, the downtime, its popularity, etc. 195 2.2. Specificities 197 Amusement parks comprise a variable number of attractions, mostly 198 outdoor. Thus, 200 The tourists are free to move from an attraction to another, covering 201 a large geographical area. Wearable devices are expected for a user 202 experience personalisation. Thus, some devices may be mobile, while 203 the rest of the infrastructure remains static. 205 The infrastrcuture is typically multi-scale: 207 o local area: the sensors and actuators controlling the attractions 208 are co-located. Real-time flows are localized, a set of sensors 209 triggering actuators. Maintenance flows are mostly lrage-range, 210 interconnected with the information system; 212 o wearable devices are free to move in the park. They exchange 213 traffic locally (identification, personalization, multimedia) or 214 globally (billing child tracking); 216 o global information system manages the whole park, and exchange 217 commands or information with the different parts. 219 2.3. The Need for Wireless 221 Amusement parks cover large areas and a global interconnection would 222 require a huge length of cables. Wireless also optimizes the 223 reconfigurability, enabling to plug novel services easily to increase 224 e.g. the interactivity. 226 Attractions comprise mobile components (e.g. robots, wagons), which 227 require wireless connections since cables are particulalry 228 inconvenient and source of failures in such conditions. 230 Wearable devices have to support by nature wireless transmissions. 231 They aim to enable novel high-value services. VIP tickets are 232 nowadays more and more popular. Wireless wearable devices may help 233 to reduce the operating costs [disney-VIP] and increasing the number 234 of charged services provided to the audience (VIP tickets, 235 interactivity, etc.) 237 2.4. Asks for SPAWN 239 The networ infrastructure has to support heterogenous traffic, with 240 very different criticalities. Thus, flow isolation has to be 241 provided, where best effort traffic only 243 We have to schedule appropriately the transmissions, even in presence 244 of mobile devices. While the [I-D.ietf-6tisch-architecture] already 245 proposes an architecture for synchronized, IEEE Std. 802.15.4 Time- 246 Slotted Channel Hopping (TSCH) networks, 6TiSCH focused on best- 247 effort IPv6 flows. SPAWN expects to schedule appropriately the 248 transmissions, across heterogeneous technologies, with strict SLA 249 requirements. 251 Nowadays, long-range wireless transmissions are used for best-effort 252 traffic, and [IEEE802.1TSN] is used for critical flows using Ethernet 253 devices. However, we need an IP enabled technology to interconnect 254 large areas, independent of the PHY and MAC layer to maximize the 255 compliance. 257 3. Wireless for Industrial Applications 259 3.1. Use Case Description 261 A major use case for networking in Industrial is the control networks 262 where periodic control loops operate between a sensor that measures a 263 physical property such as the temperature of a fluid, a Programmable 264 Logic Controller that decides an action such as warm up the mix, and 265 an actuator that performs the required action, e.g., inject power in 266 a resistor. 268 3.2. Specificities 270 3.2.1. Control Loops 272 Process Control designates continous processing operations, e.g., 273 heating Oil in a refinery or mixing drinking soda. Control loops in 274 the Process Control industry operate at a very low rate, typically 4 275 times per second. Factory Automation, on the other hand, deal with 276 discrete goods such as individual automobile parts, and requires 277 faster loops, in the order of 10ms. Motion control that monitors 278 dynamic activities may require even faster rates in the order of a 279 few ms. Finally, some industries exhibit hybrid behaviors, like 280 canned soup that will start as a process industry while mixing the 281 food and then operate as a discrete manufacturing when putting the 282 final product in cans and shipping them. 284 In all those cases, a packet must flow deterministically between the 285 sensor and the PLC, be processed by the PLC, and sent to the actuator 286 within the control loop period. In some particular use cases that 287 inherit from analog operations, jitter might also alter the operation 288 of the control loop. A rare packet loss is usually admissible, but 289 typically 4 losses in a row will cause an emergency halt of the 290 production and incur a high cost for the manufacturer. 292 3.2.2. Unmeasured Data 294 A secondary use case deals with monitoring and diagnostics. This so- 295 called unmeasured data is essential to improve the performances of a 296 production line, e.g., by optimizing real-time processing or 297 maintenance windows using Machine Learning predictions. For the lack 298 of wireless technologies, some specific industries such as Oil and 299 Gas have been using serial cables, literally by the millions, to 300 perform their process optimization over the previous decades. But 301 few industries would afford the associated cost and the Holy Grail of 302 the Industrial Internet of Things is to provide the same benefits to 303 all industries, including SmartGrid, Transportation, Building, 304 Commercial and Medical. This requires a cheap, available and 305 scalable IP-based access technology. 307 Inside the factory, wires may already be available to operate the 308 Control Network. But unmeasured data are not welcome in that network 309 for a number of reasons. On the one hand it is rich and 310 asynchronous, meaning that using they may influence the deterministic 311 nature of the control operations and impact the production. On the 312 other hand, this information must be reported to the carpeted floor 313 over IP, which means the potential for a security breach via the 314 interconnection of the Operational Technology (OT) network with the 315 Internet technology (IT) network and possibly enable a rogue access. 317 3.3. The Need for Wireless 319 Ethernet cables used on a robot arm are prone to breakage after a few 320 thousands flexions, a lot faster than a power cable that is wider inn 321 diameter, and more resilient. In general, wired networking and 322 mobile parts are not a good match, mostly in the case of fast and 323 recurrent activities, as well as rotation. 325 When refurbishing older premises that were built before the Internet 326 age, power is usually available everywhere, but data is not. It is 327 often impractical, time consuming and expensive to deploy an Ethernet 328 fabric across walls and between buildings. Deploying a wire may take 329 months and cost tens of thousands of US Dollars. 331 Even when wiring exists, e.g., in an existing control network, 332 asynchronous IP packets such as diagnostics may not be welcome for 333 operational and security reasons (see Section 3.2.1). An alternate 334 network that can scale with the many sensors and actuators that equip 335 every robot, every valve and fan that are deployed on the factory 336 floor and may help detect and prevent a failure that could impact the 337 production. IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) 338 [RFC7554] is a promising technology for that purpose, mostly if the 339 scheduled operations enable to use the same network by asynchronous 340 and deterministic flows in parallel. 342 3.4. Asks for SPAWN 344 As stated by the "Deterministic Networking Problem Statement" 345 [I-D.ietf-detnet-problem-statement], a Deterministic Network is 346 backwards compatible with (capable of transporting) statistically 347 multiplexed traffic while preserving the properties of the accepted 348 deterministic flows. While the [I-D.ietf-6tisch-architecture] serves 349 that requirement, the work at 6TiSCH was focused on best-effort IPv6 350 packet flows. SPAWN should be able to lock so-called hard cells for 351 use by a centralized scheduler, and program so-called end-to-end 352 Tracks over those cells. 354 Over the course of the recent years, major Industrial Protocols, 355 e.g., [ODVA] with EtherNet/IP [EIP] and [Profinet], have been 356 migrating towards Ethernet and IP. In order to unleash the full 357 power of the IP hourglass model, it should be possible to deploy any 358 application over any network that has the physical capacity to 359 transport the industrial flow, regardless of the MAC/PHY technology, 360 wired or wireless, and across technologies. SPAWN should be able to 361 setup a Track over a wireless access segment such as TSCH and a 362 backbone segment such as Ethernet or WI-Fi, to report a sensor data 363 or a critical monitoring within a bounded latency. 365 4. Pro Audio and Video 367 4.1. Use Case Description 369 The professional audio and video industry ("ProAV") includes: 371 o Public address, media and emergency systems at large venues 372 (airports, stadiums, train stations, churches, theme parks). 374 Today the ProAV applications are moving towards packet-based 375 technology to introduce routing features and to reduce costs. 377 4.2. Specificities 379 Considering the uninterrupted audio or video stream, a potential 380 packet losses during the transmission of audio or video flows cannot 381 be tackled by re-trying the transmission, as it is done with file 382 transfer, because by the time the packet lost has been identified it 383 is too late to proceed with packet re-transmission. 385 4.3. The Need for Wireless 387 4.4. Asks for SPAWN 389 TBD. 391 5. UAV control 393 5.1. Use Case Description 395 Unmanned Aerial Vehicles (UAVs) are becoming very popular for many 396 different applications, including military and civil use cases. The 397 term drone is commonly used to refer to a UAV. 399 UAVs can be used to perform aerial surveillance activities, traffic 400 monitoring (e.g., Spanish traffic control has recently introduced a 401 fleet of drones for quicker reactions upon traffic congestion related 402 events), support of emergency situations, and even transportation of 403 small goods. 405 UAVs typically have various forms of wireless connectivity: 407 o cellular: for communication with the control center, for remote 408 manuevering as well as monitoring of the drone; 410 o IEEE 802.11: for inter-drone communications (e.g., coordination of 411 actions, platooning) and providing connectivity to other devices 412 (e.g., acting as Access Point). 414 5.2. Specificities 416 Some of the use cases/tasks involving drones require coordination 417 among drones. Others involve complex compute tasks that might not be 418 performed using the limited computing resources that a drone 419 typically has. These two aspects require continuous connectivity 420 with the control center and among drones. 422 Remote maneuvering of a drone might be performed over a cellular 423 network in some cases, however, there are situations that need very 424 low latencies and deterministic behavior of the connectivity. 426 Examples involve platooning of drones or sharing of computing 427 resources among drones (e.g., a drone offload some function to a 428 neighboring drone). 430 5.3. The Need for Wireless 432 UAVs cannot be connected through any type of wired media, so it is 433 obvious that wireless is needed. 435 5.4. Asks for SPAWN 437 The network infrastructure is actually composed by the UAVs 438 themselves, requiring self-configuration capabilities. 440 Heterogeneous types of traffic need to be supported, from extremely 441 critical ones requiring ultra low latency and high resiliency, to 442 traffic requiring low-medium latency. 444 When a given service is decomposed into functions -- hosted at 445 different drones -- chained, each link connecting two given functions 446 would have a well-defined set of requirements (latency, bandwith and 447 jitter) that have to be met. 449 6. Edge Robotics control 451 6.1. Use Case Description 453 The Edge Robotics scenario consists of several robots, deployed in a 454 given area (for example a shopping mall), inter-connected via an 455 access network to a network's edge device or a data center. The 456 robots are connected to the edge so complex computational activities 457 are not executed locally at the robots, but offloaded to the edge. 458 This brings additional flexibility in the type of tasks that the 459 robots do, as well as reducing the costs of robot manufacturing (due 460 to their lower complexity), and enabling complex tasks involving 461 coordination among robots (that can be more easily performed if 462 robots are centrally controlled). 464 A simple example of the use of multiples robots is cleaning, 465 delivering of goods from warehouses to shops or video surveillance. 466 Multiple robots are simultaneously instructed to perform individual 467 tasks by moving the robotic intelligence from the robots to the 468 network's edge (e.g., data center). That enables easy 469 synchronization, scalable solution and on-demand option to create 470 flexible fleet of robots. 472 Robots would have various forms of wireless connectivity: 474 o IEEE 802.11: for connection to the edge and also inter-robot 475 communications (e.g., for coordinated actions); 477 o cellular: as an additional communication link to the edge, though 478 primarily as backup, since ultra low latencies are needed. 480 6.2. Specificities 482 Some of the use cases/tasks involving robots might benefit from 483 decomposition of a service in small functions that are distributed 484 and chained among robots and the edge. These require continuous 485 connectivity with the control center and among drones. 487 Robot control is an activity requiring very low latencies between the 488 robot and the location where the control intelligence resides (which 489 might be the edge or another robot). 491 6.3. The Need for Wireless 493 Deploying robots in scenarios such as shopping malls for the 494 aforementioned applications cannot be done via wired connectivity. 496 6.4. Asks for SPAWN 498 The network infrastructure needs to support heterogeneous types of 499 traffic, from robot control to video streaming. 501 When a given service is decomposed into functions -- hosted at 502 different robots -- chained, each link connecting two given functions 503 would have a well-defined set of requirements (latency, bandwith and 504 jitter) that have to be met. 506 7. IANA Considerations 508 TBD. 510 8. Security Considerations 512 TBD. 514 9. Informative References 516 [disney-VIP] 517 Wired, "Disney's $1 Billion Bet on a Magical Wristband", 518 March 2015, 519 . 521 [EIP] http://www.odva.org/, "EtherNet/IP provides users with the 522 network tools to deploy standard Ethernet technology (IEEE 523 802.3 combined with the TCP/IP Suite) for industrial 524 automation applications while enabling Internet and 525 enterprise connectivity data anytime, anywhere.", 526 . 530 [I-D.ietf-6tisch-architecture] 531 Thubert, P., "An Architecture for IPv6 over the TSCH mode 532 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 533 in progress), March 2019. 535 [I-D.ietf-detnet-architecture] 536 Finn, N., Thubert, P., Varga, B., and J. Farkas, 537 "Deterministic Networking Architecture", draft-ietf- 538 detnet-architecture-12 (work in progress), March 2019. 540 [I-D.ietf-detnet-problem-statement] 541 Finn, N. and P. Thubert, "Deterministic Networking Problem 542 Statement", draft-ietf-detnet-problem-statement-09 (work 543 in progress), December 2018. 545 [I-D.ietf-detnet-use-cases] 546 Grossman, E., "Deterministic Networking Use Cases", draft- 547 ietf-detnet-use-cases-20 (work in progress), December 548 2018. 550 [IEEE802.1TSN] 551 IEEE standard for Information Technology, "IEEE 552 802.1AS-2011 - IEEE Standard for Local and Metropolitan 553 Area Networks - Timing and Synchronization for Time- 554 Sensitive Applications in Bridged Local Area Networks". 556 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 557 . 559 [ODVA] http://www.odva.org/, "The organization that supports 560 network technologies built on the Common Industrial 561 Protocol (CIP) including EtherNet/IP.". 563 [Profinet] 564 http://us.profinet.com/technology/profinet/, "PROFINET is 565 a standard for industrial networking in automation.", 566 . 568 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 569 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 570 Internet of Things (IoT): Problem Statement", RFC 7554, 571 DOI 10.17487/RFC7554, May 2015, 572 . 574 Authors' Addresses 576 Georgios Z. Papadopoulos 577 IMT Atlantique 578 Office B00 - 114A 579 2 Rue de la Chataigneraie 580 Cesson-Sevigne - Rennes 35510 581 FRANCE 583 Phone: +33 299 12 70 04 584 Email: georgios.papadopoulos@imt-atlantique.fr 586 Pascal Thubert 587 Cisco Systems, Inc 588 Building D 589 45 Allee des Ormes - BP1200 590 MOUGINS - Sophia Antipolis 06254 591 FRANCE 593 Phone: +33 497 23 26 34 594 Email: pthubert@cisco.com 596 Fabrice Theoleyre 597 CNRS 598 Office B-270 599 Boulevard Sebastien Brant 600 Illkirch 67400 601 FRANCE 603 Phone: +33 368 85 45 33 604 Email: theoleyre@unistra.fr 605 Carlos J. Bernardos 606 Universidad Carlos III de Madrid 607 Av. Universidad, 30 608 Leganes, Madrid 28911 609 Spain 611 Phone: +34 91624 6236 612 Email: cjbc@it.uc3m.es 613 URI: http://www.it.uc3m.es/cjbc/