Internet DRAFT - draft-srinivasa-mip4-mir
draft-srinivasa-mip4-mir
Mobility for IPv4 Working Group K. Srinivasa
Internet-Draft Net-Mobile
Expires: April 9, 2006 October 6, 2005
Multi-Interface Routing for Mobile Terminals (MIR)
draft-srinivasa-mip4-mir-00.txt
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 April 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines protocol enhancements that allow a Mobile IP
enabled mobile terminal, when away from home, to simultaneously use
multiple connected network interfaces for the routed traffic between
the home agent and the mobile terminal so as to obtain higher
aggregated bandwidth.
Srinivasa Expires April 9, 2006 [Page 1]
Internet-Draft Multi-Interface Routing Support October 2005
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution in a nut shell . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Extensions . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Multi-Interface Routing Registration Request . . . . . . . 5
4.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios & Routing Considerations . . . . . . . . . . . . . . 8
5.1. Case-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Case-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Case-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Case-4 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Case-5 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Mobile Terminal Operation: . . . . . . . . . . . . . . . . 15
6.2. Foreign Agent Operation: . . . . . . . . . . . . . . . . . 17
6.3. Home Agent Operation: . . . . . . . . . . . . . . . . . . 18
7. Implementations . . . . . . . . . . . . . . . . . . . . . . . 18
8. Traffic Flow Management . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Srinivasa Expires April 9, 2006 [Page 2]
Internet-Draft Multi-Interface Routing Support October 2005
1. Problem Statement
We have a requirement for our mobile video terminal to support
multiple cellular interfaces for achieving higher throughput for the
traffic from the streaming server to the mobile terminal. To that
effect, we have extended the Mobile IP protocol to support this
functionality. We have implemented these extensions on a open source
code base and were able to demonstrate a very high quality Video when
using this scheme.
With the availability of multiple cellular technologies and services,
mobile terminals are now equipped with multiple interfaces and with
the ability to connect to a provider network over any of those
interfaces and access the Internet. However, the available bandwidth
on any single interface or the connected link is quite low, in the
order of 20kbps to 100kbps, and that is not sufficient for running
multimedia or other high bandwidth consuming applications.
The operation defined in the Mobile IP Protocol [11], allows a mobile
terminal to continue to use its home address as it moves around the
Internet. There will be a tunnel that will be setup directly from
the home agent to the mobile terminal or from the home agent to the
attached foreign agent of the mobile terminal based on the mode of
operation. In both these modes, there will only be one interface on
the mobile terminal that is receiving the traffic from the home
agent. However, this is not efficient and requires an approach where
the mobile terminal can use more than one interfaces for reaching the
home network. The objective being efficient use of all available
links to obtain higher aggregated bandwidth for the tunneled traffic
between the home agent and the mobile terminal.
This document presents extensions to the Mobile IP protocol for using
multiple interfaces on the mobile terminal and having a over lay
network of tunnels to the home agent over those interfaces for load
balancing the traffic across all those tunnels based on various
traffic policies.
Srinivasa Expires April 9, 2006 [Page 3]
Internet-Draft Multi-Interface Routing Support October 2005
2. Solution in a nut shell
Home Agent Mobile Terminal
%%%%%%%% Tunnel 1 If_1 %%%%%%%%%
%% %% |=============={PROVIDER_1}------------%% %%
%% %% | COA_1 %% %%
%% %% | %% %%
%% %% | Tunnel 2 If_2 %% %% ----
%% %% |==============={PROVIDER_2}-----------%% %% | |
%% %% | COA_2 %% %% |Home|
%% %% | %% %%-|Addr|
%% %%-----|HA_If %% %% | |
%% %% | %% %% ----
%% %% | Tunnel 3 If_3 %% %%
%% %% |==============={PROVIDER_3}-----------%% %%
%% %% | COA_3 %% %%
%% %% | %% %%
%% %% | Tunnel 4 %%%%% If_4 %% %%
%% %% |============{PROVIDER_4}-%% %%--------%% %%
%%%%%%%% %%%%% FA_COA %%%%%%%%%
Foreign
Agent
Figure 1: Mobile Terminal with multi-interface routing support
This is the view of the routing data paths between the mobile
terminal and the home agent. The home address of the mobile terminal
may be reachable from the home agent through any these tunnels.
The throughput capacity of each of these tunnels is dependent on the
type of the interface and the attached provider network. The mobile
terminal will have the ability to notify the size of the tunnel to
the home agent for more effective load balancing of the traffic.
The care-of address of any these interfaces of the mobile terminal
when configured to operate in co-located mode, may keep changing as
the mobile terminal keeps moving across the network.
When a given interface of the mobile terminal is configured to avail
the mobility services of a foreign agent available on the link, the
available foreign agents may change as the mobile terminal keeps
moving across the network.
Srinivasa Expires April 9, 2006 [Page 4]
Internet-Draft Multi-Interface Routing Support October 2005
3. 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 [9]. Other
terminology is used as already defined in RFC 3344 [7].
In addition, this document frequently uses the following terms and
conventions:
HAA - Home Agent Address
COA - Care-of Address
MT_HA - Mobile Terminal Home Address
MT_If - Mobile Terminal Interface
MT_If_COA - Mobile Terminal Interface Care-of Address
NH_GW - Next Hop Gateway
FA_If - Foreign Agent Interface
HA_If - Home Agent Interface
FA_If_COA - Foreign Agent Interface Care-of Address
NAT_GWA - Network Address Translation Gateway Address
======= - Tunnel Representation
------- - Interface Representation
4. Message Extensions
4.1. Multi-Interface Routing Registration Request
This extension is a non-skippable extension and MAY be added to the
Registration Request message by the mobile terminal. It notifies the
home agent to register the current care-of address listed in this
Registration Request as one of the care-addresses through which the
mobile terminal can be reached. The home agent after authorizing the
request MUST create a tunnel to the care-of address listed in the
registration request.
The Multi-Interface Routing Registration extension MAY be added to
Srinivasa Expires April 9, 2006 [Page 5]
Internet-Draft Multi-Interface Routing Support October 2005
the Registration request ONLY by the mobile terminal. This extension
MUST not be added by the home agent or by the foreign agent either to
the Registration Request or to the Reply.
This extension should be protected by Mobile Home Authentication
extension. As per Section 3.2 and 3.6.1.3 of RFC 3344 [1], the
mobile terminal MUST place this Extension before the Mobile-Home
Authentication Extension in the registration messages, so that it is
covered by the Mobile-Home Authentication 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 | Sub-Type | If-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|W|L|Reservd-0| If-Type | Link-Weight | Reserved-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multi-Interface Routing Extension
Type: <IANA>
Length: 6. Length in bytes of this extension, not including the
Type and Length bytes.
Sub-Type: 0
If-Id: Interface identifier. Indicates the identifier of the
interface from where this request is being sent. This is useful
when the mobile terminal moves from one access network to another
access network and keeps sending the registration requests. The
home agent can identify the movement of the terminal and the given
interface for registering the new care-of address.
F: Flow Continuity flag indicates that the mobile node wants the
home agent to route all packets for a given flow originating from
this tunnel to always be sent over the same tunnel. But, if the
tunnel goes down, then the home agent MUST route the traffic
through the other available tunnel routes.
W: Weighted Mode Flag indicates that the value specified in the
Link-Weight field must be interpreted as "Weighted Ratio" mode.
Srinivasa Expires April 9, 2006 [Page 6]
Internet-Draft Multi-Interface Routing Support October 2005
If this flag is not specified, then the home agent must interpret
the Link-Weight field as the "Absolute Bandwidth" mode.
L: Rate Limit Flag indicates that the mobile node wants the home
agent to rate limit the traffic sent on this tunnel to the
specified bandwidth in the link weight flag. This flag is
applicable only for the "Absolute Bandwidth" mode, when the "W"
bit is not set.
Reserved-0: Reserved for future use. MUST be set to 0 on sending,
MUST be ignored on reception.
If-Type: Interface Type for the link. Further study required
Link-Weight: The Link Weight could be either the weighted ratio or
the absolute link bandwidth. The mode is specified by the "W" bit
in the request. The Link-Weight in the weighted ratio mode
indicates the ratio of the traffic from the home agent that can
take this Interface route. If there are 3 interfaces on the
mobile with the following ratios 1, 4 and 5 respectively. Every 1
packet of the 10 packets goes through Interface-1, every 4 packets
out of the 10 packets go through Interface-2 and every 5 packets
out of the 10 packets go through Interface-3. If Interface-3 goes
down, the ratios between Interface-1 and Interface-2 get adjusted
to 2 and 8. The Link-Weight when the W bit is not set indicates
that the value specified for this field is the absolute bandwidth
available for this link. The value indicates the absolute
bandwidth in the kilobytes, rounded to the nearest integer.
Reserved-1: Reserved for future use. MUST be set to 0 on sending,
MUST be ignored on reception.
4.2. Error Codes
Four new registration reply codes are defined for supporting these
protocol extensions:
ERROR_HA_MULTI_INTERFACE_RTG_UNAVAIL: Requested Multi-Interface
Routing service unavailable at the home agent
This is used by the home agent in registration reply with the code
set to the above value. A home agent that is not configured to
support this Multi-Interface Routing feature or when it is not
Srinivasa Expires April 9, 2006 [Page 7]
Internet-Draft Multi-Interface Routing Support October 2005
allowed to offer this service to the requesting mobile terminal, MUST
reject the request with the above reply code.
ERROR_HA_MULTI_INTERFACE_UNEQUAL_LD_UNAVAIL: Requested Multi-
Interface unequal traffic load distribution unavailable at the home
agent.
This is used by the home agent in registration reply with the code
set to the above value. A home agent that is not capable of routing
the traffic to the mobile terminal on its registered interfaces, in
unequal load distribution terms as requested MUST reject the request
with the above code.
ERROR_FA_MULTI_INTERFACE_RTG_UNAVAIL: Requested Multi-Interface
routing service unavailable at the foreign agent.
This is used by the foreign agent in registration reply with the code
set to the above value. The foreign agent that is not configured to
support this Multi-Interface Routing feature or when it is not
allowed to offer this service to the requesting mobile terminal, MUST
reject the request with the above reply code.
ERROR_FA_MULTI_INTERFACE_UNEQUAL_LD_UNAVAIL: Requested Multi-
Interface unequal traffic load distribution unavailable at the
foreign agent.
This is used by the foreign agent in registration reply with the code
set to the above value. A foreign agent that is not capable of
routing the traffic to the mobile terminal on its registered
interfaces, in unequal load balancing terms as requested MUST reject
the request with the above code.
5. Scenarios & Routing Considerations
We have considered the following five scenarios for this feature
implementation verification. The below scenarios each describe the
network configuration and the forwarding plane state when this
feature is active. Each of the tunnels can be of the standard type
such as GRE, IP-IP, Min-IP, or UDP/IP as defined in the Mobile IP
specifications [7] and [8].
Srinivasa Expires April 9, 2006 [Page 8]
Internet-Draft Multi-Interface Routing Support October 2005
5.1. Case-1
Home Agent Mobile Terminal
%%%%%%%%% Tunnel_1 MT_COA_1 %%%%%%%%%
%% %% =====================------------%% %%
%% %% HAA // MT_If_1 %% %%
%% %%------ %% %%
%% %% HA_If\\ Tunnel_n MT_COA_n %% %%
%% %% =====================------------%% %%
%%%%%%%%% MT_If_n %%%%%%%%%
MT_HA
Figure 3: Mobile Terminal registering directly with the home agent
IP forwarding plane at the mobile terminal:
0.0.0.0/0.0.0.0 via Tunnel_1
0.0.0.0/0.0.0.0 via Tunnel_n
Tunnel_1: MT_COA_1 <------> HAA, next hop NH_GW_1
Tunnel_n: MT_COA_n <------> HAA, next hop NH_GW_n
IP forwarding plane at the home agent:
MT_HA via Tunnel_1
MT_HA via Tunnel_n
Tunnel_1: HAA ------> MT_COA_1
Tunnel_n: HAA ------> MT_COA_n
5.2. Case-2
Srinivasa Expires April 9, 2006 [Page 9]
Internet-Draft Multi-Interface Routing Support October 2005
Home Agent Foreign Agent (FA_1)
%%%%%%%%% %%%%%%%% FA_1_If (FA_1_COA)
%% %% ============---%% %%---------
%% %% // Tunnel_1 %%%%%%%% \MT_If_1
%% %% HAA // %%%%%%%%
%% %%----- %% %% Mobile Terminal
%% %% \\ Foreign Agent (FA_n) %%%%%%%% MT_HA
%% %% \\ %%%%%%%% /MT_If_n
%% %% ============---%% %%---------
%% %% Tunnel_n %%%%%%%% FA_n_If (FA_n_COA)
%%%%%%%%%
Figure 5: Mobile Terminal registering through multiple foreign agents
IP forwarding plane at the mobile terminal:
0.0.0.0/0.0.0.0 via MT_If_1 next hop FA_1_If (L2 forwarding)
0.0.0.0/0.0.0.0 via MT_If_n next hop FA_n_If (L2 forwarding)
IP forwarding plane at the foreign agent (FA_1):
MT_HA via FA_1_If next hop MT_If_1 (L2 forwarding)
Will reverse tunnel all the traffic from MT_HA received on FA_1_If
over Tunnel_1, if reverse tunnel is enabled for the tunnel. If
reverse tunnel is not enabled, the traffic received on FA_1_If
will be routed normally.
Tunnel_1: FA_1_COA <------> HAA
IP forwarding plane at the home agent:
MT_HA via Tunnel_1
MT_HA via Tunnel_n
Tunnel_1: HAA <------> FA_1_COA
Tunnel_n: HAA <------> FA_n_COA
Srinivasa Expires April 9, 2006 [Page 10]
Internet-Draft Multi-Interface Routing Support October 2005
5.3. Case-3
Home Agent
%%%%%%%%% Mobile Terminal
%% %% MT_If_1 %%%%%%%%
%% %% Foreign Agent _____%% %%
%% %% HAA %%%%%%%%% FA_COA/ %% %%
%% %%-----===========---%% %%------ %% %%
%% %% Tunnel_1 %%%%%%%%% FA_If \_____%% %%
%% %% MT_If_n %% %%
%% %% %%%%%%%%
%% %% MT_HA
%%%%%%%%%
Figure 7: Mobile Terminal registering multiple links through the same
foreign agent and with the same foreign agent care-of address
IP forwarding plane at the mobile terminal:
0.0.0.0/0.0.0.0 via MT_If_1 next hop FA_If (L2 forwarding)
0.0.0.0/0.0.0.0 via MT_If_n next hop FA_If (L2 forwarding)
IP forwarding plane at the foreign agent:
MT_HA via FA_If next hop MT_If_1 (L2 forwarding)
MT_HA via FA_If next hop MT_If_n (L2 forwarding)
Will reverse tunnel all the traffic from MT_HA received on FA_If
over Tunnel_1, if reverse tunnel is enabled for the tunnel. If
reverse tunnel is not enabled, the traffic received on FA_If
will be routed normally.
Tunnel_1: FA_COA <------> HAA
IP forwarding plane at the home agent:
MT_HA via Tunnel_1
Tunnel_1: HAA <------> FA_COA
Srinivasa Expires April 9, 2006 [Page 11]
Internet-Draft Multi-Interface Routing Support October 2005
5.4. Case-4
Home Agent Foreign Agent Mobile Terminal
|
%%%%%%%%% Tunnel_1 |-------------------
%% %% =============---|FA_COA_1 \ MT_If_1
%% %% // |FA_If_1 %%%%%%%%
%% %% HAA // %%%%%%%%% %% %%
%% %%------ %% %% %% %%
%% %% HA_If\\ %%%%%%%%% %% %%
%% %% \\Tunnel_n |FA_If_n %%%%%%%%
%% %% =============---|FA_COA_n / MT_If_n
%% %% |-------------------
%%%%%%%%% | MT_HA
Figure 9: Mobile Terminal registering its multiple interfaces through
the same foreign agent but with different foreign agent care-of
addresses
Srinivasa Expires April 9, 2006 [Page 12]
Internet-Draft Multi-Interface Routing Support October 2005
IP forwarding plane at the mobile terminal:
0.0.0.0/0.0.0.0 via MT_If_1 next hop FA_If_1 (L2 forwarding)
0.0.0.0/0.0.0.0 via MT_If_n next hop FA_If_n (L2 forwarding)
IP forwarding plane at the foreign agent:
MT_HA via FA_If_1 next hop MT_If_1 (L2 forwarding)
MT_HA via FA_If_n next hop MT_If_n (L2 forwarding)
Will reverse tunnel all the traffic from MT_HA received on FA_If_1
over Tunnel_1, if reverse tunnel is enabled for the tunnel. If
reverse tunnel is not enabled, the traffic received on FA_If_1
will be routed normally.
Tunnel_1: FA_COA_1 <------> HAA
Will reverse tunnel all the traffic from MT_HA received on FA_If_n
over Tunnel_n, if reverse tunnel is enabled for the tunnel. If
reverse tunnel is not enabled, the traffic received on FA_If_n
will be routed normally.
Tunnel_n: FA_COA_n <------> HAA
IP forwarding plane at the home agent:
MT_HA via Tunnel_1
MT_HA via Tunnel_n
Tunnel_1: HAA <------> FA_COA_1
Tunnel_n: HAA <------> FA_COA_n
5.5. Case-5
Srinivasa Expires April 9, 2006 [Page 13]
Internet-Draft Multi-Interface Routing Support October 2005
NAT
=====
Home Agent | | Foreign Agent
%%%%%%%%% | | %%%%%%%%% FA_If
%% %% ==| |=======---%% %%-----------
%% %% // | | Tunnel_1 %%%%%%%%% FA_COA \MT_If_1
%% %% HAA // | | MT_If_2 %%%%%%%%
%% %%----- ====| |========================----%% %% Mobile
%% %% \\ | | Tunnel_2 MT_COA_2 %%%%%%%%
%% %% \\ | | MT_If_n /MT_HA
%% %% ==| |===========================--
%% %% | | Tunnel_n MT_COA_n
%%%%%%%%% | |
=====
NAT_GWA
Figure 11: Mobile Terminal registering and some other interfaces
through one or more foreign agents
Srinivasa Expires April 9, 2006 [Page 14]
Internet-Draft Multi-Interface Routing Support October 2005
IP forwarding plane at the mobile terminal:
0.0.0.0/0.0.0.0 via MT_If_1 next hop FA_If (L2 forwarding)
0.0.0.0/0.0.0.0 via Tunnel_2
0.0.0.0/0.0.0.0 via Tunnel_n
Tunnel_2: MT_COA_2 <------> HAA, next hop NH_GW_2
Tunnel_n: MT_COA_n <------> HAA, next hop NH_GW_n
IP forwarding plane at the foreign agent:
MT_HA via FA_If next hop MT_If_1 (L2 forwarding)
Reverse tunnel all traffic from MT_HA received on FA_If
over Tunnel_1
Tunnel_1: MT_COA <------> HAA
IP forwarding plane at the home agent:
MT_HA via Tunnel_1
MT_HA via Tunnel_2
MT_HA via Tunnel_n
Tunnel_1: HAA <------> NAT_GWA, (UDP Port 1)
Tunnel_2: HAA <------> NAT_GWA, (UDP Port 2)
Tunnel_n: HAA <------> NAT_GWA, (UDP Port n)
6. Operation
6.1. Mobile Terminal Operation:
At Home:
When the mobile terminal is at home, the communication with other
nodes occurs normally without the use of Mobile IPv4 functionality.
The method used by a mobile terminal to determine that it is attached
to the home link is per the base Mobile IP Specification [7]. If the
mobile moves into the home network from a foreign network and if it
had previous bindings with the home agent, it will deregister all of
its care-of addresses with the home agent per Section 3.6.1.2 of the
Mobile IP Specification [7]. If the mobile terminal for connecting
to the home link, uses either a designated interface or any of the
available interfaces, to connect to the home link, the mobile
Srinivasa Expires April 9, 2006 [Page 15]
Internet-Draft Multi-Interface Routing Support October 2005
terminal in either case MUST consider it is at home when the home
link is available from any one of its interfaces.
Away from Home:
The mobile terminal is considered to be away from home when the home
link is not available from any one of its interfaces. When the
mobile terminal is away from home, the following occurs:
1. The mobile terminal should send the registration request with the
Multi-Interface Registration Request extension for each of the
interfaces configured to participate in Multi-Interface routing. The
mobile terminal should tune the routing stack to ensure the
registration request goes out from the interface where the
registration is sough for. The mobile terminal should constantly try
to check the availability of the link on each of the interfaces and
attempt to register over that interface.
2. The mobile terminal on receiving a registration reply for a
registration request that it sent over a specific interface and by
specifying the "D" bit in the request and in the co-located care-of
address mode, should check for the code in the reply. If the Code
field indicates that the request has been accepted, the mobile
terminal SHOULD create a tunnel with the registered care-of address
as the tunnel source address and the home agent address as the tunnel
destination address.
3. The mobile terminal on receiving a registration reply for a
registration request that it sent over a specific interface and using
the foreign agent care-of address in the request, should check for
the code in the reply. If the Code field indicates that the request
has been accepted, the mobile terminal SHOULD configure its routing
table appropriately for its current point of attachment.
4. The mobile terminal on registering from two different interfaces
and using the same foreign agent care-of address [Section 5.3] MUST
register to the home agent with the adjusted link-weight equal to sum
of the specified link-weights on each of those interfaces. In this
configuration, there is only one tunnel between the home agent and
foreign agent and the traffic for both the interfaces sent by the
home agent is sent on the same tunnel and so this adjusted link-
weight metric reflects the consolidated load for the tunnel.
5. The mobile terminal on receiving a registration reply with the
code set to either ERROR_HA_MULTI_INTERFACE_RTG_UNAVAIL or
Srinivasa Expires April 9, 2006 [Page 16]
Internet-Draft Multi-Interface Routing Support October 2005
ERROR_FA_MULTI_INTERFACE_RTG_UNAVAIL, MAY attempt to register using a
single interface as per the base Mobile IP specification [11].
6. The mobile terminal on receiving a registration reply with the
code set to either ERROR_HA_MULTI_INTERFACE_UNEQUAL_LD_UNAVAIL or
ERROR_FA_MULTI_INTERFACE_UNEQUAL_LD_UNAVAIL, MAY attempt to register
using a equal load-weight for all the interfaces.
6.2. Foreign Agent Operation:
As per the operation defined in the Mobile IP Protocol [11], when a
mobile terminal is using a foreign agent services and its care-of
address, the routing between the mobile terminal and the foreign
agent is based on layer 2 forwarding, using MAC address as the
communication end point identifier. In this model, there is an
association between the home address of the mobile terminal, its MAC
address and the tunnel from the foreign agent to the mobile terminal.
The capabilities that got extended to the mobile terminal by the way
of this specification is in the form of the ability for the mobile
terminal to use multiple interfaces and simultaneously connect to one
or more interfaces of the foreign agent as described in Section 5.
This requires a change at the foreign agent for maintaining an
association between a tunnel from the home agent, its interface where
the mobile terminal with a specific MAC address is anchored and the
home address of the mobile terminal. This foreign agent has to
establish the routing path keeping this relation.
1. Upon receipt of a registration request from a mobile terminal
attached to one of its interface advertising the foreign agent
service, the foreign agent SHOULD verify its policy database to check
if it configured to allow the multi-interface registration. If it
not configured to allow this service, the foreign agent MUST reject
the request with a registration reply and with the code set to
ERROR_FA_MULTI_INTERFACE_RTG_UNAVAIL, as explained in Section 4.2.
2. A foreign agent upon receipt of a registration request with the
Multi-Interface Routing extension from a mobile terminal, and if
there is an existing visitor list entry for the same home address,
but on a different interface, the foreign agent should setup the
routing path as described in Section 5.4.
3. A foreign agent upon receipt of a registration request with the
Multi-Interface Routing extension from a mobile terminal, and if
there is an exisiting visitor list entry for the same mobile terminal
identified by the home address and on the same interface, the foreign
agent should setup the routing path as described in Section 5.3. In
this scenario, there is 1 to many relation between the tunnel from
the home agent and the interface of the mobile terminal where the
Srinivasa Expires April 9, 2006 [Page 17]
Internet-Draft Multi-Interface Routing Support October 2005
flow from the tunnel terminates. The foreign agent should perform
the traffic load distribution between these two interfaces as
requested by the mobile terminal. If the foreign agent is not
capable of doing unequal load distribution, it MUST reject the
request with a registration reply and with the code set to
ERROR_FA_MULTI_INTERFACE_UNEQUAL_LD_UNAVAIL, as explained in Section
4.2.
6.3. Home Agent Operation:
As per the operation defined in the Mobile IP Protocol [11], the home
agent is required to maintain multiple bindings for a mobile terminal
when it is supporting simultaneous bindings for that registration.
When the home agent allows simultaneous bindings, it will tunnel a
separate copy of each arriving datagram to each care-of address, and
the mobile node will receive multiple copies of datagrams destined to
it. The operation defined in this specification allows a mobile
terminal to register from multiple interfaces using different care-of
addresses and have multiple tunnels from the home agent to each of
those care-of addresses and for distributing the traffic load across
those tunnels. This is slightly a different model than the
simultanous bindings when it comes to the datagram routing. However,
the basis ability for the home agent to associate a mobile terminal
with multiple care-of addresses remain to be the same.
1. A home agent upon receipt of a registration request with the
Multi-Interface Routing extension from a mobile terminal, SHOULD
verify its policy database to check if it is configured to allow the
Multi-Interface registration. If it not configured to allow this
service, the home agent MUST reject the request with a registration
reply and with the code set to ERROR_HA_MULTI_INTERFACE_RTG_UNAVAIL,
as explained in Section 4.2.
2. A home agent upon receipt of a registration request with the
Multi-Interface Routing extension from a mobile terminal, and with a
unequal load distribution metric, and if the home agent is not
capable of doing unequal load distribution, it MUST reject the
request with a registration reply and with the code set to
ERROR_HA_MULTI_INTERFACE_UNEQUAL_LD_UNAVAIL, as explained in Section
4.2.
7. Implementations
We have implemented this feature on Linux 2.6 Kernel. We might be
able to open source the implementation under GNU Licensing terms at a
later date, if this work gets accepted in the working group.
Srinivasa Expires April 9, 2006 [Page 18]
Internet-Draft Multi-Interface Routing Support October 2005
8. Traffic Flow Management
The document defines a simple "Link-Weight" based model for load
balancing the traffic across all the available interfaces on the
mobile terminal and that are participating in the Mobile IP routing.
It is possible to define more complex policies than what this
document supports. However, it comes at its own implementation
complexity. We have verified the approach chosen by this draft on
Linux and by using the IPTables architecture. We believe that this
approach is sufficient and serves the required purpose. We have also
allowed room for enabling new traffic management policies that can be
defined outside this document and still be applied when using the
Multi-Interface approach defined in this document, by simply ignoring
the Link-Weight field in the Multi-Interface Registration extension
of the Mobile IP Registration request.
9. IANA Considerations
The numbers for the extensions defined in this document have been
taken from the numbering space defined for Mobile IP registration
extensions and error codes defined in RFC 3344 [1]. This document
proposes one new extension and four new error codes that require type
numbers and an error code value that have been assigned by IANA. The
new extension also introduces a new sub-type numbering spaces to be
managed by IANA.
Section 4.1 defines a new Mobile IP extension, the Multi-Interface
Routing Request Extension. The type number for this extension has is
IANA-1 [IANA: TBD]. This extension introduces a new sub-type
numbering space where the value 0 has been chosen for this extension.
Approval of this new Multi-Interface Routing Extension sub-type
numbers is subject to Expert Review, and a specification is required
[7].
Section 4.2 defines a new error code, ERROR_HA_MULTI_IF_REG_UNAVAIL:
"Requested Multi-Interface Routing service unavailable at the home
agent", from the numbering space for values defined for use with the
Code field of Mobile IP Registration Reply Messages. Code number
IANA-2 [IANA: TBD] has been assigned from the subset "Error Codes
from the Home Agent".
Section 4.2 defines a new error code,
ERROR_HA_MULTI_IF_UNEQUAL_LD_UNAVAIL: "Requested Multi-Interface
unequal traffic load distribution unavailable at the home agent",
from the numbering space for values defined for use with the Code
field of Mobile IP Registration Reply Messages. Code number IANA-
5[IANA: TBD] has been assigned from the subset "Error Codes from the
Srinivasa Expires April 9, 2006 [Page 19]
Internet-Draft Multi-Interface Routing Support October 2005
Home Agent".
Section 4.2 defines a new error code, ERROR_FA_MULTI_IF_REG_UNAVAIL:
"Requested Multi-Interface Routing service unavailable at the foreign
agent", from the numbering space for values defined for use with the
Code field of Mobile IP Registration Reply Messages. Code number
IANA-3 [IANA: TBD] has been assigned from the subset "Error Codes
from the Foreign Agent"
Section 4.2 defines a new error code,
ERROR_FA_MULTI_IF_UNEQUAL_LD_UNAVAIL: "Requested Multi-Interface
unequal traffic load distribution unavailable at the foreign agent",
from the numbering space for values defined for use with the Code
field of Mobile IP Registration Reply Messages. Code number IANA-
5[IANA: TBD] has been assigned from the subset "Error Codes from the
Foreign Agent".
10. Security Considerations
This specification introduces a new Mobile IP extension that is used
to carry the Multi-Interface Routing request. The Mobile IP messages
that carry this extension MUST be authenticated as described in [7].
Therefore, this specification does not lessen the security of Mobile
IP Protocol.
11. Acknowledgements
We like to thank all those people who have discussed with us about
this approach and contributed to the improvement of this
specification.
We also like thank the Open Source community for enabling us to prove
this technique by extending the open source work and building on top
of it.
We acknowledge IETF for adopting a open community contribution model
and for enabling the technology evolution in the true spirit and with
the goal of making Internet better and available to one and all.
12. References
Normative References:
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
Srinivasa Expires April 9, 2006 [Page 20]
Internet-Draft Multi-Interface Routing Support October 2005
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[3] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[4] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[5] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[6] Montenegro, G., "Reverse Tunneling for Mobile IP, revised",
RFC 3024, January 2001.
[7] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[8] Levkowetz, H., Vaarala, S., "NAT Traversal for Mobile IP", RFC
3519, April 2003.
[9] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Informative References:
[11] Alvestrand, H., "A Mission Statement for the IETF, October
2004.
Srinivasa Expires April 9, 2006 [Page 21]
Internet-Draft Multi-Interface Routing Support October 2005
Author's Address
K. Srinivasa
Architect,
Net-Mobile India Ltd.
18-1-98/1, Yeshoda Nagar,
Tirupathi, AP 517501
India
Email: krsriniva@gmail.com
Srinivasa Expires April 9, 2006 [Page 22]
Internet-Draft Multi-Interface Routing Support October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Srinivasa Expires April 9, 2006 [Page 23]
