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