draft-ietf-mmusic-media-loopback-00.txt   draft-ietf-mmusic-media-loopback-01.txt 
K. Hedayat K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: June 30, 2005 P. Jones Expires: December 27,2005 P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
A. Roychowdhury A. Roychowdhury
Hughes Software Systems Flextronics Software Systems
C. SivaChelvan C. SivaChelvan
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BroadVoice BroadVoice
December 2, 2004 June 27, 2005
An Extension to the Session Description Protocol (SDP) for Media An Extension to the Session Description Protocol (SDP) for Media
Loopback Loopback
draft-ietf-mmusic-media-loopback-00.txt draft-ietf-mmusic-media-loopback-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which we are aware have been applicable patent or other IPR claims of which he or she is aware
disclosed and any of which we become aware will be disclosed, in have been or will be disclosed, and any of which he or she becomes
accordance with RFC 3668 (BCP 79). aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, we accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
The wide deployment of VoIP and Video over IP services has The wide deployment of VoIP and Video over IP services has
introduced new challenges in managing and maintaining voice/video introduced new challenges in managing and maintaining voice/video
quality, reliability, and overall performance. In particular, quality, reliability, and overall performance. In particular,
media delivery is an area that needs attention. One method of media delivery is an area that needs attention. One method of
meeting these challenges is monitoring the media delivery meeting these challenges is monitoring the media delivery
performance by looping media back to the transmitter. This is performance by looping media back to the transmitter. This is
typically referred to as "active monitoring" of services. Media typically referred to as "active monitoring" of services. Media
loopback is especially popular in ensuring the quality of transport loopback is especially popular in ensuring the quality of transport
to the edge of a given VoIP or Video over IP service. Today in to the edge of a given VoIP or Video over IP service. Today in
networks that deliver real-time media, short of running ' ping' and networks that deliver real-time media, short of running ' ping' and
skipping to change at page 2, line 27 skipping to change at page 2, line 30
SDP media attributes which enables establishment of media sessions SDP media attributes which enables establishment of media sessions
where the media is looped back to the transmitter. Such media where the media is looped back to the transmitter. Such media
sessions will serve as monitoring and troubleshooting tools by sessions will serve as monitoring and troubleshooting tools by
providing the means for measurement of more advanced VoIP and Video providing the means for measurement of more advanced VoIP and Video
Over IP performance metrics. Over IP performance metrics.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
2. Terminology...................................................3 2. Terminology...................................................3
3. Offering Entity Behavior......................................3 3. Offering Entity Behavior......................................4
4. Answering Entity Behavior.....................................4 4. Answering Entity Behavior.....................................4
5. SDP Constructs Syntax.........................................4 5. SDP Constructs Syntax.........................................4
5.1 Loopback Type Attribute...................................4 5.1 Loopback Type Attribute...................................4
5.2 Loopback Mode Attribute...................................5 5.2 Loopback Mode Attribute...................................6
5.3 Generating the Offer for Loopback Session.................5 5.3 Generating the Offer for Loopback Session.................6
5.4 Generating the Answer for Loopback Session................6 5.4 Generating the Answer for Loopback Session................7
5.5 Offerer Processing of the Answer..........................7 5.5 Offerer Processing of the Answer..........................8
5.6 Modifying the Session.....................................7 5.6 Modifying the Session.....................................8
6. RTP Requirements..............................................7 6. RTP Requirements..............................................8
7. RTCP Requirements.............................................8 7. RTCP Requirements.............................................9
8. Examples......................................................8 8. Examples......................................................9
8.1 Offer for specific media loopback type....................8 8.1 Offer for specific media loopback type....................9
8.2 Offer for choice of media loopback type...................9 8.2 Offer for choice of media loopback type..................10
8.3 Response to INVITE request rejecting loopback media......10 8.3 Offer for choice of media loopback type with
9. Implementer Guidelines.......................................11 rtp-start-loopback...........................................11
10. Security Considerations.....................................11 8.4 Response to INVITE request rejecting loopback media......12
11. IANA Considerations.........................................11 8.5 Response to INVITE request rejecting loopback media with
12. Acknowledgements............................................11 rtp-start-loopback...........................................13
13. References..................................................11 9. Security Considerations......................................13
13.1 Normative References....................................11 10. IANA Considerations.........................................14
11. Acknowledgements............................................14
12. References..................................................14
12.1 Normative References....................................14
1. Introduction 1. Introduction
The overall quality, reliability, and performance of VoIP and Video The overall quality, reliability, and performance of VoIP and Video
over IP services relies on the performance and quality of the media over IP services relies on the performance and quality of the media
path. In order to assure the quality of the delivered media there path. In order to assure the quality of the delivered media there
is a need to monitor the performance of the media transport. One is a need to monitor the performance of the media transport. One
method of monitoring and managing the overall quality of VoIP and method of monitoring and managing the overall quality of VoIP and
Video over IP Services is through monitoring the quality of the Video over IP Services is through monitoring the quality of the
media in an active session. This type of "active monitoring" of media in an active session. This type of "active monitoring" of
services is a method of pro-actively managing the performance and services is a method of pro-actively managing the performance and
skipping to change at page 4, line 39 skipping to change at page 4, line 42
Two new media attributes are defined: one indicates the type of Two new media attributes are defined: one indicates the type of
loopback and one indicates the mode of the loopback. loopback and one indicates the mode of the loopback.
5.1 Loopback Type Attribute 5.1 Loopback Type Attribute
The loopback type is a property media attribute with the following The loopback type is a property media attribute with the following
syntax: syntax:
a=loopback:<loopback-type> a=loopback:<loopback-type>
Following is the Augmented BNF (RFC 2234) [RFC2234] for loopback- Following is the Augmented BNF (RFC 2234) [RFC2234] for
type: loopback-type:
loopback-type = loopback-type-choice [ space loopback-type-choice ] loopback-type = loopback-type-choice [ space loopback-type-choice ]
loopback-type-choice = "rtp-pkt-loopback" | "rtp-media-loopback" loopback-type-choice = "rtp-pkt-loopback" | "rtp-media-loopback |
rtp-start-loopback"
The loopback type is used to indicate the type of loopback. The The loopback type is used to indicate the type of loopback. The
loopback-type values are rtp-pkt-loopback and rtp-media-loopback. loopback-type values are rtp-pkt-loopback, rtp-media-loopback, and
rtp-start-loopback.
rtp-pkt-loopback: In this mode, the RTP packets are looped back to rtp-pkt-loopback: In this mode, the RTP packets are looped back to
the sender at a point before the encoder/decoder function in the the sender at a point before the encoder/decoder function in the
receive direction to a point after the encoder/decoder function in receive direction to a point after the encoder/decoder function in
the send direction. This effectively re-encapsulates the RTP the send direction. This effectively re-encapsulates the RTP
payload with the RTP/UDP/IP overheads appropriate for sending it in payload with the RTP/UDP/IP overheads appropriate for sending it in
the reverse direction. Any type of encoding related functions, the reverse direction. Any type of encoding related functions,
such as packet loss concealment, MUST NOT be part of this type of such as packet loss concealment, MUST NOT be part of this type of
loopback path. loopback path.
rtp-media-loopback: This loopback is activated as close as possible rtp-media-loopback: This loopback is activated as close as possible
to the analog interface and after the decoder so that the RTP to the analog interface and after the decoder so that the RTP
packets are subsequently re-encoded prior to transmission back to packets are subsequently re-encoded prior to transmission back to
the sender. the sender.
rtp-start-loopback: In certain scenarios it is possible that the
media transmitted by the offering entity is blocked by a network
element until the answering entity starts transmitting packets.
One example of this scenario is the presence of an RTP relay in the
path of the media. RTP relays exist in VoIP networks for purpose
of NAT and Firewall traversal. If an RTP relay is present the
offering entity∆s packets are dropped by the RTP relay until the
answering entity has started transmitting media and the media state
within the RTP relay is established. This loopback attribute is
used to specify the media type for transmitting media packets by
the answering entity prior to the loopback process for the purpose
of setting media state within the network. In the presence of this
loopback attribute the answering entity will transmit media,
according to the description that contains this attribute, until it
receives media from the offering entity. After the first media
packet is received from the offering entity, the answering entity
MUST terminate the transmission of rtp-start-loopback media and
MUST start looping back media as defined by the other loopback
attributes present in the offer. If an offer includes the
rtp-start-loopback attribute it MUST also include at least one
other attribute as defined in this section. The offering entity is
able to filter rtp-start-loopback packets from other types of
loopback with the payload type of the packet. The media port number
for rtp-start-loopback MUST be the same as the corresponding
loopback attribute that will take over after the reception of first
media packet from the offering entity.
It is recommended that an offering entity specifying media with
either rtp-pkt-loopback or rtp-media-loopback attribute also
specify the rtp-start-loopback attribute unless the offering entity
is certain that its media will not be blocked by a network entity
as explained above.
5.2 Loopback Mode Attribute 5.2 Loopback Mode Attribute
The loopback mode is a value media attribute that is used to The loopback mode is a value media attribute that is used to
indicate the mode of the loopback. These attributes can be viewed indicate the mode of the loopback. These attributes can be viewed
as additional mode attributes similar to sendonly, recvonly, etc. as additional mode attributes similar to sendonly, recvonly, etc.
The syntax of the loopback mode media attribute is: The syntax of the loopback mode media attribute is:
a=<loopback-mode> a=<loopback-mode>
The loopback-mode values are loopback-source and loopback-mirror.. The loopback-mode values are loopback-source and loopback-mirror.
loopback-source: This attribute specifies that the sender is the loopback-source: This attribute specifies that the sender is the
media source and expects the receiver to act as a loopback-mirror. media source and expects the receiver to act as a loopback-mirror.
loopback-mirror: This attribute specifies that the receiver will loopback-mirror: This attribute specifies that the receiver will
mirror (echo) all received media back to the sender of the RTP mirror (echo) all received media back to the sender of the RTP
stream. No media is generated locally by the reciver for stream. No media is generated locally by the reciver for
transmission in the mirrored stream. transmission in the mirrored stream.
The loopback mode attribute does not apply to rtp-start-loopback
attribute and MAY be omitted. If the loopback mode attribute is
present with the rtp-start-loopback attribute it MUST be ignored by
the answering entity.
5.3 Generating the Offer for Loopback Session 5.3 Generating the Offer for Loopback Session
If an offerer wishes to make a loopback request, it MUST include If an offerer wishes to make a loopback request, it MUST include
both the loopback-type and loopback-mode attribute in a valid SDP both the loopback-type and loopback-mode attribute in a valid SDP
offer: offer:
Example: a=loopback-type:rtp-media-loopback Example: a=loopback:rtp-media-loopback
a=loopback-source a=loopback-source
Note: A loopback offer in a given media description MUST NOT Note: A loopback offer in a given media description MUST NOT
contain the standard mode attributes sendonly, recvonly, sendrecv contain the standard mode attributes sendonly, recvonly, sendrecv
or inactive. or inactive.
The offerer may offer more than one loopback-type in the SDP offer. The offerer may offer more than one loopback-type in the SDP offer.
In this case the answer MUST include only one of the loopback types In this case the answer MUST include only one of the loopback types
that is accepted by the answerer. The answerer SHOULD give that is accepted by the answerer. The answerer SHOULD give
preference to the first loopback-type in the SDP offer. preference to the first loopback-type in the SDP offer.
For loopback-source media (e.g. audio) streams, the port number and For loopback-source media (e.g. audio) streams, the port number and
skipping to change at page 6, line 32 skipping to change at page 7, line 26
If an answerer wishes to accept the loopback request it MUST If an answerer wishes to accept the loopback request it MUST
include both the loopback mode and loopback type attribute in the include both the loopback mode and loopback type attribute in the
answer. If a stream is offered with loopback-source or answer. If a stream is offered with loopback-source or
loopback-mirror attributes, the corresponding stream MUST be loopback-mirror attributes, the corresponding stream MUST be
loopback-mirror or loopback-source respectively, provided that loopback-mirror or loopback-source respectively, provided that
answerer is capable of supporting the requested loopback-type. answerer is capable of supporting the requested loopback-type.
For example, if the offer contains: For example, if the offer contains:
a=loopback-type:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-source a=loopback-source
The answer that is capable of supporting the offer MUST contain: The answer that is capable of supporting the offer MUST contain:
a=loopback-type:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror a=loopback-mirror
As previously stated if a stream is offered with multiple loopback As previously stated if a stream is offered with multiple loopback
type attributes, the corresponding stream MUST contain only one type attributes, the corresponding stream MUST contain only one
loopback type attribute selected by the answerer. loopback type attribute selected by the answerer.
For example, if the offer contains: For example, if the offer contains:
a=loopback-type:rtp-media-loopback rtp-pkt-loopback a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-source a=loopback-source
The answer that is capable of supporting the offer and chooses to The answer that is capable of supporting the offer and chooses to
loopback the media using the rtp-media-loopback type MUST contain: loopback the media using the rtp-media-loopback type MUST contain:
a=loopback-type:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror a=loopback-mirror
5.4.1 Rejecting the Loopback Offer 5.4.1 Rejecting the Loopback Offer
An offered stream with loopback-source MAY be rejected, if the An offered stream with loopback-source MAY be rejected, if the
loopback-type is not specified, the specified loopback-type is not loopback-type is not specified, the specified loopback-type is not
supported, or the endpoint cannot honor the offer for any other supported, or the endpoint cannot honor the offer for any other
reason. The Loopback request may be rejected by setting the media reason. The Loopback request may be rejected by setting the media
port number to zero, according to RFC 3264 [RFC3264], in the port number to zero, according to RFC 3264 [RFC3264], in the
answer. answer.
5.5 Offerer Processing of the Answer 5.5 Offerer Processing of the Answer
skipping to change at page 10, line 23 skipping to change at page 11, line 19
e=user@example.com e=user@example.com
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-mirror a=loopback-mirror
The server is accepting to mirror the media from the client at the The server is accepting to mirror the media from the client at the
packet level. packet level.
8.3 Response to INVITE request rejecting loopback media 8.3 Offer for choice of media loopback type with rtp-start-loopback
A client sends an INVITE request with SDP which looks like:
v=0
o=user1 2890844526 2890842807 IN IP4 126.16.64.4
s=Example
i=An example session
e=user@example.com
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0
a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-source
m=audio 49170 RTP/AVP 100
a=loopback:rtp-start-loopback
The client is offering to source the media and expects the server
to mirror the RTP stream at either the media or rtp level. The
client also expects the server to source media until it receives
packets from the server per media described with the
rtp-start-loopback attribute.
A server sends a response with SDP which looks like:
v=0
o=user1 2890844526 2890842807 IN IP4 126.16.64.4
s=Example
i=An example session
e=user@example.com
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0
a=loopback:rtp-pkt-loopback
a=loopback-mirror
m=audio 49170 RTP/AVP 100
a=rtpmap:100 pcmu/8000
a=loopback:rtp-start-loopback
The server is accepting to mirror the media from the client at the
packet level. The server is also accepting to source media until
it receives media packets from the client.
8.4 Response to INVITE request rejecting loopback media
A client sends an INVITE request with SDP which looks like: A client sends an INVITE request with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 126.16.64.4 o=user1 2890844526 2890842807 IN IP4 126.16.64.4
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=user@example.com
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=0 0 t=0 0
skipping to change at page 11, line 12 skipping to change at page 13, line 5
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror a=loopback-mirror
NOTE: Loopback request may be rejected by either not including the NOTE: Loopback request may be rejected by either not including the
loopback mode attribute(for backward compatibility) or setting the loopback mode attribute(for backward compatibility) or setting the
media port number to zero, or both, in the response. media port number to zero, or both, in the response.
9. Implementer Guidelines 8.5 Response to INVITE request rejecting loopback media with
rtp-start-loopback
This section provides guidelines to the implementers of this A client sends an INVITE request with SDP which looks like:
extension.
10. Security Considerations v=0
o=user1 2890844526 2890842807 IN IP4 126.16.64.4
s=Example
i=An example session
e=user@example.com
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0
a=loopback:rtp-media-loopback
a=loopback-source
m=audio 49170 RTP/AVP 100
a=loopback:rtp-start-loopback
The client is offering to source the media and expects the server
to mirror the RTP stream at the media level. The client also
expects the server to source media until it receives packets from
the server per media described with the rtp-start-loopback
attribute.
A server sends a response with SDP which looks like:
v=0
o=user1 2890844526 2890842807 IN IP4 126.16.64.4
s=Example
i=An example session
e=user@example.com
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 0 RTP/AVP 0
a=loopback:rtp-media-loopback
a=loopback-mirror
m=audio 0 RTP/AVP 0
a=loopback:rtp-start-loopback
NOTE: Loopback request may be rejected by either not including the
loopback mode attribute(for backward compatibility) or setting the
media port number to zero, or both, in the response.
9. Security Considerations
The security considerations of [RFC3261] apply. Furthermore, given The security considerations of [RFC3261] apply. Furthermore, given
that media loopback may be automated without the end users that media loopback may be automated without the end user's
knowledge, the server of the media loopback should be aware of knowledge, the server of the media loopback should be aware of
denial of service attacks. It is recommended that sessions with denial of service attacks. It is recommended that sessions with
media loopback are authenticated and the frequency of such sessions media loopback are authenticated and the frequency of such sessions
are limited by the server. are limited by the server.
11. IANA Considerations 10. IANA Considerations
There are no IANA considerations associated with this There are no IANA considerations associated with this
specification. specification.
12. Acknowledgements 11. Acknowledgements
The authors wish to thank Flemming Andreasen, Jeff Bernstein, Paul The authors wish to thank Flemming Andreasen, Jeff Bernstein, Paul
Kyzivat, and Dave Oran for their comments and suggestions. Kyzivat, and Dave Oran for their comments and suggestions.
13. References 12. References
13.1 Normative References 12.1 Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M. Johnston, A., Peterson, J., Sparks, R., Handley, M.
and E. Schooler, "SIP: Session Initiation Protocol", and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, STD 1, June 2002. RFC 3261, STD 1, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with the Session Description Protocol (SDP)", Model with the Session Description Protocol (SDP)",
RFC 3264, STD 1, June 2002. RFC 3264, STD 1, June 2002.
[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", RFC 3550, STD 1, July 2003. Applications", RFC 3550, STD 1, July 2003.
skipping to change at page 13, line 4 skipping to change at page 15, line 29
Paul E. Jones Paul E. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Phone: +1 919 392 6948 Phone: +1 919 392 6948
EMail: paulej@packetizer.com EMail: paulej@packetizer.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Arjun Roychowdhury Arjun Roychowdhury
Hughes Software Systems Flextronics Software Systems
11717 Exploration Lane 11717 Exploration Lane
Germantown, MD 20876 Germantown, MD 20876
US US
Phone: +1 301 212 7860 Phone: +1 301 212 7860
EMail: aroychow@hssworld.com EMail: arjun.roy@flextronicssoftware.com
URI: http://www.hssworld.com/ URI: http://www.flextronicssoftware.com/
Chelliah SivaChelvan Chelliah SivaChelvan
Cisco Systems, Inc. Cisco Systems, Inc.
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, TX 75082 Richardson, TX 75082
US US
Phone: +1 972 813 5224 Phone: +1 972 813 5224
EMail: chelliah@cisco.com EMail: chelliah@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
skipping to change at page 14, line 27 skipping to change at page 17, line 11
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/