idnits 2.17.1 draft-irtf-nwcrg-network-coding-taxonomy-03.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 == Line 214 has weird spacing: '...symbols repa...' == Line 219 has weird spacing: '... packet rep...' -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NWCRG B. Adamson 3 Internet-Draft NRL 4 Intended status: Informational C. Adjih 5 Expires: December 31, 2017 INRIA 6 J. Bilbao 7 Ikerlan 8 V. Firoiu 9 BAE Systems 10 F. Fitzek 11 TU Dresden 12 S. Ghanem 13 Independant 14 E. Lochin 15 ISAE - Supaero 16 A. Masucci 17 Orange 18 M-J. Montpetit 19 Independant 20 M. Pedersen 21 Aalborg University 22 G. Peralta 23 Ikerlan 24 V. Roca, Ed. 25 INRIA 26 P. Saxena 27 AnsuR Technologies 28 S. Sivakumar 29 Cisco 30 June 29, 2017 32 Network Coding Taxonomy 33 draft-irtf-nwcrg-network-coding-taxonomy-03 35 Abstract 37 This document summarizes a recommended terminology for Network Coding 38 concepts and constructs. It provides a comprehensive set of terms in 39 order to avoid ambiguities in future Network Coding IRTF and IETF 40 documents. This document is intended to be in-line with the 41 terminology used by the RFCs produced by the Reliable Multicast 42 Transport (RMT) and FEC Framework (FECFRAME) IETF working groups. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on December 31, 2017. 61 Copyright Notice 63 Copyright (c) 2017 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 80 2. General definitions and concepts . . . . . . . . . . . . . . 4 81 3. Taxonomy of Code Uses . . . . . . . . . . . . . . . . . . . . 6 82 4. Coding Details . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.1. Coding Types . . . . . . . . . . . . . . . . . . . . . . 8 84 4.2. Coding Basics . . . . . . . . . . . . . . . . . . . . . . 9 85 4.3. Coding In Practice . . . . . . . . . . . . . . . . . . . 11 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 90 7.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Appendix A. Additional references . . . . . . . . . . . . . . . 13 92 Appendix B. Authors and Contributors . . . . . . . . . . . . . . 13 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 The literature on Network Coding research and system design, IETF 98 included, led to a rich set of concepts and constructs. This 99 document collects terminology used in the domain, both outside and 100 inside IETF, provides concise definitions, and introduces a high 101 level taxonomy. Its primary goal is to be useful to IETF and IRTF 102 activities. It is also intended to be in-line with the terminology 103 already used by the RFCs produced by the Reliable Multicast Transport 104 (RMT) and FEC Framework (FECFRAME) IETF working groups, in particular 105 [RFC5052] [RFC6726] [RFC5775] [RFC5740] [RFC6363]. 107 This document only focuses on packet transmissions and packet losses, 108 for instance because of congested routers, routing issues, 109 intermittent connectivity (e.g., a mobile terminal can suddenly go 110 behind an obstacle) and wireless communication issues. 111 Communications may happen in various types of networks, physical 112 links, UDP services, overlay networks or even virtual networks. The 113 notion of packet itself is multiform, depending on the target use- 114 case and the notion of network (e.g., in which layer of the protocol 115 stack). For instance, a packet may be a UDP datagram because coding 116 happens within a dedicated transport protocol on top of UDP. 118 This document does not try to be exhaustive: it is voluntarily kept 119 as simple as possible. 121 This document does not consider physical layer transmission issues, 122 nor physical layer codes, nor error detection: if low layer error 123 codes detect but fail to correct bit errors, or if an upper layer 124 checksum (e.g., within IP or UDP) identifies a corrupted packet, then 125 this packet is supposed to be dropped. 127 This document IS NOT restricted to constructs that perform re-coding 128 within intermediate coding forwarding nodes. If network coding 129 (i.e., re-coding within the network) is of course considered, this 130 document has a broader scope. 132 In the following definitions, the "(IETF)" tag indicates that the 133 associated term is already used in IETF documents. 135 1.1. Requirements Language 137 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 2. General definitions and concepts 143 This section gathers general definitions and concepts that are used 144 throughout this document. 146 Packet Erasure Channel: A communication path where packets are 147 either dropped or received without any error. This type of 148 packet drop is referred to as an "erasure" or "loss". The 149 term "channel" must be understood as a generic term for any 150 type of communication facility. The "Erasure" channels are 151 opposed to "Error" channels that are out of scope. 153 Erasure Correcting Code (ECC), or (IETF) Forward Erasure Code (FEC): 155 A code for the Packet Erasure Channel (only). These 156 codes are also called "Application-Level FEC" to 157 highlight that they have been designed to be used within 158 the higher layers of the protocol stack, to protect 159 against packet losses. These codes are opposed to 160 "Error" correction codes that address errors and are out 161 of scope. 163 Original Payload, or Uncoded Payload, or Systematic Symbol, or 164 (IETF) Source Symbol: 165 A unit of data originating from the source that is used 166 as input to encoding operations. When there is a single 167 Source Symbol per Source Packet, an Original Payload 168 corresponds to a Source Packet. 170 Coded Payload, Coded Symbol, or (IETF) Repair Symbol: A unit of 171 data that is the result of a coding operation, applied 172 either to Source Symbols or (in case of recoding) Source 173 and/or Repair Symbols. When there is a single Repair 174 Symbol per Repair Packet, a Coded Payload corresponds to 175 a Repair Packet. 177 Input Symbol and Output Symbol: A unit of data that is used as 178 input to an encoding operation or that is generated as 179 output of an encoding operation. At a re-coding node, 180 Repair Symbols are also part of the Input Symbols. With 181 Systematic Coding, Source Symbols are also part of the 182 Output Symbols. 184 (IETF) Encoding Symbol: A Source or a Repair Symbol. 186 (IETF) Source Packet: A packet originating from the source 187 which contributes to one or more Source Symbols. For 188 instance, an RTP packet as a whole can constitute a 189 Source Symbol. In other situations (e.g, to address 190 variable size packets) a single RTP packet may 191 contribute to various Source Symbols. 193 (IETF) Repair Packet: A packet containing one or more Repair 194 Symbols. 196 Figure 1 illustrates the relationships between packets (what is sent 197 in the Packet Erasure Channel) and symbols (what is manipulated 198 during encoding and decoding operations) in case of FEC encoding, at 199 a Coding Node. A similar figure could be done for FEC decoding. 201 source packet 202 | 203 | source packet to source symbols transform 204 | (one or more symbols per packet) 205 v 206 source symbols 207 | 208 v input symbols 209 +----------------------+ 210 | FEC encoding | 211 +----------------------+ 212 | output symbols | 213 v v 214 source symbols repair symbols 215 | | 216 | | symbol to packet transform 217 | | (one or more symbols per packet) 218 v v 219 source packet repair packet 221 Figure 1: Packet and symbol relationships at a Coding Node. 223 Source Node: A node that generates one or more Source Flows. 225 Coding Node: A node that performs FEC encoding operations. It may 226 be an end-host, a middlebox, or a forwarding node. 228 (IETF) Flow: A stream of packets logically grouped. 230 (IETF) Source Flow: A flow of Source Packets coming from an 231 application on a given host, and to which FEC encoding is to 232 be applied, potentially along with other Source Flows. 233 Depending on the use case, Source Flows may come from the 234 same application, from different applications on the same 235 host, or from different applications on different hosts. 237 (IETF) Repair flow: A flow containing Repair Packets, after FEC 238 encoding. 240 3. Taxonomy of Code Uses 242 This section discusses the various ways of using coding, without 243 going into coding details. 245 Source Coding versus Channel Coding: (see Fig. Figure 2) When both 246 terms are opposed, "Source Coding" usually refers to 247 compression techniques (e.g., audio and video compression) 248 within the upper application that generates the source flow. 249 On the opposite, "Channel Coding" refers to FEC encoding in 250 order to improve transmission robustness, initially within 251 the lower physical layer, potentially also encompassing the 252 upper layers. These terms should not be confused with 253 respectively "FEC coding within the Source Node" and "FEC re- 254 coding within an intermediate Coding Node". 256 raw data flow from camera ^ video flow display 257 | | ^ 258 v | upper | 259 +-----------------------+ | +-----------------------+ 260 | source coding | | applica- | source (de)coding | 261 |(e.g. mpeg compression)| | tion |(eg. mpg decompression)| 262 +-----------------------+ v +-----------------------+ 263 | ^ 264 v | 265 +-----------------------+ ^ +-----------------------+ 266 | network/AL-FEC coding | | middle- | network/AL-FEC coding | 267 | (e.g. RLC encoding) | | ware | (e.g. RLC decoding) | 268 +-----------------------+ v +-----------------------+ 269 | ^ 270 v | 271 +-----------------------+ ^ +-----------------------+ 272 | packetization | | | depacketization | 273 | (e.g. UDP/IP) | | communi- | (e.g. UDP/IP) | 274 +-----------------------+ | cation +-----------------------+ 275 | | ^ 276 v | layers | 277 +-----------------------+ | +-----------------------+ 278 | PHY layer | | | PHY layer | 279 | (channel coding) | | | (channel decoding) | 280 +-----------------------+ v +-----------------------+ 281 | ^ 282 | source + repair traffic | 283 +-------------------------------------------+ 285 Figure 2: Example of end-to-end flow manipulation with Network Coding 286 between the application and UDP layers (as with RMT or FECFRAME 287 architectures). Other architectures are possible, for instance with 288 network coding below the transport layer in order to allow re-coding 289 within the network. 291 End-to-End Coding: A system where coding is performed at the source 292 or (coding) middlebox, and decoding at the destination(s) or 293 (decoding) middlebox. There is no re-coding operation at 294 intermediate nodes. This is the approach followed in the 295 FLUTE/ALC [RFC6726][RFC5775], NORM [RFC5740] and FECFRAME 296 [RFC6363] protocols. 298 Network Coding: A system where coding can be performed at the source 299 as well as at intermediate forwarding nodes (all or a subset 300 of them). End-to-End Coding can be regarded as a special 301 case of Network Coding. Depending on the use case, 302 additional assumptions can be made: for instance the 303 knowledge by the destination of the coding node topology and 304 coding operations can help during decoding operations. 306 Intra-Flow Coding, or Single Source Network Coding: Process where 307 incoming packets to the Coding Node belong to the same flow. 309 Inter-Flow Coding, or Multi-Source Network Coding: Process where 310 incoming packets to the Coding Node belong to different 311 flows. 313 Single-Path Coding: Network Coding over a route that has a single 314 path from the source to each destination(s). In case of 315 multicast or broadcast traffic, this route is a tree. Coding 316 may be done end-to-end and/or at intermediate forwarding 317 nodes. 319 Multi-Path Coding: Network Coding over a route that has multiple (at 320 least partially) disjoint paths from the source to each given 321 destination. Coding may be done end-to-end and/or at 322 intermediate forwarding nodes. 324 4. Coding Details 326 4.1. Coding Types 328 This section provides a high level taxonomy of coding techniques. 329 Technical details are left for the following sections. 331 Linear Coding: Linear combination of a set of input symbols (i.e., 332 Source and/or Repair Symbols) using a given set of 333 coefficients and resulting in a Repair Symbol. Many linear 334 codes exist that differ from the way coding coefficients are 335 drawn from a Finite Field of a given size. 337 Random Linear Coding (RLC): Particular case of Linear Coding using a 338 set of random coding coefficients. 340 Adaptive Linear Coding: Linear Coding that utilizes cross layer 341 adaptation. For instance, an adaptive coding scheme may 342 adapt the generation and transmission of Repair Packets 343 according to the channel variations over time, accounting for 344 the predictive loss of degrees of freedom due to erasures. 346 Block Coding: Coding technique where the input Flow(s) must be first 347 segmented into a sequence of blocks, FEC encoding and 348 decoding being performed independently on a per-block basis. 349 The term "Chunk Coding" is sometimes used, where a "Chunk" 350 denotes a block. 352 Sliding Window Coding, or Convolutional Coding: General class of 353 coding techniques that rely on a sliding encoding window. 354 This is an alternative solution to Block Coding. 356 Fixed or Elastic Sliding Window Coding: Coding technique that 357 generates Repair Symbol(s) on-the-fly, from the set of Source 358 Symbols present in the sliding encoding window at that time, 359 usually by using Linear Coding. The sliding window may be 360 either of fixed size or of variable size over the time (also 361 known as "elastic sliding window"). For instance this size 362 may depend on acknowledgments sent by the receiver(s) for a 363 particular Source Symbol or Source Packet (received, decoded, 364 or decodable). 366 Systematic Coding: A coding technique where Source Symbols are part 367 of the output Flow generated by a Coding Node. 369 Rateless and Non-Rateless Coding: Rateless Coding can potentially 370 generate an infinite number of Repair Symbols (in practice 371 this number is only extremely large) from a given set of 372 Source Symbols (meaning that their code rate is null). RLC 373 codes are an example of Rateless Codes. Non-Rateless Coding 374 usually have a predefined maximum number of Repair Symbols 375 that can be generated from a given set of Source Symbols. 377 4.2. Coding Basics 379 This section discusses and defines low level coding aspects. 381 Code Rate: In case of a Block Code, the Code Rate is the k/n ratio 382 between the number of Source Symbols, k, and the number of 383 Source plus Repair Symbols, n. With a Sliding Window Code, 384 the Code Rate is defined similarly over a certain time 385 interval, since the Code Rate may change dynamically. By 386 definition, the Code Rate is such that: 0 < Code Rate <= 1. 387 A Code Rate close to 1 indicates that a small number of 388 Repair Symbols have been produced during the encoding process 389 and vice-versa. 391 (En)coding Window: A set of Source (and Repair in the case of re- 392 coding) Symbols used as input to the coding operations. The 393 set of symbols will typically change over the time, as the 394 Coding Window slides over the input Flow(s). 396 (En)coding Window Size: The number of Source (and Repair in case of 397 re-coding) Symbols in the current Encoding Window. This size 398 may change over the time. 400 Payload Set: The set of Source and Repair Symbols available (i.e., 401 received or previously decoded) at the receiver and used 402 during FEC decoding operations. 404 Decoding window: The set of Source Symbols (only) that are 405 considered in the current linear system of a receiver, 406 independently of the fact these Source Symbols have been 407 received, decoded, or lost. The Decoding Window will 408 typically change over the time, as transmissions and decoding 409 progress, and may be different for different receivers of a 410 session where content is multicast or broadcast. 412 Decoding Window Size: The number of Source Symbols (only) in the 413 current Decoding Window. This size may change over the time. 415 Rank of a Payload Set, or (IETF) Rank of the Linear System: At a rec 416 eiver, number of linearly independent members of a Payload 417 Set, or equivalently the number of linearly independent 418 equations of the linear system. It is also known as "Degrees 419 of Freedom". The system may be of "full rank" and decoding 420 is possible, or "partial rank", and only partial decoding is 421 possible. 423 Seen Payload, or Seen Symbol: A Source Symbol is Seen when the 424 receiver can compute a linear combination with this symbol 425 and Source Symbols that are strictly more recent (i.e., with 426 logically higher Encoding Symbol Identifiers). Otherwise the 427 Source Symbol is considered as "unseen". 429 Generation, or (IETF) Block: With Block Codes, the set of Source 430 Symbols of the input Flow(s) that are logically grouped into 431 a Block, before doing encoding. 433 Generation Size, or Code Dimension, or (IETF) Block Size: With Block 434 Codes, the number k of Source Symbols belonging to a Block. 436 Coding Matrix, or Generator Matrix: A matrix G that transforms the 437 set of Input Symbols X into a set of Repair Symbols: Y = X * 438 G. Defining a Generator Matrix is usual with Block Codes. 439 The set of Input Symbols X can consist only of Source Symbols 440 (e.g., with End-to-End Coding) or can consist of Source and 441 Repair Symbols (e.g., with re-coding in an intermediate 442 node). 444 Coding Coefficient: With Linear Coding, this is a coefficient in a 445 certain Finite Field. This coefficient may be chosen in 446 different ways: randomly, or in a pre-defined table, or using 447 a pre-defined algorithm plus a seed. 449 Coding Vector: A set of Coding Coefficients used to generate a 450 certain Repair Symbol through Linear Coding. The number of 451 nonzero coefficients in the Coding Vector defines its 452 density. 454 Finite Field, or Galois Field, or Coding Field: Finite fields, used 455 in Linear Codes, have the desired property of having all 456 elements (except zero) invertible for + and * and all 457 operations over any elements do not result in an overflow or 458 underflow. Examples of Finite Fields are prime fields 459 {0..p^m-1}, where p is prime. Most used fields use p=2 and 460 are called binary extension fields {0..2^m-1}, where m often 461 equals 1, 4 or 8 for practical reasons. 463 Finite Field size, or Coding Field size: The number of elements in a 464 finite field. For example the binary extension field 465 {0..2^m-1} has size q=2^m. 467 Feedback: Feedback information sent by a decoding node to a Coding 468 Node (or from a receiver to a source in case of End-to-End 469 Coding). The nature of information contained in a feedback 470 packet varies, depending on the use-case. It can provide 471 reception and/or FEC decoding statistics, or the list of 472 available Source Packets received or decoded 473 (acknowledgement), or the list of lost Source Packets that 474 should be retransmitted (negative acknowledgement), or a 475 number of additional Repair Symbols needed to have a Full 476 Rank Linear System. 478 4.3. Coding In Practice 480 This section discusses practical aspects. Indeed, a practical 481 solution must specify the exact manner encoding and decoding is 482 performed but also all the peripheral aspects, for instance how an 483 encoder informs a decoder about the parameters used to generate a 484 certain Repair Packet (signaling). 486 (IETF) FEC Scheme: A specification that defines the additional 487 protocol aspects required to use a particular FEC code. In 488 particular the FEC Scheme defines in band (e.g., information 489 contained in Source and Repair Packet header or trailers) and 490 out of band (e.g., information contained in an SDP 491 description) signaling needed to synchronize encoders and 492 decoders. 494 Payload Indices, or (IETF) Encoding Symbol Identifiers (ESI): An ide 495 ntifier of a Source or Repair Symbol. If conceptually, each 496 symbol is identified by a unique ESI value, in practice, with 497 a continuous flow and a limited field size to hold the ESI, 498 wrapping to zero in unavoidable and the same integer value 499 will be re-used several times. 501 (IETF) FEC Payload ID: Information that identifies the contents of a 502 packet with respect to the FEC Scheme. The FEC Payload ID of 503 a packet containing Source Symbol(s) is usually different 504 from that of a packet containing Repair Symbol(s). The FEC 505 Payload ID typically contains at least an ESI. 507 Coding Vector and Encoding Window Signaling: With Sliding Window 508 Codes, the FEC Payload ID of a Repair Packet contains 509 information needed and sufficient to identify the Coding 510 Vector and Coding Window. Concerning the Coding Vector, this 511 may consist of a full list of Coding Coefficients (that may 512 be compressed or not), or a piece of information (e.g., a 513 seed) that can be used to generate the list of Coding 514 Coefficients thanks to a predefined algorithm known by 515 encoders and decoders (e.g., a Pseudo Random Number 516 Generator, or PRNG), or an ESI that points to a given entry 517 in a Generator Matrix in case of a Block Code. Concerning 518 the Coding Window, this may consist of the full list of ESI 519 of symbols in the Coding Window (that may be compressed or 520 not), or the ESI of the first Source Symbol along with their 521 number (assuming there is no gap). 523 5. IANA Considerations 525 This document is not subject to IANA registration. 527 6. Security Considerations 529 This document introduces a recommended terminology for network coding 530 and therefore does not contain any security consideration. This does 531 not mean that network coding systems do not have any security 532 implication. 534 7. References 536 7.1. Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, 540 DOI 10.17487/RFC2119, March 1997, 541 . 543 7.2. Informative References 545 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 546 Correction (FEC) Building Block", RFC 5052, 547 DOI 10.17487/RFC5052, August 2007, 548 . 550 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 551 "NACK-Oriented Reliable Multicast (NORM) Transport 552 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 553 . 555 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 556 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 557 DOI 10.17487/RFC5775, April 2010, 558 . 560 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 561 Correction (FEC) Framework", RFC 6363, 562 DOI 10.17487/RFC6363, October 2011, 563 . 565 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 566 "FLUTE - File Delivery over Unidirectional Transport", 567 RFC 6726, DOI 10.17487/RFC6726, November 2012, 568 . 570 Appendix A. Additional references 572 Additional references on network coding are available in the NWCRG 573 research web site: https://irtf.org/nwcrg 575 Appendix B. Authors and Contributors 577 This document is the result of a collaborative work that involved may 578 authors and contributors from the NWCRG IRTF research group. They 579 are listed below in alphabetical order in this document. 581 Authors' Addresses 583 Brian Adamson 584 NRL 585 USA 587 Email: brian.adamson@nrl.navy.mil 588 Cedric Adjih 589 INRIA 590 France 592 Email: cedric.adjih@inria.fr 594 Josu Bilbao 595 Ikerlan 596 Spain 598 Email: jbilbao@ikerlan.es 600 Victor Firoiu 601 BAE Systems 602 USA 604 Email: victor.firoiu@baesystems.com 606 Frank Fitzek 607 TU Dresden 608 Germany 610 Email: frank.fitzek@tu-dresden.de 612 Samah A. M. Ghanem 613 Independant 615 Email: samah.ghanem@gmail.com 617 Emmanuel Lochin 618 ISAE - Supaero 619 France 621 Email: emmanuel.lochin@isae-supaero.fr 623 Antonia Masucci 624 Orange 625 France 626 Marie-Jose Montpetit 627 Independant 628 USA 630 Email: marie@mjmontpetit.com 632 Morten V. Pedersen 633 Aalborg University 634 Denmark 636 Email: mvp@es.aau.dk 638 Goiuri Peralta 639 Ikerlan 640 Spain 642 Email: gperalta@ikerlan.es 644 Vincent Roca (editor) 645 INRIA 646 France 648 Email: vincent.roca@inria.fr 650 Paresh Saxena 651 AnsuR Technologies 652 Norway 654 Email: paresh.saxena@ansur.es 656 Senthil Sivakumar 657 Cisco 658 USA 660 Email: ssenthil@cisco.com