AVT                                                             A. Begen
Internet-Draft                                               B. VerSteeg
Intended status:  Standards Track                                  Cisco
Expires:  August 30,  October 14, 2010                              February 26,                                April 12, 2010

        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

   This document presents a port mapping solutions solution that allow allows RTP
   receivers to choose their own RTP and RTCP receive ports for the an auxiliary unicast session(s)
   session in RTP applications using both unicast and multicast
   services.  The solution requires multiplexing RTP and RTCP on a
   single port on both endpoints in the unicast session.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   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
   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 August 30, October 14, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Design Guidelines  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  SDP Description  .  6
     3.1.  Steps for Establishing a Unicast Session . . . . . . . . .  8
     3.2.  Implications of NATs . . . . . . . . . . .  6
     4.2.  Server-Generated Cookie Approach . . . . . . . .  9
     3.3.  Message Flows  . . . . .  8
       4.2.1.  Steps . . . . . . . . . . . . . . . . .  9
     3.4.  Keeping the NAT Binding(s) Alive . . . . . . .  8
       4.2.2.  Implications of NATs . . . . . . 11
     3.5.  SDP Description  . . . . . . . . . . .  9
       4.2.3.  Message Flows . . . . . . . . . . 11
   4.  Message Formats  . . . . . . . . . . 10
     4.3.  Client-Generated Cookie Approach . . . . . . . . . . . . . 12
       4.3.1.  Steps 13
     4.1.  PortMappingRequest (PMReq) . . . . . . . . . . . . . . . . 13
     4.2.  PortMappingResponse (PMRes)  . . . . . . . . 12
       4.3.2.  Implications of NATs . . . . . . . 14
   5.  Procedures for Cookie Construction . . . . . . . . . . 13
   5.  Message Formats . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  Security 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . 17
     7.1.  Registration of FMT Values . . . . . . . . . . . . . . . . 14 17
   8.  Contributors and Acknowledgments . . . . . . . . . . . . . . . 14 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14 19
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 21

1.  Introduction

   In (any-source or source-specific) multicast RTP applications,
   destination ports, i.e., the ports on which the multicast receivers
   receive the RTP and RTCP packets, are defined declaratively.  In
   other words, the receivers cannot choose their receive ports and the
   sender(s) use the pre-defined ports.

   In unicast RTP applications, the receiving end often needs to choose its
   receive ports for RTP and RTCP.  It RTCP since these ports are local resources
   and only the receiving end can determine which ports are available to
   use.  The receiving may convey its request to the sending end through
   different ways, one of which is the Offer/Answer Model [RFC3264] for
   the Session Description Protocol (SDP) [RFC4566].  However, the
   Offer/Answer Model requires offer/answer exchange(s) between the
   endpoints, and the resulting delay may not be acceptable desirable in delay-sensitive 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.

   In this specification, we consider an RTP application that uses one
   or more unicast and multicast RTP sessions are defined based on the destination addresses
   [RFC3550]. together.  While the
   declaration and selection of the ports are well defined and work well
   for multicast and unicast RTP applications, respectively, the usage
   of the ports introduces complications when a receiving end mixes
   unicast and multicast RTP sessions within the same RTP application.

   An example scenario is where the RTP packets are distributed through
   source-specific multicast (SSM) and a receiver sends unicast RTCP
   feedback to a local repair server (also functioning as a feedback
   target) [I-D.ietf-avt-rtcpssm] [RFC5760] asking for a retransmission of the packets it is
   missing, and the local repair server sends the
   retransmissions retransmission packets
   over a unicast RTP session [RFC4588].

   Another scenario is where a receiver wants to rapidly acquire a new
   primary multicast RTP session and receives one or more RTP
   retransmissions burst
   packets over a unicast session before joining the SSM session
   [I-D.ietf-avt-rapid-acquisition-for-rtp].  Similar scenarios exist in
   applications where some part of the content is distributed through
   multicast while the receivers get additional and/or auxiliary content
   through one or more unicast connections, as sketched in Figure 1.

   In this document, we discuss this problem and introduce alternative
   solutions a solution
   that we refer to as Port Mapping.  These solutions allow  This solution allows receivers to
   choose their desired RTP and RTCP receive ports for every unicast
   session when they are running RTP applications using both unicast and
   multicast services.

          -----------
         |  Unicast  |................
         |  Source   |.............  :
         | (Server)  |            :  :
          -----------             :  :
                                  v  v
          -----------          ----------             -----------
         | Multicast |------->|  Router  |---------->|Client RTP |
         |  Source   |        |          |..........>|Application|
          -----------          ----------             -----------
                                   | :
                                   | :                -----------
                                   | :..............>|Client RTP |
                                   +---------------->|Application|
                                                      -----------

         -------> Multicast RTP Flow
         .......> Unicast RTP Flow

     Figure 1: RTP applications simultaneously using both unicast and
                            multicast services

   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
   receiving RTP endpoints are referred to as Clients.

2.  Requirements Notation

   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].

3.  Design Guidelines  Port Mapping

   We have present the details of 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 solution in the context of
   an
   example application. illustrative example.

   Consider an SSM distribution network where a distribution source
   multicasts RTP packets to a large number of clients, and one or more
   retransmission servers function as feedback targets to collect
   unicast RTCP feedback from these clients [I-D.ietf-avt-rtcpssm]. [RFC5760].  The
   retransmission servers also join the primary multicast session to
   receive the multicast packets and cache them for a certain time
   period.  When a client detects a missing packet packets in the primary
   multicast session, it requests a retransmission from one of the
   retransmission
   servers. servers by using an RTCP NACK message [RFC4585].  The client may or may not be behind a NAT device.  We first
   consider the simpler scenario where there are no NAT devices between
   the
   retransmission server and client.  We then discuss pulls the implications requested packet(s) out of NAT
   devices.

   The pertaining RTP the cache
   and retransmits them to the requesting client.

   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        |
    |              |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-|   |.->|P2        |
    |              |                               |   |   |          |
    | Distribution |      ----------------         |   |   |          |
    |    Source    |     |                |        |   |   |          |
    |              |---->|P1              |        |   |   |          |
    |              |.-.->|P2              |        |   |   |          |
    |              |     |                |        |   |   |          |
     --------------      |              P2|<.=.=.=.|              P3|<.=.=.=.|   |=.=|*c1       |
                         |              P2|<~~~~~~~|              P3|<~~~~~~~|   |~~~|*c1       |
                         |                |        | N |   |          |
                         | Retransmission |        | A |   |  Client  |
                         |     Server     |        | T |   |          |
                         |                |        |   |   |          |
                         |              P3|........|              P4|........|   |..>|*c2       |
                         |              P4|<.=.=.=.|   |=.>|*c3   |=.>|*c2       |
                         |                |        |   |   |          |
                          ----------------          ---     ----------

    -------> Multicast RTP Flow
    .-.-.-.> Multicast RTCP Flow
    .=.=.=.> Unicast RTCP Reports
    ~~~~~~~> Unicast RTCP Feedback Messages
    .......> Unicast RTP Flow

    Figure 2: Example scenario showing an SSM distribution with support
                     for retransmissions from a local server

4.1.  SDP Description

   The SDP describing the scenario given in Figure 2 can be written as:

        v=0
        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
                    retransmissions from a local server

   In this SDP, the source stream is multicast from a distribution
   source (with a source IP address of 198.51.100.1) to figure, we have the following multicast
   destination address of 233.252.0.2 and port 41000.  A retransmission
   server including feedback target functionality (with an address of
   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: ports:

   o  DS=198.51.100.1 - Address of  Ports P1 and P2 denote the distribution source

   o  G=233.252.0.2 - Destination address where destination RTP and RTCP ports in the
      primary multicast
      stream is sent session, respectively.  The clients listen to

   o  P1=41000 - Destination RTP port where
      these ports to receive the primary multicast stream
      is sent to RTP and RTCP packets.  Ports
      P1 and P2 are defined declaratively.

   o  P2=41001 - Destination  Port P3 denotes the RTCP port on the feedback target running on
      the retransmission server to collect the RTCP feedback messages,
      and RTP receiver and extended reports from the clients for in the
      primary multicast session session.  Port P3 is defined declaratively.

   o  S=192.0.2.1 - Address of  Port P4 denotes the retransmission server
   o  P3=41002 - Source RTP port on the retransmission server used for the
      unicast session

   o  P4=41003 - session.  The server multiplexes RTP and RTCP port traffic on the retransmission server for
      this single port [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast
      session

   We denote the client address
      session.  Port P4 is defined declaratively.

   o  Ports *c1 and *c2 are chosen by C. the client. *c1 denotes the port
      on the client used to send the unicast RTCP feedback in the
      primary multicast session. *c2 and *c3 denote denotes the RTP and RTCP ports port on the client used
      in the unicast session, respectively. session.  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/ muxes RTP and RTCP traffic on
      this single port muxing [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast
   session,
      session.  Ports c1 and c2 will equal c3.

   During do not have to be different ports.

   Once the lifetime of a unicast session, session is established, the server needs to remember
   the public IP address and public RTP and RTCP ports port of the client as a part of the
   session state information.

4.2.  Server-Generated Cookie Approach

4.2.1.  Steps

   This approach follows  The public ports of the client are
   denoted by c1' and c2'.

   In addition to the ports, we use the following notation:

   o  DS:  IP address of the distribution source

   o  G:  Destination multicast address

   o  S:  IP address of the retransmission server

   o  C:  IP address of the client

   o  C':  Public IP address of the client (as seen by the server)

   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.

3.1.  Steps for Establishing a Unicast Session

   The steps outlined to establish a unicast session are provided below:

   1.  The client ascertains server address (S) and port number(s) numbers (P3 and
       P4) from the
       SDP description (S, P3 and P4). session description.

   2.  The client determines its receive port numbers (*c2 (*c1 and *c3). *c2).

   3.  The client sends a message to the server via a new RTCP message,
       called PortMappingRequest.  Separate messages are sourced from
       ports c2 and c3 on the client.  Note that normally the  This message MUST be sent from port
       c2 should be addressed to port P3 on the server, P4.  The server learns client's public IP address (C')
       and the message sent from port c3 should be addressed to its public RTP/RTCP 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 (c2') from ports c2 and c3 MUST be
       sent to port P3 on the server. received message.

   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 opaque encapsulation (called Cookie) that
       conveys client's addressing information (IP address and port) using a reversible
       transform only known to the server.

   6.

   5.  The server sends each cookie the Cookie back to the client using a new RTCP
       message, called PortMappingResponse.  Assuming that the client
       does not support port muxing, two separate PortMappingResponse
       messages  This message 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
       from port muxing, then there is no need P4 to
       select a port c3 and the client needs one cookie only.

   8. c2'.

   6.  The client includes the cookie(s) Cookie when necessary in the subsequent
       messages sent to the server.

   9.

   7.  Normal flows ensue, with the server using the addressing
       encapsulated in the opaque cookie(s).

4.2.2. Cookie.  The client is responsible for
       keeping the NAT binding alive for the duration of the unicast
       session.

3.2.  Implications of NATs

   If there are no

   There may be one or more NAT devices between the server and client, the client
   MUST acquire a cookie for each distinct 2-tuple of (S, c2) and (S,
   c3).  In other words, as long server.
   Without an external mechanism such as STUN [RFC5389], the client uses the same local ports
   cannot determine whether there are any NATs between itself and the same server, it can use the same cookies when communicating
   with any feedback target running on this
   server.  The advantage here
   is that  Such NAT devices would block all incoming traffic unless the
   client can acquire sent traffic of the necessary cookies at same transport protocol to the very
   beginning for every port pair (if it is not port-muxing) it is
   planning server
   first.  Thus, the client has always to use, assume that there is at least
   one NAT device and thus, can avoid the delays incurred send periodic packets to acquire keep the cookies later when NAT binding
   alive [I-D.ietf-avt-app-rtp-keepalive].  Since the client multiplexes
   RTP and RTCP on a single port, it wants has to use keep a new single NAT binding
   alive for each unicast service. session.  See Section 3.4 for further details.

   If there is a the NAT device between the server fails for some reason and client, then restarts, the public
   IP address and/or port assigned to a particular client may still acquire change.
   This will invalidate the previously acquired cookies at the beginning, provided that it is
   behind and may result
   in a failure in the unicast session.  Upon detecting the failure, the
   client must acquire new cookies.  Applications using this method must
   be aware of the potential temporary interruptions.

   The NAT device may have endpoint-independent mappings [RFC4787],
   meaning that it assigns the same public IP address and port for the
   messages
   packets sent from the same internal IP address and port port, even when
   the client is talking to different destinations ("endpoint-
   independent mapping" [RFC4787]).  However, if destinations.  Oppositely, the NAT has endpoint-
   dependent mapping [RFC4787],
   device may have endpoint-dependent mappings in which case the client MUST fall back to acquiring a
   cookie for each distinct 3-tuple public
   IP address and port of (S, P3, c2) and (S, P3, c3). 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].

   When the client is behind a NAT, it needs to send periodic packets to
   keep the NAT bindings alive [RFC4787].  If the NAT device fails for
   some reason and then restarts, the public IP address and ports
   assigned to a client may change.  This will invalidate the previously
   acquired cookies.  Upon detecting the failure, the client must
   acquire new cookies.

4.2.3.

3.3.  Message Flows

   Figure 4 3 shows the message flows, where each message is appended with
   the (Source Address, Source Port, Destination Address, Destination
   Port) information.  In this section, we assume that the client does
   not mux the RTP and RTCP ports.

       --------------

     ------------   ----------------                     --------
      | Distribution |                     ------
    |Distribution| | Retransmission |                   |      |
    |   Source   | |     Server     |                   | Client |                   |Client|
    |    (DS)    | |       (S)      |                   |  (C) |
       --------------
     ------------   ----------------                     --------                     ------
               |    |                                  -    |
               |    |                                 | |
          |- (DS, *, G, P1) ->|---------   |
    (DS,*,G,P1)|--->|-------- RTP Multicast --------->|
          |- (DS, *, G, P2) .>|.-.-.-.-. |-->|
    (DS,*,G,P2)|.-.>|.-.-.-.- RTCP Multicast -.-.-.-.>| .-.-.-.->| |-->|
                    |                                 | |   |
                    |                                 | |   |    (C, c1, S, P2) |<.=.=.
                    |<=.=. RTCP Receiver Reports =.=.=|
          | |<..|(C,c1,S,P3)
                    |   (for the multicast session)   | |   |
                    :                                 | |   :
                    :                                 |    (C, c3, S, P3) |<~~~~ PortMappingRequest(c3) ~~~~~| |   :
                    :                                 | |
          |    (S, P3, C, c3) |~~~~~~~ PortMappingResponse ~~~~~>|
          |                   |            Cookie(c3)            |
          |                   |                                  |
          |    (C, c2, S, P3) |<~~~~ PortMappingRequest(c2) ~~~~~|
          |                   |          with Cookie(c3)         |   :
                    :                                 | |   :
                    |<~~~~~ PortMappingRequest ~~~~~~~| |<~~|(C,c2,S,P4)
                    |                                 |N|   |    (S, P3, C, c3) |~~~~~~~
       (S,P4,C',c2')|~~~~~~ PortMappingResponse ~~~~~>|
          | ~~~~~>|A|~~>|
                    |            Cookie(c2)            (Cookie)             |T|   |
                    |                                 | |   |    (C, c1, S, P2) |<~
                    |<~~~~ RTCP NACK with Cookie(c2,c3) ~~|
          | Cookie ~~~~~| |<~~|(C,c1,S,P3)
                    |                                 | |                   |**********************************|   |
                    |*********************************|*|***|
                    |*   UNICAST SESSION ESTABLISHED  *|  |                   |**********************************| |  *|
                    |*********************************|*|***|
                    |                                 | |    (S, P3, C, c2) |.......   |
       (S,P4,C',c2')|...... RTP Retransmissions .....>| |..>|
                    |                                 | |   |
                    |                                 | |   |    (C, c3, S, P3) |<.=.=.
                    |<=.=. RTCP Receiver Reports =.=.=|
          | |<..|(C,c2,S,P4)
                    |    (for the unicast session)    | |   |
                    |                                 |    (S, P3, C, c3) |.=.=.=. |   |
       (S,P4,C',c2')|=.=.=. RTCP Sender Reports =.=.=>|
          | |..>|
                    |    (for the unicast session)    | |   |
                    |                                 | |   |
                                                       -

    -------> Multicast RTP Flow
    .-.-.-.> Multicast RTCP Flow
    .=.=.=.> Unicast RTCP Reports
    ~~~~~~~> Unicast RTCP Feedback Messages
    .......> Unicast RTP Flow

        Figure 4: 3: Message flows for server-side cookie approach establishing a unicast session

   In the example above, the compound RTCP packet carrying the NACK
   message also carries the Cookie(c2) and Cookie(c3) Cookie since the server must know which ports 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 any cookies.

4.3.  Client-Generated Cookie Approach

4.3.1.  Steps

   This approach follows the steps outlined below:

   1.  The client ascertains server address and port number from Cookie.

3.4.  Keeping the SDP
       description (S and P3).

   2.  The client determines its port numbers (*c2 and *c3).

   3.  The client generates a random cookie.

   4.  The client sends separate RTCP packets from its ports c2 and c3 NAT Binding(s) Alive

   Editor's note:  We need to determine 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 best option to keep the NAT
   bindings alive
       [RFC4787].

   5.  The client sends unicast feedback from its port c1 to server port
       P2 where the RTCP feedback message also carries the cookie from
       Step 3.

   6.  The server correlates these three [I-D.ietf-avt-app-rtp-keepalive].

   Editor's note:  Are RTCP packets based on the
       cookie value, and remembers the public IP address(es) and port(s)
       of the client when sending packets back to the client.

       If the client supports RTP/RTCP port muxing, the server needs to
       remember only one public IP address and port.  The state
       information the server has receiver/extended reports enough to keep is reduced but not totally
       eliminated.

   If the server is about to send an RTP and/or RTCP packet to the
   client but does not know the port mappings since it has not received
   one or both of
   binding alive?

   TBD.

3.5.  SDP Description

   The SDP describing the RTCP packets sent scenario given in Step 4, it cannot start
   transmission.  Eventually, the client times out and resends the RTCP
   packets carrying the cookie Figure 2 can be written as:

        v=0
        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=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

       Figure 4: SDP describing an SSM distribution with support for
                    retransmissions from its ports c2 and c3.  Note that if
   the client supports port muxing, the failure probability is
   substantially reduced.  Once the a local server figures out the port
   mappings, it keeps that state information until

   In this SDP, the unicast session source stream is ended.

   After the server has established multicast from a port mapping for the 2-tuple of
   cookie and public distribution
   source (with a source IP address of 198.51.100.1) to the client, it discards RTCP packets
   carrying the same cookie coming from the same public IP multicast
   destination address but
   from a different public port. of 233.252.0.2 (G) and port 41000 (P1).  The reason is that such
   associated RTCP packets are
   likely to be sent by an attacker since there is no good reason for a
   client to change its port during a short-lived session.  Thus, if two
   different clients sharing multicast in the same public group to port 42000
   (P2).  A retransmission server including feedback target
   functionality with an IP address accidentally
   generate the same random cookie of 192.0.2.1 (S) and send it to the same port on the
   server, only of 43000
   (P3) is specified with the first 'rtcp' attribute.  The server uses port mapping will be valid.  If neither client
   is port-muxing,
   51000 (P4) for the (total 4) RTCP packets can cross each other
   resulting unicast sessions.

4.  Message Formats

   The common packet format for the RTCP feedback messages is defined in
   Section 6.1 of [RFC4585].  A feedback message has a failure.  To minimize the chances fixed-length
   field for version, padding, feedback message type (FMT), payload type
   (PT), length, SSRC of packet sender, SSRC of media sender as well as
   a failure in variable-length field for feedback control information (FCI).

   In the
   client-generated cookie approach, PortMappingRequest and PortMappingResponse messages, the client should support port
   muxing PT
   field is set to RTPFB (205), and the generated cookies should be truely random [RFC4086].

4.3.2.  Implications of NATs

   If there respective FMT fields are no NAT devices between the server set to
   PMReq (7) and client, there is
   no risk of a cookie collision.  Thus, PMRes (8).  Depending on the specific scenario, it is safe may
   be desirable to use this
   approach.

   When there is send these messages in a NAT device between reduced-size RTCP packet
   [RFC5506].  However, unless support for [RFC5506] has been signaled,
   compound RTCP packets MUST be used by following [RFC3550] rules.

   Editor's note:  Should the server and client, there is a
   risk of a cookie collision, although it is unlikely if always respond to the random
   cookies PMReq message
   as soon as possible?

   Following the rules specified in [RFC3550], all integer fields in the
   messages defined below are generated properly [RFC4086].

5.  Message Formats

   The carried in network-byte order, that is,
   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.

4.1.  PortMappingRequest message has (PMReq)

   Editor's note:  How do we set the media source SSRC field in the
   following format: message?  Is it application specific (e.g.,
   retransmissions, RAMS, etc.)?

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|   FMT  FMT=7  |       PT     PT=205    |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC of Packet Sender                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC of Media Source                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 5: FCI field syntax Syntax for the PortMappingRequest (PMReq) message

   The

   Editor's note:  What else do we need to transmit in the PMReq
   message?

4.2.  PortMappingResponse message has (PMRes)

   Editor's note:  How do we set the packet sender SSRC and media source
   SSRC fields in the following format: message?  Are they application specific
   (e.g., retransmissions, RAMS, etc.)?

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|   FMT  FMT=8  |       PT     PT=205    |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC of Packet Sender                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC of Media Source                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                             Cookie                            :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 6: FCI field syntax Syntax for the PortMappingResponse (PMRes) message

   Editor's note:  What else do we need to transmit in the PMRes
   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 PortMappingResponse message

   Editor's note:  We will finalize server
      tell the message formats in client about the expiration date so that the client may
      request a later
   version. 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

   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

   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

   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.1.  Normative References

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4588]  Rey,

   [RFC4585]  Ott, J., Leon, D., Miyazaki, A., Varsa, V., Wenger, S., Sato, N., Burmeister, C., and R.

              Hakenberg, "RTP Retransmission Payload Format", J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4588, 4585,
              July 2006.

   [I-D.ietf-avt-rtcpssm]

   [RFC5760]  Ott, J. and J. J., Chesterfield, "RTCP J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-
              Source Single-Source Multicast
              Sessions with Unicast Feedback",
              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. 5760, February 2010.

   [I-D.ietf-avt-rtp-and-rtcp-mux]
              Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port",
              draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
              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

   [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]
              Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
              Based Rapid Acquisition of Multicast RTP Sessions",
              draft-ietf-avt-rapid-acquisition-for-rtp-07
              draft-ietf-avt-rapid-acquisition-for-rtp-08 (work in
              progress), February March 2010.

   [I-D.ietf-behave-nat-behavior-discovery]
              MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
              Using STUN", draft-ietf-behave-nat-behavior-discovery-08
              (work in progress), September 2009.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              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,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              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
              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

   Ali Begen
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  abegen@cisco.com

   Bill VerSteeg
   Cisco
   5030 Sugarloaf Parkway
   Lawrenceville, GA  30044
   USA

   Email:  billvs@cisco.com