Internet DRAFT - draft-morioka-nemo-mrcoop
draft-morioka-nemo-mrcoop
NEMO Working Group H. Morioka
Internet-Draft ROOT Inc.
Expires : January 9, 2006 July 2005
Mobile Router Cooperation Protocol
draft-morioka-nemo-mrcoop-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 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This protocol intended to provide cooperation between mobile routers
in a mobile network. A mobile network is usually connected to the
Internet through mobile routers with wireless interfaces. Link
quality of the wireless interface changes frequently and rapidly. In
case of several mobile routers in a mobile network, MNN should use
the MR that has the best link quality. This protocol makes all MRs
in a mobile network share link quality of MRs each other. Propagation
of routing information in a mobile network is not out of sight of
Morioka Expires January 9, 2006 [Page 1]
Internet-Draft Mobile Router Cooperation Protocol July 2005
this draft.
1. Introduction
This protocol intended to provide cooperation between mobile routers
in a mobile network. A mobile network is usually connected to the
Internet through mobile routers with wireless interfaces. Link
quality of the wireless interface changes frequently and rapidly. In
case of several mobile routers in a mobile network, MNN should use
the MR that has the best link quality. This protocol makes all MRs
in a mobile network share link quality of MRs each other.
Propagation of routings in a mobile network is outside of scope of
this draft.
MR sends a packet, which is called "Link Metric Message",
periodically to all other MRs in the same mobile network. The packet
consists of link metrics with the interface identifier, the
timestamp, prefixes belonging to the MR and the hash value of the
packet. The link metric is decided from the link quality and the
pre-configured preference value. All MRs have a link metric table
which maintains link metrics of all interfaces of all MRs in the same
mobile network. When a MR receives a Link Metric Message, the MR
updates the link metric table and compare link metrics of all
interfaces. The MR selects a interface which has the largest metric.
The MR that has this interface sends binding update to the home agent
with all prefixes of the mobile network. And all routers should work
as this MR is the gateway by some routing protocols.
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 BCP 14, RFC 2119 [1].
Network Mobility - related terminology is defined in [2] and [3].
This document in addition defines the following terms.
Mobile Network Prefix
An IPv6 prefix delegated to a Mobile Router and advertised in
the Mobile Network. More than one Mobile Network Prefix could
be advertised in a Mobile Network.
3. Overview of the protocol
Morioka Expires January 9, 2006 [Page 2]
Internet-Draft Mobile Router Cooperation Protocol July 2005
The MR has a list of MRs which may be connected to the same mobile
network. The MR sends the link metric message that includes the link
quality of interfaces of the MR to other MRs periodically. All MRs
in the mobile network share the link metrics by the link metric
messages and maintain the link metric table by each MR. The MRs in
the same mobile network selects the MR that has the largest link
metric and make it as the gateway. Propagation of the routing in the
mobile network is not considered in this draft. But the routing can
change rapidly, so some routing protocols which work fast enough
should be used.
The MRs also exchange the prefixes of the mobile networks. So the
protocol supports connection and split of multiple mobile networks
autonomously which will occur in reassemble of train, for example.
4. Transport protocol
This protocol uses UDP.
5. Behavior of MR
5.1. Link Metric Table
Each MR maintains a link metric table. The link metric table
contains the link metrics, the interface identifiers, the IP
addresses of the ingress interface of MRs, the mobile network
prefixes and the last updated time. Each item in the table expires
in 300ms. For example, the link metric table will be as shown below.
+------------------+--------+------------+--------+---------+
| IP address of MR | Prefix | Interface | Link | Updated |
| | | Identifier | Metric | Time |
+==================+========+============+========+---------+
| | | | | |
| | | | | |
5.2. Sending Link Metric Message
The Link Metric Message (LMM) is sent by the MR periodically. The
interval of messages MUST NOT be greater than 300ms and SHOULD be
less than 100ms unless receiving ICMP Destination Unreachable
Message[4]. If the MR receives ICMP Destination Unreachable Message,
the MR MAY increase the interval of the messages up to 1 second.
Morioka Expires January 9, 2006 [Page 3]
Internet-Draft Mobile Router Cooperation Protocol July 2005
Each LMM includes link metrics with the interface identifier, a
timestamp, prefixes belonging to the MR and the hash value of the
packet.
LMM MUST include link metrics of all available egress interfaces of
the MR. An available interface means that it can communicate with
the point of attachment to the Internet with IP. Typically the
interface link is up and at least one IP address are assigned. Link
metrics of unavailable interfaces, which cannot communicate by IP,
MAY NOT be included in the LMM. Detail of the link metric is
described in later section.
An interface identifier is 16-bit unsigned integer. This is for
identification of interfaces of the MR sending the LMM. Each
interface in the MR MUST have a different interface identifier. The
interface identifier SHOULD NOT be changed during operation.
A timestamp is adjusted to the clock of the MR that receives the LMM.
A LMM can include multiple prefixes which belongs to the MR.
A hash value is calculated from the LMM itself.
5.3. Receiving Link Metric Message
When the MR receives a LMM, the MR work as described in this section.
5.3.1. Checking Timestamp
At first, the MR compare the timestamp of the LMM and it in the link
metric table. If the timestamp of the LMM is equal or smaller than
the timestamp in the link metric table, the LMM is silently
discarded.
If the difference between timestamp of the LMM and the clock of the
MR is greater than 5 seconds, the MR sends the Time Adjusting Message
described in later section to the sender of the LMM and discards the
LMM.
5.3.2. Checking Hash Value
The MR compares the hash value according to the hash type. If the
hash value does not match, the message is silently discarded.
5.3.3. Updating the Link Metric Table
When the MR receives a LMM, the MR MUST updates the link metric table
Morioka Expires January 9, 2006 [Page 4]
Internet-Draft Mobile Router Cooperation Protocol July 2005
and selects the interface that has the largest metric, that is called
primary interface, immediately. If multiple interfaces have the
largest metric, the primary interface is selected as following.
Upper condition has higher priority.
- The previous primary interface
- The interface belongs to a MR which has shorter mobile network
prefix length
- The interface belongs to a MR which has larger IP address as
128-bit unsigned integer
- The interface which has smaller interface identifier
5.3.4. Changing Gateway
If the primary interface is changed from the previous primary
interface, the MR MUST work as following.
The MR that has the primary interface MUST send the Binging Update to
the home agent and announce to the mobile network by some routing
protocols as the MR is the gateway. The Binding Update contains all
mobile network prefixes.
All other MRs also announce to the mobile network by some routing
protocols as the MR that has the primary interface is the gateway.
The MR that has the previous primary interface MUST stop sending
Binding Update.
5.4. Sending Time Adjusting Message
If the difference between timestamp of the received LMM and the clock
of the MR is greater than 5 seconds, the MR MUST send the Time
Adjusting Message to the sender of the LMM. The timestamp field of
the Time Adjusting Message is set to the clock of the sender.
5.5. Receiving Time Adjusting Message
If the MR receives Time Adjusting Message (described below) from the
correspondent MR, the MR SHOULD adjusts the timestamp after checking
the hash value.
If the hash value does not match, the message is silently discarded.
6. Message Format
Morioka Expires January 9, 2006 [Page 5]
Internet-Draft Mobile Router Cooperation Protocol July 2005
6.1. Link Metric Message
The format of Link Metric Message is described below.
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
+---------------+---------------+-------------------------------+
| Version | Reserved | Length |
+---------------+---------------+-------------------------------+
| |
+ Timestamp +
| |
+---------------+---------------+-------------------------------+
| Hash Type | Hash Length | Hash Value... |
+---------------+---------------+ +
| |
| |
+---------------------------------------------------------------+
| |
| Options |
| |
+---------------------------------------------------------------+
Version
8-bit unsigned integer indicates the version of this protocol.
Set to 1.
Reserved
This field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
Length
16-bit unsigned integer indicates the length in octets of the
message, including the version, reserved and the length field.
Timestamp
64-bit unsigned integer indicates the time of generating the
message. The MR MUST set this field to a 64-bit value
specified by the Network Time Protocol[5]. This value MUST be
greater than the timestamp value of any messages previously
sent to the receiver.
Hash Type
8-bit unsigned integer indicates the type of hash algorism.
The values shown below are decimal values.
1 keyed-MD5
Morioka Expires January 9, 2006 [Page 6]
Internet-Draft Mobile Router Cooperation Protocol July 2005
keyed-MD5 MUST be supported by all MRs.
Hash Length
8-bit unsigned integer indicates the length of the hash value
field in octets.
Hash Value
This field is hash value generated by the method indicated in
the hash type field and the length is indicated in the hash
length field.
Options
The options field follows the hash value field.
6.1.1. Link Metric Option
The format of the link metric option is described below. Multiple
link metric options can be included in a LMM.
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 | Interface Identifier |
+---------------+---------------+-------------------------------+
| Link Metric |
+---------------------------------------------------------------+
Type
Set to 1.
Length
8-bit unsigned integer indicates the length in octets of this
option, including the type and the length field. Set to 8.
Interface Identifier
16-bit unsigned integer indicates the interface of the MR.
This value is specified by the sender MR.
Link Metric
32-bit unsigned integer indicates the metric of interface.
This value is generated by the method described in later
section.
6.1.2. Prefix Option
The format of the prefix option is described below. Multiple prefix
Morioka Expires January 9, 2006 [Page 7]
Internet-Draft Mobile Router Cooperation Protocol July 2005
options can be included in a LMM.
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 | Reserved | Prefix Length |
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ Mobile Network Prefix +
| |
+ +
| |
+---------------------------------------------------------------+
Type
Set to 6.
Length
8-bit unsigned integer indicates the length in octets of this
option, including the type and the length field. Set to 20 in
decimal.
Reserved
This field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
Prefix Length
8-bit unsigned integer indicates the prefix length of the IPv6
prefix contained in the option.
Mobile Network Prefix
A 128-bit field containing the Mobile Network Prefix
6.1.3. Padding Option
The format of the padding option is described below. Multiple
padding options can be included in a LMM.
Morioka Expires January 9, 2006 [Page 8]
Internet-Draft Mobile Router Cooperation Protocol July 2005
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 |
+---------------+
Type
Set to 0.
6.2. Time Adjusting Message
The format of Time Adjusting Message is described below.
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
+---------------+---------------+-------------------------------+
| Version | Reserved | Length |
+---------------+---------------+-------------------------------+
| |
+ Timestamp +
| |
+---------------+---------------+-------------------------------+
| Hash Type | Hash Length | Hash Value... |
+---------------+---------------+ +
| |
| |
+---------------------------------------------------------------+
| |
| Options |
| |
+---------------------------------------------------------------+
Version
8-bit unsigned integer indicates the version of this protocol.
Set to 1.
Reserved
This field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
Length
16-bit unsigned integer indicates the length in octets of the
message, including the version, reserved and the length field.
Morioka Expires January 9, 2006 [Page 9]
Internet-Draft Mobile Router Cooperation Protocol July 2005
Timestamp
64-bit unsigned integer indicates the time of generating the
message. The MR MUST set this field to a 64-bit value
specified by the Network Time Protocol.
Hash Type
8-bit unsigned integer indicates the type of hash algorism.
The values shown below are decimal values.
1 keyed-MD5
keyed-MD5 MUST be supported by all MRs.
Hash Length
8-bit unsigned integer indicates the length of the hash value
field in octets.
Hash Value
This field is hash value generated by the method indicated in
the hash type field and the length is indicated in the hash
length field.
Options
The options field follows the hash value field. No options are
defined for now.
6.3. Hash Value
The hash value is used for authentication of the message. This pro-
tocol supports the following hash types.
6.3.1. keyed-MD5
In case of using keyed-MD5[6] for authentication, the hash value is
generated from the following byte stream with "prefix+suffix" mode.
- the shared secret defined between the MRs and by hash type,
followed by
- the message with hash value field filled by 0 excluding UDP
and IP headers, followed by
- the shared secret again
Then the hash value field is filled with the computed value.
7. Link Metric
The link metric is the sum of the link quality value of the interface
and the pre-configured preference value, with a exception. The
exception is the case the link quality value is 0. In this case the
link metric MUST set to 0.
Morioka Expires January 9, 2006 [Page 10]
Internet-Draft Mobile Router Cooperation Protocol July 2005
The link metric is 32-bit unsigned integer and the larger interface
metric means the interface has higher priority. If a metric is 0, it
means the interface is unavailable or will be going to be
unavailable, for example, the interface of multi-channel media will
start channel scan.
The link quality value is 16-bit unsigned integer. This value
changes dynamically according to the quality of the link. The MR
MUST set it to the value by the profile defined for the media by
other document.
The preference value is 32-bit unsigned integer and MUST NOT be
greater than 0xffff0000.
8. Security Consideration
The MR MUST filter the received messages by their source IP address
and the hash value for avoiding the attack of fake messages. Replay
attack is avoidable by using the timestamp.
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Manner, J. and M. Kojo, Eds., "Mobility Related Terminology",
RFC 3753, June 2004.
[3] Ernst, T., and H.-Y. Lach, "Network Mobility Support
Terminology", Work in Progress, October 2004.
[4] Conta, A., "Internet Control Message Protocol (ICMPv6) for the
Internet Protocol Version 6 (IPv6) Specification", RFC 2463,
December 1998.
[5] Mills, D., "Network Time Protocol (Version 3):
Specification, Implementation and Analysis", RFC 1305, March
1992.
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
Authors' Addresses
Morioka Expires January 9, 2006 [Page 11]
Internet-Draft Mobile Router Cooperation Protocol July 2005
Hitoshi Morioka
ROOT INC.
2-1-22-307 Momochihama,
Sawara-ku, Fukuoka
814-0001
Japan
EMail: hmorioka@root-hq.com
Morioka Expires January 9, 2006 [Page 12]
Internet-Draft Mobile Router Cooperation Protocol July 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.
Morioka Expires January 9, 2006 [Page 13]
Internet-Draft Mobile Router Cooperation Protocol July 2005
Morioka Expires January 9, 2006 [Page 14]
