idnits 2.17.1 draft-chakrabarti-mip4-mcbc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- 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 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 (July 08, 2009) is 5405 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) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Muhanna (Ed.) 3 Internet-Draft Nortel 4 Intended status: Standards Track S. Chakrabarti 5 Expires: January 9, 2010 IP Infusion 6 G. Montenegro 7 Microsoft Corporation 8 Y. Wu 9 ZTE USA 10 B. Patil 11 Nokia 12 July 08, 2009 14 IPv4 Mobility Extension for Multicast and Broadcast Packets 15 draft-chakrabarti-mip4-mcbc-04.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 9, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This specification defines a new Mobile IPv4 extension which is used 54 to negotiate the Multicast-Broadcast Encapsulation Delivery style in 55 the case of Mobile IPv4 Foreign Agent Care-of Address mode 56 registration. This mechanism allows the mobile node to negotiate 57 which type of traffic to be delivered encapsulated to the foreign 58 agent while delivering other types of IP packets using direct 59 delivery style. In particular, this mechanism gives the flexibility 60 to eliminate tunnel overhead in the (typically) wireless medium 61 between the mobile node and the foreign agent. In addition to the 62 reduced overhead, the new mechanism makes many multicast and 63 broadcast services available to the mobile node in a much more 64 deterministic and efficient way. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 70 2.1. Conventions used in this document . . . . . . . . . . . . 5 71 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Multicast-Broadcast Encapsulating Delivery Style . . . . . . . 6 73 3.1. Multicast-Broadcast Encapsulating Delivery Extension . . . 6 74 3.2. Packet Header Formats for Visited Network Traffic . . . . 8 75 3.3. Packet Header Formats for Homebound Traffic . . . . . . . 9 76 4. Multicast-Broadcast Encapsulating delivery Style Vs 77 RFC3024 Encapsulating delivery . . . . . . . . . . . . . . . . 9 78 5. Link-layer Assisted Delivery Style (LLADS) . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative references . . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative references . . . . . . . . . . . . . . . . . . 11 85 Appendix A. Appendix-A . . . . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The IP Mobility Protocol [RFC3344] describes multicast and broadcast 91 packet transmission between the mobile node and the home network or 92 visited network. Reverse Tunneling for Mobile IP [RFC3024] includes 93 support for reverse tunneling of multicast and broadcast packets to 94 the home network using the encapsulating delivery style between the 95 mobile nodes and the foreign agent. However, [RFC3024] says that 96 once the encapsulated delivery style is negotiated, all packets 97 exchanged between the mobile node and the foreign agent must be 98 delivered encapsulated. In particular, this imposition prevents 99 direct delivery of unicast packets from the mobile node to the 100 foreign agent. This causes a huge tunnel overhead in the (typically) 101 wireless medium between the mobile node and the foreign agent and 102 indirectly makes it impossible for the mobile node to use any of the 103 multicast and broadcast services. 105 Additionally, [RFC3344] sections 4.3 and 4.4 discusses multicast and 106 broadcast routing to and from the mobile node in the presence of 107 triangular routing and with a co-located Care-of address. Reverse 108 tunneling for Mobile IP [RFC3024] uses the optimal direct delivery 109 style from the mobile node via the foreign agent if only unicast 110 traffic is being reverse tunneled. If, however, multicast or 111 broadcast packets are also meant to be reverse tunneled, it 112 introduces the Encapsulating Delivery Style. Unfortunately, once the 113 encapsulating delivery style is negotiated, it applies to all reverse 114 tunneling traffics, including unicast. [RFC3344] also mandates, in 115 the case of FA Care-of Address mode, that all multicast and broadcast 116 packets be delivered encapsulated to mobile node. This also imposes 117 tunnel overhead for multicast and broadcast packets. While tunneling 118 overhead on wired links may be acceptable, it has a higher cost and 119 throughput impact in wireless links. Even though, Mobile IP has been 120 deployed for 3G data services, there has not been much usage of 121 multicast or broadcast data transfer to or from the mobile node. The 122 Wimax Network Architecture [NWG] uses Mobile IP services as one of 123 the mobility services which could be used for both Voice-over-IP and 124 data. In the future, PTT (Push-To-Talk) service may be popular and 125 thus demands efficient usage of multicast delivery from the mobile 126 node to the access network. Similarly, IPTV may use multicast to 127 distribute streaming media across high bandwidth wireless network 128 such as Wimax [NWG]. 130 Moreover, neither [RFC3344] nor [RFC3024] clearly specify multicast/ 131 broadcast packet delivery for FA Care-of address; for example, for 132 encapsulating delivery style, the source address of the outer and 133 inner IP header is the home address of the mobile node as described 134 in section 5.2.2 of [RFC3024]. In addition, section 5.4 talks about 135 local delivery of multicast/broadcast packets in the visited network 136 but some boarder cases are not completely specified. In particular, 137 multicast messages from the mobile node to the visited network may be 138 needed for retrieving service information. The all Mobility-agents 139 multicast address is used for router solicitation by the mobile node, 140 so foreign agent implementations must use it as a special address. 141 This leads to complexity if in the reverse tunnel the mobile node 142 uses its home address as the source address for other multicast 143 messages destined to the home and visited network. 145 Currently different organizations [3GPP2] define their own mechanism 146 to obtain local information such as DNS server IP address through 147 AAA. All Mobility-agent multicast is used for router solicitation by 148 the mobile node and the implementation can treat this address 149 specially at the foreign agent. However, the implementation of 150 foreign agent needs to apply multicast-address filtering and gets 151 very complex if the mobile client uses the home address as source 152 address for other multicast messages destined to the home and visited 153 network, in the reverse tunnel mode. Even if multicast packets are 154 delivered locally, the return packet which has the destination 155 address as the home address will be routed back all the way to the 156 home agent of the mobile node to be tunneled back to the foreign 157 agent and then to the mobile node. [RFC3024] recommends selective 158 reverse tunneling by delivering packets directly to the foreign 159 agent, while encapsulating them for reverse tunnel delivery. But the 160 specification is not clear about the source addresses of the packets 161 from the mobile node in case of selective direct delivery. Although 162 it clearly states that for the mobile node which uses co-located 163 care-of address mode. 165 This specification aims to clarify the delivery of multicast messages 166 when reverse tunneling is used, adds the capability to selectively 167 negotiates which type of traffic to be delivered using encapsulating 168 delivery, e.g., only for multicast and broadcast packets from mobile 169 node to foreign agent, while allowing direct delivery for other type 170 of traffic, e.g., unicast, and explores direct delivery options of 171 multicast messages between the mobile node and the foreign agent by 172 using link-layer capabilities. 174 Section 3 describes the new delivery extension for multicast- 175 broadcast packets in reverse tunnel mode. 177 2. Conventions & Terminology 179 2.1. Conventions used in this document 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 2.2. Terminology 187 All the general mobility related terminology and abbreviations are to 188 be interpreted as defined in IP Mobility Protocol [RFC3344] and 189 Reverse tunneling for Mobile IP [RFC3024]. The following terms are 190 used in this document. 192 MN 194 Mobile Node. 196 FA 198 Foreign Agent. 200 FA-CoA 202 Foreign Agent as the Mobile Node Care-of Address. 204 3. Multicast-Broadcast Encapsulating Delivery Style 206 The Mobile IP reverse tunneling [RFC3024] defines the Encapsulating 207 delivery style for delivering multicast and broadcast packets from 208 the mobile node to the foreign agent in the FA-CoA mode. It also 209 mandates Encapsulating delivery mode for sending multicast/broadcast 210 packets to reverse-tunnel to home agent via the foreign agent. But 211 [RFC3024] section 2 says that all reverse-tunneled traffic is 212 encapsulated when Encapsulating Delivery is negotiated. The 213 "Multicast-Broadcast Encapsulating Delivery Style" (MBEDS) extension 214 defined in this specification applies encapsulation only to the 215 reverse-tunneled multicast and broadcast packets, leaving direct 216 delivery for reverse-tunneled unicast packets. The main motivation 217 for adding this extension is to save the overhead of additional IP 218 header for unicast packets which consequently will enable the use of 219 Multicast and Broadcast packets when Mobile IPv4 is in use. This 220 procedure works for both shared media like ethernet, IEEE 802.11 and 221 links of a point-to-point nature such as those defined by 3GPP, 3GPP2 222 and IEEE 802.16. 224 3.1. Multicast-Broadcast Encapsulating Delivery Extension 226 The proposed extension is used in Mobile IPv4 signaling to negotiate 227 the Multicast-Broadcast Encapsulation Delivery Style. Foreign agents 228 SHOULD support the Multicast-Broadcast Encapsulating Delivery Style 229 Extension. A registration request MAY include either a regular 230 encapsulating delivery extension (see section 3.3 in [RFC3024]) or a 231 Multicast-Broadcast Encapsulating Delivery extension, but not both. 232 If both extensions are present, the foreign agent will consider that 233 an error scenario and the FA MUST reject the registration request by 234 sending a registration reply with the code field set to "Poorly 235 Formed Request". 237 If a foreign agent supports MBEDS, then the foreign agent SHOULD 238 advertise the MBEDS extension in its router advertisement to inform 239 the mobile node about the type of delivery style it supports. This 240 will avoid the possibility of multiple registration requests to 241 figure out which encapsulating mode the foreign agent supports. 243 If the MN includes an MBEDS extension, if MUST do so after the 244 Mobile-Home Authentication Extension, and before the Mobile-Foreign 245 Authentication Extension, if present. The Encapsulating Delivery 246 Style Extension MUST NOT be included if the 'T' bit is not set in the 247 Registration Request. 249 If no delivery style extension is present, Direct Delivery per RFC 250 3024 is assumed. 252 The Multicast-Broadcast Encapsulation Extension format is as in 253 Figure 1 below. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | Bit-field Value | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 1: Multicast-Broadcast Encapsulating Extension 263 Type 265 267 Length 269 8-bit unsigned integer indicating the length in octets of the Bit- 270 Field . It is set to 2. 272 Bit-Field Value 274 A 16-bit bit-field. Value specifies what type of packets are 275 encapsulated. The following bits are defined (0 being the right- 276 most bit, 15 the left-most bit): 278 0: 280 All packets are encapsulated between a mobile node and a 281 foreign agent. It is same as the Encapsulating Delivery Style 282 in RFC3024. NOTE: obsolete EDS in 3024?. 284 1: 286 Only multicast and broadcast packets are encapsulated (MBEDS). 288 2: 290 Link-layer Assisted Delivery Style (LLAS) for local network. 292 All other bits values are reserved. 294 NOTE: Only MBEDS packets are reverse tunneled after being 295 decapsulated at the foreign agent, not those directly destined to the 296 foreign-agent address or all mobility agent address. These are 297 processed locally by the foreign agent. 299 3.2. Packet Header Formats for Visited Network Traffic 301 Other than Mobile IP agent solicitation packets, there might be some 302 multicast or broadcast packets meant for consumption at the visited 303 network. If the mobile node can acquire a local IP address, then it 304 MUST direct deliver the multicast and broadcast traffic for local 305 use. If the mobile node can have only one IP address, (i.e. home 306 address) then it MUST send all the multicast and broadcast packets 307 encapsulated. These packets will be sent to the home network through 308 the reverse tunnel after being decapsulated at the foreign agent; 309 only exceptions are the multicast solicitation messages for the 310 mobility agent. 312 In some cases, the mobile node may want to send multicast or 313 broadcast packets to visited network entities other than the foreign 314 agent. In those cases they should always be direct delivered by 315 acquiring a local IP address or using link-layer mechanism if 316 possible. Please see the section 'Link-layer Assisted Delivery 317 Style' below for details. 319 3.3. Packet Header Formats for Homebound Traffic 321 The packet format and processing for encapsulated multicast and 322 broadcast traffic is the same as defined in section 5.2 of Reverse 323 Tunneling for Mobile IP [RFC3024]. Additionally, the packet format 324 and processing for unicast traffic is the same as defined in section 325 5.1 of the same specification. 327 4. Multicast-Broadcast Encapsulating delivery Style Vs RFC3024 328 Encapsulating delivery 330 RFC3024 encapsulating delivery style does not require the foreign- 331 agent to advertise an extension as well for the mobile node 332 efficiency. MBEDS provides an option for foreign agent to advertise 333 the extension with supported extension types, so that a mobile node 334 can request a delivery style that the foreign agent supports. 336 RFC3024 encapsulating delivery style requires all multicast, 337 broadcast and unicast traffic to be encapsulated in order to be 338 reverse tunneled. In MBEDS unicast packets are always direct 339 delivered to the foreign agent. Most of the the cases a node sends 340 unicast packets for communication with a correspondent node and 341 occasionally it may send broadcast or multicast packets to the home 342 network. Thus this new style of delivery relieves the overhead of 343 encapsulation for most traffic. 345 MBEDS introduces TLV style extension for delivery style. Therefore, 346 this extension can be used to negotiate different delivery styles in 347 the future. Currently, it can be backward compatible with RFC3024 348 encapsulating delivery style when the value field is zero. NOTE: We 349 should make this a bit field to allow for easier advertisement and 350 other extensions. 352 A mobile node SHOULD use either RFC3024 style encapsulating delivery 353 extension or the MBEDS extension (defined in this document), but not 354 both at the same time. If both extensions are received at the 355 foreign-agent, the foreign agent MUST reject the registration request 356 by sending a registration reply with error (70) "Poorly Formed 357 Request". 359 5. Link-layer Assisted Delivery Style (LLADS) 361 This section discusses direct-delivery of multicast and broadcast 362 packets between the mobile node and the foreign agent by taking 363 advantage of link-layer mechanisms. Certain link-layers allow for 364 direct delivery from the MN to the FA (and vice-versa) without the 365 need for encapsulation. In effect, this is assumed by RFC 3024 for 366 Direct Delivery Style. In this mode, a unicast packet at the IP 367 layer is carried over a unicast link-layer delivery mechanism. For 368 example, the FA's MAC address is the link-layer destination address, 369 or the packet is sent on a link of a point-to-point nature as in 3G 370 or WiMAX networks. Broadcast and multicast packets, however are 371 typically sent using a link-layer broadcast or multicast mechanism: a 372 broadcast or multicast MAC address for IEEE 802.11 networks. If, 373 however, these packets had the FA unicast MAC address while carrying 374 an IP layer broadcast or multicast destination, then there would be 375 no need for encapsulation to remove the ambiguity. The packet would 376 be unequivocally directed at, and consumed by the FA. Notice that in 377 links of a point-to-point nature, there is no ambiguity even for 378 multicast and broadcast packets: these are unequivocally delivered to 379 the FA. The Link-layer Assisted Delivery Style allows for direct 380 delivery of unicast, multicast and broadcast packets over link-layers 381 that can support it. In particular, it requires that regardless of 382 whether the IP layer packet is unicast, broadcast or multicast, (1) 383 when sending from MN to FA, the FA unicast address always be used, 384 and (2) when sending from FA to MN, the MN unicast address always be 385 used. The FA advertises such capability per the extension defined 386 above, and the MN requests it in its registration request. 388 The LLADS imposes the least amount of tunneling overhead of the 389 delivery styles as it effectively uses the equivalent of direct 390 delivery for unicast, broadcast and multicast. It enables the MN to 391 deliver packets to the FA for the foreign agent to reverse tunnel 392 them back to the MN's home network. 394 However LLADS does not by itself allow the MN to deliver packets such 395 that the FA know whether or not it should reverse tunnel them, or 396 process them as local packets (e.g., perhaps forwarding them to local 397 services). Certain networks have the capability of enabling 398 additional context at the link-layer to effect different 399 classification and treatment of packets otherwise indistinguishable 400 at the IP layer, e.g., by establishing additional PDP contexts in 401 3GPP or additional service flows (and the corresponding CIDs) in 402 WiMAX networks. In such networks, it is possible for the MN and the 403 FA to establish additional context such that packets sent by the MN 404 to the FA are classified correctly upon arrival into either packets 405 meant for local consumption, or packets meant to be reverse tunneled. 406 In the absence of any IP layer differentiation (i.e., by sending 407 packets meant for local consumption with the MN's local care-of 408 address as source address), such link-layer mechanisms can provide 409 the necessary means for the FA to select the correct processing for 410 packets received from the MN. Such link-layer mechanisms, however, 411 are out of scope of this document. 413 6. Security Considerations 415 This draft does not introduce any security threats on the top of what 416 is defined in IP Mobility Protocol [RFC3344]. If included, the 417 Multicast-Broadcast Encapsulating Delivery Style extension MUST be 418 added after the MN-HA authentication extension and before the MN-FA 419 authentication extension, if present. 421 7. IANA Considerations 423 This document defines a new IP Mobility extension, as described in 424 Section 3.1 and uses a type . The Multicast-Broadcast 425 Encapsulation Delivery Extension type is assigned from the range of 426 values associated with the skippable IP Mobility extensions. 428 8. Acknowledgments 430 The authors like to thank Charlie Perkins, Alex Bachmutsky, De Juan 431 Huarte Federico, Parviz Yegani, Jayshree Bharatia for their comments 432 and contribution in shaping up this document. We also thank the 433 Wimax Forum NWG members for their valuable input and suggestions for 434 the intial discussion of the problem. Thanks to Prakash Iyer for 435 approving this work for Wimax forum. 437 9. References 439 9.1. Normative references 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 445 revised", RFC 3024, January 2001. 447 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 448 August 2002. 450 9.2. Informative references 452 [3GPP2] "3GPP2 - Third Generation Partnership Project 2: X.P0028- 453 200", Online web site http://www.3gpp2.org. 455 [NWG] "NWG - Wimax Network Architecture Group", Online web 456 site http://www.wimaxforum.org. 458 Appendix A. Appendix-A 460 TBD. 462 Authors' Addresses 464 Ahmad Muhanna (Editor) 465 Nortel Networks 466 2221 Lakeside Blvd. 467 Richardson, TX 75082 468 USA 470 Email: amuhanna@nortel.com 472 Samita Chakrabarti 473 IP Infusion 474 1188 Arquest Street 475 Sunnyvale, CA 476 USA 478 Email: samitac@ipinfusion.com 480 Gabriel Montenegro 481 Microsoft Corporation 482 One Microsoft Way 483 Redmond, WA 98052 484 USA 486 Email: gabriel.montenegro@microsoft.com 488 Yingzhe Wu 489 ZTE USA 490 10105 Pacific Heights Blvd, Suite 250 491 San Diego, CA 92121 492 USA 494 Email: yingzhe.wu@zteusa.com 495 Basavaraj Patil 496 Nokia 497 6021 Connection Drive 498 Irving, TX 75039 499 USA 501 Email: basavaraj.patil@nokia.com