idnits 2.17.1 draft-xia-avt-proxy-rapid-acquisition-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([RFC4605]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 8, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5506' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-johansson-avt-mcast-based-rams' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.1Q' is defined on line 1024, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-07 == Outdated reference: A later version (-03) exists of draft-johansson-avt-mcast-based-rams-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1Q' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group J. Xia 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: September 9, 2010 H. Asaeda 6 Keio University 7 March 8, 2010 9 Proxy Rapid Acquisition of Multicast RTP Sessions 10 draft-xia-avt-proxy-rapid-acquisition-01 12 Abstract 14 This document describes a proxy rapid acquisition mechanism which 15 reduces acquisition delay for an RTP receiver without supporting any 16 rapid acquisition related functionality. The network is responsible 17 for managing rapid acquisition on behalf of the RTP receiver, 18 including detecting SFGMP message as proxy specified in [RFC4605] 19 from the RTP receiver and launching the required rapid acquisition 20 signaling instead of the RTP receiver. This proxy rapid acquisition 21 of multicast RTP session in this document is referred to as Proxy 22 Rapid Acquisition of Multicast Sessions. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 9, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Proxy Rapid Acquisition Motivation . . . . . . . . . . . . . . 5 66 4. Proxy Rapid Acquisition Overview . . . . . . . . . . . . . . . 7 67 4.1. Proxy Rapid Acquisition Architecture . . . . . . . . . . . 7 68 4.2. Proxy Rapid Acquisition Message Flows . . . . . . . . . . 10 69 4.3. Proxy Acquisition Anchor Point Operation . . . . . . . . . 14 70 4.3.1. Membership Database . . . . . . . . . . . . . . . . . 15 71 4.3.2. Transport Address Mapping Database . . . . . . . . . . 16 72 4.3.3. Forwarding Packets . . . . . . . . . . . . . . . . . . 16 73 4.4. Retransmission Server Operation . . . . . . . . . . . . . 17 74 4.5. RTP Receiver Operation . . . . . . . . . . . . . . . . . . 17 75 5. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 17 76 5.1. Proxy Rapid Acquisition Request . . . . . . . . . . . . . 17 77 6. SDP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 18 78 6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 82 10. Normative References . . . . . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 85 1. Introduction 87 The AVT working group has recently been working on specifying 88 extensions to the unicast feedback for SSM sessions [RFC5760]. There 89 is a large amount of interest from the IETF community in extending 90 the protocol to support some real, practical and immediate use-cases 91 for rapid acquisition. The basic requirement to adopt rapid 92 acquisition and related solutions have been described in 93 [I-D.ietf-avt-rapid-acquisition-for-rtp], 94 [I-D.draft-johansson-avt-mcast-based-rams]and 95 [I-D.draft-wang-avt-rtp-improved-rams]. In order to reduce the 96 acquisition time, these solutions primarily require the RTP receiver 97 to support rapid acquisition related functionality, including the 98 ability to solicit or terminate the burst and provide required 99 parameters to the network. These extensions will be implemented by 100 receiver's software, and maybe hardware, to accommodate the 101 requirement. From this viewpoint, this requirement may lead its 102 deployment difficulties. 104 This document proposes a proxy rapid acquisition approach without RTP 105 receiver involvement by extending RTCP Rapid Acquisition 106 [I-D.ietf-avt-rapid-acquisition-for-rtp] . This approach does not 107 require the RTP receiver to be involved in the exchange of signaling 108 messages between a RS and an RTP receiver. In order for this to 109 work, a proxy rapid acquisition function, called the Proxy 110 Acquisition Anchor Point, is introduced and allocated in the access 111 network, and performs the rapid acquisition related signaling with a 112 RS on behalf of the RTP receivers. Furthermore, the Proxy 113 Acquisition Anchor Point should support feedback target function to 114 perform aggregation of incoming RTCP messages and send aggregated 115 information directly or indirectly (e.g., the Proxy Acquisition 116 Anchor Point acts as a leaf feedback target in a hierarchical 117 topological structure) to Distribution Source as described in 118 [RFC5760]. 120 The document is organized as follows: in Section 3, we describe the 121 motivation why use a proxy network entity to perform rapid 122 acquisition on behave of RTP receiver; in Section 4, we present an 123 overview of the protocol design and behavior of network entities; in 124 Section 5, we list som messages that are exchanged between the RS and 125 Proxy Acquisition Anchor Point during proxy rapid acquisition.;in 126 Section 6, we discuss SDP signaling items with examples. 128 2. Terminology 130 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 All terms in this document are defined in [RFC4585], [RFC4588], 135 [RFC5760], [I-D.ietf-avt-rapid-acquisition-for-rtp] and [RFC4605]. 136 In addition or in replacement of these, the following terms are 137 defined or redefined: 139 Proxy Acquisition Domain 141 Proxy Acquisition Domain refers to the access network where the 142 rapid acquisition management of a RTP receiver is handled by Proxy 143 Acquisition Anchor Point as defined in this document. The Proxy 144 Acquisition domain includes single Proxy Acquisition Anchor Point 145 and multiple RTP receivers between which security associations can 146 be set up. It may consist of multiple wire or wireless interface 147 technologies (e.g. XDSL, MSTP, 802.16e, Universal Mobile 148 Telecommunications System (UMTS), etc.) interconnected with 149 multiple types of backhaul interconnections (such as Synchronous 150 Optical Network (SONET), Metro Ethernet, etc.). 152 Proxy Acquisition Anchor Point (PAAP) 154 The Proxy Acquisition Anchor Point is aggregation router which 155 manages the rapid acquisition related signaling for RTP receivers 156 attached to the proxy acquisition domain. Furthermore, Proxy 157 Acquisition Anchor Point is responsible for receiving the RTP 158 receivers' SFGMP Join/Leave messages, performing rapid acquisition 159 related signaling with the RS and aggregating RTCP information of 160 RTP receivers to Distribution Source. In this document, the Proxy 161 Acquisition Anchor Point MUST support the SFGMP Proxy 162 functionality specified in [RFC4605] and support the Feedback 163 Target functionality specified in [RFC5760]. 165 RTP Receiver (RR) 167 Throughout this document, the term "RTP Receiver" refers to the 168 entity whose rapid acquisition related functionality is managed by 169 the Proxy Acquisition Anchor Point. As a result, the RTP Receiver 170 is not required to participate in any rapid acquisition related 171 signaling for achieving rapid acquisition in the Proxy Acquisition 172 Domain. 174 Multicast Burst 176 A multicast stream is translated by Proxy Acquisition Anchor Point 177 into an RTP receiver understandable multicast format when Proxy 178 Acquisition Anchor Point receives the unicast RTP burst stream 179 from Burst Source [I-D.ietf-avt-rapid-acquisition-for-rtp] or the 180 unicast retransmission stream from Retransmission Source 181 [RFC4588]. If the multicast stream conveyed to RTP receiver is to 182 enable RTP receiver to rapidly acquire the Reference Information, 183 the multicast burst stream is typically shaped and transmitted at 184 an accelerated rate. Otherwise, the multicast burst stream is 185 shaped and transmitted at a normal rate. 187 Proxy Rapid Acquisition Request 189 A new RTCP message is sent by Proxy Acquisition Anchor Point to RS 190 for triggering unicast burst stream for the RTP receivers in its 191 proxy acquisition domain. 193 Proxy Rapid Acquisition Information 195 A new RTCP message is sent by RS in response to Proxy Rapid 196 Acquisition Request message that it received from Proxy 197 Acquisition Anchor Point. 199 Proxy Rapid Acquisition Termination 201 A new RTCP message is sent by Proxy Acquisition Anchor Point to RS 202 for terminating unicast burst stream. 204 3. Proxy Rapid Acquisition Motivation 206 All current rapid acquisition methods utilize an auxiliary high- 207 bitrate unicast or multicast burst triggered by the RTP receiver to 208 reduce the acquisition time. The common characteristic of these 209 methods is that software update, system resource allocation or 210 hardware modification are required on RTP receiver to support rapid 211 acquisition related functionality. This limits broad usage even if 212 the updates are small. The followings are the specific issues that 213 should be taken into account: 215 1. A large number of the RTP receivers lacking rapid acquisition 216 capability have been largely deployed. It is required lots of 217 efforts for each vendor to adopt rapid acquisition on all 218 variants of Windows, Android, iPhone, Linux and BSD systems. 219 Additionally, it will be impossible to support older models for 220 which support has been discontinued. 222 2. To avoid congestion possibility on the access network, RTP 223 receiver needs to frequently acquire the network state 224 information. It is assume that a RTP receiver may have knowledge 225 of a portion of this network which is in the vicinity of the RTP 226 receiver as described in section 5 of 228 [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, the RS may be 229 located far from the RTP receiver, in which case learning about 230 the states of network adjacent to RS is still a difficult task 231 for RTP receiver. Let alone it will be more complicated when the 232 states of network are varying over time. From the whole network 233 point of view, the transmission rate reported by RTP receiver 234 only reflects the capability of RTP receiver itself or its 235 adjacent access network rather than the capability of the 236 comprehensive network. 238 3. The RTP receiver may not smoothly splice (minimize or eliminate 239 the overlap and gap) the unicast burst stream and primary 240 multicast stream because of imperfections in the switch over. 242 4. The rapid acquisition signaling messages will consume radio 243 resources and the RTP receiver's power when RTP receiver is a 244 mobile terminal. The situation becomes worse in the case where 245 all rapid acquisition messages are sent multiple times against 246 the possibility of message loss. 248 For these reasons, Proxy Acquisition Anchor Point located at access 249 network is able to perform rapid acquisition related signaling for 250 RTP receivers as well as aggregate information contained in RTCP 251 packets of RTP receivers inside its domain. 253 As an intermediary network entity, Proxy Acquisition Anchor Point has 254 a more global view of the access network close to RTP receiver, as 255 well as the aggregate network close to RS. So Proxy Acquisition 256 Anchor Point can adjust bursting rate according to the states (i.e., 257 transmission medium, number of RTP receivers behind it, upper bound 258 bandwidth etc) of each segmental network respectively. It will be 259 more efficient to reduce the transmission latency when delivering 260 burst from RS to RTP receiver. For example, RS can transmit RTP 261 packets at 10Gbit/s rate to Proxy Acquisition Anchor Point when fiber 262 link is deployed between them, while Proxy Acquisition Anchor Point 263 can only transmit RTP packets at 200Mbit/s rate to RTP receiver when 264 ADSL link is deployed between them. The burst can earlier arrives at 265 RTP receiver compared to always transmit RTP packets at 200Mbit/s 266 rate in the whole burst course. 268 On the path between RS and RTP receiver, Proxy Acquisition Anchor 269 Point is regarded as an RTP receiver from RS perspective. Proxy 270 Acquisition Anchor Point should keep bursting with higher rate until 271 the burst catches up with the primary multicast stream, then 272 terminates the burst and conveys the primary multicast stream to RTP 273 receiver, in which case the overlap and gap are perfectly eliminated 274 on RTP receiver even if Proxy Acquisition Anchor Point needs to 275 filter the overlap of the unicast burst and the primary multicast 276 stream as an trade-off. However the network between RS and Proxy 277 Acquisition Anchor Point usually can provide wider bandwidth than 278 access network, so the network congestion caused by overlap is almost 279 negligible and the possibility of congestion-caused packet loss is 280 absolutely decreased. 282 The other advantages of developing a proxy rapid acquisition protocol 283 based on RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] are: 285 1. Reuse of RS functionality and the messages/format used in RAMS 286 signaling. RAMS is a mature protocol with several 287 implementations that have undergone interoperability testing. 289 2. For a rapid acquisition capable RTP receiver, the Proxy 290 Acquisition Anchor Point must be transparent to RAMS messages 291 from/to the RTP receiver without any interference. 293 The above observations, justify the development of the proxy rapid 294 acquisition protocol as an efficient alternative to RAMS. The 295 details of how a Proxy Acquisition Anchor Point perform rapid 296 acquisition on behalf of the RTP receiver are described in the 297 following sections. 299 4. Proxy Rapid Acquisition Overview 301 4.1. Proxy Rapid Acquisition Architecture 303 PRAMS provides proxy rapid acquisition support to an RTP receiver 304 (RR) without requiring its participation in any rapid acquisition 305 related signaling. The architecture for PRAMS is shown in Figure 1. 307 +----------------------------------------------+ 308 | Retransmission Server (RS) | 309 | (Feedback Target) | 310 | (Burst/Retrans Source) | 311 +----------------------------------------------+ 312 ^ ^ : 313 | ' : 314 | ' : 315 | ' v 316 +-----------+ +----------+ +------------------------------------+ 317 | | | |'''''''''''>| | 318 | Multicast |------->| Router |...........>| Proxy Acquisition Anchor Point | 319 | Source | | |<~~~~~~~~~~~| (Feedback Target) | 320 | | | |----------->| | 321 +-----------+ +----------+ +------------------------------------+ 322 / ^ ^ \ 323 / ~ ~ \ 324 / ~ ^ ~ \ 325 / ~ ' ' ~ \ 326 / ~ ' ' ~ \ 327 / ~ ' ' ~ \ 328 v ~ ' ' ~ v 329 +----------+ +----------+ 330 | | | | 331 | RTP | | RTP | 332 | Receiver | | Receiver | 333 | (RR1) | | (RR2) | 334 +----------+ +----------+ 336 '''> Unicast RTCP Messages 337 ~~~> SFGMP Messages 338 ...> Unicast RTP Flow 339 ---> Multicast RTP Flow 341 Figure 1: Flow diagram for proxy rapid acquisition 343 Feedback Target is defined as a logical function to which RTCP 344 unicast feedback traffic is addressed in [RFC5760]. The Feedback 345 Target can disjoint from the Distribution Source, perform aggregation 346 of incoming RTCP packets and send only aggregated information to the 347 Distribution Source, in which case Feedback Target performs 348 summarization functions and it must also act as a receiver and choose 349 a unique SSRC for its own reporting towards the Distribution Source. 351 This document reuses and extends above concepts to introducing a new 352 function entity, the Proxy Acquisition Anchor Point, and minor 353 extensions to the RS operation 355 [I-D.ietf-avt-rapid-acquisition-for-rtp]. The RTP Receiver and 356 Multicast Source operation will not be affected. 358 Proxy Acquisition Anchor Point can be deployed as the first hop 359 Feedback Target to the RTP receiver(s) and has knowledge of all these 360 RTP receivers behind it through summarizing RTCP reports. 361 Furthermore, from RS perspective, the Proxy Acquisition Anchor Point 362 is an RTP receiver and receives unicast format RTP packets [RFC4588] 363 from RS. 365 When Proxy Acquisition Anchor Point detects SFGMP messages from the 366 RTP receiver to joining the SSM session, prior to relay the messages 367 to upstream multicast router, the Proxy Acquisition Anchor Point 368 firstly launches the proxy rapid acquisition signaling for achieving 369 unicast burst defined in [I-D.ietf-avt-rapid-acquisition-for-rtp]. 370 Upon receiving unicast burst from RS, the Proxy Acquisition Anchor 371 Point needs to translate the unicast burst into multicast format 372 burst whose packet has same transport address as primary multicast 373 packet, then forward the multicast burst to RTP receiver. The Proxy 374 Acquisition Anchor Point needs to be able to adjust the rate of 375 multicast burst based on the access network situation and the RTP 376 receiver's capability. It is also worth noting that in order to 377 avoid any overlap or gap between the end of the multicast burst and 378 the reception of the primary multicast stream on RTP receiver, the 379 Proxy Acquisition Anchor Point must not stop the multicast burst 380 until the primary multicast stream arrives on its upstream interface. 382 The RS is defined as the combined functionality of Burst Source, 383 Retransmission Source and Distribution Source. This document reuses 384 and extends it to support proxy rapid acquisition function. This 385 means that the RS should be capable of distinguishing the unicast 386 burst stream is requested by a Proxy Acquisition Anchor Point or by a 387 RTP receiver. 389 The RTP receiver regularly sends the periodic receiver reports to 390 Proxy Acquisition Anchor Point, as well as receives RTCP RSI packets 391 and adapts session parameters in the SSM session. After sending 392 SFGMP messages, RTP receiver will receive the SSM stream with 393 accelerated rate soon, note that the rate is limited within the RTP 394 receiver's performance envelope. After a while the SSM stream slows 395 down to a normal rate and keeps stable. During the whole process, 396 RTP receiver should be unaware of the translation performance on 397 Proxy Acquisition Anchor Point. 399 It is possible that an operator may co-locate a Proxy Acquisition 400 Anchor Point with a RS. In such case, how the RS transmits bursts to 401 the Proxy Acquisition Anchor Point is an implementation issue which 402 is outside the scope of this document. In this document, only the 403 split scenario where the Proxy Acquisition Anchor Point is separated 404 from RS is taken into account. 406 Note that the proxy rapid acquisition protocol must ensure that there 407 is no any other significantly negative impact when providing 408 multicast burst to the RTP receiver. However, in the case where a 409 RTP receiver supports rapid acquisition and launches rapid 410 acquisition signaling itself, the Proxy Acquisition Anchor Point must 411 be transparent to the RAMS messages sent from/to the RTP receiver. 413 4.2. Proxy Rapid Acquisition Message Flows 415 Figure 2 shows the signaling flow for proxy rapid qcquisition when 416 the RTP receiver plans to join a SSM session. In Figure 2, the 417 signaling flow is simplified without any updated messages compared to 418 RAMS protocol. 420 +----------------+ +----------+ +-------------+ +-----------+ 421 | Retransmission | | | | Rapid | | RTP | 422 | Server | | Router | | Acquisition | | Receiver | 423 | (RS) | | | | Proxy(RAP) | | (RR) | 424 +----------------+ +----------+ +-------------+ +-----------+ 425 | | | | 426 | RTP Multicast | | 427 ----------------------------------------->|--------------->| 428 | | | | 429 | | | | 430 | | |<~ SFGMP Join ~~| 431 | | | | 432 | | | | 433 |<'''''''''''''RTCP Proxy RAMS-R ''| | 434 | | | | 435 | | | | 436 |'' (RTCP Proxy RAMS-I)'''''''''''>| | 437 | | | | 438 | | | | 439 |.. Unicast RTP Burst ............>| | 440 | | | | 441 | | | | 442 | | Format Translate | 443 | | | | 444 | | | Multicast RTP | 445 | | | Burst | 446 | | |--------------->| 447 | | | | 448 | | SFGMP Proxy | 449 | | | | 450 | | | | 451 | |<~ SFGMP Join ~~| | 452 | | | | 453 | | | | 454 | RTP Multicast | | 455 ----------------------------------------->|--------------->| 456 | | | | 457 | | | | 458 |<'''''''''''''''''' RTCP RAMS-T ''| | 459 | | | | 461 '''> Unicast RTCP Messages 462 ~~~> SFGMP Messages 463 ...> Unicast RTP Flow 464 ---> Multicast RTP Flow 466 Figure 2: Message flows for proxy rapid acquisition 468 1. Upon receiving the SFGMP Join message from RTP receiver, the 469 Proxy Acquisition Anchor Point will perform SFGMP Proxy function 470 defined in [RFC4605], and learn about which multicast RTP session 471 the RTP receiver intends to join. 473 The Proxy Acquisition Anchor Point needs to create a record in 474 membership database to maintain the membership record for each 475 RTP receiver. The membership database is a set of membership 476 records to set up the mapping between multicast session and 477 downstream interface connected to each RTP receiver. The details 478 about how the membership database work are specified in 479 Section 4.3.1. 481 Additionally, the Proxy Acquisition Anchor Point needs to 482 allocate a unique set of transport addresses, i.e., they share 483 the same IP address of upstream interface connected to RS but 484 different ports, for the multicast session which each RTP 485 receiver plan to join. Then the Proxy Acquisition Anchor Point 486 also creates a record in transport address mapping database to 487 maintain the mapping record for each multicast session. The 488 transport address mapping database is a set of records to set up 489 the mapping between multicast session and the list of transport 490 addresses. The details about how the transport address mapping 491 database work are specified in Section 4.3.2. 493 2. Then Proxy Acquisition Anchor Point sends a proxy rapid 494 acquisition request message for the multicast RTP session to the 495 RS. The request is analogous to the RAMS-R message and includes 496 a new flag to indicate to RS that the request is sent by Proxy 497 Acquisition Anchor Point. Note that proxy rapid acquisition 498 request message also contains a similar set of parameters (e.g. 499 bandwidth limit etc.) to indicate the capability of Proxy 500 Acquisition Anchor Point. 502 It is worth noting that the Proxy Acquisition Anchor Point must 503 have knowledge whether the RTP receiver support RAMS 504 functionality prior to sending proxy rapid acquisition request 505 message. Otherwise, the Proxy Acquisition Anchor Point may 506 misunderstand the SFGMP message and perform redundant rapid 507 acquisition for the RTP receiver who has already performed RAMS 508 itself prior to sending SFGMP message. 510 3. Upon receiving this proxy rapid acquisition request message, the 511 RS decides whether or not accept it and sends a proxy rapid 512 acquisition information message, which is analogous to RAMS-I 513 message, to RTP receiver. 515 If RS cannot provide a rapid acquisition service, RS rejects the 516 request and informs Proxy Acquisition Anchor Point immediately 517 via an proxy rapid acquisition information message. If Proxy 518 Acquisition Anchor Point receives a message indicating that its 519 proxy rapid acquisition request has been denied, it abandons the 520 proxy rapid acquisition attempt and MAY immediately join the 521 multicast session by relaying the SFGMP Join message towards its 522 upstream multicast router for the new primary multicast session. 523 If the primary multicast session has been subscribed by Proxy 524 Acquisition Anchor Point (i.e., other RTP receiver in proxy 525 acquisition domain has joined the same primary multicast 526 session), the Proxy Acquisition Anchor Point should immediatedly 527 forward the multicase stream to its downstream interface on which 528 the RTP receiver attaches. 530 If RS accepts the request, it sends an proxy rapid acquisition 531 information message to Proxy Acquisition Anchor Point that 532 comprises fields that can be used to describe the unicast burst 533 (e.g., the maximum bitrate and the duration of the unicast burst) 534 transfered between RS and Proxy Acquisition Anchor Point. A 535 particularly important field in the proxy rapid acquisition 536 information message carries the RTP sequence number of the first 537 packet transmitted in the retransmission session to allow Proxy 538 Acquisition Anchor Point to detect any missing initial packet(s). 539 When RS accepts the request, this field MUST be populated in the 540 proxy rapid acquisition information message and it is RECOMMENDED 541 that the proxy rapid acquisition information message is sent 542 early enough in the session to be useful. If RS rejects the 543 request, this field SHALL NOT exist in the proxy rapid 544 acquisition information message. 546 From the RS perspective, the Proxy Acquisition Anchor Point 547 performs RTP receiver role of the RAMS protocol. Hence, a common 548 RS would serve for both RAMS and proxy rapid acquisition protocol 549 simultaneously. 551 4. If the request is accepted, the RS starts sending the unicast RTP 552 burst to Proxy Acquisition Anchor Point. Because RTP receiver 553 does not support rapid acquisition functionality and has no 554 conception about the unicast RTP burst, so the Proxy Acquisition 555 Anchor Point needs to translate the received unicast RTP burst 556 into an multicast format (i.e., multicast RTP burst) before 557 forwarding it to RTP receiver. 559 On receiving unicast burst from the RS, the Proxy Acquisition 560 Anchor Point firstly verifies whether the destination transport 561 address of the unicast burst can match an existing record in its 562 transport address mapping database defined in Section 4.3.2. If 563 there does not exist one matched record, the Proxy Acquisition 564 Anchor Point must silently drop the burst. If there does exist 565 one matched record, the Proxy Acquisition Anchor Point should 566 replace the destination transport address of the unicast burst by 567 the transport address of the mapping multicast session. It is 568 worth noting that the source address of the burst is unchanged 569 because the RS is the single source in SSM defined in [RFC5760]. 571 After that, the Proxy Acquisition Anchor Point looks up the 572 membership database and finds out the exact downstream interface 573 as described in Section 4.3.1. If there is an existing matched 574 downstream interface, the Proxy Acquisition Anchor Point forwards 575 the reconstructive multicast burst to the proper RTP receiver at 576 an appropriate bursting rate. More details are given in 577 Section 4.3.3. 579 5. The time at which the Proxy Acquisition Anchor Point joins the 580 primary multicast session and transmits the primary multicast 581 session to the RTP receiver will varies with different use cases. 582 If the Proxy Acquisition Anchor Point has already joined the 583 primary multicast session on behalf of other RTP receiver 584 attached to it, the Proxy Acquisition Anchor Point will 585 immediately cease transmitting the multicast burst packets when 586 the multicast RTP burst has caught up with the primary multicast 587 stream. Beginning at that point, the Proxy Acquisition Anchor 588 Point should transmit the primary multicast packets instead of 589 multicast burst packets to RTP receiver at a normal rate. 591 If the primary multicast session which RTP receiver plans to join 592 is not subscribed by Proxy Acquisition Anchor Point at that time, 593 the Proxy Acquisition Anchor Point should rely on the proxy rapid 594 acquisition information message to explicitly notify when the 595 Proxy Acquisition Anchor Point should forward the SFGMP Join 596 message to its upstream multicast router for the new primary 597 multicast session. 599 6. After receiving the primary multicast session, the Proxy 600 Acquisition Anchor Point should extract the sequence number of 601 the first RTP packet received in the primary multicast session 602 and check whether the unicast burst has already caught up with 603 the primary multicast session. 605 If the unicast burst from RS has already caught up with the 606 primary multicast session (i.e., the value in Original Sequence 607 Number (OSN) field of the RTP retransmission payload header in 608 the latest unicast burst packet higher than the sequence number 609 of the first RTP packet received in the primary multicast 610 session, the Proxy Acquisition Anchor Point should initiate a 611 proxy rapid acquisition termination message to RS to cease the 612 burst, as well as not forward primary multicast streams to RR 613 until the sequence number of the primary multicast packet equal 614 to the OSN of the RTP retransmission payload header in the latest 615 unicast burst packet. 617 If the OSN of the RTP retransmission payload header in the latest 618 unicast burst packet exactlly equals to the sequence number of 619 the first RTP packet received in the primary multicast session, 620 the Proxy Acquisition Anchor Point should only initiate a proxy 621 rapid acquisition termination message to RS to cease the burst, 622 as wll as seamlessly switch to primary multicast session and 623 forward the primary multicast streams to RR immediately. 625 Otherwise, the Proxy Acquisition Anchor Point should continue 626 receiving burst packets until the OSN value in the latest unicast 627 burst packes exactlly equals to the sequence number of the latest 628 RTP packet received in the primary multicast packet. The next 629 process is in same order as above third paragraph. 631 4.3. Proxy Acquisition Anchor Point Operation 633 In Proxy Rapid Acquisition of Multicast Session, the Proxy 634 Acquisition Anchor Point is a intermediary network entity between the 635 RS and RTP receiver. It is responsible for performing rapid 636 acquisition related signaling with RS on behalf of the RTP receiver 637 in its Proxy Acquisition Domain. 639 Additionally, the Proxy Acquisition Anchor Point performs as SFGMP 640 proxy device and listens for SFGMP messages sent from RTP receivers 641 on its downstream interfaces. All SFGMP messages received on its 642 downstream interfaces MUST be properly processed by the Proxy 643 Acquisition Anchor Point and the necessary database to record the 644 mapping relationship between multicast session and RTP receiver also 645 need to be taken into account. The more details are described in 646 Section 4.3.1. 648 In particular, the Proxy Acquisition Anchor Point receives unicast 649 RTP burst from RS and translates the unicast RTP burst into multicast 650 format RTP burst . The more translation details are described in 651 Section 4.3.2. 653 In order to avoid the buffer overflow on the path between Proxy 654 Acquisition Anchor Point and RTP receiver and at RTP receiver itself, 655 Proxy Acquisition Anchor Point must limit the multicast burst rate 656 within the capability of RTP receiver. The more forwarding details 657 are described in Section 4.3.3. 659 When packet loss occurs during the burst between Proxy Acquisition 660 Anchor Point and RS, the Proxy Acquisition Anchor Point must create 661 its own RTCP feedback message to requesting retransmissions of the 662 missing packets from RS. 664 Proxy Acquisition Anchor Point acts as a regular Feedback Target in 665 the vicinity of RTP receiver, so it has the duty to detecting any 666 RTCP NACK message indicating packet loss on the path from Proxy 667 Acquisition Anchor Point to RTP receiver. In such case, the Proxy 668 Acquisition Anchor Point should perform conventional retransmission 669 for RTP receiver. The more details are described in Section 4.3.3. 671 4.3.1. Membership Database 673 Proxy Acquisition Anchor Point performs router portion of the SFGMP 674 protocol, handles SFGMP subscription from RTP receiver on its each 675 downstream interface and maintains a record for each downstream 676 interface. In SSM session, the address of Distribution Source is 677 explicitly indicated as specific source for the multicast group, as 678 well as the filter mode must be set as inclusion mode. Therefore, 679 only multicast group is the variable item needed to be maintained in 680 a record of membership database associated with a specific RTP 681 receiver. The membership database is a set of membership records of 682 the form: 684 (multicast group address, downstream interface to RTP receiver) 686 Note that the membership database need to be immediately updated once 687 the RTP receiver switches from one multicast session to another one. 689 4.3.2. Transport Address Mapping Database 691 Before sending proxy rapid acquisition request message, Proxy 692 Acquisition Anchor Point must firstly allocate a unique set of ports, 693 P, for the multicast session which the RTP receiver plans to join. 694 The multicast session can carry multiple multicast RTP sessions, m. 695 In such case each multicast RTP session will be allocated a couple of 696 ports for RTP and RTCP. The total available ports for each RTP 697 receiver (in the SSM session) P = m*2. Note that if Proxy 698 Acquisition Anchor Point implements RTP/RTCP port muxing 699 [I-D.ietf-avt-rtp-and-rtcp-mux], only one port is enough for each 700 multicast RTP session and the total available ports for each receiver 701 P = m. At this time, Proxy Acquisition Anchor Point creats a record 702 in its transport address mapping database to maintain the mapping for 703 port(s) and multicast RTP session. The transport address mapping 704 database is a set of membership records of the form: 706 (RTP port, RTCP port, multicast group address) 708 4.3.3. Forwarding Packets 710 Upon receiving the unicast burst whose destination address is Proxy 711 Acquisition Anchor Point upstream interface's address, the Proxy 712 Acquisition Anchor Point first lookups its transport address mapping 713 database to verify whether the destination port matches an existing 714 record. If there exist a matched record, the Proxy Acquisition 715 Anchor Point will replace the destination transport address of the 716 unicast burst by the transport address of the mapping multicast RTP 717 session and forward the reconstructive multicast burst to its 718 appropriate downstream interface based on membership database. 720 When RTP receiver receives multicast burst at an accelerated rate 721 compared to normal multicast stream, the Proxy Acquisition Anchor 722 Point must guarantee the accelerated rate stays within the capability 723 that RTP receiver can handle. However the RTP receiver is non- 724 updated to support rapid acquisition, so it can not negotiate its 725 capability with Proxy Acquisition Anchor Point, such as the buffer 726 and bandwidth limits. It is up to Proxy Acquisition Anchor Point to 727 estimate an amplification coefficient for each specific RTP receiver. 728 For example, the accelerated rate may be normal primary multicast 729 rate * 1.3 for the RTP receiver on ADSL link. 731 Note that the accelerated rate should be value within the range 732 normal rate < accelerated rate <= unicast burst rate. That demands 733 Proxy Acquisition Anchor Point must has enough buffer to continuously 734 cache the packets from RS. 736 If packet loss occurs on the RTP receiver, Proxy Acquisition Anchor 737 Point must reduce the raw accelerated rate. In the meanwhile, Proxy 738 Acquisition Anchor Point initiates its own RTCP NACK message to RS on 739 behalf RTP receiver. 741 4.4. Retransmission Server Operation 743 The RS MUST keep the RMAS related function as defined in 744 [I-D.ietf-avt-rapid-acquisition-for-rtp] and support additional 745 extensions defined in this document. 747 Proxy Acquisition Anchor Point can request different multicast 748 session on behalf of different RTP receivers simultaneously. Whereas 749 a RAMS capable RTP receiver can only request one multicast session at 750 a certain time, the request for a new multicast session means that 751 RTP receiver switches from former multicast session to another one. 752 From the above analysis, the RS MUST distinguish the request message 753 is sent from a proy or a real RTP receiver. This can be done by 754 checking whether the 'P' flag is set to value of 1 in rapid 755 acquisition request message, format specified in Section 5.1. 757 4.5. RTP Receiver Operation 759 When a RTP receiver attaches to an access network managed by Proxy 760 Acquisition Anchor Point, the RTP receiver can avoid significant 761 acquisition delay when joining a new multicast session, even if the 762 RTP receiver lacks of supporting any rapid acquisition related 763 functionality. So the support of rapid acquisition is completely 764 transparent to the RTP receiver''s operation. RTP receiver only gets 765 multicast streams from Proxy Acquisition Anchor Point at an 766 accelerated or a normal rate. 768 5. Signaling Extensions 770 This section outlines the extensions proposed to the feedback 771 messages specified in [RFC4585]. These signaling extensions also 772 refer RAMS messages specified in 773 [I-D.ietf-avt-rapid-acquisition-for-rtp]. 775 5.1. Proxy Rapid Acquisition Request 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | SFMT=1 |P| Reserved | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 : Optional TLV-encoded Fields (and Padding, if needed) : 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Figure 3: FCI field syntax for the RAMS Request message 785 A Proxy Rapid Acquisition message that is sent by a Proxy Acquisition 786 Anchor Point to a RS is referred to as the "Proxy Rapid Acquisition 787 Request" message. A new flag (P) is included in the Proxy Rapid 788 Acquisition Request message. The rest of the Proxy Rapid Acquisition 789 Request message format remains the same as defined in 790 [I-D.ietf-avt-rapid-acquisition-for-rtp]. 792 Proxy Rapid Acquisition Flag (P) 794 A new flag (P) is included in the Proxy Rapid Acquisition Request 795 message to indicate to the RS that the Rapid Acquisition Request 796 message is a proxy rapid acquisition. The flag MUST be set to the 797 value of 1 for proxy rapid acquisition and MUST be set to 0 for 798 direct rapid acquisition sent by a RTP receiver. 800 6. SDP Extensions 802 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585] 803 and a new syntax 'ssli' is added into the 'rtcp-fb' attribute in 804 [I-D.ietf-avt-rapid-acquisition-for-rtp]to the use of RAMS messages. 805 In this document, new SDP parameters are needed by the proposed 806 mechanisms (and that also need to be registered with IANA). 807 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 809 rtcp-fb-pt = "*" ; wildcard: applies to all formats 810 / fmt ; as defined in SDP spec 812 rtcp-fb-val = "nack" SP "psli" 814 The following parameter is defined in this document for use with 815 'nack': 817 'psli' stands for Proxy Synchronization Loss Indication and 818 indicates the use of proxy rapid acquisition messages on the Proxy 819 Acquisition Anchor Point. 821 6.1. Examples 823 This section provides a declarative SDP [RFC4566] example for 824 enabling proxy rapid acquisition of multicast RTP sessions. 826 In this example, we refer the similar SDP parameters defined in 827 [I-D.ietf-avt-rapid-acquisition-for-rtp]and [RFC5760]. The multicast 828 source stream from Distribution Source (with a source IP address of 829 192.0.2.2) to the multicast destination address of 233.252.0.2 and 830 port 41000. A RS including feedback target functionality (with an 831 address of 192.0.2.1 and port of 41001) is specified with the 'rtcp' 832 attribute. a Proxy Acquisition Anchor Point receives multicast source 833 stream and unicast burst stream on its upstream interface (with an 834 address of 192.0.2.3, rtp port 41002 and rtcp port 41003). 836 v=0 837 o=alice 3203093520 3203093520 IN IP4 prams.example.com 838 s=Proxy Rapid Acquisition Multicast Example 839 t=0 0 840 a=group:FID 1 2 3 841 a=rtcp-unicast:rsi 842 m=video 41000 RTP/AVPF 98 843 i=Primary Multicast Stream 844 c=IN IP4 233.252.0.2/255 845 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 846 a=recvonly 847 a=rtpmap:98 MP4V-ES/90000 848 a=rtcp:41001 IN IP4 192.0.2.1 849 a=rtcp-fb:98 nack 850 a=rtcp-fb:98 nack psli 851 a=ssrc:314159 cname:user@prams.example.com 852 a=mid:1 853 m=video 41002 RTP/AVPF 99 854 i=Unicast Rapid Acq Stream (upstream interface) 855 c=IN IP4 192.0.2.1 856 a=recvonly 857 a=rtpmap:99 rtx/90000 858 a=rtcp:41003 859 a=fmtp:99 apt=98; rtx-time=5000 860 a=mid:2 861 m=video 41000 RTP/AVPF 100 862 i=Multicast Stream (downstream interface) 863 c=IN IP4 233.252.0.2/255 864 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 865 a=sendonly 866 a=rtpmap:100 MP4V-ES/90000 867 a=rtcp:41001 IN IP4 192.0.2.3 868 a=rtcp-fb:100 nack 869 a=ssrc:314159 cname:user@prams.example.com 870 a=mid:3 872 Figure 4: Example SDP for Proxy Acquisition Anchor Point 873 v=0 874 o=ali 1122334455 1122334466 IN IP4 rams.example.com 875 s=Rapid Acquisition Example 876 t=0 0 877 a=group:FID 1 2 878 a=rtcp-unicast:rsi 879 m=video 41000 RTP/AVPF 98 880 i=Primary Multicast Stream 881 c=IN IP4 233.252.0.2/255 882 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 883 a=recvonly 884 a=rtpmap:98 MP2T/90000 885 a=rtcp:41001 IN IP4 192.0.2.1 886 a=rtcp-fb:98 nack 887 a=rtcp-fb:98 nack ssli 888 a=rtcp-fb:98 nack psli 889 a=ssrc:123321 cname:iptv-ch32@rams.example.com 890 a=rams-updates 891 a=mid:1 892 m=video 41002 RTP/AVPF 99 893 i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) 894 c=IN IP4 192.0.2.1 895 a=sendonly 896 a=rtpmap:99 rtx/90000 897 a=rtcp:41003 898 a=fmtp:99 apt=98; rtx-time=5000 899 a=mid:2 901 Figure 5: Example SDP for Retransmission Server 903 v=0 904 o=alice 3203093520 3203093520 IN IP4 prams.example.com 905 s=Proxy Rapid Acquisition Multicast Example 906 t=0 0 907 a=rtcp-unicast:rsi 908 m=video 41000 RTP/AVPF 100 909 i=Primary Multicast Stream 910 c=IN IP4 233.252.0.2/255 911 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 912 a=recvonly 913 a=rtpmap:100 MP4V-ES/90000 914 a=rtcp:41001 IN IP4 192.0.2.3 915 a=rtcp-fb:100 nack 916 a=ssrc:314159 cname:user@prams.example.com 918 Figure 6: Example SDP for RTP Receiver 920 7. IANA considerations 922 TBD 924 8. Security Considerations 926 Applications that are using PRAMS are analogous to the applications 927 that are using RAMS described in the 928 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Thus, these applications 929 are subject to the general security considerations discussed in 930 [I-D.ietf-avt-rapid-acquisition-for-rtp]. The additional security 931 weaknesses introduced by PRAMS needs to be taken into account and a 932 higher level of protection must be adopted. 934 First of all, after attaching to access network with Proxy 935 Acquisition Anchor Point support, the RTP receiver will send SFGMP 936 join message to its upstream router. a Proxy Acquisition Anchor Point 937 residing between the RTP receiver and its upstream router will 938 intercept this message. Counter-measures SHOULD be taken to prevent 939 tampered or spoofed SFGMP join messages between the Proxy Acquisition 940 Anchor Point and RTP receiver. The integrity and authenticity 941 mechanism can be used to prevent this security weakness. 943 When the Proxy Acquisition Anchor Point performs Rapid acquisition on 944 behalf of all the RTP receivers, PRAMS operation for each RTP 945 receiver may consume a lot of resources on RAP. A series of PRAMS 946 messages encapsulation and processing may sometimes overload the RAP. 947 On the other hand, the Proxy Acquisition Anchor Point needs to buffer 948 SFGMP message and establish membership database before PRAMS 949 operation completes. Upon receiving the unicast burst packet, the 950 Proxy Acquisition Anchor Point needs to translate unicast burst 951 packets into multicast format packets. These operations also consume 952 a certain resources. Therefore, the Proxy Acquisition Anchor Point 953 may for example discard messages until its resources become available 954 again. 956 Since the Proxy Acquisition Anchor Point may be impersonated by a 957 malicious node, counter measures should be taken to prevent man in 958 middle attack and replay attack brought by RAP. For example, the 959 channel binding mechanism described in [RFC5056] may be used to avoid 960 a rogue intermediary node providing unverified and conflicting 961 service information to each of the RTP receiver and the Authorization 962 server. 964 9. Acknowledgments 966 TBD 968 10. Normative References 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, March 1997. 973 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 974 Description Protocol", RFC 4566, July 2006. 976 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 977 "Extended RTP Profile for Real-time Transport Control 978 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 979 July 2006. 981 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 982 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 983 July 2006. 985 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 986 "Internet Group Management Protocol (IGMP) / Multicast 987 Listener Discovery (MLD)-Based Multicast Forwarding 988 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 990 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 991 Real-Time Transport Control Protocol (RTCP): Opportunities 992 and Consequences", RFC 5506, April 2009. 994 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 995 Channels", RFC 5056, November 2007. 997 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 998 Protocol (RTCP) Extensions for Single-Source Multicast 999 Sessions with Unicast Feedback", RFC 5760, February 2010. 1001 [I-D.ietf-avt-rapid-acquisition-for-rtp] 1002 Steeg, B. and Begen, A., "Unicast- Based Rapid Acquisition 1003 of Multicast RTP Sessions", 1004 draft-ietf-avt-rapid-acquisition-for-rtp-07 (work in 1005 progress), October 2009. 1007 [I-D.ietf-avt-rtp-and-rtcp-mux] 1008 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1009 Control Packets on a Single Port", 1010 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 1011 August 2007. 1013 [I-D.draft-johansson-avt-mcast-based-rams] 1014 Johansson, I., "Multicast-Based Rapid Acquisition of 1015 Multicast RTP Sessions", 1016 draft-johansson-avt-mcast-based-rams-00 (work in 1017 progress), April 2009. 1019 [I-D.draft-wang-avt-rtp-improved-rams] 1020 Wang, Y., "Improved Rapid Acquisition of Multicast 1021 Sessions", draft-wang-avt-rtp-improved-rams-01 (work in 1022 progress), October 2009. 1024 [IEEE-802.1Q] 1025 "Draft Standard for Virtual Bridged Local Area Networks 1026 P802.1Q-2003", IEEE Standards for Local and Metropolitan 1027 Area Networks , January 2003. 1029 Authors' Addresses 1031 Jinwei Xia 1032 Huawei Technologies Co.,Ltd 1033 Hui Hong Mansion 1034 Nanjing, Baixia District 210001 1035 China 1037 Phone: +86-025-84565890 1038 Email: xiajinwei@huawei.com 1040 Qin Wu 1041 Huawei Technologies Co.,Ltd 1042 Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd. 1043 Nanjing, Jiangsu 21001 1044 China 1046 Phone: +86-25-84565892 1047 Email: Sunseawq@huawei.com 1048 Hitoshi Asaeda 1049 Keio University 1050 Graduate School of Media and Governance 1051 5322 Endo 1052 Fujisawa, Kanagawa 252-8520 1053 Japan 1055 Email: asaeda@wide.ad.jp 1056 URI: http://www.sfc.wide.ad.jp/~asaeda/