wdiff rfc4908.original rfc4908.txt

No Specific
Network Working Group K. Nagami
Internet-Draft
Request for Comments: 4908 INTEC NetCore
Expires: November 16, 2007
Category: Experimental S. Uda
JAIST
N. Ogashiwa
INTEC NetCore
NOWARE, Inc.
H. Esaki
U.
University of Tokyo
R. Wakikawa
Keio University
H. Ohnishi
NTT
May 15,
June 2007

Multi-homing

Multihoming for small scale fixed network Small-Scale Fixed Networks
Using Mobile IP and NEMO
draft-nagami-mip6-nemo-multihome-fixed-network-04.txt Network Mobility (NEMO)

Status of this This Memo

By submitting this Internet-Draft, each author represents that

This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any
applicable patent or other IPR claims kind.
Discussion and suggestions for improvement are requested.
Distribution of which he or she this memo is aware
have been or will be disclosed, and unlimited.

IETF Note

This RFC is not a candidate for any level of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents Internet Standard. The
IETF disclaims any knowledge 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 fitness of six months
and may be updated, replaced, or obsoleted by other documents at this RFC for any
time. It is inappropriate
purpose and in particular notes that the decision to use Internet-Drafts publish is not
based on IETF review for such things as reference
material security, congestion control,
or to cite them other than as "work in progress." inappropriate interaction with deployed protocols. The list of current Internet-Drafts can be accessed RFC Editor
has chosen to publish this document at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list its discretion. Readers of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 16, 2007.

Copyright (C) The IETF Trust (2007).
this document should exercise caution in evaluating its value for
implementation and deployment. See RFC 3932 for more information.

Abstract

Multi-homing

Multihoming technology improves the availability of host and network
connectivity. Since the node and network behavior behaviors of mobile
networking and fixed networking are different, the different
architecture has and mobile networks
differ, distinct architectures for each have been discussed and
proposed. This document proposes
the a common architecture both for both
mobile and fixed networking
environment, environments, using the mobile IP [1] (RFC 3775)
and NEMO [2]. Network Mobility (NEMO; RFC 3963). The proposed architecture only
requires a modification of the mobile IP and NEMO so that multiple-CoA multiple Care-
of Addresses (CoAs) can be used. In addition, multiple HAs which Home Agents
(HAs) that are located in different place, places are required for
redundancy.

1. Motivation

Users of small-scale network networks need an easy method to improve the network
availability and to get load balance of several links by easy method. Multi-
homing links. Multihoming
technology is one of the solutions to improve the availability.
Conventional major multi-homing network uses BGP. But multihoming networks use BGP, but it has some
issues. Therefore, we propose a multi-homing multihoming architecture using the
mobile IP [1] and NEMO [2] for small-scale fixed network. networks.

1.1. General Benefits of Multi-homing Multihoming

In a multi-homing multihoming network environment, both users and network managers takes several benefits by
benefit from controlling out-going outgoing traffic, incoming traffic, in-
comming traffic or both
of them. Those benefits are listed described in the
draft [3] as the goals "Goals and benefits Benefits of multi-homing.
Multihoming" [3]. The following is a summary of those goals and benefits listed in the draft.
benefits:

o Ubiquitous Access

o Redundancy/Fault-Recovery

o Load Sharing

o Load Balancing

o Bi-casting

o Preference Settings

1.2. Problems to be Solved to Accomplish Multi-homing Multihoming

Several multi-homing multihoming technologies have been proposed so far.
Conventional major multi-homing network uses BGP. But multihoming networks use BGP, but it has some
issues
issues, as follows.

(1) Increasing route entries in the Internet

In the multi-homing multihoming environments, each user's network needs to
advertise its address block to all ISPs connected to them. If
multi-homed a
multihomed user connects to only one ISP, the ISP can advertise
routing information to aggregate them. But some multi-homed user
needs multihomed users
need to connect with different ISPs in preparation to be prepared for failure of
ISP. ISP
failure. In this case, ISPs need to advertise routing information
for
multi-homed user multihomed users without aggregation. Therefore, the number
of routing entries in the Internet is increasing one by one.

(2) Difficulty to efficiently use of using multiple links efficiently

It is not easy to control in-coming traffics incoming traffic in the case of the
conventional multi-homing multihoming architecture using BGP. Therefore, load
balancing of connected links is difficult.

1.3. Using the Architecture of Mobile IP and NEMO to Solve the Problems

Basically, the Mobile mobile IP (MIP) and the NEMO have been proposed for mobile
host
hosts or mobile network, however the networks; however, their architecture and the protocol of
them
can be used for fixed networks. The following problems
mentioned avobe can be solved by using the architecture networks and to solve the
protocol of them. problems mentioned
above. The details of the solution is being are described in the later section.

o increasing route entries in the Internet

o difficulty to efficient use multiple links sections
below.

Moreover, by using the architecture and the protocol of the MIP and the
NEMO, a the cost of network operation will be decreased. For instance,
in the architecture of the MIP and the NEMO, renumbering IP addresses when relocation of an
office or network equipments equipment is relocated becomes
needless in consequence of that unnecessary, as the
network address prefix used in by a user network in a Mobile mobile IP
environment is does not depend on the upstream ISP's network prefix.

2. Multi-homing Multihoming Architecture Using Mobile IP and NEMO

2.1. Mobile Network Includes Fixed Network

By their nature, NEMO and Mobile mobile IP must work with multi-homing by its nature. multihoming. This
is because mobile nodes need to use multiple links for improving to improve the
availability of network connectivity since the wireless link is not
always stable. Therefore, we propose that multihoming for fixed
nodes (routers and hosts) use uses the framework of NEMO and Mobile mobile IP.

2.2. Overview multi-homing network architecture using of Multihoming Network Architecture Using Mobile IP

Figure 1 shows the basic multi-homing multihoming network architecture. In this
architecture, a mobile router (MR), which is boarder a border router of multi-
homed the
multihomed network, sets up several tunnels between the MR and the HA
by multiple-CoA registration. A An HA or (or a router to which the HA belongs
advertise
belongs) advertises the user's network prefix (Prefix X in Fig.1) Figure 1)
to ISPs via the routing protocol. If the HA has several multi-homed network multihomed
networks (Prefix X and Y in Fig.1), Figure 1), they can advertise an
aggregated network prefix to ISPs. Therefore, the Internet routing
entries do not increase one by one when multi-homed user the number of multihomed
users is increased.

HA1
||(Advertise aggregated prefix X and Y)
|v
ISP
|
+------------------------+---------------------+
| The Internet |
+-+----------+--------------------+----------+-+
| | | |
ISP-A ISP-B ISP-A' ISP-B'
| | | |
| | | |
+--- MR ---+ +--- MR ---+
CoA1 | CoA2 CoA1|CoA2
| |
-------+--------- (Prefix X) -------+------ (Prefix Y)
Multihomed Network X Multihomed Network Y

Figure 1: advertisement Advertisement of aggregated prefixes

Packets to multi-homed multihomed users go to HA the HA, and the HA sends packets to
the MR using CoA1 and CoA2. The HA selects a route in which a CoA is
used. The route selection algorithm is out of for scope of this
document. This can improve the availability of the user network and
control an in-coming traffic
between going from the ISP and to the MR. In the basic
architecture, HA1 is the single point of failure. In order to
improve the availability of the user network, multiple HA is HAs are
needed. This is described in later section. Section 3.2.

Figure 2: packet forwarding Packet Forwarding by HA

3. Requirements for Mobile IP and NEMO

3.1. Multiple Care-of-Addresses (CoA) (CoAs)

Multiple Care-of-Addresses needs are needed to improve the availability and
to control in coming incoming and out going outgoing traffic. The current Mobile IPv6
and the NEMO Basic Support protocol does not allow to register registration of
more than one care-of address Care-of Address bound to a home address to the home
agent. Therefore, [4] is proposed proposes to extend the MIP6 and the NEMO Basic Support
to allow multiple care-of address Care-of Address registrations for the particular Home Address.
home address.

3.2. Multiple Home Agents

Multiple Home Agents should be geographically distributed across the
Internet, for the improvement of
Internet to improve service availability and for the load balancing
of the HA. When all the networks that have HA advertise the same
network prefix to their adjacent router/network, the traffic is
automatically routed to the nearest Home Agent from the view point viewpoint of
routing protocol topology. This operation has been already been proven
operational technology to
work in the area of web Web server application, applications, such as CDN (Contents
Delivery Network), regarding IGP with the Interior Gateway Protocol (IGP) and EGP.
Exterior Gateway Protocol (EGP).

In order to operate multiple HAs, all HAs must have the same
information such as binding information. This is synchronizes the synchronization
of database
databases among the HA. HAs. The HAHA protocol [5] introduces the
binding synchornozation synchronization among HAs. This is the same architecture as
I-BGP.
Internal BGP (IBGP). The database is synchronized by full-mesh
topology. In addition, in order to simplify operation of the HA, the
database is synchronized using star topology. This is analogy with I-BGP analogous to
the IBGP route reflector.

Figure 3: Architecture with HA redundancy Redundancy

4. Discussion on the Mailing List

4.1. Why does the proposed architecture use Proposed Architecture Uses NEMO protocols Protocols

The multihome multihomed architecture proposed in this draft document is basically
the same as the architecture of NEMO. Furthermore, NEMO protocols
meet to the requirements of the proposed architecture in this draft, document,
which are:

o The protocol can inform CoA, HoA, BID from be used by the MR to HA send information such as the
CoA, Home Address (HoA), and Binding Unique Identifier (BID) [4]
to the HA.

o The protocol can establish multiple tunnels between the MR and HA HA.

o The protocol support supports multiple HA HAs and can synchronize Binding
Caches among multiple HAs HAs.

The proposed multihome multihomed architecture uses NEMO protocols as one of
the applications of NEMO. Needless to say, using the NEMO protocol
is one of the solutions to accomplish the proposed multihome
architecture. Another solution is to propose a new protocol just
like NEMO. Nevertheless, such new a protocol will would have functions just same as
like those of NEMO.

4.2. Route Announcement from Geographically Distributed Multiple HAs

In the proposed architecture, the xSP (Multihome (Multihomed Service Provider)
is introduced. The xSP is a conceptual Service Provider and service provider; it doesn't
have to be connected to the Internet physically for all practical purpose.
purposes. xSP has one or more aggregatable mobile network prefixes.
xSP contracts with some ISPs that are physically connected to the
Internet. The purpose of this contract is to setup set up some HAs into in
those ISP's network. ISPs' networks. Those HAs announce the xSP's aggregated mobile
network prefixes. This means that HAs work just like border gateway
router,
routers, and this situation is the same as peering between the ISP
and xSP. In this case, the origin AS Autonomous System (AS) announced
from the HAs is the xSP.

On the other hand, multihome a multihomed user (small (a small office user or home
user)
contract contracts with the xSP to acquire a mobile network prefix from
the xSP. Each
multihome multihomed user has a an MR and multiple L3 connectivity
to the Internet via multiple ISPs ISPs, and the MR will establish multiple
tunnels to the HA. Since the user's mobile network prefixes are
aggregated and announced from the HA, the packets to the user's
mobile network will be sent to the nearest HA depending on global route
routing information at that time and time. The HA that received such packets
will forward those packets them to the user's network over the established multiple
tunnels.

This model of route announcement from multiple HA HAs is along compatible with
the conventional scalable Internet architecture architecture, and it doesn't have
scalability problems.

5. Implementation and Experimentation

We have implemented and experimented with the proposed architecture.
Currently, the system works well not only on our test-bed network,
but on the Internet. In our experimentation, the MR has two upstream
organizations (ISPs) and two Care-of-Addresses Care-of Addresses for each
organizations. organization.
The MR uses the multiple-CoA option to register the Care-
of-Addresses Care-of Addresses
to the HA.

6. Security considerations Considerations

This document describes requirements of multiple CoAs and HAs for
redundancy. It is necessary to enhance the protocol protocols of the MIP and
the NEMO
to solve the requirements. Security considerations of these
multihoming network networks must be considered in a specification of the each
protocol.

7. References

7.1. Normative References

[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.

[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.

7.2. Informative References

[3] Ernst, T., Montavont, N., Wakikawa, R., and E. Paik, E., Ng, C.,
Kuladinithi, K., and T. Noel, "Goals and Benefits of
Multihoming",
draft-multihoming-generic-goals-and-benefits (work Work in progress), Progress, February 2004.

[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration", draft-ietf-monami6-multiplecoa-02 (work Work in progress), February Progress, March 2007.

[5] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home
Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (work (HAHA)", Work in progress),
March 2006. Progress, February 2004.

Authors' Addresses

Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
Japan

Phone: +81-3-5565-5069
Fax: +81-3-5565-5094
Email:
EMail: nagami@inetcore.com

Satoshi Uda
Japan Advanced Institute of Science and Technology
1-1 Asahidai
Tatsunokuchi,
Nomi, Ishikawa 923-1292
Japan

Email:

EMail: zin@jaist.ac.jp
Nobuo Ogashiwa
INTEC NetCore
Network Oriented Software Institute, Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
190-2, Yoshii,
Yoshii, Tano, Gunma 370-2132
Japan

Email: ogashiwa@inetcore.com

EMail: ogashiwa@noware.co.jp

Hiroshi Esaki
The university University of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo 113-8656
Japan

Email:

EMail: hiroshi@wide.ad.jp

Ryuji Wakikawa
Keio University
Department of Environmental Information, Keio University.
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan

Phone: +81-466-49-1100
Fax: +81-466-49-1395
Email:
EMail: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/

Hiroyuki Ohnishi
NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan

Email:

EMail: ohnishi.hiroyuki@lab.ntt.co.jp

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, 78 and at www.rfc-editor.org/copyright.html, and
except as set forth therein, the authors retain all their rights.

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, THE IETF TRUST 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.

Intellectual Property

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.

Acknowledgment

Acknowledgement

Funding for the RFC Editor function is currently provided by the IETF
Administrative Support Activity (IASA).
Internet Society.