Internet DRAFT - draft-hunt-avt-rtcptrans
draft-hunt-avt-rtcptrans
Audio/Video Transport Working G. Hunt
Group BT
Internet-Draft November 12, 2007
Intended status: Informational
Expires: May 15, 2008
RTCP Reporting by Translators
draft-hunt-avt-rtcptrans-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Hunt Expires May 15, 2008 [Page 1]
Internet-Draft RTCP Reporting by Translators November 2007
Abstract
This memo addresses RTCP reporting by and through RTP translators.
It collects existing guidance from RFC 3550, systematises
translators' reporting behaviour by considering potential sources of
information and the policy-controlled forwarding of such information,
considers naming issues in labelling reports, considers methods of
control of reporting behaviour, and presents some examples of
architectures for reporting.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and recommendations from RFC3550 . . . . . . . . . 7
4. Requirements for reporting by translators . . . . . . . . . . 11
5. Architectural analysis . . . . . . . . . . . . . . . . . . . . 12
6. Naming considerations . . . . . . . . . . . . . . . . . . . . 15
6.1. SSRC and CNAME requirements from RFC3550 . . . . . . . . . 15
6.2. Identification of RTCP reports . . . . . . . . . . . . . . 16
6.3. Naming in reports to control layers . . . . . . . . . . . 17
7. Control of reporting by translators . . . . . . . . . . . . . 19
8. Example applications . . . . . . . . . . . . . . . . . . . . . 21
9. Combining RTCP packets from multiple sources . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Hunt Expires May 15, 2008 [Page 2]
Internet-Draft RTCP Reporting by Translators November 2007
1. Requirements notation
This memo is informative and as such contains no normative
requirements. However it does import text fragments from other
documents which contain normative requirements. The following
guidance is provided for interpretation of key words in these
fragments:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Any requirements are those of the quoted document and not of the
current informative memo.
Hunt Expires May 15, 2008 [Page 3]
Internet-Draft RTCP Reporting by Translators November 2007
2. Introduction
[RFC3550] defines three types of RTP systems which may source and
sink RTP streams. These types are RTP end systems, RTP mixers, and
RTP translators. For purposes of reporting connection quality to
other RTP systems, RTP mixers and RTP end systems are very similar.
Mixers resynchronize audio packets and do not relay RTCP reports
received from one cloud towards other cloud(s). Translators do not
resynchronize packets and SHOULD forward certain RTCP reports between
clouds. Translators have a wide range of possible reporting
behaviours. This memo is intended to assist readers in thinking
about the use of RTCP by RTP translators, by collecting relevant
requirements and architectural considerations.
An RTP translator is defined in [RFC3550] as "An intermediate system
that forwards RTP packets with their synchronization source
identifier intact". [RFC3550] gives the following examples of
translators: devices that convert encodings without mixing;
replicators from multicast to unicast; and application-level filters
in firewalls.
For each session, an RTP translator has at least two RTP connections
via different logical interfaces to network clouds, with logical
separation based on a transport layer identifier (e.g. by UDP port)
or at a lower layer (e.g. IP address, Ethernet VLAN identifier, ATM
VCI, or physical interface). RTP traffic streams flowing via these
two connections may be unicast or multicast, and may be
unidirectional or bidirectional. Section 7 of [RFC3550] defines the
RTCP processing in the translator which is required to maintain
correct semantics for the RTCP communication between the RTP end
systems involved in the connection.
This memo does not try to augment or in any way to modify normative
text of [RFC3550], but it gathers together the various items of text
from [RFC3550] which are relevant to RTCP processing and reporting by
translators. It attempts to clarify the consequences of the
recommendations, including those which arise from applying the
recommendations to RTCP-based reporting beyond the "basic" RTCP
standardised by [RFC3550].
The memo attempts to systematise the wide range of possibilities for
measurement and reporting topologies or architectures which arise
when RTP translators are capable of making measurements and sending
the resulting metrics to other RTP systems. It suggests that it is
helpful to consider the choices of "what measurements should be sent
where" as an application of policy. Different policies lead to
different tradeoffs between the cost of RTCP processing against the
level of detailed knowledge which RTCP makes available about the
Hunt Expires May 15, 2008 [Page 4]
Internet-Draft RTCP Reporting by Translators November 2007
performance of a monitored connection.
Section 3 collects relevant definitions and descriptions of
recommended behaviour from [RFC3550].
Section 4 states some known requirements which may be satisfied, or
partly satisfied, as a result of RTP translators' reporting of packet
transport metrics. These have been used to drive the architectural
suggestions.
Section 5 provides an architectural analysis of reporting by
translators. It considers the sources of the information which might
be available to an RTP system, and the destinations towards which
that information might be sent. It suggests that decisions by each
RTP system, to transfer information from specific sources or types of
sources towards specific destinations or types of destinations, may
be controlled by policy. The end-to-end measurement architecture
results from the collective effect of these policy-based decisions
made at each RTP system.
In connections involving multiple systems, it is important to know
which system made the measurements which resulted in a set of
metrics, and to know which system originated the packet stream which
is the subject of the measurement. Section 6 considers the naming
issues for SSRC and CNAME which arise.
Some recent groups of metrics have multiple optional sections. Some
of these may have significant costs, but may be useful in special
circumstances, either for specific types of connections or at
specific times (e.g. for diagnosis). This raises the question of
whether, and how, these capabilities might be activated when needed.
Section 7 outlines possible schemes for control of reporting by
translators. As this discussion touches on capabilities of the
signalling and management planes, which are outside the scope of the
memo, these methods are discussed only in general terms.
Section 8 provides some examples of the application of policy to
create useful monitoring architectures, e.g. to provide useful
localisation of transport faults whilst bounding the link bandwidth
and RTP system processing capacity occupied by RTCP.
[RFC3550] recommends that RTCP packets should be combined to minimise
header overheads. Using an example architecture from Section 8,
Section 9 considers how this might apply to the concatenation of
reports from multiple translators, and shows a possible benefit in
determining the order of named systems along a connection path.
Discussion in this memo is not restricted to any one set of metrics
Hunt Expires May 15, 2008 [Page 5]
Internet-Draft RTCP Reporting by Translators November 2007
within the broad scope of RTCP, such as "basic" RTCP as defined in
[RFC3550], RTCP XR as defined in [RFC3611], RTCP HR as defined in
[RTCPHR], or other schemes. It appears that any RTCP scheme which
meets the naming requirements of Section 6 may, in principle, be used
for reporting by an RTP translator. Individual metrics may not be
measurable or meaningful when reported by certain types of RTP
translator, e.g. metrics related to the behaviour of a de-jitter
buffer may not be relevant to an RTP translator which does not
contain a de-jitter buffer, but this level of detail is outside the
scope of the current memo.
Hunt Expires May 15, 2008 [Page 6]
Internet-Draft RTCP Reporting by Translators November 2007
3. Definitions and recommendations from RFC3550
RFC3550 [RFC3550] explains that RTP translators may be used to
connect two or more transport-level clouds, and provides a number of
detailed recommendations on the generation and processing of RTCP by
RTP translators. The following excerpts from [RFC3550] include the
key guidance on processing of RTCP by RTP translators. Naming-
related requirements from [RFC3550] are given special attention in
Section 6 below.
Section 3 of [RFC3550] provides the following definitions:
End system: An application that generates the content to be sent in
RTP packets and/or consumes the content of received RTP packets. An
end system can act as one or more synchronization sources in a
particular RTP session, but typically only one.
Mixer: An intermediate system that receives RTP packets from one or
more sources, possibly changes the data format, combines the packets
in some manner and then forwards a new RTP packet. Since the timing
among multiple input sources will not generally be synchronized, the
mixer will make timing adjustments among the streams and generate its
own timing for the combined stream. Thus, all data packets
originating from a mixer will be identified as having the mixer as
their synchronization source.
Translator: An intermediate system that forwards RTP packets with
their synchronization source identifier intact. Examples of
translators include devices that convert encodings without mixing,
replicators from multicast to unicast, and application-level filters
in firewalls.
Section 6.1 of [RFC3550] states:
It is RECOMMENDED that translators and mixers combine individual RTCP
packets from the multiple sources they are forwarding into one
compound packet whenever feasible in order to amortize the packet
overhead (see Section 7 [of [RFC3550]]). An example RTCP compound
packet as might be produced by a mixer is shown in Fig. 1 [of
[RFC3550]]. If the overall length of a compound packet would exceed
the MTU of the network path, it SHOULD be segmented into multiple
shorter compound packets to be transmitted in separate packets of the
underlying protocol. This does not impair the RTCP bandwidth
estimation because each compound packet represents at least one
distinct participant. Note that each of the compound packets MUST
begin with an SR or RR packet.
Section 7.1 of [RFC3550] summarises the purpose of translators and
Hunt Expires May 15, 2008 [Page 7]
Internet-Draft RTCP Reporting by Translators November 2007
mixers as follows:
An RTP translator/mixer connects two or more transport-level
"clouds". Typically, each cloud is defined by a common network and
transport protocol (e.g., IP/UDP) plus a multicast address and
transport level destination port or a pair of unicast addresses and
ports. (Network-level protocol translators, such as IP version 4 to
IP version 6, may be present within a cloud invisibly to RTP.) One
system may serve as a translator or mixer for a number of RTP
sessions, but each is considered a logically separate entity.
The same Section provides examples of translators, and a further
definition:
There may be many varieties of translators and mixers designed for
different purposes and applications. Some examples are to add or
remove encryption, change the encoding of the data or the underlying
protocols, or replicate between a multicast address and one or more
unicast addresses. The distinction between translators and mixers is
that a translator passes through the data streams from different
sources separately, whereas a mixer combines them to form one new
stream.
Translator: Forwards RTP packets with their SSRC identifier intact;
this makes it possible for receivers to identify individual sources
even though packets from all the sources pass through the same
translator and carry the translator's network source address. Some
kinds of translators will pass through the data untouched, but others
MAY change the encoding of the data and thus the RTP data payload
type and timestamp. If multiple data packets are re-encoded into
one, or vice versa, a translator MUST assign new sequence numbers to
the outgoing packets. Losses in the incoming packet stream may
induce corresponding gaps in the outgoing sequence numbers.
Receivers cannot detect the presence of a translator unless they know
by some other means what payload type or transport address was used
by the original source.
Section 7.2 of [RFC3550], titled "RTCP Processing in Translators",
provides the following detailed guidance:
In addition to forwarding data packets, perhaps modified, translators
and mixers MUST also process RTCP packets. In many cases, they will
take apart the compound RTCP packets received from end systems to
aggregate SDES information and to modify the SR or RR packets.
Retransmission of this information may be triggered by the packet
arrival or by the RTCP interval timer of the translator or mixer
itself.
Hunt Expires May 15, 2008 [Page 8]
Internet-Draft RTCP Reporting by Translators November 2007
A translator that does not modify the data packets, for example one
that just replicates between a multicast address and a unicast
address, MAY simply forward RTCP packets unmodified as well. A
translator that transforms the payload in some way MUST make
corresponding transformations in the SR and RR information so that it
still reflects the characteristics of the data and the reception
quality. These translators MUST NOT simply forward RTCP packets. In
general, a translator SHOULD NOT aggregate SR and RR packets from
different sources into one packet since that would reduce the
accuracy of the propagation delay measurements based on the LSR and
DLSR fields.
Section 7.2 of [RFC3550] describes the treatment of each RTCP packet
type by translators as follows:
SR sender information: A translator does not generate its own sender
information, but forwards the SR packets received from one cloud to
the others. The SSRC is left intact but the sender information MUST
be modified if required by the translation. If a translator changes
the data encoding, it MUST change the "sender's byte count" field.
If it also combines several data packets into one output packet, it
MUST change the "sender's packet count" field. If it changes the
timestamp frequency, it MUST change the "RTP timestamp" field in the
SR packet.
SR/RR reception report blocks: A translator forwards reception
reports received from one cloud to the others. Note that these flow
in the direction opposite to the data. The SSRC is left intact. If
a translator combines several data packets into one output packet,
and therefore changes the sequence numbers, it MUST make the inverse
manipulation for the packet loss fields and the "extended last
sequence number" field. This may be complex. In the extreme case,
there may be no meaningful way to translate the reception reports, so
the translator MAY pass on no reception report at all or a synthetic
report based on its own reception. The general rule is to do what
makes sense for a particular translation.
SDES: Translators typically forward without change the SDES
information they receive from one cloud to the others, but MAY, for
example, decide to filter non-CNAME SDES information if bandwidth is
limited. The CNAMEs MUST be forwarded to allow SSRC identifier
collision detection to work. A translator that generates its own RR
packets MUST send SDES CNAME information about itself to the same
clouds that it sends those RR packets.
BYE: Translators forward BYE packets unchanged. A translator that is
about to cease forwarding packets SHOULD send a BYE packet to each
connected cloud containing all the SSRC identifiers that were
Hunt Expires May 15, 2008 [Page 9]
Internet-Draft RTCP Reporting by Translators November 2007
previously being forwarded to that cloud, including the translator's
own SSRC identifier if it sent reports of its own.
APP: Translators forward APP packets unchanged.
Hunt Expires May 15, 2008 [Page 10]
Internet-Draft RTCP Reporting by Translators November 2007
4. Requirements for reporting by translators
[Editor's note: it is intended that requirements are added to this
section during the development of the draft. Community input is
requested either directly as requirements or as scenarios which might
lead to additional requirements. Any additional requirements will be
taken into account in enhancing proposals and descriptions of options
in other sections of the draft.]
Apart from the RTP/RTCP protocol-based requirements listed in
Section 3 above, which must be satisfied when translators process or
report RTCP, there are also motivating requirements which drive the
introduction of these capabilities.
Operators' and users' objectives in implementing and using
performance monitoring may include some or all of the following:
o to determine packet transport performance for their own and peer
networks,
o to detect faulty packet transport,
o to prove faults or poor performance to a single operator's area of
responsibility or to a point-to-point link (demarcation),
o to key monitoring results against individual customer RTP
sessions, for correlation with subsequent user-reported faults,
and
o to use monitoring results either alone, or (preferably) in
conjunction with data describing characteristics and performance
of media terminals and any other networks involved in the
connection, to form estimates of media quality experienced by end
users
Hunt Expires May 15, 2008 [Page 11]
Internet-Draft RTCP Reporting by Translators November 2007
5. Architectural analysis
RTCP reception reports may be produced by any of the types of RTP
systems which are defined in [RFC3550] as capable of receiving RTP
packets, that is, by an RTP end system, by an RTP mixer, or by an RTP
translator. Here, RTCP reports include "basic" RTCP RR packets
[RFC3550], or other types of RTCP reception reports including those
defined in [RFC3611], [RTCPHR], or further reports which may be
defined in future.
[Editor's note - need to add references to relevant work on quality
monitoring schemes for video and possibly other media]
For purposes of sending reports about distribution quality, a mixer
is somewhat similar to an end system, since mixers resynchronize
audio packets before transmission and do not forward either reception
reports from contributing sources towards the destination of the
mixed output RTP stream. However an RTP translator has RTP
interfaces in more than one transport-level "cloud", but does not
resynchronize audio packets in transit between "clouds". Of course,
like translators, mixers also have interfaces in multiple clouds
which participate in the same RTP session and share the session's
SSRC/CSRC space, but the mixer's outgoing RTP packets are labelled
with the mixer's SSRC.
Hence it is expected that the information provided by RTP translators
to other RTP systems will be primarily about transport quality. If
RTP mixers provide information to other RTP systems, the main focus
may be on higher-level metrics of application quality. An example
from the voice domain might be an RTP mixer acting as a conference
bridge, which could provide information about echo-path delay and
attenuation for connection to each of the participants.
[Editor's note: Reporting by mixers is outside the current scope of
this memo, but need to ensure that any statements which *are* made
are not controversial or contradictory]
An RTP translator may:
o forward RTCP reports generated by RTP systems in one cloud towards
RTP systems in another cloud, possibly with modification
o generate its own RTCP reports and send them to one or more of the
clouds to which it is connected.
An RTP translator has several potential sources of information about
transport and application quality in a session. These include
Hunt Expires May 15, 2008 [Page 12]
Internet-Draft RTCP Reporting by Translators November 2007
o RTCP (including XR) reports received from RTP end systems and
mixers
o RTCP (including XR) reports received from other translators
o Measurements made locally on incoming RTP streams at the
translators' interfaces
(Here and in the following, RTCP XR is used to include both the RTCP
XR report blocks defined in [RFC3611] and other XR report blocks
defined elsewhere, such as in [RTCPHR], which use the infrastructure
defined in [RFC3611].)
In general, it is a matter of policy whether each of these types of
information should be reported or forwarded by the translator towards
neighbouring RTP systems involved in the same session. The objective
of this policy may be to ensure that sufficient information is
available to support network and service management at RTP systems,
whilst avoiding excessive RTCP processing.
Where a translator forms a boundary between service providers'
domains, a provider may wish to apply policy to restrict the release
of network performance information towards the provider's peer. This
suggests that policy controlling reporting and forwarding of RTCP
information (including XR) might be configurable differently for each
network interface, and may be chosen differently for each session if
the translator is capable of this level of control. This allows
certain types of RTCP reports for the session to be sent outwards via
one subset of the translator's interfaces involved in the session,
whilst restricting reporting and forwarding outwards via another
subset.
The following behaviours are potentially useful at a translator:
o RTCP [RFC3550] reports received from an upstream RTP end system or
mixer might be forwarded towards the downstream RTP end systems or
mixers involved in the session. This behaviour is recommended by
[RFC3550] to maintain the integrity of the RTCP connection between
the RTP end systems involved in the connection. We call this
behaviour "a" to aid discussion below of the examples of end-to-
end capabilities.
o RTCP XR reports received from an upstream RTP end system or mixer
might be forwarded towards the downstream RTP end systems or
mixers involved in the session. We call this behaviour "b".
o The results of measurements made on an RTP stream received at one
of the translator's network interfaces might be sent out as RTCP
Hunt Expires May 15, 2008 [Page 13]
Internet-Draft RTCP Reporting by Translators November 2007
XR reports towards neighbouring RTP systems, either upstream in
the direction towards the RTP system which originated the RTP
stream (behaviour "c1"), or downstream in the direction towards
the RTP system(s) which will receive the translated RTP stream
(behaviour "c2"), or both upstream and downstream (described as
behaviour "c1+c2").
o RTCP XR reports received from an upstream RTP translator might be
forwarded towards the downstream RTP end systems or mixers
involved in the session. We call this behaviour "d".
Guidance in Section 7.2 of [RFC3550] (see Section 3 above) on RTCP
processing in RTP translators requires translators to modify RTCP to
reflect the translator's processing of RTP media packets. If such
modification is necessary it would apply to packets forwarded under
all the behaviours "a", "b", "c2" and "d". It would not apply to
behaviour "c1" where a report is returned to the cloud which
originated the stream which is the subject of the report. The
details of any necessary modification are determined by the details
of the RTP translation and are outside the scope of this memo.
Material in Section 8 illustrates how policies may be applied to
control these measuring, reporting and forwarding behaviours, and
hence achieve potentially useful end-to-end reporting modes.
Hunt Expires May 15, 2008 [Page 14]
Internet-Draft RTCP Reporting by Translators November 2007
6. Naming considerations
Section 6.1 collects the requirements from [RFC3550] related to
naming. In the context of RTP and RTCP, naming relates to the choice
of values for SSRC and CNAME at an RTP system, and how SSRC and CNAME
are used in RTCP reports to other RTP systems.
Section 6.2 discusses how compliance with these naming requirements
allows the identification of the RTP system which made a set of
measurements, and the RTP system which originated the measured
stream.
Section 6.3 discusses, in very general terms, how names might be used
when reporting results 'upwards' to the signalling or management
planes.
6.1. SSRC and CNAME requirements from RFC3550
Allocation of SSRC by RTP systems is described in detail in Section 8
of [RFC3550]. Similarly the allocation of CNAME is described in
detail in section 6.5.1 of [RFC3550]. This material is not repeated
here.
Section 7.2 of [RFC3550] makes the following statement about SSRC
allocation for translators:
A translator does not require an SSRC identifier of its own, but MAY
choose to allocate one for the purpose of sending reports about what
it has received. These would be sent to all the connected clouds,
each corresponding to the translation of the data stream as sent to
that cloud, since reception reports are normally multicast to all
participants.
Section 6.5.1 of [RFC3550] places a requirement on certain types of
translators to have the capability to translate a CNAME. This is
likely to apply mainly to connections involving RTP systems which use
their IPv4 address as a CNAME.
Restating a naming-related requirement from Section 7.2 of [RFC3550]
already given above:
A translator that generates its own RR packets MUST send SDES CNAME
information about itself to the same clouds that it sends those RR
packets.
Application writers should be aware that private network address
assignments such as the Net-10 assignment proposed in RFC 1918 may
create network addresses that are not globally unique. This would
Hunt Expires May 15, 2008 [Page 15]
Internet-Draft RTCP Reporting by Translators November 2007
lead to non-unique CNAMEs if hosts with private addresses and no
direct IP connectivity to the public Internet have their RTP packets
forwarded to the public Internet through an RTP-level translator.
(See also RFC 1627.) To handle this case, applications MAY provide a
means to configure a unique CNAME, but the burden is on the
translator to translate CNAMEs from private addresses to public
addresses if necessary to keep private addresses from being exposed.
In this memo we assume that RTP systems comply with these normative
requirements of [RFC3550].
6.2. Identification of RTCP reports
An RTP system which sends out a report about packets it has sent
(such as the RTCP SR packet defined in [RFC3550]) includes its own
SSRC as part of the SR. It also provides an RTCP SDES packet
containing (at least) its own SSRC and CNAME, to bind SSRC to CNAME.
For "basic" RTCP, this is required by the normative text in sections
6.1 and 6.4.1 of [RFC3550]. For RTCP XR, it is required by normative
text in section 2 of [RFC3611]. For RTCP HR [RTCPHR] (work in
progress), which uses the infrastructure for extended reports created
by [RFC3611], it is likewise required by normative text in section 2
of [RFC3611].
An RTP system which sends out a report about packets it has received
(such as the RTCP RR packet defined in [RFC3550]) includes the SSRC
of the RTP system which originated the received stream. For "basic"
RTCP this is required by the text in section 6.4.2 of [RFC3550]. For
RTCP XR this is required by normative text in section 4 of [RFC3611]
and for RTCP HR (work in progress) it is required by normative text
in section 3.1 of [RTCPHR].
[RFC3550] recommends that RTP mixers send out multiple SDES packets
to bind contributing source (CSRC) identifiers to these sources'
CNAMEs. However it is not necesary for a receiving RTP end system
(named B) to send out SDES packets to bind a stream-source's SSRC in
a receiver report (RR) to the corresponding CNAME of the RTP system
(named A) which originated the measured stream. It is assumed that
any RTP system which receives the RTCP RR sent by B (containing A's
SSRC but not A's CNAME) will also receive an RTCP packet from the
stream sender A, which will contain an SR and an SDES packet. This
SDES binds A's SSRC to A's CNAME.
Section 7.2 of [RFC3550] (as repeated above) requires that an RTP
translator which sends RRs (and by extension other kinds of reception
report such as RTCP XR or RTCP HR reports) must send SDES information
about itself along with these reception reports. Although the
allocation of an SSRC by an RTP translator is only permissive in
Hunt Expires May 15, 2008 [Page 16]
Internet-Draft RTCP Reporting by Translators November 2007
[RFC3550], it appears that the obligation to send SDES information
also mandates the allocation of an SSRC if the RTP translator wishes
to send any kind of reception report (RTCP RR or any kind of RTCP XR
report).
RTP translators may make measurements related to RTP packet streams
from multiple sources. However translators (by definition) forward
RTP packets with their SSRC unchanged, and also forward the sender's
necessary RTCP SDES information. Hence there is no requirement for
RTP translators to create RTCP SDES packets describing the RTP
systems which are the sources of the streams measured at the RTP
translator. The translator may assume that RTP systems which receive
the translator's reception reports for a stream from any given RTP
sender will also receive forwarded SDES information describing that
sender. Typically these SDES items will be forwarded by the same
translator, as part of its required behaviour.
6.3. Naming in reports to control layers
RTP systems are typically controlled by functions in the signalling
and/or management planes, and it is often useful to send measurement
results either to, or via, these higher-layer entities. Delivery
mechanisms include (but are not restricted to):
o Statistics Descriptors in H.248/MEGACO packages [H.248]
o Entries in SNMP MIBs [RFC4711]
o The proposed mechanism using SIP PUBLISH or NOTIFY messages
[SIPSUMM]
o Ad-hoc mechanisms using Call Detail Records (CDRs)
As discussed above for reporting within the RTP layer, it is usually
necessary to label measurement results with the identity of the RTP
system which made the measurement (the Measuring Point), and with the
identity of the RTP system which originated the measured stream (the
Originating Point). In addition when reports are sent out of the RTP
layer 'upwards' to systems in the signalling or management planes, it
may be useful to label the measurement results with the identity of
the RTP system which made the report upwards (the Reporting Point).
The SSRC identifier may convey no meaning to signalling or management
systems which do not receive RTCP SDES packets. It is likely to be
more useful to label measurement results with the CNAMEs of the RTP
systems involved rather than with their SSRCs. An exception arises
in cases where some binding information may be missing, and higher
layer systems may still be able to deduce useful information about
Hunt Expires May 15, 2008 [Page 17]
Internet-Draft RTCP Reporting by Translators November 2007
the connection if SSRC information is provided. For example, it
might be possible to deduce that several reports provided
measurements of the same RTP stream. It is relatively cheap to
provide SSRC information in addition to CNAME.
Hunt Expires May 15, 2008 [Page 18]
Internet-Draft RTCP Reporting by Translators November 2007
7. Control of reporting by translators
Some recent schemes for monitoring [RFC3611][RTCPHR] have multiple
optional groups of metrics. Some of these have significant costs in
processing or bandwidth, but may be useful in special circumstances,
either for specific types of connections or at specific times (e.g.
for diagnosis). This raises the question of whether, and how, these
capabilities might be activated when needed. This section outlines
possible schemes for control of reporting by translators. As this
discussion touches on capabilities of the signalling and management
planes, which are outside the scope of the memo, these methods are
discussed only in general terms.
The first and simplest scheme is that any optional capabilites are
enabled (or not) by configuration data in every participating RTP
system. This solution may be satisfactory for RTP systems in a small
and/or homogeneous network. However it is unlikely that large
populations of independently controlled terminals and RTP translators
will be configured in compatible ways. The problem is similar to
that of ensuring that a compatible codec is chosen to enable end-to-
end communication. Any modification of the level of reporting, e.g.
for diagnostics, would need to be a coordinated change of
configuration data across multiple systems.
If the RTCP monitoring and reporting capability is to be controlled
dynamically on a per-connection basis, it is assumed that the SDP
Offer/Answer model [RFC4566][RFC3264] will be used to signal that an
RTP end system wishes to receive metrics of a specific kind. This is
in line with some existing practice [RFC3611], and parallels the use
of SDP to select a compatible codec.
We assume that "basic" RTCP SR and RR will always be sent, as they
are not optional in [RFC3550]. Hence SDP will typically be used to
control additional reporting, probably RTCP XR based.
Assuming SDP Offer/Answer is used, there is still the question of the
granularity of control. Some of the options are as follows:
o SDP selects only the top-level protocol (e.g., selects RTCP XR
[RFC3611] or RTCP HR [RTCPHR]). The selection of optional
capabilities within the chosen top-level protocol would still
require configuration at each RTP system, hence would still be a
likely source of incompatibility.
o SDP controls each reporting option individually, both to determine
the top-level protocol and to determine options within the
protocol. This is the design choice made in [RFC3611] where
options within the protocol are defined as XR report block types,
Hunt Expires May 15, 2008 [Page 19]
Internet-Draft RTCP Reporting by Translators November 2007
and these block types (and, in some cases, options within them)
have SDP parameters registered with IANA. This has the advantage
that, if a device implements a specific monitoring standard, it
can provide any subset of that standard on request. However, the
amount of SDP data may become significant.
o SDP indicates the choice of a profile. The profile is registered.
It specifies all the monitoring capabilities and probably also a
set of preferred forwarding policies which achieve the desired
end-to-end monitoring architecture. This has the advantage that a
very small amount of SDP data in signalling (typically a single
integer of SDP "payload") can select from a wide range of
potentially complex behaviour in an RTP system. The disadvantage
is that the RTP systems must implement the chosen profiles, so
there will be a time lag between definition of a profile and its
becoming available in equipment. To mitigate against this, a
number of profiles could be defined at the same time as any new
proposal for monitoring. These might include profiles for both
"normal" and "diagnostic" purposes. The latter might include more
detailed metrics and/or changed policies for forwarding
measurements.
Of course, local policy may override a request for a specific
monitoring behaviour if there are strong reasons to do so, such as a
perceived threat to security or performance.
SDP may be originated at RTP end systems and carried in signalling
such as SIP [RFC3261]. In some cases SIP and its SDP attachment may
be routed via a system (such as an application-layer gateway) which
also contains the RTP translator function. In this case it may need
only simple local communication to provide the RTP system with
information from the signalling plane. Alternatively the RTP
translator may be physically separated from nodes in the signalling
path. In the latter case, the SDP Offer/Answer exchange may be
extended to the RTP translator over a gateway control protocol such
as H.248/MEGACO [H.248].
Hunt Expires May 15, 2008 [Page 20]
Internet-Draft RTCP Reporting by Translators November 2007
8. Example applications
This section defines three potentially useful modes for reporting by
translators and shows how each one may be implemented by consistent
choices of policy at each RTP system which participates in the
connection. These are "uniform" in the sense that the same policy is
applied at each system of a given type.
A further example illustrates the application of the same principles
to a less uniform scenario in which an RTP end system is made
responsible for reporting results which were measured by an RTP
translator.
"End system peering" is a mode in which a translator forwards RTCP
reports originating from an RTP end system towards other RTP end
systems (possibly with some modification consistent with the
translation which it performs [RFC3550]). RTCP reports received from
an end system are forwarded towards the same destination(s) as the
destination(s) of the RTP packets received at the same interface as
that at which the RTCP reports were received. This is the minimum
which a translator must do to maintain the integrity of RTCP
communication between the end systems. In end system peering mode,
the translator does not originate any RTCP reports based on any
measurements which it may make locally.
A minimum "End system peering" behaviour is realised by application,
at each RTP translator, of policy "a" from Section 5 above. This
passes only "basic" RTCP between RTCP end systems. If policy "b" is
also included, RTP end systems' XR reports are also passed between
RTP end systems.
"Local reporting" is a mode in which the translator forwards the end
systems' reports as in "end system peering" mode, to maintain RTCP
communication between end systems. In addition, the translator makes
measurements on the RTP stream arriving at each receive transport
interface, creating associated RTCP reports. These RTCP reports are
sent by the translator both towards the source and destination(s) of
the monitored RTP stream. However, the translator does not forward
RTCP reports generated by other translators. "Local reporting" mode
allows translators to assist in localising transport faults, whilst
keeping RTCP traffic and processing bounded in systems which use
large numbers of translators.
"Local reporting" behaviour is realised by application, at each RTP
translator, of policies "a", "b" and "c1+c2" from Section 5 above.
"Global reporting" is a mode in which the translator forwards the end
systems' reports as in "end system peering" mode, to maintain RTCP
Hunt Expires May 15, 2008 [Page 21]
Internet-Draft RTCP Reporting by Translators November 2007
communication between end systems. In addition the translator makes
measurements on the RTP stream arriving at each receive transport
interface, creating associated RTCP reports. These RTCP reports are
sent by the translator both towards the source and destination(s) of
the RTP stream. Finally, the translator also forwards RTCP reports
generated by other translators, but only towards the same
destination(s) as the destination(s) of the RTP stream received at
the same interface as that at which the RTCP reports were received.
In particular, no RTCP report received at a translator from a system
S is ever sent back towards S. "Global reporting" provides complete
transport metrics to every RTP system involved in a session. In
particular, end systems receive reports of measurements made on RTP
streams at all receive interfaces of every translator. However, the
volume of RTCP traffic and RTCP processing may become excessively
large in networks, or collections of networks, which use large
numbers of translators.
"Global reporting" behaviour is realised by application, at each RTP
translator, of all the policies "a", "b", "c1+c2" and "d" from
Section 5 above.
The following application example illustrates that the policy-based
approach is also capable of meeting specific, less uniform
requirements. This arises in a provider P1's voice network which has
a connection to the network of a second provider P2. P1's network
contains an RTP end system, and an application layer gateway which
provides a connection to a P2's network. P2's network might be a
transit or terminating network. P1's application layer gateway
(ALG1) is connected to P2's application layer gateway (ALG2), via a
point-to-point link or a routed network. ALG1 and ALG2 provide a
symmetric security barrier at the P1-to-P2 network-to-network
interface. We assume that both ALGs are RTP translators with
measurement capabilities and RTCP-based reporting capabilities. We
assume also that both operators are willing to operate their sections
of the connection in "local reporting" mode. This includes sending
results of their respective ALG's measurements across the network-to-
network interface, to assist their peer operator in detecting and
localising transport faults.
Ideally P1 would like to transfer the results of ALG1's measurements,
and the reports which ALG1 receives as local reports from ALG2,
directly into P1's management plane. However in this case ALG1 has
no capability to report its measurement results "upwards" to
signalling or management planes, although P1's RTP end system does
have this capability. P1 defines policy "a", "b" and "c1+c2" for
reports outgoing via ALG1's interface facing ALG2, in order to
achieve the agreed "local reporting" behaviour at the network-to-
network interface. In addition, however, P1 defines policies "a",
Hunt Expires May 15, 2008 [Page 22]
Internet-Draft RTCP Reporting by Translators November 2007
"b", "c1+c2" and "d" for reports outgoing via ALG1's interface to the
inside of P1's network. The effect is that ALG1 relays (towards P1's
RTP end system) all the reports which the RTP translator ALG2
measured and sent to ALG1.
ALG1's behaviour is asymmetric, in that it would not forward out of
its outside interface (towards ALG2) any reports from other RTP
translators inside P1's network. However for the connection
described, this asymmetry is not expressed, because ALG1 receives
into its inside interface only reports from P1's RTP end system.
According to policy "b" in force at ALG1's outside interface, such
reports are forwarded to ALG2.
Hunt Expires May 15, 2008 [Page 23]
Internet-Draft RTCP Reporting by Translators November 2007
9. Combining RTCP packets from multiple sources
As stated above in Section 3, Section 6.1 of [RFC3550] recommends
that translators and mixers combine individual RTCP packets from the
multiple sources they are forwarding into one compound packet
whenever feasible in order to amortize the packet overhead. However,
section 7.2 of [RFC3550] warns that translators should not aggregate
SR and RR packets from different sources because this would degrade
the accuracy of round-trip delay measurements based on the LSR and
DLSR fields. This guidance is aimed at multicast connections
implementing "basic" RTCP, but it may be extended to warn against the
aggregation of any other system's RTCP packets with packets
originated by RTP end systems and containing SR/RR information.
This section suggests a method of aggregation which might reduce
packet overhead in cases where translators forward reports from other
translators. We suggest that RTP end systems might send all their
RTCP information in a single compound RTCP packet which includes both
the "basic" RTCP SR/RR information defined in [RFC3550], including
the LSR and DLSR fields, and any RTCP XR information which the RTP
end system wishes to send. RTP translators which forward RTCP
reports from other translators are assumed to comply with the
intention of Section 7.2 of [RFC3550], and hence will not attempt to
combine their own RTCP reports with reports received from RTP end
systems. This behaviour will help to avoid degradation of round-trip
delay measurements. However RTP translators might concatenate their
own RTCP reports with RTCP reports from peer translators which they
choose to forward. If RTP translators append their own report to the
end of a compound packet which they choose to forward, the order of
concatenated RTCP blocks will be the same as the order in which
network segments are traversed. This might be helpful in determining
the ordering of RTP translators along the connection and hence in
fault localisation for complex, multi-translator connections.
This behaviour is described below with respect to the following
example of a bidirectional unicast connection between RTP end systems
A and Z using three translators J, K, and L:
---- ----- ----- ----- ----
| T|-->|1R 2T|-->|1R 2T|-->|1R 2T|-->|R |
| A | | J | | K | | L | | Z |
| R|<--|1T 2R|<--|1T 2R|<--|1T 2R|<--|T |
---- ----- ----- ----- ----
Hunt Expires May 15, 2008 [Page 24]
Internet-Draft RTCP Reporting by Translators November 2007
Figure 1: Connection with 3 translators.
[Editors notes: Need to consider desirable behaviour for RTP
translators which do not support specific blocks which may arrive
from other RTP systems. If translation is transport-level only,
probably best to forward unchanged apart from appropriate transport-
header modifications, but if translation is application-level (e.g.
codec, packetisation time) then semantics might be wrong so better to
discard?]
In the first example, Figure 2, translators implement policies "a",
"b", "c1+c2" and "d" of Section 5. The result is that the connection
operates in the mode called "Global Reporting" of Section 8 above, in
which all measurements by translators are forwarded by other
translators, ultimately reaching end systems. Without concatenation,
this set of policies results in a large number of separate RTCP
packets.
In Figure 3, concatenation is applied to reduce the number of
separate RTCP packets, here to 3. The packet labelled "RTCP(A.R)" is
the report from the end system, identified because its SSRC is the
same as the SSRC of the RTP flow in the same direction. This is
forwarded without concatenation. The packet labelled RTCP(J.1R,
K.1R, L.1R) contains translator reports of measurements made on the
RTP flow from A to Z, identified because they report the measured
flow having SSRC equal to the SSRC of A. The packet labelled RTCP
(J.2R,K.2R,L.2R) contains translator reports of measurements made on
the RTP flow from Z to A, identified because they report the measured
flow having SSRC equal to the SSRC of Z.
Hunt Expires May 15, 2008 [Page 25]
Internet-Draft RTCP Reporting by Translators November 2007
A.R/A.T------>J.1R/J.2T---->K.1R/K.2T---->L.1R/L.2T------>Z.R/Z.T
| RTP | | | |
|<------------|-------------|-------------|------------->|
| | | | |
| RTCP(A.R) | RTCP(A.R) | RTCP(A.R) | RTCP(A.R) |
|- - - - - - >|- - - - - - >|- - - - - - >|- - - - - - > |
| | RTCP(J.1R) | RTCP(J.1R) | RTCP(J.1R) |
| |- - - - - - >|- - - - - - >|- - - - - - > |
| | RTCP(J.2R) | RTCP(J.2R) | RTCP(J.2R) |
| |- - - - - - >|- - - - - - >|- - - - - - > |
| | | RTCP(K.1R) | RTCP(K.1R) |
| | |- - - - - - >|- - - - - - > |
| | | RTCP(K.2R) | RTCP(K.2R) |
| | |- - - - - - >|- - - - - - > |
| | | | RTCP(L.2R) |
| | | |- - - - - - > |
| | | | RTCP(L.2R) |
| | | |- - - - - - > |
| | | | |
A.T/A.R<------J.1T/J.2R<----K.1T/K.2R<----L.1T/L.2R<------Z.T/Z.R
| RTP | | | |
|<------------|-------------|-------------|------------->|
| | | | |
| RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) |
|< - - - - - -|< - - - - - -|< - - - - - -|< - - - - - - |
| RTCP(L.1R) | RTCP(L.1R) | RTCP(L.1R) | |
|< - - - - - -|< - - - - - -|< - - - - - -| |
| RTCP(L.2R) | RTCP(L.2R) | RTCP(L.2R) | |
|< - - - - - -|< - - - - - -|< - - - - - -| |
| RTCP(K.1R) | RTCP(K.1R) | | |
|< - - - - - -|< - - - - - -| | |
| RTCP(K.2R) | RTCP(K.2R) | | |
|< - - - - - -|< - - - - - -| | |
| RTCP(J.1R) | | | |
|< - - - - - -| | | |
| RTCP(J.2R) | | | |
|< - - - - - -| | | |
| | | | |
Figure 2: Global reporting mode - no packet aggregation
Hunt Expires May 15, 2008 [Page 26]
Internet-Draft RTCP Reporting by Translators November 2007
A.R/A.T------>J.1R/J.2T---->K.1R/K.2T---->L.1R/L.2T------>Z.R/Z.T
| RTP | | | |
|<------------|-------------|-------------|------------->|
| | | | |
| RTCP(A.R) | RTCP(A.R) | RTCP(A.R) | RTCP(A.R) |
|- - - - - - >|- - - - - - >|- - - - - - >|- - - - - - > |
| | | | RTCP(J.1R, |
| | | RTCP(J.1R, | K.1R, |
| | RTCP(J.1R) | K.1R) | L.1R) |
| |- - - - - - >|- - - - - - >|- - - - - - > |
| | | | RTCP(J.2R, |
| | | RTCP(J.2R, | K.2R, |
| | RTCP(J.2R) | K.2R) | L.2R) |
| |- - - - - - >|- - - - - - >|- - - - - - > |
A.T/A.R<------J.1T/J.2R<----K.1T/K.2R<----L.1T/L.2R<------Z.T/Z.R
| RTP | | | |
|<------------|-------------|-------------|------------->|
| | | | |
| RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) |
|< - - - - - -|< - - - - - -|< - - - - - -|< - - - - - - |
| RTCP(L.1R, | | | |
| K.1R, | RTCP(L.1R, | | |
| J.1R) | K.1R) | RTCP(L.1R) | |
|< - - - - - -|< - - - - - -|< - - - - - -| |
| RTCP(L.2R, | | | |
| K.2R, | RTCP(L.2R, | | |
| J.2R) | K.2R) | RTCP(L.2R) | |
|< - - - - - -|< - - - - - -|< - - - - - -| |
| | | | |
Figure 3: Proposed multiplexing scheme of the Global reporting mode
In the second example, Figure 4 translators implement policies "a",
"b", and "c1+c2" of Section 5. The result is that the connection
operates in the mode called "Local Reporting" described in Section 8
above, in which measurements by each translator are sent to the
nearest-neighbour RTP system in each direction but are not forwarded
further. Even without concatenation, this set of policies results in
a maximum of three RTCP packets in each direction on each link (per
RTCP measurement cycle). There is no opportunity for concatenation
in this mode.
Hunt Expires May 15, 2008 [Page 27]
Internet-Draft RTCP Reporting by Translators November 2007
A.R/A.T------>J.1R/J.2T---->K.1R/K.2T---->L.1R/L.2T------>Z.R/Z.T
| RTP | | | |
|<------------|-------------|-------------|------------->|
| | | | |
| RTCP(A.R) | RTCP(A.R) | RTCP(A.R) | RTCP(A.R) |
|- - - - - - >|- - - - - - >|- - - - - - >|- - - - - - > |
| | RTCP(J.1R) | RTCP(K.1R) | RTCP(L.1R) |
| |- - - - - - >|- - - - - - >|- - - - - - > |
| | RTCP(J.2R) | RTCP(K.2R) | RTCP(L.2R) |
| |- - - - - - >|- - - - - - >|- - - - - - > |
| | | | |
| | | | |
A.T/A.R<------J.1T/J.2R<----K.1T/K.2R<----L.1T/L.2R<------Z.T/Z.R
| RTP | | | |
|<------------|-------------|-------------|------------->|
| | | | |
| RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) |
|< - - - - - -|< - - - - - -|< - - - - - -|< - - - - - - |
| RTCP(J.1R) | RTCP(K.1R) | RTCP(L.1R) | |
|< - - - - - -|< - - - - - -|< - - - - - -| |
| RTCP(J.2R) | RTCP(K.2R) | RTCP(L.2R) | |
|< - - - - - -|< - - - - - -|< - - - - - -| |
| | | | |
Figure 4: Local reporting mode
Hunt Expires May 15, 2008 [Page 28]
Internet-Draft RTCP Reporting by Translators November 2007
10. IANA Considerations
None.
Hunt Expires May 15, 2008 [Page 29]
Internet-Draft RTCP Reporting by Translators November 2007
11. Security Considerations
There are known security considerations for the operation of RTP
translators and mixers which have been documented in [TOPO] (work in
progress).
However, this document itself contains no normative text and hence
should not give rise to any new security considerations, to be
confirmed.
Hunt Expires May 15, 2008 [Page 30]
Internet-Draft RTCP Reporting by Translators November 2007
12. References
12.1. Normative References
[H.248] ITU-T, "Recommendation H.248.1, Gateway control protocol:
Version 3", September 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3261] Rosenberg, J., "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3264] Rosenberg, J., "An Offer/Answer Model with the Session
Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003.
[RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP
XR)", RFC 3611, November 2003.
[RFC4566] Handley, M., "SDP: Session Description Protocol",
RFC 4566, July 2006.
[RFC4711] Siddiqui, A., "Real-time Application Quality-of-Service
Monitoring (RAQMON) MIB.", RFC 4711, October 2006.
12.2. Informative References
[RTCPHR] Clark, A., "RTCP HR - High Resolution VoIP Metrics Report
Blocks", ID draft-ietf-avt-rtcphr-01, February 2007.
[SIPSUMM] Pendleton, A., "Session Initiation Protocol Package for
Voice Quality Reporting Event",
ID draft-ietf-sipping-rtcp-summary-02, May 2007.
[TOPO] Westerlund, M., "RTP Topologies",
ID draft-ietf-avt-topologies-07, October 2007.
Hunt Expires May 15, 2008 [Page 31]
Internet-Draft RTCP Reporting by Translators November 2007
Author's Address
Geoff Hunt
BT
Orion 1 PP9
Adastral Park
Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
Phone: +44 1473 608325
Email: geoff.hunt@bt.com
Hunt Expires May 15, 2008 [Page 32]
Internet-Draft RTCP Reporting by Translators November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hunt Expires May 15, 2008 [Page 33]
