One document matched: draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt
AVT WG J. Peterson
Internet-Draft NeuStar
Expires: January 10, 2005 J. Rosenberg
dynamicsoft
July 12, 2004
A Multiplexing Mechanism for the Real-Time Protocol (RTP)
draft-peterson-rosenberg-avt-rtp-ssrc-demux-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
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
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a mechanism for the Real-Time Protocol (RTP)
that allows multiple RTP sessions to be demultiplexed at a single
port. Accordingly, it also requests that the IANA allocate assigned
ports for the use of RTP with three applications: voice, video and
text. A similar mechanism is proposed for the Real-Time Control
Protocol (RTCP). The use of this mechanism is confined to a strict
domain of applicability.
Peterson & Rosenberg Expires January 10, 2005 [Page 1]
Internet-Draft RTP SSRC Multiplexing July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multiple Ports vs. Single Port Multiplexing . . . . . . . . . 4
3. Applicability of this Mechanism . . . . . . . . . . . . . . . 5
4. RTP and SSRC Multiplexing . . . . . . . . . . . . . . . . . . 7
5. Negotiating Usage in SDP . . . . . . . . . . . . . . . . . . . 8
5.1 Specifying a Port in SDP . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1 Registration for SDP Attributes . . . . . . . . . . . . . 11
7.2 Registration for SIP option-tag . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Peterson & Rosenberg Expires January 10, 2005 [Page 2]
Internet-Draft RTP SSRC Multiplexing July 2004
1. Introduction
The Real-Time Protocol (RTP) specification (RFC 3550) [1]) Section 3
notes that "RTP depends upon the lower-layer protocol to provide some
mechanism such as ports to multiplex the RTP and RTCP packets of a
session." As such, there is no standard port over which RTP traffic
flows; ephemeral ports are generally selected for RTP connections.
While this simplifies the implementation of RTP as a protocol, it
also gives rise to problems for applications that use RTP. Notably,
it interferes with the operation of Network Address Translators
(NATs, [8]). It also makes it hard for firewall administrators to
implement layer-4 policies for RTP, since the ports over which RTP
travels cannot be anticipated.
As such, this document proposes a mechanism for RTP that would allow
multiple RTP sessions to be multiplexed at a single transport-layer
port. A given host might instruct several peers, for example, to all
send media (using this extension) to the same transport address on
that host. This mechanism leverages the synchronization source
(SSRC) parameter of the RTP header to multiplex and demultiplex
discrete RTP sessions that are sent to the same IP address and port.
Multiplexing RTP for this purpose would yield little benefit if the
Real-Time Control Protocol (RTCP) did not admit of a similar
multiplexing scheme. Today, an RTCP session is paired with an RTP
session (typically, though not always, RTCP runs on a port one port
higher than RTP). This proposal continues to manage RTP and RTCP on
separate ports, but only one port will be required for RTCP.
RTP today is used to carry data associated with a number of common
media types. These include real-time voice, video and text traffic.
Since it desirable for firewall administrators to be able to
implement policies that allow or disallow particular media types,
this document requests that the IANA allocate separate standard RTP
ports for each of the three common media types. The 'rtp-voice' port
would also serve as a default port for all other media types, though
if in the future other media types for RTP become popular, they might
also warrant new media types.
The motivations for the existing RTP lower-layer multiplexing
decision are analyzed in Section 2, and current RTP operation is
compared with the use of the proposed extension. The use of the SSRC
to multiplex traffic is described in Section 4, and the problems with
sending multiple RTP sessions to the same transport address described
in Section 5.2 of RFC3550 are also examined. The use of this
mechanism is confined to the domain of applicability described in
Section 3, which provides a high-layer scheme for negotiating support
of this mechanism and reverting back to standard RTP if it is
Peterson & Rosenberg Expires January 10, 2005 [Page 3]
Internet-Draft RTP SSRC Multiplexing July 2004
unsupported.
2. Multiple Ports vs. Single Port Multiplexing
RTP runs over an existing transport protocol, such as UDP or DCCP
[7]. All transport protocols by definition carry a port number -
port numbers differentiate services or applications that are using a
single Internet address on a device. Therefore, during the design of
RTP, a decision was made that providing an indicator for handling
multiplexing within RTP would be undesirable because the transport
protocol under RTP already necessarily supports multiplexing through
multiple ports - adding capability for multiplexing within RTP would
be redundant.
Accordingly, selection of a port for RTP is deferred to the
application layer. Applications typically bind to a random available
port to listen for RTP, and then inform their peers (through an
out-of-band protocol like the Session Description Protocol (SDP [6])
the port to which media should be sent. However, carriage of RTP
over multiple ports has created a number of obstacles to the
widespread deployment of RTP. The most infamous of these is the
interaction with firewalls and Network Address Translators (NATs).
Typically, firewall administrators are reluctant to allow traffic on
arbitrary ports to enter (and in some cases exit) their network.
However, in order to allow the random ports selected by RTP, firewall
administrators have little recourse. If RTP (and RTCP) ran over
well-known assigned ports, firewall administrators could make a
trivial decision to allow traffic over such ports into their network.
NAT traversal presents an even more troublesome obstacle, since its
impacts on RTP traffic are not necessarily side-effects of policy
enforcement, but are innate in the deployment of many enterprises and
residential networks. Since NATs are fielded in order to conserve
IPv4 address resources by allowing multiple hosts to share a single
IP address, many users that would like to connect an IP telephone to
their existing residential network discover only inadvertently that
their NAT blocks RTP traffic.
In the absence of a single RTP port, a whole cottage industry of
standard and proprietary protocols and devices have emerged that
facilitate RTP's traversal through firewalls and NATs. The MIDCOM
and NSIS protocols, ICE [4] and its components (STUN [5] and TURN
[9]) are IETF standards that have been developed for this purpose.
Specifying a standard-port variant of RTP will not obviate the need
for mechanisms like ICE, but it does significantly simplify
authorized firewall traversal (essentially eliminating the need for
special-purpose ALGs or firewall controllers designed to permit VoIP
Peterson & Rosenberg Expires January 10, 2005 [Page 4]
Internet-Draft RTP SSRC Multiplexing July 2004
while maintaining network security), and it helps with some limited
NAT cases.
Given this problem space, there seems to be ample motivation for a
way of consolidating all RTP traffic for a single IP address down to
a single port that can easily be managed by middlebox administrators.
Section 5.2 of RFC3550 anticipates that applications designers might
want to multiplex several RTP streams over the same port, and
normatively recommends against this practice. Five major points are
raised against multiplexing in that section. The first three of
these points, as RFC3550 notes, do not effect mechanisms that use the
synchronization source (SSRC) for multiplexing. Of the remaining
two, point 4 notes that an RTP mixer would not be able to combine
streams of incompatible media into a single stream; however, since
the mechanism presented in this document still uses different ports
for different media types, this is not immediately applicable here.
Similarly, point 5 establishes more problems with sending different
varieties of media over the same port, and also notes that
establishing different network paths or resource allocations for
different sessions is rendered impossible. This last point is valid
in networks where certain quality of service (QoS) mechanisms are
used. In order for these mechanisms to work with a standard-port
variant of RTP, resource allocation for RTP would need to evolve into
a form similar to that used for TCP, where a 5-tuple is used to
identify network resources rather than just the pairs of network
addresses and ports. While this presents hurdles for the deployment
of such QoS mechanisms with standard-port RTP, they are not
insurmountable hurdles. On balance, the trade-off seems to favor the
specification of standard-port RTP.
3. Applicability of this Mechanism
If the mechanism proposed in this document is employed, but
understood by only one of the parties in an RTP session, the
consequences for the protocol could be very negative (i.e. in all
likelihood, RTP would not function properly). In order to prevent
this eventuality, implementations MUST NOT use this mechanism without
a higher-layer negotiation mechanism that allows implementations to
back off to traditional (unmodified) RTP.
Specifically, implementations of this session MUST negotiate the use
of the extension via SDP. Furthermore, implementations that use the
Session Initiation Protocol (SIP [2]) to carry such SDP MUST supply a
Require header field value with the 'sp-rtp' option-tag defined in
Section 5.
This mechanism is of primary value for traversing firewalls, in
Peterson & Rosenberg Expires January 10, 2005 [Page 5]
Internet-Draft RTP SSRC Multiplexing July 2004
keeping with the policies of firewall administrators, in the absence
of Network Address Translators. When NATs are used, the
applicability of this mechanism is more limited. The following
scenarios are appropriate for use with standard-port RTP:
If a single RTP implementation is behind a NAT, then the
administrator of the NAT can use a simple packet-forwarding rule
to forward all packets directed to standard RTP ports to the IP
address of the RTP implementation. This could be useful in some
residential deployments, for example.
If multiple RTP implementations are behind a NAT, then there must
be a single host which acts as a media relay for that network,
effectively demultiplexing and reflecting traffic to the RTP
implementations as appropriate. TURN servers could readily be
adapted to this purpose, and furthermore, many enterprises
effectively have such relays already, in the form of IP PBXs and
various sorts of devices that manage call centers.
However, even in these instances, this mechanism does not interact
well with the usage of STUN as a means for obtaining an IP address
and port to signal as the media destination. The problem is that the
NAT will modify the source port of the outbound STUN request, and the
source port it selected depends on the algorithms it implements,
along with the state of the NAT itself. As a result, a client is
likely to get back an IP address and a random port. This random port
will not match any of the default ports for RTP traffic. This will
make it impossible for the client to receive RTP traffic on the
default ports.
This problem is mitigated somewhat by NATs that provide a port
preservation property. Port preservation is defined as a property
whereby a NAT tries to preserve the source port in the outgoing
packet. However, even in NATs that provide port preservation, there
is a possibility that the port is already in use for another binding.
In such a case, the NAT is forced to allocate a different port to the
client. Thus, if a client sends its STUN messages from the default
RTP port, port preservation makes it possible that the STUN results
will indicate the same port, but there is no guarantee.
Eventually, as NAT's become less transparent and more controllable,
using techniques like MIDCOM and NSIS, a client could explicitly ask
for a binding to the necessary RTP port.
Fortunately, the mechanism described here is very compatible with
ICE. ICE is based on the idea that a client might be able to receive
RTP traffic at a multiplicity of IP addresses and ports. The default
RTP port just becomes one other possibility, and ICE's peer-to-peer
connectivity checks would be used to verify that RTP traffic could
flow to the default RTP port.
Peterson & Rosenberg Expires January 10, 2005 [Page 6]
Internet-Draft RTP SSRC Multiplexing July 2004
Indeed, ICE provides a good transition mechanism to aid in the
gradual adoption of the approach described here. ICE can be
configured to prefer RTP traffic that connects to the default port,
but would allow it to work to other ports when the default doesn't
work (as in the STUN case above). As the STUN cases reduce in
frequency (with the advent of more controllable devices and/or the
usage of TURN servers when multiple clients behind a NAT require RTP
services), ICE will discover, more and more frequently, that the
default RTP port works.
As this work progresses, it is expected that further work will be
done on the interaction between standard-port RTP, STUN, TURN and
ICE.
An additional limitation of this mechanism is that the usage of RTP
by multiple applications on a single host can be problematic, given
common RTP implementations today. Any application that binds to an
assigned port for RTP becomes the only application that can receive
such RTP packets on a host. However, the authors believe that there
are enough devices (like Internet telephones) that would only host a
single RTP application that this extension would still have
significant applicability without changes to existing RTP
implementations. In environments where multiple applications would
like to use RTP on a single host, RTP implementations would need to
provide system-wide services.
The applicability of this mechanism to multicast scenarios is a
subject for further study. The intended use of this mechanism is in
unicast scenarios, most likely those RTP sessions associated with the
Session Initiation Protocol (SIP).
4. RTP and SSRC Multiplexing
SSRC multiplexing does not require any extension to RTP. It reuses
the 32-bit synchronization source (SSRC) header, which already exists
in RFC3550, to differentiate discrete streams originating from a
single source.
The most obvious change to RTP behavior prescribed by this draft is
that RTP server applications would no longer bind to ephemeral ports,
but rather to one or more standard ports for various media types,
depending on the capabilities and needs of the application. RTP
implementations would also be required the multiplex and demultiplex
traffic according to the SSRC, and render the results appropriately
to higher level applications. This requires changes to existing RTP
APIs.
RFC3550 states that the SSRC is created randomly and unilaterally,
Peterson & Rosenberg Expires January 10, 2005 [Page 7]
Internet-Draft RTP SSRC Multiplexing July 2004
and that it must be globally unique within a particular RTP session
(which is especially meaningful in ad-hoc conferences, or when
multiple source devices are used to provide media for a single
participant). In order to use the mechanism described in this
document, the SSRC is negotiated collaboratively with other
participants in a session using a higher-layer protocol like the
Session Description Protocol (SDP). More information about
negotiating the SSRC in SDP and SIP is given in Section 5. Without
this higher-layer negotiation, this mechanism MUST NOT be used.
Additionally, the SSRC negotiated by an RTP application MUST be
unique across all RTP sessions on the host (or more specifically,
associated with the same network address), rather than merely unique
across participants in a particular RTP session.
RTCP also uses the SSRC parameter. Like RTP, RTCP server
applications would bind to standard ports rather than ephemeral
ports, and similar multiplexing/demultiplexing operations are
required to associate RTCP traffic with the proper multiplexed
session.
5. Negotiating Usage in SDP
The use of this mechanism with the Session Description Protocol (SDP)
requires the addition of new attributes to SDP that communicate the
values of the SSRC when using the offer/answer model (described in
RFC3263). It also eliminates the need for RTP port selection in SDP.
Thus, this mechanism defines two new attributes (a= lines) that can
appear in SDP: 'ssrc-upper' and 'ssrc-lower'. Each of these
attributes offers 16 bits of the SSRC that will be received by each
participant in a RTP session. When an SDP offer is made, the offerer
specifies the upper 16 bits of the SSRC in RTP that they will receive
in the 'ssrc-upper' parameter, and specifies the lower 16 bits of the
SSRC that the answerer will receive in the 'ssrc-lower' parameter.
When the SDP answer is formulated, the answerer again specifies the
upper 16 bits of the SSRC that they will receive in the 'ssrc-upper'
parameter, and specifies the lower bits of the SSRC that the offerer
will receive in the 'ssrc-lower' parameter. In both cases the
generation of these bits MUST be random (following the guidance given
in RFC3550 Appendix A) and MUST be unique across all RTP sessions
supported by the host.
So, for example, in an offer:
a:ssrc-upper=0x6f12
a:ssrc-lower=0xaa9f
Peterson & Rosenberg Expires January 10, 2005 [Page 8]
Internet-Draft RTP SSRC Multiplexing July 2004
and in the answer:
a:ssrc-upper=0x8b3b
a:ssrc-lower=0x110c
In this example, the RTP from the offerer to the answerer would have
SSRC 0x8b3baa9f, and the SSRC from the answerer to offerer would be
0x6f12110c.
The primary motivation for this collaborative agreement on SSRCs is
to allow this mechanism to work with cases where SIP forking has
occurred. Without this collaboration on SSRC, it would be difficult
to distinguish media coming from different SIP user agents that were
reached by an offer.
Note that this mechanism does not eliminate the potential for
collisions in SSRC selection described in RFC3550 Section 8.1. In
fact, since each party to an offer/answer in a SIP forking case
specifies only 16 bits of their SSRC, the potential for collisions
may be higher. However, given a reasonable amount of randomness, the
odds of a collision remain very low, and SDP could conceivably be
used to renegotiate the SSRC in case of a collision.
5.1 Specifying a Port in SDP
The presence of the 'ssrc-upper' and 'ssrc-lower' attributes in an
SDP offer signals that this use of this mechanism is desired. SDP
answerers MUST NOT supply 'ssrc-upper' and 'ssrc-lower' attributes in
an SDP answer if they were not present in the offer; if the answerer
requires the use of this extension, they SHOULD refuse the initial
offer and formulate an appropriate counteroffer.
SDP attributes that are not understood are ignored. Consequently, if
an SDP offer containing 'ssrc-upper' and 'ssrc-lower' is answered
with an SDP that does not contain these attributes, the offerer can
determine that this extension is unsupported. However, this would
not prevent the answerer from sending RTP media based on its
understanding of the offer, which could have undesirable
consequences, especially in SIP cases where the SDP offer is forked
to multiple endpoints.
When SIP INVITEs are used to carry SDP that contains the 'ssrc-upper'
and 'ssrc-lower' attributes, those messages MUST have a SIP Require
header field value containing the option-tag 'sp-rtp'. If this
option is unsupported by recipients of such SIP request, a suitable
SIP error code will be sent in the backwards direction, and the
parties may subsequently attempt to renegotiate a session without
Peterson & Rosenberg Expires January 10, 2005 [Page 9]
Internet-Draft RTP SSRC Multiplexing July 2004
supporting this mechanism.
SDP offers and answers use a field of the m= line to specify the port
to which media should be sent. In the context of this mechanism,
since standard port numbers are used, there is no need to signal a
media port in the m= line. Moreover, it is undesirable, when this
extension is used, to allow a port number to be specified (since this
would allow applications potentially to use the voice port for video
media, and the like). Therefore, the 'port' value of the m= line of
SDP using this mechanism MUST be set to 99999. This is an invalid
UDP port, and thus implementations which do not support this
mechanism will be unable to send or receive media at this port.
Implementations that support this mechanism MUST ignore the value
99999 in the port field of the m= line, and instead use the media
value of the m= line to determine the port to which they will send
media.
In particular, if the media value of the m= line is 'audio', the port
to which media will be sent MUST be the standard 'rtp-audio' port;
similarly, 'video' MUST use the 'rtp-video' port, and 'text' MUST use
the 'rtp-text' port. All other media values default to the
'rtp-audio' port, unless otherwise specified in a standards-track RFC
that extends this specification. The IANA will assign port numbers
for these ports as per the instructions in Section 7.
6. Security Considerations
If the mechanism described in this document is used by RTP
applications, firewall administrators will gain the ability to create
firewall policies to control admission of RTP to their networks with
a simple transport-layer filter. Like any other port-based policy,
however, it is not a perfect instrument of security. Mischievous
users have been known to send traffic over well-known ports (such as
port 80) that is not appropriate for the IANA-registered application
of that port. So while this document specifies, for example,
separate RTP ports for voice and video, there is nothing that
prevents a misbehaving application from accidentally or intentionally
sending RTP video over the RTP voice port, and so on. For more
information on the limitations of port-based security policies, see
[10].
That much said, this approach does increase the firewall-friendliness
of RTP significantly. In order to support an RTP implementation
based entirely on ephemeral ports, firewall administrator today would
have to open vast ranges of ephemeral ports to any applicable UDP
traffic. If the mechanism described in this draft were widely
deployed, firewall administrators would need to open only a handful
of ports in order to allow RTP traffic. Since in many environments,
Peterson & Rosenberg Expires January 10, 2005 [Page 10]
Internet-Draft RTP SSRC Multiplexing July 2004
network administrators might have to remove firewalls in order to
allow VoIP services on ephemeral ports, this mechanism improves the
security of deployments.
The best known practice for securing RTP is sRTP. Implementers
should strongly consider the use of sRTP to authenticate the source
of a media stream. The behavior suggested in this draft for
constructing SSRCs is not a substitute for cryptographic
authentication of a media source. The effects of this mechanism on
sRTP are a subject for further study.
7. IANA Considerations
This document requests that the IANA allocate three standard ports
associated with RTP media types: one port for 'rtp-audio', one or
'rtp-video', and one for 'rtp-text.' This document also requests that
the IANA allocate three standard ports for RTCP, one associated with
each of the RTP ports described above: 'rtcp-audio, 'rtcp-video' and
'rtcp-text'. Further, this document requests that the assignment
ports be ascending, and in the following order: rtp-audio,
rtcp-audio, rtp-video, rtcp-video, rtp-text, rtcp-text. The first
assigned port number must be an even number.
Future standards-track specifications may request the assignment of
additional ports that will be used by this mechanism. Such
specifications MUST identify ports corresponding to the top-level
media values that appear in the m= line of SDP.
7.1 Registration for SDP Attributes
This document requests that the IANA allocate two new media-level
attributes for SDP: 'ssrc-upper' and 'ssrc-lower'.
[Ed Note: The formal registrations TBD]
7.2 Registration for SIP option-tag
This document requests that the IANA allocate a new option-tag for
SIP: 'sp-rtp'.
[Ed Note: The formal registrations TBD]
8. References
8.1 Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
Peterson & Rosenberg Expires January 10, 2005 [Page 11]
Internet-Draft RTP SSRC Multiplexing July 2004
3261, May 2002.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3550, July 2003.
[3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[4] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
draft-ietf-mmusic-ice-01 (work in progress), February 2004.
[5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
[6] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-18 (work in
progress), June 2004.
[7] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", draft-ietf-dccp-spec-06 (work in
progress), February 2004.
8.2 Informative References
[8] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[9] Rosenberg, J., Huitema, C. and R. Mahy, "Traversal Using Relay
NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress),
February 2004.
[10] St. Johns, M. and G. Huston, "Considerations on the use of a
Service Identifier in Packet Headers", RFC 3639, October 2003.
[11] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
Peterson & Rosenberg Expires January 10, 2005 [Page 12]
Internet-Draft RTP SSRC Multiplexing July 2004
Authors' Addresses
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054-2711
US
Phone: +1 973/952-5050
EMail: jdrosen@dynamicsoft.com
URI: http://www.dynamicsoft.com/
Peterson & Rosenberg Expires January 10, 2005 [Page 13]
Internet-Draft RTP SSRC Multiplexing July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson & Rosenberg Expires January 10, 2005 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 10:01:08 |