draft-ietf-xrblock-rtcp-xr-video-lc-06.txt   rfc7867.txt 
XRBLOCK R. Huang Internet Engineering Task Force (IETF) R. Huang
INTERNET-DRAFT Huawei Request for Comments: 7867 Huawei
Intended Status: Standards Track March 30, 2016 Category: Standards Track July 2016
Expires: September 30, 2016 ISSN: 2070-1721
RTCP XR Report Block for Loss Concealment Metrics Reporting on RTP Control Protocol (RTCP) Extended Report (XR) Block
Video Applications for Loss Concealment Metrics for Video Applications
draft-ietf-xrblock-rtcp-xr-video-lc-06
Abstract Abstract
This document defines a new RTCP XR Report Block that allows the This document defines a new RTP Control Protocol (RTCP) Extended
reporting of loss concealment metrics for video applications of RTP. Report (XR) block that allows the reporting of loss concealment
metrics for video applications of RTP.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (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 7841.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7867.
Copyright and License Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . . 3 1.1. RTCP and RTCP XR Reports ...................................3
1.2 Performance Metrics Framework . . . . . . . . . . . . . . . 3 1.2. Performance Metrics Framework ..............................3
1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Applicability ..............................................3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................3
3 Video Loss Concealment Methods . . . . . . . . . . . . . . . . 4 3. Video Loss Concealment Methods ..................................3
4 Video Loss Concealment Report Block . . . . . . . . . . . . . . 5 4. Video Loss Concealment Report Block .............................4
5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. SDP Signaling ...................................................8
5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 9 5.1. SDP rtcp-xr-attrib Attribute Extension .....................8
5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 9 5.2. Offer/Answer Usage .........................................9
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations .........................................9
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations .............................................9
7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 10 7.1. New RTCP XR Block Type Value ...............................9
7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 10 7.2. New RTCP XR SDP Parameter ..................................9
7.3 Contact Information for registrations . . . . . . . . . . . 10 7.3. Contact Information for Registrations .....................10
8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References .....................................................10
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References ......................................10
9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References ....................................11
9.2 Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Metrics Represented Using the Template from RFC 6390 ..12
Appendix A. Metrics Represented Using the Template from RFC 6390 . 11 Acknowledgements ..................................................16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses ................................................16
1 Introduction 1. Introduction
Multimedia applications often suffer from packet losses in IP Multimedia applications often suffer from packet losses in IP
networks. In order to get a reasonable degree of quality in case of networks. In order to get a reasonable degree of quality when there
packet losses, it is necessary to have loss concealment mechanisms at is packet loss, it is necessary to have loss concealment mechanisms
the decoder. Video loss concealment is a range of techniques to mask at the decoder. Video loss concealment is a range of techniques to
the effects of packet loss in video communications. mask the effects of packet loss in video communications.
In some applications, reporting the information of receivers applying In some applications, reporting the information of receivers applying
video loss concealment could give monitors or senders useful video loss concealment could give monitors or senders useful
information on application QoE. One example is no-reference video information on the Quality of Experience (QoE) of the application.
quality evaluation. Video probes located upstream from the video One example is no-reference video quality evaluation. Video probes
endpoint or terminal may not see loss occurring between the probe and located upstream from the video endpoint or terminal may not see loss
the endpoint, and may also not be fully aware of the specific loss occurring between the probe and the endpoint, and also may not be
concealment methods being dynamically applied by the video endpoint. fully aware of the specific loss concealment methods being
Evaluating error concealment is important in the circumstance in dynamically applied by the video endpoint. Evaluating error
estimating the subjective impact of impairments. concealment is important in this circumstance to estimate the
subjective impact of impairments.
This draft defines one new video loss concealment block type to This document defines one new block type for video loss concealment
augment those defined in [RFC3611] and [RFC7294] for use in a range to augment those defined in [RFC3611] and [RFC7294] for use in a
of RTP video applications. The metrics defined in this draft belong range of RTP video applications. The metrics defined in this
to the class of transport-related terminal metrics defined in document belong to the class of transport-related terminal metrics
[RFC6792]. defined in [RFC6792].
1.1 RTCP and RTCP XR Reports 1.1. RTCP and RTCP XR Reports
The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
defines an extensible structure for reporting using an RTCP Extended defines an extensible structure for reporting using an RTCP Extended
Report (XR). This draft defines a new Extended Report block that is Report (XR). This document defines a new Extended Report block that
used as defined in [RFC3550] and [RFC3611]. is used as defined in [RFC3550] and [RFC3611].
1.2 Performance Metrics Framework 1.2. Performance Metrics Framework
The Performance Metrics Framework [RFC6390] provides guidance on the The Performance Metrics Framework [RFC6390] provides guidance on the
definition and specification of performance metrics. The RTP definition and specification of performance metrics. The RTP
Monitoring Architectures [RFC6792] provides guidelines for reporting monitoring framework [RFC6792] provides guidelines for the reporting
block format using RTCP XR. The XR block type described in this block format using RTCP XR. The XR block type described in this
document are in accordance with the guidelines in [RFC6390] and document is in accordance with the guidelines in [RFC6390] and
[RFC6792]. [RFC6792].
1.3 Applicability 1.3. Applicability
These metrics are applicable to video applications the video These metrics are applicable to video applications the video
component of Audio/Video applications using RTP and applying packet component of audio/video applications using RTP and applying packet
loss concealment mechanisms which are incorporated into the receiving loss concealment mechanisms that are incorporated into the receiving
endpoint to mitigate the impact of network impairments on QoE. For endpoint to mitigate the impact of network impairments on QoE. For
example, in an IPTV system Set Top Boxes could use this RTCP XR block example, in an IPTV system, set-top boxes could use this RTCP XR
to report loss and loss concealment metrics to an IPTV management block to report loss and loss concealment metrics to an IPTV
system to enable the service provider to monitor the quality of the management system to enable the service provider to monitor the
IPTV service being delivered to end users. quality of the IPTV service being delivered to end users.
2 Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3 Video Loss Concealment Methods 3. Video Loss Concealment Methods
Video loss concealment mechanisms can be classified into 4 types as Video loss concealment mechanisms can be classified into 4 types as
follow: follows:
a) Frame freeze a) Frame freeze
The impaired video frame is not displayed, instead, the previously The impaired video frame is not displayed; instead, the previously
displayed frame is frozen for the duration of the loss event. displayed frame is frozen for the duration of the loss event.
b) Inter-frame extrapolation b) Interframe extrapolation
If an area of the video frame is damaged by loss, the same area from If an area of the video frame is damaged by loss, the same area
the previous frame(s) can be used to estimate what the missing pixels from the previous frame(s) can be used to estimate what the
would have been. This can work well in a scene with no motion but can missing pixels would have been. This can work well in a scene
be very noticeable if there is significant movement from one frame to with no motion but can be very noticeable if there is significant
another. Simple decoders can simply re-use the pixels that were in movement from one frame to another. Simple decoders can simply
the missing area while more complex decoders can try to use several reuse the pixels that were in the missing area, while more complex
frames to do a more complex extrapolation. Another example of a decoders can try to use several frames to do a more complex
sophisticated form of inter-frame repair is to estimate the motion of extrapolation. Another example of a sophisticated form of
the damaged region based on the motion of surrounding regions, and interframe repair is to estimate the motion of the damaged region
use that to select what part of the previous frame to use for repair. based on the motion of surrounding regions, and use that to select
Some important frames, such as IDR frames, may not depend on any what part of the previous frame to use for repair. Some important
other frames and may be involved in a scene change. Using inter-frame frames, such as Instantaneous Decoding Refresh (IDR) frames, may
extrapolation method to conceal the loss of these frames may not not depend on any other frames and may be involved in a scene
obtain a quite satisfactory result. change. Using the interframe extrapolation method to conceal the
loss of these frames may not obtain a satisfactory result.
c) Interpolation c) Interpolation
A decoder uses the undamaged pixels in the video frame to estimate A decoder uses the undamaged pixels in the video frame to estimate
what the missing block of pixels should have. what the missing block of pixels should have.
d) Error Resilient Encoding d) Error-resilient encoding
The sender encodes the message in a redundant way so that receiver The sender encodes the message in a redundant way so that the
can correct errors using the redundant information. There are usually receiver can correct errors using the redundant information.
two kinds of Error Resilient Encoding: One is that the redundant data There are usually two kinds of error-resilient encoding: One is
useful for error resiliency performed at the decoder can be embedded that the redundant data useful for error resiliency performed at
into the compressed image/video bitstream. The other is bit-block the decoder can be embedded into the compressed image/video
level encoding, e.g., FEC. bitstream. The other is encoding at the bitstream level, e.g.,
Forward Error Correction (FEC).
Usually, methods b,c,d are deployed together to provide a Usually, methods b, c, and d are deployed together to provide
comprehensive loss concealment in some complex decoders, while method comprehensive loss concealment in complex decoders, while method a is
a is relatively independent and may be only applied in some simple relatively independent and may be applied in some simple decoders.
decoders. Moreover, frame freeze method repairs video based on frames Moreover, the frame-freeze method repairs video based on frames,
while the other methods repair video based on fine-grained elements, while the other methods repair video based on fine-grained elements,
such as macroblock or bit-block, which will cause the measurement such as macroblocks or bitstreams; this will cause the measurement
metrics of frame freeze and the other methods slightly different. metrics of frame-freeze and the other methods to be slightly
Thus, In this document, we differentiate between frame freeze and the different. Thus, In this document, we differentiate between frame-
other 3 concealment mechanisms described. freeze and the other 3 loss concealment mechanisms.
4 Video Loss Concealment Report Block 4. Video Loss Concealment Report Block
This block reports the video loss concealment metrics to complement This block reports the video loss concealment metrics to complement
the audio metrics defined in [RFC7294]. The report block MUST be sent the audio metrics defined in [RFC7294]. The report block MUST be
in conjunction with the information from the Measurement Information sent in conjunction with the information from the Measurement
Block [RFC6776]. Instances of this metric block refer by SSRC to the Information Block [RFC6776]. Instances of this metric block refer by
separate auxiliary Measurement Information Block [RFC6776]. This synchronization source (SSRC) to the separate auxiliary Measurement
metric block relies on the measurement period in the Measurement Information Block [RFC6776]. The Video Loss Concealment Report Block
Information Block indicating the span of the report. If the relies on the measurement period in the Measurement Information Block
measurement period is not received in the same compound RTCP packet indicating the span of the report. If the measurement period is not
as this metric block, this metric block MUST be discarded at the received in the same compound RTCP packet as this metric block, this
receiving side. The metrics in this report block are based on metric block MUST be discarded at the receiving side. The metrics in
measurements that are typically made at the time that a video frame this report block are based on measurements that are typically made
is decoded and rendered for playout. at the time that a video frame is decoded and rendered for playout.
The video loss concealment report block has the following format: The Video Loss Concealment Report Block has the following format:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=VLC | I | V | RSV | block length | | BT=34 | I | V | RSV | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source | | SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Impaired Duration | | Impaired Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Concealed Duration | | Concealed Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean Frame Freeze Duration (optional) | | Mean Frame Freeze Duration (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIFP | MCFP | FFSC | Reserved | | MIFP | MCFP | FFSC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the Video Loss Concealment Report Block Figure 1: Format for the Video Loss Concealment Report Block
Block Type (BT): 8 bits Block Type (BT): 8 bits
A Video Loss Concealment Report Block is identified by the
constant VLC.
[Note to RFC Editor: Please replace VLC with the IANA provided A Video Loss Concealment Report Block is identified by the
RTCP XR block type for this block.] constant 34.
Interval Metric Flag (I): 2 bits Interval Metric Flag (I): 2 bits
This field indicates whether the reported metrics are interval, This field indicates whether the reported metrics are interval,
cumulative, or sampled metrics [RFC6792]: cumulative, or sampled metrics [RFC6792]:
I=10: Interval Duration - the reported value applies to the I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between successive most recent measurement interval duration between
metrics reports. successive metrics reports.
I=11: Cumulative Duration - the reported value applies to the I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative measurements. accumulation period characteristic of cumulative
measurements.
I=01: Sampled Value - this value MUST NOT be used for this I=01: Sampled Value - this value MUST NOT be used for this
block type. block type.
I=00: Reserved. I=00: Reserved.
Video Loss Concealment Method Type (V): 2 bits Video Loss Concealment Method Type (V): 2 bits
This field is used to identify the video loss concealment method This field is used to identify the video loss concealment method
type used at the receiver. The value is defined as follow: type used at the receiver. The value is defined as follows:
V=10 - Frame freeze V=10: Frame-freeze
V=11 - Other Loss Concealment Method V=11: Other Loss Concealment Method
V=01&00 - Reserved V=01 and V=00: Reserved
If Frame freeze and other loss concealment method are used If frame-freeze and another loss concealment method are used
together for the media stream, 2 report blocks, one with V=10 for together for the media stream, two report blocks (one with V=10
frame freeze and one with V=11 for other loss concealment method for frame freeze and one with V=11 for the other loss concealment
SHOULD be compounded together to report the whole concealment method) SHOULD be compounded together to report complete
information. concealment information.
RSV: 4 bits RSV: 4 bits
These bits are reserved for future use. They MUST be set to zero These bits are reserved for future use. They MUST be set to zero
by senders and ignored by receivers (see Section 4.2 of by senders and ignored by receivers (see Section 4.2 of
[RFC6709]). [RFC6709]).
block length: 16 bits Block Length: 16 bits
This field is in accordance with the definition in [RFC3611]. In This field is in accordance with the definition in [RFC3611]. In
this report block, it MUST be set to 5 when V=10 and be set to 4 this report block, it MUST be set to 5 when V=10 and set to 4 when
when V=11. The block MUST be discarded if the block length is set V=11. The block MUST be discarded if the block length is set to a
to a different value. different value.
SSRC of source: 32 bits SSRC of Source: 32 bits
As defined in Section 4.1 of [RFC3611]. As defined in Section 4.1 of [RFC3611].
Impaired Duration: 32 bits Impaired Duration: 32 bits
The total time length, expressed in units of RTP timestamp from The total duration, expressed in units of RTP timestamp from the
the sending side of the reporting block, of video impaired by sending side of the reporting block, of video impaired by
transmission loss before applying any loss concealment methods. transmission loss before applying any loss concealment methods.
Two values are reserved: A value of 0xFFFFFFFE indicates out of Two values are reserved: A value of 0xFFFFFFFE indicates out of
range (that is, a measured value exceeding 0xFFFFFFFD) and a value range (that is, a measured value exceeding 0xFFFFFFFD), and a
of 0xFFFFFFFF indicates that the measurement is unavailable. value of 0xFFFFFFFF indicates that the measurement is unavailable.
Concealed Duration: 32 bits Concealed Duration: 32 bits
The total time length, expressed in units of RTP timestamp from The total duration, expressed in units of RTP timestamp from the
the sending side of the reporting block, of concealed damaged sending side of the reporting block, of concealed damaged video
video pictures on which loss concealment method corresponding to pictures on which the loss concealment method corresponding to the
Video Loss Concealment Method Type is applied. Video Loss Concealment Method Type is applied.
Two values are reserved: A value of 0xFFFFFFFE indicates out of Two values are reserved: A value of 0xFFFFFFFE indicates out of
range (that is, a measured value exceeding 0xFFFFFFFD) and a value range (that is, a measured value exceeding 0xFFFFFFFD), and a
of 0xFFFFFFFF indicates that the measurement is unavailable. value of 0xFFFFFFFF indicates that the measurement is unavailable.
Mean Frame Freeze Duration: 32 bits Mean Frame-Freeze Duration: 32 bits
Mean Frame Freeze Duration is the mean duration, expressed in Mean Frame-Freeze Duration is the mean duration, expressed in
units of RTP timestamp from the sending side of the reporting units of RTP timestamp from the sending side of the reporting
block, of the frame freeze events. The value of Mean Frame Freeze block, of the frame-freeze events. The value of Mean Frame-Freeze
Duration is calculated by summing the total duration of all frame Duration is calculated by summing the total duration of all frame
freeze events and dividing by the number of events. This metric is freeze events and dividing by the number of events. This metric
optional. It only exists when Video Loss Concealment Method is optional. It only exists when Video Loss Concealment Method
Type=10. Type=10.
Mean Impaired Frame Proportion (MIFP): 8 bits Mean Impaired Frame Proportion (MIFP): 8 bits
Mean Impaired Frame Proportion is the mean proportion of each Mean Impaired Frame Proportion is the mean proportion of each
video frame impaired by loss before applying any loss concealment video frame impaired by loss before applying any loss concealment
method during the interval, expressed as a fixed point number with method during the interval, expressed as a fixed-point number with
the binary point at the left edge of the field. It is calculated the binary point at the left edge of the field. It is calculated
by summing the impaired proportion of each video frame and by summing the impaired proportion of each video frame and
dividing by the number of frames during this period. The impaired dividing by the number of frames during this period. The impaired
proportion of each video frame is obtained by dividing the number proportion of each video frame is obtained by dividing the number
of missing macroblocks from this video frame by the total of missing macroblocks from this video frame by the total
macroblock number of the video frame, which is equivalent to macroblock number of the video frame, which is equivalent to
multiplying the result of the division by 256, limiting the multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer maximum value to 255 (to avoid overflow), and taking the integer
part. part.
If a video frame is totally lost, a value of 0xFF SHOULD be used If a video frame is totally lost, a value of 0xFF SHOULD be used
for the frame when calculating the mean value. for the frame when calculating the MIFP.
Mean Concealed Frame Proportion (MCFP): 8 bits Mean Concealed Frame Proportion (MCFP): 8 bits
Mean Concealed Frame Proportion is the mean proportion of each Mean Concealed Frame Proportion is the mean proportion of each
video frame to which loss concealment (depicted as "V" in the video frame to which loss concealment (depicted as "V" in the
definition of "Video Loss Concealment Method Type") was applied definition of "Video Loss Concealment Method Type") was applied
during the interval, expressed as a fixed point number with the during the interval, expressed as a fixed-point number with the
binary point at the left edge of the field. It is calculated by binary point at the left edge of the field. It is calculated by
summing the concealed proportion of each video frame and dividing summing the concealed proportion of each video frame and dividing
by the number of frames during this period. The concealed by the number of frames during this period. The concealed
proportion of each video frame is obtained by dividing the number proportion of each video frame is obtained by dividing the number
of concealed macroblocks from this video frame by the total of concealed macroblocks from this video frame by the total
macroblock number of the video frame, which is equivalent to macroblock number of the video frame, which is equivalent to
multiplying the result of the division by 256, limiting the multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer maximum value to 255 (to avoid overflow), and taking the integer
part. part.
If a lost video frame is totally concealed, a value of 0xFF and if When calculating the MCFP, a value of 0xFF SHOULD be used for a
there are no concealed macroblocks, a value of 0, SHOULD be used lost frame that is totally concealed, and a value of 0 SHOULD be
for the frame when calculating the mean value. For Video Loss used for the frame if there are no concealed macroblocks in it.
Concealment Method Type=10, each frame covered in the period of For Video Loss Concealment Method Type=10, each frame covered in
frame freeze is considered to be totally concealed, which means a the period of frame freeze is considered to be totally concealed;
value of 0xFF MUST be assigned. this means a value of 0xFF MUST be assigned.
Fraction of Frames Subject to Concealment (FFSC): 8 bits Fraction of Frames Subject to Concealment (FFSC): 8 bits
Fraction of Frames Subject to Concealment is calculated by Fraction of Frames Subject to Concealment is calculated by
dividing the number of frames to which loss concealment (using dividing the number of frames to which loss concealment (using
Video Loss Concealment Method Type) was applied by the total Video Loss Concealment Method Type) was applied by the total
number of frames and expressing this value as a fixed point number number of frames and expressing this value as a fixed-point number
with the binary point at the left edge of the field. It is with the binary point at the left edge of the field. It is
equivalent to multiplying the result of the division by 256, equivalent to multiplying the result of the division by 256,
limiting the maximum value to 255 (to avoid overflow), and taking limiting the maximum value to 255 (to avoid overflow), and taking
the integer part. the integer part.
A value of 0 indicates that there were no concealed frame and a A value of 0 indicates that there were no concealed frames, and a
value of 0xFF indicates that the frames in the entire measurement value of 0xFF indicates that the frames in the entire measurement
interval are all concealed. interval are all concealed.
Reserved: 8 bits Reserved: 8 bits
These bits are reserved for future use. They MUST be set to zero These bits are reserved for future use. They MUST be set to zero
by senders and ignored by receivers (see Section 4.2 of by senders and ignored by receivers (see Section 4.2 of
[RFC6709]). [RFC6709]).
5 SDP Signaling 5. SDP Signaling
[RFC3611] defines the use of SDP (Session Description Protocol) for [RFC3611] defines the use of the Session Description Protocol (SDP)
signaling the use of RTCP XR blocks. for signaling the use of RTCP XR blocks.
5.1 SDP rtcp-xr-attrib Attribute Extension 5.1. SDP rtcp-xr-attrib Attribute Extension
This session augments the SDP attribute "rtcp-xr" defined in Section This session augments the SDP attribute "rtcp-xr" defined in Section
5.1 of [RFC3611] by providing an additional value of "xr-format" to 5.1 of [RFC3611] by providing an additional value of "xr-format" to
signal the use of the report block defined in this document. signal the use of the report block defined in this document. The
ABNF [RFC5234] syntax is as follows.
xr-format =/ xr-vlc-block xr-format =/ xr-vlc-block
xr-vlc-block = "vlc" xr-vlc-block = "vlc"
5.2 Offer/Answer Usage 5.2. Offer/Answer Usage
When SDP is used in offer-answer context, the SDP Offer/Answer usage When SDP is used in an offer/answer context, the SDP Offer/Answer
defined in section 5.2 of [RFC3611] for unilateral "rtcp-xr" usage defined in Section 5.2 of [RFC3611] for the unilateral
attribute parameters applies. For detailed usage of Offer/Answer for "rtcp-xr" attribute parameters applies. For detailed usage of
unilateral parameter, refer to section 5.2 of [RFC3611]. Offer/Answer for unilateral parameters, refer to Section 5.2 of
[RFC3611].
6 Security Considerations 6. Security Considerations
It is believed that this RTCP XR block introduces no new security It is believed that this RTCP XR block introduces no new security
considerations beyond those described in [RFC3611]. This block does considerations beyond those described in [RFC3611]. This block does
not provide per-packet statistics, so the risk to confidentially not provide per-packet statistics, so the risk to confidentiality
documented in Section 7, paragraph 3 of [RFC3611] does not apply. documented in paragraph 3 of Section 7 of [RFC3611] does not apply.
An attacker is likely to put incorrect information in the Video Loss An attacker is likely to put incorrect information in the Video Loss
Concealment reports, which will affect the estimation of video loss Concealment reports; this will affect the estimation of the
concealment mechanisms performance and QoE of users. Implementers performance of video loss concealment mechanisms and the QoE of
SHOULD consider the guidance in [RFC7202] for using appropriate users. Implementers SHOULD consider the guidance in [RFC7202] for
security mechanisms, i.e., where security is a concern, the using appropriate security mechanisms, i.e., where security is a
implementation SHOULD apply encryption and authentication to the concern, the implementation SHOULD apply encryption and
report block. For example, this can be achieved by using the AVPF authentication to the report block. For example, this can be
profile together with the Secure RTP profile as defined in [RFC3711]; achieved by using the AVPF profile together with the Secure RTP
an appropriate combination of the two profiles (an "SAVPF") is profile as defined in [RFC3711]; an appropriate combination of the
specified in [RFC5124]. However, other mechanisms also exist two profiles (an "SAVPF") is specified in [RFC5124]. However, other
(documented in [RFC7201]) and might be more suitable. mechanisms also exist (documented in [RFC7201]) and might be more
suitable.
7 IANA Considerations 7. IANA Considerations
New block types for RTCP XR are subject to IANA registration. For
New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, please refer general guidelines on IANA considerations for RTCP XR, please refer
to [RFC3611]. to [RFC3611].
7.1 New RTCP XR Block Type Value 7.1. New RTCP XR Block Type Value
This document assigns the block type value VLC in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
the "Video Loss Concealment Metric Report Block".
[Note to RFC Editor: please replace VLC with the IANA provided RTCP This document assigns the block type value 34 to Video Loss
XR block type for this block.] Concealment Metric Report Block in the IANA "RTP Control Protocol
Extended Reports (RTCP XR) Block Type Registry".
7.2 New RTCP XR SDP Parameter 7.2. New RTCP XR SDP Parameter
This document also registers a new parameter "video-loss-concealment" This document also registers a new parameter "video-loss-concealment"
in the "RTP Control Protocol Extended Reports (RTCP XR) Session in the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry". Description Protocol (SDP) Parameters Registry".
7.3 Contact Information for registrations 7.3. Contact Information for Registrations
The contact information for the registration is: The contact information for the registration is:
RAI Area Directors RAI Area Directors <rai-ads@ietf.org>
rai-ads@tools.ietf.org
8 Acknowledgements
The author would like to thank Colin Perkins, Roni Even for their
valuable comments.
9 References 8. References
9.1 Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", RFC "RTP Control Protocol Extended Reports (RTCP XR)",
3611, November 2003. RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC5124] Ott, J., and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information
Reporting Using a Source Description (SDES) Item and an Reporting Using a Source Description (SDES) Item and an
RTCP Extended Report (XR) Block", RFC6776, October 2012. RTCP Extended Report (XR) Block", RFC 6776,
DOI 10.17487/RFC6776, October 2012,
<http://www.rfc-editor.org/info/rfc6776>.
[RFC7294] Clark, A., Zorn, G., Bi, C. and Q., Wu, "RTCP XR Report [RFC7294] Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control
Block for Concealment Metrics Reporting on Audio Protocol (RTCP) Extended Report (XR) Blocks for
Applications", April 2014. Concealment Metrics Reporting on Audio Applications",
RFC 7294, DOI 10.17487/RFC7294, July 2014,
<http://www.rfc-editor.org/info/rfc7294>.
9.2 Informative References 8.2. Informative References
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
October 2011. DOI 10.17487/RFC6390, October 2011,
<http://www.rfc-editor.org/info/rfc6390>.
[RFC6709] Carpenter, B., and S. Cheshire, "Design Considerations for [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Protocol Extensions", RFC 6709, September 2012. Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<http://www.rfc-editor.org/info/rfc6709>.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
RTP Monitoring Framework", RFC 6792, November 2012. of the RTP Monitoring Framework", RFC 6792,
DOI 10.17487/RFC6792, November 2012,
<http://www.rfc-editor.org/info/rfc6792>.
[RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, April 2014. Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <http://www.rfc-editor.org/info/rfc7202>.
Appendix A. Metrics Represented Using the Template from RFC 6390 Appendix A. Metrics Represented Using the Template from RFC 6390
a. Video Impaired Duration Metric a. Video Impaired Duration Metric
* Metric Name: Video Impaired Duration Metric * Metric Name: Video Impaired Duration Metric
* Metric Description: The total time length of video impaired by * Metric Description: The total duration of the video impaired by
transmission loss before applying any loss concealment methods. transmission loss before applying any loss concealment methods.
* Method of Measurement or Calculation: The metric is based on * Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video measurements that are typically made at the time that a video
frame is decoded and rendered for playout. frame is decoded and rendered for playout.
* Units of Measurement: This metric is expressed in units of RTP * Units of Measurement: This metric is expressed in units of RTP
timestamp. timestamp.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of Section 4. * Measurement Timing: See paragraph 1 of Section 4.
* Use and Applications: The metric is applicable to video * Use and Applications: The metric is applicable to video
applications of RTP and the video component of Audio/Video applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are applications in which packet loss concealment mechanisms are
applied to the receiving endpoint to mitigate the impact of applied to the receiving endpoint to mitigate the impact of
network impairments on QoE. network impairments on QoE.
b. Video Concealed Duration Metric b. Video Concealed Duration Metric
* Metric Name: Video Concealed Duration Metric * Metric Name: Video Concealed Duration Metric
* Metric Description: The total time length of concealed damaged * Metric Description: The total duration of concealed damaged
video pictures on which loss concealment method corresponding to video pictures on which loss concealment method corresponding
Video Loss Concealment Method Type is applied. to Video Loss Concealment Method Type is applied.
* Method of Measurement or Calculation: The metric is based on * Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video measurements that are typically made at the time that a video
frame is decoded and rendered for playout. frame is decoded and rendered for playout.
* Units of Measurement: This metric is expressed in units of RTP * Units of Measurement: This metric is expressed in units of RTP
timestamp. timestamp.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of Section 4. * Measurement Timing: See paragraph 1 of Section 4.
* Use and Applications: These metrics are applicable to video * Use and Applications: These metrics are applicable to video
applications of RTP and the video component of Audio/Video applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact of incorporated into the receiving endpoint to mitigate the impact
network impairments on QoE. of network impairments on QoE.
c. Mean Video Frame Freeze Duration Metric c. Mean Video Frame-Freeze Duration Metric
* Metric Name: Mean Video Frame Freeze Duration Metric * Metric Name: Mean Video Frame-Freeze Duration Metric
* Metric Description: The mean duration of the frame freeze * Metric Description: The mean duration of the frame-freeze
events. events.
* Method of Measurement or Calculation: The metric is based on * Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video measurements that are typically made at the time that a video
frame is decoded and rendered for playout. The metric is frame is decoded and rendered for playout. The metric is
calculated by summing the total duration of all frame freeze calculated by summing the total duration of all frame-freeze
events and dividing by the number of events. events and dividing by the number of events.
* Units of Measurement: This metric is expressed in units of RTP * Units of Measurement: This metric is expressed in units of RTP
timestamp. timestamp.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of Section 4. * Measurement Timing: See paragraph 1 of Section 4.
* Use and Applications: These metrics are applicable to video * Use and Applications: These metrics are applicable to video
applications of RTP and the video component of Audio/Video applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact of incorporated into the receiving endpoint to mitigate the impact
network impairments on QoE. of network impairments on QoE.
d. Mean Impaired Video Frame Proportion Metric d. Mean Impaired Video Frame Proportion Metric
* Metric Name: Mean Impaired Video Frame Proportion Metric * Metric Name: Mean Impaired Video Frame Proportion Metric
* Metric Description: Mean proportion of each video frame impaired * Metric Description: Mean proportion of each video frame
by loss before applying any loss concealment method during the impaired by loss before applying any loss concealment method
interval. during the interval.
* Method of Measurement or Calculation: The metric is based on * Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video measurements that are typically made at the time that a video
frame is decoded and rendered for playout. It is calculated by frame is decoded and rendered for playout. It is calculated by
summing the impaired proportion of each video frame and dividing summing the impaired proportion of each video frame and
by the number of frames during this period. The impaired dividing by the number of frames during this period. The
proportion of each video frame is obtained by dividing the number impaired proportion of each video frame is obtained by dividing
of missing macroblocks from this video frame by the total the number of missing macroblocks from this video frame by the
macroblock number of the video frame, which is equivalent to total macroblock number of the video frame, which is equivalent
multiplying the result of the division by 256, limiting the to multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer maximum value to 255 (to avoid overflow), and taking the
part. integer part.
* Units of Measurement: This metric is expressed as a fixed point * Units of Measurement: This metric is expressed as a fixed-point
number with the binary point at the left edge of the field. number with the binary point at the left edge of the field.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of Section 4. * Measurement Timing: See paragraph 1 of Section 4.
* Use and Applications: These metrics are applicable to video * Use and Applications: These metrics are applicable to video
applications of RTP and the video component of Audio/Video applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact of incorporated into the receiving endpoint to mitigate the impact
network impairments on QoE. of network impairments on QoE.
e. Mean Concealed Video Frame Proportion Metric e. Mean Concealed Video Frame Proportion Metric
* Metric Name: Mean Concealed Video Frame Proportion Metric * Metric Name: Mean Concealed Video Frame Proportion Metric
* Metric Description: Mean proportion of each video frame to which * Metric Description: Mean proportion of each video frame to
loss concealment (using Video Loss Concealment Method Type) was which loss concealment (using Video Loss Concealment Method
applied during the interval. Type) was applied during the interval.
* Method of Measurement or Calculation: The metric is based on * Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video measurements that are typically made at the time that a video
frame is decoded and rendered for playout. It is calculated by frame is decoded and rendered for playout. It is calculated by
summing the concealed proportion of each video frame and dividing summing the concealed proportion of each video frame and
by the number of frames during this period. The concealed dividing by the number of frames during this period. The
proportion of each video frame is obtained by dividing the number concealed proportion of each video frame is obtained by
of concealed macroblocks from this video frame by the total dividing the number of concealed macroblocks from this video
macroblock number of the video frame, which is equivalent to frame by the total macroblock number of the video frame, which
multiplying the result of the division by 256, limiting the is equivalent to multiplying the result of the division by 256,
maximum value to 255 (to avoid overflow), and taking the integer limiting the maximum value to 255 (to avoid overflow), and
part. taking the integer part.
* Units of Measurement: This metric is expressed as a fixed point * Units of Measurement: This metric is expressed as a fixed-point
number with the binary point at the left edge of the field. number with the binary point at the left edge of the field.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of Section 4. * Measurement Timing: See paragraph 1 of Section 4.
* Use and Applications: These metrics are applicable to video * Use and Applications: These metrics are applicable to video
applications of RTP and the video component of Audio/Video applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact of incorporated into the receiving endpoint to mitigate the impact
network impairments on QoE. of network impairments on QoE.
f. Fraction of Video Frames Subject to Concealment Metric f. Fraction of Video Frames Subject to Concealment Metric
* Metric Name: Fraction of Video Frames Subject to Concealment * Metric Name: Fraction of Video Frames Subject to Concealment
Metric Metric
* Metric Description: Proportion of concealed video frames to * Metric Description: Proportion of concealed video frames to
which loss concealment (using Video Loss Concealment Method Type) which loss concealment (using the Video Loss Concealment Method
was applied comparing to the total number of frames during the Type) was applied compared to the total number of frames during
interval. the interval.
* Method of Measurement or Calculation: The metric is based on * Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video measurements that are typically made at the time that a video
frame is decoded and rendered for playout. This metric is frame is decoded and rendered for playout. This metric is
calculated by dividing the number of frames to which loss calculated by dividing the number of frames to which loss
concealment (using Video Loss Concealment Method Type) was applied concealment (using Video Loss Concealment Method Type) was
by the total number of frames. It is equivalent to multiplying the applied by the total number of frames. It is equivalent to
result of the division by 256, limiting the maximum value to 255 multiplying the result of the division by 256, limiting the
(to avoid overflow), and taking the integer part. maximum value to 255 (to avoid overflow), and taking the
integer part.
* Units of Measurement: This metric is expressed as a fixed point * Units of Measurement: This metric is expressed as a fixed-
number with the binary point at the left edge of the field. point number with the binary point at the left edge of the
field.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of Section 4. * Measurement Timing: See paragraph 1 of Section 4.
* Use and Applications: These metrics are applicable to video * Use and Applications: These metrics are applicable to video
applications of RTP and the video component of Audio/Video applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact of incorporated into the receiving endpoint to mitigate the impact
network impairments on QoE. of network impairments on QoE.
Acknowledgements
The author would like to thank Colin Perkins and Roni Even for their
valuable comments.
Authors' Addresses Authors' Addresses
Rachel Huang Rachel Huang
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing 210012 Nanjing 210012
China China
EMail: rachel.huang@huawei.com Email: rachel.huang@huawei.com
 End of changes. 143 change blocks. 
383 lines changed or deleted 400 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/