idnits 2.17.1 draft-petrov-lpwan-ipv6-schc-over-lorawan-02.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 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.) ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 388: '...request), the device MUST transmit the...' RFC 2119 keyword, line 400: '...ink. The device SHALL keep this ACK m...' RFC 2119 keyword, line 407: '...ent. The device SHALL keep this ABORT...' RFC 2119 keyword, line 429: '...est), the device MUST always transmit ...' RFC 2119 keyword, line 448: '... The device SHALL keep the all-1 ACK...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4944' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 506, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-16 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group N. Sornin, Ed. 3 Internet-Draft M. Coracin 4 Intended status: Informational Semtech 5 Expires: January 3, 2019 I. Petrov 6 Acklio 7 A. Yegin 8 Actility 9 J. Catalano 10 Kerlink 11 V. Audebert 12 EDF R&D 13 July 02, 2018 15 Static Context Header Compression (SCHC) over LoRaWAN 16 draft-petrov-lpwan-ipv6-schc-over-lorawan-02 18 Abstract 20 The Static Context Header Compression (SCHC) specification describes 21 generic header compression and fragmentation techniques for LPWAN 22 (Low Power Wide Area Networks) technologies. SCHC is a generic 23 mechanism designed for great flexibility, so that it can be adapted 24 for any of the LPWAN technologies. 26 This document provides the adaptation of SCHC for use in LoRaWAN 27 networks, and provides elements such as efficient parameterization 28 and modes of operation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 3, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Static Context Header Compression Overview . . . . . . . . . 3 67 4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Device classes (A, B, C) and interactions . . . . . . . . 5 69 4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 6 70 4.3. General Message Types . . . . . . . . . . . . . . . . . . 6 71 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 6 72 5. SCHC over LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Rule ID management . . . . . . . . . . . . . . . . . . . 6 74 5.2. IID computation . . . . . . . . . . . . . . . . . . . . . 6 75 5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 6 76 5.3.1. Reliability options . . . . . . . . . . . . . . . . . 6 77 5.3.2. Supporting multiple window sizes . . . . . . . . . . 11 78 5.3.3. Downlink fragment transmission . . . . . . . . . . . 11 79 5.3.4. SCHC behavior for devices in class A, B and C . . . . 11 80 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 86 Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 The Static Context Header Compression (SCHC) specification 92 [I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header 93 compression and fragmentation techniques that can be used on all 94 LPWAN (Low Power Wide Area Networks) technologies defined in 96 [I-D.ietf-lpwan-overview]. Even though those technologies share a 97 great number of common features like start-oriented topologies, 98 network architecture, devices with mostly quite predictable 99 communications, etc; they do have some slight differences in respect 100 of payload sizes, reactiveness, etc. 102 SCHC gives a generic framework that enables those devices to 103 communicate with other Internet networks. However, for efficient 104 performance, some parameters and modes of operation need to be set 105 appropriately for each of the LPWAN technologies. 107 This document describes the efficient parameters and modes of 108 operation when SCHC is used over LoRaWAN networks. 110 2. Terminology 112 This section defines the terminology and acronyms used in this 113 document. For all other definitions, please look up the SCHC 114 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 116 o DevEUI: an IEEE EUI-64 identifier used to identify the device 117 during the procedure while joining the network (Join Procedure) 119 o DevAddr: a 32-bit non-unique identifier assigned to a device 120 statically or dynamically after a Join Procedure (depending on the 121 activation mode) 123 o TBD: all significant LoRaWAN-related terms. 125 3. Static Context Header Compression Overview 127 This section contains a short overview of Static Context Header 128 Compression (SCHC). For a detailed description, refer to the full 129 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 131 Static Context Header Compression (SCHC) avoids context 132 synchronization, which is the most bandwidth-consuming operation in 133 other header compression mechanisms such as RoHC [RFC5795]. Based on 134 the fact that the nature of data flows is highly predictable in LPWAN 135 networks, some static contexts may be stored on the Device (Dev). 136 The contexts must be stored in both ends, and it can either be 137 learned by a provisioning protocol or by out of band means or it can 138 be pre-provisioned, etc. The way the context is learned on both 139 sides is out of the scope of this document. 141 Dev App 142 +--------------+ +--------------+ 143 |APP1 APP2 APP3| |APP1 APP2 APP3| 144 | | | | 145 | UDP | | UDP | 146 | IPv6 | | IPv6 | 147 | | | | 148 | SCHC C/D | | | 149 | (context) | | | 150 +-------+------+ +-------+------+ 151 | +--+ +----+ +---------+ . 152 +~~ |RG| === |NGW | === |SCHC C/D |... Internet .. 153 +--+ +----+ |(context)| 154 +---------+ 156 Figure 1: Architecture 158 Figure 1 represents the architecture for compression/decompression, 159 it is based on [I-D.ietf-lpwan-overview] terminology. The Device is 160 sending applications flows using IPv6 or IPv6/UDP protocols. These 161 flows are compressed by an Static Context Header Compression 162 Compressor/Decompressor (SCHC C/D) to reduce headers size. Resulting 163 information is sent on a layer two (L2) frame to a LPWAN Radio 164 Network (RG) which forwards the frame to a Network Gateway (NGW). 165 The NGW sends the data to a SCHC C/D for decompression which shares 166 the same rules with the Dev. The SCHC C/D can be located on the 167 Network Gateway (NGW) or in another place as long as a tunnel is 168 established between the NGW and the SCHC C/D. The SCHC C/D in both 169 sides must share the same set of Rules. After decompression, the 170 packet can be sent on the Internet to one or several LPWAN 171 Application Servers (App). 173 The SCHC C/D process is bidirectional, so the same principles can be 174 applied in the other direction. 176 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 177 Server, and the SCHC C/D can be embedded in different places, for 178 example in the Network Server and/or the Application Server. 180 Next steps for this section: detailed overview of the LoRaWAN 181 architecture and its mapping to the SCHC architecture. 183 4. LoRaWAN Architecture 185 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 186 is described in [I-D.ietf-lpwan-overview]. Mapping between the LPWAN 187 architecture entities as described in 189 [I-D.ietf-lpwan-ipv6-static-context-hc] and the ones in 190 [lora-alliance-spec] is as follows: 192 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 193 actuators, etc.). There can be a very high density of devices per 194 radio gateway. This entity maps to the LoRaWAN End-device. 196 o The Radio Gateway (RGW), which is the end point of the constrained 197 link. This entity maps to the LoRaWAN Gateway. 199 o The Network Gateway (NGW) is the interconnection node between the 200 Radio Gateway and the Internet. This entity maps to the LoRaWAN 201 Network Server. 203 o LPWAN-AAA Server, which controls the user authentication and the 204 applications. This entity maps to the LoRaWAN Join Server. 206 o Application Server (App). The same terminology is used in LoRaWAN. 208 () () () | +------+ 209 () () () () / \ +---------+ | Join | 210 () () () () () / \======| ^ |===|Server| +-----------+ 211 () () () | | <--|--> | +------+ |Application| 212 () () () () / \==========| v |=============| Server | 213 () () () / \ +---------+ +-----------+ 214 End-Devices Gateways Network Server 216 Figure 1: LPWAN/LoRaWAN Architecture 218 SCHC C/D (Compressor/Decompressor) and SCHC Fragmentation are 219 performed on the LoRaWAN End-device and the Application Server. 220 While the point-to-point link between the End-device and the 221 Application Server constitutes single IP hop, the ultimate end-point 222 of the IP communication may be an Internet node beyond the 223 Application Server. In other words, the LoRaWAN Application Server 224 acts as the first hop IP router for the End-device. Note that the 225 Application Server and Network Server may be co-located, which 226 effectively turns the Network/Application Server into the first hop 227 IP router. 229 4.1. Device classes (A, B, C) and interactions 231 TBD 233 4.2. Device addressing 235 TBD 237 4.3. General Message Types 239 TBD 241 4.4. LoRaWAN MAC Frames 243 TBD 245 5. SCHC over LoRaWAN 247 5.1. Rule ID management 249 Rule ID can be stored and transported in the FPort field of the 250 LoRaWAN MAC frame or as the first bytes of the payload. 252 TBD 254 5.2. IID computation 256 TBD 258 5.3. Fragmentation 260 TBD 262 5.3.1. Reliability options 264 5.3.1.1. Uplinks: From device to gateway 266 In that case the device is the fragmentation transmitter, and the 267 SCHC gateway the fragmentation receiver. 269 o SCHC fragmentation reliability mode : "ACK_ALWAYS" 271 o Window size: 8, the FCN field is encoded on 3 bits 273 o DTag : 1bit. this field is used to clearly separate two 274 consecutive fragmentation sessions. A LoRaWAN device cannot 275 interleave several fragmented SCHC datagrams. 277 o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the 278 reverse representation of the polynomial used e.g. in the Ethernet 279 standard [RFC3385]) 281 o Retransmission Timer and inactivity Timer: LoRaWAN devices do not 282 implement a "retransmission timer". At the end of a window the 283 ACK corresponding to this window is transmitted by the network 284 gateway in the RX1 or RX2 receive slot of the device. If this ACK 285 is not received the device sends an all-0 (or an all-1) fragment 286 with no payload to request an ACK retransmission. The periodicity 287 between retransmission of the all-0/all-1 fragments is device/ 288 application specific and may be different for each device (not 289 specified). The gateway implements an "inactivity timer". The 290 default recommended duration of this timer is 12h. This value is 291 mainly driven by application requirements and may be changed. 293 | RuleID | DTag | W | FCN | Payload | 294 + ------ + ----- + ----- | ------ + ------- + 295 | 3 bits | 1 bit | 1 bit | 3 bits | | 297 Figure 2: All fragment except the last one. Header size is 8 bits. 299 | RuleID | DTag | W | FCN | MIC | Payload | 300 + ------ + ----- + ----- | ------ + ------- + ------- + 301 | 3 bits | 1 bit | 1 bit | 3 bits | 32 bits | | 303 Figure 3: All-1 fragment detailed format for the last fragment. 304 Header size is 8 bits. 306 The format of an all-0 or all-1 acknowledge is: 308 | RuleID | DTag | W | Encoded bitmap | Padding (0s) | 309 + ------ + ----- + ----- | -------------- + ------------ + 310 | 3 bits | 1 bit | 1 bit | up to 8 bits | 0 to 3 bits | 312 Figure 4: ACK format for All-0 windows. Header size is 1 or 2 bytes. 314 | RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) | 315 + ------ + ----- + ----- + ----- + ------------------------- + ------------ + 316 | 3 bits | 1 bit | 1 bit | 1 bit | up to 8 bits | 0 to 2 bits | 318 Figure 5: ACK format for All-1 windows. Header size is 1 or 2 bytes. 320 5.3.1.2. Downlinks: From gateway to device 322 In that case the device is the fragmentation receiver, and the SCHC 323 gateway the fragmentation transmitter. The following fields are 324 common to all devices. 326 o SCHC fragmentation reliability mode : ACK_ALWAYS 328 o Window size : 1 , The FCN field is encoded on 1 bits 330 o DTag : 1bit. This field is used to clearly separate two 331 consecutive fragmentation sessions. A LoRaWAN device cannot 332 interleave several fragmented SCHC datagrams. 334 o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the 335 reverse representation of the polynomial used e.g. in the Ethernet 336 standard [RFC3385]) 338 o MAX_ACK_REQUESTS : 8 340 | RuleID | DTag | W | FCN | Payload | Padding | 341 + ------ + ----- + ----- | ------ + ------- + ------- + 342 | 3 bits | 1 bit | 1 bit | 1 bits | X bytes | 2 bits | 344 Figure 6: All fragments but the last one. Header size is 6 bits. 346 | RuleID | DTag | W | FCN | MIC | Payload | Padding | 347 + ------ + ----- + ----- | ------ + ------- + ------- + ------- + 348 | 3 bits | 1 bit | 1 bit | 1 bits | 32 bits | X bytes | 2 bits | 350 Figure 7: All-1 Fragment Detailed Format for the Last Fragment. 351 Header size is 6 bits. 353 The format of an all-0 or all-1 acknowledge is: 355 | RuleID | DTag | W | Encoded bitmap | Padding (0s) | 356 + ------ + ----- + ----- | -------------- + ------------ + 357 | 3 bits | 1 bit | 1 bit | 1 bit | 2 bits | 359 Figure 8: ACK format for All-0 windows. Header size is 8 bits. 361 | RuleID | DTag | W | C = 1 | Padding (0s) | 362 + ------ + ----- + ----- + ----- + ------------ + 363 | 3 bits | 1 bit | 1 bit | 1 bit | 2 bits | 365 Figure 9: ACK format for All-1 windows, MIC is correct. Header size 366 is 8 bits. 368 | RuleID | DTag | W | b'111 | 0xFF (all 1's) | 369 + ------ + ----- + ----- + ------ + -------------- + 370 | 3 bits | 1 bit | 1 bit | 3 bits | 8 bits | 372 Figure 10: Receiver ABORT packet (following an all-1 packet with 373 incorrect MIC). Header size is 16 bits. 375 Class A and classB&C device do not manage retransmissions and timers 376 in the same way. 378 5.3.1.2.1. Class A devices 380 Class A devices can only receive in an RX slot following the 381 transmission of an uplink. Therefore there cannot be a concept of 382 "retransmission timer" for a gateway talking to classA devices for 383 downlink fragmentation. 385 The device replies with an ACK fragment to every single fragment 386 received from the gateway (because the window size is 1). Following 387 the reception of a FCN=0 fragment (fragment that is not the last 388 fragment of the packet or ACK-request), the device MUST transmit the 389 ACK fragment until it receives the fragment of the next window. The 390 device shall transmit up to MAX_ACK_REQUESTS ACK fragments before 391 aborting. The device should transmit those ACK as soon as possible 392 while taking into consideration eventual local radio regulation on 393 duty-cycle, to progress the fragmentation session as quickly as 394 possible. The ACK bitmap is 1 bit long and is always 1. 396 Following the reception of a FCN=1 fragment (the last fragment of a 397 datagram) and if the MIC is correct, the device shall transmit the 398 ACK with the "MIC is correct" indicator bit set. This message might 399 be lost therefore the gateway may request a retransmission of this 400 ACK in the next downlink. The device SHALL keep this ACK message in 401 memory until it receives a downlink from the gateway different from 402 an ACK-request indicating that the gateway has received the ACK 403 message. 405 Following the reception of a FCN=1 fragment (the last fragment of a 406 datagram) and if the MIC is NOT correct, the device shall transmit a 407 receiver-ABORT fragment. The device SHALL keep this ABORT message in 408 memory until it receives a downlink from the gateway different from 409 an ACK-request indicating that the gateway has received the ABORT 410 message. The fragmentation receiver (device) does not implement 411 retransmission timer and inactivity timer. 413 The fragmentation sender (the gateway) implements an inactivity timer 414 with default duration 12 hours. Once a fragmentation session is 415 started, if the gateway has not received any ACK or receiver-ABORT 416 message 12 hours fater the last message from the device was received, 417 the gateway may flush the fragmentation context. For devices with 418 very low transmission rates (example 1 packet a day in normal 419 operation) , that duration may be extended, but this is application 420 specific. 422 5.3.1.3. Class B or C devices 424 Class B&C devices can receive in scheduled RX slots or in RX slots 425 following the transmission of an uplink. The device replies with an 426 ACK fragment to every single fragment received from the gateway 427 (because the window size is 1). Following the reception of a FCN=0 428 fragment (fragment that is not the last fragment of the packet or 429 ACK-request), the device MUST always transmit the corresponding ACK 430 fragment even if that fragment has already been received. The ACK 431 bitmap is 1 bit long and is always 1. If the gateway receives this 432 ACK, it proceeds to send the next window fragment If the 433 retransmission timer elapses and the gateway has not received the ACK 434 of the current window it retransmits the last fragment. The gateway 435 tries retransmitting up to MAX_ACK_REQUESTS times before aborting. 437 Following the reception of a FCN=1 fragment (the last fragment of a 438 datagram) and if the MIC is correct, the device shall transmit the 439 ACK with the "MIC is correct" indicator bit set. If the gateway 440 receives this ACK, the current fragmentation session has succeeded 441 and its context can be cleared. 443 If the retransmission timer elapses and the gateway has not received 444 the all-1 ACK it retransmits the last fragment with the payload (not 445 an ACK-request without payload). The gateway tries retransmitting up 446 to MAX_ACK_REQUESTS times before aborting. 448 The device SHALL keep the all-1 ACK message in memory until it 449 receives a downlink from the gateway different from the last (FCN=1) 450 fragment indicating that the gateway has received the ACK message. 451 Following the reception of a FCN=1 fragment (the last fragment of a 452 datagram) and if the MIC is NOT correct, the device shall transmit a 453 receiver-ABORT fragment. The retransmission timer is used by the 454 gateway (the sender), the optimal value is very much application 455 specific but here are some recommended default values. For classB 456 devices, this timer trigger is a function of the periodicity of the 457 classB ping slots. The recommended value is equal to 3 times the 458 classB ping slot periodicity. (modify 128sec) For classC devices 459 which are nearly constantly receiving, the recommended value is 30 460 seconds. This means that the device shall try to transmit the ACK 461 within 30 seconds of the reception of each fragment. The inactivity 462 timer is implemented by the device to flush the context in-case it 463 receives nothing from the gateway over an extended period of time. 464 The recommended value is 12 hours for both classB&C devices. 466 5.3.2. Supporting multiple window sizes 468 TBD 470 5.3.3. Downlink fragment transmission 472 TBD 474 5.3.4. SCHC behavior for devices in class A, B and C 476 TBD 478 6. Security considerations 480 TBD 482 7. Acknowledgements 484 TBD 486 8. References 488 8.1. Normative References 490 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 491 "Internet Protocol Small Computer System Interface (iSCSI) 492 Cyclic Redundancy Check (CRC)/Checksum Considerations", 493 RFC 3385, DOI 10.17487/RFC3385, September 2002, 494 . 496 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 497 "Transmission of IPv6 Packets over IEEE 802.15.4 498 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 499 . 501 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 502 Header Compression (ROHC) Framework", RFC 5795, 503 DOI 10.17487/RFC5795, March 2010, 504 . 506 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 507 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 508 February 2014, . 510 8.2. Informative References 512 [I-D.ietf-lpwan-ipv6-static-context-hc] 513 Minaburo, A., Toutain, L., Gomez, C., and D. Barthel, 514 "LPWAN Static Context Header Compression (SCHC) and 515 fragmentation for IPv6 and UDP", draft-ietf-lpwan-ipv6- 516 static-context-hc-16 (work in progress), June 2018. 518 [I-D.ietf-lpwan-overview] 519 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 520 overview-10 (work in progress), February 2018. 522 [lora-alliance-spec] 523 Alliance, L., "LoRaWAN Specification Version V1.0.2", 524 . 528 Appendix A. Examples 530 Appendix B. Note 532 Authors' Addresses 534 Nicolas Sornin (editor) 535 Semtech 536 14 Chemin des Clos 537 Meylan 538 France 540 Email: nsornin@semtech.com 541 Michael Coracin 542 Semtech 543 14 Chemin des Clos 544 Meylan 545 France 547 Email: mcoracin@semtech.com 549 Ivaylo Petrov 550 Acklio 551 2bis rue de la Chataigneraie 552 35510 Cesson-Sevigne Cedex 553 France 555 Email: ivaylo@ackl.io 557 Alper Yegin 558 Actility 559 . 560 Paris, Paris 561 France 563 Email: alper.yegin@actility.com 565 Julien Catalano 566 Kerlink 567 1 rue Jacqueline Auriol 568 35235 Thorigne-Fouillard 569 France 571 Email: j.catalano@kerlink.fr 573 Vincent AUDEBERT 574 EDF R&D 575 7 bd Gaspard Monge 576 91120 PALAISEAU 577 FRANCE 579 Email: vincent.audebert@edf.fr