idnits 2.17.1 draft-daley-magma-mobile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 337 has weird spacing: '...ishment hando...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7620 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) == Missing Reference: 'IP6-RFC' is mentioned on line 102, but not defined == Missing Reference: 'SAA-RFC' is mentioned on line 104, but not defined == Missing Reference: 'BETH' is mentioned on line 309, but not defined == Unused Reference: 'MLD-SRC' is defined on line 353, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. 'ND-RFC') (Obsoleted by RFC 4861) -- Duplicate reference: RFC2710, mentioned in 'MLD-SRC', was also mentioned in 'MLD-RFC'. -- Possible downref: Non-RFC (?) normative reference: ref. 'SENDIPSEC-01' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNOOP-07' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MAGMA Working Group Greg Daley 3 INTERNET-DRAFT Gopi Kurup 4 Expires: December 2003 Monash University CTIE 5 June 2003 7 Requirements for Mobile Multicast Clients 8 draft-daley-magma-mobile-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is an individual submission to the IETF. Comments 31 should be directed to the authors. 33 Definitions of requirements keywords are in accordance with the IETF 34 Best Current Practice - RFC2119 [KEYW-RFC] 36 Abstract 38 This document describes the existing systems available for mobile 39 devices to receive multicast data streams. It provides a case for 40 common handling of Network Attachment Detection for moving multicast 41 clients independent of global mobility signalling. 43 Table of Contents 45 Status of this Memo.......................................... 1 46 Abstract..................................................... 1 47 Table of Contents............................................ 1 48 1.0 Introduction............................................. 2 49 1.1 Terminology............................................. 2 50 2.0 Multicast Client Mobility................................ 3 51 2.1 Using Global Mobility Signalling for Multicast.......... 4 52 2.2 Joining a Group on a Visited Link...................... 5 53 2.3 Leaving a Visited Link.................................. 5 54 3.0 Proposal for Handling Multicast Client Movement.......... 6 55 3.1 Detecting Network Attachment............................ 6 56 3.2 Detecting Client Detachment............................. 6 57 3.3 Minimizing Multicast Routing Changes.................... 7 58 4.0 IANA Considerations...................................... 7 59 5.0 Security Considerations.................................. 7 60 Normative References......................................... 8 61 Non-Normative References..................................... 8 62 Acknowledgements............................................. 9 63 Authors' Address............................................. 9 65 1.0 Introduction 67 Multicast routing enables a set of applications which have 68 scalability benefits when many nodes on a subnet (or set of links) 69 wish to receive a common stream of data. This document describes the 70 existing systems available for mobile devices to receive multicast 71 data streams. 73 Most of the work which has been previously undertaken to provide 74 mobility support for hosts has relied upon unicast routing 75 [MIPv6-22,3GPP-MULT]. Work on these systems aims at principally at 76 isolating unicast address change from peer packet sources, or 77 providing direct path unicast routing through the use of unicast 78 care-of-addresses. 80 In the case where a mobile device does not require reception of 81 unicast packets, it may still have a requirement to receive multicast 82 streams as a client. One example environment is where commuters on 83 may be interested in updated weather or financial data, or local news 84 services. 86 In a dense user environment such as this, unicasting of these data 87 streams using mobility protocols will be inefficient and may lead to 88 excess bandwidth consumption[MULT-UMTS]. 90 If multicast is employed as an alternative delivery mechanism to 91 mobile hosts, there are tasks which must be performed in order to 92 start receiving multicast data streams on a new link. Additionally, 93 issues arise from the mobility of multicast clients which mean that 94 group membership information held by routers is not up-to-date. 96 As will be described in this document, some of these issues are 97 common to other application domains and may be handled using 98 mechanisms in common with those systems. 100 1.1 Terminology 102 IP - Internet Protocol Version 6 (IPv6)[IP6-RFC]. 104 DAD - Duplicate Address Detection [SAA-RFC] 106 MLD - Multicast Listener Discovery [MLD-RFC] 108 node - a device that implements IPv6. 110 router - a node that forwards IPv6 packets not explicitly 111 addressed to itself. 113 host - any node that is not a router. 115 link - a communication facility or medium over which nodes can 116 communicate at the link layer, i.e., the layer 117 immediately below IPv6. Examples are Ethernets (simple 118 or bridged); PPP links; X.25, Frame Relay, or ATM 119 networks; and internet (or higher) layer "tunnels", 120 such as tunnels over IPv4 or IPv6 itself. 122 address - an IPv6-layer identifier for an interface or a set of 123 interfaces. 125 querier - router on the subnet which actively queries MLD 126 state. 128 snooping - A mechanism whereby Link-Layer devices attempt to 129 infer multicast group membership by monitoring 130 MLD messages. 132 2.0 Multicast Client Mobility 134 MLD [MLD-RFC] defines mechanisms for joining Multicast groups on a 135 link. This protocol's goal is to provide a mechanism for determining 136 the presence or absence of hosts, in order that multicast routing 137 trees may be built to deliver streams of data to these clients. 139 Upon attaching to a link, a multicast client is instructed to send 140 MLD Reports for each of the multicast groups which it wishes to join. 141 When it receives a report, the Multicast Router requests a stream to 142 be sent to its own subnet if it is not already receiving that data. 143 Data will then arrive if multicast senders are transmitting for the 144 requested (S,G) pair[MLDv2-ID]. 146 When the client is moving, there is no existing provision which 147 allows the host to detect if it has arrived on a network where these 148 streams already exist. Additionally, until it receives router 149 advertisement information[ND-RFC], it may not be aware even if it is 150 attaching to a link where it has already joined the multicast groups 151 (for example if the Link-Layer Access Point changed, but not the IP 152 subnet). 154 Movement of a mobile device away from a node is problematic in that 155 existing multicast systems propagate data on the link for a fixed 156 interval unless the host explicitly leaves all of its multicast 157 groups before moving to another link. While this may be possible in 158 some link technologies where planned handovers are common [MULT- 159 UMTS], in circumstances where this signalling is not possible, 160 trailing multicast group memberships are left by moving nodes. 162 2.1 Using Global Mobility Signalling for Multicast 164 Existing work on Mobile IPv6 attempts to avoid reliance on Multicast 165 routing in the access networks by providing MLD support over a tunnel 166 between a mobile multicast client and its Home Agent Router. The 167 Home Agent is principally a device which redirects unicast packets to 168 a host when it has moved away from its unicast Home Address' subnet. 170 Under this scheme, multicast packets are treated in the same fashion 171 as unicast packets and are encapsulated in IPv6 and IPSec headers 172 before delivery to the mobile multicast client. The addition of such 173 headers to multicast packets is problematic in that their final size 174 may exceed link MTUs. This may lead to loss of the complete data 175 stream since Multicast systems provide no mechanisms for resizing 176 packets for clients on links with small MTUs. 178 Additionally, if the multicast client happens to be on the same 179 subnet as another device receiving this multicast data stream, it 180 loses the scalability benefits of group membership, and each packet 181 will be transferred across the link many times[MULT-UMTS]. 182 Conversely, if the mobile client population for this data stream is 183 sufficiently sparse, this may provide a reliable access to multicast 184 traffic, without undue burden to the visited access 185 network[MIPv6-22]. 187 2.2 Joining a Group on a Visited Link 189 Tunneled Multicasting may be valid in situations where multicast data 190 is associated with the mobile client's home network, but is not valid 191 if information received is specific to the visited domain. 193 For these services, at least, it is important to join multicast 194 groups on the visited access network. This means that MNs arriving 195 on-link will be bound to send MLD group join messages as soon as they 196 are aware that they are on a new link. If the mobile client 197 discovers that it is receiving a multicast data stream, but has not 198 sent reports to join the group on this link, it is still required to 199 join the group since the device which reported may itself be mobile 200 and cause the group to be removed by moving to another link. 202 In each case, the mobile client should either determine that the link 203 is a new one, or transmit MLD group join (report) messages even if 204 the link is the same. This second method may cause excessive 205 multicast traffic on the link if there may be many Link-Layer 206 handovers without changing subnet. 208 A notable exception to this is when it is possible that MLD snooping 209 may be in use within the access network [SNOOP-07]. In this case 210 snooping networks will require MLD group join messages whenever the 211 multicast client changes its Link-Layer attachment. 213 Further investigation of the effects of MLD snooping on host mobility 214 is required before recommendations may be made in this regard. 216 2.3 Leaving a Visited Link. 218 It is worth noting that a mobile client will (by default) maintain 219 group membership until the MLD Multicast Listener Interval expires. 220 This entails failing to send in an MLD report after a periodic Group 221 Query from the MLD Querier Router [MLD-RFC,MLDv2-ID]. 223 This may lead to the multicast router continuing to send packets 224 associated with a group to the mobile client, even if the this client 225 has moved, and it was the only member of the group. 227 If the mobile client is able to send an Multicast Listener Done 228 message, this issue does not occur, although this requires the client 229 to predict when it is about to move [FMIPv6-06,L2MANY-02]. Given 230 that this is not the case with most mobile devices today, it is 231 reasonable to expect that in some environments Multicast Routers may 232 have multiple groups for which data are transmitted onto a link for 233 absent clients. This would be a significant drain on wireless link 234 bandwidth resources, and could even be used to deny service. 236 3.0 Proposal for Handling Multicast Client Movement 238 Movement of multicast clients from subnet to subnet is likely to 239 cause significant routing disruption to multicast routing tables, or 240 additional bandwidth consumption. Here we outline three proposals 241 which may be of use in reducing link utilization and multicast 242 signalling. 244 3.1 Detecting Network Attachment 246 The role of joining a group is simply that of sending an MLD Report 247 and initiating timers. Even though this task is very simple to 248 perform, it is required for every group the multicast client is 249 interested in. Therefore it is valuable to avoid sending MLD reports 250 unless it has arrived at a link where its MLD group membership has 251 not been registered. This is particularly important if clients may 252 attach to a the same subnet many times as part of Link-layer handover 253 procedures. 255 There are existing reasons for detecting whether a host is attached 256 to a new link. For example in [MIPv6-22], mechanisms for detecting 257 movement have been defined which may be able to provide knowledge of 258 link identity using IPv6 Router Discovery[ND-RFC][MDO-01]. 260 Similar requirements exist for hosts without mobility signalling, in 261 order to determine if a session is able to maintain connectivity with 262 currently selected addresses. 264 It may make sense to use Router Discovery to determine the current 265 configuration status of a link using a common method. This method 266 could then be used for all affected sessions on the host, whether 267 unicast or multicast. 269 Currently enough interest exists in this field to propose a BoF 270 Session for IETF57 on Detecting Network Attachment. 272 3.2 Detecting Client Detachment 274 Access Routers on a link may have access to additional information 275 about the presence of hosts attached to a link. This may take the 276 form of communication with Link-Layer devices (such as wireless 277 access points) on a link, or through communication to peer ARs within 278 a routing domain. It may be possible for access routers to remove 279 old multicast state when the router is certain that the mobile client 280 has departed. 282 For Link-Layer devices, it may be possible to associate an Link-layer 283 identifier with the identity of a multicast client. When a wireless 284 Access Point indicates the removal of this Simple hysteresis 285 mechanisms could ensure that routing state is not changed in the case 286 where a client momentarily disconnects due to Link-Layer 287 handover[L2TRIG-01]. 289 Upon the multicast client's arrival at a new network, it may be 290 possible for the new access router to initiate a context transfer 291 with the old AR, which would remove the client's old multicast state. 292 While it is not seen as useful to initiate multicast services on a 293 new network using context transfer, it may be valid to remove 294 existing state on a previous network using such protocolsp[CTPPROB]. 296 At this stage, the use of the Context Transfer Protocol between ARs 297 in a domain is ongoing within the SEAMOBY-WG of the IETF[CTP-02]. 298 Additional protocols or mechanisms which define methods to 299 communicate Link-Layer connectivity within the local subnet are 300 underway, although no particular working group has ownership of this. 302 3.3 Minimizing Multicast Routing Changes 304 If mobile devices engender sparse Multicast Routing behaviour, there 305 may be significant cost in re-calculating and re-propagating 306 multicast trees, to support mobile client movements. It may be 307 necessary in some cases to defer multicast routing updates, by 308 adopting a local tunneling solution between pairs of Access 309 Routers[BETH,FMIPv6-06]. This would allow ARs to request data 310 streams from a router which is known to have access to a group, 311 without explicitly modifying global multicast routing. When routing 312 updates are completed, the new AR sends a Multicast Listener Done 313 message for the stream, across the tunnel. 315 This system would have similar MTU issues to the Unicast Mobility 316 systems described previously, except that the AR decapsulates packets 317 once they leave the tunnel before delivery on the access network. 318 Additionally, the role of the AR as arbiter of which groups arrive on 319 link is maintained. 321 At this stage, further analysis is required to determine if this 322 mechanism is actually useful in real networks. 324 4.0 IANA Considerations 326 N/A. 328 5.0 Security Considerations 330 This document describes a set of existing approaches which each have 331 their own security considerations. 333 Current work on Securing Neighbor Discovery [SENDIPSEC-01] may be 334 applicable to determine trust when undertaking router discovery 335 operations. 337 The proposal for edge multicast tunnel establishment handovers 339 Normative References 341 [KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate 342 Requirement Levels. Request for Comments (Best Current Practice) 343 2119 (BCP 14), Internet Engineering Task Force, March 1997 345 [ND-RFC] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for 346 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 347 Internet Engineering Task Force, December 1998. 349 [MLD-RFC] S. Deering, W. Fenner, B. Haberman. Multicast Listener 350 Discovery (MLD) for IPv6. Request for Comments (Proposed 351 Standard) 2710, Internet Engineering Task Force, October 1999. 353 [MLD-SRC] B. Haberman. "Source Address Selection for Multicast 354 Listener Discovery Protocol (RFC 2710)", Internet Draft (work in 355 progress), September 2002. 357 [SENDIPSEC-01] J. Arkko et al, "Secure Neighbor Discovery (SEND)", 358 Internet Draft (work in progress), June 2003. 360 [SNOOP-07] M. Christensen, K. Kimball, F. Solensky, "Considerations 361 for IGMP and MLD snooping switches", Internet Draft (work in 362 progress), April 2003. 364 Non-Normative References 366 [MIPv6-22] D. Johnson, C. Perkins, J. Arkko. Mobility Support in 367 IPv6. Internet Draft (work in progress), May 2003. 369 [MULT-UMTS] Mariann Hauge, �yvind Kure,"Multicast in 3G Networks: 370 Employment of Existing IP Multicast Protocols in UMTS", 371 Proceedings of the 5th ACM international workshop on Wireless 372 mobile multimedia, 2002 , Atlanta, Georgia, USA 374 [3GPP-MULT] "Universal Mobile Telecommunications System (UMTS); 375 Multimedia Broadcast/Multicast Service (MBMS); Stage 1", 3GPP 376 TS 22.146 version 6.2.0 Release 6, 2002. 378 [MLDv2-ID] R. Vida et al. Multicast Listener Discovery Version 2 379 (MLDv2) for IPv6. Internet Draft (work in progress), June 2002. 381 [CTPPROB] J. Kempf (Ed.). "Problem Description: Reasons For 382 Performing Context Transfers Between Nodes in an IP Access 383 Network", RFC 3374 (Informational), September 2002. 385 [CTP-02] J. Loughney (Ed.). "Context Transfer Protocol", Internet 386 Draft (work in progress), June 2003. 388 [MDO-01] G. Daley, JinHyeock Choi. "Movement Detection Optimization 389 in Mobile IPv6", Internet Draft (work in progress), May 2003. 391 [FMIPv6-06] R. Koodli (Ed.). "Fast Handovers for Mobile IPv6", 392 Internet Draft (work in progress), Mar 2003. 394 [L2MANY-02] A. Yegin (Ed.). "Supporting Optimized Handover for IP 395 Mobility - Requirements for Underlying Systems", Expired 396 Internet Draft, June 2002, http://www.yegin.org/alper/draft- 397 manyfolks-l2-mobilereq-02.txt 399 [L2TRIG-01] A. Yegin "Link-layer Triggers Protocol", Internet Draft 400 (work in progress), June 2003. 402 Acknowledgements 404 Alper Yegin's Contributions to the DNA-BoF mailing list have helped 405 in describing MLD state removal mechanisms. 407 Authors' Address: 409 greg.daley@eng.monash.edu.au 411 Greg Daley 413 g.kurup@eng.monash.edu.au 415 Gopi Kurup 417 Centre for Telecommunications and Information Engineering 418 Department of Electrical and Computer Systems Engineering 419 Monash University 420 Clayton 3800 421 Victoria 422 Australia 424 This document expires in December 2003.