idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 01, 2013) is 3859 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: 'RFCXXXX' is mentioned on line 436, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-13 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-security-options-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XR Block Working Group J. Ott 3 Internet-Draft V. Singh, Ed. 4 Intended status: Standards Track Aalto University 5 Expires: April 04, 2014 I. Curcio 6 Nokia Research Center 7 October 01, 2013 9 RTP Control Protocol (RTCP) Extended Report (XR) for Run Length Encoding 10 (RLE) of Discarded Packets 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-07 13 Abstract 15 The RTP Control Protocol (RTCP) is used in conjunction with the Real- 16 time Transport Protocol (RTP) in to provide a variety of short-term 17 and long-term reception statistics. The available reporting may 18 include aggregate information across longer periods of time as well 19 as individual packet reporting. This document specifies a per-packet 20 report metric capturing individual packets discarded from the de- 21 jitter buffer after successful reception. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 04, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. XR Discard RLE Report Block . . . . . . . . . . . . . . . . . 4 60 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 5 62 4.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . 6 63 5. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. XR Report Block Registration . . . . . . . . . . . . . . 7 67 7.2. SDP Parameter Registration . . . . . . . . . . . . . . . 7 68 7.3. Contact information for IANA registrations . . . . . . . 8 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Metrics represented using RFC6390 Template . . . . . 9 74 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10 75 B.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 76 metrics-00 . . . . . . . . . . . . . . . . . . . . . . . 10 77 B.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 78 metrics-01 . . . . . . . . . . . . . . . . . . . . . . . 10 79 B.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 80 metrics-02 . . . . . . . . . . . . . . . . . . . . . . . 10 81 B.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 82 metrics-03 . . . . . . . . . . . . . . . . . . . . . . . 10 83 B.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 84 metrics-04 . . . . . . . . . . . . . . . . . . . . . . . 11 85 B.6. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 86 metrics-05 . . . . . . . . . . . . . . . . . . . . . . . 11 87 B.7. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 88 metrics-06 . . . . . . . . . . . . . . . . . . . . . . . 11 89 B.8. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 90 metrics-07 . . . . . . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 RTP [RFC3550] provides a transport for real-time media flows such as 96 audio and video together with the RTP control protocol (RTCP) which 97 provides periodic feedback about the media streams received in a 98 specific duration. In addition, RTCP can be used for timely feedback 99 about individual events to report (e.g., packet loss) [RFC4585]. 100 Both long-term and short-term feedback enable a media sender to adapt 101 its media transmission and/or encoding dynamically to the observed 102 path characteristics. 104 RFC3611 [RFC3611] defines RTCP Extended Reports as a detailed 105 reporting framework to provide more than just the coarse Receiver 106 Report (RR) statistics. The detailed reporting may enable a media 107 sender to react more appropriately to the observed networking 108 conditions as these can be characterized better, although at the 109 expense of extra overhead. 111 Among many other report blocks, RFC3611 specifies the Loss Run Length 112 Encoding (RLE) block which reports runs of packets received and lost 113 with the granularity of individual packets. This can help both error 114 recovery and path loss characterization. In addition to lost 115 packets, RFC3611 defines the notion of "discarded" packets: packets 116 that were received but dropped from the de-jitter buffer because they 117 were either too early (for buffering) or too late (for playout). The 118 "discard rate" metric is part of the VoIP metrics report block even 119 though it is not just applicable to audio: it is specified as the 120 fraction of discarded packets since the beginning of the session. 121 See section 4.7.1 of RFC3611 [RFC3611]. The discard metric is 122 believed to be applicable to a large class of RTP applications which 123 use a de-jitter buffer RFC5481 [RFC5481]. 125 Recently proposed extensions to the Extended Reports (XR) reporting 126 suggest enhancing this discard metric: 128 o Reporting the number of discarded packets in a measurement 129 interval, i.e., during either the last reporting interval or since 130 the beginning of the session, as indicated by a flag in the 131 suggested XR report [I-D.ietf-xrblock-rtcp-xr-discard]. If an 132 endpoint needs to report packet discard due to other reasons than 133 early- and late-arrival (for example, discard due to duplication, 134 redundancy, etc.) then it should consider using the Discarded 135 Packets Report Block [I-D.ietf-xrblock-rtcp-xr-discard]. 137 o Reporting gaps and bursts of discarded packets during a 138 measurement interval, i.e., the last reporting interval or the 139 duration of the session 140 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. 142 o Reporting the sum of payload bytes discarded during a measurement 143 interval, i.e., the last reporting interval or the duration of the 144 session [I-D.singh-xrblock-rtcp-xr-bytes-discarded-metric]. 146 However, none of these metrics allow a receiver to report precisely 147 which packets were discarded. While this information could in theory 148 be derived from high-frequency reporting on the number of discarded 149 packets [I-D.ietf-xrblock-rtcp-xr-discard] or from the gap/burst 150 report [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], these two 151 mechanisms do not appear feasible: The former would require an unduly 152 high amount of reporting which still might not be sufficient due to 153 the non-deterministic scheduling of RTCP packets. The latter incur 154 significant complexity and reporting overhead and might still not 155 deliver the desired accuracy. 157 This document defines a discard report block following the idea of 158 the run-length encoding applied for lost and received packets in 159 [RFC3611]. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in BCP 14, RFC 2119 166 [RFC2119]. 168 The terminology defined in RTP [RFC3550] and in the extensions for XR 169 reporting [RFC3611] applies. 171 3. XR Discard RLE Report Block 173 The XR Discard RLE report block uses the same format as specified for 174 the loss and duplicate report blocks in [RFC3611]. Figure 1 175 describes the packet format. The fields "BT", "T", "block length", 176 "SSRC of source", "begin_seq", and "end_seq" have the same semantics 177 and representation as defined in [RFC3611], with the addition of the 178 "E" flag to indicate the reason for discard. The "chunks" encoding 179 the run length have the same representation as in RFC3611, but encode 180 discarded packets. A definition of a discarded packet is given in 181 [I-D.ietf-xrblock-rtcp-xr-discard]. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | BT=DRLE |rsvd |E| T | block length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SSRC of source | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | begin_seq | end_seq | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | chunk 1 | chunk 2 | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 : ... : 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | chunk n-1 | chunk n | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: XR Discard RLE Report Block 201 Block Type (BT, 8 bits): A Run-length encoded Discarded Packets 202 Report Block is identified by the constant DRLE. 204 [Note to RFC Editor: please replace DRLE with the IANA provided RTCP 205 XR block type for this block. Please remove this note prior to 206 publication as an RFC.] 208 rsvd (3 bits): This field is reserved for future definition. In the 209 absence of such definition, the bits in this field MUST be set to 210 zero and MUST be ignored by the receiver. 212 The 'E' bit is introduced to distinguish between packets discarded 213 due to early arrival and those discarded due to late arrival. The 214 'E' bit is set to '1' if the chunks represent packets discarded due 215 to too early arrival and is set to '0' otherwise. 217 In case both early and late discarded packets shall be reported, two 218 Discard RLE report blocks MUST be included; their sequence number 219 range MAY overlap, but individual packets MUST only be reported as 220 either early or late and not appear marked in both. If packets 221 appear in both report blocks, the conflicting packets are ignored. 222 Packets reported in neither are considered to be properly received 223 and not discarded. 225 Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP 226 RR as a compound RTCP packet. 228 4. Protocol Operation 230 This section describes the behavior of the reporting node (= media 231 receiver) and the media sender. 233 4.1. Reporting Node (Receiver) 235 Transmission of RTCP XR Discard RLE Reports is up to the discretion 236 of the media receiver, as is the reporting granularity. However, it 237 is RECOMMENDED that the media receiver signals all discarded packets 238 using the method defined in this document. If all packets over a 239 reporting period were discarded, the media receiver MAY use the 240 Discard Report Block [I-D.ietf-xrblock-rtcp-xr-discard] instead. In 241 case of limited available reporting bandwidth, it is up to the 242 receiver whether or not to include RTCP XR Discard RLE reports. 244 The media receiver MAY send the Discard RLE Reports as part of the 245 regularly scheduled RTCP packets as per RFC3550. It MAY also include 246 Discard RLE Reports in immediate or early feedback packets as per 247 RFC4585. 249 4.2. Media Sender 251 The media sender MUST be prepared to operate without receiving any 252 Discard RLE reports. If Discard RLE reports are generated by the 253 media receiver, the media sender cannot rely on all these reports 254 being received, nor can the media sender rely on a regular generation 255 pattern from the media receiver. 257 However, if the media sender receives any RTCP reports but no Discard 258 RLE report blocks and is aware that the media receiver supports 259 Discard RLE report blocks, it MAY assume that no packets were 260 discarded at the media receiver. 262 5. SDP signaling 264 A participant of a media session MAY use SDP to signal its support 265 for the report block specified in this document or use them without 266 any prior signaling (see section 5 of [RFC3611]). 268 For signaling in SDP, the RTCP XR attribute as defined in [RFC3611] 269 MUST be used. The SDP [RFC4566] attribute 'xr-format' defined in 270 RFC3611 is augmented as described in the following to indicate the 271 the discard RLE metric. 273 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 274 CRLF ; defined in [RFC3611] 276 xr-format =/ xr-discard-rle 278 xr-discard-rle = "discard-rle" 280 The parameter 'discard-rle' is used to indicate support for the 281 Discard RLE Report Block defined in Section 3. 283 When SDP is used in Offer/Answer context, the mechanism defined in 284 [RFC3611] for unilateral "rtcp-xr" attribute parameters applies (see 285 section 5.2 of [RFC3611]). 287 6. Security Considerations 289 The Discard RLE block provides per-packet statistics so the risk to 290 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 291 applies. In some situations, returning very detailed error 292 information (e.g., over-range measurement or measurement unavailable) 293 using this report block can provide an attacker with insight into the 294 security processing. Implementers should consider the guidance in 295 [I-D.ietf-avt-srtp-not-mandatory] for using appropriate security 296 mechanisms, i.e., where security is a concern, the implementation 297 should apply encryption and authentication to the report block. For 298 example this can be achieved by using the AVPF profile together with 299 the Secure RTP profile as defined in [RFC3711]; an appropriate 300 combination of the two profiles (an "SAVPF") is specified in 301 [RFC5124]. However, other mechanisms also exist (documented in 302 [I-D.ietf-avtcore-rtp-security-options]) and might be more suitable. 304 Additionally, The security considerations of [RFC3550], [RFC3611], 305 and [RFC4585] apply. 307 7. IANA Considerations 309 New block types for RTCP XR are subject to IANA registration. For 310 general guidelines on IANA considerations for RTCP XR, refer to 311 [RFC3611]. 313 7.1. XR Report Block Registration 315 This document extends the IANA "RTP Control Protocol Extended Reports 316 (RTCP XR) Block Type Registry" by a new value: DRLE (Discard RLE 317 Report). 319 [Note to RFC Editor: please replace DRLE with the IANA provided RTCP 320 XR block type for this block here and in the diagrams above. Please 321 remove this note prior to publication as an RFC.] 323 7.2. SDP Parameter Registration 325 This document registers a new parameters for the Session Description 326 Protocol (SDP), "discard-rle" in the "RTP Control Protocol Extended 327 Reports (RTCP XR) Session Description Protocol (SDP) Parameters 328 Registry". 330 7.3. Contact information for IANA registrations 332 Joerg Ott (jo@comnet.tkk.fi) 334 Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. 336 8. Acknowledgments 338 The authors would like to thank Alan Clark, Roni Even, Sam Hartman, 339 Colin Perkins, Dan Romascanu, Dan Wing, and Qin Wu for providing 340 valuable feedback on earlier versions of this draft. 342 9. References 344 9.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 350 Jacobson, "RTP: A Transport Protocol for Real-Time 351 Applications", STD 64, RFC 3550, July 2003. 353 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 354 Protocol Extended Reports (RTCP XR)", RFC 3611, November 355 2003. 357 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 358 "Extended RTP Profile for Real-time Transport Control 359 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 360 2006. 362 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 363 Description Protocol", RFC 4566, July 2006. 365 [I-D.ietf-xrblock-rtcp-xr-discard] 366 Clark, A., Zorn, G., and W. Wu, "RTP Control Protocol 367 (RTCP) Extended Report (XR) Block for Discard Count metric 368 Reporting", draft-ietf-xrblock-rtcp-xr-discard-15 (work in 369 progress), June 2013. 371 9.2. Informative References 373 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 374 Clark, A., Huang, R., and W. Wu, "RTP Control 375 Protocol(RTCP) Extended Report (XR) Block for Burst/Gap 376 Discard metric Reporting", draft-ietf-xrblock-rtcp-xr- 377 burst-gap-discard-14 (work in progress), April 2013. 379 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 380 Applicability Statement", RFC 5481, March 2009. 382 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 383 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 384 RFC 3711, March 2004. 386 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 387 Real-time Transport Control Protocol (RTCP)-Based Feedback 388 (RTP/SAVPF)", RFC 5124, February 2008. 390 [I-D.ietf-avt-srtp-not-mandatory] 391 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 392 Framework: Why RTP Does Not Mandate a Single Media 393 Security Solution", draft-ietf-avt-srtp-not-mandatory-13 394 (work in progress), May 2013. 396 [I-D.ietf-avtcore-rtp-security-options] 397 Westerlund, M. and C. Perkins, "Options for Securing RTP 398 Sessions", draft-ietf-avtcore-rtp-security-options-04 399 (work in progress), July 2013. 401 [I-D.singh-xrblock-rtcp-xr-bytes-discarded-metric] 402 Singh, V., Ott, J., and I. Curcio, "RTP Control Protocol 403 (RTCP) Extended Reports (XR) for Bytes Discarded Metric", 404 draft-singh-xrblock-rtcp-xr-bytes-discarded-metric-00 405 (work in progress), August 2013. 407 Appendix A. Metrics represented using RFC6390 Template 409 RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC 410 number, when assigned. 412 a. Run-length encoding (RLE) of Discarded Packets Metric 414 * Metric Name: Discard Run-length encoding Metric 416 * Metric Description: Instances of packets discarded over the 417 period covered by this report. 419 * Method of Measurement or Calculation: See section 3, for the 420 definition of Discard RLE [RFCXXXX] and section 4.1 of RFC3611 421 for Run-length encoding. 423 * Units of Measurement: Every packet in the interval is reported 424 as discarded or not. See section 3 for the definition of 425 Discard RLE [RFCXXXX]. 427 * Measurement Point(s) with Potential Measurement Domain: The 428 measurement of these metrics is made at the receiving end of 429 the RTP stream. 431 * Measurement Timing: Each packet between a beginning sequence 432 number (begin_seq) and ending sequence number (end_seq) are 433 reported as discarded or not. See section 3 for the 434 definition of Discard RLE [RFCXXXX]. 436 * Use and applications: See section 1, paragraph 1 of [RFCXXXX]. 438 * Reporting model: See RFC3611. 440 Appendix B. Change Log 442 Note to the RFC-Editor: please remove this section prior to 443 publication as an RFC. 445 B.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 447 o Changed the interval flag from 1 to 2 bits in the discarded bytes 448 report. Also added the measurement identification tag to the 449 block. 451 o Added this section. 453 B.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 455 o Removed the measurement identification tag in the bytes discarded 456 block. 458 B.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 460 o Removed the extra Tag bits from the Discarded bytes XR block. 462 o Clarified use of measurement identity block in Section 4 and 5.2 464 B.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 466 o Added explanation for block length in bytes discarded block. 468 o Added an acknowledgement section. 470 B.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 472 o Added Block Type definition to each XRBlock. 474 o Made changes requested in WGLC. 476 B.6. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 478 o Made changes requested by SDP directorate. 480 B.7. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 482 o Editorial fixes based on review from Gen-art and IESG review. 484 B.8. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-07 486 o Editorial fixes based on review from IESG. 488 o Editorial fixes based on Security and PM directorate. 490 o Split bytes discarded from this draft to another. 492 o Updated Security Considerations Section. 494 o This draft now normatively cites the definition of discards in 495 'packets discarded' draft. 497 Authors' Addresses 499 Joerg Ott 500 Aalto University 501 School of Electrical Engineering 502 Otakaari 5 A 503 Espoo, FIN 02150 504 Finland 506 Email: jo@comnet.tkk.fi 508 Varun Singh (editor) 509 Aalto University 510 School of Electrical Engineering 511 Otakaari 5 A 512 Espoo, FIN 02150 513 Finland 515 Email: varun@comnet.tkk.fi 516 URI: http://www.netlab.tkk.fi/~varun/ 517 Igor D.D. Curcio 518 Nokia Research Center 519 P.O. Box 1000 (Visiokatu 3) 520 Tampere, FIN 33721 521 Finland 523 Email: igor.curcio@nokia.com