From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7005.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc7005.txt (limited to 'doc/rfc/rfc7005.txt') diff --git a/doc/rfc/rfc7005.txt b/doc/rfc/rfc7005.txt new file mode 100644 index 0000000..953feb2 --- /dev/null +++ b/doc/rfc/rfc7005.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Clark +Request for Comments: 7005 Telchemy +Category: Standards Track V. Singh +ISSN: 2070-1721 Aalto University + Q. Wu + Huawei + September 2013 + + + RTP Control Protocol (RTCP) Extended Report (XR) Block + for De-Jitter Buffer Metric Reporting + +Abstract + + This document defines an RTP Control Protocol (RTCP) Extended Report + (XR) block that allows the reporting of de-jitter buffer metrics for + a range of RTP applications. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7005. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Clark, et al. Standards Track [Page 1] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. De-Jitter Buffer Metrics Block . . . . . . . . . . . . . . 3 + 1.2. RTCP and RTCP Extended Reports . . . . . . . . . . . . . . 3 + 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 + 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Standards Language . . . . . . . . . . . . . . . . . . . . . . 4 + 3. De-Jitter Buffer Operation . . . . . . . . . . . . . . . . . . 4 + 3.1. Idealized De-Jitter Buffer . . . . . . . . . . . . . . . . 4 + 3.2. Fixed De-Jitter Buffer . . . . . . . . . . . . . . . . . . 5 + 3.3. Adaptive De-Jitter Buffer . . . . . . . . . . . . . . . . 5 + 4. De-Jitter Buffer Metrics Block . . . . . . . . . . . . . . . . 6 + 4.1. Report Block Structure . . . . . . . . . . . . . . . . . . 6 + 4.2. Definition of Fields in De-Jitter Buffer Metrics Block . . 6 + 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 9 + 5.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 9 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . . 9 + 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 10 + 6.3. Contact Information for Registrations . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Appendix A. Metrics Represented Using the Template from + RFC 6390 . . . . . . . . . . . . . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + + +Clark, et al. Standards Track [Page 2] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + +1. Introduction + +1.1. De-Jitter Buffer Metrics Block + + This document defines a new block type to augment those defined in + [RFC3611] for use in a range of RTP applications. + + The new block type provides information on de-jitter buffer + configuration and performance. + + The metric belongs to the class of transport-related end-system + metrics defined in [RFC6792]. + + Instances of this metrics block refer by synchronization source + (SSRC) to the separate auxiliary Measurement Information Block + [RFC6776], which contains information such as the SSRC of the + measured stream, and RTP sequence numbers and time intervals + indicating the span of the report. + +1.2. RTCP and RTCP Extended Reports + + The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] + defines an extensible structure for reporting using an RTCP Extended + Report (XR). This document defines a new Extended Report block for + use with [RFC3550] and [RFC3611]. + +1.3. Performance Metrics Framework + + "Guidelines for Considering New Performance Metric Development" + [RFC6390] provides guidance on the definition and specification of + performance metrics. "Guidelines for Use of the RTP Monitoring + Framework" [RFC6792] provides guidance on the reporting block format + using RTCP XR. Metrics described in this document are in accordance + with the guidelines in [RFC6390]and [RFC6792]. + +1.4. Applicability + + Real-time applications employ a de-jitter buffer [RFC5481] to absorb + jitter introduced on the path from source to destination. These + metrics are used to report how the de-jitter buffer at the receiving + end of the RTP stream behaves as a result of jitter in the network; + they are applicable to a range of RTP applications. + + These metrics correspond to terminal-related factors that affect + real-time application quality and are useful for providing a better + end-user quality of experience (QoE) when these terminal-related + factors are used as inputs to calculate QoE metrics [QMB]. + + + + +Clark, et al. Standards Track [Page 3] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + +2. Standards Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +3. De-Jitter Buffer Operation + + A de-jitter buffer is required to absorb delay variation in the + network delivery of media packets. A de-jitter buffer works by + holding media data for a period of time after it is received and + before it is played out. Packets that arrive early are held in the + de-jitter buffer longer. If packets arrive too early, they may be + discarded if there is no available de-jitter buffer space. If + packets are delayed excessively by the network, they may be discarded + if they miss their playout time. + + The de-jitter buffer can be considered a time window with the early + edge aligned with the delay corresponding to the earliest arriving + packet and the late edge representing the maximum permissible delay + before a late arriving packet would be discarded. The delay applied + to packets that arrive on time or at their expected arrival time is + known as the nominal delay, and this is equivalent to the time + difference/buffer size difference between the insertion point of the + on-time packets and the point at which the packets are read out. + + The reference for the expected arrival time may be, for example, the + first packet in the session or the running average delay. If all + packets arrived at their expected arrival time, then every packet + would be held in the de-jitter buffer exactly the nominal delay. + + The de-jitter buffer maximum delay is the delay that is applied to + the earliest arriving packet that is not discarded and corresponds to + the early edge of the de-jitter buffer time window. + +3.1. Idealized De-Jitter Buffer + + In practice, de-jitter buffer implementations vary considerably; + however, they should behave in a manner conceptually consistent with + an idealized de-jitter buffer, which is described as follows: + + + + + + + + + + + +Clark, et al. Standards Track [Page 4] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + + (i) Receive the first packet and delay playout by D ms. Keep the + RTP timestamp (TS) and receive time as a reference. + + RTP TS[1] + + receive time[1] + + Assume that both are normalized in ticks (there are 10,000 + ticks in a millisecond). + + (ii) Receive the next packet. + + (iii) Calculate r = RTP TS[n] - RTP TS[1] and t = receive time[n] - + receive time[1]. If r == t, then the packet arrived on time. + If r < t, then the packet arrived late, and if r > t, then the + packet arrived early. + + (iv) Delay playout of packet by D + (r-t). + + (v) Go back to (ii). + + Note that this idealized implementation assumes that the sender's RTP + clock is synchronized to the clock in the receiver, which is used to + timestamp packet arrivals. If there is no such inherent + synchronization, the system may need to use an adaptive de-jitter + buffer or other techniques to ensure reliable reception. + +3.2. Fixed De-Jitter Buffer + + A fixed de-jitter buffer lacks provision to track the condition of + the network and has a fixed size, and packets leaving the de-jitter + buffer have a constant delay. For fixed de-jitter buffer + implementation, the nominal delay is set to a constant value + corresponding to the packets that arrive at their expected arrival + time, while the maximum delay is set to a constant value + corresponding to the fixed size of the de-jitter buffer. + +3.3. Adaptive De-Jitter Buffer + + An adaptive de-jitter buffer can adapt to the change in the network's + delay and has variable size or variable delay. It allows the nominal + delay to be set to a low value initially to minimize user perceived + delay; however, it can automatically extend the late edge (and + possibly also retract the early edge) of a buffer window if a + significant proportion of the packets are arriving late (and hence + being discarded). + + + + + +Clark, et al. Standards Track [Page 5] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + +4. De-Jitter Buffer Metrics Block + + This block describes the configuration and operating parameters of + the de-jitter buffer in the receiver of the RTP end system or RTP + mixer that sends the report. Instances of this metrics block use the + SSRC to refer to the separate auxiliary Measurement Information Block + [RFC6776], which describes the measurement periods in use (see + [RFC6776], Section 4.2). This metrics block relies on the + measurement interval in the Measurement Information Block indicating + the span of the report and MUST be sent in the same compound RTCP + packet as the Measurement Information Block. If the measurement + interval is not received in the same compound RTCP packet as this + metrics block, this metrics block MUST be discarded. + +4.1. Report Block Structure + + De-Jitter Buffer (DJB) Metrics Block + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BT=23 | I |C| resv | Block Length=3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SSRC of Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DJB nominal | DJB maximum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DJB high-water mark | DJB low-water mark | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Report Block Structure + +4.2. Definition of Fields in De-Jitter Buffer Metrics Block + + Block Type (BT): 8 bits + + A De-Jitter Buffer Metrics Report Block is identified by the + constant 23. + + Interval Metric flag (I): 2 bits + + This field is used to indicate whether the de-jitter buffer + metrics are Sampled, Interval, or Cumulative metrics: + + I=01: Sampled Value - the reported value is a sampled + instantaneous value. + + + + + +Clark, et al. Standards Track [Page 6] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + + I=10: Interval Duration - the reported value applies to the + most recent measurement interval duration between successive + metrics reports. + + I=11: Cumulative Duration - the reported value applies to the + accumulation period characteristic of cumulative measurements. + + In this document, de-jitter buffer metrics can only be sampled and + cannot be measured over definite intervals. Also, the value I=00 + is reserved for future use. Senders MUST NOT use the values I=00, + I=10, or I=11. If a block is received with I=00, I=10, or I=11, + the receiver MUST discard the block. + + Jitter Buffer Configuration (C): 1 bit + + This field is used to identify the de-jitter buffer method in use + at the receiver, according to the following code: + + 0 = Fixed de-jitter buffer + + 1 = Adaptive de-jitter buffer + + Reserved (resv): 5 bits + + These bits are reserved. They MUST be set to zero by senders and + ignored by receivers (see [RFC6709], Section 4.2). + + Block Length: 16 bits + + The length of this report block in 32-bit words, minus one, in + accordance with the definition in [RFC3611]. This field MUST be + set to 3 to match the fixed length of the report block. + + SSRC of Source: 32 bits + + As defined in Section 4.1 of [RFC3611]. + + De-jitter buffer nominal delay (DJB nominal): 16 bits + + This is the current nominal de-jitter buffer delay (in + milliseconds) that corresponds to the nominal de-jitter buffer + delay for packets that arrive exactly on time. It is calculated + based on the time spent in the de-jitter buffer for the packet + that arrives exactly on time. This parameter MUST be provided for + both fixed and adaptive de-jitter buffer implementations. + + + + + + +Clark, et al. Standards Track [Page 7] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + + The measured value is an unsigned value. If the measured value + exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an + over-range measurement. If the measurement is unavailable, the + value 0xFFFF MUST be reported. + + De-jitter buffer maximum delay (DJB maximum): 16 bits + + This is the current maximum de-jitter buffer delay (in + milliseconds) that corresponds to the earliest arriving packet + that would not be discarded. It is calculated based on the time + spent in the de-jitter buffer for the earliest arriving packet. + In simple queue implementations, this may correspond to the size + of the de-jitter buffer. In adaptive de-jitter buffer + implementations, this value may vary dynamically. This parameter + MUST be provided for both fixed and adaptive de-jitter buffer + implementations. + + The measured value is an unsigned value. If the measured value + exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an + over-range measurement. If the measurement is unavailable, the + value 0xFFFF MUST be reported. + + De-jitter buffer high-water mark (DJB high-water mark): 16 bits + + This is the highest value of the de-jitter buffer nominal delay + (in milliseconds) that occurred at any time during the reporting + interval. This parameter MUST be provided for adaptive de-jitter + buffer implementations, and its value MUST be set to DJB maximum + for fixed de-jitter buffer implementations. + + The measured value is an unsigned value. If the measured value + exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an + over-range measurement. If the measurement is unavailable, the + value 0xFFFF MUST be reported. + + De-jitter buffer low-water mark (DJB low-water mark): 16 bits + + This is the lowest value of the de-jitter buffer nominal delay (in + milliseconds) that occurred at any time during the reporting + interval. This parameter MUST be provided for adaptive de-jitter + buffer implementations, and its value MUST be set to DJB maximum + for fixed de-jitter buffer implementations. + + The measured value is an unsigned value. If the measured value + exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an + over-range measurement. If the measurement is unavailable, the + value 0xFFFF MUST be reported. + + + + +Clark, et al. Standards Track [Page 8] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + +5. SDP Signaling + + [RFC3611] defines the use of the Session Description Protocol (SDP) + [RFC4566] for signaling the use of XR blocks. However, XR blocks MAY + be used without prior signaling (see Section 5 of RFC 3611). + +5.1. SDP rtcp-xr-attrib Attribute Extension + + This section augments the SDP [RFC4566] attribute "rtcp-xr" defined + in [RFC3611] by providing an additional value of "xr-format" to + signal the use of the report block defined in this document. + + xr-format =/ xr-djb-block + + xr-djb-block = "de-jitter-buffer" + +5.2. Offer/Answer Usage + + When SDP is used in Offer/Answer context [RFC3264], the SDP Offer/ + Answer usage defined in [RFC3611] for unilateral "rtcp-xr" attribute + parameters applies. For detailed usage of Offer/Answer for + unilateral parameters, refer to Section 5.2 of [RFC3611]. + +6. IANA Considerations + + New block types for RTCP XR are subject to IANA registration. For + general guidelines on IANA considerations for RTCP XR, refer to + [RFC3611]. + +6.1. New RTCP XR Block Type Value + + This document assigns the block type value 23 in the IANA "RTP + Control Protocol Extended Reports (RTCP XR) Block Type Registry" to + the "De-Jitter Buffer Metrics Block". + +6.2. New RTCP XR SDP Parameter + + This document also registers a new parameter "de-jitter-buffer" in + the "RTP Control Protocol Extended Reports (RTCP XR) Session + Description Protocol (SDP) Parameters Registry". + + + + + + + + + + + +Clark, et al. Standards Track [Page 9] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + +6.3. Contact Information for Registrations + + The contact information for registrations is: + + Qin Wu (sunseawq@huawei.com) + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + +7. Security Considerations + + It is believed that this RTCP XR block introduces no new security + considerations beyond those described in [RFC3611]. This block does + not provide per-packet statistics, so the risk to confidentiality + documented in Section 7, paragraph 3 of [RFC3611] does not apply. + +8. Contributors + + Geoff Hunt wrote the initial draft of this document. + +9. Acknowledgments + + The authors gratefully acknowledge reviews and feedback provided by + Bruce Adams, Philip Arden, Amit Arora, Claire Bi, Bob Biskner, Benoit + Claise, Kevin Connor, Claus Dahm, Spencer Dawkins, Randy Ethier, Roni + Even, Jim Frauenthal, Kevin Gross, Albert Higashi, Tom Hock, Shane + Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy + Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Dan Romascanu, + Albrecht Schwarz, Tom Taylor, Hideaki Yamada, and Glen Zorn. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + June 2002. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control + Protocol Extended Reports (RTCP XR)", RFC 3611, + November 2003. + + + +Clark, et al. Standards Track [Page 10] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information + Reporting Using a Source Description (SDES) Item and an + RTCP Extended Report (XR) Block", RFC 6776, October 2012. + +10.2. Informative References + + [QMB] Clark, A., "RTP Control Protocol (RTCP) Extended Report + (XR) Blocks for QoE Metric Reporting", Work in Progress, + May 2013. + + [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation + Applicability Statement", RFC 5481, March 2009. + + [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New + Performance Metric Development", BCP 170, RFC 6390, + October 2011. + + [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, + September 2012. + + [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the + RTP Monitoring Framework", RFC 6792, November 2012. + + + + + + + + + + + + + + + + + + + + + + + + + +Clark, et al. Standards Track [Page 11] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + +Appendix A. Metrics Represented Using the Template from RFC 6390 + + a. De-Jitter Buffer Nominal Delay Metric + + * Metric Name: De-jitter buffer nominal delay in RTP + + * Metric Description: The "expected arrival time" is the time + that an RTP packet would arrive if there was no delay + variation. The delay applied to packets that arrive at their + expected time is known as the Nominal Delay. + + * Method of Measurement or Calculation: See Section 4.2, + de-jitter buffer nominal delay definition. + + * Units of Measurement: See Section 4.2, de-jitter buffer + nominal delay definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4. + + * Measurement Timing: See Section 4 for measurement timing and + Section 4.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + b. De-Jitter Buffer Maximum Delay Metric + + * Metric Name: De-jitter buffer maximum delay in RTP. + + * Metric Description: It is the current maximum de-jitter buffer + delay for RTP traffic that corresponds to the earliest + arriving packet that would not be discarded. + + * Method of Measurement or Calculation: See Section 4.2, + de-jitter buffer maximum delay definition and Section 3, the + last paragraph. + + * Units of Measurement: See Section 4.2, de-jitter buffer + maximum delay definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4. + + * Measurement Timing: See Section 4 for measurement timing and + Section 4.2 for Interval Metric flag. + + + + +Clark, et al. Standards Track [Page 12] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + c. De-Jitter Buffer High-Water Mark Metric + + * Metric Name: De-jitter buffer high-water mark in RTP. + + * Metric Description: It is the highest value of the de-jitter + buffer nominal delay for RTP traffic which occurred at any + time during the reporting interval. + + * Method of Measurement or Calculation: See Section 4.2, + de-jitter buffer high-water mark definition. + + * Units of Measurement: See Section 4.2, de-jitter buffer + nominal delay definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4. + + * Measurement Timing: See Section 4 for measurement timing and + Section 4.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + d. De-Jitter Buffer Low-Water Mark Metric + + * Metric Name: De-jitter buffer low-water mark in RTP. + + * Metric Description: It is the lowest value of the de-jitter + buffer nominal delay (for RTP traffic) that occurred at any + time during the reporting interval. + + * Method of Measurement or Calculation: See Section 4.2, + de-jitter buffer low-water mark definition. + + * Units of Measurement: See Section 4.2, de-jitter buffer low + water mark definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4, 1st paragraph. + + * Measurement Timing: See Section 4 for measurement timing and + Section 4.2 for Interval Metric flag. + + + + +Clark, et al. Standards Track [Page 13] + +RFC 7005 RTCP XR Jitter Buffer September 2013 + + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + +Authors' Addresses + + Alan Clark + Telchemy Incorporated + 2905 Premiere Parkway, Suite 280 + Duluth, GA 30097 + USA + + EMail: alan.d.clark@telchemy.com + + + Varun Singh + Aalto University + School of Electrical Engineering + Otakaari 5 A + Espoo, FIN 02150 + Finland + + EMail: varun@comnet.tkk.fi + + + Qin Wu + Huawei + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + + EMail: sunseawq@huawei.com + + + + + + + + + + + + + + + + + + + +Clark, et al. Standards Track [Page 14] + -- cgit v1.2.3