idnits 2.17.1 draft-braun-core-compressed-ipfix-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4944], [RFC5101]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Compressed Templates MUST be sent by an Compressed Exporter before any Compressed Data Set that refers to the Compressed Template is transmitted. Compressed Templates are not expected to change over time in Compressed IPFIX. Hence, a Compressed Template that has been sent once MAY NOT be withdrawn and MUST NOT expire. If an IPFIX Smart Meter wants to use another Compressed Template it MUST use a new Compressed Template ID for the Compressed Template. -- The document date (September 21, 2011) is 4601 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) == Missing Reference: 'RFC4944' is mentioned on line 1032, but not defined == Missing Reference: 'RFC5101' is mentioned on line 1036, but not defined ** Obsolete undefined reference: RFC 5101 (Obsoleted by RFC 7011) == Missing Reference: 'RFC5982' is mentioned on line 1048, but not defined == Missing Reference: 'I-D.ietf-ipfix-mediators-framework' is mentioned on line 1052, but not defined == Missing Reference: 'RFC2119' is mentioned on line 1025, but not defined == Missing Reference: 'RFC5470' is mentioned on line 1044, but not defined == Missing Reference: 'RFC5102' is mentioned on line 1040, but not defined ** Obsolete undefined reference: RFC 5102 (Obsoleted by RFC 7012) == Missing Reference: 'RFC2434' is mentioned on line 1028, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'I-D.shelby-core-coap' is mentioned on line 1058, but not defined Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Braun 3 Internet-Draft C. Schmitt 4 Intended status: Standards Track TU Muenchen 5 Expires: March 22, 2012 B. Claise 6 Cisco Systems, Inc. 7 G. Carle 8 TU Muenchen 9 September 21, 2011 11 Compressed IPFIX for smart meters in constrained networks 12 14 Abstract 16 This document specifies the Compressed IPFIX protocol that serves for 17 transmitting smart metering data in 6LoWPAN networks [RFC4944]. 18 Compressed IPFIX is derived from IPFIX [RFC5101] and adopted to the 19 needs of constrained networks. This documents specifies how the 20 Compressed IPFIX Data and Template Records are transmitted in 6LoWPAN 21 networks and how Compressed IPFIX data can be converted into 22 uncompressed IPFIX data in a proxy device. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 22, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Document structure . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Hard- and Software constraints . . . . . . . . . . . . . . . . 7 64 3.1. Hardware constraints . . . . . . . . . . . . . . . . . . . 7 65 3.2. Energy constraints . . . . . . . . . . . . . . . . . . . . 8 66 3.3. Packet size constraints . . . . . . . . . . . . . . . . . 8 67 3.4. Transport protocol constraints . . . . . . . . . . . . . . 8 69 4. Application scenarios for Compressed IPFIX . . . . . . . . . . 9 71 5. Architecture for Compressed IPFIX . . . . . . . . . . . . . . 11 73 6. Compressed IPFIX Message Format . . . . . . . . . . . . . . . 13 74 6.1. Compressed IPFIX Message Header . . . . . . . . . . . . . 13 75 6.2. Compressed Set . . . . . . . . . . . . . . . . . . . . . . 15 76 6.3. Compressed Template Record Format . . . . . . . . . . . . 16 77 6.4. Field Specifier Format . . . . . . . . . . . . . . . . . . 17 78 6.5. Compressed Data Record Format . . . . . . . . . . . . . . 18 80 7. Compressed IPFIX Mediation . . . . . . . . . . . . . . . . . . 19 81 7.1. Expanding the Message header . . . . . . . . . . . . . . . 21 82 7.2. Translating the Set Headers . . . . . . . . . . . . . . . 22 83 7.3. Expanding the Template Record Header . . . . . . . . . . . 22 85 8. Template Management . . . . . . . . . . . . . . . . . . . . . 22 86 8.1. TCP / SCTP . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 9. Security considerations . . . . . . . . . . . . . . . . . . . 23 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 12.1. Norminative References . . . . . . . . . . . . . . . . . . 24 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 Smart meters that form a constrained wireless network need an 104 application layer protocol that allows the efficient transmission of 105 metering data from the devices to some kind of central analysis 106 device. The meters used to build such networks are usually equipped 107 with low-cost and low-power hardware. This leads to constraints in 108 computational capacities, available memory and networking resources. 110 The devices are often battery powered and are expected to run for a 111 long time without having the possibility to re-charge themselves. In 112 order to save energy, smart meters often power off their wireless 113 networking device. Hence, they don't have a steady network 114 connection, but are only part of the wireless network as needed when 115 there is data that needs to be exported. A push protocol like 116 Compressed IPFIX, where data is transmitted autonomically from the 117 meters to one or more collectors, is suitable for reporting metering 118 data in such networks. 120 Compressed IPFIX is derived from IPFIX [RFC5101] and therefore 121 inherits most of its properties. One of these properties is the 122 separation of data and its data description by encoding the former in 123 Data Sets and the latter in Template Sets. 125 Transforming Compressed IPFIX to IPFIX as per [RFC5101] is very 126 simple and can be done on the border between the constrained network 127 and the more general network. The transformation between one form of 128 IPFIX data into another is known as IPFIX Mediation [RFC5982]. 129 Hence, smart metering networks that are based on Compressed IPFIX can 130 be easily integrated into an existing IPFIX measurement 131 infrastructure. 133 1.1. Document structure 135 Section 2 introduces the used terminology in this draft. Afterwards, 136 hardware and software constraints in constrained networks, which will 137 motivate our modifications to the IPFIX protocol, are discussed in 138 Section 3. Section 4 describes the application scenarios and 139 Section 5 describes the architecture for Compressed IPFIX. Section 6 140 defines the Compressed IPFIX protocol itself and discusses the 141 differences between Compressed IPFIX and IPFIX. The Mediation 142 Process from Compressed IPFIX to IPFIX is described in Section 7. 143 Section 8 defines the process of Template Management on the Exporter 144 and the Collector. Section 9 and Section 10 discuss the security and 145 IANA considerations for Compressed IPFIX. Section 11 lists the open 146 issues that need to be addressed in further versions of this draft. 148 2. Terminology 150 The term smart meter is used to refer to constrained devices like 151 wireless senor nodes, motes or any other kind of small constraint 152 device that can be part of a network that is based on IEEE802.15.4 153 and 6LoWPAN [RFC4944]. 155 Most of the terms used in this draft are defined in [RFC5101]. All 156 these terms are written with their first letter being capitalized. 157 Most of the terms that are defined for IPFIX can be used to describe 158 Compressed IPFIX. The term "Compressed" is used in front of the 159 IPFIX term to distinguish between the IPFIX version and the 160 Compressed IPFIX version. This draft uses the term IPFIX to refer to 161 IPFIX as per RFC 5101 and the term Compressed IPFIX for the IPFIX 162 version defined in this draft. 164 The terms IPFIX Message, IPFIX Device, Set, Data Set, Template Set, 165 Data Record, Template Record, Collecting Process, Collector, 166 Exporting Process and Exporter are defined as in [RFC5101]. The term 167 IPFIX Mediator is defined in [RFC5982]. The terms Intermediate 168 Process, IPFIX Proxy, IPFIX Concentrator are defined in 169 [I-D.ietf-ipfix-mediators-framework]. 171 All these terms above have been adapted from the IPFIX definitions. 172 As they keep a similar notion but in a different context of 173 constrained networks, the term "Compressed" now complements the 174 defined terms. 176 Compressed Exporting Process 178 The Compressed Exporting Process is a process that exports 179 Compressed Records. 181 Compressed Exporter 183 A Compressed Exporter is a smart metering device that contains at 184 least one Compressed Exporting Process. 186 Compressed Collecting Process 188 The Compressed Collecting Process is a process inside a device 189 that is able to receive and process Compressed Records. 191 Compressed IPFIX Collector 193 A Compressed Collector is a device that contains at least one 194 Compressed Collecting Process. 196 Compressed IPFIX Device 198 A Compressed IPFIX Device is a device that contains one or more 199 Compressed Collector or one or more Compressed Exporter. 201 Compressed IPFIX Smart Meter 203 A Compressed IPFIX Smart Meter is a device that contains the 204 functionality of an Compressed IPFIX device. It is usually 205 equipped with one or more sensors that meter a physical quantity, 206 like power consumption, temperature, or physical tempering with 207 the device. Every Compressed IPFIX Smart Meter MUST at least 208 contain an Compressed Exporting Process. It MAY contain a 209 Compressed Collecting Process in order to work as a Compressed 210 IPFIX Proxy or Concentrator. 212 Compressed IPFIX Message 214 The Compressed IPFIX Message is a message originated by an 215 Compressed IPFIX Exporter. It is composed of a Compressed Message 216 Header and one or more Compressed Sets. The Compressed IPFIX 217 Message Format is defined in Section 6. 219 Compressed Data Record 221 A Compressed Data Record equals a Data Record in [RFC5101]. The 222 term is used to distinguish between IPFIX and Compressed IPFIX 223 throughout the document. 225 Compressed Template Record 227 A Compressed Template Record is similar to a Template Record. The 228 Template Record Header is substituted with a Compressed Template 229 Record Header and is otherwise equal to a Template Record. 230 Section 6.3. 232 Compressed Set 234 The Compressed Set is a group of Compressed Data Records or 235 Compressed Template Records with a Compressed Set Header. Its 236 format is defined in Section 6.2. 238 Compressed Data Set 240 The Compressed Data Set is a Compressed Set that contains 241 Compressed Data Records. in Section 6.2. 243 Compressed Template Set 245 A Compressed Template Set is a Compressed Set that contains 246 Compressed Template Records. 248 Compressed Intermediate Process 250 A Compressed Intermediate Process is an Intermediate Process that 251 can handle Compressed IPFIX Messages. 253 Compressed IPFIX Proxy 255 A Compressed IPFIX Proxy is an IPFIX Proxy that can handle 256 Compressed IPFIX Messages. 258 Compressed IPFIX Concentrator 260 A Compressed IPFIX Concentrator is an IPFIX Concentrator that can 261 handle Compressed IPFIX Messages. 263 A Compressed IPFIX Transport Session is defined by the communication 264 between a Compressed Exporter (identified by an 6LowPAN-Address, the 265 Transport Protocol, and the Transport Port) and a Compressed 266 Collector (identified by the same properties). 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 270 document are to be interpreted as described in [RFC2119]. 272 3. Hard- and Software constraints 274 3.1. Hardware constraints 276 The target devices for Compressed IPFIX are usually equipped with 277 low-cost hardware and therefore face several constraints concerning 278 CPU and memory [Schmitt09]. For example, the IRIS mote from Crossbow 279 Technologies Inc. has a size of 58 x 32 x 7 mm (without a battery 280 pack) [Crossbow]. Thus, there is little space for micro controller, 281 flash memory (128 kb) and radio frequency transceiver, which are 282 located on the board. 284 Network protocols used on such hardware need to respect these 285 constraints. They must be simple to implement using little code and 286 little run time memory and should produce little overhead when 287 encoding the application payload. 289 3.2. Energy constraints 291 Smart meters that are battery powered have hard energy constraints 292 [Schmitt09]. By power supply of two 2 AA 2,800-mAh batteries this 293 means approximately 30,240J. If they run out of power, their battery 294 Has to be changed, which means physical manipulation to the device is 295 necessary. Using as little energy as possible for network 296 communication is therefore desired. 298 A smart metering device can save a lot of energy, if it powers down 299 its radio frequency transceiver. Such devices do not have permanent 300 network connectivity but are only part of the network as needed. A 301 push protocol, where only one side is sending data, is suitable for 302 transmitting application data under such circumstances. As the 303 communication is unidirectional, a meter can completely power down 304 its radio frequency transceivers as long as it does not have any data 305 to sent. If the metering device is able to keep a few measurements 306 in memory, and if real time metering is not a requirement, the 307 Compressed Data Records can be pushed less frequently. Therefore, 308 saving some more energy on the radio frequency transceivers. 310 3.3. Packet size constraints 312 Compressed IPFIX is mainly targeted for the use in 6LoWPAN networks, 313 which are based on IEEE 802.15.4 [RFC4944]. However, the protocol 314 can also be used to transmit data in other networks. IEEE 802.15.4 315 defines a maximum frame size of 127 octets, which usually leaves 102 316 octets for user data. IPv6 on the other hand defines a minimum MTU 317 of 1280 octets. Hence, fragmentation has to be implemented in order 318 to transmit such large packets. While fragmentation allows the 319 transmission of large messages, its use is problematic in networks 320 with high packet loss because the complete message has to be 321 discarded if only a single fragment gets lost. 323 Compressed IPFIX enhances IPFIX by a header compression scheme, which 324 allows to reduce the overhead from header sizes significantly. 325 Additionally, the overall Compressed IPFIX Message size is reduced, 326 which reduces the need for fragmentation. 328 3.4. Transport protocol constraints 330 The IPFIX standard [RFC5101] defines several transport protocol 331 bindings for the transmission of IPFIX Messages. SCTP support is 332 REQUIRED for any IPFIX Device to achieve standard conformance 333 [RFC5101], and its use is highly recommended. However, sending IPFIX 334 over UDP and TCP MAY also be implemented. 336 This transport protocol recommendation is not suitable for Compressed 337 IPFIX. A header compression scheme that allows to compress an IPv6 338 header from 40 octets down to 2 octets is defined in 6LoWPAN. There 339 is a similar compression scheme for UDP, but there is no such 340 compression for TCP or SCTP headers. If header compression can be 341 employed, more space for application payload is available. 343 Using UDP on the transport layer for transmitting IPFIX Messages is 344 therefore highly recommended. Furthermore, TCP or SCTP are currently 345 not supported on some platforms, like on TinyOS [Harvan08]. Hence, 346 UDP may be the only option. 348 Every Compressed IPFIX Exporter and Collector MUST implement UDP 349 transport layer support for transmitting data in a constrained 350 network environment. It MAY also offer TCP or SCTP support. 351 However, using these protocols is NOT RECOMMENDED as their use will 352 consume more power and reduces the available size of application 353 payload compared to the use of UDP. If Compressed IPFIX is 354 transmitted over a non-constrained network, using SCTP as a transport 355 layer protocol is RECOMMENDED. 357 4. Application scenarios for Compressed IPFIX 359 Compressed IPFIX is derived from IPFIX [RFC5101] and is therefore a 360 unidirectional push protocol. This means all communication that 361 employs Compressed IPFIX is unidirectional from an Exporting Process 362 to a Collecting Process. Hence, Compressed IPFIX only fits for 363 application scenarios where meters transmit data to one or more 364 Collectors. 366 If Compressed IPFIX is used over UDP, as recommended, packet loss can 367 occur. Furthermore, if an initial Template Message gets lost, and is 368 therefore unknown to the Collector, all Data Sets that reference this 369 Template cannot be decoded. Hence, all these Messages are lost if 370 they are not cached by the Collector. It should be clear to an 371 application developer, that Compressed IPFIX can only be used over 372 UDP if these Compressed IPFIX Message losses are not a problem. 374 Compressed IPFIX over UDP is especially not a suitable protocol for 375 applications where sensor data trigger policy decisions or 376 configuration updates for which packet loss is not tolerable. 378 Applications that use smart sensors for accounting purposes for long 379 time measurements can benefit from the use of Compressed IPFIX. One 380 application for IPFIX can be long term monitoring of large physical 381 volumes. In [Tolle05], Tolle et al. built a system for monitoring a 382 "70-meter tall redwood tree, at a density interval of 5 minutes in 383 time and 2 meters in space". The sensor node infrastructure was 384 deployed to measure the air temperature, relative humidity and 385 photosynthetically active solar radiation over a long time period. 387 Deploying Compressed IPFIX in such scenarios seems to be a good fit. 388 The sensors of the IPFIX Smart Meter can be queried over several 5 389 minute time intervals and the query results can be aggregated into a 390 single Compressed IPFIX Message. As soon as enough query results are 391 stored in the Compressed IPFIX Message, e.g. if the Compressed IPFIX 392 Message size fills the available payload in a single IEEE 802.15.4 393 packet, the wireless transceiver can be activated and the Compressed 394 IPFIX Message can be exported to a Compressed IPFIX Collector. 396 Similar sensor networks have been built to monitor the habitat of 397 animals, e.g. in the "Great Duck Island Project" [GreatDuck], 398 [SMPC04]. The purpose of the sensor network was to monitor the birds 399 by deploying sensors in and around their burrows. The measured 400 sensor data was collected and stored in a database for offline 401 analysis and visualization. Again, the sensors can perform their 402 measurements periodically, aggregate the sensor data and export them 403 to a Compressed IPFIX Collector. 405 Other application scenarios for Compressed IPFIX could be 406 applications where sensor networks are used for long term structural 407 health monitoring in order to investigate long term weather 408 conditions on the structure of a building. For example, a smart 409 metering network has been built to monitor the structural health of 410 the Golden Gate Bridge [Kim07]. If a sensor network is deployed to 411 perform a long term measurement of the structural integrity, 412 Compressed IPFIX can be used to collect the sensor measurement data. 414 If an application developer wants to decide whether to use Compressed 415 IPFIX for transmitting data from smart meters, he must take the 416 following considerations into account: 418 1. The application must require a push protocol. It is not possible 419 to request data from a smart meter. The IPFIX Smart Meter 420 decides for itself when to send its metering data. 421 2. The property above allows a IPFIX Smart Meter to turn off its 422 wireless device in order to save energy, as it does not have to 423 receive any data. 424 3. If real-time is not required, the application might benefit from 425 accumulated several measurements into a single Compressed IPFIX 426 Message. Compressed IPFIX easily allows the aggregation of 427 several into a single Compressed IPFIX Message (or a single 428 packet). This aggregation can happen on the IPFIX Smart Meter 429 that aggregates several of its own measurements. Or it can 430 happen within a multi-hop wireless network where one IPFIX Proxy 431 aggregates several Compressed IPFIX Messages into a single 432 Compressed IPFIX Message before forwarding them. 434 4. The application must accept potential packet loss. Compressed 435 IPFIX only fits for applications where metering data is stored 436 for accounting purposes and not for applications where the sensor 437 data triggers configuration changes or policy decisions (except: 438 if Message loss is acceptable for some reason). 440 5. Architecture for Compressed IPFIX 442 The Compressed IPFIX architecture is similar to the IPFIX 443 architecture which is described in [RFC5470]. The most common 444 deployment of IPFIX Smart Meters is shown in Figure 1. 446 +----------------+ +----------------+ 447 |[*Application 1]| ... |[*Application n]| 448 +--------+-------+ +-------+--------+ 449 ^ ^ 450 | | 451 + = = = = -+- = = = = + 452 ^ 453 | 454 +------------------------+ Compressed +--------+-------------------+ 455 | Compressed IPFIX S.M. | IPFIX | Compressed IPFIX Collector | 456 | [Exporting Process] |----------->| [Collecting Process(es)] | 457 +------------------------+ +----------------------------+ 459 Figure 1: Direct transmission between sensors and applications 461 An IPFIX Smart Meter (S.M.) queries its internal sensors to retrieve 462 the sensor data. It then encodes the results into a Compressed IPFIX 463 Message and exports this Compressed IPFIX Message to one or more 464 Compressed IPFIX Collectors. The Compressed IPFIX Collector runs one 465 or more applications that process the collected sensor data. The 466 Compressed IPFIX Collector can be deployed on non-constrained devices 467 at the constrained network border. 469 A second way to deploy IPFIX Smart Meter can employ aggregation on 470 Compressed IPFIX Messages during their journey through the 471 constrained network as shown in Figure 2. This aggregation can be 472 performed by special IPFIX Smart Meter that act as Compressed IPFIX 473 Concentrators. Such devices must have enough resources to perform 474 the aggregation. 476 +-------------------------+ +------------------------+ 477 | Compressed IPFIX S.M. | Compressed IPFIX |Comp. IPFIX Concentrator| 478 | [Exporting Process] |----------------->| [Collecting Process] | 479 +-------------------------+ +-------->| [Exporting Process] | 480 | +------------------------+ 481 +-------------------------+ | | 482 | Compressed IPFIX S.M. | | Compressed IPFIX| 483 | [Exporting Process] |--------+ | 484 +-------------------------+ v 485 +-------+------------------+ 486 | Collector(1) | 487 | [Collecting Process(es)] | 488 +--------------------------+ 490 Figure 2: Aggregation on Compressed IPFIX 492 IPFIX Smart Meters send their data to Compressed IPFIX Concentrator 493 which needs to have enough storage space to store the incoming data. 494 It may also aggregate the incoming data with its own measurement 495 data. The aggregated data can then be re-exported again to one or 496 more Collectors. 498 The last deployment, shown in Figure 3, employs another Compressed 499 IPFIX Mediation process. 501 +------------------------+ +------------------------+ 502 | Compressed IPFIX S.M | Compressed IPFIX | Compressed IPFIX Proxy | 503 | [Exporting Process] |----------------->| [Collecting Process] | 504 +------------------------+ | [Exporting Process] | 505 +------------------------+ 506 | 507 IPFIX | 508 | 509 v 510 +-------+------------------+ 511 | IPFIX Collector(1) | 512 | [Collecting Process(es)] | 513 +--------------------------+ 515 Figure 3: Aggregation on Compressed IPFIX 517 The IPFIX Smart Meters transmit their Compressed IPFIX Messages to 518 one node, e.g. the base station, which translates the Compressed 519 IPFIX Messages to IPFIX Messages. The IPFIX Messages can then be 520 exported into an existing IPFIX infrastructure. The Mediation 521 process from Compressed IPFIX to IPFIX is described in Section 7. 523 6. Compressed IPFIX Message Format 525 A Compressed IFPIX Message starts with a Compressed Message Header, 526 followed by one or more Compressed Sets. The Compressed Sets can be 527 any of the possible two types: Compressed Template Set and Compressed 528 Data Set. An Compressed IPFIX Message MUST only contain one type of 529 Compressed Set. The format of the Compressed IPFIX Message is shown 530 in Figure 4 532 +----------------------------------------------------+ 533 | Compressed Message Header | 534 +----------------------------------------------------+ 535 | Compressed Set | 536 +----------------------------------------------------+ 537 | Compressed Set | 538 +----------------------------------------------------+ 539 ... 540 +----------------------------------------------------+ 541 | Compressed Set | 542 +----------------------------------------------------+ 544 Figure 4: Compressed IPFIX Message Format 546 6.1. Compressed IPFIX Message Header 548 The Compressed IPFIX Message Header is derived from the IPFIX Message 549 Header, with some optimization using field compression. The IPFIX 550 Message Header from [RFC5101] is shown in Figure 5. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Version Number | Length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Export Time | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Sequence Number | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Observation ID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Figure 5: IPFIX Message Header 565 The length of the IPFIX Message Header is 16 octets and every IPFIX 566 Message has to be started with it. The Compressed IPFIX Message 567 Header needs to be smaller due to the packet size constraints 568 discussed in Section 3.3. Compressed IPFIX introduces a Compressed 569 IPFIX Message Header that has a smaller size. The Compressed header 570 consists of a fixed part of two octets and a variable length 571 "Remaining Header" as shown in Figure 6. 573 0 1 574 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |Version|ETC|SNC| Length | 577 |Number | | | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Remaining Header | 580 | | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 6: Format of the Compressed IPFIX Message header 585 The first part has a fixed length of two octets and consists of the 586 "Version Field" (4 bit), the "Export Time Compression" (ETC) field (2 587 bit), the "Sequence Number Compression" (SNC) field (2 bit) and the 588 "Length" field (8 bit). The second part (the "Remaining Header") has 589 a variable length. Its length is defined by the ETC and SNC fields 590 in the fixed header. 592 The fixed header has a length of two octets which equals the length 593 of the version field of the IPFIX Message Header. Hence, Compressed 594 IPFIX Messages can be read and identified by an IPFIX Collector. 595 This is important for building an IPFIX Mediator by extending an 596 IPFIX Collector (Section 7). 598 The fixed header fields are defined as follows: 600 Version number 602 The Compressed IPFIX version field MUST have the most significant 603 bit set to one and the other bits set to zero. The remaining bits 604 of the version field are reserved for future versions of 605 Compressed IPFIX. Note that IPFIX has the version 0x000a, hence 606 an IPFIX Collector can distinguish between IPFIX and Compressed 607 IPFIX by checking the first bit of the version field. 609 ETC 611 The ETC field defines the compression level of the "Export Time" 612 field of the IPFIX Messages Header. Its value defines the length 613 as follows. A bit sequence of "00" denotes that the "Export Time" 614 field is omitted. A sequence of "01" denotes that the "Export 615 Time" field has a size of one octet. A sequence of "10" denotes 616 that the "Export Time" field has a size of two octets. Finally, a 617 sequence of "11" denotes that the "Export Time" field has the 618 original length of four octets. 620 SNC 622 The SNC field defines the compression level of the "Sequence 623 Number" field of the IPFIX Messages Header. Its value defines the 624 length as follows. A bit sequence of "00" denotes that the 625 "Sequence Number" field is omitted. A sequence of "01" denotes 626 that the "Sequence Number" field has a size of one octet. A 627 sequence of "10" denotes that the "Sequence Number" field has a 628 size of two octets. Finally, a sequence of "11" denotes that the 629 "Sequence Number" field has the original length of four octets. 631 Length 633 The length field has a fixed length of one octet. Compressed 634 IPFIX Messages therefore have a maximum length of 255 octets. 636 An application SHOULD never send a Compressed IPFIX that is bigger 637 than 102 octets to avoid fragmentation. If the "Export Time" field 638 is not omitted, it is placed directly behind the length field. If 639 the Export Time field has a size of four octets, it MUST contain the 640 time in seconds since 0000 UTC Jan 1, 1970, at which the Compressed 641 IPFIX Message Header leaves the Exporter. This complies with the 642 "Export Time" field in IPFIX. 644 Afterwards, the "Sequence Number" field is attached (if not omitted). 645 If the field has a length of four bytes, it must contain the number 646 of records sent since the start of the Exporter module 2^32 at the 647 end of this Compressed IPFIX Message. If the field is Compressed to 648 one or two bytes, it must contain the number of IPFIX messages sent 649 by the Exporter since its start modulo 2^8 or 2^16. 651 6.2. Compressed Set 653 A Compressed Set is a set of Compressed Template or Compressed Data 654 Records. Depending on the Compressed Record type, the Compressed Set 655 can either be a Compressed Template Set or a Compressed Data Set. 656 Every Compressed Set is started with an Compressed Set Header and is 657 followed by one or more Compressed Records. 659 The IPFIX Set Header consists of an two octet "Set ID" field and a 660 two octet "Length" field. These two fields are compressed to one 661 octet each for the Compressed Set Header. The format of the 662 Compressed Set Header is shown in Figure 7. 664 0 1 665 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Comp. Set ID | Length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Figure 7: Compressed Set Header 672 The two fields are defined as follows: 674 Compressed Set ID 676 The "Compressed Set ID" (Comp. Set ID) identifies the type of 677 data that is transported in the Compressed Set. A Compressed 678 Template Set is identified by Compressed Set ID 2. This 679 corresponds to the Set IDs that are used by Sets in IPFIX. 680 Compressed Set ID number 3 MUST NOT be used. All values from 4 to 681 127 are reserved for future use. Values above 127 are used for 682 Compressed Data Sets. 684 Length 686 The "Length" Field contains the total length of the Compressed 687 Set, including the Compressed Set Header. 689 6.3. Compressed Template Record Format 691 The format of the Compressed Template Records is shown in Figure 8. 692 The Compressed Template Record starts with an Compressed Template 693 Record Header and is followed by one or more Field Specifiers. The 694 Field Specifier format is defined as in Section 6.4 and is identical 695 to the Field Specifier definition in [RFC5101]. 697 +--------------------------------------------------+ 698 | Compressed Template Record Header | 699 +--------------------------------------------------+ 700 | Field Specifier | 701 +--------------------------------------------------+ 702 | Field Specifier | 703 +--------------------------------------------------+ 704 ... 705 +--------------------------------------------------+ 706 | Field Specifier | 707 +--------------------------------------------------+ 709 Figure 8: Compressed Template Format 711 The format of the Compressed Template Record Header is shown in 712 Figure 9. 714 0 1 715 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Comp. Temp ID | Field Count | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Figure 9: Compressed Template Header 722 Compressed Template ID 724 Each Compressed Template Record must have a unique Compressed 725 Template ID (Comp. Temp ID) between 128 and 255. The Compressed 726 Template ID must be unique for the given Compressed Transport 727 Session. 729 Field Count 731 The number of fields placed in the Compressed Template Record. 733 6.4. Field Specifier Format 735 The type and length of the transmitted data is encoded in Field 736 Specifiers within Compressed Template Records. The Field Specifier 737 is shown in Figure 10 and is identical with the Field Specifier that 738 was defined for IPFIX [RFC5101]. The following text has been copied 739 from [RFC5101] for completeness. 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 |E| Information Element ident. | Field Length | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Enterprise Number | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Figure 10: Compressed Template Header 751 Where: 753 E 755 Enterprise bit. This is the first bit of the Field Specifier. If 756 this bit is zero, the Information Element Identifier identifies an 757 IETF-specified Information Element, and the four-octet Enterprise 758 Number field MUST NOT be present. If this bit is one, the 759 Information Element Identifier identifies an enterprise-specific 760 Information Element, and the Enterprise Number field MUST be 761 present. 763 Information Element Identifier 765 A numeric value that represents the type of Information Element. 767 Field Length 769 The length of the corresponding encoded Information Element, in 770 octets. Refer to [RFC5102]. The value 65535 is illegal as there 771 are no variable size encoded elements as they are defined in 772 IPFIX. 774 Enterprise Number 776 IANA [IANA] enterprise number of the authority defining the 777 Information Element identifier in this Template Record. 779 Vendors can easily define their own data model by registering a 780 Enterprise ID with IANA. Using their own Enterprise ID, they can use 781 any ID in the way they want them to use. 783 6.5. Compressed Data Record Format 785 The Data Records are sent in Compressed Data Sets. The format of the 786 Data Records is shown in Figure 11 and matches the Data Record format 787 from IPFIX. 789 +--------------------------------------------------+ 790 | Field Value | 791 +--------------------------------------------------+ 792 | Field Value | 793 +--------------------------------------------------+ 794 ... 795 +--------------------------------------------------+ 796 | Field Value | 797 +--------------------------------------------------+ 799 Figure 11: Data Record Format 801 7. Compressed IPFIX Mediation 803 There are two types of Compressed IPFIX Intermediate Processes. The 804 first one can occur on the transition between a constraint 6LoWPAN 805 and the non-constrained network. This mediation changes the network 806 and transport protocol from 6LowPAN/UDP to IP/(SCTP|TCP|UDP) and is 807 shown in Figure 12. 809 +-----------------------+Compressed IPFIX+-------------------------+ 810 |Compressed IPFIX S.M. | 6LoWPAN/UDP |Compressed IPFIX mediator| 811 | [Exporting Process] |--------------->| [Collecting Process] | 812 +-----------------------+ | [Exporting Process] | 813 +-------------------------+ 814 | 815 Compressed IPFIX | 816 IP/(UDP/SCTP|TCP) | 817 v 818 +-------+------------------+ 819 | Collector(1) | 820 | [Collecting Process(es)] | 821 +--------------------------+ 823 Figure 12: Translation from Compressed IPFIX over 6LowPAN/UDP to 824 Compressed IPFIX over IP/(SCTP|TCP|UDP) 826 The mediator removes the Compressed IPFIX Messages from the 6LowPAN/ 827 UDP packets and wraps them into the new network and transport 828 protocols. Templates MUST be managed the same way as in the 829 constraint environment after the translation to IP/(SCTP|UDP|TCP) 830 (see Section 8). 832 The second type of mediation transforms Compressed IPFIX into IPFIX. 834 This process MUST be combined with the transport protocol mediation 835 as shown in Figure 13. 837 +------------------------+ Compressed IPFIX+-----------------------+ 838 | Compressed IPFIX S.M. | 6LoWPAN/UDP | IPFIX mediator | 839 |[Exporting Processes] |---------------->| [Collecting Process] | 840 +------------------------+ | [Exporting Process] | 841 +-----------------------+ 842 | 843 IPFIX | 844 IP/(UDP/SCTP|TCP) | 845 v 846 +-------+------------------+ 847 | Collector(1) | 848 | [Collecting Process(es)] | 849 +--------------------------+ 851 Figure 13: Transformation from Compressed IPFIX to IPFIX 853 This mediation can also be performed by an IPFIX Collector before 854 parsing the IPFIX message as shown in Figure 14. There is no need 855 for a Compressed IPFIX parser if such a mediation process can be 856 employed in front of an already existing IPFIX collector. 858 +------------------------+ Compressed IPFIX +----------------------+ 859 | Compressed IPFIX S.M. | 6LoWPAN/UDP | IPFIX Mediator | 860 | [Exporting Processes] |----------------->| [Collecting Process] | 861 +------------------------+ | [Exporting Process] | 862 | | | 863 | |IPFIX | 864 | | | 865 | v | 866 | Collector(1) | 867 | [Collecting Process] | 868 +----------------------+ 870 Figure 14: Transformation from Compressed IPFIX to IPFIX 872 The Compressed Mediation Process has to translate the Compressed 873 IPFIX Message Header, the Compressed Set Headers and the Compressed 874 Template Record Header into their counterparts in IPFIX Afterwards, 875 the new IPFIX Message Length needs to be calculated and inserted into 876 the IPFIX Message header. 878 7.1. Expanding the Message header 880 The fields of the IPFIX Message Header that are shown in Figure 5 can 881 be determined as follows: 883 Version 885 This is always 0x000a. 887 Length 889 The IPFIX Message Length can only be calculated after the complete 890 Compressed IPFIX Message has been translated. The new length can 891 be calculated by adding the length of the IPFIX Message Header, 892 which is 16 octets, and the length of all Sets that are contained 893 in the IPFIX Message. 895 Export Time 897 If the "Export Time" in the Compressed IPFIX Message Header has a 898 length of 4 octets, the value from the Compressed Message Header 899 MUST be used for the IPFIX Message Header. If it was omitted, the 900 "Export Time" MUST be generated by the Mediator. If the IPFIX 901 Message is exported again, the "Export Time" field MUST contain 902 the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX 903 Message leaves the Exporter. If the Message is passed to an IPFIX 904 Collector for decoding directly, the "Export Time" field is the 905 time in seconds since 0000 UTC Jan 1 1970 at which the Compressed 906 IPFIX Message has been received by the Compressed IPFIX Exporter. 908 Sequence Number 910 If the Compressed Sequence Number has a length of 4 octets, the 911 original value MUST be used for the IPFIX Message. If the 912 Compressed Sequence Number has a size of one or two octets, the 913 Compressed IPFIX Mediator MUST expand the Compressed Sequence 914 Number into a four octet field. If the Compressed Sequence Number 915 was omitted, the Mediator needs to calculate the Sequence Number 916 as per RFC 5101 [RFC5101]. 918 Observation Domain ID 920 This is always 0 indicating to the IPFIX Collector, that the 921 Observation Domain ID is not relevant. 923 7.2. Translating the Set Headers 925 Both fields in the Compressed Set Header have a size of one octet and 926 need to be expanded: 928 Set ID 930 The field needs to be expanded from one octet to two octets. If 931 the Set ID is below 128, no recalculation needs to be performed. 932 This is because all IDs below 128 are reserved for special 933 messages and match the IDs used in IPFIX. The Compressed Set IDs 934 starting with 128 identify Data Sets. Therefore, every Compressed 935 Set ID above 127 needs to be incremented by 128 because IPFIX Data 936 Set IDs are located above 255. 938 Set Length 940 The field needs to be expanded from one octet to two octets. It 941 needs to be recalculated by adding a value of 2 octet to match the 942 additional size of the Set Header. For each Compressed Template 943 Record that is contained in the Compressed Set, 2 more octets need 944 to be added to the length. 946 7.3. Expanding the Template Record Header 948 Both fields in the Compressed Template Record Header have a length of 949 one octet and therefore need translation: 951 Template ID 953 The field needs to be expanded from one octet to two octets. The 954 Template ID needs to be increased by a value of 128. 956 Field Count 958 The field needs to be expanded from one octet to two octets. 960 8. Template Management 962 The way Compressed Templates have to be managed depends on the usd 963 transport protocol. If TCP or SCTP is used, it can be ensured that 964 Compressed Templates are delivered reliably. Template loss can occur 965 on UDP on the other hand. If a Template is lost on its way to the 966 Collector, all following Compressed Data Records that refer to this 967 Compressed Template cannot be decoded. 969 8.1. TCP / SCTP 971 If TCP or SCTP is an option and can be used for the transmission of 972 Compressed IPFIX, Template Management MUST be performed as defined in 973 [RFC5101] for IPFIX. 975 8.2. UDP 977 All specifications for Template management from [RFC5101] apply 978 unless specified otherwise in this document. 980 Compressed Templates MUST be sent by an Compressed Exporter before 981 any Compressed Data Set that refers to the Compressed Template is 982 transmitted. Compressed Templates are not expected to change over 983 time in Compressed IPFIX. Hence, a Compressed Template that has been 984 sent once MAY NOT be withdrawn and MUST NOT expire. If an IPFIX 985 Smart Meter wants to use another Compressed Template it MUST use a 986 new Compressed Template ID for the Compressed Template. 988 As UDP is used, reliable transport of Compressed Templates cannot be 989 guaranteed and Compressed Templates can be lost. A Compressed 990 Exporter MUST expect Compressed Template loss. It MUST therefore re- 991 send its Compressed Templates periodically. A Compressed Template 992 MUST be re-send after a fixed number of N Compressed IPFIX Messages 993 that contained Compressed Data Sets that referred to this Compressed 994 Template. The number N MUST be configured by the application 995 developer. 997 9. Security considerations 999 The same security considerations as for the IPFIX Protocol [RFC5101] 1000 apply. 1002 10. IANA Considerations 1004 The same IANA considerations as for the IPFIX Protocol [RFC5101] 1005 apply. 1007 11. Open Issues 1009 1. Export Time field value if the field is compressed to one or two 1010 bytes is unclear. 1011 2. It is unclear how reserved IPFIX Set IDs above 127 can be 1012 handled, if they are standardized some day 1014 3. Translating the one or two byte long Sequence Number from 1015 Compressed IPFIX to IPFIX has some pitfalls when packet loss 1016 occurs. 1017 4. Option Templates need to be defined (they are forbidden right 1018 now) 1019 5. Section on the Collector side (as in RFC 5101) is needed. 1021 12. References 1023 12.1. Norminative References 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, March 1997. 1028 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1029 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1030 October 1998. 1032 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1033 "Transmission of IPv6 Packets over IEEE 802.15.4 1034 Networks", RFC 4944, September 2007. 1036 [RFC5101] Claise, B., "Specification of the IP Flow Information 1037 Export (IPFIX) Protocol for the Exchange of IP Traffic 1038 Flow Information", RFC 5101, January 2008. 1040 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1041 Meyer, "Information Model for IP Flow Information Export", 1042 RFC 5102, January 2008. 1044 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1045 "Architecture for IP Flow Information Export", RFC 5470, 1046 March 2009. 1048 [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export 1049 (IPFIX) Mediation: Problem Statement", RFC 5982, 1050 August 2010. 1052 [I-D.ietf-ipfix-mediators-framework] 1053 Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 1054 "IPFIX Mediation: Framework", 1055 draft-ietf-ipfix-mediators-framework-09 (work in 1056 progress), October 2010. 1058 [I-D.shelby-core-coap] 1059 Shelby, Z., Frank, B., and D. Sturek, "Constrained 1060 Application Protocol (CoAP)", draft-shelby-core-coap-01 1061 (work in progress), May 2010. 1063 12.2. Informative References 1065 [IANA] "IANA Private Enterprise Numbers registry 1066 http://www.iana.org/assignments/enterprise-numbers.". 1068 [Schmitt09] 1069 Schmitt, C. and G. Carle, "Applications for Wireless 1070 Sensor Networks", In Handbook of Research on P2P and Grid 1071 Systems for Service-Oriented Computing: Models, 1072 Methodologies and Applications, Antonopoulos N.; 1073 Exarchakos G.; Li M.; Liotta A. (Eds.), Information 1074 Science Publishing. , 2010. 1076 [Tolle05] Tolle, G., Polastre, J., Szewczyk, R., Turner, N., Tu, K., 1077 Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson, 1078 T., and D. Culler, "A macroscope in the redwoods", In the 1079 Proceedings of the 3rd ACM Conference on Embedded 1080 Networked Sensor Systems (Sensys 05), San Diego, ACM 1081 Press , November 2005. 1083 [Kim07] Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G., 1084 Glaser, S., and M. Turon, "Health Monitoring of Civil 1085 Infrastructure Using Wireless Sensor Networks", In the 1086 Proceedings of the 6th International Conference on 1087 Information Processing in Sensor Networks (IPSN 2007), 1088 Cambridge, MA, ACM Press, pp. 254-263 , April 2007. 1090 [SMPC04] Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler, 1091 "An analysis of a large scale habitat monitoring 1092 application", The Proceedings of the Second ACM Conference 1093 on Embedded Networked Sensor Systems (SenSys 04) , 1094 November 2004. 1096 [GreatDuck] 1097 Habitat Monitoring on Great Duck Island, 1098 "http://www.greatduckisland.net", The Proceedings of the 1099 Second ACM Conference on Embedded Networked Sensor Systems 1100 (SenSys 04) , November 2004. 1102 [Harvan08] 1103 Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the 1104 Internet: IPv6 over 802.15.4 (6lowpan)", 2008. 1106 [Crossbow] 1107 Crossbow Technologies Inc., "http://www.xbow.com", 2010. 1109 Authors' Addresses 1111 Lothar Braun 1112 Technische Universitaet Muenchen 1113 Department of Informatics 1114 Chair for Network Architectures and Services (I8) 1115 Boltzmannstr. 3 1116 Garching 85748 1117 Germany 1119 Email: braun@net.in.tum.de 1120 URI: http://www.net.in.tum.de/~braun 1122 Corinna Schmitt 1123 Technische Universitaet Muenchen 1124 Department of Informatics 1125 Chair for Network Architectures and Services (I8) 1126 Boltzmannstr. 3 1127 Garching 85748 1128 Germany 1130 Email: schmitt@net.in.tum.de 1131 URI: http://www.net.in.tum.de/~schmitt 1133 Benoit Claise 1134 Cisco Systems, Inc. 1135 De Kleetlaan 6a b1 1136 Diegem 1831 1137 Belgium 1139 Email: bclaise@cisco.com 1141 Georg Carle 1142 Technische Universitaet Muenchen 1143 Department of Informatics 1144 Chair for Network Architectures and Services (I8) 1145 Boltzmannstr. 3 1146 Garching 85748 1147 Germany 1149 Email: carle@net.in.tum.de 1150 URI: http://www.net.in.tum.de/~carle