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: 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]