NEMO Working Group F. Z. Yousaf
Internet Draft C. Wietfeld
Expires: January 2009 A. Tigyo
Communication Networks Institute,
Dortmund University of Technology
July 30, 2008
Nest Route Optimization for NEMO (NERON)
draft-yousaf-ietf-nemo-neron-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 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
IETF has proposed MIPv6 based Network Mobility (NEMO) Basic Support
protocol that handles the mobility management of IPv6 based mobile
networks. However the NEMO protocol has severe performance
limitations and does not specify the route optimization method for
Yousaf & Wietfeld Expires January 30, 2009 [Page 1]
Internet-Draft NERON July 2008
mobile networks and does not take into account the operational and
functional complexities involving nested mobile networks.
In this draft we present NEst Route Optimization for NEMO (NERON)
protocol, a light weight, efficient and scalable approach that aims
at enabling nodes behind nested mobile networks to use optimized
communication paths with zero tunneling overhead and minimum end-to-
end delay, irrespective of the depth of the nest, with minimum but
manageable changes to the base MIPv6 and IPv6 Neighbor Discovery
protocols and without introducing any new network entities.
Table of Contents
1. Requirements notation..........................................3
2. Introduction...................................................3
3. Terminology....................................................4
4. Assumptions....................................................4
5. Problem Statement..............................................5
6. Design Goals...................................................6
7. Network Mobility Background....................................6
7.1. General Handover Process in Mobile Networks...............6
7.2. Non-optimum Packet Routing in Mobile Networks.............7
8. NERON Protocol Overview........................................8
8.1. Nest Formation and Mobile Network Gateway Discovery.......8
8.1.1. Loop Avoidance and Nest Depth Identification.........9
8.2. Route Notification.......................................10
8.3. Return Routability and Binding Registration..............11
9. Data Communication between MNN and CN.........................11
9.1. When CN Is Part of the Internet Infrastructure...........12
9.1.1. MNN Sending Packets to CN...........................12
9.1.2. CN Sending Packets to MNN...........................12
9.2. When CN and MNN Share the Same Mobile Network Domain.....13
10. Data Structures..............................................13
11. Message Formats..............................................14
11.1. Type-3 Routing Header...................................14
11.2. Modified Neighbor Discovery Messages and Options........16
11.2.1. Modified MIPv6 Router Advertisement Message........16
11.2.2. Modified Neighbor Advertisement Message............17
11.2.3. Modified Prefix Information Option.................18
11.3. New Message Options.....................................19
11.3.1. Mobile Network Gateway Option......................19
11.3.2. Route Notification Option..........................21
11.3.3. Nest Gate Option...................................23
12. Security Considerations......................................23
13. IANA Considerations..........................................23
14. Conclusions..................................................24
15. Acknowledgments..............................................24
Yousaf, Wietfeld Expires January 30, 2009 [Page 2]
Internet-Draft NERON July 2008
16. References...................................................24
Author's Addresses...............................................25
Intellectual Property Statement..................................26
Disclaimer of Validity...........................................26
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
2. Introduction
IETF's Network Mobility (NEMO) Basic Support Protocol [2] proposes
the mobility management protocol for Mobile Networks which enables
Mobile Network Nodes (MNN) inside the Mobile Network behind a Mobile
Router (MR) to communicate with Correspondent Node CN(s) via a
bidirectional tunnel maintained between the MR and its Home Agent
(HA). Thus [2] doesn't redress and specify the route optimization
(RO) solution that would enable direct communication between MNNs and
CN(s) over optimized paths without involving any tunnels and
bypassing the HA(s) associated with MR(s).
The performance issues linked to the absence of any RO solution in
mobile networks, which has been detailed in [3], becomes more
conspicuous in case of nested mobile networks and gets compounded
with every incremental increase in the nest depth.
RFC 4889 [4] gives a very detailed account of the solution space of
RO in Mobile networks and nested mobile networks by encompassing the
different issues and scenarios referenced in [3].
There are solutions available that address either complete or part of
the RO issue in nested Mobile networks but the common goal of any
solution is to enable a RO solution which fulfills the requirements
specified in [3] and [4].
However a close review of the proposed solutions, which would be
referenced in the subsequent sections, reveals that the RO solution
for nested mobile networks has the tendency of being over-engineered
by over estimating the architectural scope of a mobile network, which
in fact is limited within very closed and well defined confines of
mobile entities such as cars, busses, trains, aircrafts, ships, etc.
In such an environment the size of the Mobile network can not exceed
beyond a certain constant limit (in terms of nodes) and degree of
complexity (in terms of network architecture). A conservative
Yousaf, Wietfeld Expires January 30, 2009 [Page 3]
Internet-Draft NERON July 2008
estimate is that the probability of the nest depth to increase beyond
a nest depth of 3 is very small.
With this perspective in consideration, we propose Nest Route
Optimization in NEMO (NERON) which is a light weight, efficient and
scaleable RO solution for nested, non-nested and intra-NEMO mobile
network scenarios and is designed within the boundaries defined in
[3] and [4]. NERON is light weight in the sense that it does not
introduce any new network entities and utilizes the available MIPv6
[5] and IPv6 Neighbor Discovery [6] protocol messages with minimum
but manageable changes to them.
3. Terminology
This document assumes that the reader is familiar with the mobility
related terms defined in [5] and [7], and particularly with the
network mobility terms introduced in [8]. The user must also be
familiar with the terms defined in IPv6 Neighbor Discovery Protocol
as defined in [6].
The following term is used additionally in this document.
NEMO Prefix:
The on-link prefix(es) advertised by the nested MRs as part of
the Route Notification Process.
4. Assumptions
There are RO solutions proposed in the context of nested mobile
networks like MANEMO [9], ONEMO [10], MIRON [11] being more
prominent. However a close review of the proposed solutions reveal
that the RO solution has the tendency of being over-engineered by
over estimating the architectural and functional scope of a mobile
network, which in fact is limited within very closed and well defined
confines of mobile entities such as cars, busses, trains, aircrafts,
ships, etc. In such an environment the size of a mob network can not
exceed beyond a certain constant limit (in terms of nodes) and degree
of complexity (in terms of network architecture). A conservative
estimate is that the probability of the nest depth to increase beyond
a nest depth of 3 is very small.
Also MIPv6 is now becoming a standard part of an OS kernel, such as
Linux, and therefore it is safe to assume that in the very near
future all nodes will have inherent support for MIPv6.
Yousaf, Wietfeld Expires January 30, 2009 [Page 4]
Internet-Draft NERON July 2008
With the above considerations in perspective the following
assumptions are made while proposing the NERON solution:
o The mobile network environment is limited in terms of size and
number of users.
o The MNN are assumed to be fixed LFN with no mobility support.
Although NERON operation makes provision for MIPv6 capable VMN to
travel as part of the mobile network however its position in the
domain of the mobile network is depth independent.
o The Correspondent Node (CN) is MIPv6 aware. This eliminates the
need to introduce Correspondent Router (CR).
o The CN is a fixed node, either in the Internet or sharing the same
mobile network domain as the corresponding MNN.
o The root-MR (rMR) will connect to the infrastructure network with
a single egress interface.
o The visiting MR will connect to the rMR forming a hierarchical
nested architecture rather than a flat configuration.
5. Problem Statement
The current NBSP [2] does not specify any RO mechanism and the
problems and issues related to the absence of any RO mechanism with
reference to mobile networks is listed in detail in [3].
According to [3], all data packets to and from the MNNs are tunneled
through the HA of its MR i.e., over sub-optimal routes, even though a
shorter and more optimized path may exist between the MNN and the CN.
In case of nested mobile networks, these data packets then traverse
multiple HAs with multiple levels of encapsulation. This would limit
the overall performance and give rise to various performance which
are summarized as follows:
1. Longer routes leading to increased delay and additional
infrastructure load posing crucial problems for real-time
applications and video streaming.
2. Increased susceptibility to link failures due to the packets
traversing longer routes.
3. Increase packet overhead due to tunneling and maintaining tunnels
within tunnels thus reducing the overall bandwidth efficiency.
Yousaf, Wietfeld Expires January 30, 2009 [Page 5]
Internet-Draft NERON July 2008
4. Increased processing delay due to successive encapsulation and
decapsulation.
5. Increased probability of packet fragmentation due to successive
tunneling of packets leading towards non-negligible packet loss.
6. Design Goals
The design goal of NERON is to develop a light-weight and scalable RO
solution by utilizing and leveraging the existing MIPv6 [5] and IPv6
Neighbor Discovery [6] protocols with minimum but manageable changes
to them and without introducing any additional network entity and/or
third party support protocol(s).
The solution space of NERON encompasses all the major considerations
and requirements defined in [4] and summarized as follows:
o To enable the intercommunication between MNN and corresponding
CN(s) over optimized paths without requiring to traverse any and
all HA(s) irrespective of the nest depth.
o Enable direct intra-communication between MNN and CN when CN may
exist within the same domain of the mobile network as the MNN.
o To completely eliminate the possibility of establishing any
tunnels between any network entities involved in the
infrastructure.
o Reuse existing protocols such as MIPv6 and IPv6 Neighbor Discovery
protocol with minimum changes to the existing messages and network
infrastructure.
o Abstain from introducing any new network entities or changes that
would require drastic changes in the network infrastructure.
7. Network Mobility Background
In this section we give a summarized account of how NEMO protocol
manages the handover of mobile networks and how data packets are
routed between the CN(s) and MNN(s).
7.1. General Handover Process in Mobile Networks
According to [2], a mobile network consists of several MNNs attached
to a MR's ingress interface whereas the MR connects the mobile
network to the Internet via its egress interface. The MNNs are
unaware of the mobility of the mobile network.
Yousaf, Wietfeld Expires January 30, 2009 [Page 6]
Internet-Draft NERON July 2008
When a mobile network is at its home network, it is identified and
reachable via its Home Address (HoA), which is auto-configured [12]
or assigned [13] on the MR's egress interface based on the Home
Agent's (HA) advertised address prefix on the home link. The prefix
advertised on the MR's ingress interface inside the mobile network is
called a Mobile Network Prefix (MNP), which is delegated from the
subnet owned by the HA, and the MNNs configure their addresses with
the advertised MNP. When the Mobile Network is away from its home
network, the MR configures a Care-of-Address (CoA) on its egress
interface only according to the prefix advertised by the access
router (AR) of the visit network infrastructure whereas the address
of the MR's ingress interfaces, and hence those of the MNNs remain
unchanged. The MR will register its CoA with its HA through an
exchange of binding update (BU) and binding acknowledgment (BA)
message pair, and the HA will in turn create a binding between the
MR's CoA and its respective MNP(s) with the MR's Home Address (HoA),
all conveyed by the BU message, in a locally maintained cache called
Binding Cache (BC). After a successful binding, a bi-directional
tunnel is created between the HA and the MR. A packet addressed to a
MNN is first routed to its HA, which will intercept the packet and
tunnel it to the CoA of the MR, which in turn will decapsulate the
outer header of the packet and forward it to the MNN. In the reverse
direction the MR will encapsulate the packet originating from the MNN
and tunnels it to its respective HA, which in turn will decapsulate
the outer header of the packet and forward it to the destination
based on Internet routing mechanism.
7.2. Non-optimum Packet Routing in Mobile Networks
The basic task of NEMO Basic Support Protocol (NBSP) is to utilize
the MIPv6 protocol operation and integrate it into the realm of
mobile networks, however this introduces severe performance
limitation in terms of sub-optimal communication paths for packets of
the MNN as it has to traverse, in both directions, the MR's HA via a
bidirectional tunnel established between the MR and its corresponding
HA. This sub-optimal routing of packets, also called 'triangular
routing', is due to the fact that [2] does not specify any RO
mechanism; a mechanism enabling MNN(s) and CN(s) to communicate
directly over optimum routes as determined by generic Internet
routing protocols and bypassing any or all HAs minimizing the
possibility of establishing and maintaining tunnel(s) between the MNN
and CN(s). The problems associated with sub-optimal routing have
already been highlighted in section 5 above.
This problem gets compounded when other MRs (and hence mobile
networks) attach behind another MR (or mobile network) in a
hierarchical fashion forming a larger mobile network. In such a
Yousaf, Wietfeld Expires January 30, 2009 [Page 7]
Internet-Draft NERON July 2008
cluster of mobile networks a MR that has connectivity to an
infrastructure AR is called a root-MR (rMR) and the MR behind the rMR
is called a nest-MR (nMR), and such a topology is termed as ``nest
topology'' and the network is called nested mobile network [8].
Although NBSP does not prevent the formation of such a nested
architecture but, in the absence of any RO mechanism, when a CN
communicates with a MNN located behind a nMR. (where . is the depth
of the nest and rMR, which acts as a gateway to the nested mobile
network, is considered at depth .=0), the packets of the MNN will
traverse over (.+1) HAs (i.e., through the HAs of all the upper level
mobile networks present in the nest chain) thereby undergoing (.+1)
encapsulations/decapsulations in both directions. This problem gets
exacerbated especially in the case of two inter-communicating MNNs
belonging to different nMRs but located within the same rMR domain.
In such a case the number of encapsulations undergone by a packet
will double than the case when the MNN is communicating with a
Correspondent Node (CN) outside its mobile network domain. This is
also called "pin-ball" routing problem [4].
8. NERON Protocol Overview
The NERON protocol proposes a MIPv6 based RO solution which is
independent of the nest depth. The NERON process, similar to other RO
solutions such as MANEMO [9] and ONEMO [10], consists of the
following three essential steps namely;
o Nest formation and mobile network gateway discovery.
o Route notification within the rMR nested domain.
o Return Routability and binding registration.
The proceeding sub-sections will elaborate the above three essential
operational steps.
8.1. Nest Formation and Mobile Network Gateway Discovery
It is important for a visit MR (VMR) to detect the presence of a
Mobile Network domain behind which it can nest and acquire not only
the address of the rMR's egress interface, as this will be the
gateway for all the nMRs nested behind rMR, but also compute its
position in terms of the depth in the the nested architecture.
When a mobile network, such as a PAN, enters the domain of another
mobile network, it has to first detect and connect to the rMR as
nMR. The nMR will be able to distinguish a MR from a regular AR based
Yousaf, Wietfeld Expires January 30, 2009 [Page 8]
Internet-Draft NERON July 2008
on the status of the R-flag carried by the periodically advertised RA
message. When set it will indicate the AR is acting as a MR in which
case the RA's are advertised periodically over the ingress
interface(s) only and received and processed by the egress
interface(s). The RA MUST also carry the new Mobile Network Gateway
(MNG) option (see section 11.3.1) which conveys the rMR's depth in
the nest (which is 0 by default) and also the address assigned to its
egress interface (which can be a HoA or CoA, depending on the rMR
location). The receiving nMR will cache the rMR's egress interface
address and the incremented value of the "depth" parameter in its
two-field Nest Gate Table (NGT) (see section 10).
A non-zero Nest-Position value in the local NGT implies that the MR
is nested behind a MR as nMR at a depth indicated by the Nest-
Position value (see section 10).
The nMR in turn MUST include the entry of its local NGT in the
appropriate fields of the MNG option of the RA messages advertised
periodically over its respective ingress interface(s). In other words
the nMR will relay the assigned address of the rMR's egress interface
to other nMRs deep inside the nest which in turn will relay it
further deeper in the nest using the RA message and this relaying
will continue till the last MR in the nest. All nMRs will also store
an incremented value of the received Depth field (D-Field) value in
the MNG option indicating its depth and position in the nest. In
this way all nMRs will not only compute their position in the nest
but will also be informed of the rMR's egress interface address that
will be stored by the nMRs in their respective NGT.
8.1.1. Loop Avoidance and Nest Depth Identification
Since the egress interface of a MR will be able to listen to the RA
messages advertised not only from its local ingress interface(s) but
also by the ingress interface(s) of the nMR(s), there is a
possibility of the MR to form loop either with itself or with its
nMR. To achieve loop-less connectivity the MR will compare the
advertised prefix(es) with its home prefix and also with the nest-
depth value in the NGT. If the advertised "depth" value is greater
than the value stored in the local NGT and/or if the advertised
prefix matches the home prefix of the egress interface, then in such
case(s) the MR will drop/ignore the RA and not attempt connection
with the MR. NERON specifies that only the egress interface of the MR
should configure CoA as it roams whereas the ingress interface(s)
address(es) should remain the same as acquired at the home network.
At the home network of a MR, both ingress and egress interface will
configure addresses using the prefix of the home agent.
Yousaf, Wietfeld Expires January 30, 2009 [Page 9]
Internet-Draft NERON July 2008
In order to prevent against race condition i.e., in situation when
both MRs will be advertising depth value of 0 in its MNG option, then
this will be decided by the state of the P-flag in RANG option (See
section 11.3.1 for details).
In comparison to NERON, the MANEMO project follows the TD [14]
protocol to achieve the above tasks but it uses a much larger and
complex 32B Tree Information Option (TIO) with further 5 different
sub-options (potentially increasing the size of TIO sub-option to an
additional 34B) in its RA message. The extensive and complicated TIO
sub-option not only accounts for large size RA messages but also
accounts for complexity in terms of logic processing. In contrast
NERON uses a 20B fixed size MNG sub-option accounting for smaller RA
packets and straightforward processing of the RA message. A similar
approach is adopted by ONEMO [10] but ONEMO does not specify how a MR
will compute its position in the nest and how to ensure loop-less
connectivity.
The decision mechanism of the MR concerning preferred rMR is out-of-
scope of this work and hence should rely on some decision algorithms.
8.2. Route Notification
This is a crucial process that would furnish the routing tables of
MRs, within a nested domain, with the information necessary to route
data packets between CN and MNN irrespective of the depth of the MNN.
After the VMR nests behind a rMR and updates its NGT, it will send an
Unsolicited Neighbor Advertisement (UNA) message [6] over its egress
interface with the Override flag (O-flag) set to 0. This UNA will
convey the respective nMR's egress interface's link local address and
respective MNPs embedded in the newly defined "Route Notification
Option" (RNO) (see section 11.3.2).
A MR upon receiving the UNA on one of its ingress interface will
update its local routing table with the MNPs carried by the UNA and
assign/specify the corresponding link local address carried by the
same UNA message as the next hop address to reach the listed MNPs. If
the receiving MR is a nMR (in case depth value listed in local NGT is
not 0), it will relay the UNA to the next higher MR by replacing the
previous nMR's link local address with the link local address of its
own (the relaying MR) egress interface leaving the MNP entries
untouched. The next higher MR upon receiving the UNA will add/update
its routing table and relay it to the next higher MR as explained
above. In this way the routing tables of all the MR will get updated
with all the MNPs that are present in the nest and an appropriate
Yousaf, Wietfeld Expires January 30, 2009 [Page 10]
Internet-Draft NERON July 2008
next hop address will also be assigned for correct routing of the
packets.
A Relay flag (R-Flag) is added to the RNO which when set will
indicate to the next higher MR to relay the MNP carried by the RNO to
the next higher MR in the nest chain in case it is not a rMR.
The UNA is transmitted on the egress interface(s) and received and
processed on the ingress interface(s).
In contrast to a much simpler and smaller RNO, NINA [15] uses a new
NA message termed as Network In Node Advertisement (NINA) to relay
the MNPs up the tree. NINA is a NA message with a 32B Network In Node
Option (NINO) as compared to 24B Route Noticiation option which is
less complex than NINO. Also NINA/NINO depends on the Tree Discovery
protocol [14] before it can relay the MNPs.
8.3. Return Routability and Binding Registration
As proposed in [2] and specified in MIRON [11], NERON uses the MIPv6
based Return Routability (RR) procedure [5] but unlike MIRON its
performance is independent of the nest depth.
In NERON, the MR of the MNN will perform home registration with its
HA as specified in [2]. After successful home registration, the MR
will perform MIPv6 specified RR procedure on behalf of the MNN as
specified in [11]. After a successful RR procedure with the CN, the
nMR, on behalf of the MNN, will send a BU carrying the rMR's address
(accessed from its NGT) in the newly defined Nest Gate Option (NGO)
(see section 11.3.3). It should be noted that the BU is triggered
every time the entry in the NGT changes indicating a handover of the
Mobile Network. The CN upon receiving the BU, will process it as
specified in [2] and [11] and additionally it will extract the
address carried in the NGO and records the rMR's address in its
Binding Cache (BC) entry. The CN will send a Binding Acknowledgment
thus completing the RO and correspondent registration process.
9. Data Communication between MNN and CN
After the mobile network has handed over and RO process completes,
the packets between MNN and CN will then flow over optimized paths
bypassing any and/or all HA(s) without any tunneling over head. NERON
address the following two scenarios in terms of data communication
between CN and MNN:
o When CN is part of the Internet infrastructure.
Yousaf, Wietfeld Expires January 30, 2009 [Page 11]
Internet-Draft NERON July 2008
o When CN and MNN share the same mobile network domain.
It should be noted that the CN in both cases are assumed to be non-
mobile i.e., a standard host in the Internet or an LFN in the mobile
network (see section 4).
9.1. When CN Is Part of the Internet Infrastructure
The communication flow between CN and MNN over optimized path is as
follows:
9.1.1. MNN Sending Packets to CN
When a MR receives a packet from its MNN destined to the CN, it will
replace the source address of the IPv6 header with the CoA assigned
to its egress interface and put the address of the MNN in the Home
Address Destination option [5]. All the other nMRs on the path to the
rMR will simply forward this packet until it reaches the rMR. The rMR
will then forward the packet normally to the CN and hence the packet
arrives at the CN with no encapsulation and via a direct optimized
route bypassing the HAs.
9.1.2. CN Sending Packets to MNN
When a CN wants to a send a packet to a nested MNN, it will first
search its BC for a valid cached entry for the packet's destination
address. If the packet's destination address is found listed in the
BC, the CN will then check if a Nest Gate entry (see section 10)
exists for the destination. If a valid Nest Gate address is present
in the BC, the CN knows that the MNN resides inside a nested mobile
network and composes the packet as follows;
o The source address field in the IPv6 header is set to the CN
address.
o The destination address field in the IPv6 header is set to the
Nest Gate address found in the BC entry.
o The CoA of the nMR found in the BC entry corresponding to the
MNN's destination prefix, and the MNN destination address are
contained in the newly defined Type 3 Routing Header (T3RH)
address vector (see section 11.1). The T3RH gets processed only by
the destination router.
When receiving the packet with a T3RH, the rMR replaces the
destination address with the nMR's CoA found in the T3RH address
vector. Since inside the nest routes have already been exchanged
Yousaf, Wietfeld Expires January 30, 2009 [Page 12]
Internet-Draft NERON July 2008
between the MRs as part of the route notification process (see
section 8.2), the rMR, and the subsequent MRs nested behind the rMR,
will route the packet to the destination nMR using standard routing
algorithm. The destined nMR will then replace the packet's
destination address with the address of the MNN carried inside the
T3RH address vector and the packet eventually gets delivered to the
MNN without any tunneling over head.
9.2. When CN and MNN Share the Same Mobile Network Domain
If the MNN and CN are connected behind different MRs that are
connected to the same nested mobile network, that is they share the
same rMR domain, then without RO, the intercommunicated packets will
leave the mobile network to be tunneled back into the same mobile
network following a pinball route [3].
NERON solution inherently provides reachable destinations to all MRs
inside the nest connected to the rMR by a combination of Route
Notification process described in section 8.2 and by advertising off-
link prefixes (NEMO prefixes), prefixes of other MRs inside the nest,
received via the Route Notification process in the prefix information
option of the RA message.
When advertising the NEMO prefix in the prefix information option
[6], both the On-link flag (L-Flag) and the Autonomous Address-
Configuration Flag (A-Flag) MUST be set to zero while the newly
defined Update flag (U-Flag) (see section 11.2.3) MUST be set. The
combined status of these flags will indicate that the specified
prefix MUST be used by MRs to update its local routing table with
destination prefixes set to the received prefix and the next hop
address set to the source address of the received RA message.
This combined exchanged of Route Notification messages via UNA and
and NEMO prefixes via unsolicited RA messages prevents against the
pinball routing problem by enabling the MNN and CN to
intercommunicate directly without having the packets leave the mobile
network domain and thus dramatically reduce the packet round trip
delay and packet overhead in terms of successive tunneling and de-
tunneling.
10. Data Structures
Mention the NGT and the small modification in the CN's BC.
The NERON protocol defines a new Nest Gate Table (NGT) maintained by
each MR. The NGT conceptual data structure consists of the following
fields:
Yousaf, Wietfeld Expires January 30, 2009 [Page 13]
Internet-Draft NERON July 2008
o Nest Position: The position of the respective MR in terms of its
depth inside the nested mobile network's nest hierarchy. The MR
will calculate its position in the nest hierarchy by incrementing
the value carried in the Depth field of the RA's "Mobile Network
Gateway" Option (see section 11.3.1).
o Mobile Network Gateway: The globally unique IPv6 address
configured and assigned to the rMR's egress interface. The MR will
update this field in the NGT from the information received in the
RA's "Mobile Network Gateway" Option (see section 11.3.1).
Besides NGT, NERON proposes to modify the binding cache of the CN [5]
by adding the "Nest Gate" field which will contain the rMR's egress
interface address received in the Nest Gate Option of the BU message
(see section 11.3.3).
11. Message Formats
The NERON protocol introduces a new routing header called a Type-3
Routing header (T3RH) and makes use of the existing MIPv6 [5] and
IPv6 Neighbor Discovery protocol [6] with minimum but manageable
modifications and new message sub-options.
11.1. Type-3 Routing Header
NERON defines a new routing header variant, the Type 3 Routing Header
(T3RH), to allow the packet to be routed directly from a CN to the
MNN inside the nested mobile network without any tunneling overhead.
This routing header type is restricted to carry two IPv6 addresses;
the nMR's CoA (the address of the egress interface) and the
associated MNN address. The rMR's egress interface address is
inserted into the IPv6 Destination Address field.
Once the packet arrives at the rMR's egress interface, it will swap
the destination address of the IPv6 header with the nMR's CoA inside
the T3RH and forward the packet inside the mobile network. The packet
upon reaching the relevant nMR will then replace the MNN address in
the IPv6 destination address field from the T3RH, and this is used as
the final destination address for the packet. The nMR will remove the
routing header and forward the packet to the required MNN.
The T3RH is used instead of the Type 2 Routing Header [5] whenever
the CN is sending data packets towards MNN that resides inside a
mobile network. See section 9 to understand how CN determines whether
the MNN is inside a mobile network or is connected to the Internet
infrastructure.
Yousaf, Wietfeld Expires January 30, 2009 [Page 14]
Internet-Draft NERON July 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header |Hdr Ext Len = 4|Routing Type=3 |Segment Left=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ nested MR Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile Network Node Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 : Type 3 Routing Header
The type 3 routing header is shown in figure 1 and has the following
format:
Next Header
8-bit selector. Identifies the type of header
immediately following the routing header. Uses the
same values as the IPv6 Next Header field [16].
Hdr Ext Len
4 (8-bit unsigned integer). Length of the routing
header in 8-octet units, not including the first 8
octets.
Routing Type
3 (8-bit unsigned integer).
Segments Left
1 (8-bit unsigned integer).
Reserved
Yousaf, Wietfeld Expires January 30, 2009 [Page 15]
Internet-Draft NERON July 2008
32-bit reserved field. The value MUST be initialized
to zero by the sender, and MUST be ignored by the
receiver.
Nested MR Care of Address
The CoA of the nMR's egress interface.
Mobile Network Node Address
The IPv6 address of the MNN connected to the nMR's
ingress interface.
11.2. Modified Neighbor Discovery Messages and Options
NERON proposes minor modification to the MIPv6 specified router
advertisement message [5], prefix information option and Neighbor
Discovery message [6] with the addition of single flag bits.
11.2.1. Modified MIPv6 Router Advertisement Message
The NERON protocol modifies the format of the MIPv6 specified router
advertisement message [5] by the addition of a single flag bit to
differentiate a MR from a regular infrastructure AR.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Curr Hop Limit |M|O|H|R|Reserve| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-
Figure 2 : Modified RA Message
This format represents the following changes over that originally
specified for MIPv6:
Mobile Router Flag (R)
When set indicates that the advertising router is a MR
and not a regular infrastructure AR.
Yousaf, Wietfeld Expires January 30, 2009 [Page 16]
Internet-Draft NERON July 2008
Reserved
Reduced from a 5-bit field to a 4-bit field to account
for the addition of the R-flag bit.
Valid Options:
Mobile Network Gateway Option
Carries the global unicast IP address configured at
the rMR's egress interface. This option MUST be
included, when the R-flag is set.
11.2.2. Modified Neighbor Advertisement Message
The NERON protocol modifies the format of the IPv6 Neighbor
Discovery's neighbor advertisement message [6] by the addition of a
single flag bit to differentiate a MR from a regular infrastructure
AR. The MR will send unsolicited neighbor advertisement (UNA) to
advertise the MNPs of the local and nested MRs up to the higher MR in
the nest hierarchy/chain. The UNA is transmitted only on the egress
interface and received and processed at the ingress interface. The
receiving MR will update its local routing table by assigning the
link local address as the next hop address to reach the address
prefix(es) carried by the same UNA.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link Local Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+
Figure 3 : Modified Neighbor Advertisement Message
Yousaf, Wietfeld Expires January 30, 2009 [Page 17]
Internet-Draft NERON July 2008
This format represents the following changes over that originally
specified in [6]:
Mobile Router Flag (M)
When set indicates that the advertising router is a MR
and not a regular infrastructure AR. When M is set
then the R flag MUST be set and the S and the O flag
MUST be zero.
Reserved
Reduced from a 21-bit field to a 20-bit field to
account for the addition of the M-flag bit.
Link Local Address
MUST include the link local address of the egress
interface sending out the unsolicited NA when the
M-flag is set. The receiving MR will use this address
as the next hop address for the prefix(es) carried in
the route notification option.
Valid Options:
Route Notification Option
Carries the prefix of the MR's ingress interface. This
option MUST be included, when the M-flag is set. The
advertisement may carry multiple such options.
11.2.3. Modified Prefix Information Option
The format of the modified prefix information option carried by the
RA message is shown in figure 4.
This format represents the following changes over that originally
specified in [5]:
Update Flag (U)
When set indicates that the prefix option MUST be
processed by the MR and that the advertised prefix is
a NEMO prefix that MUST be used by the MR to update
its local routing table and using the source IP
address of the RA message as the next hop address to
reach this prefix/address.
Reserved
Reduced from a 5-bit field to a 4-bit field to account
for the addition of the U-flag bit.
Yousaf, Wietfeld Expires January 30, 2009 [Page 18]
Internet-Draft NERON July 2008
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 | Prefix Length |L|A|R|U| Res 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix (variable length) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 : Prefix Information Option
11.3. New Message Options
NERON defines two new message sub-options.
11.3.1. Mobile Network Gateway Option
This option is included in the router advertisement message
advertised periodically by the MRs on their ingress interfaces. This
option MUST be included whenever the R-flag is set. This message
option carries the address configured on the rMR's egress interface
and also notifies its position in terms of nest-depth. The receiving
MR will compute its position in the nest by incrementing the depth
value specified in this option.
The format of the message is shown in figure 4.
Yousaf, Wietfeld Expires January 30, 2009 [Page 19]
Internet-Draft NERON July 2008
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 | Prefix Length |P| D |Reserve|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ root Mobile Router CoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 : Mobile Network Gateway Option
Type
To be assigned by IANA.
Length
8-bit unsigned integer. Indicates length of the option
field.
Primary Flag (P)
When set indicates that the MR is attached to a non-
mobile infrastructure AR. This flag will eliminate the
race condition that may occur when a MR enters the
domain of another MR and both have the same Depth
value.
Depth Field (D)
This 3-bit field indicates the position of the
advertising MR in terms of nest depth. The rMR will
always have a depth value of zero by default and
incremented by 1 by the nMR (which receives this
option) indicating the depth of its location.
Prefix Length
The prefix length indicates the number of significant
bits of the rMR's CoA. This will enable a MIPv6
capable VMN to derive a topologically correct CoA for
initiating its MIPv6 handover process. This option
will allow MIPv6 enabled node to co-locate and operate
from within the domain of a mobile network.
Reserved
Yousaf, Wietfeld Expires January 30, 2009 [Page 20]
Internet-Draft NERON July 2008
4-bit unused field. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Root Mobile Router CoA
The global unicast address assigned/configured on the
egress interface of the root mobile router (rMR). It
may be a HoA or a CoA depending on the location of the
rMR. This value is stored by the receiving MR in its
Nest Gate Table and is relayed down to the next MR in
its respective RA message. This option enables all the
MRs nested behind the same rMR get information about
the rMR's CoA.
11.3.2. Route Notification Option
This option MUST be carried by the unsolicited neighbor advertisement
message whenever the M-flag is set. The MR will convey the MNP that
may be local or received from a nMR in a similar option to the next
higher MR.
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 = 3 | Prefix Length |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix (variable length) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 : Route Notification Option
Type
To be assigned by IANA.
Length
3 (8-bit unsigned integer). The length of the option
(including the type and length fields) in units of 8-
octets.
Yousaf, Wietfeld Expires January 30, 2009 [Page 21]
Internet-Draft NERON July 2008
Prefix Length
8-bit unsigned integer. The number of leading bits in
the Prefix that are valid. The value ranges from 0 to
128.
Relay Flag (R)
The R-flag when set would indicate that this prefix
must be relayed to the next higher MR in the chain.
The rMR MUST not relay it further up.
Reserved
7-bit unused field. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Valid Lifetime
32-bit unsigned integer. The length of time in seconds
(relative to the time the packet is sent) that the
prefix is valid.
Prefix
An IP address or a prefix of an IP address. The prefix
length field contains the number of valid leading bits
in the prefix.
Yousaf, Wietfeld Expires January 30, 2009 [Page 22]
Internet-Draft NERON July 2008
11.3.3. Nest Gate Option
This option MUST be carried by the BU message sent by the nMR on
behalf of the LFN during correspondent registration. It carries the
address of the mobile network gateway i.e., the address of the rMR's
egress interface. After the successful completion of the return
Routability procedure (see section 8.3), the rMR/nMR will search and
acquire the rMR's egress interface address from its Nest Gate Table
and include this address in the Nest Gate Option and append it to the
BU.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Nest Gate Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 : Nest Gate Option
The format of the Nest Gate option is shown in figure 6 and it is
similar to the MIPv6 Alternate Care-of-Address option but with a
different type.
12. Security Considerations
NERON follows the security aspects defined in [5] and [2]. For packet
transmission it uses the IPSec features of IPv6. Further security
considerations are still under investigation.
13. IANA Considerations
This document requires IANA to assign numbers to the Type value of
the 3 message options namely; Nest Gate Option, Route Notification
Option and Mobile Network Gateway Option.
Yousaf, Wietfeld Expires January 30, 2009 [Page 23]
Internet-Draft NERON July 2008
14. Conclusions
NERON is a light weight scalable RO solution that is independent of
the MNN depth in a nested mobile network and it utilizes the existing
MIPv6 and Neighbor Discovery Protocol constructs with minor but
manageable modifications to the existing messages. NERON does not
introduce any new network entity and all the protocol complexity is
limited within the scope of a MR. It tackles the issues described in
[3] and encompasses the solution space prescribed in [4]. All of the
above considerations makes NERON ideal for quick and early
deployment.
15. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
16. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] NEMO RFC 3963: Devarapalli, V., Wakikawa, R. A. Petrescu, P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC
3963, January 2005.
[3] RFC 4888: C. Ng, P. Thubert, M. Watari, F. Zhao, "Network
Mobility Route Optimization Problem Statement", RFC 4888, IETF,
July 2007.
[4] Thubert P., C. Ng., M. Watari, F. Zhao, "Network Mobility Route
Optimization Solution Space Analysis", RFC 4889, July 2007.
[5] MIPv6 RFC 3775 Johnson, D., Perkins, C., and J. Arkko,
"Mobility Support in IPv6", RFC 3775, June 2004.
[6] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007.
[7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[8] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
RFC 4885, June 2004.
[9] MAENMO Project. http://www.mobileip.jp/MANEMO/MANEMO.html. July
2008.
Yousaf, Wietfeld Expires January 30, 2009 [Page 24]
Internet-Draft NERON July 2008
[10] M. Watari et. al., "Routing Optimization for Nested Mobile
Networks", IEICE Transaction on Communications, Volume E-89-B,
No 10, October 2006.
[11] C. Bernardo, M. Bagnulo, M. Calderon, "MIPv6 Route Optimization
for Network Mobility (MIRON)", Internet Draft (Work in
progress), January 2008.
[12] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless Address
Autoconfiguration", RFC 4862, September 2007.
[13] R. Droms, et al, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[14] P. Thubert, C. Bontoux, M. Montavont, "Nested NEMO Tree
Discovery", Internet Draft (Work in progress), July, 2007.
[15] P. Thubert, R. Wakikawa, C. Bernardos, et. al., "Network In
Node Advertisement", Internet Draft (Work in progress), July,
2007.
[16] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
Author's Addresses
Faqir Zarrar Yousaf
Communication Networks Institute
Dortmund University of Technology
Otto-Hahn-Str. 6,
D-44227 Dortmund, Germany
Email: faqir.yousaf@tu-dortmund.de
Christian Wietfeld
Communication Networks Institute
Dortmund University of Technology
Otto-Hahn-Str. 6,
D-44227 Dortmund, Germany
Email: christian.wietfeld@tu-dortmund.de
Yousaf, Wietfeld Expires January 30, 2009 [Page 25]
Internet-Draft NERON July 2008
Alain Tigyo
Communication Networks Institute
Dortmund University of Technology
Otto-Hahn-Str. 6,
D-44227 Dortmund, Germany
Email: alain.tigyo@tu-dortmund.de
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, 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.
Copyright Statement
Copyright (C) The IETF Trust (2008).
Yousaf, Wietfeld Expires January 30, 2009 [Page 26]
Internet-Draft NERON July 2008
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.
Yousaf, Wietfeld Expires January 30, 2009 [Page 27]