21-06-0000-00-0000

IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0000-00-0000Title: Link Independent Multi-homing Date Submitted: Jan, 10, 2007Presented at IEEE 802.21 session #18 in LondonAuthors or Source(s): John Kaippallimalil, Liu YuanAbstract: This proposal identifies link independent multi-homing

as a solution to remaining connected for long sessions when multiple short range accesses are present. Multi-homing would provide the ability to associate two (or more) links and home them to one IP connection.

21-06-0000-00-0000

BackgroundCurrently there are a number of different access technologies to meet the QoS requirements of various applications, including bandwidth, load balance and etc. The need for handovers between these multiple access technologies and roaming between domains during a course of session is critical due to the characteristics of the access networks (long sessions, short range access that has not a ubiquitous coverage of an entire area, mobility and etc). Thus, reliable connections should be provided for enabling a session to move between these access networks in a manner that is transparent to the application.

IEEE 802.21 provides a solution to address handovers in between access networks in a technology independent manner, while reliable connections is presently not addressed in the context of multi-technology access networks and remaining always connected with a high level of mobility between these access technologies.

21-06-0000-00-0000

SolutionThis proposal identifies link independent multi-homing as a solution to remaining connected for long sessions when multiple short range accesses are present. The multi-homing is related to links since it involves homing in over more than one link for a single connection (IP, application). However, it is independent of any single link technology and should provide a solution for moving between links of different technologies.

Multi-homing would provide the ability to associate two (or more) links and home them to one connection from the IP network point of view. This capability would also enable the multi-homing server to forward packets based on policies. This proposal proposes extending IEEE 802.21 to include the multi-homing semantics for supporting discovery of multi-homing capable servers, link address association, homing policy handling and forwarding based on policy.

21-06-0000-00-0000

Solution

Terminal-A

Terminal-B

Access

ARIP Network

Access

AN2

AR

IP Network

IP Network

Access

AN3

GW

PNPN PNPNPN

(e.g. Home)

(e.g. Train)

GW

IP FlowLink level Flow

AN is the multi-homing point for

Terminal-B.

GW is the multi-homing point for

Terminal-A.

AN1

AN Access NodeAR Access RouterGW GatewayPN Personal Network

PNPN

Figure 1: Multi-link Homing

21-06-0000-00-0000

Figure 1 outlines the basic network structure. The IP network access server in the network is the AR. The aggregation networks between AN, AR are based on IP as well. Thus, ANs can snoop and forward IP packets. The access networks are based on various layer 2 technologies such as WiFi, WiMAX, LAN and other emerging technologies. Terminals have multiple radios, network terminations and connect to the access via their home or some other personal networks (PN) such as those in vehicles or public buildings.

Solution

21-06-0000-00-0000

The flow in Figure 1 shows an IP connection (solid blue line) between Terminal-A and Terminal-B that is not aware of link level multi-homing. Each of the terminals in the figure is capable of host based, link independent multi-homing that this proposal describes. This is denoted in the figure by two link connections (dashed red lines) to the link layer nodes (GW, AN). This kind of multi-homing allows the terminals to obtain redundancy or connection load balancing in a technology independent manner and transparent to the IP layer. The network and terminal negotiate to use the ‘closest’ node for multi-homing. For Terminal-A, GW is the closest node with multi-homing capability, and for Terminal-B, AN3 is closest. ‘Closest’ in this case is the node topologically closest to the terminal that is capable of handling the multi-homing functions: discovery, link address association, homing policy handling, forwarding based on policy.

Solution

21-06-0000-00-0000

Solution

Figure 2: Multi-homing Sequence.

APPL/IP

802.21Layer

MAC2

MAC1

MAC1, 2

802.21Layer GW

Terminal Multi-homing Server

802.21Layer

AR/DHCP

LEASE PER

IOD

Link Available

Attach Link DHCP Request

DHCP Offer

MIH Capability Discovery Request

MIH Capability Discovery Response

Link Available

Binding NAI and MAC addresses

Binding NAI and MAC addresses

Policies for NAI/Binding

21-06-0000-00-0000

Discovery, Selection of Multi-homing Server1. The terminal sends MIH capability discovery advertisement. In 802.21,

the current MIH capability discovery mechanism need to be extended to include discovering the multi-homing capabilities. The MIH Capability Discovery confirm primitives can be amended to support multi-homing information.

2. Terminal receives multiple MIH capability discovery responses from multi-homing servers.Currently, 802.21 architecture is not capable of representing a path. Multiple responses/selection would require this path capability.

3. Terminal selects ‘closest’ server. From responses received over multiple paths, terminal selects the closest common server.

Solution

21-06-0000-00-0000

SolutionSelection of Primary MAC AddressPrimary MAC address is selected from list of active links for the terminal. Primary MAC can be selected by configuration in terminal of the link with most coverage, or the terminal may learn this information based on usage patterns, or it may pick MAC at random and designate it primary. When a terminal moves and loses its previously designated primary MAC, it selects a new primary MAC address. The primary MAC is associated with the IPv4 (ARP) or IPv6 (neighbor discovery).

Associating of Multiple Link Addresses:Association of multiple addresses binds the NAI (Network Access Identifier) with MAC addresses.

21-06-0000-00-0000

Policy Based ForwardingPolicy based mechanisms can be used to associate filters with an association/binding. A filter is associated with the NAI in an (MIH) binding. Further work needs to determine if filters are useful in other areas in IEEE 802.21 than just multi-homing.For multi-homing described in this proposal, filters can be used to request the multi-homing server to forward packets based on the policies For example: Duplicate and forward on all links if link availability (signal strength) is not accessible. Load balance between available links if throughput required exceeds that of a single link. Select link based on lowest cost route when signal strength is acceptable.

Solution

21-06-0000-00-0000

Amendment to the current draftMIH_Bind.request ( SourceIdentifier, DestinationIdentifier, NAI,LinkIdentiferList, Action )

Name Type Valid Range DescriptionSource Identifier Identifier Any valid

individual or group identifier

The identifier of entity where the request is initiated. The field may be optionally left empty if the command is local.

Destination Identifyer Identifier Valid MIH identifier

The destination identifier of request or response. This is the identifier of local or peer MIHF.

NAI String N/A Network address Identifier that takes the form: username@realm.

LinkIdentiferList List Set of Link IDs List of link idendifers.Action Integer 0,1 Action of bind or unbind.

0: Unbind, 1: Bind

MIH_Bind.confirm ( ResponseLinkIdentiferList )Name Type Valid Range Description

Response Link Identifer List

List Set of Link IDs List of link idendifers along with their bind/unbind status.

21-06-0000-00-0000

Amendment to the current draftMIH_Capability_Discover.request (SourceIdentifier, DestinationIdentifier, LinkIdentifier, SupportedEventList, SupportedCommandList, SupportedISQueryTypeList, MultiHomingSupported)

Name Type Valid Range DescriptionMultiHomingSupported Boolean 0, 1 Flag to indicate whether the MIHF can

support Multi-homing.0 : Unsupported, 1 : Supported

MIH_Capability_Discover.confirm (SourceIdentifier, DestinationIdentifier, LinkIdentifier, SupportedEventList, SupportedCommandList, SupportedISQueryTypeList, MultiHomingSupported, Path)

Name Type Valid Range DescriptionMultiHomingSupported Boolean 0, 1 Flag to indicate whether the MIHF can

support Multi-homing.0 : Unsupported, 1 : Supported

Path N/A N/A Path from the source to the destination. The MIHF that sends MIH capability discovery requests can select proper MIHF according to received path information.

21-06-0000-00-0000

Advantages Each individual link/technology does not have to be ubiquitous. -Coverage can be made to seem even more seamless by enhancing the existing IEEE 802.21 handovers with multi-homing. Costs can be reduced by keeping each link technology simpler and not having to worry about additional reliability. Adaptive applications can take advantage of combined throughput of the links (load balancing). IP host based multi-homing needs to use mechanisms that have several issues to solve (For example, separation of location and identity, use provider based addresses and etc.). In essence, L2 based multi-homing is simpler for hosts.

21-06-0000-00-0000

IEEE 802.21 presentation release statementsThis document has been prepared to assist the IEEE 802.21 Working Group. It is

offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21.

The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>