idnits 2.17.1 draft-jimenez-p2psip-coap-reload-00.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2012) is 4444 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'I-D.ietf-p2psip-concepts' is mentioned on line 137, but not defined == Unused Reference: 'I-D.ietf-core-coap' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 608, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-20 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP J. Jimenez 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Lopez-Vega 5 Expires: August 27, 2012 University of Granada 6 J. Maenpaa 7 G. Camarillo 8 Ericsson 9 February 24, 2012 11 A Constrained Application Protocol (CoAP) Usage for REsource LOcation 12 And Discovery (RELOAD) 13 draft-jimenez-p2psip-coap-reload-00 15 Abstract 17 This document defines a Constrained Application Protocol (CoAP) Usage 18 for REsource LOcation And Discovery (RELOAD). The CoAP Usage 19 provides the functionality to federate Wireless Sensor Networks (WSN) 20 in a peer-to-peer fashion. The CoAP Usage also provides a rendezvous 21 service for CoAP Nodes and caching of sensor information. The RELOAD 22 AppAttach method is used to establish a direct connection between 23 nodes through which CoAP messages are exchanged. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 27, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Registering CoAP URIs . . . . . . . . . . . . . . . . . . . . 6 63 5. Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Forming a direct connection and reading data . . . . . . . . . 7 65 7. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. ProxyCache . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.2. SensorCache . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. CoAP Usage Kinds Definition . . . . . . . . . . . . . . . . . 12 69 8.1. CoAP-REGISTRATION Kind . . . . . . . . . . . . . . . . . . 12 70 8.2. CoAP-CACHING Kind . . . . . . . . . . . . . . . . . . . . 13 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 10.1. RELOAD Sensor Type Registry . . . . . . . . . . . . . . . 13 74 10.2. CoAP-REGISTRATION Kind-ID . . . . . . . . . . . . . . . . 14 75 10.3. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . . 14 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The Constrained Application Protocol (CoAP) is a specialized web 84 transfer protocol. It realizes the Representational State Transfer 85 (REST) architecture for the most constrained nodes, such as sensors 86 and actuators. CoAP can be used not only between nodes on the same 87 constrained network but also between constrained nodes and nodes on 88 the Internet. The latter is possible since CoAP can be translated to 89 Hypertext Transfer Protocol (HTTP) for integration with the web. 90 Application areas of CoAP include different forms of M2M 91 communication, such as home automation, construction, health care or 92 transportation. Areas with heavy use of sensor and actuator devices 93 that monitor and interact with the surrounding environment. 95 The CoAP Usage for RELOAD allows CoAP nodes to store resources in a 96 RELOAD peer-to-peer overlay, provides a rendezvous service, and 97 enables the use of RELOAD overlay as a cache for sensor data. This 98 functionality is implemented in the RELOAD overlay itself, without 99 the use of centralized servers. The CoAP Usage involves three basic 100 functions: 102 1. Registration: CoAP nodes can use the RELOAD data storage 103 functionality to store a mapping from their CoAP URI to their 104 Node-ID in the overlay, and to retrieve the Node-IDs of other 105 nodes. 106 2. Rendezvous: Once a CoAP node has identified the Node-ID for an 107 URI it wishes to retrieve, it can use the RELOAD message routing 108 system to set up a direct connection which can be used to 109 exchange CoAP messages. 110 3. Caching: Nodes can use the RELOAD overlay as a caching mechanism 111 for their sensor information. This is specially useful for 112 battery constrained nodes that can make their data available in 113 the cache provided by the overlay while in sleep mode. 115 For instance, a CoAP proxy (See Section 3) could register its Node-ID 116 (e.g. "9996172") and a list of sensors (e.g. "/temperature-1; 117 ./temperature-2; ./temperature-3") under its URI (e.g. 118 "coap://overlay-1.com/proxy-1/"). 120 When a node wants to discover the values associated with that URI, it 121 queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back 122 the Node-ID of the proxy and the list of its associated sensors. The 123 requesting node can then use the RELOAD overlay to establish a direct 124 connection with the proxy and to read sensor values. 126 Moreover, the CoAP proxy can store the sensor information in the 127 overlay. In this way information can be retrieved directly from the 128 overlay without performing a direct connection to the storing proxy. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 We use the terminology and definitions from Concepts and Terminology 137 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 138 Protocol [I-D.ietf-p2psip-base] extensively in this document. 140 3. Architecture 142 In our architecture we extend the different nodes present in RELOAD 143 (Peer, Client) and add support for sensor devices or other 144 constrained devices. Figure 1 illustrates our architecture. The 145 different nodes, according to their functionality are : 147 Client 148 Devices that are capable of participating in a RELOAD overlay as 149 client nodes, that is they do not route messages in the overlay. 150 Router 151 Devices that are members of (i.e., peers in) a RELOAD overlay and 152 capable of forwarding RELOAD messages following a path through the 153 overlay to the destination. 154 Sensor 155 Devices capable of measuring a physical quantity. Sensors usually 156 acquire quantifiable information about their surrounding 157 environment such as: temperature, humidity, electric current, 158 moisture, radiation, and so on. 159 Actuator 160 Devices capable of interacting and affecting their environment 161 such as: electrical motors, pneumatic actuators, electric 162 switches, and so on. 163 Proxy 164 Devices having sufficient resources to run RELOAD either as client 165 or peer. These devices are located at the edge of the sensor 166 network and, in case of Wireless Sensor Networks (WSN), act as 167 coordinators of the network. 169 Physical devices can have one or several of the previous functional 170 roles. According to the functionalities that are present in each of 171 the nodes, they can be: 173 Constrained Node 174 A Constrained Node (CN) is a node with limited computational 175 capabilities. If it is wireless then it will be part of a Low- 176 Rate Wireless Personal Area Network (LR-WPAN), it might be movable 177 and often offer unreliable connectivity. Also, devices will 178 usually be in sleep mode in order to prevent battery drain, and 179 will not communicate during those periods. A CN is NOT part of 180 the RELOAD overlay, therefore it can not act as a client, router 181 nor proxy. A CN is always either a either a Sensor or an 182 Actuator. In the latter case the node is often connected to a 183 continuous energy power supply. 185 Reload Node 186 A Reload Node (RN) MUST implement the client functionality in the 187 Overlay. Additionally the node will often be a full RELOAD peer 188 with Proxy functionality. A RN may also be sensor or actuator 189 since it can have those devices connected to it. 191 +------+ 192 | | 193 +--------+ RN +---------+ 194 | | | | 195 +---+--+ +------+ +--+---+ 196 | | | | 197 | RN | | RN | 198 | | | | +------------+ 199 +---+--+ +--+---+ | WSN | 200 | RELOAD | | +----+ | 201 | OVERLAY | | +---+ CN | | 202 +---+--+ +--+---+ | | +----+ | 203 | | | +-----+ | 204 | RN | | PN | | | 205 | | | +-----+ | 206 +---+--+ +------+ +--+---+ | | +----+ | 207 | | | | | +---+ CN | | 208 +--------+ PN +---------+ | +----+ | 209 | | +------------+ 210 +-+--+-+ 211 | | 212 +--------|--|--------+ 213 | +--+ +--+ | 214 | | | | 215 | +--+-+ +-+--+ | 216 | | CN | | CN | | 217 | +----+ +----+ | 218 | WSN | 219 +--------------------+ 220 Figure 1: Architecture 222 4. Registering CoAP URIs 224 CoAP URIs are typically resolved using a DNS. When CoAP is needed in 225 a RELOAD environment, URI resolution is provided by the overlay as a 226 whole. Instead of registering register a URI, a peer stores a 227 CoAPRegistration structure under a hash of its own URI. This uses 228 the CoAP REGISTRATION Kind-ID, which is formally defined in 229 Section 6, and that uses a DICTIONARY data model. 231 As an example, if a CoAP proxy that is located in an overlay overlay- 232 1.com using a Node-ID "9996172" wants to register three different 233 temperature sensors to the URI 234 "coap://overlay-1.com/proxy-1/.well-known/", it might store the 235 following mapping in the overlay: 237 RESOURCE-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 238 KEY = 9996172, 239 VALUE = {./temperature-1; 240 ./temperature-2; 241 ./temperature-3} 243 Note that the RESOURCE-ID stored in the overlay is calculated as a 244 SHA-1 hash over the URI (i.e. h(URI)). 246 This would inform any other node performing a lookup for the previous 247 URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value 248 for proxy-1 is "9996172". In addition, this mapping provides 249 relevant information as to the number of sensors (CNs) and the URI 250 path to connect to them using CoAP. 252 5. Rendezvous 254 The RELOAD overlay supports rendezvous by fetching mapping 255 information between CoAP URIs and Node-IDs. 257 As an example, if a node RN located in the overlay overlay-1.com 258 wishes to read which resources are served at a RN with URI 259 coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. 260 The RESOURCE-ID used in this fetch is a SHA-1 hash over the URI 261 "coap://overlay-1.com/proxy-1/.well-known/". 263 After this fetch request, the overlay will return the following 264 result: 266 RESOURCE-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 267 KEY = 9996172, 268 VALUE = { ./temperature-1; 269 ./temperature-2; 270 ./temperature-3} 272 The obtained KEY is the Node-ID of the RN responsible of this KEY/ 273 VALUE pair. The VALUE is the set of URIs necessary to read data from 274 the CNs associated with the RN. 276 Using the RELOAD DICTIONARY model allows for multiple nodes to 277 perform a store to the same RESOURCE-ID. This feature allows for 278 performing rendezvous with multiple RNs that host CNs of the same 279 class. 281 As an example, a fetch to the URI 282 "coap://overlay-1.com/temperature/.well-known/" could return the 283 following results: 285 RESOURCE-ID = h(coap://overlay-1.com/temperature/.well-known/) 286 KEY = 9992323, 287 VALUE = { ./temperature} 289 KEY = 9996172, 290 VALUE = { ./temperature-1; 291 ./temperature-2; 292 ./temperature-3} 294 KEY = 9996173, 295 VALUE = { ./temp-a; 296 ./temp-b} 298 6. Forming a direct connection and reading data 300 Once a RN (e.g., node-A) has obtained the rendezvous information for 301 a node in the overlay (e.g., proxy-1), it can open a direct 302 connection to that node. This is performed by sending an AppAttach 303 request to the Node-ID obtained during the rendezvous process. 305 After the AppAttach negotiation, node-A can access to the values of 306 the CNs at proxy-1 using the URIs obtained during the rendezvous. 307 Following the example in Section 5, the URIs for accessing to the CNs 308 at proxy-1 would be: 310 coap://overlay-1.com/proxy-1/temperature-1 311 coap://overlay-1.com/proxy-1/temperature-2 312 coap://overlay-1.com/proxy-1/temperature-3 314 Note that the ".well-known" string has been removed from the URIs, as 315 this is only used during CNs discovery. Figure 1 shows a sample of a 316 node reading humidity data. 318 +---+ +-----+ +---------+ +-----+ +---+ 319 |CNA| | PNA | | OVERLAY | | PNB | |CNB| 320 +---+ +-----+ +---------+ +-----+ +---+ 321 | | | | | 322 | .COAP CON GET | | | | 323 | /humidity | 2.RELOAD | | | 324 |+------------->| Fetch | | | 325 | |+----------->| | | 326 | | | | | 327 | | 3.RELOAD | | | 328 | | 200 OK | | | 329 | |<-----------+| | | 330 | | | | | 331 | | 4.RELOAD | | | 332 | | Attach | | | 333 | |+----------->| | | 334 | | | 5.RELOAD | | 335 | | | Attach | | 336 | | |+---------->| | 337 | | | | | 338 | | | 6.RELOAD | | 339 | | 7.RELOAD | 200 OK | | 340 | | 200 OK |<----------+| | 341 | |<-----------+| | | 342 | | | | | 343 | | | | 344 | | --------------------- | | 345 | | / 8.ICE \| | 346 | | \ connectivity checks /| | 347 | | --------------------- | | 348 | | | | 349 | | 9.CoAP CON | | 350 | | GET humidity | | 351 | |+------------------------>| | 352 | | | 10.CoAP CON | 353 | | | GET humidity | 354 | | |+-------------->| 355 | | | 11.CoAP | 356 | | 12.CoAP | ACK 200 | 357 | 12.CoAP | ACK 200 |<--------------+| 358 | ACK 200 |<------------------------+| | 359 |<-------------+| | | 360 | | | | 362 Figure 2: An Example of a Message Sequence 364 7. Caching Mechanisms 366 The CoAP protocol itself supports the caching of sensor information 367 in order to reduce the response time and network bandwidth 368 consumption of future, equivalent requests. This storage is done in 369 CoAP proxies. 371 This CoAP usage proposes an additional caching mechanism for storing 372 sensor information directly in the overlay. This caching mechanism 373 is primarily intended for CNs with sensor capabilities, not for RN 374 sensors. This is due to the battery constrains of CNs, forcing them 375 to stay in sleep mode for long periods of time. 377 Whenever a CN wakes up, it sends the most recent data from its 378 sensors to its proxy (RN), which stores the data in the overlay using 379 a RELOAD StoredData structure defined in Section 6 of the RELOAD base 380 draft. We use the StoredDataValue structure defined in Section 6.2 381 of the RELOAD base draft, in particular we use the SingleValue format 382 type to store the cached values in the overlay. From that structure 383 length, storage_time, lifetime and Signature are used in the same 384 way. The only difference is data_value which in our case can be 385 either a ProxyCache or a SensorCache: 387 struct { 388 uint16 coap_caching_type; 390 select(coap_caching_type) { 391 case proxy_cache: ProxyCache proxy_cache_entry; 392 case sensor_cache: SensorCache sensor_cache_entry; 394 /* extensions */ 396 } 397 } CoAPCaching; 399 7.1. ProxyCache 401 ProxyCache is meant to store values and sensor information (e.g. 402 inactivity time) for all the sensors associated with a certain proxy, 403 as well as their CoAP URIs. On the other hand, SensorCache is used 404 for storing the information and cached value of only one sensor (CoAP 405 URI is not necessary, as is the same as the one used for generating 406 the Resource-ID associated to that SensorCache entry). 408 ProxyCache contains the fields NodeId and series of SensorEntry 409 types. 411 struct { 412 NodeId Node_ID; 413 SensorEntry sensors[]; 414 } ProxyCache; 416 NodeId 417 The NodeID of the Proxy Node (PN) responsible for different sensor 418 devices; 419 SensorEntry 420 List of sensors in the form of SensorEntry types; 422 SensorEntry contains the coap_uri, sensor_info and a series of 423 SensorValue types. 425 struct { 426 opaque coap_uri; 427 SensorInfo sensor_info; 428 SensorValue sensor_value[]; 429 } SensorEntry; 431 coap_uri 432 CoAP name of the sensor device in question; 433 sensor_info 434 contains relevant sensor information; 435 sensor_value 436 contains a list of values stored by the sensor; 438 7.2. SensorCache 440 SensorCache: contains the information related to one sensor. 442 struct { 443 NodeId Node_ID; 444 SensorInfo sensor_info; 445 SensorValue sensor_value[]; 446 } SensorCache; 448 Node_ID 449 identifies the NodeID of the Proxy Node responsible for the 450 sensor; 451 sensor_info 452 contains relevant sensor information; 453 sensor_value 454 contains a list of values stored by the sensor; 456 SensorInfo contains relevant sensor information, such as sensor_type, 457 duration_of_inactivity and last_awake fields. 459 struct { 460 integer sensor_type; 461 uint32 duration_of_inactivity; 462 uint32 last_awake; 464 /* extensions */ 466 } SensorInfo; 468 sensor_type 469 is an integer identifying the type of the sensor. See Figure 3; 470 duration_of_inactivity 471 contains the sleep pattern (if any) that the sensor device 472 follows, specified in seconds; 473 last_awake 474 indicates the last time that the sensor was awake in UNIX time; 476 SensorValue contains the measurement_time, lifetime and value. 478 struct { 479 uint32 measurement_time; 480 uint32 lifetime; 481 opaque value; 483 /* extensions */ 485 } SensorValue; 487 measurement_time 488 indicates the moment in which the measure was taken; 489 lifetime 490 indicates the validity time of that measured value; 491 value 492 indicates the actual value measured. It can be of different types 493 (integer, long, string) therefore opaque has been used; 495 8. CoAP Usage Kinds Definition 497 This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds. 499 8.1. CoAP-REGISTRATION Kind 500 Kind IDs 501 The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP 502 URI. The data stored is a CoAPRegistration, which contains a 503 Node-ID and a set of CoAP URIs. 504 Data Model 505 The data model for the CoAP-REGISTRATION Kind-ID is dictionary. 506 The dictionary key is the Node-ID of the storing RN. This allows 507 each RN to store a single mapping. 508 Access Control 509 URI-NODE-MATCH. The "coap:" prefix needs to be removed from the 510 COAP URI before matching. 512 Data stored under the COAP-REGISTRATION kind is of type 513 CoAPRegistration, defined below. 515 struct { 516 uint16 coap_uris_length; 517 opaque coap_uris (0..2^16-1); 518 } CoAPRegistration; 520 8.2. CoAP-CACHING Kind 521 KindIDs 522 The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. 523 The data stored is a CoAPCaching, which contains a Node-ID and a 524 value. 525 Data Model 526 The data model for the CoAP-CACHING Kind-ID is single value. 527 Access Control 528 URI-MATCH. The "coap:" prefix needs to be removed from the COAP 529 URI before matching. 531 Data stored under the CoAP-CACHING kind is of type CoAPCaching, 532 defined in Section 7 . 534 9. Security Considerations 536 TBD. 538 10. IANA Considerations 540 10.1. RELOAD Sensor Type Registry 542 IANA SHALL create a "RELOAD sensor type" Registry. Entries in this 543 registry are 16-bit integers denoting method codes as described in 544 Section 7. The initial contents of this registry are: 546 +-----------------+-------+ 547 | Code Name | Value | 548 +-----------------+-------+ 549 | temperature | 0 | 550 | humidity | 1 | 551 | acceleration | 2 | 552 | pressure | 3 | 553 | altitude | 4 | 554 | luminance | 5 | 555 | velocity | 6 | 556 | signal_strength | 7 | 557 | battery | 8 | 558 | heart_rate | 9 | 559 +-----------------+-------+ 561 Figure 3 563 10.2. CoAP-REGISTRATION Kind-ID 565 This document introduces one additional data Kind-ID to the "RELOAD 566 Data Kind-ID" Registry: 568 +-------------------+------------+----------+ 569 | Kind | Kind-ID | RFC | 570 +-------------------+------------+----------+ 571 | CoAP-REGISTRATION | 105 | RFC-AAAA | 572 +-------------------+------------+----------+ 574 This Kind-ID was defined in Section 4. 576 10.3. CoAP-CACHING Kind-ID 578 This document introduces one additional data Kind-ID to the "RELOAD 579 Data Kind-ID" Registry: 581 +--------------+------------+----------+ 582 | Kind | Kind-ID | RFC | 583 +--------------+------------+----------+ 584 | CoAP-CACHING | 106 | RFC-AAAA | 585 +--------------+------------+----------+ 587 This Kind-ID was defined in Section 4. 589 11. References 590 11.1. Normative References 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 [I-D.ietf-core-coap] 596 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 597 "Constrained Application Protocol (CoAP)", 598 draft-ietf-core-coap-08 (work in progress), October 2011. 600 [I-D.ietf-p2psip-base] 601 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 602 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 603 Base Protocol", draft-ietf-p2psip-base-20 (work in 604 progress), January 2012. 606 11.2. Informative References 608 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 609 A., Peterson, J., Sparks, R., Handley, M., and E. 610 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 611 June 2002. 613 Authors' Addresses 615 Jaime Jimenez 616 Ericsson 617 Hirsalantie 11 618 Jorvas 02420 619 Finland 621 Email: jaime.j.jimenez@ericsson.com 623 Jose M. Lopez-Vega 624 University of Granada 625 CITIC-UGR Periodista Rafael Gomez Montero 2 626 Granada 18071 627 Spain 629 Email: jmlvega@ugr.es 630 Jouni Maenpaa 631 Ericsson 632 Hirsalantie 11 633 Jorvas 02420 634 Finland 636 Email: jouni.maenpaa@ericsson.com 638 Gonzalo Camarillo 639 Ericsson 640 Hirsalantie 11 641 Jorvas 02420 642 Finland 644 Email: gonzalo.camarillo@ericsson.com