changes will adversely affect the Home Agent’s performance. This
also introduces a high level of instability in the home network. To
avoid this, the following should be considered when the bi-
directional tunnel is implemented:
- A tunnel interface is consistently assigned to each Mobile Router,
as long as it has a valid binding cache at the Home Agent.
- Every time the Mobile Router moves and updates the binding cache
entry, the bi-directional tunnel should not be torn down and set
up again. The tunnel end points should be updated dynamically
with the Mobile Router’s current Care-of Address.
- With a large number of interfaces, Hello packet processing may
become a burden. Therefore, the tunnel interface should be
treated as On-Demand circuits for OSPF [16].
B.2. OSPF Area Considerations
The following should be considered when the Home Network is
configured for running OSPF:
- The entire Home domain SHOULD NOT be configured as a single area
if a Home Agent supports Mobile Routers. At least the home
network should be configured as a separate area.
- The bi-directional tunnel interfaces to the Mobile Routers should
never be included in the same area as the backbone links.
For a more detailed discussion on configuring a home network for NEMO
Basic Support, please see [17].
One disadvantage of running OSPFv3 with NEMO Basic Support is the
possibility that the Mobile Networks will be told of the topology of
the entire home network, including all the fixed and Mobile Routers.
The only thing the Mobile Routers might really need is a default
route through the Home Agent.
To reduce the amount of routing protocol messages received by a
Mobile Router, one can configure each bi-directional tunnel to a
Mobile Router as a separate area. But this requires that the Home
Agent support a large number of OSPF areas if it supports a large
number of Mobile Routers, and it might not be possible with most
router implementations.
Another option is to configure multiple areas on the Home Link and
group a number of Mobile Routers into each area. This reduces the
number of areas that a Home Agent needs to support but also reduces
the amount of routing protocol traffic that a Mobile Router receives.
Authors’ Addresses
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
EMail: vijay.devarapalli@nokia.com
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252-8520
Japan
EMail: ryuji@sfc.wide.ad.jp
Alexandru Petrescu
Motorola Labs
Parc les Algorithmes Saint Aubin
Gif-sur-Yvette 91193
France
EMail: Alexandru.Petrescu@motorola.com
Pascal Thubert
Cisco Systems Technology Center
Village d’Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
France
EMail: pthubert@cisco.com
Full 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.
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.
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 IETF’s procedures with respect to rights in IETF 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.