draft-ietf-avtcore-multi-media-rtp-session-12.txt   draft-ietf-avtcore-multi-media-rtp-session-13.txt 
AVTCORE WG M. Westerlund AVTCORE WG M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3550, 3551 (if approved) C. Perkins Updates: 3550, 3551 (if approved) C. Perkins
Intended status: Standards Track University of Glasgow Intended status: Standards Track University of Glasgow
Expires: June 12, 2016 J. Lennox Expires: June 20, 2016 J. Lennox
Vidyo Vidyo
December 10, 2015 December 18, 2015
Sending Multiple Types of Media in a Single RTP Session Sending Multiple Types of Media in a Single RTP Session
draft-ietf-avtcore-multi-media-rtp-session-12 draft-ietf-avtcore-multi-media-rtp-session-13
Abstract Abstract
This document specifies how an RTP session can contain RTP Streams This document specifies how an RTP session can contain RTP Streams
with media from multiple media types such as audio, video, and text. with media from multiple media types such as audio, video, and text.
This has been restricted by the RTP Specification, and thus this This has been restricted by the RTP Specification, and thus this
document updates RFC 3550 and RFC 3551 to enable this behaviour for document updates RFC 3550 and RFC 3551 to enable this behaviour for
applications that satisfy the applicability for using multiple media applications that satisfy the applicability for using multiple media
types in a single RTP session. types in a single RTP session.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 12, 2016. This Internet-Draft will expire on June 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Real-time Transport Protocol [RFC3550] was designed to use The Real-time Transport Protocol [RFC3550] was designed to use
separate RTP sessions to transport different types of media. This separate RTP sessions to transport different types of media. This
implies that different transport layer flows are used for different implies that different transport layer flows are used for different
media streams. For example, a video conferencing application might RTP streams. For example, a video conferencing application might
send audio and video traffic RTP flows on separate UDP ports. With send audio and video traffic RTP flows on separate UDP ports. With
increased use of network address/port translation, firewalls, and increased use of network address/port translation, firewalls, and
other middleboxes it is, however, becoming difficult to establish other middleboxes it is, however, becoming difficult to establish
multiple transport layer flows between endpoints. Hence, there is multiple transport layer flows between endpoints. Hence, there is
pressure to reduce the number of concurrent transport flows used by pressure to reduce the number of concurrent transport flows used by
RTP applications. RTP applications.
This memo updates [RFC3550] and [RFC3551] to allow multiple media This memo updates [RFC3550] and [RFC3551] to allow multiple media
types to be sent in a single RTP session in certain cases, thereby types to be sent in a single RTP session in certain cases, thereby
reducing the number of transport layer flows that are needed. It reducing the number of transport layer flows that are needed. It
skipping to change at page 4, line 23 skipping to change at page 4, line 23
it makes it easy to use network layer quality of service (QoS) it makes it easy to use network layer quality of service (QoS)
mechanisms to give differentiated performance for different flows. mechanisms to give differentiated performance for different flows.
However, we note that many RTP-using application don't use network However, we note that many RTP-using application don't use network
QoS features, and don't expect or desire any separation in network QoS features, and don't expect or desire any separation in network
treatment of their media packets, independent of whether they are treatment of their media packets, independent of whether they are
audio, video or text. When an application has no such desire, it audio, video or text. When an application has no such desire, it
doesn't need to provide a transport flow structure that simplifies doesn't need to provide a transport flow structure that simplifies
flow based QoS. flow based QoS.
Given the above issues, it might seem appropriate for RTP-based Given the above issues, it might seem appropriate for RTP-based
applications to send all their media streams bundled into one RTP applications to send all their RTP streams bundled into one RTP
session, running over a single transport layer flow. However, this session, running over a single transport layer flow. However, this
is prohibited by the RTP specification, because the design of RTP is prohibited by the RTP specification, because the design of RTP
makes certain assumptions that can be incompatible with sending makes certain assumptions that can be incompatible with sending
multiple media types in a single RTP session. Specifically, the RTP multiple media types in a single RTP session. Specifically, the RTP
control protocol (RTCP) timing rules assume that all RTP media flows control protocol (RTCP) timing rules assume that all RTP media flows
in a single RTP session have broadly similar RTCP reporting and in a single RTP session have broadly similar RTCP reporting and
feedback requirements, which can be problematic when different types feedback requirements, which can be problematic when different types
of media are multiplexed together. Various RTP extensions also make of media are multiplexed together. Various RTP extensions also make
assumptions about SSRC use and RTCP reporting that are incompatible assumptions about SSRC use and RTCP reporting that are incompatible
with sending different media types in a single RTP session. with sending different media types in a single RTP session.
skipping to change at page 4, line 46 skipping to change at page 4, line 46
contain more than one media type in certain circumstances, and gives contain more than one media type in certain circumstances, and gives
guidance on when it is safe to send multiple media types in a single guidance on when it is safe to send multiple media types in a single
RTP session. RTP session.
4. Applicability 4. Applicability
This specification has limited applicability, and anyone intending to This specification has limited applicability, and anyone intending to
use it needs to ensure that their application and use case meets the use it needs to ensure that their application and use case meets the
following criteria: following criteria:
Equal treatment of media: The use of a single RTP session requires Equal treatment of media: The use of a single RTP session normally
similar network treatment for all types of media used within the results in similar network treatment for all types of media used
session. Applications that require significantly different within the session. Applications that require significantly
network quality of service (QoS) or RTCP configuration for different network quality of service (QoS) or RTCP configuration
different media streams are better suited by sending those media for different RTP streams are better suited by sending those RTP
streams on separate RTP session, using separate transport layer streams in separate RTP session, using separate transport layer
flows for each, since that gives greater flexibility. Further flows for each, since that gives greater flexibility. Further
guidance on how to provide differential treatment for some media guidance on how to provide differential treatment for some media
is given in [I-D.ietf-avtcore-multiplex-guidelines] and [RFC7657]. is given in [I-D.ietf-avtcore-multiplex-guidelines] and [RFC7657].
Compatible RTCP Behaviour: The RTCP timing rules enforce a single Compatible RTCP Behaviour: The RTCP timing rules enforce a single
RTCP reporting interval for all participants in an RTP session. RTCP reporting interval for all participants in an RTP session.
Flows with very different media sending rate or RTCP feedback Flows with very different media sending rate or RTCP feedback
requirements cannot be multiplexed together, since this leads to requirements cannot be multiplexed together, since this leads to
either excessive or insufficient RTCP for some flows, depending on either excessive or insufficient RTCP for some flows, depending on
how the RTCP session bandwidth, and hence reporting interval, is how the RTCP session bandwidth, and hence reporting interval, is
skipping to change at page 6, line 23 skipping to change at page 6, line 23
or media source identity name space that is common across all or media source identity name space that is common across all
interconnect parts is needed. interconnect parts is needed.
Ability to operate with limited payload type space: An RTP session Ability to operate with limited payload type space: An RTP session
has only a single 7-bit payload type space for all its payload has only a single 7-bit payload type space for all its payload
type numbers. Some applications might find this space limiting type numbers. Some applications might find this space limiting
when using different media types and RTP payload formats within a when using different media types and RTP payload formats within a
single RTP session. single RTP session.
Avoids incompatible Extensions: Some RTP and RTCP extensions rely on Avoids incompatible Extensions: Some RTP and RTCP extensions rely on
the existence of multiple RTP sessions and relate media streams the existence of multiple RTP sessions and relate RTP streams
between sessions. Others report on particular media types, and between sessions. Others report on particular media types, and
cannot be used with other media types. Applications that send cannot be used with other media types. Applications that send
multiple types of media into a single RTP session need to avoid multiple types of media into a single RTP session need to avoid
such extensions. such extensions.
5. Using Multiple Media Types in a Single RTP Session 5. Using Multiple Media Types in a Single RTP Session
This section defines what needs to be done or avoided to make an RTP This section defines what needs to be done or avoided to make an RTP
session with multiple media types function without issues. session with multiple media types function without issues.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
to exactly one of three categories or media types: audio only, to exactly one of three categories or media types: audio only,
video only and those combining audio and video. The media types video only and those combining audio and video. The media types
are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. are marked in Tables 4 and 5 as "A", "V" and "AV", respectively.
Payload types of different media types SHALL NOT be interleaved or Payload types of different media types SHALL NOT be interleaved or
multiplexed within a single RTP session, but multiple RTP sessions multiplexed within a single RTP session, but multiple RTP sessions
MAY be used in parallel to send multiple media types. An RTP MAY be used in parallel to send multiple media types. An RTP
source MAY change payload types within the same media type during source MAY change payload types within the same media type during
a session. See the section "Multiplexing RTP Sessions" of RFC a session. See the section "Multiplexing RTP Sessions" of RFC
3550 for additional explanation. 3550 for additional explanation.
This specifications purpose is to override that existing SHALL NOT This specification's purpose is to override that existing SHALL NOT
under certain conditions. Thus this sentence also has to be changed under certain conditions. Thus this sentence also has to be changed
to allow for multiple media type's payload types in the same session. to allow for multiple media type's payload types in the same session.
The above sentence is changed to: The sentence containing "SHALL NOT" in the above paragraph is changed
to:
Payload types of different media types SHALL NOT be interleaved or Payload types of different media types SHALL NOT be interleaved or
multiplexed within a single RTP session unless [RFCXXXX] is used, multiplexed within a single RTP session unless [RFCXXXX] is used,
and the application conforms to the applicability constraints. and the application conforms to the applicability constraints.
Multiple RTP sessions MAY be used in parallel to send multiple Multiple RTP sessions MAY be used in parallel to send multiple
media types. media types.
RFC-Editor Note: Please replace RFCXXXX with the RFC number of this RFC-Editor Note: Please replace RFCXXXX with the RFC number of this
specification when assigned. specification when assigned.
5.2. Demultiplexing media types within an RTP session 5.2. Demultiplexing media types within an RTP session
When receiving packets from a transport layer flow, an endpoint will When receiving packets from a transport layer flow, an endpoint will
first separate the RTP and RTCP packets from the non-RTP packets, and first separate the RTP and RTCP packets from the non-RTP packets, and
pass them to the RTP/RTCP protocol handler. The RTP and RTCP packets pass them to the RTP/RTCP protocol handler. The RTP and RTCP packets
are then demultiplexed based on their SSRC into the different media are then demultiplexed based on their SSRC into the different RTP
streams. For each media stream, incoming RTCP packets are processed, streams. For each RTP stream, incoming RTCP packets are processed,
and the RTP payload type is used to select the appropriate media and the RTP payload type is used to select the appropriate media
decoder. This process remains the same irrespective of whether decoder. This process remains the same irrespective of whether
multiple media types are sent in a single RTP session or not. multiple media types are sent in a single RTP session or not.
It is important to note that the RTP payload type is never used to As explained below, it is important to note that the RTP payload type
distinguish media streams. The RTP packets are demultiplexed into is never used to distinguish RTP streams. The RTP packets are
media streams based on their SSRC, then the RTP payload type is used demultiplexed into RTP streams based on their SSRC, then the RTP
to select the correct media decoding pathway for each media stream. payload type is used to select the correct media decoding pathway for
each RTP stream.
5.3. Per-SSRC Media Type Restrictions 5.3. Per-SSRC Media Type Restrictions
An SSRC in an RTP session can change between media formats of the An SSRC in an RTP session can change between media formats of the
same type, subject to certain restrictions [RFC7160], but MUST NOT same type, subject to certain restrictions [RFC7160], but MUST NOT
change media type during its lifetime. For example, an SSRC can change media type during its lifetime. For example, an SSRC can
change between different audio formats, but cannot start sending change between different audio formats, but cannot start sending
audio then change to sending video. The lifetime of an SSRC ends audio then change to sending video. The lifetime of an SSRC ends
when an RTCP BYE packet for that SSRC is sent, or when it ceases when an RTCP BYE packet for that SSRC is sent, or when it ceases
transmission for long enough that it times out for the other transmission for long enough that it times out for the other
skipping to change at page 9, line 49 skipping to change at page 9, line 49
to be associated. This can be signalled using SDP with the BUNDLE to be associated. This can be signalled using SDP with the BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation] and FID grouping [RFC5888] [I-D.ietf-mmusic-sdp-bundle-negotiation] and FID grouping [RFC5888]
extensions. These SDP extensions require each "m=" line to only be extensions. These SDP extensions require each "m=" line to only be
included in a single FID group, but the RTP retransmission payload included in a single FID group, but the RTP retransmission payload
format uses FID groups to indicate the m= lines that form an original format uses FID groups to indicate the m= lines that form an original
and retransmission pair. Accordingly, when using the BUNDLE and retransmission pair. Accordingly, when using the BUNDLE
extension to allow multiple media types to be sent in a single RTP extension to allow multiple media types to be sent in a single RTP
session, each original media source (m= line) that is retransmitted session, each original media source (m= line) that is retransmitted
needs a corresponding m= line in the retransmission RTP session. In needs a corresponding m= line in the retransmission RTP session. In
case there are multiple media lines for retransmission, these media case there are multiple media lines for retransmission, these media
lines will form a independent BUNDLE group from the BUNDLE group with lines will form an independent BUNDLE group from the BUNDLE group
the source streams. with the source streams.
An example SDP fragment showing the grouping structures is provided An example SDP fragment showing the grouping structures is provided
in Figure 1. This example is not legal SDP and only the most in Figure 1. This example is not legal SDP and only the most
important attributes have been left in place. Note that this SDP is important attributes have been left in place. Note that this SDP is
not an initial BUNDLE offer. As can be seen there are two bundle not an initial BUNDLE offer. As can be seen there are two bundle
groups, one for the source RTP session and one for the groups, one for the source RTP session and one for the
retransmissions. Then each of the media sources are grouped with its retransmissions. Then each of the media sources are grouped with its
retransmission flow using FID, resulting in three more groupings. retransmission flow using FID, resulting in three more groupings.
a=group:BUNDLE foo bar fiz a=group:BUNDLE foo bar fiz
skipping to change at page 11, line 9 skipping to change at page 11, line 9
When sending FEC as a separate stream, the RTP Payload Format for When sending FEC as a separate stream, the RTP Payload Format for
generic FEC requires that FEC stream to be sent in a separate RTP generic FEC requires that FEC stream to be sent in a separate RTP
session to the original stream, using the same SSRC, with the FEC session to the original stream, using the same SSRC, with the FEC
stream being associated by matching the SSRC between sessions. The stream being associated by matching the SSRC between sessions. The
RTP session used for the original streams can include multiple RTP RTP session used for the original streams can include multiple RTP
streams, and those RTP streams can use multiple media types. The streams, and those RTP streams can use multiple media types. The
repair session only needs one RTP Payload type to indicate FEC data, repair session only needs one RTP Payload type to indicate FEC data,
irrespective of the number of FEC streams sent, since the SSRC is irrespective of the number of FEC streams sent, since the SSRC is
used to associate the FEC streams with the original streams. Hence, used to associate the FEC streams with the original streams. Hence,
it is RECOMMENDED that FEC stream use the "application/ulpfec" media it is RECOMMENDED that the FEC stream use the "application/ulpfec"
type for [RFC5109], and the "application/parityfec" media type for media type for [RFC5109], and the "application/parityfec" media type
[RFC2733]. It is legal, but NOT RECOMMENDED, to send FEC streams for [RFC2733]. It is legal, but NOT RECOMMENDED, to send FEC streams
using media specific payload format names (e.g., if an original RTP using media specific payload format names (e.g., using both the
session contains audio and video flows, for the associated FEC RTP "audio/ulpfec" and "video/ulpfec" payload formats for a single RTP
session where to use the "audio/ulpfec" and "video/ulpfec" payload session containing both audio and video flows), since this
formats), since this unnecessarily uses up RTP payload type values, unnecessarily uses up RTP payload type values, and adds no value for
and adds no value for demultiplexing since there might be multiple demultiplexing since there might be multiple streams of the same
streams of the same media type). media type).
The combination of an original RTP session using multiple media types The combination of an original RTP session using multiple media types
with a associated generic FEC session can be signalled using SDP with with an associated generic FEC session can be signalled using SDP
the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation]. In with the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation].
this case, the RTP session carrying the FEC streams will be its own In this case, the RTP session carrying the FEC streams will be its
BUNDLE group. The m= line for each original stream and the m= line own BUNDLE group. The m= line for each original stream and the m=
for the corresponding FEC stream are grouped using the SDP grouping line for the corresponding FEC stream are grouped using the SDP
framework using either the FEC-FR [RFC5956] grouping or, for grouping framework using either the FEC-FR [RFC5956] grouping or, for
backwards compatibility, the FEC [RFC4756] grouping. This is similar backwards compatibility, the FEC [RFC4756] grouping. This is similar
to the situation that arises for RTP retransmission with session to the situation that arises for RTP retransmission with session
multiplexing discussed in Section 6.1. multiplexing discussed in Section 6.1.
The Source-Specific Media Attributes [RFC5576] specification defines The Source-Specific Media Attributes [RFC5576] specification defines
an SDP extension (the "FEC" semantic of the "ssrc-group" attribute) an SDP extension (the "FEC" semantic of the "ssrc-group" attribute)
to signal FEC relationships between multiple RTP streams within a to signal FEC relationships between multiple RTP streams within a
single RTP session. This cannot be used with generic FEC, since the single RTP session. This cannot be used with generic FEC, since the
FEC repair packets need to have the same SSRC value as the source FEC repair packets need to have the same SSRC value as the source
packets being protected. There is ongoing work on an ULP extension packets being protected. There was work on an Unequal Layer
to allow it be use FEC RTP streams within the same RTP Session as the Protection (ULP) extension to allow it be use FEC RTP streams within
source stream [I-D.lennox-payload-ulp-ssrc-mux]. the same RTP Session as the source stream
[I-D.lennox-payload-ulp-ssrc-mux].
When the FEC is sent as a redundant encoding, the considerations in When the FEC is sent as a redundant encoding, the considerations in
Section 6.3 apply. Section 6.3 apply.
6.3. RTP Payload Format for Redundant Audio 6.3. RTP Payload Format for Redundant Audio
The RTP Payload Format for Redundant Audio [RFC2198] can be used to The RTP Payload Format for Redundant Audio [RFC2198] can be used to
protect audio streams. It can also be used along with the generic protect audio streams. It can also be used along with the generic
FEC payload format to send original and repair data in the same RTP FEC payload format to send original and repair data in the same RTP
packets. Both are compatible with RTP sessions containing multiple packets. Both are compatible with RTP sessions containing multiple
media types. media types.
This payload format requires each different redundant encoding use a This payload format requires each different redundant encoding use a
different RTP payload type number. When used with generic FEC in different RTP payload type number. When used with generic FEC in
sessions that contain multiple media types, this requires each media sessions that contain multiple media types, this requires each media
type use a different payload type for the FEC stream. For example, type to use a different payload type for the FEC stream. For
if audio and text are sent in a single RTP session with generic ULP example, if audio and text are sent in a single RTP session with
FEC sent as a redundant encoding for each, then payload types need to generic ULP FEC sent as a redundant encoding for each, then payload
be assigned for FEC using the audio/ulpfec and text/ulpfec payload types need to be assigned for FEC using the audio/ulpfec and text/
formats. If multiple original payload types are used in the session, ulpfec payload formats. If multiple original payload types are used
different redundant payload types need to be allocated for each one. in the session, different redundant payload types need to be
This has potential to rapidly exhaust the available RTP payload type allocated for each one. This has potential to rapidly exhaust the
numbers. available RTP payload type numbers.
7. Signalling 7. Signalling
Establishing a single RTP session using multiple media types requires Establishing a single RTP session using multiple media types requires
signalling. This signalling has to: signalling. This signalling has to:
1. ensure that any participant in the RTP session is aware that this 1. ensure that any participant in the RTP session is aware that this
is an RTP session with multiple media types; is an RTP session with multiple media types;
2. ensure that the payload types in use in the RTP session are using 2. ensure that the payload types in use in the RTP session are using
skipping to change at page 13, line 14 skipping to change at page 13, line 15
different requirements. This can have significant costs in terms of different requirements. This can have significant costs in terms of
resource usage, session set-up time, etc. resource usage, session set-up time, etc.
9. IANA Considerations 9. IANA Considerations
This memo makes no request of IANA. This memo makes no request of IANA.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Christer Holmberg, Gunnar Hellstroem, The authors would like to thank Christer Holmberg, Gunnar Hellstroem,
Charles Eckel, Tolga Asveren, and Warren Kumari for their feedback on Charles Eckel, Tolga Asveren, Warren Kumari, and Meral Shirazipour
the document. for their feedback on the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-10 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
November 2015. December 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015. negotiation-23 (work in progress), July 2015.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
 End of changes. 19 change blocks. 
55 lines changed or deleted 58 lines changed or added

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