idnits 2.17.1 draft-finlayson-mboned-autotunneling-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 276 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '4' is mentioned on line 215, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ross Finlayson 2 Internet-Draft LIVE.COM 3 Radia Perlman 4 Sun Microsystems 5 Doron Rajwan 6 Bandwiz 7 Expire in six months 2001.02.19 9 Accelerating the Deployment of Multicast Using Automatic Tunneling 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 37 this document are to be interpreted as described in RFC 2119 [1]. 39 Abstract 41 Many Internet users currently cannot participate in wide-area IP 42 multicast sessions, because their first-hop routers (or beyond) do not 43 support IP multicast routing. We describe an application level 44 (UDP-based) tunneling mechanism that allows non-multicast-connected 45 users - with no modification to their operating systems - to 46 automatically receive a large class of multicast sessions, pending the 47 deployment of multicast in their upstream routers. 49 1. Introduction 51 Many Internet users remain unable to participate in wide-area multicast 52 sessions, because their first-hop router (e.g., a DSL router or a dialup 53 'portmaster') does not support IP multicast routing, and/or because 54 their ISP is unwilling or unable to provide multicast connectivity. 56 A secondary issue is that most users' operating systems currently do 57 not support IGMP version 3 [2] - the version of IGMP that is used, at 58 the 'leaves' of the network, to implement a special form of IP multicast 59 called "Source-Specific Multicast" (SSM) [3]. (SSM is expected to 60 become widely used for a large class of multicast sessions in which 61 all multicast data originates from a single source node.) 63 To accelerate the deployment and adoption of IP multicast, we wish to 64 provide a mechanism that allows such users to participate in multicast 65 sessions, even before their router(s) and/or operating systems become 66 upgraded to support native multicast. 68 Fortunately, such a mechanism already exists: UDP multicast tunneling. 69 In this mechanism, UDP multicast packets are tunneled within UDP unicast 70 packets. Such a tunnel is implemented by two tunneling agents 71 (the endpoints of the tunnel). One agent (the tunnel 'slave') resides 72 on a node in the multicast-connected portion of the Internet. The other 73 agent (the tunnel 'master') runs on the user's computer - either 74 embedded within the end-user application (such as an audio/video tool), 75 or else running as a separate application. Upon command from the 76 master, the slave receives all multicast packets that are addressed to 77 the desired multicast group and UDP port (and, in the case of SSM, 78 originating from the desired IP source address). These multicast 79 packets are encapsulated within UDP unicast packets and sent to the 80 master (i.e., the user's computer), which then decapsulates them and 81 delivers them (as multicast data) to the end application. (Also, for 82 non-SSM sessions, multicast data could be delivered over the tunnel in 83 the opposite direction as well.) 85 The benefit of this approach is that the user's tunneling agent can run 86 at the application level, without requiring any modification to the host 87 operating system. This means, however, that only UDP multicast 88 packets can be tunneled - not 'raw IP' multicast packets. Fortunately, 89 however, most (if not all) end user multicast applications use UDP. 91 For the purposes of this document, we also impose two additional 92 restrictions: First, the proposal described here is only for 93 SSM sessions. (Restricting multicast tunneling to SSM sessions makes it 94 easier to prevent data loops, as well as making it easier for a receiver 95 to detect when tunneling is no longer necessary.) Second, this proposal 96 is only for IPv4. (In IPv6, native multicast routing is ubiquitous, so 97 tunneling is not needed.) 99 Our proposal assumes the use of a UDP multicast tunneling protocol 100 such as UMTP [4]. This particular protocol has been used for several 101 years now to tunnel UDP multicast sessions (including SSM sessions) 102 over non-multicast-capable routers (and across firewalls). The protocol 103 includes both control packets (e.g., "JOIN_GROUP", "LEAVE_GROUP") and 104 data packets, all using a single UDP port. For each multicast session 105 that the tunnel master wishes to have tunneled, the master sends - to 106 the tunnel slave - a JOIN_GROUP command. This is done periodically, as 107 a 'keep-alive' (and thus the tunnel slave maintains 'soft state' for 108 each such session). The reader is referred to [4] for more information. 110 2. An Improvement: Automatic Tunneling, using Router Interception 112 The biggest problem with UDP multicast tunneling, as described above, is 113 that before the end user's computer can request that a multicast session 114 be tunneled, it needs to know which node to use as the remote (slave) 115 tunnel endpoint. Either the end user has to know and enter this 116 manually, or else some separate (unspecified) lookup or discovery 117 mechanism must be used to determine the tunnel endpoint. In any case, 118 there's no inherent guarantee that whatever tunnel endpoint gets used 119 will be in an optimal place in the networking topology. 121 This problem can be overcome by if *multicast routers* can also act as 122 tunnel endpoints. The user (master) end of the tunnel can send its 123 JOIN_GROUP requests not to an explicit tunnel endpoint, but instead 124 addressed to the SSM multicast source. The first multicast-capable 125 router in the path from the user's computer to the SSM source can 126 intercept this request, and - from then on - act as a UMTP tunnel slave 127 for this master. 129 Thus, this mechanism automatically locates a tunnel endpoint, and one 130 that is in an optimal location: the first multicast-capable router on 131 the path between the user's computer and the the SSM source node. 132 Furthermore, as additional routers below this become multicast-enabled, 133 they, too, will automatically take over the tunneling duty. Should 134 *all* routers on the path between the user's computer and the SSM 135 source become multicast enabled, the user's computer will start seeing 136 incoming native multicast packets from the SSM source node. When it 137 sees such packets, it can shut down the tunnel, knowing that native 138 multicast routing is now in place. 140 For this mechanism to work, SSM-multicast-capable (i.e., PIM-SSM) 141 routers should also be capable of acting as UMTP tunnel slaves, and 142 be able to intercept UMTP requests coming from below, as well as 143 receiving incoming data packets from above (i.e., from the SSM source) 144 and retransmitting them to the appropriate master(s) as tunneled UMTP 145 "DATA" commands. A single, well-known UDP port number (assigned by 146 IANA) would be used for UMTP; the routers would detect UDP packets 147 addressed to this port as UMTP commands that need to be handled 148 especially. 150 Ideally, *all* PIM-SSM routers would also be able to act as UMTP 151 tunnel slaves. However, this mechanism would still work - albeit 152 with a less-than-optimal tunneling topology - even if only *some* 153 of them have this capability. 155 The worst-case scenario is that *no* routers in the path between the 156 user's computer and the SSM source have this capability. To handle 157 this case, the SSM source node may also contain implement a UMTP slave 158 implementation of its own. This allows the server to automatically 159 stream to its multicast-connected customers via native multicast, and 160 to its non-multicast-connected customers via tunneled multicast. 162 3. Behavior of multicast receivers 164 To join a SSM session (S,G) (on UDP port P), the receiving node would: 165 1/ do an IGMPv3 (S,G) join (if it can!), *and* 166 2/ (perhaps after a short delay) act as UMTP tunnel master, 167 by periodically sending - to the desired SSM source - 168 a UMTP command: JOIN_GROUP(S,G,P). This command is sent 169 as a UDP packet addressed to the desired SSM source S. 171 (By doing a IGMPv3 join as well as sending a UMTP JOIN_GROUP 172 command, we allow for the possibility that the receiver's upstream 173 routers are multicast-enabled, but do *not* support UMTP.) 175 Similarly, to leave a SSM session, the receiving node would do both 176 an IGMPv3 leave (if it can!), *and* send a UMTP LEAVE_GROUP command 177 (again, addressed to the SSM source S). 179 If the receiver ever receives a native (i.e., non-tunneled) multicast 180 packet from the SSM source S, it knows that tunneling is no longer 181 necessary (for this source, at least). It then removes the tunnel, by 182 sending a UMTP "TEAR_DOWN" command (addressed to S), and stops sending 183 periodic JOIN_GROUP commands. (Thus, even if the TEAR_DOWN command 184 gets lost in transit, the tunneling would later time out anyway. In the 185 meantime, there would be some duplicate packets - tunneled and native.) 187 As the receiver receives encapsulated multicast packets across the 188 tunnel (as UMTP DATA commands), it decapsulates them and delivers them 189 to their intended local recipients - e.g., by re-multicasting them 190 locally (to the appropriate UDP port). Note, however, that this means 191 that the IP source address that the the ultimate receiving 192 application(s) see will *not* be that of the original SSM source. 193 Instead, the source address will be that of the local machine, and so 194 the receiving applications need to made be aware of this. 196 Probably the best place to deal with this is in whatever 'wrapper' 197 software is used to launch the application. This wrapper software can 198 do the following: 199 1/ act as a UMTP tunnel master and send a JOIN_GROUP command for 200 the desired SSM source, and then 201 2/ launch the application, but telling it that the *local node* 202 is to be the SSM source. 204 Another possible approach is to integrate the UMTP tunneling master 205 implementation within the application itself (rather than running UMTP 206 a separate application). 208 4. Behavior of routers 210 Non multicast-capable routers will, of course, simply forward UMTP 211 packets (whether control or data) just like any other UDP packets. 213 Multicast-capable routers, however, should intercept all UDP packets 214 that are addressed to the special port number for UMTP, and act as 215 a UMTP slave server to process such packets. (See [4] for details.) 216 The router performs the role of a UMTP slave in semantically exactly 217 the same way as if UMTP were running on top of the router as a 218 user-level application. 220 In particular, an incoming JOIN_GROUP command would be handled by 221 (effectively) joining the specified SSM group (S,G). The UMTP 222 implementation would then receive any subsequent (native) multicast 223 packets for this group, and deliver these packets down the tunnel 224 (i.e., encapsulated in UMTP DATA commands) to each UMTP recipient. 226 Note that - apart from this - the underlying router would handle these 227 incoming native multicast packets in exactly the same way as usual 228 (including continuing to forward them downstream if there are any native 229 receivers). While the router's UMTP implementation receives and 230 processes all native multicast packets that have a (S,G) that it's 231 interested in tunneling, the router *intercepts* only UMTP commands 232 (which are identified by UDP port number). Thus, only the handling of 233 incoming UDP commands needs to be in the router's 'fast path'. 235 5. Behavior of multicast senders 237 As noted earlier, the sending node may also include its own UMTP slave 238 implementation - allowing it to send data to non-multicast-connected 239 recipients via tunneling. This is assuming, of course, that the sender 240 has sufficient bandwidth to support these tunnels. (If necessary, the 241 sender's UMTP implementation can limit the number of tunnels that get 242 created.) 244 Alternatively, a sender without any multicast connectivity could set up 245 just a single UMTP tunnel - to a second, multicast-connected node that 246 would then do the actual multicasting. (This tunnel would be set up 247 explicitly rather than automatically.) The drawback of this approach 248 is that the actual SSM source would then be the second node rather than 249 the first; prospective receivers would need to be made aware of this. 251 6. References 253 [1] Bradner, S. 254 "Key words for use in RFCs to Indicate Requirement Levels" 255 RFC 2119, March 1997. 256 [2] Cain, B., Deering, S., Fenner, B., Kouvelas, I., Thyagarajan, A. 257 "Internet Group Management Protocol, Version 3" 258 Work-in-Progress, Internet-Draft "draft-ietf-idmr-igmp-v3-06.txt,.ps" 259 January, 2001. 260 [3] Holbrook, H., Cain, B. 261 "Source-Specific Multicast for IP" 262 Work-in-Progress, Internet-Draft "draft-holbrook-ssm-arch-01.txt" 263 November, 2000. 264 [3] Finlayson, R. 265 "The UDP Multicast Tunneling Protocol" 266 Work-in-Progress, Internet-Draft "draft-finlayson-umtp-05.txt" 267 February, 2001.