idnits 2.17.1 draft-ietf-mext-binary-ts-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (December 16, 2009) is 5245 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: A later version (-11) exists of draft-ietf-mext-flow-binding-04 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Tsirtsis 3 Internet-Draft G. Giarreta 4 Intended status: Standards Track Qualcomm 5 Expires: June 19, 2010 H. Soliman 6 Elevate Technologies 7 N. Montavont 8 IT/TB 9 December 16, 2009 11 Traffic Selectors for Flow Bindings 12 draft-ietf-mext-binary-ts-02.txt 14 Abstract 16 This document defines binary formats for IPv4 and IPv6 traffic 17 selectors to be used in conjunction with flow bindings for Mobile 18 IPv6. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 19, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Traffic Selector Sub-Options . . . . . . . . . . . . . . . . . 5 63 3.1. IPv4 binary traffic selector . . . . . . . . . . . . . . . 5 64 3.2. IPv6 binary traffic selector . . . . . . . . . . . . . . . 9 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 6. Aknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 This document defines binary formats for IPv4 and IPv6 Traffic 82 Selector sub-options as defined in [I-D.ietf-mext-flow-binding]. 84 The binary traffic selector format defined here, allows for efficient 85 identification of flow(s) based on well known fields in IPv4 86 [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP 87 [RFC0793] and UDP [RFC0768]. 89 3. Traffic Selector Sub-Options 91 [I-D.ietf-mext-flow-binding] defines the format for the traffic 92 selector sub-option. 94 The following values of the TS Format field, are defined in this 95 specification for binary traffic selectors. 97 TS Format: 99 1 IPv4 binary traffic selector 101 2 IPv6 binary traffic selector 103 3.1. IPv4 binary traffic selector 105 If the TS Format field of the traffic selector sub-option indicates 106 "IPv4 binary traffic selector", then the traffic selector is 107 formatted as shown below. 109 The alignment requirement for this sub-option is: 111 4n if A, B, C, D, E, or F is set 113 2n if G, H, I, or J is set 115 n if K, L, M, N is sett 116 0 1 2 3 117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |A|B|C|D|E|F|G|H|I|J|K|L|M|N| Reserved | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | (A)Start Source Address | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | (B)End Source Address | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | (C)Start Destination Address | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | (D)End Destination Address | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | (E)Start SPI | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | (F)End SPI | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | (G)Start Source port | (H)End Source port | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | (I)Start Destination port | (J)End Destination port | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | (K)Start DS | (L)End DS |(M)Start Prot. | (N) End Prot. | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: IPv4 binary traffic selector 144 Flags (A-N) 146 Each flag indicates whether the corresponding field is present in 147 the message 149 (A)Start Source Address 151 This field identifies the first source address, from the range of 152 32-bit IPv4 addresses to be matched, on data packets as seen by 153 the home agent. In other words this is one of the addresses of 154 the correspondent node. 156 (B)End Source Address 158 If more than one contiguous source address needs to be matched 159 then this field can be used to indicate the end value of a range 160 starting from the value of the Start Source Address field. This 161 field MUST NOT be included unless the Start Source Address field 162 is included. When this field is included the receiver will match 163 all of the addresses between fields (A) and (B), inclusive of (A) 164 and (B). 166 (C)Start Destination Address 168 This field identifies the first destination address, from the 169 range of 32-bit IPv4 addresses to be matched, on data packets as 170 seen by the home agent. In other words this is one of the 171 registered home addresses of the mobile node. 173 (D)End Destination Address 175 If more than one contiguous destination address needs to be 176 matched then this field can be used to indicate the end value of a 177 range starting from the value of the Start Destination Address 178 field. This field MUST NOT be included unless the Start 179 Destination Address field is included. When this field is 180 included the receiver will match all of the addresses between 181 fields (C) and (D), inclusive of (C) and (D). 183 (E)Start SPI - Security Parameter Index 185 This field identifies the first 32-bit SPI value, from the range 186 of SPI values to be matched, on data packets as seen by the home 187 agent. This field is defined in [RFC4303]. 189 (F)End SPI - Security Parameter Index 191 If more than one contiguous SPI values need to be matched then 192 this field can be used to indicate the end value of a range 193 starting from the value of the Start SPI field. This field MUST 194 NOT be included unless the Start SPI field is included. When this 195 field is included the receiver will match all of the SPI values 196 between fields (E) and (F), inclusive of (E) and (F). 198 (G)Start Source Port 200 This field identifies the first 16-bit source port number, from 201 the range of port numbers to be matched, on data packets as seen 202 by the home agent. This is from the range of port numbers defined 203 by IANA (http://www.iana.org/assignments/port-numbers) 205 (H)End Source Port 207 If more than one contiguous source port numbers need to be matched 208 then this field can be used to indicate the end value of a range 209 starting from the value of the Start Source Port field. This 210 field MUST NOT be included unless the Start Source Port field is 211 included. When this field is included the receiver will match all 212 of the port numbers between fields (G) and (H), inclusive of (G) 213 and (H). 215 (I)Start Destination Port 217 This field identifies the first 16-bit destination port number, 218 from the range of port numbers to be matched, on data packets as 219 seen by the home agent. 221 (J)End Destination Port 223 If more than one contiguous destination port numbers need to be 224 matched then this field can be used to indicate the end value of a 225 range starting from the value of the Start Destination Port field. 226 This field MUST NOT be included unless the Start Destination Port 227 field is included. When this field is included the receiver will 228 match all of the port numbers between fields (I) and (J), 229 inclusive of (I) and (J). 231 (K)Start DS - Differential Services 233 This field identifies the first differential services value, from 234 the range of differential services values to be matched, on data 235 packets as seen by the home agent. Note that this field is called 236 Type of Service field in [RFC0791]. [RFC3260] then clarified that 237 the field has been redefined as 6 bits DS field and 2 bits 238 reserved, later claimed by Explicit Congestion Notification (ECN) 239 [RFC3168]. For the purpose of this specification the DS field is 240 8 bits long, were the 6 most significant bits indicating the DS 241 field to be matched and the 2 least significant bits MUST be set 242 to 0 by the sender and ignored by the receiver. 244 (L)End DS - Differential Services 246 If more than one contiguous DS values need to be matched then this 247 field can be used to indicate the end value of a range starting 248 from the value of the Start DS field. This field MUST NOT be 249 included unless the Start DS field is included. When this field 250 is included, it MUST be coded the same way as defined for (K). 251 When this field is included the receiver will match all of the 252 values between fields (K) and (L), inclusive of (K) and (L). 254 (M)Start Protocol 256 This field identifies the first 8-bit protocol value, from the 257 range of protocol values to be matched, on data packets as seen by 258 the home agent. 260 (N)End Protocol 262 If more than one contiguous protocol values need to be matched 263 then this field can be used to indicate the end value of a range 264 starting from the value of the Start Protocol field. This field 265 MUST NOT be included unless the Start Protocol field is included. 266 When this field is included the receiver will match all of the 267 values between fields (M) and (N), inclusive of (M) and (N). 269 Reserved 271 Reserved for future use. These bits MUST be set to zero by the 272 sender and ignored by the receiver. 274 3.2. IPv6 binary traffic selector 276 If the TS Format field of the traffic selector sub-option indicates 277 "IPv6 binary traffic selector", then the traffic selector is 278 formatted as follows: 280 The alignment requirement for this sub-option is: 282 8n if A, B, C, or D is set 284 4n if E, F, G, or H is set 286 2n if I, J, K, or L is set 288 n if M, N, O, or P is set 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P| Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 + + 299 | | 300 + (A)Start Source Address + 301 | | 302 + + 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 + + 307 | | 308 + (B)End Source Address + 309 | | 310 + + 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 + + 315 | | 316 + (C)Start Destination Address + 317 | | 318 + + 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 + + 323 | | 324 + (D)End Destination Address + 325 | | 326 + + 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | (E)Start SPI | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | (F)End SPI | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | (G)Start Flow Label | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | (H)End Flow Label | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | (I)Start Source port | (J)End Source port | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | (K)Start Destination port | (L)End Destination port | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | (M)Start DS | (N)End DS | (O)Start NH | (P) End NH | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 2: IPv6 binary traffic selector 346 Flags (A-P) 348 Each flag indicates whether the corresponding field is present in 349 the message 351 (A)Start Source Address 352 This field identifies the first source address, from the range of 353 128-bit IPv6 addresses to be matched, on data packets as seen by 354 the home agent. In other words this is one of the addresses of 355 the correspondent node. 357 (B)End Source Address 359 If more than one contiguous source address needs to be matched 360 then this field can be used to indicate the end value of a range 361 starting from the value of the Start Source Address field. This 362 field MUST NOT be included unless the Start Source Address field 363 is included. When this field is included the receiver will match 364 all of the addresses between fields (A) and (B), inclusive of (A) 365 and (B). 367 (C)Start Destination Address 369 This field identifies the first destination address, from the 370 range of 128-bit IPv6 addresses to be matched, on data packets as 371 seen by the home agent. In other words this is one of the 372 registered home addresses of the mobile node. 374 (D)End Destination Address 376 If more than one contiguous destination address needs to be 377 matched then this field can be used to indicate the end value of a 378 range starting from the value of the Start Destination Address 379 field. This field MUST NOT be included unless the Start 380 Destination Address field is included. When this field is 381 included the receiver will match all of the addresses between 382 fields (C) and (D), inclusive of (C) and (D). 384 (E)Start SPI - Security Parameter Index 386 This field identifies the first 32-bit SPI value, from the range 387 of SPI values to be matched, on data packets as seen by the home 388 agent. This field is defined in [RFC4303]. 390 (F)End SPI - Security Parameter Index 392 If more than one contiguous SPI values need to be matched then 393 this field can be used to indicate the end value of a range 394 starting from the value of the Start SPI field. This field MUST 395 NOT be included unless the Start SPI field is included. When this 396 field is included the receiver will match all of the SPI values 397 between fields (E) and (F), inclusive of (E) and (F). 399 (G)Start Flow Label 400 This field identifies the first flow label value, from the range 401 of flow label values to be matched, on data packets as seen by the 402 home agent. According to [RFC2460] the flow label is 24-bit long. 403 For the purpose of this specification the sender of this option 404 MUST prefix the flow label value with 8-bits of "0" before 405 inserting it in this field. The receiver SHOULD ignore the first 406 8-bits of this field. 408 (H)End Flow Label 410 If more than one contiguous flow label values need to be matched 411 then this field can be used to indicate the end value of a range 412 starting from the value of the Start Flow Label field. This field 413 MUST NOT be included unless the Start Flow Label field is 414 included. When this field is included the receiver will match all 415 of the flow label values between fields (G) and (H), inclusive of 416 (G) and (H). 418 (I)Start Source Port 420 This field identifies the first 16-bit source port number, from 421 the range of port numbers to be matched, on data packets as seen 422 by the home agent. 424 (J)End Source Port 426 If more than one contiguous source port numbers need to be matched 427 then this field can be used to indicate the end value of a range 428 starting from the value of the Start Source Port field. This 429 field MUST NOT be included unless the Start Source Port field is 430 included. When this field is included the receiver will match all 431 of the port numbers between fields (I) and (J), inclusive of (I) 432 and (J). 434 (K)Start Destination Port 436 This field identifies the first 16-bit destination port number, 437 from the range of port numbers to be matched, on data packets as 438 seen by the home agent. 440 (L)End Destination Port 442 If more than one contiguous destination port numbers need to be 443 matched then this field can be used to indicate the end value of a 444 range starting from the value of the Start Destination Port field. 445 This field MUST NOT be included unless the Start Destination Port 446 field is included. When this field is included the receiver will 447 match all of the port numbers between fields (K) and (L), 448 inclusive of (K) and (L). 450 (M)Start DS - Differential Services 452 This field identifies the first differential services value, from 453 the range of differential services values to be matched, on data 454 packets as seen by the home agent. Note that this field is called 455 Type of Service field in [RFC0791]. [RFC3260] then clarified that 456 the field has been redefined as 6 bits DS field and 2 bits 457 reserved, later claimed by Explicit Congestion Notification (ECN) 458 [RFC3168]. For the purpose of this specification the DS field is 459 8 bits long, were the 6 most significant bits indicating the DS 460 field to be matched and the 2 least significant bits MUST be set 461 to 0 by the sender and ignored by the receiver. 463 (N)End DS - Differential Services 465 If more than one contiguous DS values need to be matched then this 466 field can be used to indicate the end value of a range starting 467 from the value of the Start DS field. This field MUST NOT be 468 included unless the Start DS field is included. When this field 469 is included, it MUST be coded the same way as defined for (M). 470 When this field is included the receiver will match all of the 471 values between fields (M) and (N), inclusive of (M) and (N). 473 (O)Start NH - Next Header 475 This field identifies the first 8-bit next header value, from the 476 range of next header values to be matched, on data packets as seen 477 by the home agent. 479 (P)End NH - Next Header 481 If more than one contiguous next header values need to be matched 482 then this field can be used to indicate the end value of a range 483 starting from the value of the Start NH field. This field MUST 484 NOT be included unless the Start next header field is included. 485 When this field is included the receiver will match all of the 486 values between fields (O) and (P), inclusive of (O) and (P). 488 Reserved 490 Reserved for future use. These bits MUST be set to zero by the 491 sender and ignored by the receiver. 493 4. Security Considerations 495 This draft defines the format of the traffic selector field of a sub- 496 option defined for flow bindings [I-D.ietf-mext-flow-binding]. The 497 authors have not identified any security concerns pertaining to this 498 draft beyond what is already identified in 499 [I-D.ietf-mext-flow-binding]. 501 5. IANA Considerations 503 1) New TS format values from the "Traffic Selector Format" namespace 504 for the Traffic Selector sub-option defined in 505 [I-D.ietf-mext-flow-binding]. The following values are requested: 507 1 IPv4 Binary Traffic Selector 509 2 IPv6 Binary Traffic Selector 511 6. Aknowledgements 513 The authors would like to thank Patrick Stupar and Julien Laganier 514 for their contributions to this document. We would also like to 515 thank Benjamin Lim, Dave Craig, Patrick Stupar, and Basavaraj Patil 516 for their reviews and comments. 518 7. References 520 7.1. Normative References 522 [I-D.ietf-mext-flow-binding] 523 Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., 524 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO 525 Basic Support", draft-ietf-mext-flow-binding-04 (work in 526 progress), November 2009. 528 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 529 August 1980. 531 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 532 September 1981. 534 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 535 RFC 793, September 1981. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 541 (IPv6) Specification", RFC 2460, December 1998. 543 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 544 of Explicit Congestion Notification (ECN) to IP", 545 RFC 3168, September 2001. 547 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 548 RFC 4303, December 2005. 550 7.2. Informative References 552 [RFC3260] Grossman, D., "New Terminology and Clarifications for 553 Diffserv", RFC 3260, April 2002. 555 Authors' Addresses 557 George Tsirtsis 558 Qualcomm 560 Email: tsirtsis@gmail.com 562 Gerardo Giarreta 563 Qualcomm 565 Email: gerardog@qualcomm.com 567 Hesham Soliman 568 Elevate Technologies 570 Email: hesham@elevatemobile.com 572 Nicolas Montavont 573 Institut Telecom / Telecom Bretagne 574 2, rue de la chataigneraie 575 Cesson Sevigne 35576 576 France 578 Phone: (+33) 2 99 12 70 23 579 Email: nicolas.montavont@telecom-bretagne.eu 580 URI: http://www.rennes.enst-bretagne.fr/~nmontavo//