[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-mip4-mcbc

Network Working Group                                     S. Chakrabarti
Internet-Draft                                           Azaire Networks
Expires: May 18, 2008                                         A. Muhanna
                                                         Nortel Networks
                                                           G. Montenegro
                                                               Microsoft
                                                           A. Bachmutsky
                                                   Nokia Siemens Network
                                                                   Y. Wu
                                                                  Huawei
                                                                B. Patil
                                                  Nokia Siemens Networks
                                                               P. Yegani
                                                           Cisco Systems
                                                       November 15, 2007


      IPv4 Mobility extension for Multicast and Broadcast Packets
                     draft-chakrabarti-mip4-mcbc-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).



Chakrabarti, et al.       Expires May 18, 2008                  [Page 1]

Internet-Draft            Multicast IP Mobility            November 2007


Intended Status <To Be Removed Upon Publication>

   Intended status: Informational
















































Chakrabarti, et al.       Expires May 18, 2008                  [Page 2]

Internet-Draft            Multicast IP Mobility            November 2007


Abstract

   The IP Mobility Protocol [RFC3344] describes multicast and broadcast
   packet transmission between the mobile node and the home network or
   visited network.  Reverse Tunneling for Mobile IP [RFC3024] includes
   support for reverse tunneling of multicast and broadcast packets to
   the home network using the encapsulating delivery style between
   mobile nodes and the foreign agent.  However, [RFC3024] says that
   once the encapsulated delivery style is negotiated, all packets must
   be encapsulated.  In particular, this imposition prevents direct
   delivery of unicast packets.  This causes tunnel overhead in the
   (typically) wireless medium between the mobile and the foreign agent.
   This document removes this imposition It also provides alternatives
   of direct delivery of multicast-broadcast packets between a foreign
   agent and a mobile node if allowed by the underlying link-layer.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   3.  Multicast-Broadcast Encapsulating Delivery Style . . . . . . .  7
     3.1.  Packet header formats for visited network traffic  . . . .  8
     3.2.  Packet header formats for homebound traffic  . . . . . . .  9
   4.  Multicast-Broadcast Encapsulating delivery Style Vs
       RFC3024 Encapsulating delivery . . . . . . . . . . . . . . . . 10
   5.  Link-layer Assisted Delivery Style (LLADS) . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19
















Chakrabarti, et al.       Expires May 18, 2008                  [Page 3]

Internet-Draft            Multicast IP Mobility            November 2007


1.  Introduction

   [RFC3344] section 4.3 and 4.4 discusses multicast and broadcast
   routing to and from the mobile node in the presence of triangular
   routing and with a co-located Care-of-address.  Reverse tunneling for
   Mobile IP [RFC3024] uses the optimal direct delivery style from the
   mobile node via the foreign agent if only unicast traffic is being
   reverse tunneled.  If, however, multicast or broadcast packets are
   also meant to be reverse tunneled, it introduces the Encapsulating
   Delivery Style Unfortunately, once the encapsulated delivery style is
   negotiated, it applies to all reverse tunneling, including unicast.
   [RFC3344] also mandates that all multicast and broadcast packets
   should be delivered encapsulated from foreign agent to mobile-node.
   This imposes tunnel overhead for multicast and broadcast packets.
   While tunneling overhead on wired links may be acceptable, it has a
   higher cost and throughput impact in wireless links.  Even though,
   Mobile IP has been deployed for 3G data services, there has not been
   much usage of multicast or broadcast data transfer to or from the
   mobile node.  The Wimax Network Architecture [NWG] uses Mobile IP
   services as one of the mobility services which could be used for both
   Voice-over-IP and data.  In the future, PTT (Push-To-Talk) service
   may be popular and thus demands efficient usage of multicast delivery
   from the mobile to the network acess provider network.  Similary,
   IPTV may use multicast to distribute streaming media across high
   bandwidth wireless network such as Wimax [NWG].

   Moreover, neither RFC3344 nor RFC3024 clearly specify multicast/
   broadcast packet delivery for FA Care-of address; for example, for
   encapsulated delivery, the source address of the outer and inner IP
   header is the home address of the mobile (RFC3024, section 5.2.2),
   and section 5.4 talks about local delivery of multicast/broadcast
   packets in the visited network but some border cases are not
   completely specified.  In particular, multicast messages from the
   mobile node to the visited network may be needed for retrieving
   service information.  The all Mobility-agents multicast address is
   used for router solicitation by the mobile node, so foreign agent
   implementations must it as a special address.  This leads to
   complexity if in the reverse tunnel the mobile node uses its home
   address as the source address for other multicast messages destined
   to the home and visited network.

   Currently different organizations [3GPP2] define their own mechanism
   to obtain local information such as DNS server IP address through
   AAA.  All Mobility-agent multicast is used for router solicitation by
   the mobile and the implementation can treat this address specially at
   the foreign-agent.  However, the implementation of foreign agent
   needs to apply multicast-address filtering and gets very complex if
   the mobile client uses home-address as source address for other



Chakrabarti, et al.       Expires May 18, 2008                  [Page 4]

Internet-Draft            Multicast IP Mobility            November 2007


   multicast messages destined to the home and visited network, in the
   reverse tunnel mode.  Even if multicast packets are delivered
   locally, the return packet which will have destination address as the
   home-address will be dropped at foreign-agent as they are not coming
   from the reverse tunnel.  RFC3024 recommends selective reverse
   tunneling by delivering packets directly to foreign agent, while
   encapsulating them for reverse tunnel delivery.  But the
   specification is not clear about the source addresses of the packets
   from the mobile in case of selective direct-delivery.  Although it
   clearly states that for the mobile using co-located care-of-address.

   This document aims to clarify multicast messages with reverse
   tunneling, adds the capability of using encapsulated delivery only
   for multicast/broadcast packets from mobile to foreign agent (while
   allowing direct delivery for unicast), and explores direct delivery
   options of multicast messages between the mobile and the foreign
   agent by using link-layer capabilities.

   Section 3 describes the new delivery extension for multicast-
   broadcast messages in reverse tunnel mode.































Chakrabarti, et al.       Expires May 18, 2008                  [Page 5]

Internet-Draft            Multicast IP Mobility            November 2007


2.  Definition Of Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   MN
      Mobile Node

   FA
      Foreign Agent

   FA-COA
      Foreign Agent as care-of-address.





































Chakrabarti, et al.       Expires May 18, 2008                  [Page 6]

Internet-Draft            Multicast IP Mobility            November 2007


3.  Multicast-Broadcast Encapsulating Delivery Style

   The Mobile IP reverse tunneling [RFC3024] defines the Encapsulating
   delivery style for delivering multicast and broadcast packets from
   the mobile to the foreign agent in the FA-CoA mode.  It also mandates
   Encapsulating delivery mode for sending multicast/broadcast packets
   to reverse-tunnel to home agent via the foreign agent.  But RFC3024
   section 2 says that all reverse-tunneled traffic is encapsulated when
   Encapsulating Delivery is negotiated.  The "Multicast-Broadcast
   Encapsulating Delivery Style" (MBEDS) extension defined here applies
   encapsulation only to the reverse-tunneled multicast and broadcast
   packets, leaving direct delivery for reverse-tunneled unicast
   packets.  The main motivation for adding this extension is to save
   the overhead of additional IP header for unicast packets.  This
   procedure works for both shared media like ethernet, IEEE 802.11 and
   links of a point-to-point nature such as those defined by 3GPP, 3GPP2
   and IEEE 802.16.

   Foreign agents SHOULD support the Multicast-Broadcast Encapsulating
   Delivery Style Extension.  A registration request MAY include either
   a regular Encapsulating delivery extension (see section 3.3 in
   RFC3024) or a Multicast-Broadcast Encapsulating Delivery extension,
   but not both.  If both extensions are present, only the first
   extension will be taken into consideration and the second one will be
   skipped.

   If a foreign agent supports MBEDS, then the foreign agent SHOULD
   advertise the MBEDS extension int its router advertisement to inform
   the mobile about the type of delivery style it supports.  This will
   avoid the possiblity of multiple registration requests to figure out
   which encapsulating method the foreign agent supports.

   If the MN includes an MBEDS extension, if MUST do so after the
   Mobile-Home Authentication Extension, and before the Mobile-Foreign
   Authentication Extension, if present.  The Encapsulating Delivery
   Style Extension MUST NOT be included if the 'T' bit is not set in the
   Registration Request.

   If no delivery style extension is present, Direct Delivery per RFC
   3024 is assumed.











Chakrabarti, et al.       Expires May 18, 2008                  [Page 7]

Internet-Draft            Multicast IP Mobility            November 2007


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |    Bit-field Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type

         TBD

       Length

         2

       Value
         It is a 16-bit bit-field. Value specifies what type of packets are encapsulated.
         The following bits are defined (0 being the right-most bit, 15 the left-most bit):

         0 : All packets are encapsulated between a mobile node and a foreign agent. It is same
             as the Encapsulating Delivery Style in RFC3024. NOTE: obsolete EDS in 3024?
         1 : Only multicast and broadcast packets are encapsulated (MBEDS)
           2 : Link-layer Assisted Delivery Style (LLAS) for local network

        NOTE: Only MBEDS packets are reverse tunneled after being de-capsulated at
               the foreign agent, not those directly destined to the foreign-agent address
               or all mobility agent address. These are processed locally by the foreign agent.



3.1.  Packet header formats for visited network traffic

   Other than Mobile IP agent solicitation packets, There might be some
   multicast or broadcast packets meant for consumption at the visited
   network.  If the mobile node can acquire a local IP address, then it
   MUST direct deliver the multicast and broadcast traffic for local
   use.  If the mobile node can have only one IP address, (i.e. home
   address ) then it MUST send all the multicast and broadcast packets
   encapsulated.  These packets will be sent to the home network through
   the reverse tunnel after decapsulation at the foreign agent; only
   exceptions are the multicast solicitation messages for the mobility
   agent.

   In some cases, the mobile may want to send multicast or broadcast
   packets to visited network entities other than the foreign agent.  In
   those cases they should always be direct delivered by acquiring a
   local IP address or using link-layer mechanism if possible.  Please
   see the section 'Link-layer Assisted Delivery Style' below for
   details.




Chakrabarti, et al.       Expires May 18, 2008                  [Page 8]

Internet-Draft            Multicast IP Mobility            November 2007


3.2.  Packet header formats for homebound traffic

   The packet format and processing for encapsulated multicast and
   broadcast traffic is the same as defined in section 5.2 of Mobile IP
   Reverse tunnel document.














































Chakrabarti, et al.       Expires May 18, 2008                  [Page 9]

Internet-Draft            Multicast IP Mobility            November 2007


4.  Multicast-Broadcast Encapsulating delivery Style Vs RFC3024
    Encapsulating delivery

   RFC3024 encapsulating delivery style does not require the foreign-
   agent to advertise an extension as well for the mobile node
   efficiency.  MBEDS provides an option for foreign agent to advertise
   the extension with supported extension types, so that a mobile node
   can request a delivery style that the foreign agent supports.

   RFC3024 encapsulating delivery style requires all multicast,
   broadcast and unicast traffic to be encapsulated in order to be
   reverse tunneled.  In MBEDS unicast packets are always direct
   delivered to the foreign-agent.  Most of the the cases a node sends
   unicast packets for communication with a correspondent node and
   occassionally it may send broadcast or multicast packets to the home
   network.  Thus this new style of delivery relieves the overhead of
   encapsulation for most traffic.

   MBEDS introduces TLV style extension for delivery style.  Therefore,
   this extension can be used to negotiate different delivery styles in
   the future.  Currently, it can be backward compatible with RFC3024
   encapsulating delivery style when the value field is zero.  NOTE: We
   should make this a bit field to allow for easier advertisement and
   other extensions.

   A mobile node SHOULD use either RFC3024 style encapsulating delivery
   extension or the MBEDS extension (defined in this document), but not
   both at the same time.  If both extensions are received at the
   foreign-agent, it sends an error (70) in the registration reply
   message.  On the other hand, a foreign-agent MUST not send both old
   and new extensions at the same time with the registration request.




















Chakrabarti, et al.       Expires May 18, 2008                 [Page 10]

Internet-Draft            Multicast IP Mobility            November 2007


5.  Link-layer Assisted Delivery Style (LLADS)

   This section discusses direct-delivery of multicast and broadcast
   packets between the mobile node and the foreign agent by taking
   advantage of link-layer mechanisms.  Certain link-layers allow for
   direct delivery from the MN to the FA (and viceversa) without the
   need for encapsulation.  In effect, this is assumed by RFC 3024 for
   Direct Delivery Style.  In this mode, a unicast packet at the IP
   layer is carried over a unicast link-layer delivery mechanism.  For
   example, the FA's MAC address is the link-layer destination address,
   or the packet is sent on a link of a point-to-point nature as in 3G
   or WiMAX networks.  Broadcast and multicast packets, however are
   typically sent using a link-layer broadcast or multicast mechanism: a
   broadcast or multicast MAC address for IEEE 802.11 networks.  If,
   however, these packets had the FA unicast MAC address while carrying
   an IP layer broadcast or multicast destination, then there would be
   no need for encapsulation to remove the ambiguity.  The packet would
   be unequivocally directed at, and consumed by the FA.  Notice that in
   links of a point-to-point nature, there is no ambiguity even for
   multicast and broadcast packets: these are unequivocally delivered to
   the FA.  The Link-layer Assisted Delivery Style allows for direct
   delivery of unicast, multicast and broadcast packets over link-layers
   that can support it.  In particular, it requires that regardless of
   whether the IP layer packet is unicast, broadcast or multicast, (1)
   when sending from MA to FA, the FA unicast address always be used,
   and (2) when sending from FA to MN, the MN unicast address always be
   used.  The FA advertises such capability per the extension defined
   above, and the MN requests it in its registration request.

   The LLADS imposes the least amount of tunneling overhead of the
   delivery styles as it effectively uses the equivalent of direct
   delivery for unicast, broadcast and multicast.  It enables the MN to
   deliver packets to the FA for the foreign agent to reverse tunnel
   them back to the MN's home network.

   However LLADS does not by itself allow the MN to deliver packets such
   that the FA know whether or not it should reverse tunnel them, or
   process them as local packets (e.g., perhaps forwarding them to local
   services).  Certain networks have the capability of enabling
   additional context at the link-layer to effect different
   classification and treatment of packets otherwise indistinguishable
   at the IP layer, e.g., by establishing additional PDP contexts in
   3GPP or additional service flows (and the corresponding CIDs) in
   WiMAX networks.  In such networks, it is possible for the MN and the
   FA to establish additional context such that packets sent by the MN
   to the FA are classified correctly upon arrival into either packets
   meant for local consumption, or packets meant to be reverse tunneled.
   In the absence of any IP layer differentiation (i.e., by sending



Chakrabarti, et al.       Expires May 18, 2008                 [Page 11]

Internet-Draft            Multicast IP Mobility            November 2007


   packets meant for local consumption with the MN's local care-of
   address as source address), such link-layer mechanisms can provide
   the necessary means for the FA to select the correct processing for
   packets received from the MN.  Such link-layer mechanisms, however,
   are out of scope of this document.














































Chakrabarti, et al.       Expires May 18, 2008                 [Page 12]

Internet-Draft            Multicast IP Mobility            November 2007


6.  Security Considerations


















































Chakrabarti, et al.       Expires May 18, 2008                 [Page 13]

Internet-Draft            Multicast IP Mobility            November 2007


7.  IANA Considerations


















































Chakrabarti, et al.       Expires May 18, 2008                 [Page 14]

Internet-Draft            Multicast IP Mobility            November 2007


8.  Acknowledgments

   The authors like to thank Charlie Perkins, De Juan Huarte Federico,
   Parviz Yeghani, Jayshree Bharatia for their comments and contribution
   in shaping up this document.  We also thank the Wimax Forum NWG
   members for their valuable input and suggestions for the intial
   discussion of the problem.  Thanks to Prakash Iyer for approving this
   work for Wimax forum.











































Chakrabarti, et al.       Expires May 18, 2008                 [Page 15]

Internet-Draft            Multicast IP Mobility            November 2007


9.  References

9.1.  Normative references

   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

9.2.  Informative references

   [3GPP2]    "3GPP2 - Third Generation Partership Project 2: X.P0028-
              200", Online web site http://www.3gpp2.org.

   [NWG]      "NWG - Wimax Network Architecture Group", Online web
              site http://www.wimaxforum.org.


































Chakrabarti, et al.       Expires May 18, 2008                 [Page 16]

Internet-Draft            Multicast IP Mobility            November 2007


Authors' Addresses

   Samita Chakrabarti
   Azaire Networks


   Email: samita.chakrabarti@azairenet.com


   Ahmad Muhanna
   Nortel Networks


   Email: amuhanna@nortel.com


   Gabriel Montenegro
   Microsoft


   Email: gabriel.montenegro@microsoft.com


   Alexander Bachmutsky
   Nokia Siemens Network


   Email: alexander.bachmutsky@nsn.com


   Yingzhe Wu
   Huawei


   Email: ywu@huawei.com


   Basavaraj Patil
   Nokia Siemens Networks


   Email: basavaraj.patil@nsn.com









Chakrabarti, et al.       Expires May 18, 2008                 [Page 17]

Internet-Draft            Multicast IP Mobility            November 2007


   Parviz Yegani
   Cisco Systems


   Email: pyegani@cisco.com














































Chakrabarti, et al.       Expires May 18, 2008                 [Page 18]

Internet-Draft            Multicast IP Mobility            November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Chakrabarti, et al.       Expires May 18, 2008                 [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/