One document matched: draft-chakrabarti-mip4-mcbc-02.xml
<?xml version="1.0"?>
<!--
RFC/Internet draft DTD:
RFC2629 with xml2rfc.tcl
<rfc number="XXXX" ipr="full3978">
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119" >
<!ENTITY % RFC3344 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3344" >
<!ENTITY % RFC3024 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3024" >
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119" >
<!ENTITY % RFC3041 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3041" >
<!ENTITY % RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972" >
<!ENTITY % RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971" >
<!ENTITY % RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460" >
<!ENTITY % RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775" >
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<rfc ipr="full3978">
<front>
<note title='Intended Status <To Be Removed Upon Publication>'>
<t>Intended status: Informational</t>
</note>
<title abbrev="Multicast IP Mobility">
IPv4 Mobility extension for Multicast and Broadcast Packets
</title>
<author initials="S" surname="Chakrabarti" fullname="Samita Chakrabarti">
<organization>Azaire Networks</organization>
<address>
<postal>
<street></street>
<city> </city>
<country></country>
</postal>
<email>samita.chakrabarti@azairenet.com</email>
</address>
</author>
<author initials="A" surname="Muhanna" fullname="Ahmad Muhanna">
<organization>Nortel Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>amuhanna@nortel.com</email>
</address>
</author>
<author initials="G" surname="Montenegro" fullname="Gabriel Montenegro">
<organization> Microsoft
</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>gabriel.montenegro@microsoft.com</email>
</address>
</author>
<author initials="A" surname="Bachmutsky" fullname="Alexander Bachmutsky">
<organization> Nokia Siemens Network
</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>alexander.bachmutsky@nsn.com</email>
</address>
</author>
<author initials="Y" surname="Wu" fullname="Yingzhe Wu">
<organization> Huawei
</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>ywu@huawei.com</email>
</address>
</author>
<author initials="B" surname="Patil" fullname="Basavaraj Patil">
<organization> Nokia Siemens Networks
</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>basavaraj.patil@nsn.com</email>
</address>
</author>
<author initials="P" surname="Yegani" fullname="Parviz Yegani">
<organization> Cisco Systems
</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>pyegani@cisco.com</email>
</address>
</author>
<date year="2007" />
<area>Internet</area>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
The <xref target="RFC3344">IP Mobility Protocol </xref>
describes multicast and broadcast packet transmission between the mobile
node and the home network or visited network.
<xref target="RFC3024">Reverse Tunneling for Mobile IP
</xref> 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, <xref target="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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="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 <xref target="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.
<xref target="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 <xref
target="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 <xref target="NWG"/>.
</t>
<t>
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.
</t>
<t>
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 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.
</t>
<t>
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.
</t>
<t>
Section 3 describes the new delivery extension for multicast-broadcast
messages in reverse tunnel mode.
</t>
</section>
<section title="Definition Of Terms">
<t>
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.
</t>
<t>
<list style="hanging">
<t hangText="MN"><vspace />
Mobile Node
</t>
<t hangText="FA"><vspace />
Foreign Agent
</t>
<t hangText="FA-COA"><vspace />
Foreign Agent as care-of-address.
</t>
</list>
</t>
</section>
<section title="Multicast-Broadcast Encapsulating Delivery Style">
<t>
The Mobile IP reverse tunneling <xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
If no delivery style extension is present,
Direct Delivery per RFC 3024 is assumed.
</t>
<artwork><![CDATA[
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.
]]></artwork>
<section title="Packet header formats for visited network traffic">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Packet header formats for homebound traffic">
<t>
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.
</t>
</section>
<t>
</t>
</section>
<section title="Multicast-Broadcast Encapsulating delivery Style Vs RFC3024 Encapsulating delivery">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Link-layer Assisted Delivery Style (LLADS)">
<t> 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.
</t>
<t>
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.
</t>
<t>
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 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.
</t>
</section>
<!--
<section title="Usage Examples">
<t> Text </t>
</section>
-->
<!--
<section title="Implementation Notes">
<t>
<list style="symbols">
<t>
A
</t>
<t>
B
</t>
<t>
C
</t>
</list>
</t>
</section>
-->
<section title="Security Considerations">
<t>
</t>
</section>
<section title="IANA Considerations">
<t>
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC3344;
&RFC3024;
</references>
<references title="Informative references">
<reference anchor="NWG">
<front>
<title>NWG - Wimax Network Architecture Group</title>
</front>
<seriesInfo name="Online web site" value="http://www.wimaxforum.org"/>
</reference>
<reference anchor="3GPP2">
<front>
<title>3GPP2 - Third Generation Partership Project 2: X.P0028-200 </title>
</front>
<seriesInfo name="Online web site" value="http://www.3gpp2.org"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:57:18 |