idnits 2.17.1 draft-ietf-mip4-mcbc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 5036 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: 'NWG' is defined on line 462, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Muhanna (Ed.) 3 Internet-Draft Ericsson 4 Intended status: Standards Track B. Patil 5 Expires: January 13, 2011 Nokia 6 S. Chakrabarti 7 IP Infusion 8 G. Montenegro 9 Microsoft Corporation 10 Y. Wu 11 ZTE USA 12 July 12, 2010 14 IPv4 Mobility Extension for Multicast and Broadcast Packets 15 draft-ietf-mip4-mcbc-01.txt 17 Abstract 19 This document specifies a new Mobile IPv4 extension which is used to 20 negotiate the Multicast-Broadcast Encapsulation Delivery style in the 21 case of Mobile IPv4 Foreign Agent Care-of Address mode registration. 22 With this extension the mobile node is able to negotiate the type of 23 traffic that needs to be encapsulated for delivery to the foreign 24 agent while other types of traffic use the direct delivery style. 25 This mechanism eliminates the tunnel overhead between the mobile node 26 and the foreign agent. Multicast and broadcast applications on a 27 mobile IPv4 mobile node are better served with this extension. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 13, 2011. 46 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 Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 65 2.1. Conventions used in this document . . . . . . . . . . . . 5 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Multicast-Broadcast Encapsulating Delivery Style . . . . . . . 5 68 3.1. Multicast-Broadcast Encapsulating Delivery Extension . . . 6 69 3.2. Packet Header Formats for Visited Network Traffic . . . . 7 70 3.3. Packet Header Formats for Homebound Traffic . . . . . . . 8 71 4. Multicast-Broadcast Encapsulating delivery Style Vs 72 RFC3024 Encapsulating delivery . . . . . . . . . . . . . . . . 8 73 5. Link-layer Assisted Delivery Style (LLADS) . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative references . . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative references . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Appendix-A . . . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 The IP Mobility Protocol [RFC3344] describes multicast and broadcast 86 packet transmission between the mobile node and the home network or 87 visited network. Reverse Tunneling for Mobile IP [RFC3024] includes 88 support for reverse tunneling of multicast and broadcast packets to 89 the home network using the encapsulating delivery style between the 90 mobile nodes and the foreign agent. However, [RFC3024] says that 91 once the encapsulated delivery style is negotiated, all packets 92 exchanged between the mobile node and the foreign agent must be 93 delivered encapsulated. The delivery (of packets between the MN and 94 FA) methods specified in the base mobile IPv4 specification [RFC3344] 95 prevents an MN from sending unicast packets to the FA. Tunnelling 96 overhead is an issue especially on wireless links with the current 97 specification. Multicast and broadcast applications for a MN running 98 mobile IPv4 client software also are negatively impacted. In 99 particular, this imposition prevents direct delivery of unicast 100 packets from the mobile node to the foreign agent. This causes a 101 huge tunnel overhead in the (typically) wireless medium between the 102 mobile node and the foreign agent and indirectly makes it impossible 103 for the mobile node to use any of the multicast and broadcast 104 services. 106 Additionally, [RFC3344] sections 4.3 and 4.4 discusses multicast and 107 broadcast routing to and from the mobile node in the presence of 108 triangular routing and with a co-located Care-of address. Reverse 109 tunneling for Mobile IP [RFC3024] uses the optimal direct delivery 110 style from the mobile node via the foreign agent if only unicast 111 traffic is being reverse tunneled. If, however, multicast or 112 broadcast packets are also meant to be reverse tunneled, it 113 introduces the Encapsulating Delivery Style. Unfortunately, once the 114 encapsulating delivery style is negotiated, it applies to all reverse 115 tunneling traffics, including unicast. [RFC3344] also mandates, in 116 the case of FA Care-of Address mode, that all multicast and broadcast 117 packets be delivered encapsulated to mobile node. This also imposes 118 tunnel overhead for multicast and broadcast packets. While tunneling 119 overhead on wired links may be acceptable, it has a higher cost and 120 throughput impact in wireless links. Even though, Mobile IP has been 121 deployed for 3G data services, there has not been much usage of 122 multicast or broadcast data transfer to or from the mobile node. 123 Services like PTT (Push-To-Talk) rely on multicast. Other services 124 such as IPTV also use multicast to distribute streaming video to 125 mobile nodes. Hence it is essential to ensure that the mobile IPv4 126 clients support multicast and broadcast packet delivery in an optimal 127 manner. 129 Current mobile IPv4 specifications [RFC3344] and [RFC3024] do not 130 clearly address multicast/broadcast packet delivery for a MN with FA 131 care-of-address. for example, for encapsulating delivery style, the 132 source address of the outer and inner IP header is the home address 133 of the mobile node as described in section 5.2.2 of [RFC3024]. In 134 addition, section 5.4 talks about local delivery of multicast/ 135 broadcast packets in the visited network but some corner cases are 136 not completely specified. In particular, multicast messages from the 137 mobile node to the visited network may be needed for retrieving 138 service information. A mobile node may use all-mobility-agent 139 multicast as the destination address and its home-address as the 140 source-address for local service discovery. In this case, the 141 foreign agents must consider all messages with the all-mobility-agent 142 multicast as the destination address as special case and reply back 143 directly to the mobile-node. However, this scenario makes foreign 144 agent processing a bit more complex when reverse-tunnel is setup and 145 the mobile-node sends multicast messages towards the reverse tunnel 146 using its home-address as the source address. The all-mobility- 147 agents multicast address is used for router solicitation by the 148 mobile node, so foreign agent implementations must use it as a 149 special address. This leads to complexity if in the reverse tunnel 150 the mobile node uses its home address as the source address for other 151 multicast messages destined to the home and visited network. 153 Currently different organizations [3GPP2] define their own mechanism 154 to obtain local information such as DNS server IP address through 155 AAA. All Mobility-agent multicast is used for router solicitation by 156 the mobile node and the implementation can treat this address 157 specially at the foreign agent. However, the implementation of 158 foreign agent needs to apply multicast-address filtering and gets 159 very complex if the mobile client uses the home address as source 160 address for other multicast messages destined to the home and visited 161 network, in the reverse tunnel mode. Even if multicast packets are 162 delivered locally, the return packet which has the destination 163 address as the home address will be routed back all the way to the 164 home agent of the mobile node to be tunneled back to the foreign 165 agent and then to the mobile node. [RFC3024] recommends selective 166 reverse tunneling by delivering packets directly to the foreign 167 agent, while encapsulating them for reverse tunnel delivery. But the 168 specification is not clear about the source addresses of the packets 169 from the mobile node in case of selective direct delivery. Although 170 it clearly states that for the mobile node which uses co-located 171 care-of address mode. 173 This specification aims to clarify the delivery of multicast messages 174 when reverse tunneling is used, adds the capability to selectively 175 negotiates which type of traffic to be delivered using encapsulating 176 delivery, e.g., only for multicast and broadcast packets from mobile 177 node to foreign agent, while allowing direct delivery for other type 178 of traffic, e.g., unicast, and explores direct delivery options of 179 multicast messages between the mobile node and the foreign agent by 180 using link-layer capabilities. 182 Section 3 describes the new delivery extension for multicast- 183 broadcast packets in reverse tunnel mode. 185 2. Conventions & Terminology 187 2.1. Conventions used in this document 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 2.2. Terminology 195 All the general mobility related terminology and abbreviations are to 196 be interpreted as defined in IP Mobility Protocol [RFC3344] and 197 Reverse tunneling for Mobile IP [RFC3024]. The following terms are 198 used in this document. 200 MN 202 Mobile Node. 204 FA 206 Foreign Agent. 208 FA-CoA 210 Foreign Agent as the Mobile Node Care-of Address. 212 3. Multicast-Broadcast Encapsulating Delivery Style 214 The Mobile IP reverse tunneling [RFC3024] defines the Encapsulating 215 delivery style for delivering multicast and broadcast packets from 216 the mobile node to the foreign agent in the FA-CoA mode. It also 217 mandates Encapsulating delivery mode for sending multicast/broadcast 218 packets to reverse-tunnel to home agent via the foreign agent. But 219 [RFC3024] section 2 says that all reverse-tunneled traffic is 220 encapsulated when Encapsulating Delivery is negotiated. The 221 "Multicast-Broadcast Encapsulating Delivery Style" (MBEDS) extension 222 defined in this specification applies encapsulation only to the 223 reverse-tunneled multicast and broadcast packets, leaving direct 224 delivery for reverse-tunneled unicast packets. The main motivation 225 for adding this extension is to save the overhead of additional IP 226 header for unicast packets which consequently will enable the use of 227 Multicast and Broadcast packets when Mobile IPv4 is in use. This 228 procedure works for both shared media like ethernet, IEEE 802.11 and 229 links of a point-to-point nature such as those defined by 3GPP, 3GPP2 230 and IEEE 802.16. 232 3.1. Multicast-Broadcast Encapsulating Delivery Extension 234 The proposed extension is used in Mobile IPv4 signaling to negotiate 235 the Multicast-Broadcast Encapsulation Delivery Style. Foreign agents 236 SHOULD support the Multicast-Broadcast Encapsulating Delivery Style 237 Extension. A registration request MAY include either a regular 238 encapsulating delivery extension (see section 3.3 in [RFC3024]) or a 239 Multicast-Broadcast Encapsulating Delivery extension, but not both. 240 If both extensions are present, the foreign agent will consider that 241 an error scenario and the FA MUST reject the registration request by 242 sending a registration reply with the code field set to "Poorly 243 Formed Request". 245 If a foreign agent supports MBEDS, then the foreign agent SHOULD 246 advertise the MBEDS extension in its router advertisement to inform 247 the mobile node about the type of delivery style it supports. This 248 will avoid the possibility of multiple registration requests to 249 figure out which encapsulating mode the foreign agent supports. 251 If the MN includes an MBEDS extension, if MUST do so after the 252 Mobile-Home Authentication Extension, and before the Mobile-Foreign 253 Authentication Extension, if present. The Encapsulating Delivery 254 Style Extension MUST NOT be included if the 'T' bit is not set in the 255 Registration Request. 257 If no delivery style extension is present, Direct Delivery per RFC 258 3024 is assumed. 260 The Multicast-Broadcast Encapsulation Extension format is as in 261 Figure 1 below. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length | Bit-field Value | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1: Multicast-Broadcast Encapsulating Extension 271 Type 273 275 Length 277 8-bit unsigned integer indicating the length in octets of the Bit- 278 Field . It is set to 2. 280 Bit-Field Value 282 A 16-bit bit-field. Value specifies what type of packets are 283 encapsulated. The following bits are defined (0 being the right- 284 most bit, 15 the left-most bit): 286 0: 288 All packets are encapsulated between a mobile node and a 289 foreign agent. It is same as the Encapsulating Delivery Style 290 in RFC3024. NOTE: obsolete EDS in 3024?. 292 1: 294 Only multicast and broadcast packets are encapsulated (MBEDS). 296 2: 298 Link-layer Assisted Delivery Style (LLAS) for local network. 300 All other bits values are reserved. 302 NOTE: Only MBEDS packets are reverse tunneled after being 303 decapsulated at the foreign agent, not those directly destined to the 304 foreign-agent address or all mobility agent address. These are 305 processed locally by the foreign agent. 307 3.2. Packet Header Formats for Visited Network Traffic 309 Other than Mobile IP agent solicitation packets, there might be some 310 multicast or broadcast packets meant for consumption at the visited 311 network. If the mobile node can acquire a local IP address, then it 312 MUST direct deliver the multicast and broadcast traffic for local 313 use. If the mobile node can have only one IP address, (i.e. home 314 address) then it MUST send all the multicast and broadcast packets 315 encapsulated. These packets will be sent to the home network through 316 the reverse tunnel after being decapsulated at the foreign agent; 317 only exceptions are the multicast solicitation messages for the 318 mobility agent. 320 In some cases, the mobile node may want to send multicast or 321 broadcast packets to visited network entities other than the foreign 322 agent. In those cases they should always be direct delivered by 323 acquiring a local IP address or using link-layer mechanism if 324 possible. Please see the section 'Link-layer Assisted Delivery 325 Style' below for details. 327 3.3. Packet Header Formats for Homebound Traffic 329 The packet format and processing for encapsulated multicast and 330 broadcast traffic is the same as defined in section 5.2 of Reverse 331 Tunneling for Mobile IP [RFC3024]. Additionally, the packet format 332 and processing for unicast traffic is the same as defined in section 333 5.1 of the same specification. 335 4. Multicast-Broadcast Encapsulating delivery Style Vs RFC3024 336 Encapsulating delivery 338 RFC3024 encapsulating delivery style does not require the foreign- 339 agent to advertise an extension as well for the mobile node 340 efficiency. MBEDS provides an option for foreign agent to advertise 341 the extension with supported extension types, so that a mobile node 342 can request a delivery style that the foreign agent supports. 344 RFC3024 encapsulating delivery style requires all multicast, 345 broadcast and unicast traffic to be encapsulated in order to be 346 reverse tunneled. In MBEDS unicast packets are always direct 347 delivered to the foreign agent. Most of the the cases a node sends 348 unicast packets for communication with a correspondent node and 349 occasionally it may send broadcast or multicast packets to the home 350 network. Thus this new style of delivery relieves the overhead of 351 encapsulation for most traffic. 353 MBEDS introduces TLV style extension for delivery style. Therefore, 354 this extension can be used to negotiate different delivery styles in 355 the future. Currently, it can be backward compatible with RFC3024 356 encapsulating delivery style when the value field is zero. NOTE: We 357 should make this a bit field to allow for easier advertisement and 358 other extensions. 360 A mobile node SHOULD use either RFC3024 style encapsulating delivery 361 extension or the MBEDS extension (defined in this document), but not 362 both at the same time. If both extensions are received at the 363 foreign-agent, the foreign agent MUST reject the registration request 364 by sending a registration reply with error (70) "Poorly Formed 365 Request". 367 5. Link-layer Assisted Delivery Style (LLADS) 369 This section discusses direct-delivery of multicast and broadcast 370 packets between the mobile node and the foreign agent by taking 371 advantage of link-layer mechanisms. Certain link-layers allow for 372 direct delivery from the MN to the FA (and vice-versa) without the 373 need for encapsulation. In effect, this is assumed by RFC 3024 for 374 Direct Delivery Style. In this mode, a unicast packet at the IP 375 layer is carried over a unicast link-layer delivery mechanism. For 376 example, the FA's MAC address is the link-layer destination address, 377 or the packet is sent on a link of a point-to-point nature as in 3G 378 networks. Broadcast and multicast packets, however are typically 379 sent using a link-layer broadcast or multicast mechanism: a broadcast 380 or multicast MAC address for IEEE 802.11 networks. If, however, 381 these packets had the FA unicast MAC address while carrying an IP 382 layer broadcast or multicast destination, then there would be no need 383 for encapsulation to remove the ambiguity. The packet would be 384 unequivocally directed at, and consumed by the FA. Notice that in 385 links of a point-to-point nature, there is no ambiguity even for 386 multicast and broadcast packets: these are unequivocally delivered to 387 the FA. The Link-layer Assisted Delivery Style allows for direct 388 delivery of unicast, multicast and broadcast packets over link-layers 389 that can support it. In particular, it requires that regardless of 390 whether the IP layer packet is unicast, broadcast or multicast, (1) 391 when sending from MN to FA, the FA unicast address always be used, 392 and (2) when sending from FA to MN, the MN unicast address always be 393 used. The FA advertises such capability per the extension defined 394 above, and the MN requests it in its registration request. 396 The LLADS imposes the least amount of tunneling overhead of the 397 delivery styles as it effectively uses the equivalent of direct 398 delivery for unicast, broadcast and multicast. It enables the MN to 399 deliver packets to the FA for the foreign agent to reverse tunnel 400 them back to the MN's home network. 402 However LLADS does not by itself allow the MN to deliver packets such 403 that the FA know whether or not it should reverse tunnel them, or 404 process them as local packets (e.g., perhaps forwarding them to local 405 services). Certain networks have the capability of enabling 406 additional context at the link-layer to effect different 407 classification and treatment of packets otherwise indistinguishable 408 at the IP layer, e.g., by establishing additional PDP contexts in 409 3GPP or additional service flows (and the corresponding CIDs) in 410 WiMAX networks. In such networks, it is possible for the MN and the 411 FA to establish additional context such that packets sent by the MN 412 to the FA are classified correctly upon arrival into either packets 413 meant for local consumption, or packets meant to be reverse tunneled. 414 In the absence of any IP layer differentiation (i.e., by sending 415 packets meant for local consumption with the MN's local care-of 416 address as source address), such link-layer mechanisms can provide 417 the necessary means for the FA to select the correct processing for 418 packets received from the MN. Such link-layer mechanisms, however, 419 are out of scope of this document. 421 6. Security Considerations 423 This draft does not introduce any security threats on the top of what 424 is defined in IP Mobility Protocol [RFC3344]. If included, the 425 Multicast-Broadcast Encapsulating Delivery Style extension MUST be 426 added after the MN-HA authentication extension and before the MN-FA 427 authentication extension, if present. 429 7. IANA Considerations 431 This document defines a new IP Mobility extension, as described in 432 Section 3.1 and uses a type . The Multicast-Broadcast 433 Encapsulation Delivery Extension type is assigned from the range of 434 values associated with the skippable IP Mobility extensions. 436 8. Acknowledgments 438 The authors like to thank Charlie Perkins, Alex Bachmutsky, De Juan 439 Huarte Federico, Parviz Yegani, Jayshree Bharatia for their comments 440 and contribution in shaping up this document. We also thank the 441 WiMAX Forum NWG members for their valuable input and suggestions 442 during the initial discussion of the problem. 444 9. References 446 9.1. Normative references 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 452 revised", RFC 3024, January 2001. 454 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 455 August 2002. 457 9.2. Informative references 459 [3GPP2] "3GPP2 - Third Generation Partnership Project 2: X.P0028- 460 200", Online web site http://www.3gpp2.org. 462 [NWG] "NWG - WiMAX Network Architecture Group", Online web 463 site http://www.wimaxforum.org. 465 Appendix A. Appendix-A 467 TBD. 469 Authors' Addresses 471 Ahmad Muhanna (Editor) 472 Ericsson Inc. 473 2201 Lakeside Blvd. 474 Richardson, TX 75082 475 USA 477 Email: ahmad.muhanna@ericsson.com 479 Basavaraj Patil 480 Nokia 481 6021 Connection Drive 482 Irving, TX 75039 483 USA 485 Email: basavaraj.patil@nokia.com 487 Samita Chakrabarti 488 IP Infusion 489 1188 Arquest Street 490 Sunnyvale, CA 491 USA 493 Email: samitac@ipinfusion.com 494 Gabriel Montenegro 495 Microsoft Corporation 496 One Microsoft Way 497 Redmond, WA 98052 498 USA 500 Email: gabriel.montenegro@microsoft.com 502 Yingzhe Wu 503 ZTE USA 504 10105 Pacific Heights Blvd, Suite 250 505 San Diego, CA 92121 506 USA 508 Email: yingzhe.wu@zteusa.com