One document matched: draft-jiang-msa-00.txt
INTERNET-DRAFT Jiang Wu
<draft-jiang-msa-00.txt> KTH/IT
Expires: October, 2000 April 2000
Seamless IP Multicast Receiver Mobility Support
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 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.
Abstract
This document specifies protocol enhancements that allow seamless
IP multicast datagram delivery to mobile nodes in the Internet. In
order to receive IP multicast datagrams, mobile nodes are not
required to be identified by their unicast IP addresses. For
unicast communication using Mobile IP, each mobile node needs to
have a unicast home address and a care-of address. Following a
handover to another IP subnet, such a mobile node is able to
receive IP multicast traffic after exchanging IGMP messages with
the multicast routers on the currently visiting network. However,
in the worst case, it takes an unreasonably long time (especially
with respect to streaming media) to resume receiving multicast IP
traffic in the visiting network.
This draft specifies a Mobility Support Agent (MSA) protocol which
provides a mechanism to help ensure seamless reception of IP
multicast traffic despite a mobile node handover. This is possible
because in advance of its handover, a mobile node pre-registers
with the MSA on the next network to be visited. The MSA acts as a
proxy for this mobile node and is thus able to set up all the
necessary states for the seamless delivery of multicast traffic to
this mobile node.
Jiang [Page 1]
INTERNET-DRAFT Expires October, 2000 April 2000
Table of Contents
1. Introduction ................................................... 2
1.1. New Architectural Entities ........................... 5
1.2. Terminology .......................................... 5
1.3. Protocol Overview .................................... 6
1.4. Message Format ....................................... 7
2. Agent Discovery ................................................ 8
2.1. Inter-Agent Advertisement ............................ 8
2.2. Agent-MN Advertisement ............................... 9
2.2.1. Neighboring Network Extension ................. 10
2.3. Agent Solicitation ................................... 10
2.3.1. MSA History Extension ......................... 10
2.4. MSA Considerations ................................... 11
2.5. Mobile Node Considerations ........................... 12
3. Pre-registration ............................................... 12
3.1. Pre-registration ..................................... 12
3.2. Registration Confirm ................................. 13
3.3. MSA Considerations ................................... 14
3.3.1. Visitor Counter ............................... 14
3.3.2. Mapping Table ................................. 14
3.3.3. IGMPv2 Process ................................ 15
3.3.4. Multicast Routing Process ..................... 15
3.3.5. Other Services ................................ 16
3.4. Mobile Node Considerations ........................... 16
4. De-registration ................................................ 16
5. Security Considerations ........................................ 17
6. Performance Measurements ....................................... 17
7. Acknowledgments ................................................ 18
8. References ..................................................... 18
9. Author's Addresses ............................................. 19
1. Introduction
Current IP multicast routing protocols [3, 4, 8] and membership
management protocols [2, 6] do not require explicit identification
of a node in the IP layer. A mobile node, is therefore capable of
receiving IP multicast traffic in a visited network, provided that
IP multicast routing is available on that network, and that the
node is provided service. The later aspect is being addressed by
the AAA work regarding Mobile IP [1, 9]. Because in IP multicast
traffic the destination addresses are not network specific, the
mobile node can easily resume receiving IP multicast IP after a
handover without changing its IP address or even acquiring a
care-of IP address.
Jiang [Page 2]
INTERNET-DRAFT Expires October, 2000 April 2000
In this draft we propose a Mobility Support Agent (MSA)
architecture to support IP mobility related issues on a IP subnet,
especially for micro-mobility support. A MSA is a network entity
that resides on a IP subnet. It provides a set of services to all
the mobile nodes currently visiting that IP subnet. This approach
supposes to provide seamless IP handover with little change to the
current Internet architecture and protocols. The MSA architecture
is a general purpose architecture. In this draft, however, only IP
multicast is considered. The MSA protocol described in this draft
only intends to be used in an environment where multicast is widely
deployed and the nodes are mobile. Its main goal is to help the
mobile nodes to make handovers without causing noticeable increases
in multicast handover latency.
Internet
----------------------------
| |
| |
+------+ +------+
+---+ |Router| +---+ |Router|
|MSA| +------+ |MSA| +------+
+---+ | +---+ |
| | | |
---------------------- ---------------------
visiting network next network
+--+
|MN| --->
+--+
The figure above shows a typical scenario for a handover
procedure. A mobile node can take part in multiple multicast
sessions identified by their multicast IP addresses. When doing a
handover to the next network, two scenarios are possible for each
multicast session:
1.That multicast session is active on the next network, i.e.,
the corresponding multicast traffic is available on that
network.
2.That multicast session is passive on the next network, i.e.,
the multicast tree is not established yet - hence there is no
corresponding multicast traffic on that network.
In the case of active multicast sessions, the mobile node suffers
little latency receiving the IP multicast traffic after a handover
- since it is already being delivered to this subnet. However, for
those passive multicast sessions, IGMP and multicast routing
protocols must be used to establish the new multicast tree on that
network. This draft deals with the second scenario, the next
network is highly possible to be passive in the multicast sessions
a mobile node is participating in because:
Jiang [Page 3]
INTERNET-DRAFT Expires October, 2000 April 2000
1.Pico cells with high capacity and low error rate will be
popular in the near future as the basic wireless
infrastructure. The pico cell size is too small to accommodate
many mobile nodes, hence the probability of their already
being a member of the multicast group in the cell is small.
2.Many multicast sessions will be sparse mode sessions, in which
members are scattered over the Internet. This also reduces the
probability of having active multicast sessions in the next
network.
In this scenario, after a handover to the next network, the mobile
node waits for an new IGMP Membership Query. It is this message
that triggers the mobile node to send an IGMP Membership Report to
the multicast routers. However, this will probably result in a big
traffic gap in receiving, since the average waiting time for an
IGMP Membership Query by a mobile node after a handover is around
half of the IGMP Query Membership Interval. In typical
implementations, the IGMP Query Membership Interval usually is 60
or 120 seconds, resulting in 30 or 60 seconds of average handover
latency. In the following text, we use "handover latency" to
indicate the traffic gap (in time domain) a mobile node suffers
during a handover.
Once the mobile node receives an IGMP Membership Query, it sets a
delay timer for each group. Each timer is set to a different random
value between 0 and Max Response Time. It is after this timer's
expiration that the mobile node sends an IGMP Membership Report to
the multicast routers, which in turn start to establish the
multicast tree. The handover latency introduced by the back off
sending IGMP Membership Report is on average half of the Max
Response Time. In typical implementations, the Max Response Time is
10 seconds, resulting in 5 seconds of average handover latency.
Besides the latency introduced by IGMP process, the mobile node
also needs to establish the multicast tree to the up-streaming
routers. The tree establishing procedure is started right after the
multicast routers receiving the IGMP Membership Report, which
introduces additional latency in the handover. The tree
establishing latency depends on the distance between the leaf
multicast router and the closest up-streaming router, and the
current situation of the networks. This latency is short in many
cases (in the magnitude order of several tens of milliseconds), so
that it is insignificant when compared with the potential latency
introduced by IGMP. However, the tree establishing latency is not
negligible when the distance to the up-streaming router is very
long or the networks are instable.
Looking a little closer, the situation after the handover is
similar to when a multicast application first starts running in the
mobile node - in this case the application triggers the IGMP to
emit an unsolicited IGMP Membership Report, which eliminates the
Jiang [Page 4]
INTERNET-DRAFT Expires October, 2000 April 2000
start up latency by allowing the mobile node to report its presence
without waiting for the IGMP Membership Query. The remaining
latency only results from the tree establishing procedure.
However, in the current Internet, neither the multicast
applications nor IGMP has the mechanism to detect the handover and
trigger the unsolicited IGMP Membership Report. The potential
handover latency for a mobile node thus is very long in receiving
IP multicast traffic [see section 6].
1.1. New Architecture Entities
The MSA protocol introduces the following new architectural
entities:
Mobile Node
A host that changes its point of attachment from one
network or subnetwork to another.
Mobility Support Agent
An agent on a network which acts as a proxy for mobile
nodes (that potential might come to this network) to
establish the multicast tree in advance of the mobile
nodes' arrival. In addition, this agent can also be used to
advertise the services available on its subnet to the
mobile nodes.
1.2. Terminology
The terminology used in this draft mostly is the same as used in
Mobile IP. The different/additional definitions used in this draft
are:
Visiting network
The IP subnet that the mobile node is currently visiting.
Neighboring network
An IP subnet that is geographically a neighbor of the
visiting IP subnet.
Next network (to be visited)
The IP subnet that that the mobile node will be connected to
(i.e., to which it handsover).
Previous network - i.e., Previously visited network
The IP subnet that the mobile node has just visited.
Jiang [Page 5]
INTERNET-DRAFT Expires October, 2000 April 2000
1.3. Protocol Overview
The following protocols are defined for IP multicast mobility
support:
Agent Discovery
The MSAs may advertise their availability and the services
they provide for their subnet. A mobile node utilizes these
advertisement and makes a handover accordingly. Agent
Discovery consists of two parts: Inter-Agent Advertisement
among the MSAs and the Agent-MN Advertisement between the
mobile node and its directly attached MSA.
Pre-registration
In advance of the handover, the mobile node pre-registers
with the MSA on the next network. Based on this
pre-registration the MSA establishes the multicast tree and
negotiates for services (as a proxy of the mobile node).
De-registration
After moving to another network, a mobile node de-registers
with the MSA on the previous network. De-registration
explicitly removes stale states which might otherwise lead to
unnecessary traffic being sent to the previous network.
The following steps provide a rough outline of the operation of the
MSA protocol:
- MSAs advertise their presence and services (bandwidth
reservation, authentication, etc.) via Agent Advertisements. A
mobile node may optionally solicit an Agent Advertisement from
any locally attached MSAs through an Agent Solicitation.
- A mobile node about to make a handover chooses one or more
most-likely next network (perhaps via a movement prediction
algorithm) and sends Pre-registration(s) to the MSA on the
potential next network(s).
- After authentication and following negotiation between the mobile
node and each of these MSAs, these MSAs can now act as a proxy
for the mobile node in setting up the requested multicast
sessions. IGMP messages are exchanged between the MSA and its
directly attached multicast routers.
- As soon as the mobile node arrives at the next network, it
resumes receiving the IP multicast traffic with the minimum
possible latency, since the join occurred even before it
arrived.
Jiang [Page 6]
INTERNET-DRAFT Expires October, 2000 April 2000
- Once confirmed that it is successfully receiving IP multicast
traffic, the mobile node sends De-registrations to the MSA on
the preciously visited network. If this mobile node was the last
mobile member in a multicast group on the previous network, the
MSA sends a IGMPv2 Leave Group message for that specific
multicast group.
1.4. Message Format
The MSA protocol messages are quite similar to the Mobile IP
message format. One reason is that both are tackling the IP
mobility problem, so that the MSA can be integrated with Mobile IP
agents in one unit. Another reason is that Mobile IP protocol
messages provide a flexible way to make protocol extensions.
The MSA protocol defines several new control messages:
Pre-registration
De-registration
They are sent with UDP [7] using the well-known port number
434, the same port number used for Mobile IP Registration
Request/Reply messages.
Inter-Agent Advertisement
Inter-Agent Advertisement has its own message format. It uses
multicast datagrams instead of unicast datagrams. The
involved MSAs are allocated a dedicated multicast group, to
which all MSAs are both senders and receivers.
MSA protocol defines a general Extension mechanism to allow
optional information to be carried by MSA control messages or by
ICMP Router Discovery messages [5] (just as in Mobile IP). Each of
these Extensions is encoded in the following Type-Length-Value
format:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type Indicates the particular type of Extension.
Length Indicates the length (in bytes) of the data field
within this Extension. The length does NOT include the
Type and Length bytes.
Jiang [Page 7]
INTERNET-DRAFT Expires October, 2000 April 2000
Data The particular data associated with this Extension.
This field may be zero or more bytes in length. The
format and length of the data field are determined by
the type and length fields.
The extension messages are:
Those appearing in the ICMP Router Discovery message
Agent-MN Advertisement Extension
Registration Confirm Extension
MN History Extension
Those appearing in the MSA protocol control message
MN Authentication Extension
2. Agent Discovery
The Agent Discovery protocol is used to advertise the presence of
MSAs and their services. Unlike Mobile IP, mobile nodes do not use
MSA Agent Discovery protocol to determine its current location or
to detect the node's movement. For the MSA architecture, movement
detection can either be performed with the help of Mobile IP or by
using link layer mechanisms. Because a mobile node wants to
(quickly) use the services on its next network, movement prediction
is a very important part of the MSA architecture. In this draft,
however, we do not specify the way to do movement prediction.
2.1. Inter-Agent Advertisement
A group of cooperating MSAs form their own multicast group to
advertise their availability and services to each other. The
Inter-Agent Advertisements are not directly received by the mobile
nodes. The address of the multicast group can either be a
administrative multicast address or other pre-defined addresses.
The most important field within a Inter-Agent Advertisement is the
MSA's unicast IP address. Using this address a mobile node can
pre-register. Inter-Agent Advertisement can also advertise the
services that the local MSA provides and the current link situation
of the local network. These are done by using the extensions.
IP fields:
Source Address
Typically the MSA interface address from which the
message is sent.
Destination Address
The multicast address for the MSA group.
Jiang [Page 8]
INTERNET-DRAFT Expires October, 2000 April 2000
UDP fields:
Source Port variable
Destination Port TBN
The UDP header is followed by the advertisement fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NetType|A|R| Reserved | Current Free Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero or more Neighboring MSA Addresses |
| ... |
Lifetime
The valid time period for a Inter-Agent Advertisement,
measured in seconds.
Sequence Number
The count of Agent Advertisement messages sent since the
agent was initialized.
NetType The link layer network that the MSA is attached to,
for instance, WLAN (1), Ethernet (2), GPRS (3), etc.
A Authentication required.
R Resource reservation available.
Reserved For future extension.
Current Free Bandwidth
The estimated spare bandwidth available (in kbps) in
the network, used for adaptive applications, e.g.,
layered multicast applications.
Neighboring MSA address
Unicast IP address of neighboring MSA's.
2.2. Agent-MN advertisement
The Agent-MN advertisement makes use of the Mobile IP Agent
Advertisement Extensions of the ICMP Router
Advertisement. Advertisement messages are transmitted by a MSA to
the mobile nodes which are on the same network. The information
advertised by the MSA is either directly retrieved from the
Inter-agent Discovery messages, or derived from them. Within an
Agent Advertisement message, ICMP Router Advertisement fields of
the message have the same requirements as in Mobile IP.
Jiang [Page 9]
INTERNET-DRAFT Expires October, 2000 April 2000
2.2.1. Neighboring Network Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSA Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NetType|A|R| | Current Free Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSA Address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NetType|A|R| | Current Free Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBN
Length (2+4*N), where N is the number of MSA addresses
advertised.
Sequence Number
The count of Agent Advertisement messages sent
since the agent was initialized
MSA Address n
The neighboring MSA's unicast IP address to which a
mobile node can send pre-registration requests to.
2.3. Agent Solicitation
Mobile nodes may send an Agent Solicitation message when moving to
the next network. An Agent Solicitation uses the ICMP Router
Solicitation with the IP TTL set to 1.
2.3.1. MSA History Extension
In the MSA History Extension, the mobile node records the most
recently visited MSAs in reverse sequence. The current serving MSA
can determine its neighboring peers from the history list.
Jiang [Page 10]
INTERNET-DRAFT Expires October, 2000 April 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |O 1|O 2|O 3|O 4|O 5|O 6|O 7|O 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Visited MSA 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp in 1 | Timestamp out 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Visited MSA n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp in n | Timestamp out n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBN
Length (2+4*N)
O n Optionally records the overlap status between the
network n and network (n-1). Possible values are: 0
non-overlap, 1 partial overlap, 2 full overlap.
Visited MSA n
The MSA that has been visited by the mobile node, 1 is
the most recently visited, while n is the MSA visited
n hops back.
Timestamp in/out n
The time (in seconds) when the mobile node first
receives an Agent advertisement (in), and the time
when the mobile node sends a Pre-registration (out).
2.4. MSA considerations
Every MSA must send Agent advertisements. However, it must limit
the rate at which it sends broadcast or multicast Agent
Advertisements. A recommended maximum rate is once per second.
For Inter-Agent Advertisement, all the involved MSAs must be both
senders and receivers. To avoid synchronization of the
advertisement messages, sending to the multicast group should be
randomized in time.
Each MSA keeps a table including a list of peer MSAs serving their
own network and their corresponding services and information. By
collecting the MSA History Extensions, MSAs are able to work out a
map of the network topology with MSA services. If MSA is deployed
on each network, full geographic topology of the networks can be
revealed. This map can optionally be advertised to the mobile nodes
for aiding movement prediction. The detailed operation is not
discussed in this draft.
Jiang [Page 11]
INTERNET-DRAFT Expires October, 2000 April 2000
2.5. Mobile Nodes Considerations
In order to take advantage of the MSAs, mobile nodes may process
received Agent Advertisements. They may report their MSA history
list by sending MSA History Extensions. There might be loops in the
history list. Mobile nodes can use this information and the
timestamps together with the map information to analyze the user's
movement behavior, which aids movement prediction.
In the MSA History Extension, the information of whether the
neighboring networks are overlapped or not is optional. One
straight forward mechanism possibly can be used is for the mobile
node to monitor all the network interfaces. If the mobile node can
hear simultaneously signals from the neighboring networks, it can
assume the networks are overlapped. Multiple wireless interfaces
are needed and required to monitor the channels when the
neighboring networks are heterogeneous.
3. Pre-registration
Pre-registration is the key method for a mobile node to enable
seamless handover relative to multicast. By pre-registration, a
mobile node can:
- Negotiate services on the next network.
- Request that the corresponding MSA set up services in
advance; in the case of multicast, the MSA helps to set up
the multicast tree.
Pre-registration has one new control message type:
Pre-registration
The MSAs use the UDP port 434 for listening to the
Pre-registrations. For each multicast group, the MSA creates
an entry in its mobile multicast table.
The reason to use the same well-known UDP port as Mobile IP
registration is that the MSA can also act as a Mobile IP Home Agent
or Foreign Agent. It can also be used for pre-registration for IP
unicast (which is not developed further in this draft).
3.1. Pre-registration
A mobile node sends a pre-registration to the MSA on the next
network before it makes a handover. This message contains a
timestamp and all the multicast groups that are currently active in
the mobile node. Pre-registration does not require feedback from
the MSA, because the mobile node might have left the current
visiting network before the feedback is available. In order to
improve reliability, the mobile node is required to send the same
pre-registration 3 times.
Jiang [Page 12]
INTERNET-DRAFT Expires October, 2000 April 2000
IP fields:
Source Address
Typically the mobile node interface address (a unicast
IP address) from which the message is sent.
Destination Address
The unicast address of the MSA on the next network.
UDP fields:
Source Port variable
Destination Port 434
The UDP header is followed by the Mobile IP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One or more Multicast Address(es) |
| ... |
Type TBN
Reserved For future use.
Lifetime
The number of seconds remaining before the registration
is considered expired.
Multicast Addresses
The multicast address for each group that the mobile node is
participating as receiver.
3.2. Registration Confirm Extension
Once the MSA receives a pre-registration, it initiates the process
to establish the corresponding multicast tree. At the same time it
checks if the multicast group in the message is present on the
local network. If not, it will setup a timer which has the value of
"Lifetime" in the Pre-registration message. During the "Lifetime"
period, the MSA waits for a Registration Confirm from the mobile
node. The mobile node sends the Registration Confirm to the MSA
only after it has moved to the next network and successfully
received the first multicast datagram. After receiving the
Registration Confirm, the MSA stop the timer and send a
De-registration to the MSA on the previous network. The way to find
out the previous network is by looking for the mobile node's
identity and its MSA history list.
Jiang [Page 13]
INTERNET-DRAFT Expires October, 2000 April 2000
The Registration Confirm Extension makes use of the ICMP Router
Solicitation Extension:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous MSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One or more multicast address |
| ... |
Type TBN
Length (2+4*N)
Previous MSA
The MSA on the previous network that the
De-registration message will be sent to.
Multicast Address
The multicast address that the mobile node is
currently participating as receiver.
3.3. MSA considerations
3.3.1. Visitor Counter
A MSA maintains a visitor counter for each multicast group that are
pre-registered by the mobile nodes. The counter records the number
of mobile nodes on the network are receiving the corresponding
multicast group. The counter increases by one every time the MSA
receives a Registration Confirm for that multicast group, decreases
by one when the MSA receives a De-registration for that multicast
group. A counter is created when the MSA receives the first
Pre-registration for that multicast group. But the counter number
is not initialized until the MSA receives the first Registration
Confirm. If the timer set by the MSA for Registration Confirm
expires, the counter is removed.
3.3.2. Mapping Table
Every MSA maintains a Mapping Table to reveal the relations among
the MSA enabled networks. The mapping information either comes from
the mobile node's MSA History Extension or by manual configuration
when the MSAs are setup. The MSAs exchange the information with
each other via the Inter-Agent Advertisement, thus every MSA can
compute the full map on its own.
Jiang [Page 14]
INTERNET-DRAFT Expires October, 2000 April 2000
A Mapping Table has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer MSA Address | HopCount | Overlap | Services |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 130.237.216.146 | 3 | 0 | AR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 130.237.15.178 | 0 | 1 | A |
| ... | ... | ... | ... |
Peer MSA Address
Normally the unicast IP address the peer MSA uses for
receiving the Pre-registrations.
HopCount
It indicates how many networks away the peer MSA is. When
the MSAs are not fully deployed in the networks, the
HopCount is only meaningful for those networks with MSA.
Overlap
HopCount value 0 indicates the network served by the peer
MSA and the local networks are overlapped. Overlap 1
indicates they are partially overlapped.
Services
The services that the peer MSA provides, it has the same
convention as in the Inter-Agent Advertisement.
3.3.3. IGMPv2 Process
On the MSA's directly attached network, the MSA acts as an
individual IGMP entity as the other nodes do on the network. To the
registering mobile nodes, the MSA functions as the IGMP proxy. The
MSA should immediately transmit an unsolicited Membership Report
for that group when a new Visitor Counter is initialized for a
multicast group. It should send a Leave Group message to the
all-routers multicast group (224.0.0.2) when a multicast group
entry is removed.
The MSA is only responsible for establishing the multicast tree if
it is not already done for the pre-registered mobile nodes. Once a
mobile node is on the MSA's directly attached network, IGMP
messages are exchanged in the normal way between the mobile host
and the multicast routers.
3.3.4. Multicast Routing Protocol Process
Once the IGMP process in a multicast router receives a membership
report for a new group, it will notify the multicast router to add
a routing entry for the corresponding multicast group in its
routing table. Usually the multicast router immediately start the
tree establishing process. It sends a "join/prune" message (in PIM)
Jiang [Page 15]
INTERNET-DRAFT Expires October, 2000 April 2000
or "graft" message (in DVMRP) to their up-streaming routers. The
latency in this process is introduced by the processing time and
propagation delay. This latency normally is not much, however, when
the up-streaming multicast router is geographically far away or the
networks are not stable, the propagation delay would be
significant.
3.3.5. Other Services
Other services may be available as options in the MSA. All these
services may use the extensions of Pre-registration to negotiate
and use extensions of Inter-Agent Advertisement to advertise. One
of these services is that the MSA can buffer some multicast packets
for the coming mobile node if it is asked by that mobile
node. Another is that MSA acts as a multicast router on the local
network which establishes tunnels with other MSAs or multicast
Routers. These services are not parts of this draft specification.
3.4. Mobile Nodes Considerations
A mobile node sends Pre-registrations via UDP datagram with the
destination port 434, the destination IP address is the MSA on the
next network. It listens to the ICMP Router Advertisement to
determine the default router. No feedback is needed in the
Pre-registration protocol. In addition, authentication can use the
extension mechanism as done in Mobile IP.
It is quite possible that after a mobile node sends one or more
Pre-registrations to the MSA on the next network, it does not
handover to that network. Without receiving a Registration Confirm
during the "Lifetime" period (specified in the Pre-registration),
the MSA will "prune" the multicast tree if there are no other
members on its local network. The mobile node must not trigger
another pre-registration process within the "Lifetime"
period. After the "Lifetime" interval, it may do a pre-registration
according to the new situation and the movement prediction
mechanisms.
4. De-registration
De-registration is used for de-registering with the MSA on the
previous network. When the Visitor Counter for a multicast group
reaches 0, the MSA acting as an ordinary IGMP entity sends an IGMP
Leave Group message for that multicast group too the multicast
routers. This procedure eliminates the IGMP leaving latency on the
previous network if there are no fixed members on the previous
network.
IP fields:
Source Address
Typically the mobile node interface address (a unicast
IP address) from which the message is sent.
Jiang [Page 16]
INTERNET-DRAFT Expires October, 2000 April 2000
Destination Address
The MSA on the previous network.
UDP fields:
Source Port variable
Destination Port 434
The UDP header is followed by the Mobile IP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One or more Multicast Address |
| ... |
Type TBN
Reserved For future use.
Multicast Address
The multicast group that the mobile node has
participated as receiver on the previous network.
De-registration uses UDP and does not require the feed back, the
mobile node should send De-registration 3 times in sequence.
5. Security Considerations
The major security attacks may come from:
1.The forged Inter-Agent advertisements may prevent the mobile
nodes from knowing the correct network situation, which will
lead to wrong handover decisions.
2.The forged Pre-registrations or De-registrations may trigger
the MSAs to establish or tear down the multicast tree
improperly. Too many such messages may overload a MSA.
These attacks can be to large extend avoided by using
authentication among the MSAs and mobile nodes.
6. Performance Measurements
We have simply implemented the protocol in our own
testbed. Measurements have been made to test how much handover
performance regarding to handover latency can be improved by using
pre-registration in with the MSA architecture. IGMPv2 and PIM-SM
are used in the testbed, with IGMP Membership Query Interval
Jiang [Page 17]
INTERNET-DRAFT Expires October, 2000 April 2000
configured to 60 seconds and Max Response Time configured to 10
seconds. Results show that without pre-registration the average
handover latency is around 32 seconds, in which 27 seconds due to
IGMP Membership Query waiting, 5 seconds due to the random back off
in sending IGMP Membership Report. In our testbed, the closest
up-streaming multicast router is always close to the leaf multicast
router and the networks are stable, so the tree establishing
latency is only around several tens of milliseconds.
By using pre-registration with MSA, all the IGMP and tree
establishing processes are done in advance of the mobile node's
handover. Our measurements show that the major latency is from the
physical movement. Since we used a SNMP controlled multi-segment
10BT Ethernet hub to emulate the handover, the physical movement
latency is around several milliseconds.
7. Acknowledgments
A lot of thanks to Chip Maguire, Bjorn Pehrson, and J-O Vatn for
the discussions and comments on this draft.
8. References
[1] C. Perkins, "IP Mobility Support", RFC 2002, October 1996.
[2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236, November 1997.
[3] Estrin, et. al., "Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998.
[4] Waitzman, Partridge & Deering, "Distance Vector Multicast
Routing Protocol", RFC 1075, November 1998.
[5] Deering, S., Editor, "ICMP Router Discovery Messages",
RFC 1256, September 1991.
[6] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[8] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March 1994.
[9] S. Glass, S. Jacobs, C. Perkins, "Mobile IP authentication,
authorization, and accounting requirements",
draft-ietf-mobileip-aaa-reqs-00.txt, October 1999.
Jiang [Page 18]
INTERNET-DRAFT Expires October, 2000 April 2000
9. Authors' Addresses
Contact Information
Jiang Wu
KTH/IT, Electrum 204
S-16440 Kista, Sweden
Tel : +46 8 752 1484
Fax : +46 8 751 1793
Email: jiang@it.kth.se
Jiang [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-22 22:55:08 |