[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/