One document matched: draft-lee-xcast-mobileip-01.txt
Differences from draft-lee-xcast-mobileip-00.txt
INTERNET-DRAFT Jiwoong Lee
Expires: July 2003 KTF Advanced Lab
17 January 2003
Explicit Multicast over Mobile IP (XMIP)
<draft-lee-xcast-mobileip-01.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and 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 obsolete by other documents
at anytime. 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.
All remarks may be forwarded to author's email address or to Xcast
IG(Incubation Group) homepage
http://www.xcast-ig.org.
Abstract
As a special kind of Internet multicast, Explicit
multicast(Xcast)[1] encodes destination addresses of all the
receivers into the packet. Not requiring membership management and
routing information exchange in the intermediate routers in
contrast to the legacy Internet multicast or Deering multicast,
Xcast can effectively provide multicast service to Internet without
those overheads. A node mobility supporting protocol, Mobile
IP[2,3], requires to be modified to appropriately intercept, route
and forward Xcast packets. This document specifies the protocol
Jiwoong Lee Expire July 2003 [Page 1]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
operations for the mobile agent, the mobile node and the
correspondent node to support transmission and reception of Xcast
datagram over Mobile IPv4 and Mobile IPv6.
Table of Contents
Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . 1
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Xcast over Mobile IP . . . . . . . . . . . . . . . . 4
3. Protocol operations in Mobile IPv4 . . . . . . . . . . . . . . . 5
3.1. Home agent operations . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Requirement for reception . . . . . . . . . . . . . . . . . . 6
3.1.2. Home agent specific Xcast Routing . . . . . . . . . . . . . . 6
3.1.3. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Foreign agent operations . . . . . . . . . . . . . . . . . . . 7
3.3. Mobile node operations . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Receiving Xcast packets . . . . . . . . . . . . . . . . . . . 8
3.3.2. Sending Xcast packets . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Handling packets with Anonymity bit . . . . . . . . . . . . . 8
4. Protocol Operations over Mobile IPv6 . . . . . . . . . . . . . . 8
4.1. Home agent operations . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Requirement for link-local scope multicast packet . . . . . . 9
4.1.2. Home agent specific Xcast routing . . . . . . . . . . . . . . 9
4.1.3. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Mobile node operations . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Receiving Xcast packets while away from home . . . . . . . . 10
4.2.2. Handling packets with Anonymity bit . . . . . . . . . . . . . 11
4.2.3. Sending Binding Update . . . . . . . . . . . . . . . . . . . 11
4.2.4. Sending Xcast packets while away from home . . . . . . . . . 12
4.3. Correspondent node operations . . . . . . . . . . . . . . . . . 12
4.3.1. Binding update in Xcast packets . . . . . . . . . . . . . . . 12
4.3.2. Sending Xcast packets . . . . . . . . . . . . . . . . . . . . 12
4.4. Xcast node considerations . . . . . . . . . . . . . . . . . . . 13
4.4.1. General Xcast routing requirement . . . . . . . . . . . . . . 13
5. Security considerations . . . . . . . . . . . . . . . . . . . . . 13
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Jiwoong Lee Expire July 2003 [Page 2]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
A. Compatibility statements . . . . . . . . . . . . . . . . . . . . 14
B. Xcast header format . . . . . . . . . . . . . . . . . . . . . . . 14
C. Changes from Previous Version of the Draft . . . . . . . . . . . 15
D. Future works . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Explicit multicast (Xcast)[1] is a new kind of Internet multicast
that has different genealogy from the traditional multicast schemes
- the host group model multicast, which is based on RFC 1112[5].
Instead of being addressed to a group-specific multicast address,
Xcast packets are addressed to a pre-defined link-local multicast
address, named 'All_Xcast_Routers' for hop-by-hop forwarding and
carries unicast addresses of destinations within themselves. Since
Xcast routing is based neither on multicast address nor pre-
established multicast routing table but solely on unicast addresses
of destinations, Xcast utilizes the existing unicast routing
information and does not require routing/group management
information exchange, which are required in the host group model
based multicast.
As wireless market grows, the mobility of the Internet node is more
getting its importance. Mobile IP[2,3] is one emerging technology
that supports the Internet node mobility. Mobile IP operations
rely on binding of care-of address, intercepting and tunneling of
packets.
Mobile IP is designed to support unicast, the host group model
multicast and, if applied, broadcast, and it currently does not
support Explicit multicast.
This document is designed for the purpose of seamless support of
Xcast over Mobile IP. The mobile agent, the mobile node and the
correspondent node require new protocol operations. Some
requirements specified in this document update Mobile IP
specification[2,3].
Section 2 overviews the protocol including node behavior. Section
3 and section 4 describes the specific protocol operations of the
nodes in Mobile IPv4 network and in Mobile IPv6 network
respectively.
Jiwoong Lee Expire July 2003 [Page 3]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
1.1. Terminology
The keywords "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[10].
In addition, this document frequently uses the following terms:
Xcast Explicit Multicast.
Xcast6 Xcast in IPv6.
Mobile IP Mobile IPv4 and/or Mobile IPv6
List of Addresses
A field of the Xcast header format carrying
the unicast addresses of the recipients
Type Xcast Routing extension header
A Routing extension header for Xcast6
containing List of Addresses
Type 2 Routing extension header
A Routing extension header used when a
correspondent node directly forwards a packet
to a mobile node in Mobile IPv6 as a way of
routing optimization.
Xcast extension information
Xcast4 header in IPv4 and Xcast6 header in
IPv6. An Xcast6 header consists of a type
Xcast Routing extension header and, if any,
a type Ports Destination extension header and
a Type 2 Routing extension header.
Xcast encapsulation
Xcast encapsulation within Xcast or Xcast
encapsulation within Unicast. This is defined
in [9].
The definitions of terms that are not defined here can be found at
references at the end.
2. Overview of Xcast over Mobile IP
An Xcast-capable home agent receives Xcast packets on behalf of its
registered mobile nodes. Since Xcast packets are addressed to a
Jiwoong Lee Expire July 2003 [Page 4]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
predefined link-local multicast address, the home agent MUST be
able to intercept such packets and tunnel them to the registered
mobile nodes. While generic Xcast routers perform their Xcast
routing over the addresses shown in List of Addresses field of the
Xcast packets, Xcast-capable home agents work in a different manner
- in a special manner to home agents.
The home agent first looks up the care-of addresses that are bound
with the (home) addresses listed in the intercepted Xcast packet.
Next it determines the next forwarding hop to each care-of address
by using its unicast routing information. The home agent partitions
the set of care-of addresses based on the next hops. With this
result, the home agent replicates the intercepted Xcast packet and
tunnels them such that
- List of Addresses of each tunnel header carries a set of
partitioned care-of addresses.
- List of Addresses of each inner header carries a set of home
addresses which are shown in the original incoming Xcast
packet and which are bound with the care-of addresses shown
the packet's tunnel header.
That is, the home agent performs Xcast-in-Xcast encapsulation [9]
based on its mobility binding information.
In addition, Xcast over Mobile IPv6 prohibits a correspondent node
from using Type 2 Routing Extension Header as a mean of routing
optimization. For the goal of routing optimization, the
correspondent node MUST use Xcast-in-Xcast encapsulation, or Xcast-
in-Unicast encapsulation.
The specific protocol operations in Mobile IPv4 and Mobile IPv6 are
described in following sections.
3. Protocol operations in Mobile IPv4
A mobile node in Mobile IPv4 registers either a foreign agent care-
of address or a co-located care-of address with its home agent
while away from home. A mobile node who has registered a foreign
agent care-of address is not directly reachable from the outside of
the foreign network and is only reachable via the home agent-
foreign agent forward tunnel, while a mobile node who has
registered a co-located care-of address is directly reachable from
the outside of the foreign network with its care-of address.
If a mobile node joins an Xcast session using its home address,
Jiwoong Lee Expire July 2003 [Page 5]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
Xcast packets belonging to the session will reach its home agent
while the mobile node is away from home. Each packet carries the
home addresses of the mobile nodes in List of Address field.
The mobile node, its home agent, and, if registered, its foreign
agent require following protocol operations to appropriately handle
Xcast packets heading for the mobile node.
3.1. Home agent operations
3.1.1. Requirement for reception
If an Xcast-capable home agent has at least one mobility binding
for a mobile node, it MUST receive any Xcast packet addressed to
All_Xcast_Routers (defined in [1]) to see if it is addressed to at
least one home address of the registered mobile nodes.
3.1.2. Home agent specific Xcast Routing
When a home agent receives an arriving Xcast packet that is
addressed to the registered mobile nodes, it performs the following
operations over those addresses.
The home agent MUST route the Xcast packet based on the care-of
addresses which are bound with the home addresses; it determines
the appropriate next hops to forward any unicast packet (and
thereby the Xcast packet) to the care-of addresses. Next it
partitions the home addresses based on the just-found next hops
just found and creates Xcast packets such that
- one packet per next hop is created
- the packet is addressed to a subset of the listed home
addresses, which is composed by partitioning process based on
the same next hop.
If the home agent supports simultaneous bindings for one home
address, it MUST include all the bound care-of addresses in Xcast
routing process. As a result, the home agent can create plural
Xcast packets that carry the same home address in their List of
Addresses fields.
If only one address is left for a next hop, the home agent MAY
perform X-in-U tunneling[TUNNEL] for that address.
Jiwoong Lee Expire July 2003 [Page 6]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
The home agent SHOULD perform the normal Xcast routing over the
addresses which are not registered as home addresses of its mobile
nodes.
Administratively the home agent MAY be configured to perform X-in-U
tunneling on every incoming Xcast packet for its registered mobile
nodes. This option is helpful when the final recipients are super-
sparsely spread over the Internet and when the intermediate routers
do not support Xcast.
3.1.3. Tunneling
The home agent SHOULD encapsulate each replicated Xcast packet
within an Xcast packet, where the tunnel Xcast packet is addressed
to the care-of addresses of the addresses listed in the original
packet's List of Address. The List of Addresses of the tunnel
header MAY carry foreign-agent care of addresses as well as co-
located care-of addresses. (Xcast-in-Xcast encapsulation). How to
build up a tunnel packet is out of the scope of this document.
Explicit multicast tunneling is defined in [9].
Since plural mobile nodes can share the same foreign-agent care-of
address, the tunnel Xcast packet MAY be addressed to the same
addresses while the inner one is addressed to different addresses.
In this case the home agent MAY send the original packet in Xcast-
in-Unicast tunneling, if X bit of the original packet is set.
3.2. Foreign agent operations
Upon receipt of an tunneled Xcast packet sent to its advertised
care-of addresses, a foreign agent MUST check whether each address
in List of Addresses of the original Xcast header is registered in
its visitor list. If not, that address SHOULD be overwritten by
zero and MUST be ignored in further processing. Otherwise, the
foreign agent processes the inner Xcast packet and forwards it to
the mobile nodes in normal way. When decapsulated, the bitmap of
the original packet MUST inherit from that of the tunnel packet, as
described in [9].
Because the foreign agent MAY be located on the routing path to the
destinations, it MUST perform normal Xcast routing for the
addresses shown in List of Addresses of the tunnel header, which
are not its advertised care-of addresses.
Jiwoong Lee Expire July 2003 [Page 7]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
3.3. Mobile node operations
3.3.1. Receiving Xcast packets
While a mobile node is away from home, it can receive Xcast
packets. If it is registered using a foreign-agent care-of address,
they will be forwarded by its foreign agent. Otherwise it will
receive tunneled Xcast packets. If no address in List of Addresses
matches the home address of the mobile node, this tunneled Xcast
packet MUST be discarded. Duplicate home address in List of
Addresses SHOULD be ignored.
Any address which is neither the care-of address nor the home
address of the mobile node SHOULD be silently overwritten by zero
and MUST be ignored in further processing at the mobile node.
3.3.2. Sending Xcast packets
While away from home, a mobile node SHOULD use the default unicast
gateway router which is determined by the Mobile IP module of the
mobile node when transmitting Xcast packets. If the Xcast module of
the mobile node specifies different gateway router as the first hop
router for Xcast transmission, it overrides the default gateway
router.
If the reverse tunneling is negotiated during Mobile IP
registration, the mobile node tunnels Xcast packets to its home
agent using Xcast-in-Unicast encapsulation where the tunnel header
is addressed to the home agent.
3.3.3. Handling packets with Anonymity bit
When a mobile node away from home receives an Xcast packet, the 'A'
bit (anonymity bit) state in Xcast header may not affect the packet
processing. When a node tunnels an Xcast packet by Xcast-in-Xcast
encapsulation, the subsequent Xcast routers perform Xcast routing
only over the tunnel header while the original header remains
untouched. Even though the packet sender sets A bit, tunnel egress
nodes can find out receivers' IP addresses without concealment.
4. Protocol Operations over Mobile IPv6
Jiwoong Lee Expire July 2003 [Page 8]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
Xcast over Mobile IPv6 has many distinct features that Xcast over
Mobile IPv4 does not have. These are rooted at differences between
Mobile IPv6 and Mobile IPv4. Some of them which impact upon Xcast
are listed as follows:
- Mobile IPv6 does not utilize a foreign agent or a foreign-
agent care-of addresses. That is, the mobile node in Mobile
IPv6 uses only co-located care-of address.
- A correspondent node SHOULD route a packet using Routing
extension header, instead of IP-in-IP encapsulation if it has
Binding information on the mobile node in its Binding cache.
Based on these differences, Xcast over Mobile IPv6 places some
special requirements on the functions of Xcast nodes. This section
describes operations of Xcast nodes in Mobile IPv6.
4.1. Home agent operations
4.1.1. Requirement for link-local scope multicast packet
The current Mobile IPv6[3] does not allow tunneling of multicast
packets with link-local scope received by a home agent. Since an
Xcast packet is addressed to All_Xcast_Routers, which is a link-
local scope multicast address, a home agent SHOULD intercept
packets addressed to All_Xcast_Routers, or Xcast packet MUST be
addressed to a multicast address with larger scope than link-local.
4.1.2. Home agent specific Xcast routing
When a home agent receives an arriving Xcast packet that carries
one or more home addresses of the registered mobile nodes, it
performs the following operations over those addresses.
The home agent MUST route the Xcast packet based on the care-of
addresses which are bound with the home addresses; it determines
the appropriate next hops to forward any unicast packet (and
thereby the Xcast packet) to the primary care-of addresses. Next it
partitions the home addresses based on the just-found next hops
just found and creates Xcast packets such that
- one packet per next hop is created
Jiwoong Lee Expire July 2003 [Page 9]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
- the packet is addressed to a subset of the listed home
addresses, which is composed by partitioning process based on
the same next hop.
If only one address is left for a next hop, the home agent MAY
perform X-in-U tunneling for that address.
The home agent SHOULD perform the normal Xcast routing over the
addresses which are not registered as home addresses of its mobile
nodes.
Administratively the home agent MAY be configured to perform X-in-U
tunneling on every incoming Xcast packet for its registered mobile
nodes. This option is helpful when the final recipients are super-
sparsely spread over the Internet and when the intermediate routers
do not support Xcast.
4.1.3. Tunneling
The home agent SHOULD encapsulate each replicated Xcast packet
within an Xcast packet, where the tunneling Xcast packet is
addressed to the care-of addresses of the addresses listed in the
original packet's List of Address. The List of Addresses of the
tunnel header carries co-located care-of addresses. (Xcast-in-Xcast
encapsulation)
When one address is left in List of Addresses for a next hop as a
result of Xcast routing, the home agent MAY encapsulated the
original packet within unicast tunnel packet. The tunnel packet is
addressed to the care-of address of the mobile node, if X bit is
not set. (Xcast-in-Unicast encapsulation)
The Destination Header, if given in the original packet, is copied
to the tunnel header with the following exception:
- The Next Header field of Destination Header in the tunnel
header MUST be set to indicate the tunneled packet.
4.2. Mobile node operations
4.2.1. Receiving Xcast packets while away from home
While away from home, a mobile node will receive Xcast packets.
This will be one of the following:
Jiwoong Lee Expire July 2003 [Page 10]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
- Packets tunneled from the home agent to the primary care-of
address of the mobile node. These packets are tunneled using
Xcast-in-Unicast encapsulation[9]. On reception the mobile
node decapsulates them and re-submits them to its network
module, looping back them inside.
- Packets tunneled using Xcast-in-Xcast encapsulation. After
the reception, a mobile node decapsulates them and re-submits
them to its network module, looping back the packet inside the
mobile node. During the decapsulation, the bit inheritance
MUST be done. In further processing, packets will be handled
as normal Xcast packets, which are containing the home address
of the mobile node in List of Addresses.
4.2.2. Handling packets with Anonymity bit
When an mobile node away from home receives an Xcast packet, the
Anonymity bit state MAY NOT affect the packet processing. When a
home agent tunnels an Xcast packet by Xcast-in-Xcast encapsulation,
the intermediate Xcast routers perform Xcast routing only over the
tunnel header leaving the original header untouched. Even though
the packet sender sets A bit, destination mobile nodes will find
out other parties' IP addresses without concealment.
4.2.3. Sending Binding Update
A mobile node SHOULD return a Binding Update in response to
reception of an Xcast packet that meets all of the following tests:
- The packet was tunneled using Xcast encapsulation.
- The List of Addresses of the tunnel header carries a care-of
address of the mobile node.
- The List of Addresses of the original header carries a home
address or a previous care-of address of the mobile node.
- The source address in the tunnel header differs from the
source address in the original header.
In addition, if the mobile node can deduce that the original sender
of the Xcast packet has no or out-of-date Binding Cache entry for
the mobile node, it SHOULD return a Binding Update.
Jiwoong Lee Expire July 2003 [Page 11]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
When a mobile node registers a new care-of address with its home
agent, it generally sends Binding Update to every node listed in
its Binding Update List. If it is required to immediately send
Binding Update messages to a group of nodes, the mobile node MAY
send an Xcast packet that carries the addresses of the group nodes
in List of Addresses and that also carries both Binding Update
option and Home Address option in its Destination header. The
Binding Update option MUST carry a care-of address in its Alternate
Care-of Address Sub-option.
Because Binding Update MUST be protected against malicious security
attack, any Xcast packet for that purpose also MUST be protected in
some way. Currently no security framework for Xcast over Mobile IP
is specified.
4.2.4. Sending Xcast packets while away from home
When transmitting, a mobile node MAY send its Xcast packet using
either its home address or a care-of address as source of the
packet. In case the care-of address is used, the packet SHOULD
include the home address in a Home Address Option.
4.3. Correspondent node operations
4.3.1. Binding update in Xcast packets
If a mobile node sends a Binding Update in an Xcast packet to the
correspondent nodes, one of them MAY receive the Binding Update in
the Xcast packet. Any Xcast node that receives such a packet SHOULD
loop-back it after performing X2U to forward the packet to itself.
Thereafter the Binding Update will be handled as if it was carried
in a unicast packet.
4.3.2. Sending Xcast packets
An Xcast sending node SHOULD examine its Binding Cache for an entry
for the destination address before sending any Xcast packet to the
destination. If the entry is not found, the sending node generates
the Xcast packet in normal way in which IP packet is addressed to
All_Xcast_Routers and its Type Xcast Routing header includes the
addresses of destinations.
Otherwise, the sending node SHOULD send the Xcast packet after
Xcast encapsulation. The sending node MUST NOT use Type 2 Routing
Extension Header as a mean of routing optimization. That is, the
Jiwoong Lee Expire July 2003 [Page 12]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
sending node SHOULD generate the tunneled Xcast packet such that
- The Type Xcast Routing Extension Header of the original packet
encodes the home addresses of the mobile nodes
- The Type Xcast Routing Extension Header of the tunnel packet
encodes the care-of addresses of the mobile nodes
- The n-th address listed in the Type Xcast Routing Extension
header of the tunnel packet MUST have the legitimate binding
relation with the n-th address listed in the Type Xcast
Routing Extension header of the original packet. That is, the
binding sequence of addresses in both Routing headers MUST be
conserved.
An Xcast sending node MUST generate separate copies of Xcast
packets either to the mobile nodes whose care-of addresses are
found in the Binding Cache and or to the nodes whose binding
information is not found, in case the sending node wishes to
forward the Xcast packet directly to the mobile nodes who are away
from home.
4.4. Xcast node considerations
4.4.1. General Xcast routing requirement
Packets, which enters or are created in a home link where a home
agent has Binding Cache entries for registered mobile nodes, MUST
be intercepted by the home agent. In order to intercept such
packets, the home agent multicast on the home link "gratuitous"
Neighbor Advertisement messages [8] on behalf of the mobile nodes.
Then Neighbor Caches of Xcast nodes that share the same link with
the home agent have the same target address for the different
destination addresses, which are essentially the home addresses of
the mobile nodes. Therefore, the Xcast routing over IPv6 MUST be
based on the link-local addresses registered in the Neighbor Cache
of the forwarding node instead of global scope unicast addresses of
the mobile nodes. Otherwise an Xcast node neighboring with the
home agent MAY perform X2U over an incoming Xcast packet, which
results in that the home agent receives plural unicast packets
addressed to each of registered mobile node.
5. Security considerations
Jiwoong Lee Expire July 2003 [Page 13]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
Parts of the unicast address of the participants in an Xcast
session can be revealed to a mobile node when it receives Xcast
packets in Xcast-in-Xcast encapsulation. Therefore participant
anonymity is broken even though Anonymity bit 'A' of the original
packet is set.
A mobile node MAY send its Binding Update to the addresses listed
in its Binding Update List simultaneously by sending it in an Xcast
packet. How to securely protect this message has been left as an
work item for further study.
Appendix
A. Compatibility statements
A.1. Mobile IPv6 HA MUST NOT discard any incoming link-local
multicast packets before it performs Xcast processing, if it
is Xcast-capable.
A.2. This document clarifies the requirement of Xcast routing in
IPv6 (section 4.4). All Xcast nodes MUST route an Xcast packet
based on the link-local addresses of destinations in Neighbor
Cache. This is an especially important requirement when a home
agent sends gratuitous Neighbor Advertisement on behalf of its
mobile nodes.
B. Xcast header format
Xcast header format for IPv4 and IPv6 are quoted from [XCAST].
B.1. Xcast4
Xcast4 header is inserted between layer 3 header and layer 4
header.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROT ID | LENGTH | RESV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
Jiwoong Lee Expire July 2003 [Page 14]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.
B.2. Xcast6
Xcast extension information is carries in Type Xcast Routing
extension header in IPv6. Different from Xcast4, the port numbers
are carries in a Destination extension header.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |RouteType=Xcast| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.2.
C. Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this draft
relative to the previous version of this same draft, draft-lee-
xcast-mobileip-00.txt:
- Clarified the usage of X-in-U tunneling instead of performing
X2U over the tunnel packet.
- Removed the use of Type Xcast Routing Extension header and
Type MIP Routing Extension header as a mean of routing opti-
mization of the sending node.
Jiwoong Lee Expire July 2003 [Page 15]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
- Refereed to [9] on the matters of how to build up a tunnel
packet and how to decapsulate a tunnel packet.
- Clarified the requirement of home agent when it intercepts a
multicast packet with link-local scope.
- Changed expressions in order to clarify the protocol opera-
tions.
- Corrected some editorial nits.
D. Future works
- In Mobile IPv6, Binding Update in Xcast packet should be
explained in greater detail.
- Appendix A.2 of this document can be revised neatly.
Reference
[1] R. Boivie, Y. Imai, W. Livens, D. Ooms, and O. Paridaens, Explicit
Multicast Basic Specification, draft-ooms-xcast-basic-spec-03.txt,
June 2002.
[2] C. Perkins, IP Mobility Support for IPv4, RFC 3344, IETF, Aug 2002.
[3] D. Johnson and C. Perkins, Mobility Support in IPv6, draft-ietf-
mobileip-ipv6-16.txt, Oct 2002.
[4] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Spec-
ification, RFC 2460, Dec 1998.
[5] S. Deering, Host Extensions for IP Multicasting, RFC 1112, Aug
1989.
[6] C. Perkins, IP Encapsulation within IP, RFC 2003, Oct 1996.
[7] G. Montenegro, Reverse Tunneling for Mobile IP, revised, RFC 3024,
Jan 2001.
[8] T. Narten, E. Nordmark, and W. Simpson, Neighbor Discovery for IP
Version 6 (IPv6), RFC 2461, Dec 1998.
[9] J. Lee, Explicit multicast tunneling, draft-lee-xcast-tunnel-
ing-01.txt, Aug 2002.
Jiwoong Lee Expire July 2003 [Page 16]
INTERNET-DRAFT Xcast over Mobile IP Jan 2003
[10] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev-
els, RFC 2119, Mar 1997.
Author Address
Jiwoong Lee
KT Freetel Advanced Lab
1321-11 Seocho-Dong Seocho-Ku Seoul
Korea, Republic of
Phone : +82-2-3488-0416
Email : porce@ktf.com
Jiwoong Lee Expire July 2003 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 03:19:54 |