Network Working GroupInternet Engineering Task Force (IETF) G. ZornInternet-DraftRequest for Comments: 7004 Network ZenIntended status:Category: Standards Track R. SchottExpires: September 26, 2013ISSN: 2070-1721 Deutsche Telekom Q. Wu, Ed. R. Huang HuaweiMarch 25,August 2013 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reportingdraft-ietf-xrblock-rtcp-xr-summary-stat-11Abstract This document defines three RTP Control Protocol (RTCP) Extended Report (XR)Blocksblocks that allow the reporting of loss,duplicationduplication, and discard summary statistics metrics in a range of RTP applications. Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 26, 2013.http://www.rfc-editor.org/info/rfc7004. 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. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4....................................................2 1.1. Summary Statistics Metrics. . . . . . . . . . . . . . . . 4.................................2 1.2. RTCP and RTCPXRExtended Reports. . . . . . . . . . . . . . . . . 4.............................3 1.3. Performance Metrics Framework. . . . . . . . . . . . . . 4..............................3 1.4. Applicability. . . . . . . . . . . . . . . . . . . . . . 4..............................................3 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 5.....................................................3 3.Transport Related End SystemTransport-Related End-System Metrics. . . . . . . . . . . . . 5............................4 3.1. Burst/Gap Loss Summary StatisticsMetricsBlock. . . . . 5....................4 3.1.1. Report Block Structure. . . . . . . . . . . . . . . . 6..............................5 3.1.2. Definition of Fields in Loss Summary Statistics Block. . . . . . . . . . . . . . . . . . . . . . . . 6....................................5 3.2. Burst/Gap Discard Summary StatisticsMetricsBlock. . . . 8.................7 3.2.1. Report Block Structure. . . . . . . . . . . . . . . . 9..............................8 3.2.2. Definition of Fields in Burst/Gap Discard Summary Statistics Block. . . . . . . . . . . . . . . . . . . 9............................8 4.Application LevelApplication-Level Metrics. . . . . . . . . . . . . . . . . . 11......................................10 4.1. Frame Impairment Statistics SummaryMetricsBlock. . . . 11.................10 4.1.1. Report Block Structure. . . . . . . . . . . . . . . . 11.............................11 4.1.2. Definition of Fields in Frame ImpairmentSummaryStatistics Summary Block. . . . . . . . . . . . . . . . . . . 12...........................11 5. SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . 13..................................................13 5.1. SDPrtcp-xr-attribrtcp-xr Attribute Extension. . . . . . . . . . 13...........................13 5.2. Offer/Answer Usage. . . . . . . . . . . . . . . . . . . . 14........................................13 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 14............................................13 6.1. New RTCP XR Block Typevalues . . . . . . . . . . . . . . 14Values .............................13 6.2. New RTCP XR SDP Parameters. . . . . . . . . . . . . . . . 14................................14 6.3. ContactinformationInformation forregistrations . . . . . . . . . . 15Registrations .....................14 7. Security Considerations. . . . . . . . . . . . . . . . . . . 15........................................14 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 15...............................................14 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 15.....................................................14 9.1. Normative References. . . . . . . . . . . . . . . . . . . 15......................................14 9.2. Informative References. . . . . . . . . . . . . . . . . . 16....................................15 Appendix A. Metricsrepresented using RFC6390Represented Using the Template. . . . .from RFC 6390 16Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 B.1. draft-ietf-xrblock-rtcp-xr-summary-stat-11 . . . . . . . . 22 B.2. draft-ietf-xrblock-rtcp-xr-summary-stat-10 . . . . . . . . 22 B.3. draft-ietf-xrblock-rtcp-xr-summary-stat-09 . . . . . . . . 22 B.4. draft-ietf-xrblock-rtcp-xr-summary-stat-08 . . . . . . . . 22 B.5. draft-ietf-xrblock-rtcp-xr-summary-stat-07 . . . . . . . . 22 B.6. draft-ietf-xrblock-rtcp-xr-summary-stat-06 . . . . . . . . 22 B.7. draft-ietf-xrblock-rtcp-xr-summary-stat-05 . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 231. Introduction 1.1. Summary Statistics Metrics Thisdraftdocument defines three new block types to augment those defined in [RFC3611] for use in a range of RTPapplications.applications: o Burst/Gap Loss Summary StatisticsMetricsBlock o Burst/Gap Discard Summary StatisticsMetricsBlock o Frame Impairment Statistics SummaryMetricsBlock The first two block types support the reporting ofburst gap loss/burst/gap loss and burst/gap discard summary statistics including packet loss/discard proportion,meanmean, and variance and belong to the class oftransport-related end systemtransport- related end-system metrics defined in [RFC6792]. These two blocks are intended to be used in conjunction with information from theBurst GapBurst/Gap Loss Metrics Block[BGLOSS][RFC6958] orBurst GapBurst/Gap Discard Metrics Block[BGDISCARD], and[RFC7003], on which these two blocks therefore depend. The metrics in theBurst GapBurst/Gap Loss Metricsblock or Burst GapBlock and Burst/Gap Discard Metrics Block are consistent with the definitions ofBurst, Gap, Loss"burst", "gap", "loss", andDiscard"discard" in RTCP XR [RFC3611]. The third block supports the reporting of detailed video statistics for each frame type, including the number of frames received,lostlost, and discarded of each frame type in the Group of Pictures (GOP) and additional data allowing the calculation of statistical parameters(e.g.,the(e.g., the proportion of each frame type impaired by packet loss and discard). The metrics defined in this block belong to the class ofapplication layerapplication-level metrics defined in [RFC6792]. 1.2. RTCP and RTCPXRExtended Reports The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] defined 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 The RTP MonitoringArchitecturesFramework [RFC6792] providesguidelineguidelines for reporting block format using RTCP XR. Metrics described in thisdraftdocument are in accordance with the guidelines in [RFC6792]. 1.4. Applicability These metrics are applicable to a wide range of RTP applications and reflect transient IP problems that affect user experience. They can be used to form an accurate assessment of users' quality of experience and influence sender strategies to mitigate the problem. 2. Terminology2.1. Standards LanguageThe 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]. In addition, the followingterms areterm is defined: Frame Type In many cases, a video frame is compressed using different algorithms. Frame type is used to identify different algorithms for video frames. Two frameTypestypes used in the different video algorithms are the Key frame and Derived frames. The Key frame is independently coded without prediction from other pictures and used as a reference frame for predicting other pictures. Derived frames are predicatively coded and derived from a Key frame using a predictionalgorithmalgorithm. If there is no video image compression, all frames are KeyFrames.frames. 3.Transport Related End SystemTransport-Related End-System Metrics 3.1. Burst/Gap Loss Summary StatisticsMetricsBlock ThisBlockblock extends packet loss and discard metrics defined insectionSection 4.7.1 ofRFC3611.[RFC3611]. The metrics described here are intended to be used as described in this section, in conjunction with information from the Measurement InformationblockBlock [RFC6776] (which MUST be present in the same RTCP packet as the Burst/Gap Lossblock)Metrics Block [RFC6958]) and also with the metric "cumulative number of packets lost" provided in standard RTCP [RFC3550]. Instances of thisMetrics Block refer by Synchronizationmetrics block use the synchronization source (SSRC) to refer to the separate auxiliary Measurement Informationblock [RFC6776]Block [RFC6776], which describes measurement periods in use (see[RFC6776] section[RFC6776], Section 4.2). ThisMetrics Blockmetrics block relies on the measurement period in the Measurement InformationblockBlock indicating the span of the report and SHOULD be sent in the same compound RTCP packet as themeasurement information block.Measurement Information Block. If the measurement period is not received in the same compound RTCP packet as thisMetrics Block,metrics block, this metrics block MUST be discarded. The metrics carried in thisMetrics Blockmetrics block provide information relevant to statistical parameters, includingburst loss rate, gap loss rate, burst duration mean, burst duration varianceBurst Loss Rate, Gap Loss Rate, Burst Duration Mean, and Burst Duration Variance, and are measured at the receiving end of the RTP stream usingburst gapburst/gap loss metrics defined in[BGLOSS][RFC6958] and other informationwhichthat is sent together with this report block. 3.1.1. Report Block Structure0 1 2 3The structure of the Burst/Gap Loss Summary Statistics Block is as follows. 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=BGLSSBT=17 | I | Reserved |block lengthBlock Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Loss Rate | Gap Loss Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BurstdurationDuration Mean | BurstdurationDuration Variance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.2. Definition of Fields in Loss Summary Statistics Block Block Type (BT): 8 bits A Burst/Gap Loss Summary Statistics Block is identified by the constant<BGLSS>.17. Interval MetricFlagflag (I): 2 bits This field is used to indicate whether theBurst/Gap Loss Summary Statisticsburst/gap loss summary statistics metrics are Sampled,IntervalInterval, or Cumulative metrics: 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. I=01: Sampled Value - the reported value is a sampled instantaneous value. In this document, the value I=00 is the reserved value and MUST NOT be used. Reserved: 6 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and ignored by the receiver(See RFC6709 section(see [RFC6709], Section 4.2). Block Length: 16 bits The constant 3, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611]. SSRC of Source: 32 bits As defined in Section 4.1 ofRFC3611RFC 3611 [RFC3611]. Burst Loss Rate: 16 bits The fraction of packets lost during bursts since the beginning of reception, expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing Packets Lost in Bursts by Total Packets Expected in Bursts, multiplying the result of the division by 32768(0x8000),and(0x8000), and keeping only the integer part. The maximum value is thus 0x8000. Representing this as a formula: integer-part( (Packets Lost in Bursts / Total Packets Expected in Bursts) * 0x8000 ) If the measurement is unavailable, the value 0xFFFF MUST be reported. Gap Loss Rate: 16 bits The fraction of packets lost during gaps since the beginning of reception expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing the difference between number of packets lost and PacketslostLost in Bursts by the difference between Packets Expected and Total PacketsexpectedExpected in Bursts, multiplying the result of the division by 32768(0x8000),and(0x8000), and keeping only the integer part. The maximum value is thus 0x8000. Representing this as a formula: integer-part ( (number of packets lost - Packets Lost in Bursts)/ (Packets Expected - Total PacketsexpectedExpected in Bursts) * 0x8000 ) where "number of packets lost" is obtained from standard RTCP [RFC3550] and Packets Expected is calculated as the difference between "extended last sequence number" and "extended first sequence number" (Interval or Cumulative) provided in the Measurement Identity and InformationblockBlock [RFC6776]. If the measurement is unavailable, the value 0xFFFF MUST be reported. Note that if the metric is to be calculated on an Interval basis, a difference must be taken between the current and preceding values of "cumulative number of packets lost" inRTCP,RTCP to obtain the "number of packets lost" for the reporting interval. Burst DurationMean:16bitsMean: 16 bits The mean burst duration is obtained as the quotient: mean = Sum of Burst Durations / Number of Bursts where "Sum of Burst Durations" and "Number of Bursts" is obtained from the RTCP XR Burst/Gap Loss Metrics Block[BGLOSS].[RFC6958]. If the measurement is unavailable, the value 0xFFFF MUST be reported. Burst DurationVariance:16bitsVariance: 16 bits The variance of the burst duration is obtained using the standard result: var = ( Sum of Squares of Burst Durations - Number of Bursts * mean^2 ) / (Number of Bursts - 1) where "Sum of Squares of Burst Durations" and "Number ofBursts"isBursts" is obtained from the RTCP XR Burst/Gap Loss Metrics Block[BGLOSS].[RFC6958]. If the measurement is unavailable, the value 0xFFFF MUST be reported. 3.2. Burst/Gap Discard Summary StatisticsMetricsBlock ThisBlockblock extends packet loss and discard metrics defined insectionSection 4.7.1 ofRFC3611.[RFC3611]. The metrics described here are intended to be used as described in this section, in conjunction with information from the Measurement IdentityblockBlock [RFC6776] (which MUST be present in the same RTCP packet as the Burst/Gap Discard Summary Statisticsblock) .Block). These metrics provide information relevant to statistical parameters, includingburst discard rate, gap discard rateBurst Discard Rate and Gap Discard Rate, and are measured at the receiving end of the RTP stream usingburst gapburst/gap discard metrics defined in[BGDISCARD][RFC7003] and other informationwhichthat is sent together with this report block. Instances of thisMetrics Block refer by Synchronizationmetrics block use the synchronization source (SSRC) to refer to the separate auxiliary Measurement Information block [RFC6776]whichthat describes measurement periods in use (see[RFC6776] section[RFC6776], Section 4.2). This metrics block relies on the measurement period in the Measurement InformationblockBlock indicating the span of the report and SHOULD be sent in the same compound RTCP packet as the measurement information block. If the measurement period is not received in the same compound RTCP packet as thisMetrics Block,metrics block, thisMetrics Blockmetrics block MUST be discarded. 3.2.1. Report Block Structure The structure of the Burst/Gap Discard Summary Statistics Block is as follows. 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=BGDSSBT=18 | I | Reserved |block lengthBlock Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Discard Rate | Gap Discard Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.2. Definition of Fields in Burst/Gap Discard Summary Statistics Block Block Type (BT): 8 bits A Burst/Gap Discard Summary Statistics Block is identified by the constant<BGDSS>.18. Interval MetricFlagflag (I): 2 bits This field is used to indicate whether theBurst/Gap Discard Summary Statisticsburst/gap discard summary statistics metrics are Sampled,IntervalInterval, or Cumulative metrics: 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. I=01: Sampled Value - the reported value is a sampled instantaneous value. In this document, the value I=00 is the reserved value and MUST NOT be used. Reserved: 6 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and ignored by the receiver(See RFC6709 section(see [RFC6709], Section 4.2). Block Length: 16 bits The constant 2, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611]. SSRC of Source: 32 bits As defined in Section 4.1 of RFC3611 [RFC3611]. Burst Discard Rate: 16 bits The fraction of packets discarded during bursts since the beginning of reception, expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing Packets Discarded in Bursts by Total PacketsexpectedExpected in Bursts, multiplying the result of the division by 32768 (0x8000), and keeping only the integer part, according to the formula: integer-part( (Packets Discarded in Bursts / Total PacketsexpectedExpected in Bursts) * 0x8000 ) If the measurement is unavailable, the value 0xFFFF MUST be reported. Gap Discard Rate: 16 bits The fraction of packets discarded during gaps since the beginning of reception expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing the difference between number of packets discarded and Packets Discarded in Bursts by the difference between Packets Expected and Total PacketsexpectedExpected in Bursts, multiplying the result of the division by 32768 (0x8000), and keeping only the integer part. The maximum value is thus 0x8000. Representing this as a formula: integer-part( (number of packets discarded - Packets Discarded in Bursts) /(Packets Expected - Total PacketsexpectedExpected in Bursts) * 0x8000 ) where "number of packets discarded" is obtained from the RTCP XR Discard Count Block[DISCARD][RFC7002] and filled with the sum of packets discarded due to early arrival (DT=1) and packets discarded due to latearrival(DT=2)arrival (DT=2) and Packets Expected is calculated as the difference between "extended last sequence number" and "extended first sequence number" (Interval or Cumulative) provided in the Measurement InformationblockBlock [RFC6776]. In order for the Burst/ Gap Discard Summary Statistics Block to be meaningful, 2 instances of the Discard CountblockBlock with DT=1 and DT=2 MUST be included in the same RTCP XR packet as the Burst/Gap Discard Summary Statistics Block. If the measurement is unavailable, the value 0xFFFF MUST be reported. 4.Application LevelApplication-Level Metrics 4.1. Frame Impairment Statistics SummaryMetricsBlock This block extends the statistics summary report mechanism defined insectionSection 4.6 ofRFC3611[RFC3611] and reports statistics on which frametypetypes were affected beyond the information carried in the Statistics Summary Report Block RTCP packet specified inthe sectionSection 4.6 ofRFC 3611[RFC3611]. Information is measured at the receiving end of the RTP stream and recorded about the number of frames received, lost frames, duplicatedframesframes, and lost partial frames. Such information can be useful for network management and video quality monitoring. 4.1.1. Report Block Structure The structure of the Frame Impairment Statistics Summary Block is as follows. 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=FISSBT=19 |T| Reserved |block lengthBlock Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Discarded_framesdiscarded_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Dup_framesdup_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Full_lost_framesfull_lost_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Partial_lost_framespartial_lost_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2. Definition of Fields in Frame ImpairmentSummaryStatistics Summary Block BlocktypeType (BT): 8 bits A Frame Impairment Statistics Summary Block is identified by the constant<FISS>.19. Frame type indicator (T): 1 bit This field is used to indicate the frame type to be reported. The bit is set to 0 if the full_lost_frames, partial_lost_frames,dup_frames,discarded_framesdup_frames, andNumber of frames receiveddiscarded_frames fields contain Key frame (reference frame) counts or 1 if they contain Derived frame counts. Note that if both the Key frame and Derivation frame report are sent, they should be sent in the same RTCP compound packet using two Frame ImpairmentSummaryStatistics Summary Blocks. Reserved: 7 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and ignored by the receiver(See RFC6709 section(see [RFC6709], Section 4.2). Block Length: 16 bits The constant 6, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611]. SSRC of Source: 32 bits As defined in Section 4.1 ofRFC3611RFC 3611 [RFC3611]. begin_seq: 16 bits As defined in Section 4.1 of RFC 3611 [RFC3611]. end_seq: 16 bits As defined in Section 4.1 of RFC 3611 [RFC3611]. Number of discarded frames (discarded_frames): 32 bits Number of frames discarded in the above sequence number interval. Number of duplicate frames (dup_frames): 32 bits Number of duplicate frames received in the above sequence number interval. Number of full lost frames (full_lost_frames): 32 bits A frame is either split across multiple packets or carried in only onepacket.Ifpacket. If the whole frame or all the packets of the frameisare lost, this frame is regarded as one full_lost_frame. The full_lost_frames can be inferred from packet(s) that comprise the frame. Thefull_lost_ framesfull_lost_frames is equivalent to the number of full lost frames in the above sequence number interval. Number of partial lost frames (partial_lost_frames): 32 bits When a frame is split across multiple packets and some packets of the frame are lost, this frame is regarded as one partial_lost_frame. The partial_lost_frames can be inferred from packets that comprise the frame. The value of the partial_lost_frames field is equivalent to the number of partial lost frames in the above sequence number interval. 5. SDP Signaling RFC 3611 defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of XR blocks.HoweverHowever, XR blocks MAY be used without prior signaling (seesectionSection 5 ofRFC3611).[RFC3611]). 5.1. SDPrtcp-xr-attribrtcp-xr Attribute Extension This section augments the SDP [RFC4566] attribute "rtcp-xr" defined in Section 5.1 ofRFC 3611[RFC3611] by providing three additional values of "xr-format" to signal the use of the report block defined in this document. The ABNF [RFC5234] syntax is as follows. xr-format= /=/ xr-bglss-block / xr-bgdss-block / xr-fiss-blockxr-bglss-block=xr-bglss-block = "burst-gap-loss-stat" xr-bgdss-block = "burst-gap-discard-stat"xr-fiss-block=xr-fiss-block = "frame-impairment-stat" 5.2. Offer/Answer Usage When SDP is used inoffer-answeroffer/answer context, the SDP Offer/Answer usage defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters applies. For detailed usage of Offer/Answer for unilateral parameter, 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 RFC 3611. 6.1. New RTCP XR Block TypevaluesValues This document assigns three new block typevaluevalues in the "RTP Control Protocol(RTCP)ExtendedReport (XR)Reports (RTCP XR) Block TypeRegistry" :Registry": Name: BGLSS Long Name: Burst/Gap Loss Summary Statistics Block Value<BGLSS>17 Reference: Section 3.1 Name: BGDSS Long Name: Burst/Gap Discard Summary Statistics Block Value<BGDSS>18 Reference: Section 3.2 Name: FISS Long Name: Frame Impairment Statistics Summary Block Value<FISS>19 Reference: Section 4.1 6.2. New RTCP XR SDP Parameters This document also registers three new SDP [RFC4566] parameters for the "rtcp-xr" attribute in the" RTP"RTP Control Protocol(RTCP)ExtendedReport (XR) SDPReports (RTCP XR) Session Description Protocol (SDP) ParametersRegistry ":Registry": * "burst-gap-loss-stat" * "burst-gap-discard-stat" * "frame-impairment-stat" 6.3. ContactinformationInformation forregistrationsRegistrations The contact information for the registrations is: Qin Wu (sunseawq@huawei.com) 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China 7. Security Considerations The new RTCP XRreportblocksproposedin this documentintroduces nodo not introduce any new security considerations beyond those described inRFC 3611.[RFC3611]. 8. Acknowledgements The authors would like to thank Bill Ver Steeg, DavidRR. Oran, Ali Begen, Colin Perkins, Roni Even, Youqing Yang, Wenxiao Yu, Yinliang Hu, Jing Zhao, Ray van Brandenburg, Claire Bi, DanRomascanu , MortonRomascanu, Alfred Morton, Jr.,Alfred,Klaas Wierenga, Barry Leiba, Robert Sparks, RalphDromsDroms, and Benoit Claise for their valuable comments and suggestions on this document. 9. References 9.1. Normative References[BGDISCARD] Clark, A., Huang, R., and W. Wu, "RTP Control Protocol(RTCP) Extended Report (XR) Block[RFC2119] Bradner, S., "Key words forBurst/Gap Discard metric Reporting", draft-ietf-xrblock-rtcp-xr-burst-gap-discard-08 (work in progress), December 2012. [BGLOSS] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss metric Reporting", draft-ietf-xrblock-rtcp-xr-burst-gap-loss-06 (work in progress), December 2012. [DISCARD] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count metric Reporting", draft-ietf-xrblock-rtcp-xr-discard-09 (work in progress), October 2012. [RFC2119] Bradner, S., "Key words for useuse in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC6776] Clark, A. and Q. Wu,Q.,"Measurement Identity andinformationInformation Reportingusing SDES itemUsing a Source Description (SDES) Item andXRan RTCP Extended Report (XR) Block", RFC 6776,AugustOctober 2012. [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", RFC 6958, May 2013. [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting", RFC 7002, August 2013. [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", RFC 7003, August 2013. 9.2. Informative References [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]Hunt, G.,Wu, Q., Hunt, G., and P. Arden,"Monitoring Architectures"Guidelines forRTP",Use of the RTP Monitoring Framework", RFC 6792, November 2012. Appendix A. Metricsrepresented using RFC6390 Template RFC EDITOR NOTE: please change XXXX in [RFCXXXX] byRepresented Using thenewTemplate from RFCnumber, when assigned.6390 a. Burst Loss Rate Metric * Metric Name: RTP Burst Loss Rate * Metric Description: The fraction of packets lost during bursts since the beginning of reception for RTP traffic. * Method of Measurement or Calculation: SeesectionSection 3.1.2, Burst Loss Ratedefinition [RFCXXXX].definition. * Units of Measurement: SeesectionSection 3.1.2, Burst Loss Ratedefinition [RFCXXXX].definition. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 3.1, 2ndparagraph [RFCXXXX].paragraph. * Measurement Timing: SeesectionSection 3.1, 1st paragraph[RFCXXXX]for measurement timing andsectionSection 3.1.2[RFCXXXX]for Interval Metric flag. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. b. Gap Loss Rate Metric * Metric Name: RTP Gap Loss Rate * Metric Description: The fraction of packets lost during gaps since the beginning of reception for RTP traffic. * Method of Measurement or Calculation: SeesectionSection 3.1.2, Gap Loss Ratedefinition [RFCXXXX].definition. * Units of Measurement: SeesectionSection 3.1.2, Gap Loss Ratedefinition [RFCXXXX].definition. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 3.1, 2ndparagraph [RFCXXXX].paragraph. * Measurement Timing: SeesectionSection 3.1, 1st paragraph[RFCXXXX]for measurement timing andsectionSection 3.1.2[RFCXXXX]for Interval Metric flag. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. c. BurstdurationDuration Mean Metric * Metric Name: RTP BurstdurationDuration Mean * Metric Description: The mean duration of the burst periods that have occurred since the beginning of reception for RTP traffic. * Method of Measurement or Calculation: SeesectionSection 3.1.2, Burst Loss Ratedefinition [RFCXXXX].definition. * Units of Measurement: This metric is expressed in milliseconds. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 3.1, 2ndparagraph [RFCXXXX].paragraph. * Measurement Timing: SeesectionSection 3.1, 1st paragraph[RFCXXXX]for measurement timing andsectionSection 3.1.2[RFCXXXX]for Interval Metric flag. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. d. Burstduration varianceDuration Variance Metric * Metric Name: RTP Burstduration varianceDuration Variance * Metric Description: The variance duration of the burst periods that have occurred since the beginning of reception for RTP traffic. * Method of Measurement or Calculation: Seesection 4.1.2, Gap Loss Rate definition [RFCXXXX].Section 3.1.2, Burst Duration Variance definition. * Units of Measurement: SeesectionSection 3.1.2, Burst Duration Variancedefinition [RFCXXXX].definition. * Measurement Point(s) with Potential Measurement Domain: Seesection 4.1,Section 3.1, 2ndparagraph [RFCXXXX].paragraph. * Measurement Timing: Seesection 4.1,Section 3.1, 1st paragraph[RFCXXXX]for measurement timing andsectionSection 3.1.2[RFCXXXX]for Interval Metric flag. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. e. Burst DiscardmetricRate Metric * Metric Name: RTP Burst Discard Rate * Metric Description: The fraction of packets discarded during bursts since the beginning of reception for RTP traffic. * Method of Measurement or Calculation: SeesectionSection 3.2.2, Burst Discard Ratedefinition [RFCXXXX].definition. * Units of Measurement: SeesectionSection 3.2.2, Burst Discard Ratedefinition [RFCXXXX].definition. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 3.2, 2ndparagraph [RFCXXXX].paragraph. * Measurement Timing: SeesectionSection 3.2, 3rd paragraph[RFCXXXX]for measurement timing andsectionSection 3.1.2[RFCXXXX]for Interval Metric flag. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. f. Gap Discard RatemetricMetric * Metric Name: RTP Gap Discard Rate * Metric Description: The fraction of packets discarded during gaps since the beginning of reception for RTP traffic. * Method of Measurement or Calculation: SeesectionSection 3.2.2, Gap Discard Ratedefinition [RFCXXXX].definition. * Units of Measurement: SeesectionSection 3.2.2, Gap Discard Ratedefinition [RFCXXXX].definition. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 3.2, 2ndparagraph [RFCXXXX].paragraph. * Measurement Timing: SeesectionSection 3.2, 3rd paragraph[RFCXXXX]for measurement timing andsectionSection 3.1.2[RFCXXXX]for Interval Metric flag. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. g. Number ofdiscarded frames metricDiscarded Frames Metric * Metric Name: Number of discarded frames in RTP * Metric Description: Number of frames discarded in a certain sequence number interval for RTP traffic. * Method of Measurement or Calculation: SeesectionSection 4.1.2, Number of discarded framesdefinition [RFCXXXX].definition. This metric is directly measured and can be inferred from packet(s) that comprise the frame. * Units of Measurement: This metric is expressed as a 32-bit unsigned integer value. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 4.1, 1stparagraph [RFCXXXX].paragraph. * Measurement Timing: Seesection 4.1 [RFCXXXX],Section 4.1, Number of discarded framesdefinition, thisdefinition. This metric relies on the sequence number interval and RTCP RR packet ofRFC3550[RFC3550] to determine measurement timing. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. h. Number ofduplicate frames metricDuplicate Frames Metric * Metric Name: Number of duplicate frames in RTP * Metric Description: Number of frames duplicated in a certain sequence number interval for RTP traffic. * Method of Measurement or Calculation: SeesectionSection 4.1.2, Number ofdiscardedduplicate framesdefinition [RFCXXXX],definition. This metric is directly measured and can be inferred from packet(s) that comprise the frame. * Units of Measurement: This metric is expressed as a 32-bit unsigned integer value. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 4.1, 1stparagraph [RFCXXXX].paragraph. * Measurement Timing: Seesection 4.1 [RFCXXXX],Section 4.1, Number of duplicate framesdefinition, thisdefinition. This metric relies on the sequence number interval to determine measurement timing. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. i. Number offull lost frames metricFull Lost Frames Metric * Metric Name: Number of full lost frames in RTP * Metric Description: A frame is either split across multiple RTP packets or carried in only one RTPpacket.Ifpacket. If the whole frame or all the packets of the frame is lost, this frame is regarded as one full_lost_frame. * Method of Measurement or Calculation: SeesectionSection 4.1.2, Number ofdiscardedfull lost framesdefinition [RFCXXXX].definition. * Units of Measurement: This metric is expressed as a 32-bit unsigned integer value. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 4.1, 1stparagraph [RFCXXXX].paragraph. * Measurement Timing: Seesection 4.1 [RFCXXXX],Section 4.1, Number of full lost framesdefinition [RFCXXXX], thisdefinition. This metric relies on the sequence number interval to determine measurement timing. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611.RFC 3611. j. Number ofpartial lost frames metricPartial Lost Frames Metric * Metric Name: Number of partial lost frames in RTP * Metric Description: When a frame is split across multiple RTP packets and some RTP packets of the frame are lost, this frame is regarded as one partial_lost_frame. * Method of Measurement or Calculation: SeesectionSection 4.1.2, Number of partial lost framesdefinition [RFCXXXX].definition. * Units of Measurement: This metric is expressed as a 32-bit unsigned integer value. * Measurement Point(s) with Potential Measurement Domain: SeesectionSection 4.1, 1stparagraph [RFCXXXX].paragraph. * Measurement Timing: Seesection 4.1 [RFCXXXX],Section 4.1, Number of partial lost framesdefinition, thisdefinition. This metric relies on the sequence number interval to determine measurement timing. * Use andapplications:Applications: Seesection 1.4 [RFCXXXX].Section 1.4. * Reportingmodel:Model: SeeRFC3611. Appendix B. Change Log Note to the RFC-Editor: please remove this section prior to publication as an RFC. B.1. draft-ietf-xrblock-rtcp-xr-summary-stat-11 The following are the major changes compared to 10: o Incorporate the last proposed change by Barry when his DISCUSS was cleared. B.2. draft-ietf-xrblock-rtcp-xr-summary-stat-10 The following are the major changes compared to 09: o Add appendix to apply RFC6390 template to metrics in this draft. B.3. draft-ietf-xrblock-rtcp-xr-summary-stat-09 The following are the major changes compared to 08: o Address comments in the IESG Review. B.4. draft-ietf-xrblock-rtcp-xr-summary-stat-08 The following are the major changes compared to 07: o Address comments raised in Sec-DIR review. B.5. draft-ietf-xrblock-rtcp-xr-summary-stat-07 The following are the major changes compared to 06: o Add comments raised in PM-DIR review by Al. B.6. draft-ietf-xrblock-rtcp-xr-summary-stat-06 The following are the major changes compared to 05: o Move RFC6709 to informative reference. B.7. draft-ietf-xrblock-rtcp-xr-summary-stat-05 The following are the major changes compared to 04: o Editorial changes to get in line with Delay and Burst Gap related drafts.RFC 3611. Authors' Addresses Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 909-201060Email:EMail: glenzorn@gmail.com Roland Schott Deutsche Telekom Deutsche-Telekom-Allee 7 Darmstadt 64295 GermanyEmail:EMail: Roland.Schott@telekom.de Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 ChinaEmail:EMail: sunseawq@huawei.com Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 ChinaEmail:EMail: Rachel@huawei.com