Internet DRAFT - draft-baek-nemo-nested-ro
draft-baek-nemo-nested-ro
NEMO Working Group S. Baek
Internet-Draft J. Yoo
Expires: April 20, 2006 T. Kwon
Seoul National University
E. Paik
M. Nam
KT
October 17, 2005
Routing Optimization in the same nested mobile network
draft-baek-nemo-nested-ro-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 April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a nested NEMO Route Opimization (NNRO)
protocol for the communications between any two nodes in the same
nested mobile network. A nested NEMO Route Opimization message is
used to exchange the routing information between two mobile network
Baek, et al. Expires April 20, 2006 [Page 1]
Internet-Draft RO in the same nested mobile network October 2005
nodes in the same nested mobile network. The protocol is designed in
a way such that the mobility of the entire nested mobile network is
transparent to the nodes therein.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of NNRO Operation . . . . . . . . . . . . . . . . . . 4
4. Changes to Existing Protocol . . . . . . . . . . . . . . . . . 4
4.1 IPv6 Neighbor Discovery . . . . . . . . . . . . . . . . . 4
4.2 Conceptual Data Sturctures in Mobile Router . . . . . . . 5
5. Message Formats for Route Optimization . . . . . . . . . . . . 6
5.1 Nested NEMO Route Optimization Message . . . . . . . . . . 6
6. Operations of Mobile Routers . . . . . . . . . . . . . . . . . 8
6.1 Sending NNRO Messages . . . . . . . . . . . . . . . . . . 8
6.2 Updating Forwading Table . . . . . . . . . . . . . . . . . 8
6.3 Forwarding Packets . . . . . . . . . . . . . . . . . . . . 9
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 9
7.1 Compatability with VMN . . . . . . . . . . . . . . . . . . 9
7.2 Mobility Considerations . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Baek, et al. Expires April 20, 2006 [Page 2]
Internet-Draft RO in the same nested mobile network October 2005
1. Introduction
A mobile network (NEMO) is a network whose point of attachment to the
Internet varies as it moves about [1, 2]. A mobile network consists
of mobile routers (MRs) and mobile network nodes (MNNs). When the
mobile network changes its point of attachment, the MNNs can
communicate with corresponding nodes without need to know about the
movements. To do this, all traffic to and from MNNs is forwarded
through the bi-directional tunnel between the MR and MR's home agent
(HA). Therefore, sub-optimality occurs in the path between the two
nodes [3]. When the mobile network is nested, this sub-optimality is
amplified as all the traffic between two nodes should be routed
through the HAs of the nested MRs. Especially, when the two nodes
are within a nested mobile network, the sub-optimality is notable
although the two nodes are located within the same nested mobile
network. Besides, this sub-optimality causes the tunneling overhead.
This document proposes a nested NEMO routing optimization (NNRO)
protocol to improve the communication overhead between two MNNs
within the same nested mobile network. This protocol makes the
traffic between two MNNs in the same nested NEMO to be routed
directly without a traversing HAs of the nested MRs.
2. Terminology
MR
mobile router.
HA
home agent.
MNN
mobile network node. MNNs such as VMN and LFN are nodes in a
mobile network.
VMN
visiting mobile node. A VMN is temporarily attached to the MR's
subnet by obtaining its CoA from the mobile network prefix.
Baek, et al. Expires April 20, 2006 [Page 3]
Internet-Draft RO in the same nested mobile network October 2005
LFN
visiting mobile node. local fixed node. This belongs to the
mobile network and is unable to change its point of attachment.
3. Overview of NNRO Operation
An MR multicasts route optimization messages that contain reachable
destinations and their path metrics to the MR's one hop neighbor MRs.
The route optimization messages are transmitted by an IPv6 Link Local
Multicast to the MR's lower MRs in ingress interface and by an
unicast to the MR's upper MR in egress interface. After the neighbor
(lower and upper) MRs receive these route optimization messages, they
transmit not only their own information of reachable destinations but
also the received information from their neighbors. Consquently, the
information of mobile network prefixes is delivered to all of the MRs
in the nested mobile network.
Based on this information, the MRs in the nested mobile network
construct forwarding tables for the mobile network prefixes in the
nested mobile network. Each forwarding table has entries, each of
which contains the mobile network prefix, the path metric of the
destination, the next hop, and the life time of the entry. Before
the MR forwards packets through the bi-directional tunnel, it
searches the forwarding table. If the MR finds out an entry that
matches the destination of the packet, it forwards the packet to the
next hop MR, not performing the bi-directional tunneling with its HA.
Otherwise, the MR acts as specified in NEMO basic support protocol
[2].
4. Changes to Existing Protocol
The proposed NNRO protocol requires some modifications for NEMO basic
support protocol [2] and IPv6 Neighbor Discovery protocol [5].
4.1 IPv6 Neighbor Discovery
A new flag (N) is included in the Router Advertisement Message to
indicate to the MRs in the ingress interface whether the MR supports
NNRO protocol in the same nested NEMO or not [5].
Baek, et al. Expires April 20, 2006 [Page 4]
Internet-Draft RO in the same nested mobile network October 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|N| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Route Optimization in the same nested NEMO flag (N)
The N flag is set to indicate to the MRs in the egress interface
whether the sending MR supports the Route Opimization in the same
neseted NEMO.
For descriptions of the other fields in the message, see [5].
4.2 Conceptual Data Sturctures in Mobile Router
An MR maintains a Forwarding Table, described in section 3. The
Forwarding Table is a data structure that records the reachability to
the MNNs in the same nested mobile network. There is one entry per
each Mobile Network Prefix.
Each Forwarding Table Entry (FTE) conceptually contains the following
fields:
o The Mobile Network Prefix of the MRs in the same nested mobile
network. This field is used as the key for searching the
Forwarding Table for the destination address of a packet being
forwarded.
o The metric field is the cost at which the next hop MR can deliver
packets to the destination.
o The next hop field is the address of the MR to which packets are
forwarded.
Baek, et al. Expires April 20, 2006 [Page 5]
Internet-Draft RO in the same nested mobile network October 2005
o A lifetime value, indicating the remaining lifetime for this FTE.
The lifetime value is updated whenever NNRO messages are received.
5. Message Formats for Route Optimization
5.1 Nested NEMO Route Optimization Message
The Nested NEMO Route Optimization (NNRO) message is used by an MR to
notify other MRs in the same nested NEMO of a recheability for the
entries. Each MR that supports nested NEMO Route Optimization has a
process that sends and receives this NNRO message.
The NNRO message will use a new MH Type value (say 11). The format
of the Message Data field in the Mobility Header is as follows [4]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|R|P| | # of entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Forwarding Table Entry 1 (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Forwarding Table Entry N (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each Forwarding Table Entry (FTE) has the following format:
Baek, et al. Expires April 20, 2006 [Page 6]
Internet-Draft RO in the same nested mobile network October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mobile Network Prefix ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Metric | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Default (D)
The Default (D) bit is set by the sending MR when it sends NNRO
messages periodically.
Request (R)
The Request (R) bit is set by the sending MR to request that one
hop neighbor MRs should send its whole FTE.
Response (P)
The Response (P) bit is set when the MR responds to the NNRO
message with the R bit set.
# of entries
The number of entries indicates the number of entries in the NNRO
message.
Mobile Network Prefix
A sixteen-byte field containing the Mobile Network Prefix.
Prefix Length
Eight-bit unsigned integer indicating the prefix length of the
IPv6 prefix contained in the FTE.
Baek, et al. Expires April 20, 2006 [Page 7]
Internet-Draft RO in the same nested mobile network October 2005
Metric
Eight-bit unsigned integer indicating the cost to reach that
destination.
6. Operations of Mobile Routers
6.1 Sending NNRO Messages
The MR sends the NNRO messages to its ingress interface and its
egress interface periodically. When the MR sends NNRO messages to
its ingress interface and its egress interface, the source IP address
field of that packet is set to the HoA and the CoA of the MR,
respectively. When an MR starts its operation, there is only one
entry in the Forwarding Table, which contains its own mobile network
prefix. As the NNRO messages from other MRs propagates, the number
of entries FTE will be incremented.
An MR updates its Forwarding Table as described in Section 6.2. When
the Forwarding Table is updated, the MR sends the NNRO message
containing the updated FTEs immediately.
6.2 Updating Forwading Table
Initially, an MR has an entry about its Mobile Network Prefix in the
Forwarding Table. This entry has the minimum Metric value. When an
MR receives the NNRO messages from its neighbor MRs, it updates its
Forwarding Table based on the following criterion.
New FTE:
When an MR receives the FTE that is not in the its Forwarding
Table, it inserts a new entry for that destination.
Better Metric FTE :
When an MR receives an entry with a better metric, it modifies the
Metric and the Next Hop values of the existing entry.
Otherwise :
Otherwise, an MR ignores the FTE.
When inserting the new entries or modifying the exsting entries, the
MR sets the Next Hop to the source IPv6 address of the NNRO messages.
Baek, et al. Expires April 20, 2006 [Page 8]
Internet-Draft RO in the same nested mobile network October 2005
6.3 Forwarding Packets
When the MR receives a data packet, it searches the Forwarding Table
to find out entries that matches the destination IPv6 address of the
packet before the MR forwards the packet through the bi-directional
tunnel. If the MR finds out the matched entry, it forwards the
packet to the MR Next Hop in the Forwarding Table without tunneling.
Otherwise, the MR forwards the packet through the bi-directional
tunnel based on the NEMO basic support protocol [2].
7. Design Considerations
7.1 Compatability with VMN
Besides communication between an LFN and another LFN in the same
nested mobile network, the proposed NNRO protocol supports route
opimization between an LFN and a VMN or between a VMN and another
VMN. VMNs conforms to Mobile IPv6 protocol [4]. According to Moble
IPv6 protocol, a mobile node can establish optimal route through
binding uptate directly to the correspondent node. After the
procedure of binding update to the correspondent node, the
destination address of the packet is the CoA of the VMN using type 2
routing header when the LFN sends packets to the VMN in the same
nested mobile network. Therefore, the MR used by the VMN can forward
the packet to the VMN by searching the Forwarding Table.
7.2 Mobility Considerations
If the entire nested mobile network moves together and changes its
point of attachment, the additional operations in the nested mobile
network are not needed. The MRs in the nested mobile network are
transparent to this movement. However, if an MR in the nested mobile
network goes away, the topology of the nested mobile network is
changed, and the Forwarding Table Entry of the MR in the other MRs
will be deleted.
8. References
[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-03 (work in progress),
February 2005.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Ng, C., "Network Mobility Route Optimization Problem Statement",
draft-ietf-nemo-ro-problem-statement-01 (work in progress),
Baek, et al. Expires April 20, 2006 [Page 9]
Internet-Draft RO in the same nested mobile network October 2005
October 2005.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
Authors' Addresses
Sungmin baek
Seoul National University
Multimedia and Mobile Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9147
Fax: +82-872-2045
Email: smbaek@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~smbaek/
Jinkyu Yoo
Seoul National University
Multimedia and Mobile Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9147
Fax: +82-872-2045
Email: jkyoo@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~jkyoo/
Baek, et al. Expires April 20, 2006 [Page 10]
Internet-Draft RO in the same nested mobile network October 2005
Taekyoung Kwon
Seoul National University
Multimedia and Mobile Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9105
Fax: +82-872-2045
Email: tkkwon@snu.ac.kr
URI: http://mmlab.snu.ac.kr/~tk/
Eunkyoung Paik
KT
Portable Internet Team, Convergence Business Unit, KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Minji Nam
KT
Portable Internet Team, Convergence Business Unit, KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-6121
Fax: +82-2-526-5200
Email: mjnam@kt.co.kr
URI: http://mmlab.snu.ac.kr/~mjnam/
Baek, et al. Expires April 20, 2006 [Page 11]
Internet-Draft RO in the same nested mobile network October 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.
Baek, et al. Expires April 20, 2006 [Page 12]