draft-ietf-avt-ports-for-ucast-mcast-rtp-00.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-01.txt 
AVT A. Begen AVT A. Begen
Internet-Draft B. VerSteeg Internet-Draft B. VerSteeg
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: August 30, 2010 February 26, 2010 Expires: October 14, 2010 April 12, 2010
Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avt-ports-for-ucast-mcast-rtp-00 draft-ietf-avt-ports-for-ucast-mcast-rtp-01
Abstract Abstract
This document presents port mapping solutions that allow RTP This document presents a port mapping solution that allows RTP
receivers to choose their own RTP and RTCP receive ports for the receivers to choose their own receive ports for an auxiliary unicast
unicast session(s) in RTP applications using both unicast and session in RTP applications using both unicast and multicast
multicast services. services. The solution requires multiplexing RTP and RTCP on a
single port on both endpoints in the unicast session.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 14, 2010.
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 August 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Design Guidelines . . . . . . . . . . . . . . . . . . . . . . 4 3. Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Steps for Establishing a Unicast Session . . . . . . . . . 8
4.1. SDP Description . . . . . . . . . . . . . . . . . . . . . 6 3.2. Implications of NATs . . . . . . . . . . . . . . . . . . . 9
4.2. Server-Generated Cookie Approach . . . . . . . . . . . . . 8 3.3. Message Flows . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Steps . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Keeping the NAT Binding(s) Alive . . . . . . . . . . . . . 11
4.2.2. Implications of NATs . . . . . . . . . . . . . . . . . 9 3.5. SDP Description . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Message Flows . . . . . . . . . . . . . . . . . . . . 10 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Client-Generated Cookie Approach . . . . . . . . . . . . . 12 4.1. PortMappingRequest (PMReq) . . . . . . . . . . . . . . . . 13
4.3.1. Steps . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. PortMappingResponse (PMRes) . . . . . . . . . . . . . . . 14
4.3.2. Implications of NATs . . . . . . . . . . . . . . . . . 13 5. Procedures for Cookie Construction . . . . . . . . . . . . . . 15
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7.1. Registration of FMT Values . . . . . . . . . . . . . . . . 17
8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 14 8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
In (any-source or source-specific) multicast RTP applications, In (any-source or source-specific) multicast RTP applications,
destination ports, i.e., the ports on which the multicast receivers destination ports, i.e., the ports on which the multicast receivers
receive the RTP and RTCP packets, are defined declaratively. In receive the RTP and RTCP packets, are defined declaratively. In
other words, the receivers cannot choose their receive ports and the other words, the receivers cannot choose their receive ports and the
sender(s) use the pre-defined ports. sender(s) use the pre-defined ports.
In unicast RTP applications, the receiving end often needs to choose In unicast RTP applications, the receiving end needs to choose its
its receive ports for RTP and RTCP. It may convey its request to the receive ports for RTP and RTCP since these ports are local resources
sending end through different ways, one of which is the Offer/Answer and only the receiving end can determine which ports are available to
Model [RFC3264] for the Session Description Protocol (SDP) [RFC4566]. use. The receiving may convey its request to the sending end through
However, the Offer/Answer Model requires offer/answer exchange(s) different ways, one of which is the Offer/Answer Model [RFC3264] for
between the endpoints, and the resulting delay may not be acceptable the Session Description Protocol (SDP) [RFC4566]. However, the
in delay-sensitive real-time applications. Offer/Answer Model requires offer/answer exchange(s) between the
endpoints, and the resulting delay may not be desirable in delay-
sensitive real-time applications. Furthermore, the Offer/Answer
Model may be burdensome for the endpoints that are concurrently
running a large number of unicast sessions with other endpoints.
RTP sessions are defined based on the destination addresses In this specification, we consider an RTP application that uses one
[RFC3550]. While the declaration and selection of the ports are well or more unicast and multicast RTP sessions together. While the
defined and work well for multicast and unicast RTP applications, declaration and selection of the ports are well defined and work well
respectively, the usage of the ports introduces complications when a for multicast and unicast RTP applications, respectively, the usage
receiving end mixes unicast and multicast RTP sessions within the of the ports introduces complications when a receiving end mixes
same RTP application. unicast and multicast RTP sessions within the same RTP application.
An example scenario is where the RTP packets are distributed through An example scenario is where the RTP packets are distributed through
source-specific multicast (SSM) and a receiver sends unicast RTCP source-specific multicast (SSM) and a receiver sends unicast RTCP
feedback to a local repair server (also functioning as a feedback feedback to a local repair server (also functioning as a feedback
target) [I-D.ietf-avt-rtcpssm] asking for a retransmission of the target) [RFC5760] asking for a retransmission of the packets it is
packets it is missing, and the local repair server sends the missing, and the local repair server sends the retransmission packets
retransmissions over a unicast RTP session [RFC4588]. over a unicast RTP session [RFC4588].
Another scenario is where a receiver wants to rapidly acquire a new Another scenario is where a receiver wants to rapidly acquire a new
primary multicast RTP session and receives one or more RTP primary multicast RTP session and receives one or more RTP burst
retransmissions over a unicast session before joining the SSM session packets over a unicast session before joining the SSM session
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in
applications where some part of the content is distributed through applications where some part of the content is distributed through
multicast while the receivers get additional and/or auxiliary content multicast while the receivers get additional and/or auxiliary content
through one or more unicast connections, as sketched in Figure 1. through one or more unicast connections, as sketched in Figure 1.
In this document, we discuss this problem and introduce alternative In this document, we discuss this problem and introduce a solution
solutions that we refer to as Port Mapping. These solutions allow that we refer to as Port Mapping. This solution allows receivers to
receivers to choose their desired RTP and RTCP receive ports for choose their desired RTP and RTCP receive ports for every unicast
every unicast session when they are running RTP applications using session when they are running RTP applications using both unicast and
both unicast and multicast services. multicast services.
----------- -----------
| Unicast |................ | Unicast |................
| Source |............. : | Source |............. :
| (Server) | : : | (Server) | : :
----------- : : ----------- : :
v v v v
----------- ---------- ----------- ----------- ---------- -----------
| Multicast |------->| Router |---------->|Client RTP | | Multicast |------->| Router |---------->|Client RTP |
| Source | | |..........>|Application| | Source | | |..........>|Application|
skipping to change at page 4, line 37 skipping to change at page 6, line 5
In the remainder of this document, we refer to the RTP endpoints that In the remainder of this document, we refer to the RTP endpoints that
serve other RTP endpoints over a unicast session as the Servers. The serve other RTP endpoints over a unicast session as the Servers. The
receiving RTP endpoints are referred to as Clients. receiving RTP endpoints are referred to as Clients.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Design Guidelines 3. Port Mapping
We have the following design guidelines in developing a port mapping
solution:
o Design a scalable and distributable system. This drives the
design towards a system in which all of the actions associated
with a given set of flows at a given instant in time are distinct
from actions on other flows. This allows the system to be
dynamically segmented as dictated by dynamic conditions in the
network.
o Use atomic, client-driven transactions in order to limit the
amount of state information maintained by the server.
o Use idempotent transactions in order to limit the impact to the
overall system when messages are lost. The state of the system
thus only depends on the last successfully received message.
o Do not create dependency among messages carried in different
packets if possible. In other words, if an information is
logically coupled to other information, send all of the data in a
single transaction to the extent that this is practical.
o Do not introduce new vectors for attacks.
o Do not have any IPv4/IPv6 dependencies. To the extent that
addressing information is required to persist across transactions,
handle the addresses in a manner that allows the server to give
opaque address information (called Cookie) to the client. The
client then presents the opaque addressing information back to the
server in subsequent transactions. This allows the system to
maintain connectivity information without unduly burdening the
server(s) with state information.
The cookie is generated by the server (Section 4.2) or the client
(Section 4.3), and is only understood by the server or the client,
respectively. To other systems, the cookie is opaque data. Thus,
the endpoint generating the cookie may use any method of its
choice to make the cookie data opaque.
o Be NAT-tolerant [RFC5389] [RFC4787]. Considerations for IPv6/IPv4
translation are out of scope of this specification.
4. Port Mapping
We present the details of the proposed solutions in the context of an We present the details of the port mapping solution in the context of
example application. an illustrative example.
Consider an SSM distribution network where a distribution source Consider an SSM distribution network where a distribution source
multicasts RTP packets to a large number of clients, and one or more multicasts RTP packets to a large number of clients, and one or more
retransmission servers function as feedback targets to collect retransmission servers function as feedback targets to collect
unicast RTCP feedback from these clients [I-D.ietf-avt-rtcpssm]. unicast RTCP feedback from these clients [RFC5760]. The
When a client detects a missing packet in the primary multicast retransmission servers also join the primary multicast session to
session, it requests a retransmission from one of the retransmission receive the multicast packets and cache them for a certain time
servers. The client may or may not be behind a NAT device. We first period. When a client detects missing packets in the primary
consider the simpler scenario where there are no NAT devices between multicast session, it requests a retransmission from one of the
the server and client. We then discuss the implications of NAT retransmission servers by using an RTCP NACK message [RFC4585]. The
devices. retransmission server pulls the requested packet(s) out of the cache
and retransmits them to the requesting client.
The pertaining RTP and RTCP flows are sketched in Figure 2. The pertaining RTP and RTCP flows are sketched in Figure 2. Between
the client and server, there may be one or more NAT devices
[RFC4787].
-------------- --- ---------- -------------- --- ----------
| |-------------------------------| |-->|P1 | | |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | | | | | | | |
| Distribution | ---------------- | | | | | Distribution | ---------------- | | | |
| Source | | | | | | | | Source | | | | | | |
| |---->|P1 | | | | | | |---->|P1 | | | | |
| |.-.->|P2 | | | | | | |.-.->|P2 | | | | |
| | | | | | | | | | | | | | | |
-------------- | P2|<.=.=.=.| |=.=|*c1 | -------------- | P3|<.=.=.=.| |=.=|*c1 |
| P2|<~~~~~~~| |~~~|*c1 | | P3|<~~~~~~~| |~~~|*c1 |
| | | N | | | | | | N | | |
| Retransmission | | A | | Client | | Retransmission | | A | | Client |
| Server | | T | | | | Server | | T | | |
| | | | | | | | | | | |
| P3|........| |..>|*c2 | | P4|........| |..>|*c2 |
| P4|<.=.=.=.| |=.>|*c3 | | P4|<.=.=.=.| |=.>|*c2 |
| | | | | | | | | | | |
---------------- --- ---------- ---------------- --- ----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 2: Example scenario showing an SSM distribution with support Figure 2: Example scenario showing an SSM distribution with support
for retransmissions from a local server for retransmissions from a server
4.1. SDP Description
The SDP describing the scenario given in Figure 2 can be written as:
v=0 In this figure, we have the following multicast and unicast ports:
o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter: incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=mid:1
m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=rtpmap:99 rtx/90000
a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000
a=mid:2
Figure 3: SDP describing an SSM distribution with support for o Ports P1 and P2 denote the destination RTP and RTCP ports in the
retransmissions from a local server primary multicast session, respectively. The clients listen to
these ports to receive the multicast RTP and RTCP packets. Ports
P1 and P2 are defined declaratively.
In this SDP, the source stream is multicast from a distribution o Port P3 denotes the RTCP port on the feedback target running on
source (with a source IP address of 198.51.100.1) to the multicast the retransmission server to collect the RTCP feedback messages,
destination address of 233.252.0.2 and port 41000. A retransmission and RTP receiver and extended reports from the clients in the
server including feedback target functionality (with an address of primary multicast session. Port P3 is defined declaratively.
192.0.2.1 and port of 41001) is specified with the 'rtcp' attribute.
The RTCP port for the unicast session (41003) is also specified with
the 'rtcp' attribute.
Based on this SDP, we define the following parameters: o Port P4 denotes the port on the retransmission server used for the
unicast session. The server multiplexes RTP and RTCP traffic on
this single port [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast
session. Port P4 is defined declaratively.
o DS=198.51.100.1 - Address of the distribution source o Ports *c1 and *c2 are chosen by the client. *c1 denotes the port
on the client used to send the unicast RTCP feedback in the
primary multicast session. *c2 denotes the port on the client used
in the unicast session. The client muxes RTP and RTCP traffic on
this single port [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast
session. Ports c1 and c2 do not have to be different ports.
o G=233.252.0.2 - Destination address where the primary multicast Once the unicast session is established, the server needs to remember
stream is sent to the public IP address and public port of the client as part of the
session state information. The public ports of the client are
denoted by c1' and c2'.
o P1=41000 - Destination RTP port where the primary multicast stream In addition to the ports, we use the following notation:
is sent to
o P2=41001 - Destination RTCP port on the retransmission server and o DS: IP address of the distribution source
clients for the primary multicast session
o S=192.0.2.1 - Address of the retransmission server o G: Destination multicast address
o P3=41002 - Source RTP port on the retransmission server for the
unicast session
o P4=41003 - RTCP port on the retransmission server for the unicast o S: IP address of the retransmission server
session
We denote the client address by C. *c1 denotes the port on the client o C: IP address of the client
used to send the unicast feedback in the primary multicast session.
*c2 and *c3 denote the RTP and RTCP ports on the client used in the
unicast session, respectively. The '*' before the port numbers means
that these port numbers are chosen by the client, and not assigned/
imposed by another entity. Note that if the client implements RTP/
RTCP port muxing [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast
session, c2 will equal c3.
During the lifetime of a unicast session, the server needs to o C': Public IP address of the client (as seen by the server)
remember the public IP address and public RTP and RTCP ports of the
client as a part of the session state information.
4.2. Server-Generated Cookie Approach We assume that the information declaratively defined is available as
part of the session description information and is provided to the
clients. The Session Description Protocol (SDP) [RFC4566] and other
session description methods can be used for this purpose.
4.2.1. Steps 3.1. Steps for Establishing a Unicast Session
This approach follows the steps outlined below: The steps to establish a unicast session are provided below:
1. The client ascertains server address and port number(s) from the 1. The client ascertains server address (S) and port numbers (P3 and
SDP description (S, P3 and P4). P4) from the session description.
2. The client determines its port numbers (*c2 and *c3). 2. The client determines its receive port numbers (*c1 and *c2).
3. The client sends a message to the server via a new RTCP message, 3. The client sends a message to the server via a new RTCP message,
called PortMappingRequest. Separate messages are sourced from called PortMappingRequest. This message MUST be sent from port
ports c2 and c3 on the client. Note that normally the message c2 to port P4. The server learns client's public IP address (C')
sent from port c2 should be addressed to port P3 on the server, and its public RTP/RTCP port (c2') from the received message.
and the message sent from port c3 should be addressed to port P4
on the server. However, since the former RTCP message is sent to
an RTP port (P3), the server is required to implement RTP/RTCP
port muxing on this port [I-D.ietf-avt-rtp-and-rtcp-mux]. Thus,
the server MUST support RTP/RTCP port muxing, and both
PortMappingRequest messages sourced from ports c2 and c3 MUST be
sent to port P3 on the server.
4. The server derives client address (C) and its RTP and RTCP ports
(c2 and c3) from the received messages.
5. For each PortMappingRequest message, the server generates an 4. The server generates an opaque encapsulation (called Cookie) that
opaque encapsulation (called Cookie) that conveys client's conveys client's addressing information using a reversible
addressing information (IP address and port) using a reversible
transform only known to the server. transform only known to the server.
6. The server sends each cookie back to the client using a new RTCP 5. The server sends the Cookie back to the client using a new RTCP
message, called PortMappingResponse. Assuming that the client message, called PortMappingResponse. This message MUST be sent
does not support port muxing, two separate PortMappingResponse from port P4 to port c2'.
messages MUST be sent to port c3 on the client and the server
MUST indicate in each PortMappingResponse message whether it is
for an RTP or for an RTCP port using an appropriate field.
For the server to be able to send the PortMappingResponse for
port c2 to port c3, the client needs to include the cookie for
port c3 when requesting the cookie for port c2. This introduces
delay and dependency, which may be a drawback in certain
applications (See Figure 4).
7. If the client supports port muxing, then there is no need to
select a port c3 and the client needs one cookie only.
8. The client includes the cookie(s) when necessary in the 6. The client includes the Cookie when necessary in the subsequent
subsequent messages sent to the server. messages sent to the server.
9. Normal flows ensue, with the server using the addressing 7. Normal flows ensue, with the server using the addressing
encapsulated in the opaque cookie(s). encapsulated in the opaque Cookie. The client is responsible for
keeping the NAT binding alive for the duration of the unicast
session.
4.2.2. Implications of NATs 3.2. Implications of NATs
If there are no NAT devices between the server and client, the client There may be one or more NAT devices between the client and server.
MUST acquire a cookie for each distinct 2-tuple of (S, c2) and (S, Without an external mechanism such as STUN [RFC5389], the client
c3). In other words, as long as the client uses the same local ports cannot determine whether there are any NATs between itself and the
and the same server, it can use the same cookies when communicating server. Such NAT devices would block all incoming traffic unless the
with any feedback target running on this server. The advantage here client sent traffic of the same transport protocol to the server
is that the client can acquire the necessary cookies at the very first. Thus, the client has always to assume that there is at least
beginning for every port pair (if it is not port-muxing) it is one NAT device and send periodic packets to keep the NAT binding
planning to use, and thus, can avoid the delays incurred to acquire alive [I-D.ietf-avt-app-rtp-keepalive]. Since the client multiplexes
the cookies later when it wants to use a new unicast service. RTP and RTCP on a single port, it has to keep a single NAT binding
alive for each unicast session. See Section 3.4 for further details.
If there is a NAT device between the server and client, the client If the NAT device fails for some reason and then restarts, the public
may still acquire the cookies at the beginning, provided that it is IP address and/or port assigned to a particular client may change.
behind a NAT that assigns the same public IP address and port for the This will invalidate the previously acquired cookies and may result
messages sent from the same internal IP address and port even when in a failure in the unicast session. Upon detecting the failure, the
the client is talking to different destinations ("endpoint- client must acquire new cookies. Applications using this method must
independent mapping" [RFC4787]). However, if the NAT has endpoint- be aware of the potential temporary interruptions.
dependent mapping [RFC4787], the client MUST fall back to acquiring a
cookie for each distinct 3-tuple of (S, P3, c2) and (S, P3, c3). In
practice, however, it is a difficult task to determine the type of a
NAT device [I-D.ietf-behave-nat-behavior-discovery].
When the client is behind a NAT, it needs to send periodic packets to The NAT device may have endpoint-independent mappings [RFC4787],
keep the NAT bindings alive [RFC4787]. If the NAT device fails for meaning that it assigns the same public IP address and port for the
some reason and then restarts, the public IP address and ports packets sent from the same internal IP address and port, even when
assigned to a client may change. This will invalidate the previously the client is talking to different destinations. Oppositely, the NAT
acquired cookies. Upon detecting the failure, the client must device may have endpoint-dependent mappings in which case the public
acquire new cookies. IP address and port of the outgoing packets may differ when they are
sent to different destinations. In practice, however, it is a
difficult task to determine the type of a NAT device
[I-D.ietf-behave-nat-behavior-discovery].
4.2.3. Message Flows 3.3. Message Flows
Figure 4 shows the message flows, where each message is appended with Figure 3 shows the message flows, where each message is appended with
the (Source Address, Source Port, Destination Address, Destination the (Source Address, Source Port, Destination Address, Destination
Port) information. In this section, we assume that the client does Port) information.
not mux the RTP and RTCP ports.
-------------- ---------------- -------- ------------ ---------------- ------
| Distribution | | Retransmission | | | |Distribution| | Retransmission | | |
| Source | | Server | | Client | | Source | | Server | |Client|
| (DS) | | (S) | | (C) | | (DS) | | (S) | | (C) |
-------------- ---------------- -------- ------------ ---------------- ------
| | | | | - |
| | | | | | | |
|- (DS, *, G, P1) ->|--------- RTP Multicast --------->| (DS,*,G,P1)|--->|-------- RTP Multicast --------->| |-->|
|- (DS, *, G, P2) .>|.-.-.-.-. RTCP Multicast -.-.-.-.>| (DS,*,G,P2)|.-.>|.-.-.-.- RTCP Multicast .-.-.-.->| |-->|
| | | | | | |
| | | | | | |
| (C, c1, S, P2) |<.=.=. RTCP Receiver Reports =.=.=| |<=.=. RTCP Receiver Reports =.=.=| |<..|(C,c1,S,P3)
| | (for the multicast session) | | (for the multicast session) | | |
: : : : | | :
| (C, c3, S, P3) |<~~~~ PortMappingRequest(c3) ~~~~~| : | | :
| | | : | | :
| (S, P3, C, c3) |~~~~~~~ PortMappingResponse ~~~~~>| : | | :
| | Cookie(c3) | |<~~~~~ PortMappingRequest ~~~~~~~| |<~~|(C,c2,S,P4)
| | | | |N| |
| (C, c2, S, P3) |<~~~~ PortMappingRequest(c2) ~~~~~| (S,P4,C',c2')|~~~~~~ PortMappingResponse ~~~~~>|A|~~>|
| | with Cookie(c3) | | (Cookie) |T| |
| | | | | | |
| (S, P3, C, c3) |~~~~~~~ PortMappingResponse ~~~~~>| |<~~~~ RTCP NACK with Cookie ~~~~~| |<~~|(C,c1,S,P3)
| | Cookie(c2) | | | | |
| | | |*********************************|*|***|
| (C, c1, S, P2) |<~ RTCP NACK with Cookie(c2,c3) ~~| |* UNICAST SESSION ESTABLISHED | | *|
| | | |*********************************|*|***|
| |**********************************| | | | |
| |* UNICAST SESSION ESTABLISHED *| (S,P4,C',c2')|...... RTP Retransmissions .....>| |..>|
| |**********************************| | | | |
| | | | | | |
| (S, P3, C, c2) |....... RTP Retransmissions .....>| |<=.=. RTCP Receiver Reports =.=.=| |<..|(C,c2,S,P4)
| | | | (for the unicast session) | | |
| | | | | | |
| (C, c3, S, P3) |<.=.=. RTCP Receiver Reports =.=.=| (S,P4,C',c2')|=.=.=. RTCP Sender Reports =.=.=>| |..>|
| | (for the unicast session) | | (for the unicast session) | | |
| | | | | | |
| (S, P3, C, c3) |.=.=.=. RTCP Sender Reports =.=.=>| -
| | (for the unicast session) |
| | |
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 4: Message flows for server-side cookie approach
In the example above, the compound RTCP packet carrying the NACK Figure 3: Message flows for establishing a unicast session
message also carries the Cookie(c2) and Cookie(c3) since the server
must know which ports the client is expecting to receive the RTP
retransmission packet(s) and RTCP sender reports on. If an RTCP
message from the client will not trigger any transmission from the
server (e.g., RTCP receiver and extended reports), it does not have
to include any cookies.
4.3. Client-Generated Cookie Approach In the example above, the compound RTCP packet carrying the NACK
message also carries the Cookie since the server must know which port
the client is expecting to receive the RTP retransmission packet(s)
and RTCP sender reports on. If an RTCP message from the client will
not trigger any transmission from the server (e.g., RTCP receiver and
extended reports), it does not have to include the Cookie.
4.3.1. Steps 3.4. Keeping the NAT Binding(s) Alive
This approach follows the steps outlined below: Editor's note: We need to determine the best option to keep the NAT
bindings alive [I-D.ietf-avt-app-rtp-keepalive].
1. The client ascertains server address and port number from the SDP Editor's note: Are RTCP receiver/extended reports enough to keep the
description (S and P3). binding alive?
2. The client determines its port numbers (*c2 and *c3). TBD.
3. The client generates a random cookie. 3.5. SDP Description
4. The client sends separate RTCP packets from its ports c2 and c3 The SDP describing the scenario given in Figure 2 can be written as:
to the server port P3 to setup the NAT. Each RTCP packet
indicates through a bit/field whether it source port will be used
for RTP or RTCP traffic by the client. The client repeats this
step as deemed necessary to keep the NAT bindings alive
[RFC4787].
5. The client sends unicast feedback from its port c1 to server port v=0
P2 where the RTCP feedback message also carries the cookie from o=ali 1122334455 1122334466 IN IP4 nack.example.com
Step 3. s=Local Retransmissions
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:98 MP2T/90000
a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=mid:1
m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux
a=fmtp:99 apt=98; rtx-time=5000
a=mid:2
6. The server correlates these three RTCP packets based on the Figure 4: SDP describing an SSM distribution with support for
cookie value, and remembers the public IP address(es) and port(s) retransmissions from a local server
of the client when sending packets back to the client.
If the client supports RTP/RTCP port muxing, the server needs to In this SDP, the source stream is multicast from a distribution
remember only one public IP address and port. The state source (with a source IP address of 198.51.100.1) to the multicast
information the server has to keep is reduced but not totally destination address of 233.252.0.2 (G) and port 41000 (P1). The
eliminated. associated RTCP packets are multicast in the same group to port 42000
(P2). A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 (S) and port of 43000
(P3) is specified with the 'rtcp' attribute. The server uses port
51000 (P4) for the unicast sessions.
If the server is about to send an RTP and/or RTCP packet to the 4. Message Formats
client but does not know the port mappings since it has not received
one or both of the RTCP packets sent in Step 4, it cannot start
transmission. Eventually, the client times out and resends the RTCP
packets carrying the cookie from its ports c2 and c3. Note that if
the client supports port muxing, the failure probability is
substantially reduced. Once the server figures out the port
mappings, it keeps that state information until the unicast session
is ended.
After the server has established a port mapping for the 2-tuple of The common packet format for the RTCP feedback messages is defined in
cookie and public IP address of the client, it discards RTCP packets Section 6.1 of [RFC4585]. A feedback message has a fixed-length
carrying the same cookie coming from the same public IP address but field for version, padding, feedback message type (FMT), payload type
from a different public port. The reason is that such packets are (PT), length, SSRC of packet sender, SSRC of media sender as well as
likely to be sent by an attacker since there is no good reason for a a variable-length field for feedback control information (FCI).
client to change its port during a short-lived session. Thus, if two
different clients sharing the same public IP address accidentally
generate the same random cookie and send it to the same port on the
server, only the first port mapping will be valid. If neither client
is port-muxing, the (total 4) RTCP packets can cross each other
resulting in a failure. To minimize the chances for a failure in the
client-generated cookie approach, the client should support port
muxing and the generated cookies should be truely random [RFC4086].
4.3.2. Implications of NATs In the PortMappingRequest and PortMappingResponse messages, the PT
field is set to RTPFB (205), and the respective FMT fields are set to
PMReq (7) and PMRes (8). Depending on the specific scenario, it may
be desirable to send these messages in a reduced-size RTCP packet
[RFC5506]. However, unless support for [RFC5506] has been signaled,
compound RTCP packets MUST be used by following [RFC3550] rules.
If there are no NAT devices between the server and client, there is Editor's note: Should the server always respond to the PMReq message
no risk of a cookie collision. Thus, it is safe to use this as soon as possible?
approach.
When there is a NAT device between the server and client, there is a Following the rules specified in [RFC3550], all integer fields in the
risk of a cookie collision, although it is unlikely if the random messages defined below are carried in network-byte order, that is,
cookies are generated properly [RFC4086]. most significant byte (octet) first, also known as big-endian.
Unless otherwise noted, numeric constants are in decimal (base 10).
Any Reserved field SHALL be set to zero and ignored.
5. Message Formats 4.1. PortMappingRequest (PMReq)
The PortMappingRequest message has the following format: Editor's note: How do we set the media source SSRC field in the
following message? Is it application specific (e.g.,
retransmissions, RAMS, etc.)?
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length | |V=2|P| FMT=7 | PT=205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source | | SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FCI field syntax for the PortMappingRequest message Figure 5: Syntax for the PortMappingRequest (PMReq) message
The PortMappingResponse message has the following format: Editor's note: What else do we need to transmit in the PMReq
message?
4.2. PortMappingResponse (PMRes)
Editor's note: How do we set the packet sender SSRC and media source
SSRC fields in the following message? Are they application specific
(e.g., retransmissions, RAMS, etc.)?
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length | |V=2|P| FMT=8 | PT=205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source | | SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie : : Cookie :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the PortMappingResponse message Figure 6: Syntax for the PortMappingResponse (PMRes) message
Editor's note: We will finalize the message formats in a later Editor's note: What else do we need to transmit in the PMRes
version. message?
5. Procedures for Cookie Construction
Editor's notes:
The Cookie may contain
o A 32-bit value randomly generated by the client [RFC4086]
o Client's IP address and port (Note that the PMReq and NACK
messages are sent from different client ports (and maybe from
different public IP addresses as well), thus the server cannot use
this information to check whether a cookie is used by the true
owner of that cookie)
o Client's CNAME
o A timestamp to protect against replay attacks (Should the server
tell the client about the expiration date so that the client may
request a new cookie before the current one expires?)
o HMAC [RFC2104] of the above information (where only the server
knows the HMAC secret)
Details are TBC.
6. Security Considerations 6. Security Considerations
TBC. Editor's notes:
o Cookie expiration via timestamping. This could be important for
clients behind the same NAT (The clients may still generate the
same random number)
o Stealing cookies. Can CNAME be used to avoid this for the clients
behind the same NAT?
o Modifying cookies. Can somebody manipulate the cookies to
redirect the traffic?
7. IANA Considerations 7. IANA Considerations
TBC. The following contact information shall be used for all registrations
in this document:
Ali Begen
abegen@cisco.com
170 West Tasman Drive
San Jose, CA 95134 USA
Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC.
7.1. Registration of FMT Values
Within the RTPFB range, the following format (FMT) values are
registered:
Name: PMReq
Long name: Port Mapping Request
Value: 7
Reference: [RFCXXXX]
Name: PMRes
Long name: Port Mapping Response
Value: 8
Reference: [RFCXXXX]
8. Contributors and Acknowledgments 8. Contributors and Acknowledgments
TBC. Many individuals in the AVT and MMUSIC WGs have contributed to this
work, reviewed earlier versions of this specification and provided
feedback. The authors thank each of them.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[I-D.ietf-avt-rtcpssm] [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Ott, J. and J. Chesterfield, "RTCP Extensions for Single- Protocol (RTCP) Extensions for Single-Source Multicast
Source Multicast Sessions with Unicast Feedback", Sessions with Unicast Feedback", RFC 5760, February 2010.
draft-ietf-avt-rtcpssm-19 (work in progress),
November 2009.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007. August 2007.
[I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for
maintaining alive the Network Address Translator (NAT)
mappings associated to RTP flows.",
draft-ietf-avt-app-rtp-keepalive-07 (work in progress),
December 2009.
9.2. Informative References 9.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[I-D.ietf-avt-rapid-acquisition-for-rtp] [I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions", Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-07 (work in draft-ietf-avt-rapid-acquisition-for-rtp-08 (work in
progress), February 2010. progress), March 2010.
[I-D.ietf-behave-nat-behavior-discovery] [I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-08 Using STUN", draft-ietf-behave-nat-behavior-discovery-08
(work in progress), September 2009. (work in progress), September 2009.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: abegen@cisco.com Email: abegen@cisco.com
 End of changes. 86 change blocks. 
380 lines changed or deleted 383 lines changed or added

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