AVT                                                             A. Begen
Internet-Draft                                               B. VerSteeg                                                   D. Wing
Intended status:  Standards Track                                  Cisco
Expires:  November 20, 2010  May 19, 22, 2011                                    T. VanCaenegem
                                                          Alcatel-Lucent
                                                       November 18, 2010

  Token-Based Port Mapping Between Unicast and Multicast RTP Sessions
              draft-ietf-avt-ports-for-ucast-mcast-rtp-02
              draft-ietf-avt-ports-for-ucast-mcast-rtp-03

Abstract

   This document presents a port mapping solution that allows RTP
   receivers to choose their own ports for an auxiliary unicast 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 services
   (almost) without the unicast session. need for retrieving pre-authorization.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   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."

   This Internet-Draft will expire on November 20, 2010. May 22, 2011.

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  . . . . . . . . . . . . . . . . . . . .  5
   3.  Token-Based Port Mapping . . . . . . . . . . . . . . . . . . .  6
     3.1.  Token Request and Retrieval  . . . . . . . . . . . . . . .  6
     3.1.  Steps for Establishing a
     3.2.  Unicast Session Establishment  . . . . . . . . . .  8
     3.2.  Implications of NATs . . . .  6
   4.  The portmapping-req Attribute  . . . . . . . . . . . . . . . .  9
     3.3. 11
   5.  Message Flows Formats  . . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Keeping the NAT Binding(s) Alive . 12
     5.1.  Port Mapping Request . . . . . . . . . . . . 12
     3.5.  SDP Description . . . . . . . 13
     5.2.  Port Mapping Response  . . . . . . . . . . . . . . . 12
   4.  Message Formats . . . 13
     5.3.  Token Verification . . . . . . . . . . . . . . . . . . . . 14
     4.1.  PortMappingRequest (PMReq)
   6.  Procedures for Token Construction  . . . . . . . . . . . . . . 15
   7.  Validating Tokens  . . . . 14
     4.2.  PortMappingResponse (PMRes) . . . . . . . . . . . . . . . 15
   5.  Procedures for Cookie Construction . . . 16
   8.  SDP Example  . . . . . . . . . . . 16
   6. . . . . . . . . . . . . . . 17
   9.  Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 19
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7. 20
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
     7.1. 21
     11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 21
     11.2. Registration of FMT Values . . . . . . . . . . . . . . . . 18
   8.  Contributors and 21
     11.3. SFMT Values for Port Mapping Messages Registry . . . . . . 21
     11.4. RAMS Response Code Space Registry  . . . . . . . . . . . . 22
   12. Acknowledgments  . . . . . . . . . . . . . . . 19
   9. . . . . . . . . 23
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1. 24
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     9.2. 24
     13.2. Informative References . . . . . . . . . . . . . . . . . . 20 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 26

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 needs to choose its
   ports for RTP and 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 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.

   In this specification, we consider an RTP application that uses one
   or more unicast and multicast RTP sessions 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) [RFC5760] asking for a retransmission of the packets it is
   missing, and the local repair server sends the 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 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 a solution
   that we refer to as Port Mapping.  This solution allows receivers to
   choose their desired UDP ports for RTP and RTCP in every unicast
   session when they are running RTP applications using both unicast and
   multicast services, and offer/answer exchange is not available.  This
   solution is not applicable in cases where TCP is used as the
   transport protocol in the unicast sessions.  For such scenarios,
   refer to [RFC4145].

          -----------
         |  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.  Token-Based Port Mapping

   We present the details of the port mapping solution in the context of
   an illustrative example.

   Consider an SSM distribution network where a distribution source
   multicasts RTP packets to a large number

   Token-based Port Mapping consists of clients, two steps:  (i) Token request
   and one or more
   retransmission servers function as feedback targets to collect retrieval, and (ii) unicast RTCP feedback from these clients [RFC5760].  The
   retransmission servers also join the primary multicast session to establishment.  These are
   described below.

3.1.  Token Request and Retrieval

   This first step is required to be completed only once.  Once a Token
   is retrieved from a particular server, it can be used for all the
   unicast sessions the client will be running with this particular
   server.  By default, Tokens are server specific.  However, the client
   can use the same Token to communicate with different servers if these
   servers are provided with the same key used to generate the Token.
   The Token becomes invalid if client's public IP address changes or
   when the server expires the Token.  In these cases, the client has to
   request a new Token.

   The Token is essentially an opaque encapsulation that conveys
   client's IP address information (as seen by the server) using a
   reversible transform only known to the server.  When a request is
   received, the server creates a Token for this particular client, and
   sends it back to the client.  Later, when the client wants to
   establish a unicast session, the Token will be validated by the
   server, making sure that the IP address information matches.  This is
   effective against DoS attacks, e.g., an attacker cannot simply spoof
   another client's IP address and start a unicast transmission towards
   random clients.

3.2.  Unicast Session Establishment

   We illustrate the second step with an 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 [RFC5760].  The retransmission servers also join
   the multicast session to receive the multicast packets and cache them
   for a certain time period.  When a client detects missing packets in
   the primary multicast session, it requests a retransmission from one of the
   retransmission servers by using an RTCP NACK message [RFC4585].  The
   retransmission server pulls the requested packet(s) out of the cache
   and retransmits them to the requesting client. client [RFC4588].

   The pertaining RTP and RTCP flows are sketched in Figure 2.  Between
   the client and server, there may can be one or more NAT Network Address Port
   Translators (NAPT - hereafter simply called NAT) devices [RFC4787].

     --------------                                 ---     ----------
    |              |-------------------------------|   |-->|P1        |
    |              |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-|   |.->|P2        |
    |              |                               |   |   |          |
    | Distribution |      ----------------         |   |   |          |
    |    Source    |     |                |        |   |   |          |
    |              |---->|P1              |        |   |   |          |
    |              |.-.->|P2              |        |   |   |          |
    |              |     |                |        |   |   |          |
     --------------      |              P3|<.=.=.=.|   |=.=|*c1   |=.=|*c0       |
                         |              P3|<~~~~~~~|   |~~~|*c1       |
    PRIMARY
    MULTICAST RTP        |                |        |   |   |          |
    RTP
    SESSION with         |                |        |   |   |          |
    UNICAST FEEDBACK     |                |        | N |   |          |
                         | Retransmission |        | A |   |  Client  |
    - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
                         |     Server     |        | T |   |          |
    AUXILIARY UNICAST    |                |        |   |
                         |                |
    RTP SESSION        |              P4|<~~~~~~~|   |~~>|*c2   |   |              P4|........|   |..>|*c2          |
    PORT MAPPING         |              P4|<.=.=.=.|   |=.>|*c2              PT|<~~~~~~~|   |~~>|*cT       |
                         |                |        |   |   |          |
                          ----------------          ---     ----------

    -------> Multicast RTP Flow
    .-.-.-.> Multicast RTCP Flow
    .=.=.=.> Unicast RTCP Reports
    ~~~~~~~> Unicast RTCP Feedback Messages (if any)
    .......>
    - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
                         |                |        |   |   |          |
    AUXILIARY UNICAST    |                |        |   |   |          |
    RTP SESSION          |                |        |   |   |          |
                         |              P3|........|   |..>|*c1       |
                         |              P3|=.=.=.=.|   |=.>|*c1       |
                         |              P4|<.=.=.=.|   |=.=|*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 server

   In this figure, we have the following multicast and unicast ports:

   o  Ports P1 and P2 denote the destination RTP and RTCP ports in the
      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.

   o  Port P3 denotes the RTCP port on the feedback target running on
      the retransmission server to collect the RTCP feedback messages,
      and RTCP receiver and extended reports from the clients in the
      primary
      multicast session.  This is also the port that the retransmission
      server uses to send the RTP packets and RTCP sender reports in the
      unicast session.  Port P3 is defined declaratively.

   o  Port P4 denotes the RTCP port on the retransmission server used for to
      collect the
      unicast session.  The server multiplexes RTP and RTCP traffic on
      this single port [RFC5761] in receiver and extended reports for the unicast
      session.  Port P4 is defined declaratively and MUST be different
      from port P3.

   o  Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the
      port on the client used to send the RTCP reports for the multicast
      session. *c1 denotes the port on the client used to send the
      unicast RTCP feedback messages in the
      primary multicast session and to
      receive the RTP packets and RTCP sender reports in the unicast
      session. *c2 denotes the port on the client used
      in to send the unicast session.  The client multiplexes RTP and RTCP
      traffic on this single port [RFC5761]
      receiver and extended reports in the unicast session.  Ports c0,
      c1 and c2 do not have to MAY be the same port or different ports.

   Once  However, there
      are two advantages of using the unicast session is established, same port for both c0 and c1:

      1.  Some NATs only keep bindings active when a packet goes from
          the server needs inside to remember the public IP address and public port outside of the client as part NAT (See REQ-6 of Section 4.3
          of [RFC4787]).  When the
   session state information.  The public ports retransmission server sends unicast
          packets for a long period of time, this can exceed that
          timeout.  If c0=c1, the client are
   denoted by c1' and c2'.

   In addition to occasional (periodic) RTCP receiver
          reports sent from port c0 (for the multicast session) will
          ensure the NAT does not time out the public port associated
          with the incoming unicast traffic to port c1.

      2.  Having c0=c1 conserves NAT port bindings.

      Thus, it is strongly RECOMMENDED that the client uses the same
      port for c0 and c1.

   o  Ports PT and cT denote the ports through which the Token request
      and retrieval occur at the server and client sides, respectively.
      Port PT is declared on a per unicast session basis, although its
      value MAY be the same for all unicast sessions sourced by the
      server.  This way, a Token once requested and retrieved by a
      client from port PT remains valid across different unicast
      sessions.  Port PT MAY be equal to port P3.  Port cT MAY also be
      equal to ports c0 and c1.

   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 following steps to establish a unicast session are provided below: summarize the Token-based solution:

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

   2.  The client determines its port numbers (*c1 (*c0, *c1 and *c2).

   3.  If the client does not have a valid Token:

       A.  The client first sends a message to the server via a new RTCP
           message, called PortMappingRequest. Port Mapping Request to port PT.  This
           message MUST be is sent from port
       c2 to port P4. cT on the client side.  The server
           learns client's public IP address (C')
       and its public RTP/RTCP port (c2') from the received
           message.

   4.  The client can send this message anytime it wants
           (e.g., during initialization), and does not normally ever
           need to re-send this message (See Section 7).

       B.  The server generates an opaque encapsulation (called Cookie) (i.e., the
           Token) that conveys client's addressing IP address information using a
           reversible transform only known to the server.

   5.  For details,
           see Section 6.

       C.  The server sends the Cookie Token back to the client using a new
           RTCP message, called PortMappingResponse. Port Mapping Response.  This message
           MUST be sent from port P4 PT to port c2'.

   6. cT.

   4.  The client includes the Cookie when necessary in provides the subsequent
       messages sent Token to the server.  Note that the unicast session is
       not established during server using a new RTCP
       message, called Token Verification, whenever the steps required to retrieve client sends an
       RTCP feedback message for triggering or controlling a Cookie
       from unicast
       session.  Note that the server.  The unicast session is only established after
       the server has received a feedback message (along with a valid
       Cookie)
       Token) from the client for which it needs to react by sending
       unicast data (See Figure 3). data.  Until a unicast session is established, neither
       the server nor the client needs to send RTCP reports for the
       unicast session.

   7.

   5.  Normal flows ensue, with ensue as shown in Figure 2.  Note that in the server using
       unicast session the addressing
       encapsulated in RTP and RTCP packets MUST be multiplexed on
       the (same) port c1.  If the opaque Cookie.  The client is responsible for
       keeping uses the NAT binding alive same port for both c0
       and c1, the duration of RTCP reports sent for the unicast
       session.

3.2.  Implications of NATs

   There may be one or more NAT devices between multicast session keep the client and server.
   Without an external mechanism such as STUN [RFC5389],
       P3->c1(=c0) binding alive.  If the client
   cannot determine whether there are any NATs between itself uses different ports
       for c0 and the
   server.  Such NAT devices would block all incoming traffic unless the
   client sent traffic of the same transport protocol to the server
   first.  Thus, c1, the client has always needs to assume that there is at least
   one NAT device and periodically send periodic packets an explicit
       keep-alive message [I-D.ietf-avt-app-rtp-keepalive] to keep the NAT
       P3->c1 binding alive [I-D.ietf-avt-app-rtp-keepalive].  Since during the client multiplexes
   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 lifetime of the NAT device fails for some reason and then restarts, unicast session
       if the public
   IP address and/or port assigned unicast session's lifetime is likely to a particular client may change. exceed the NAT's
       timeout value.

4.  The portmapping-req Attribute

   This will invalidate new SDP attribute is used declaratively to indicate the previously acquired cookies and may result
   in port for
   obtaining a Token.  Its presence indicates that a failure Token MUST be
   included in the feedback messages sent to the server triggering or
   controlling a unicast session.  Upon detecting the failure, the
   client must acquire new cookies.  Applications using this method must
   be aware

   The formal description of the potential temporary interruptions.

   The NAT device may have endpoint-independent mappings [RFC4787],
   meaning that it assigns 'portmapping-req' attribute is defined
   by the same public IP address and following ABNF [RFC5234] syntax:

         portmapping-req-attribute = "a=portmapping-req:" port for the
   packets sent from the same internal IP address and port, even when
   the client CRLF

   Here, 'port' is talking to different destinations.  Oppositely, the NAT
   device may have endpoint-dependent mappings defined as specified in which case the public
   IP address and port Section 9 of the outgoing packets may differ when they are
   sent to different destinations.  In practice, however, it [RFC4566].  The
   'portmapping-req' attribute is used as a
   difficult task to determine session-level or media-level
   attribute.

5.  Message Formats

   This section defines the type formats of a NAT device
   [I-D.ietf-behave-nat-behavior-discovery].

3.3.  Message Flows

   Figure 3 shows the message flows, where each message is appended with RTCP transport-layer feedback
   messages that are exchanged between a server and a client for the (Source Address, Source Port, Destination Address, Destination
   Port) information.  The optional
   purpose of Token-based port mapping.  Three RTCP messages are indicated
   defined:

   1.  Port Mapping Request

   2.  Port Mapping Response

   3.  Token Verification

   These are all payload-independent RTCP feedback messages with a
   common format defined in
   parentheses and they may or may not be present Section 6.1 of [RFC4585], also sketched in certain scenarios.

     ------------   ----------------                     ------
    |Distribution| | Retransmission |                   |      |
    |   Source   | |     Server     |                   |Client|
    |    (DS)    | |       (S)      |                   |  (C) |
     ------------   ----------------                     ------
               |    |                                  -    |
               |    |                                 | |   |
    (DS,*,G,P1)|--->|------- (RTP Multicast) -------->| |-->|
    (DS,*,G,P2)|.-.>|.-.-.-. (RTCP Multicast) -.-.-.->| |-->|
                    |                                 | |   |
                    |                                 | |   |
                    |<=.= (RTCP Receiver Reports) .=.=| |<..|(C,c1,S,P3)
                    |   (for the multicast session)
   Figure 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|   FMT   |       PT      |          length               |
                    :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC of packet sender                        |   :
                    :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC of media source                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :
                    :                                 | |            Feedback Control Information (FCI)                 :
     :                                 | |                                                               :
                    |<~~~~~ PortMappingRequest ~~~~~~~| |<~~|(C,c2,S,P4)
                    |                                 |N|   |
       (S,P4,C',c2')|~~~~~~ PortMappingResponse ~~~~~>|A|~~>|
                    |            (Cookie)             |T|   |
                    |                                 | |   |
                    |<~~~~ RTCP NACK with Cookie ~~~~~| |<~~|(C,c1,S,P3)
                    |                                 | |   |
                    |*********************************|*|***|
                    |*   UNICAST SESSION ESTABLISHED  | |  *|
                    |*********************************|*|***|
                    |                                 | |   |
       (S,P4,C',c2')|...... RTP Retransmissions .....>| |..>|
                    |                                 | |   |
                    |                                 | |   |
                    |<=.=. RTCP Receiver Reports =.=.=| |<..|(C,c2,S,P4)
                    |    (for the unicast session)    | |   |
                    |                                 | |   |
       (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 3: Message flows The common packet format for establishing a unicast session

   In the example above, the compound RTCP packet carrying the NACK feedback messages

   Each feedback message also carries the Cookie since has a fixed-length field for version, padding,
   feedback message type (FMT), packet type (PT), length, SSRC of packet
   sender, SSRC of media source as well as a variable-length field for
   feedback control information (FCI).

   In the server must know which port new messages defined in this section, the client PT field is expecting set 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
   RTPFB (205) and
   extended reports), it does not have to include the Cookie.

3.4.  Keeping the NAT Binding(s) Alive

   Editor's note:  We need FMT field is set to determine the best option Port Mapping (7).  Individual
   Port Mapping messages are identified by a sub-field called Sub
   Feedback Message Type (SFMT).  Any Reserved field SHALL be set to keep
   zero and ignored.

   Following the NAT
   bindings alive [I-D.ietf-avt-app-rtp-keepalive].

   Editor's note:  Are RTCP receiver/extended reports enough to keep rules specified in [RFC3550], all integer fields in the
   binding alive?  No, keep-alive
   messages need to be sent after defined below are carried in network-byte order, that is,
   most significant byte (octet) first, also known as big-endian.
   Unless otherwise stated, numeric constants are in decimal (base 10).

5.1.  Port Mapping Request

   The Port Mapping Request message is identified by SFMT=1.  This
   message is a unicast feedback message transmitted by the client to a
   dedicated server port to request is made and until a Token.  In the cookie is no longer needed and Port Mapping
   Request message, the client does not start sending RTCP reports until MUST set both the unicast session
   is actually established which might happen a long time after packet sender SSRC and
   media source SSRC fields to its own SSRC since the
   cookie Port Mapping
   Request message is requested.

3.5.  SDP Description not necessarily linked to any specific media
   source.  The SDP describing the scenario given FCI field has the structure depicted in Figure 4.

      0                   1                   2 can be written as:

        v=0
        o=ali 1122334455 1122334466 IN IP4 nack.example.com
        s=Local Retransmissions
        t=0                   3
      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 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    SFMT=1     |                    Reserved                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Random                            |
     |                             Nonce                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 4: 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 The FCI field of 198.51.100.1) to Port Mapping Request message

   o  Random Nonce (64 bits):  Mandatory field that contains a random
      nonce value generated by the multicast
   destination address of 233.252.0.2 (G) and port 41000 (P1).  The
   associated RTCP packets are multicast in client following the same group to port 42000
   (P2).  A retransmission server including feedback target
   functionality with an IP address procedures of 192.0.2.1 (S) and port of 43000
   (P3) is specified with
      [RFC4086].  This nonce MUST be taken into account by the 'rtcp' attribute.  The server uses port
   51000 (P4)
      when generating a Token for the unicast sessions.

4.  Message Formats

   Editor's note:  Should we stick with 4585 packet format?

   Editor's note:  Must the client use to enable better security
      for clients that share the same SSRC (and IP address.  If the same but
   unique CNAME) both in Port Mapping
      Request message is transmitted multiple times for redundancy
      reasons, the multicast and unicast sessions so random nonce value MUST remain the
   reports received same in two sessions can be linked? these
      duplicated messages.

5.2.  Port Mapping Response

   The common packet format for the RTCP feedback messages is defined in
   Section 6.1 of [RFC4585].  A feedback Port Mapping Response message has a fixed-length
   field for version, padding, feedback is identified by SFMT=2.  This
   message type (FMT), payload type
   (PT), length, SSRC of packet sender, SSRC of media sender as well as
   a variable-length field for feedback control information (FCI).

   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 sent by following [RFC3550] rules.

   Editor's note:  Should the server always respond to the PMReq message
   as soon as possible?  If and delivers the request is rejected, Token to the server could
   send a PMRes message with client.
   In the Cookie field empty.

   Following Port Mapping Response message, the rules specified in [RFC3550], all integer packet sender SSRC and
   media sender SSRC fields in the
   messages defined below are 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 both set to zero and ignored.

4.1.  PortMappingRequest (PMReq)

   Editor's note:  How do we set the media sender client's SSRC field in since the
   following message?  The suggested approach
   Port Mapping Response message is not necessarily linked to use client's SSRC in
   both packet sender and any
   specific media sender SSRC fields. source.  The FCI field has the structure depicted in
   Figure 5.

      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=7
     |     PT=205    SFMT=2     |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC of Packet Sender                    Reserved                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC of Media Source                      |
     :                              Token                            :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     32-bit Random Number                            Expiry Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4.2.  PortMappingResponse (PMRes)

   o  Token (128 bits):  Mandatory element that contains the Token
      generated by the server.

   o  Expiry Time (32 bits):  Mandatory element that contains the expiry
      time of the Token.  The PortMappingResponse message expiry time is used by expressed in seconds from
      the server to send a
   Cookie to time the Token was generated.  An expiry time of zero
      indicates that the accompanying Token is not valid.

5.3.  Token Verification

   The Token Verification message is identified by SFMT=3.  This message
   contains the Token and MUST accompany any other RTCP feedback message
   sent by the client to trigger or control a unicast session.  Examples
   include the RAMS-R and RAMS-T messages
   [I-D.ietf-avt-rapid-acquisition-for-rtp] as well as the NACK messages
   [RFC4585].  In the Token Verification message, the client MUST set
   both the packet sender SSRC and media source SSRC fields to its own
   SSRC since the media source SSRC may not be known.  The client MUST
   NOT send a Token Verification message with a Token that has expired.
   The FCI field has the structure depicted in Figure 6.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    SFMT=3     |                    Reserved                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                              Token                            :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 6: FCI field syntax for the Token Verification message

   o  Token (128 bits):  Mandatory element that contains the Token
      previously acquired by the client.

6.  Procedures for Token Construction

   Editor's notes:

   The Token SHOULD be calculated by the server by taking into account:

   o  Client's IP address as seen by the server

   o  The nonce generated by the client and inserted in the Port Mapping
      Request message

   o  A timestamp to protect against replay attacks

   o  HMAC [RFC2104] of the above information (where only the server
      knows the HMAC secret)

   The server conveys the expiration time in the clear to the client in
   the Port Mapping Response message.  Thus, the client can request a
   new Token before the current one expires.

   Details are TBC.

7.  Validating Tokens

   Upon receipt of an RTCP feedback message along with the Token
   Verification message that contains a Token, the server MUST validate
   the Token.  The server considers a Token valid if the source IP
   address of the RTCP feedback message matches the IP address in the
   Token and the Token has not expired yet.

   The IP address is encoded into the Token by the server, using an
   algorithm known only to the server.  This, combined with the
   expiration time provides protection against DoS attacks so that a
   client using a certain IP address cannot cause one or more RTP
   packets to be sent to another client with a different IP address.

   When the server detects that the Token is invalid, it SHOULD NOT
   silently discard client's message since this adds an undesired delay.
   Instead, it is RECOMMENDED that applications define an application-
   specific error response.  In applications that have not defined an
   error response, the server MUST reply back to the client with a Port
   Mapping Response message (that goes from port P3 on the server to
   port c1 on the client) where the Token field carries the invalid
   Token sent by the client and the Expiry Time field is set to zero
   (indicating that the Token is invalid).

   For applications using [I-D.ietf-avt-rapid-acquisition-for-rtp], this
   draft defines a new 4xx-level response code in the RAMS Response Code
   Space Registry.

8.  SDP Example

   The declarative SDP describing the scenario given in Figure 2 is
   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=Multicast Stream
        c=IN IP4 233.252.0.2/255
        a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1   ; Note 1
        a=rtpmap:98 MP2T/90000s
        a=multicast-rtcp:41500                                 ; Note 1
        a=rtcp:42000 IN IP4 192.0.2.1                          ; Note 2
        a=rtcp-fb:98 nack                                      ; Note 2
        a=mid:1
        m=video 42000 RTP/AVPF 99                              ; Note 3
        i=Unicast Retransmission Stream
        c=IN IP4 192.0.2.1
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux                                             ; Note 4
        a=rtcp:42500                                           ; Note 5
        a=fmtp:99 apt=98; rtx-time=5000
        a=portmapping-req:30000                                ; Note 6
        a=mid:2

       Figure 7: SDP describing an SSM distribution with support for
                    retransmissions from a local server

   In this description, we highlight the following notes:

   Note 1:  The source stream is multicast from a distribution source
   with a source IP address of 198.51.100.1 (DS) to the multicast
   destination address of 233.252.0.2 (G) and port 41000 (P1).  The
   associated RTCP packets are multicast in the same group to port 41500
   (P2).

   Note 2:  A retransmission server including feedback target
   functionality with an IP address of 192.0.2.1 (S) and port of 42000
   (P3) is specified with the 'rtcp' attribute.  The feedback
   functionality is enabled for the RTP stream with payload type 98
   through the 'rtcp-fb' attribute [RFC4585].

   Note 3:  The port specified in the second "m" line (for the unicast
   stream) does not mean anything in this scenario as the client does
   not send any RTP traffic back to the server.

   Note 4:  The server multiplexes RTP and RTCP packets on the same port
   (c1 in Figure 2).

   Note 5:  The server uses port 42500 (P4) for the unicast sessions.

   Note 6:  The "a=portmapping-req" line indicates that a Token needs to
   be retrieved first before a unicast session associated to the
   multicast session can be established and that the Port Mapping
   Request message needs to be sent to port 30000 (PT).

9.  Address Pooling NATs

   Large-scale NAT (LSN) devices have a pool of public IPv4 addresses
   and map internal hosts to one of those public IPv4 addresses.  As
   long as an internal host maintains an active mapping in the NAT, the
   same IPv4 address is assigned to new connections.  However, once all
   of the host's mappings have been deleted (e.g., because of timeout),
   it is possible that a new connection from that same host will be
   assigned a different IPv4 address from the client, and pool.  When that occurs,
   the Token will be considered invalid by the server, causing an
   additional round trip for the client to include acquire a Cookie in the
   RTCP packets as necessary.  We might need to rename this message.

   Editor's note:  How do we set fresh Token.

   Any traffic from the packet sender SSRC and media sender
   SSRC fields in host which traverses the following message?  Are they application specific
   (e.g., retransmissions, RAMS, etc.)?  See NAT will prevent this
   problem.  As the earlier editor's note.

      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 host is sending RTCP receiver reports at least every
   5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|  FMT=8  |     PT=205    |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC of Packet Sender                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SSRC seconds (Section 6.2 of Media Source                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                             Cookie                            :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 6: Syntax [RFC3550]) for the PortMappingResponse (PMRes) message

   Editor's note:  What else do we need multicast session it is
   receiving, those RTCP messages will be sufficient to transmit in the PMRes
   message?  In particular, should the server indicate the expiration
   date for the Cookie?

5.  Procedures for Cookie Construction

   Editor's notes: prevent this
   problem.

10.  Security Considerations

   The Cookie may contain

   o  A 32-bit value randomly Token, which is generated by the client [RFC4086]

   o  Client's based on a client's IP address and port.  Note that the PMReq and NACK
      messages are
   expiration date, provides protection against denial-of-service (DoS)
   attacks.  An attacker using a certain IP address cannot cause one or
   more RTP packets to be sent from different to a victim client ports (and maybe from who has a different public IP addresses as well), thus
   address.  However, if the server cannot use
      this information to check whether attacker acquires a cookie is used by valid Token for a
   victim and can spoof the true
      owner of that cookie.

   o  Client's CNAME

   o  A timestamp victim's source address, this approach
   becomes vulnerable to protect against replay attacks (Should the server
      tell the client about the expiration date so that attacks.

   Multicast is deployed on managed networks - not the client may
      request Internet.  These
   managed networks will choose to enable network ingress filtering
   [RFC2827] or not.  If ingress filtering is enabled on a network, an
   attacker attacker cannot spoof a victim's IP address to use a new cookie before Token
   to initiate an attack against a victim.  However, if ingress
   filtering is not enabled on a network, an attacker could obtain a
   Token and spoof the current one expires?)

   o  HMAC [RFC2104] of victim's address, causing traffic to flood the above information (where only
   victim.  On such a network, the server
      knows can reduce the HMAC secret)

   Details are TBC.

6.  Security Considerations

   Editor's notes:

   o  Cookie expiration via timestamping.  This could be important time period for
      clients behind the same NAT (The clients may still generate
   such an attack by expiring a Token in a short period of time.  In the
      same random number)

   o  Stealing cookies.  Can CNAME be used to avoid this for
   extreme case, the clients
      behind server can expire the same NAT?

   o  Modifying cookies.  Can somebody manipulate Token immediately after its
   first use.  An expired Token forces a round trip from the cookies client to
      redirect
   the traffic?

7. server.

11.  IANA Considerations

   The following contact information shall be used for all registrations
   in this document:

   Ali Begen
   abegen@cisco.com

   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.

11.1.  Registration of SDP Attributes

   This document registers a new attribute name in SDP.

        SDP Attribute ("att-field"):
        Attribute name:     portmapping-req
        Long form:          Port for requesting Token
        Type of name:       att-field
        Type of attribute:  Either session or media level
        Subject to charset: No
        Purpose:            See this document
        Reference:          [RFCXXXX]
        Values:             See this document

11.2.  Registration of FMT Values

   Within FMT Values

   Within the RTPFB range, the following format (FMT) value is
   registered:

     Name:       Port Mapping
     Long name:  Port Mapping Between Unicast and Multicast RTP Sessions
     Value:      7
     Reference:  [RFCXXXX]

11.3.  SFMT Values for Port Mapping Messages Registry

   This document creates a new sub-registry for the sub-feedback message
   type (SFMT) values to be used with the FMT value registered for Port
   Mapping messages.  The registry is called the SFMT Values for Port
   Mapping Messages Registry.  This registry is to be managed by the
   IANA according to the Specification Required policy of [RFC5226].

   The length of the SFMT field in the Port Mapping messages is a single
   octet, allowing 256 values.  The registry is initialized with the
   following entries:

  Value Name                                               Reference
  ----- -------------------------------------------------- -------------
  0     Reserved                                           [RFCXXXX]
  1     Port Mapping Request                               [RFCXXXX]
  2     Port Mapping Response                              [RFCXXXX]
  3     Token Verification                                 [RFCXXXX]
  4-254                          Assignable - Specification Required
  255   Reserved                                           [RFCXXXX]

   The SFMT values 0 and 255 are reserved for future use.

   Any registration for an unassigned SFMT value needs to contain the
   following information:

   o  Contact information of the one doing the registration, including
      at least name, address, and email.

   o  A detailed description of what the RTPFB range, new SFMT represents and how it
      shall be interpreted.

11.4.  RAMS Response Code Space Registry

   This document adds the following format (FMT) values are
   registered:

        Name:           PMReq
        Long name:      Port Mapping Request
        Value:          7
        Reference:      [RFCXXXX]

        Name:           PMRes
        Long name:      Port Mapping entry to the RAMS Response
        Value:          8
        Reference: Code
   Space Registry.

  Code  Description                                        Reference
  ----- -------------------------------------------------- -------------
  405   Invalid Token                                      [RFCXXXX]

8.  Contributors and

   This response code is used when the Token included by the RTP_Rx in
   the RAMS-R message is invalid.

12.  Acknowledgments

   Many

   The approach presented in this document came out after discussions
   with various individuals in the AVT and MMUSIC WGs have contributed to this
   work, reviewed earlier versions of this specification WGs, and provided
   feedback.  The authors the breakout
   session held in the Anaheim meeting.  We thank each of them.

9. these
   individuals.

13.  References

9.1.

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

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              July 2006.

   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", RFC 5760, February 2010.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data

   [RFC5234]  Crocker, D. and
              Control Packets on a Single Port", P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5761, April 2010.

   [I-D.ietf-avt-app-rtp-keepalive]
              Marjou, X. 5234, January 2008.

   [RFC4086]  Eastlake, D., Schiller, J., and A. Sollaud, "Application Mechanism S. Crocker, "Randomness
              Requirements 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. Security", BCP 106, RFC 4086, June 2005.

13.2.  Informative References

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [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-09
              draft-ietf-avt-rapid-acquisition-for-rtp-16 (work in
              progress), April October 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.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [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.,

   [I-D.ietf-avt-app-rtp-keepalive]
              Marjou, X. and S. Crocker, "Randomness
              Requirements A. Sollaud, "Application Mechanism for Security", BCP 106, RFC 4086, June 2005.
              keeping alive the Network Address Translator (NAT)
              mappings associated to RTP flows.",
              draft-ietf-avt-app-rtp-keepalive-09 (work in progress),
              September 2010.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

Authors' Addresses

   Ali Begen
   Cisco
   181 Bay Street
   Toronto, ON  M5J 2T3
   CANADA
   Canada

   Email:  abegen@cisco.com

   Bill VerSteeg

   Dan Wing
   Cisco
   5030 Sugarloaf Parkway
   Lawrenceville, GA  30044 Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134
   USA

   Email:  billvs@cisco.com  dwing@cisco.com

   Tom VanCaenegem
   Alcatel-Lucent
   Copernicuslaan 50
   Antwerpen,   2018
   Belgium

   Email:  Tom.Van_Caenegem@alcatel-lucent.com