Internet DRAFT - draft-ogashiwa-mip4-bid-extension
draft-ogashiwa-mip4-bid-extension
MIP4 Nobuo Ogashiwa(INTEC Netcore)
Internet-Draft Kenichi Nagami(INTEC Netcore)
Expires: January 1, 2006 Ikuo Nakagawa(INTEC Netcore)
Satoshi Uda (JAIST)
Ryuji Wakikawa(Keio Univ.)
Hiroshi Esaki(Univ. Tokyo)
Hiroyuki Ohnishi(NTT)
Jul 1, 2005
Binding Identifier Extension for Mobile IPv4
<draft-ogashiwa-mip4-bid-extension-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 January 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document specifies a new extension for Registration Request
message and Registration Reply message in Mobile IPv4. This
extension can be added by mobile mode and home agent to
Registration Request and Registration Reply messages. This
extension carries an identification of binding of a care-of
address.
Ogashiwa, et al. Expires January 1, 2006 [Page 1]
Internet-Draft BID Extension for MIP4 Jul 2005
1. Introduction
According to the current MIP4 specification, mobile node can register
multiple care-of addresses (CoA) to home agent. This can be done by
setting simultaneous binding bit ('s' bit) of Registration Request
message. This implies that the current MIP4 specification is
applicable to multi-homing.
The MIP4 specification document [RFC3344] also describes home
agent's behavior as follows:
"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."
In multi-homing environment, mobile node and home agent can use
multiple links efficiently by dividing or limiting flows or traffic
for each tunnel using additional systems implemented on home agent
and mobile node. However, home agent can not divide or limit flows
to appropriate tunnels without binding information of CoA and
network interface of mobile node.
This document specifies a new extension for use in Mobile IPv4.
This extension can be added by mobile node and home agent to
Registration Request and Registration Reply messages. This
extension carries an identification of binding of care-of address
of the mobile node. By using this extension, mobile node can inform
binding of coa and network interface of mobile node.
Furthermore, by using this extension, mobile node can modify
specific care-of address previously registered by single
Registration Request even if the home agent has several care-of
address registration for the mobile node.
This specification does not require any changes to deployed MIP4
implementations and the current MIP4 specification. Home Agent and
Mobile Node that does not support this extension can silently
discard messages which includes this extension.
2. 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.
Ogashiwa, et al. Expires January 1, 2006 [Page 2]
Internet-Draft BID Extension for MIP4 Jul 2005
3. Motivation
3.1 Multihoming Using Multiple Physical Links
As mentioned above, home agent and mobile node can use multiple
links efficiently by using additional system since each links has
different characteristics. For example, a user requires to use
low-latency link for latency-sensitive application such as VoIP and
use other links for other applications. In such situation, home
agent have to know bindings of care-of address and mobile node's
network interface due to split downstream traffic to appropriate
tunnels.
The mobile node can inform own binding of care-of address and
network interface by using Multiple Care-of Address Extension
proposed in this document. The discussion of the system to divide
or limit user traffic to multiple tunnels is out of scope of this
document.
The figure 1 and following configurations are example of use of
Multiple Care-of Address Extension. The BID which is assigned to
the binding carried in the Registration Request and Registration
Reply. In a mobile node, each network interfaces have one or more
BID.
i/f-1(BID1,low-latency, 32kbps)
+----------------+
+-++ +----+---+ +--+
|MN| |Internet+-----+HA|
+-++ +----+---+ +--+
+----------------+
i/f-2(BID2, high-latency 54Mbps)
Fig.1 Example Network
The MN and the HA's configuration is following:
Home Agent's Configuration:
MN, BID1, VoIP traffic
MN, BID2, other traffic
Mobile Node's Configuration:
i/f-1, BID1
i/f-2, BID2
The MN acquires CoA1 and CoA2 for i/f-1 and i/f-2, then the MN
send registration request messages to the HA, which include BIDs for
each interfaces. After that, HA's registration database becomes as
following:
Home Agent's Registration Database:
HoA, CoA1, BID1
HoA, CoA2, BID2
Ogashiwa, et al. Expires January 1, 2006 [Page 3]
Internet-Draft BID Extension for MIP4 Jul 2005
The HA knows the bindings of BID and CoA of the MN as above
database. The HA also knows appropriate filter rules bound to
each BIDs due to the HA's configuration so that the HA can apply
filter rules to HA's tunnel interfaces.
3.2 CoA Modification by Single Registration Request
The current MIP4 specification [RFC3344] doesn't define the
operation to modify a CoA previously registered to home agent. In
case of that the 'S' bit doesn't set, the distinct definition of
the modify operation is needless since the CoA registration will be
overrided by new one. In case of the 'S' bit set and several CoAs
are registered to the home agent, mobile node have to register a
new CoA, and then deregister the old CoA since the modify operation
is not defined.
When the mobile node modify the CoA previously registered to the
home agent by single operation, the home agent can keep
communication between the mobile node and correspondent
node. However, when the mobile node modify the CoA previously
registered to the home agent by multiple operation such as
deregister old one and register new one, the home agent cannot keep
communication between the mobile node and correspondent node.
When the number of CoA reach maximum limit, mobile node cannot
register new CoA. To avoid this, if the mobile node deregister old
CoA before register new CoA, mobile node and correspondent node can
not keep communication.
If mobile node can change CoA registered to the home agent by
single operation, home agent will be able to modify the mobile
node's CoA entry in own CoA database keeping communication between
mobile node and correspondent node.
Ogashiwa, et al. Expires January 1, 2006 [Page 4]
Internet-Draft BID Extension for MIP4 Jul 2005
4. Mobile IPv4 Multiple Care-of Address Extension
The format of the Multiple Care-of Address Extension is simple
extension structure defined in MIP4 specification [RFC3344]. This
extension is not skippable.
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 = TBD | Length = 2 | Binding Unique ID (BID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Type value for Binding Unique Identifier will be assigned
later. An 8-bit identifier of the option.
Length
The value MUST be always 2.
Binding Unique ID (BID)
The BID which is assigned to the binding carried in the
Registration Request and Registration Reply. BID is
16-bit unsigned integer. A value of zero is reserved.
5. Use of the Multiple Care-of Address Extension
5.1 Changes to current MIP4 specification
No changes is requiered for deployed implementations and current
MIP4 basic specification. Home Agent and Mobile Node that doesn't
support the Multiple Care-of Address Extension MAY silently discard
messages which include the Multiple Care-of Address Extension or
alternatively, Home Agent MAY return error code 128 ("reason
unspecified") defined in MIP4 specification [RFC3344].
Ogashiwa, et al. Expires January 1, 2006 [Page 5]
Internet-Draft BID Extension for MIP4 Jul 2005
5.2 Home Agent and Mobile Node's behavior
Following is mobile node's and home agent's behavior when they send
or receive Registration Request and Registration Reply.
mobile node:
o statically or dinamically decide binding unique indentifier per
mobile node's network interfaces or bindings.
o when send registration request, attach BID to the message using
Multiple Care-of Address Extension.
o when change specific CoA previously registered, send registration
request which include new CoA and appropriate BID.
home agent:
o when receive registration request which includes Multiple Care-of
Address Extension, if the home agent doesn't support the
extension, then return error code or, alternatively silently
discard the message.
o if home agent already know the BID then override old CoA by new
CoA. And then, home agent send registration reply message which
include Multiple Care-of Address Extension.
o if home agent doesn't know the BID then store the CoA and BID
into own database. And then, home agent send registration reply
message which include Multiple Care-of Address Extension.
When the Multiple Care-of Address Extension is added, the
simulutaneous binding bit should be set. If the simulutaneous
binding bit is not set, home agent and mobile node should ignore
the Multiple Care-of Address Extension and should act as
traditional home agent and mobile node described in the MIP4
specification [RFC3344].
6. Security considerations
This draft does not raise specific security issues beyond those of
existing Mobile IP protocols.
7. IANA Considerations
This specification reserves one number for the Multiple Care-of
Address Extension Section 3 from the space of numbers for
non-skippable mobility extensions defined for Mobile IPv4 [MIP4] at
http://www.iana.org/assignments/mobileip-numbers. The value 50 is
recommended for this extension.
References
[MIP4] C. Perkins, Ed. "IP Mobility Support for IPv4",
Ogashiwa, et al. Expires January 1, 2006 [Page 6]
Internet-Draft BID Extension for MIP4 Jul 2005
RFC 3344, August 2002.
Author's Addresses
Nobuo Ogashiwa
INTEC NetCore Inc.
1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
Email: ogashiwa@inetcore.com
Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
Email: nagami@inetcore.com
Ikuo Nakagawa
INTEC NetCore Inc.
1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
Email: ikuo@inetcore.com
Satoshi Uda
School of Information Science Japan Advanced Institute of
Science and Technology
1-1 Asahidai, Tatsunokuchi, Ishikawa, 923-1292, Japan
Email: zin@jaist.ac.jp
Hiroshi Esaki
Graduate School of Information Science and Technology,
The university of Tokyo
7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656, Japan
Email: hiroshi@wide.ad.jp
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa, 252-8520, Japan
Email: ryuji@sfc.wide.ad.jp
Hiroyuki Ohnishi
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585, Japan
Email: ohnishi.hiroyuki@lab.ntt.co.jp
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.
Ogashiwa, et al. Expires January 1, 2006 [Page 7]
Internet-Draft BID Extension for MIP4 Jul 2005
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.
Ogashiwa, et al. Expires January 1, 2006 [Page 8]
