Mobile IP Working Group                                         Theo Pagtzis
INTERNET DRAFT                                                Peter Kirstein
10 July 2001                                       University College London


             A Framework for Proactive Mobility in Mobile IPv6
                 draft-pagtzis-mobileip-proactivev6-00.txt



Status of This Memo


    This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF).  Comments should be submitted to
the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.


    Distribution of this memo is unlimited.

    This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.  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.


Abstract

    This document specifies a scheme to provide support for proactive
mobility  for IPv6.  It encompasses a novel approach for seamless
handoff and proactive roaming context transfer.  The latter establishes
a generic method for proactive context transfer and manipulation of
different classes of context relating to the state of IP connectivity
for a mobile node.

    The above scheme is in support of the argument that waiting to start
the handoff process until the node has reached the cell boundaries,
where the range between a set of neighbouring coverage areas is expected
to overlap, is bound to be too late for high speed mobile nodes with
irregular mobility patterns.  For this reason the proposed mobility
scheme enables proactively roaming context allocation and management
with forward IP-guarding against irregularities of the mobility pattern


Pagtzis, Kirstein              Expires 10 January 2002               [Page i]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



of the mobile node, before the latter reaches the boundaries of overlap
areas between adjacent coverage areas.

    To address such form of proactivity, the proposed model identifies
the notion of a mobility neighbourhood through a set of adjacent
coverage areas, that are directly visible during the mobility pattern of
a mobile node and probable to be visited by it in the immediate future;
since each coverage area is effected by a single access point controlled
directly by some routing entity, the proposed mobility model establishes
the abstraction of a routing neighbourhood over spanning tree routing
topologies, acting as the traffic forwarding medium and effected over
some mobility neighbourhood.


    Since adjacency over the mobility neighbourhood does not imply
adjacency over the underlying routing neighbourhood, the proposed
model further establishes an accurate mapping between the mobility
neighbourhood that surrounds the current point of attachement of an
MN and the correct underlying routing neighbourhood so as to effect
proactive mobility through forward context tranfer and manipulation of
roaming state or other context class.


    The proposed model caters for safeguards over sustained IP
connectivity guarantees irrespective of the velocity vector of the
mobile node.  This is achieved by introducing a 1-level lookahead IP
roaming state over the established mapping between existing mobility
neighbourhood and the respective routing neighbourhood through the
notion of soft Care-of Addressing (CoA); in this mapping the latter
represents a future instantiation and transition of a mobile node to
adjacent coverage areas controlled by different routing entities and
subsequently different routable networks.


    The proactive allocation of Soft Care-of addresses over the
identified routing neighbourhood is further mapped over a Proactive
CoA onto the Multicast IPv6 domain so as to abstract the plurality of
unicast Care-of Addressing onto a single multicast routing identifier.
Management of the aformentioned mappings effect seamlessness in the
handoff process for a Mobile node, while transfer and manipulation of
its roaming context over the identified routng neighbourhood is effected
proactively.


    The proposed scheme further caters for robustness against
cell-bouncing effects that can render harmful disruptions at the IP
layer in terms of MN relocation latencies and accompanied packet loss.



Pagtzis, Kirstein             Expires 10 January 2002               [Page ii]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                                    Contents



Status of This Memo                                                      i


Abstract                                                                 i

 1.  Introduction                                                        2

 2.  Related work                                                        2

 3.  Proposal for Proactive Seamless Handoffs                            4
      3.1. Terminology and Assumptions . . . . . . . . . . . . . . .     4
            3.1.1.  Defining Router and MN Handoff states . . . . . .    5
            3.1.2.  Defining Proactive Mobility . . . . . . . . . . .    6


 4.  The Proposed Proactive Mobility model                               9
      4.1. Proactive discovery of the Mobility Neighbourhood . . . .    10
            4.1.1.  Incremental RNV aquisition through temporal reactive
                   learning . . . . . . . . . . . . . . . . . . . . .   12
            4.1.2.  Complete RNV aquisition with fully proactive
                   learning . . . . . . . . . . . . . . . . . . . . .   14
                   4.1.2.1.  Distance calculation  . . . . . . . . . .  17
      4.2. Establishing proactively full Roaming context for the RDC    17
            4.2.1.  PCN-Cache management  . . . . . . . . . . . . . .   19
      4.3. Registering with the home network . . . . . . . . . . . .    20
      4.4. Proactive Roaming state generation for the MN . . . . . .    21
      4.5. Abstracting the Routing Identifier on the RDC . . . . . .    27
            4.5.1.  PCoA membership management for RDC neighbours . .   28
            4.5.2.  Requirement for indirect Group management . . . .   30
            4.5.3.  Indirect group management considerations  . . . .   31
      4.6. Benefits from mapping of mobility neighbourhood on PCoA
          group  . . . . . . . . . . . . . . . . . . . . . . . . . .    33
      4.7. Activity on the part of the MN  . . . . . . . . . . . . .    34
      4.8. PCoA Activation Lifetimes . . . . . . . . . . . . . . . .    35
            4.8.1.  Proactive Handoff transitions between neighbouring
                   mobility links . . . . . . . . . . . . . . . . . .   37
            4.8.2.  SCoA tracking and Cell-Bounce Accumulator . . . .   41
            4.8.3.  Refreshing the soft CoA tuple . . . . . . . . . .   43
            4.8.4.  Resolution of redundant SCoA RDC neighbours . . .   45
            4.8.5.  Managing the I-MLD Done at the PREVIOUS RDC . . .   47
            4.8.6.  Managing the PCoA 'joins' at the PREVIOUS RDC . .   47
            4.8.7.  HA and CN considerations  . . . . . . . . . . . .   48
            4.8.8.  Continuous vs disrupted connectivity during MN
                   movement . . . . . . . . . . . . . . . . . . . . .   48


 5.  Extended model optimizations                                       49


Pagtzis, Kirstein            Expires 10 January 2002               [Page iii]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



      5.1. Coupling of MLD proxying and CoA allocation . . . . . . .    50
      5.2. Pessimistic and Optimistic Proactivity  . . . . . . . . .    50
      5.3. Context Transfer over multicast channels  . . . . . . . .    51

 6.  Description of the messages                                        51
      6.1. Indirect RNV Update . . . . . . . . . . . . . . . . . . .    51
      6.2. Direct RNV Update . . . . . . . . . . . . . . . . . . . .    53
      6.3. Roaming context option  . . . . . . . . . . . . . . . . .    55
      6.4. PCN Advertisment  . . . . . . . . . . . . . . . . . . . .    56
            6.4.1.  Roaming Context Ontology option . . . . . . . . .   58
      6.5. Aggregate PI-DAD Request  . . . . . . . . . . . . . . . .    59
      6.6. Aggregate PI-DAD Reply  . . . . . . . . . . . . . . . . .    61
            6.6.1.  Plain PI-DAD Request/Reply  . . . . . . . . . . .   63
      6.7. Indirect SCoA-Create message  . . . . . . . . . . . . . .    64
      6.8. SCoA-Ready message  . . . . . . . . . . . . . . . . . . .    65
      6.9. Proactive Roaming State Push  . . . . . . . . . . . . . .    66
            6.9.1.  Roaming State option  . . . . . . . . . . . . . .   68
     6.10. Proactive Roaming State Reply . . . . . . . . . . . . . .    70
     6.11. Indirect MLD Messaging  . . . . . . . . . . . . . . . . .    72
           6.11.1.  Implicit Join Solicitation  . . . . . . . . . . .   72
           6.11.2.  Indirect MLD Membership Query . . . . . . . . . .   73
           6.11.3.  Indirect MLD Report/Done  . . . . . . . . . . . .   74
     6.12. PCoA-Enable/Disable message . . . . . . . . . . . . . . .    75
     6.13. Indirect Neighbour advertisment . . . . . . . . . . . . .    77

 7.  Acknowledgements                                                   81

 8.  Addresses                                                          82



Pagtzis, Kirstein              Expires 10 January 2002               [Page 1]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


1.  Introduction


    The signalling delays expected currently over the Mobile IPv6
protocol standard in IETF [21], may cause the mobile node to experience
significant handoff latencies.  The magnitude of such delays is
sufficient to disrupt even momentarily the network connectivity of a
mobile node or at best degrade significantly the servicing quality of
the wireless network connection.


    The problem is further exacerbated when the velocity of the mobile
node fluctuates beyond the boundaries of the core Mobile IPv6 signaling
rate with which the presence of a mobile node is propagated into a
new routing IPv6 domain.  This implies that reliance in signalling
like standard router advertisments may prove insufficient in ensuring
sustained performance for time critical applications serving at the
mobile node.  This may further affect provisioning guarantees in quality
of network services as experienced by the mobile node.


    Currently Mobile IPv6 does not mandate any scheme that may provide an
upper bound over handoff latency and subsequently qualitative guarantees
that can assure a minimal measure of sustained quality in wireless
network connectivity.

    In the scheme proposed in this document we establish a model that
promotes proactive  mobility over IPv6 networks.  We argue that mobility
should not rely on the reactivity of the upcoming visited network.  This
is far too slow as soon as the node begins to consider higher and less
predictable mobility patterns.  On the contrary, we argue that it is
the network either current or previous that should work proactively
towards managing a mobile node's connectivity state, put simply as
mobility-awareness over mobile node-specific roaming state.


2.  Related work


    There have been a number of proposed protocols for Mobility in IPv6
that strive towards minimizing the handoff latency during transition
between Access Routers (ARs), especially in the light of IP flows
with real-time constraints, between an MN and its peers.  Generic
design principles for fast handoffs have been proposed by [17].  Such
principles are manifested in design specifications from [23] as well as
[24] which is targeted specifically for context transfer in the light of
seamless mobility.

    [27] proposes the comeback of some mobility agent in an IPv6
network that is foreign to the visiting MN; this is very similar to
the traditional IPv4 FA mobility entity.  It attempts to support fast
handoffs by claiming faster reaction by the LMA in terms of IPv6 address


Pagtzis, Kirstein              Expires 10 January 2002               [Page 2]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



allocation and authentication, while enabling some transitional path
between Mobile IPv4 and IPv6.


    [1] proposes a different approach where an MN informs with
bindings its peers (HA+CNs) about its current link as well as
possible 'to-be-visited' links.  This is achieved by introducing the
neighbourhood discovery task at the mobile node (MN). The scheme,
further employs route segments in the routing header for packet
forwarding towards the MN.


    The scheme presents robustness problems in what is described as
ping-pong effect (1) , since each route segment is effected only once
as the packet gets forwarded serially to all CoA in some potential
probabilistic ordering.  For instance if the MN moves from AR1 to AR2
and back on AR1 then the route segment could only reach from CoA1 to
CoA2 but not back to CoA1 (2) .


    Related considerations can also be found in [22].  The scheme
elaborates on Foreign Agent (FA)-assisted approach where the old FA
communicates with the new FA in order to setup a handoff request between
the two foreign agents.  The handoff request is initiated either from
the old or new FA when the link layer of some network entity detects
that it departs the coverage area.  The scheme assumes that both
FAs fall under the same Gateway foreign agent (GFA) in a regional
registration mobility aware IPv4 environment.


    Alternative approaches in Mobile IP have also been proposed in [32],
[19], [30].  These schemes are employing IP-Multicast between the MN
and its peers (end-to-end) for the addressing and routing of packets to
mobile nodes.  That is, the schemes require that traffic is forwarded
to a multicast group on an end-to-end basis for the purposes of minimal
latency handoffs during the mobility pattern of the mobile node.  To
this end a small group multicast solution has been proposed [25] and
[13] where each traffic source.  Both schemes utilize principles from
[4] and they employ a multiple unicast destination option at the routing
header of a packet.  This notion is similar to the route segments of
[1] since both schemes rely on unicast routing to deliver the packet.
The schemes rely on the provision of all CoA destinations to the peer
entities from the MN.


    Our proposed scheme as described in following sections is
architecturaly different from all the above schemes; this is both in
terms of routing during handoff transitions as well as neighborhood

----------------------------
1. oscillation in handoffs between two or more Access Routers

2. as soon as the last CoA is reached in the route segments the packet
is sent back to the HA where it is being discarded



Pagtzis, Kirstein              Expires 10 January 2002               [Page 3]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



establishment for the purposes of minimal handoff delays as well as
signalling overheads over the air interface as well as elimination of
ping-pong effects.  With these design requirements in mind, we argue
that the visited network should be responsible for providing proactively
mobility services to the MN ahead  of its future move.  This is the very
essence of the proactive model proposed in this document.



3.  Proposal for Proactive Seamless Handoffs


3.1.  Terminology and Assumptions


    Before proceeding to describe the proposed model we provide with
some basic terminology that our model adopts.  We further provide
with fundamental assumptions that our model makes about existing
information/messaging that is made available through other protocols.


    In IPv6, the notion of a Access Router (AR) is overloaded with more
functions than just plain routing [29, 5] and its supporting protocol
elements like Neighbour Discovery, Stateless address autoconfiguration
or other.  In a ubiquitous mobility environment it is expected to
support other funtions over IP such as context transfer, location
management, over functions like paging, admission control closely
coupled with AAA functions and so forth.  It is for this reason ARs
as routing entities will be collectively termed as Routing Domain
Controllers (RDCs) for the purpose of this document.


    For simplicity, the model initially considers that one RDC is
controlling a single Access Point (AP) that maps to a single coverage
area (3) .  It is however, possible to expand this model towards control
of multiple APs from a single RDC. This, nevertheless, may be safely
assumed as a uniform coverage area of simply larger diameter.  We
define an Access Point as a link layer entity that operates, currently,
transparently from the perspective of IP layer.


    For this model, the above further implies that semantically the
notion of a Routing Domain  maps currently to the notion of a single
IP subnet.  That is to say that an RDC is controlling a single
subnetwork in terms of routing.  As such, for the purposes of clarity
and simplicity we define a routing domain to be a single routable
(sub)network that is identified by a unique routing prefix.  Thus, the
two terms are used interchangeably in the remainder of this document.

----------------------------
3. Such coverage area may be modelled as hexagonal for the purposes of
adjacency and continuous coverage



Pagtzis, Kirstein              Expires 10 January 2002               [Page 4]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



    From that perspective the model proposed does not distinguish at this
stage between intra-domain and inter-domain movement for a mobile node
as the basic transition constituent is a routing domain which according
to the above definition is a single sub-network (4) .  As such the model
is concerned only with generic cross network transitions for a mobile
node as the fundamental requirement.


    Furthermore, a mobile node (MN) as a mobile entity that is primarily
wireless while expected to rove between different network links it
is primarily expected to first either power on and register with its
home  network domain and subsequent RDC in order to obtain its home
IPv6 address.  Alternatively the MN may be configured manually with the
required IP connectivity information that render it service-able within
its home network, even if its not expected to power on at all  within
its home network link.



3.1.1.  Defining Router and MN Handoff states


    To provide a clear designation on the states that a router may
transit as it serves a mobile node, we define a set of possible states
for both an RDC and the accommodated MN. These states identify the mode
of either the MN or the RDC with respect to transition triggers from the
former.

    In particular, a mobile node (MN) may transit between four states,
namely:  INCOMING, ACTIVE, OUTGOING, SUSPENDED and HANDOFF. These are
illustrated in figure 1.  While a network transition is pending, the MN
enters the INCOMING state for the purposes of link layer connectivity,
admission control, and possible context transfer.  Upon completion
of the handoff the MN enters the ACTIVE state; that also signifies
the completion of either admission control or context transfer (5) .
Unsuccessfull completion of these functions imply that the MN enters a
SUSPENDED state during which seamless handoff guarantees may be revoked.
This can also occur in the event suspending the MN while active (6) .
The MN may further transit to the OUTGOING state if it shows signs of
transition candidacy at the RDC. The MN may also reach this state in
the event that the RDC forces the MN to become a handoff candidate for
reasons of performance if sufficient overlap between coverage areas
allow to do so.  The MN enters the HANDOFF state when the RDC has
commenced the process of transition over to a new RDC and until the
transition has stabilised over the new RDC such that it can proceed to
complete.

----------------------------
4. single routable link

5. it may be that admission control is a context transfer function

6. due to potential billing issues



Pagtzis, Kirstein              Expires 10 January 2002               [Page 5]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



               <figure provided in postscript version>

              Figure 1: Mobile Node handoff transition states



    With respect to the RDC entity, consider two routing domains RDi  and
RDi+k  where each one is being serviced by a different RDC. The visited
routing domain and subsequently the visited RDC is assumed as an entity
that engages into a three-state transition, described by the following
core states:  NEW, CURRENT and PREVIOUS.


    While MN transits from RDCi   towards RDCi+k  , the latter enters into
state NEW while RDCi moves from CURRENT to PREVIOUS state.  As MN gets
registered and admitted to the new routing domain RDCi+k   transits to
CURRENT state.


    The RDCi+k   currently in the NEW state will need to further establish
and complete the aformentioned functions for the MN. These two functions
are subject to completion, suspension, or even revocation depending on
characteristics such as subscription, security compliance, potential
flow behaviour.  As such, the NEW router is bound to linger between the
states of NEW and CURRENT for incoming/associated node.  This is further
illustrated by figure 2.



                <figure provided in postscript version>

             Figure 2: Router transition states during handoff



    The mobility pattern of the MN may affect the stability of the
state transition process of the RDCs.  The most representative of
these is what we call coverage area (CA) bounce.  This is also known
as ping-pong  effect [17].  We envisage that our scheme should cater
for the stability of the transition process even under harsh CA bounce
conditions.



3.1.2.  Defining Proactive Mobility


    It is essential to define the semantics conveyed by the term
proactive mobility.  We are aware that in the particular class of



Pagtzis, Kirstein              Expires 10 January 2002               [Page 6]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



mobility scenarios considered (7) , a set of RDCs define a routing
neighbourhood  which spans over some geographic area through their
Access Point (AP) instantiations.  This is shown if Figure 3.  Such
instantiations and their underlying RDC define further a mobility
neighbourhood  which is manifested as overlapping coverage areas shown
in Figure 4.



             <figure provided in postscript version>

        Figure 3: Routing neighbourhood accomodating the MN



    While mobile, the MN transits between diferent coverage areas within
a mobility neighbourhood.  As previously stated, each such coverage area
effected through a single AP, maps to a single RDC and thus the mapping
between coverage area and RDC is assumed to be one-to-one.



           <figure provided in postscript version>

        Figure 4: Mobility neighbourhood servicing the MN



    It is assumed that the MN cannot be aware where it may move next
both geographically or over the respective network topology.  We regard
essential that the routing neighbourhood of the accomodating networks,
acts on its own for the purposes of preparing connectivity state or any
peripheral network functions/protocols before the MN actually engages in
requesting them.  The rationale behind such assumption is simple:  the
MN's mobility pattern is assumed to be non-deterministic in terms of
both speed and direction.  Thus, at the time that the MN will be in need
of the access services, it's movement will force it off the coverage
area of the current visiting network.  This is bound to introduce an
error prone air interface that can affect significantly in terms of
latencies or potential packet loss, the acquisition process of IP
connectivity state and thus continuous network connectivity towards a
ubiquitous mobility network environment.

----------------------------
7. we do not attack the case where the RDC is mobile also, i.e.  ad-hoc
nets



Pagtzis, Kirstein              Expires 10 January 2002               [Page 7]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



    The proposed model, thus, considers proactive mobility as the
function/set of interactions that preconfigures all or most network
functions that are required by a neighbouring network in providing
network services with some sustained connectivity safeguards.  The
ultimate goal in this proactive mobility approach is to effect seamless
network connectivity.  It is defined as the perceived quality of network
services remains constant or may degrade within some perceivably
acceptable boundaries.  Given that perceivable quality boundaries are
reached, the term may further transcend its qualitative guarantees to
objective qualitative metrics that are allowed to degrade within some
objectively  acceptable boundaries.


    We examine proactivity from the perspective of the fixed network,
extended by the last hop (RDC) wireless coverage area (APs) with respect
to the movement of an MN. The concept manifests itself in our model by
having each routing neighbourhood that is considered mobility-enabled,
to interact and communicate proactively roaming state about its mobility
neighbourhood.


    The set of interactions involve exchange of routing information of
neighbouring IPv6 routing subnetworks that map accurately over the
mobility neighbourhood servicing the MN. This should provide the an
architectural substrate for the purposes of enabling proactive mobility
over IPv6.


    Before proceeding with the description of the proactive model, we
distinguish between proactive transition establishment and other types
of transitions by defining three generic different types of mobility
handoffs with respect to a routing domain that may accommodate a mobile
node in the immediate future; that identifies the candidate new routing
domain effected over a coverage area of the mobility neighbourhood.  The
three transition types are defined as:


     -  reactive handoffs  :  handoffs that are effected as a result of a
        reaction of the new routing domain that is detecting an incoming
        node (8)  soliciting a registration request for the purposes of
        being accomodated on that network.


     -  forward reactive handoffs  :  handoffs that are effected as a
        result of a forward hint from some network entity, primarily the
        current RDC, to the new RDC. Here the current RDC is effectively
        pushing some context state, such that the new RDC is somewhat
        prepared with respect to the upcoming visiting of the MN. This
        identifies an informed reaction from the part of the new RDC.
        Alternatively, and potentially in special cases, hint requests

----------------------------
8. either through Router solicitation or registration



Pagtzis, Kirstein              Expires 10 January 2002               [Page 8]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



        may be initiated from the new RDC (towards the current RDC) such
        that some context state is pulled by the new RDC from the current
        one.


     -  proactive handoffs :  handoffs are administered entirely on the
        initiative taken from the candidate new routing domain to provide
        sufficient IP routing information which is to be utilized by the
        current routing domain in establishing IP state.  We emphasize on
        the word candidate since we do not rely specifically on knowledge
        of the identity of a new RDC and subsequently new routing domain.
        Here RDCs are conspiring to provide the essential information
        to each other in view of future handoffs.  Such information is
        self-contained and sufficient to effect a handoff without having
        the accomodating RDC to react to registration requests from an
        MN, since they are not needed.


    Currently most Mobile IPv6 protocol recommendations consider
primarily reactive handoff or at best forward reactive schemes in
terms of mobility handoffs.  To the best of our knowledge only a few
draft recommendations in IETF only begin to address some notion of
proactivity.  In addition, the IETF Working Group for Seamless Mobility
(SeaMoby) has only recently started to consider the notion of seamless
mobility through forward context transfer; this is however still at its
infancy, since currently the SeaMoby WG is in the process of specifying
the semantics and requirements for Seamless mobility as well as the
scope of its charter.


    It is important to note that the proposed proactive mobility allows
complete as well as partial proactive mobility management.  This stems
from the fact that the proactive mobility model may not be implemented
on every  RDC. In such event, only a partial  1-level lookahead view of
IP roaming context can be provided.  Since proactive mobility may not be
effected on every RDC, this lookahead view of roaming context fades on
the next visited routing domain that does not support it.



4.  The Proposed Proactive Mobility model


    As bandwidth resources over any wireless interface are commonly
accepted to be scarce (9)  in relation to their wired counterparts, the
mobility model considers that the MN should effect minimal signalling in
terms of conveying information to and from the visiting network link,
over the interface.  This is independent of whether the accomodating
routing domain is the current or a future one.  For this reason that

----------------------------
9. ranging for aggregate bandwidth in the orders of Mbps, while their
wired counterparts effect bandwidth in the order of GBps



Pagtzis, Kirstein              Expires 10 January 2002               [Page 9]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



the model attempts to minimize any signalling dependency on the mobile
node.  This is especially important under harsh propagation effects
that may yield an air interface with increased error rates during the
movement pattern of the MN. In such situations, dependency from the MN
over mobility signalling may present adverse effects in the connectivity
of the MN.


    Towards such argument the proactive model extends beyond the current
model met in most recommendations that relies generaly on what we term
as previous-new router relationship.  In particular, it encompasses not
only the current and new routing domain through the respective RDCs, but
the entire set of RDCs (10)  that effect a single contiguous mobility
neighbourhood.


    This is shown in Figure 5 where the coverage area effected by
the routing domain of RDC0   is surrounded (11)  by a six-cell (12)
mobility neighbourhood.  Each of the six neighbouring coverage areas is
controlled by a single RDC. The list of controlling RDCs may be denoted
by the list:


  <MNV/RNV neighbourhood denotation provided in postscript version>

    RNeiRDC0  denotes the routing neighbourhood vector (RNV). Each
component of RNV consists of the Link Layer Address (LLA) and the global
IPv6 address of the RDC, while N  is the number of RDCs mapping to the
mobility neighbourhood vector (MNV)  denoted as MNeiRDC0   .  RNeiRDC0
signifies also the complete set of proactive mobility state  required at
each RDC before it can provide full proactive mobility.



4.1.  Proactive discovery of the Mobility Neighbourhood


    It is important to consider the mapping between the topology of
some routing neighbourhood and the available mobility neighbourhood as
effected over the former for use by the MN; the significance lies on the
perspective of signalling when the mobility neighbourhood (MNV) needs to
be configured for some RNV for the proposed proactive model.


----------------------------
10. that may or may not be immediate routing neighbours

11. assuming initially continuous coverage

12. the neighborhood may grow larger depending on the range of the
wireless cells



Pagtzis, Kirstein             Expires 10 January 2002               [Page 10]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                 <figure provided in postscript version>

             Figure 5: Neighbouring Routing Domains defining a
                             routing neighbourhood



                <figure provided in postscript version>

            Figure 6: Basic shape of the mobility neighbourhood



    For instance, the mobility neighbourhood may be safely assumed to
follow the pattern of Figure 6 while the number of neighbours may change
depending on the diameter of the coverage area for each cell.  In such
mobility neighbourhood, each neighbouring coverage area is directly
reachable from the cell that the MN is currently residing.  This is
not necessarily true for the underlying routing neighbourhood and the
corresponding RNV since it depends highly on the topology.


    It can be seen from Figure 7 that a star  topology maps naturaly over
a mobility neighbourhood.  However, it may not be realistic to assume
only star topologies per MNV. This is because an a-priori mobility
neighbourhood would require essentially the existence of a fully
connected mesh topology as shown in Figure 7; this is not always the
case for routing topologies currently effected in the Internet.



                <figure provided in postscript version>


            Figure 7: Mobile neighbourhood over fully-connected
                             mesh routing topology



    It would, thus, be more realistic to consider and assume
spanning-tree  topologies over the mobility neighbourhood of the form
shown in Figure 8.



    As it may be seen from the topology of Figure 8 it may not be
the case that coverage areas which are neighbouring in a mobility
neighbourhood map to an RNV where each RDC is directly connected with
each other.  That implies that a movement of the MN from one coverage
area to another does not imply a direct link between the respective
RDCs.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 11]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                  <figure provided in postscript version>

               Figure 8: Mobility neighbourhood over spanning
                           tree routing topologies


    In this case, discovery of the mapping between the available mobility
neighbourhood and the corresponding routing neighbourhood has to be
effected through two different means:

     -  static configuration :  The mobility as well as the routing
        neighbourhood for fixed infrastructure networks (i.e.  not
        ad-hoc) is not expected to change often.  As such, it is possible
        that the MNV and the underlying RNV can be manually established
        and configured for each RDC.

     -  dynamic learning and configuration :  It is possible that static
        configuration may be avoided by employing dynamic learning on
        each RDC from one-time information that are conveyed to each RDC
        by the MNs that are transiting over the respective coverage area,
        and are thus natural discoverers of the mobility neighbourhood.


    The first case of static configuration is fairly trivial since it
each RDC can be configured manually.

    In the case of dynamic configuration, each RDC is effectively
required to discover its mobility neighbourhood in order to be able to
effect proactive mobility.  For this it would be essential for the RDC
to enter some probe mode over the mobility neighbourhood in order to
learn  what is the effective RNV for the MNV of its coverage area (AP).
To effect such dynamic learning there are two approaches that may be
considered each with different strengths and weaknesses:


     -  incremental RNV aquisition with reactive dynamic learning

     -  complete RNV aquisition with proactive learning


    The following sections describe each of the two schemes individually.


4.1.1.  Incremental RNV aquisition through temporal reactive learning


    Through this approach each MN conditionally contributes, indirectly,
routing information through new  router advertisments it hears as it
transits through some overlap area from the CURRENT RDC to a NEW RDC.
The condition pertains to the temporal fact that the MN either has


Pagtzis, Kirstein             Expires 10 January 2002               [Page 12]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


been provided some partial  or null  proactive mobility state for the
particular NEW RDC well before it hands off from the CURRENT RDC.

    Initially each RDC has no proactive mobility state in terms of an
RNV mapping to the mobility neighbourhood of its coverage area.  This
implies that the CURRENT RDC cannot push  (13) any proactive mobility
state to the MN; as such, the MN has no  proactive mobility state
for the particular NEW RDC and subsequenetly the coverage area it is
transiting to.  This condition is sufficient and necessary  for the MN
and the NEW RDC to engage into the reactive dynamic learning process,
during which:


     -  when no proactive mobility state exists for the NEW RDC, seamless
        mobility cannot be effected at the latter.  The model employs
        base IPv6 mobility, while the RDCs engage in probe mode for the
        purpose of dynamic but reactive RNV learning.


     -  Since the MN has had no proactive mobility state for that
        RDC, as soon as it transits to the NEW RDC, and it obtains IP
        connectivity, it provides the latter with a unicast Indirect RNV
        Update (I-RNV Update) message.  This message updates the specific
        RNV for the mobility neighbourhood of its coverage area with
        the IPv6 as well as the link layer address for the link of the
        PREVIOUS RDC over which part of the mobility neighbourhood of the
        CURRENT RDC is effected.  The latter may be derived from the IPv6
        address of the RDC by using the prefix length and reversing the
        rules for EUI-64 interface identifiers.  Alternatively the MN
        should set the L flag, which signifies the explicit inclusion of
        the previous RDC's LLA.


     -  Receipt of the I-RNV Update at the NEW RDC from the MN, signifies
        to the former that the PREVIOUS RDC is currently not aware that
        their coverage areas belong to the same mobility neighbourhood.
        For that reason the receipt of the I-RNV Update triggers  further
        a unicast Direct RNV Update (D-RNV Update) from the NEW RDC
        destined to the PREVIOUS RDC. In this manner both PREVIOUS and
        NEW RDC are establishing proactive mobility state for either
        direction.  This is a light-weight message that maintains a
        different code than the I-RNV Update and needs no explicit
        specification of the mobility-enabled link's IPv6 address for the
        NEW RDC; this address is retrieved from the sender IPv6 address
        of the D-RNV Update.

----------------------------
13. the model of pushing proactive mobility state is explained in later
sections



Pagtzis, Kirstein             Expires 10 January 2002               [Page 13]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



    The next MN that transits from the same PREVIOUS RDC to the same
NEW one, or vice versa, can now utilise the specific part of the
proactive mobility state at the PREVIOUS RDC as described in following
sections.  This signifies that the both PREVIOUS and NEW RDCs can now
effect partial proactive mobility state with respect to the particular
neighbouring coverage area of their mobility neighbourhood, while they
discovers their remainder.  This is shown in Figure 9.


                  <figure provided in postscript version>

                Figure 9: Partial proactive mobility through
                          temporal reactive learning


    As it may be seen the MN needs to 'push' I-RNV Updates and
subsequently trigger D-RNV ones, only when its has no proactive mobility
state with respect to the NEW RDC it is transiting to.  Otherwise, such
messaging is suppressed and proactive mobility state can take effect.

    In the worst of scenarios where proactive mobility state in a NEW RDC
becomes stale (14) , the state is instantly nullified; this is because
prefix information available from router advertisment heard by the MN
at the NEW RDC cannot match with any of the proactive mobility state
supplied at the CURRENT RDC. As such, proactive IPv6 mobility extensions
are naturally suspending for the NEW RDC and its coverage area, while a
new probe mode is triggered at the transiting MN initiating an new I-RNV
Update.


4.1.2.  Complete RNV aquisition with fully proactive learning


    In the case of fully proactive learning approach, each RDC is
building routing information about its own mobility neighbourhood
independent of the movement of any MN. In particular, each RDC maintains
a preconfigured coverage area tuple (CAT), denoted as:


         <CAT denotation provided in the postscript file>


    The CA tuple identifies accurately the coverage area of the RDC's AP
and comprizes of the following component information:


     -  the latitude (li) of the position of its AP.

----------------------------
14. as in the event of prefix renumbering


Pagtzis, Kirstein             Expires 10 January 2002               [Page 14]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



     -  the longtude (Li) of the position of its AP.


     -  the radius (ri) of its AP air interface.


     -  the height (hi) of the position of its AP. This may be employed
        only in the case of vertical handoffs.


    These component information are shown in Figure 10.  Vertical
handoffs are considered in later versions in the proposed proactive
mobility model.


                 <figure provided in postscript version>

                Figure 10: Coverage area tuple components


    Each RDC is sending its own CAT as an RDC-specific context option
into a D-RNV Update message to its neighbouring RDCs.  The D-RNV Update
message also includes the prefix length of the sending RDC. From that
it is possible for the receiving RDC to derive the LLA of the sending
RDC by reversing the EUI-64 interface identifier generation rules.
Alternatively a flag may be added to the message to signal explicitly
the existence of LLA of the RDC in the D-RNV Update message.  All RDCs
are assumed to be configured to listen to the well-known 'all-routers'
multicast group with link-local scope  (i.e FF02::2).


    Depending on whether an RDC is the originator of a CAT or it is
forwarding a received CAT to other RDCs the following actions are
effected:


     -  If the RDC is the originator of the CAT and subsequently of the
        D-RNV Update, the latter is sent on all interfaces except for the
        link that the effects the coverage area.  The destination address
        of the D-RNV Update is set to be the well-known 'all-router'
        multicast address with link-local scope.  Each D-RNV Update
        packet carries a monotonically increasing sequence number.

     -  On receipt of a D-RNV Update by the RDC, the message is forwarded
        after processing, on all interfaces except for the incoming
        one as well as the interface that effects a coverage area, if
        existent.  Similarly, the destination address of the D-RNV Update
        is set to be the well-known 'all-router' multicast address with
        link-local scope.

     -  The receiving RDC, checks a D-RNV Update packet for duplicates
        by means of maintaining a small table, denoted as Known RNV



Pagtzis, Kirstein             Expires 10 January 2002               [Page 15]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



        Source (KRS) table.  This table maintains the originator  and the
        sequence number  of the D-RNV Update received.  Any D-RNV Update
        with a matching originator entry and a larger sequence number, is
        silently discarded by the forwarding RDC.



                    <figure provided in postscript version>

          Figure 11: Topologies mapping to mobility neighbourhood



     -  The RDC originating the CAT in the D-RNV Update provides further
        a distance  metric with a constant value of 7.  The distance
        metric is decremented at each RDC receiving the message, before
        it is forwarded further.  When the distance metric decreases to
        zero, the D-RNV Update is not  forwarded any further.  The value
        of 7 is derived heuristically from the worst case scenario where
        a topology mapping to a single mobility neighbourhood is as
        shown in Figure 11.  This ensures that forwarding of CAT state
        is constrained within segments of the topology that make sense
        in terms of a mobility neighourhood mapping.  This value should
        change if the cell is considered to be other than hexagonal (15) .


    On receipt of the D-RNV Update the RDC extracts the CA tuple and the
address of the originator.  It then proceeds to calculate the linear
distance (dl) between its own AP and the originator's AP using (li,Li)
from the received CA tuple as well as its own (li+1,Li+1).



                <figure provided in postscript version>

              Figure 12: adjacency and overlap calculation



    Having calculated the linear distance dl, the receiving RDC then
caclulates the overlap distance do as follows:


    <overlap distance calculation provided in the postscript version>


    The overlap distance can provide with a clear answer to the receiver
RDC, whether the two RDC map to adjacent coverage areas.  That is, if do

----------------------------
15. this will instigate assymetries in cell overlap and cell radius



Pagtzis, Kirstein             Expires 10 January 2002               [Page 16]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


is larger than zero then there exists some overlap for the particular
two RDCs and thus, CA adjacency.  In this fashion one RDC can safely
augment its proactive mobility state, in terms of its RNV, with respect
to its mobility neighbourhood without being assisted from the MN.

    It should be noted that the messaging described is currently targeted
to be implemented as ICMPv6 messages.  However, the messaging may well
be integrated with routing protocol specifics and implemented as UDP.


4.1.2.1.  Distance calculation


    The linear distance between the positioning of two APs, assuming
spherical Earth, may be calculated as:

    <linear distance formula provided in postscript version>

    However, for very small distances between APs the angular
distance (16)  da must be optimized by means of half angles to:


    <optimization of linear distance formula provided in postscript
version>


4.2.  Establishing proactively full Roaming context for the RDC


    Given that each RDC maintains a complete RNV on the mobility
neighbourhood effected over the coverage area of its AP, it can then
proceed to acquire proactively also, the roaming state of all RDCs
mapping in its mobility neighbourhood.  This would identify the full
Roaming Context for the 1-level lookahead-view from the perspective of
the RDC utilized for management of complete proactive state to an MN.


    With regard to the type of messaging there are two perspectives that
should be considered, particularly in the light of differentiation
of context classes over a communication protocol for context state
transfer:

     -  Use of ICMP messaging.  Each type of context should be
        'multiplexed' over ICMP messages through different code types
        of context.  ICMP more tightly bound in the IP stack within the
        kernel.

----------------------------
16. angular distance measures in radians.  For degrees convert to
radians using rad = deg ss_=180



Pagtzis, Kirstein             Expires 10 January 2002               [Page 17]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



     -  Use of IP-Multicast.  It provides a more persistent but less
        reliable perspective of signalling, where each multicast group
        may identify an individual context type.  RDCs that determine
        their mobility neighbourhood can tune their membership to receive
        only from specific sources (source specific multicast).


    Currently, we identify two individual ICMPv6 [6] messages that are
required.  These are instantiations of what the model identifies as
Proactive Context Neighbour (PCN)  Discovery (PCN-D). With respect to
roaming state, PCN Discovery messaging proactively informs the mobility
neighbourhood of an RDC about the mobility neighbourhood of their
neighbour RDCs as effected by a set of adjacent coverage areas each
controlled by different RDCs.  This is done by providing full routing
information about the neighbouring RDCs' link interface which belongs
to the mobility neighbourhood and over which a router advert is made
available.


    The exchange of such roaming context is effected only  between a set
of neighbouring RDC; it may be periodicaly advertised or explicitly
solicited by an RDC. For the first case, the PCN discovery takes
the form of a PCN Advertisment (PCN-Ad), while in the second case
the message is explicitly solicited as a PCN Solicitation (PCN-Sol).
Figure 13 depicts the receipt of PCN-Ad/Sol message by a single RDC.
We differentiate from the conventional notion of advertisment and
solicitation over conventional neighbour discovery in the sense that PCN
discovery need not  take place over the local link.  As such globally
routable IPv6 addresses may be used for source or destination of such
signalling packets unless stated otherwise.  N  is the number of RDC
neighbours mapping to the mobility neighbourhood of the AP's coverage
area controlled by the sending RDC.


               <figure provided in postscript version>

         Figure 13: Neighbours inform Proactively the current RDC


    The current routing domain RDC, creates a cache of its neighbours
of size P CNk , where k is the size of the mobility neighbourhood This
is part of the PCN Cache (PCN-C) and is required in each RDC. The PCN
Cache is also expected to maintain context state information for other
potential context classes; however, the current version of this document
focuses specificaly on what has been defined as roaming context.


    For the purposes of clarity, an RDC (A) whose IPv6 address is found
in the RNV of another RDC (B) is denoted for the remainder of this
document as a neighbour RDC  of B.


Pagtzis, Kirstein             Expires 10 January 2002               [Page 18]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


    At each RDC, the PCN Advertisment message first signifies the
existence of roaming context; it further includes the RNV identifying
the mobility neighbourhood of each RDC as well as the prefix length
on the mobility-enabled link interface where the router advertisment
is effected.  The latter is combined with EUI-64 rules to deduce the
LLA of each neighbouring RDC if needed.  The source address of the PCN
Advertisment is set to be the IPv6 address of the sending RDC's link
interface on which the router advertisment is made available at the
particular coverage area.

    The PCN Solicitation simply signifies the need for Roaming Context
provisioning through a PCN advertisment.  The current version of the
model proposed does not specify explicitly a subset of the mobility
neighbourhood over which it would require specificaly it roaming
context.  It simply signifies the need to obtain the roaming context of
the entire  mobility neighbourhood.

    A PCN Advert may be periodically unicast by a single RDC to the RDC
neighbours.  Alternatively a PCN Solicitation is explicitly unicast
by an RDC to its neighbour RDCs.  A PCN Solicitation should piggyback
Roaming context of the sending RDC to the receiver RDC to speedup
convergence of roaming context state on all neighbouring RDC. In
response, the RDC neighbours reply with a PCN Advert that carries the
roaming context of their mobility neighbourhood.

    Proactive Context Discovery does not await on the MN reaching any
coverage boundaries between the CURRENT RDC/AP and any future candidate
RDCs.  On the contrary, such exchange of neighbour information is
happening on the background between RDCs while the MN is registering
with the CURRENT RDC.

    From a seamless mobility perspective, reactivity over coverage
boundaries between RDCs would be considered too late an action on behalf
of either the CURRENT or NEW RDC or even for triggers that initiate
the handoff process when the MN is transiting the overlap area.  This
latency is expected to also propagate over potential context tranfer
relocation which is bound to be time-consuming.  We argue that as the
velocity vector of the MN becomes highly irregular, non-proactive
mobility recommendations are bound to be severely constrained in
terms of reaction times; this is especially true in cases that the MN
alternates fast between coverage areas of different RDCs.


4.2.1.  PCN-Cache management

    With respect to roaming context, PCN-Cache entries MUST not be
purged periodically or according to some timer value unless explicitly
requested.  In addition the periodic advertisment of PCN-Ad or PCN-Sol
messages should be injected with some small random delay [16], the


Pagtzis, Kirstein             Expires 10 January 2002               [Page 19]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



magnitude of which is dependent on the frequency of transmission of
the PCN-Ad message.  In the event that a PCN-Ad transmission interval
is small (smaller than the observed frequency of transmitted PCN-Sol
messages), a PCN-Sol message will be serviced by the next PCN-Ad at time
that syncronizes with the PCN Advertisement interval plus some random
delay [16].


                  <figure provided in postscript version>

      Figure 14: Roaming context in PCN Cache maintained at node 14
     (RDC0).  Number 14 would point to the RDC's prefix on that link
                           connecting the two RDCs


    Figure 14, illustrates an outline of the PCN Cache for the roaming
context.  The first entry signifies the mobility neighbourhood of the
CURRENT RDC (which maintains this cache).  Subsequent entries signify
the mobility neighbourhood of that RDC's immediate neighbours.



4.3.  Registering with the home network


    Initially the mobile node bootstraps and registers with its home
network and, thus, obtains a home IPv6 address.  This allows also the MN
to store information about its home network and subsequently Home Agent
when designated through during the Home Agent Discovery phase.


    Home network registration is important for the MN in the event that
it roves away from it with its network interface disabled or when the MN
is dormant/switched off.  It allows the MN to inform its home network,
upon boostrap at a foreign network, by means of a binding update.  This
also tackles the case of home network renumbering.


    The registration process provides upon bootstrap, the link-layer
address (LLA) of the MN, to the home RDC (or any RDC in the CURRENT
state).  As soon as the link layer address of the MN has updated the
home RDC, the latter may propagate it to any RDC neighbours that the
MN may traverse in the future, as part of the roaming state generation
process effected at the CURRENT or neighbour RDC that is mapping over
the mobility neighbourhood to be visited.


    On the reverse direction, during first time registration with the
home network, the CURRENT (home) RDC provides to the MN its own LLA
and its IP address.  The MN is expected to store such information in
its neighbour cache and its default router list.  The MN must not
discard these entries, when it hands off to a new RDC unless explicitly



Pagtzis, Kirstein             Expires 10 January 2002               [Page 20]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



requested to do so, since they would be utilised amongst others (17)  for
the purposes of probing the routing neighbourhood.


4.4.  Proactive Roaming state generation for the MN


    Subject to admission control, the registration or bootstraping
process of the MN with some routing domain (the home or a foreign one)
enables the MN with IP connectivity.  Upon completion, the controlling
RDC transits from the NEW to the CURRENT state.  Transition at this
state requires that the CURRENT RDC generates a tuple of soft (unicast)
Care of Addresses (SCoAT) for the MN admitted.


    Such SCoA tuple comprizes of unique IPv6 unicast addresses, each
of which must be topologically correct in one of the CURRENT RDC's
neighbours.  By producing this SCoA tuple, the CURRENT RDC proactively
enables the MN with valid roaming context of configured IPv6 addressing
over prospective RDC neighbours that map to the mobility neighbourhood
of the CURRENT RDC's coverage area.  Some part of this mobility
neighbourhood is expected to be immediate candidate for the next handoff
transition of the MN.


    The SCoA tuple may be generated through two alternative ways:


     -  The CURRENT RDC utilizes the neighbour RDC prefix entries from
        the roaming context state maintained in its Proactive Context
        Neighbour Cache.  It combines each of the neighbouring RDC
        routing prefix with the LLA of the MN according to [31] and
        produces an IPv6 address.  Each of the IPv6 addresses created by
        the CURRENT RDC must now be checked for duplicates (DAD) against
        the neighbour Cache (NDC) of the neighbouring RDCs.  The LLA is
        expected to be found in the neighbour cache of the CURRENT RDC
        since during boostrap the MN needs to update the neighbour cache
        of the RDC with its LLA for on-link forwarding purposes according
        to the standard neighbour discovery protocol.


        It is intuitive that there will be more than one MNs registering
        with RDC0   and as such this RDC will need to perform multiple
        Duplicate Address Detection checks per neighbouring RDC, each one
        representing an SCoA for a single MN. For that case, the proposed
        scheme may be optimized with an aggregateProactive Indirect
        Duplicate Address Detection (PI-DAD) check per neighbouring RDC
        for the RDC in the CURRENT state.

----------------------------
17. as we see it will also comprize common roaming state between the
CURRENT and the NEW RDC



Pagtzis, Kirstein             Expires 10 January 2002               [Page 21]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



        A standard DAD check under IPv6 is effectively address resolution
        for a tentative address; that includes neighbour solicitation and
        neighbour advertisment as described by [33].  This is usually
        performed on-link upon generation of new IPv6 address which is
        also topologicaly correct on the local link.  If the neighbour
        solicitation is not responded with a neighbour advertsment within
        some time interval the address is considered to be unique.



                  <figure provided in postscript version>

            Figure 15: Aggregated Indirect proactive DAD check



        With the case of proactive IPv6 address generation, however, the
        IPv6 addresses are generated off-link and are targeted to be
        topologically correct on the prospective on-link.  As Figure 15
        shows there exist some IPv6 SCoAs that are generated behind
        RDC2, however they are targeted for use behind RDC0.  It is for
        that purpose an extra level of indirection need be generated in
        terms of signalling at the attachment point where the addresses
        get generated.  This is created by means of the PI-DAD Request
        message sent by the CURRENT RDC towards the RDC for which the
        tentative SCoAs are topologically correct.  The aggregate PI-DAD
        Request message comprizes of one or more (18)  ICMPv6 packets.
        Each aggregate PI-DAD Request includes a set of SCoA that are
        topologically correct at the RDC neighbour.  Furthermore for each
        of the SCoA the CURRENT RDC includes also the link layer address
        (LLA) of the MN.


        On receipt of the PI-DAD Request, the neighbour RDC first checks
        its neighbour cache entry for each of the SCoAs to see if they
        are already existent.  If not, it creates an entry with the SCoA
        and the link layer address of the MN. It also adds a P flag to
        the entry, as an extension, to mark it as PROACTIVE. The entry is
        set to INCOMPLETE. It then attempts DAD through standard address
        resolution.  In particular it sends neighbour solicitation to
        the solicited-node multicast address mapping to the SCoA. It
        further includes a Source Link Layer address option with its own
        link layer address as the sender.  The SCoA address is found to
        be unique if no neighbour advertisment is received back within
        RetransTime milliseconds.

----------------------------
18. if SCoAs are more than can fit in a packet with MAX MTU



Pagtzis, Kirstein             Expires 10 January 2002               [Page 22]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



        As soon as uniqueness of the soft CoA is ensured at the RDC
        neighbour, the neighbour cache entry is marked as PROACTIVELY
        REACHABLE. This is a new state introduced for the purposes of
        enabling proactively the neighbour cache entry without  requiring
        a solicited neighbour advertisment.  This is illustrated in
        Figure 16.  If a neighbour solicitation is sent towards that
        RDC (from that link) that requires the LLA of the MN, then the
        RDC defends the soft CoA with its own LLA. This is because such
        neighbour solicitation is probably for the purposes of neighbour
        reachability or DAD rather than traffic forwarding to the soft
        CoA. This is because usually any host that attempts to contact
        the MN, will do so through its home address rather than directly
        using its CoA, since its does not know it.  In the event that
        a node is contacted directly through its soft CoA by a host
        without going through its home network and while the MN has not
        yet handed off to that RDC, then buffering at that RDC may be
        considered.


                 <figure provided in postscript version>

       Figure 16: Proactively Reachable neighbour cache entry state


        By setting the link layer address of the MN in the neighbour
        cache proactively and marking it with the P flag, the neighbour
        RDC requires minimal information in order to effect that LLA when
        traffic needs to be forwarded to and from the MN's particular
        soft CoA. This is because both the accomodating RDC neighbour and
        the MN are configuring their neighbour cache entry proactively
        with the particular entries marked as proactive and set in the
        state PROACTIVELY REACHABLE. In this manner, communication
        between the two entities does not need to go through a solicited
        neighbour advertisment explicitly; it can effect communication of
        packet traffic immediatelly.  The period for which a neighbour
        cache entry is set to the PROACTIVELY REACHABLE state is until
        the MN has sent a Binding Update to towards its peers.  This
        effects a stable active primary CoA (as detailed in following
        sections) and thus does not require proactive reachability in the
        neighbour cache of either the MN or the new CURRENT RDC.

        Upon succesfull completion of DAD for each of the SCoAs, instead
        of configuring an interface, the neighbouring RDC joins the
        SCoA to both all-nodes and respective solicited-node multicast
        address.  This way, the neighbour RDC can defend with neighbour
        advertisment the SCoA allocated proactively for the MN.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 23]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


        Each aggregate PI-DAD request message is acknowledged back to
        the CURRENT RDC with a respective aggregate PI-DAD Reply.  The
        reply contains an address bitmap which describes which addresses
        have succeded DAD. Each SCoA that has been checked for DAD
        successfully, is marked with 1 while each unsuccessful one is
        marked in the bitmap with 0.

        An aggregate PI-DAD check is expected to save individual DAD
        packet header overheads by means of aggregating DAD checks
        for each neighbouring RDC. An RDC awaits for a maximum period
        DAD_AGGREGATE_INTERVAL before its triggers a proactive aggregate
        PI-DAD request; this is done so that some DAD requests have been
        aggregated before the CURRENT RDC requests the check from the
        neighbouring RDC.

        Alternatively, a PI-DAD request message may be submitted to each
        neighbour RDCi   found in the PCN Cache, for each SCoA. It is
        known that the probability of a duplicate IPv6 address detected
        is very low (19) ; however, for reasons of precaution in the
        event of a vendor MAC address provisioning conflict, the IPv6
        community feels that DAD is not necessarily mandatory but would
        be recommended.  For this reason we consider as optional the
        reliance of every PI-DAD-Req on a returned Proactive Indirect DAD
        Acknowledgement (PI-DAD-Ack).  In the event that both messages
        are to be effected (20)  then the mobility neighbourhoood of the
        CURRENT RDC will receive for each SCoA tuple mapping to an MN the
        set of PI-DAD requests denoted by:


        <PI-DAD request denotation provided in postscript version>


        while similarly this may be acknowledged by:


        <PI-DAD reply denotation provided in postscript version>


     -  The CURRENT RDC unicasts the LLA of the MN to the neighbouring
        RDCn in a soft CoA Create message.  This is a relatively light
        message sent in the unicast packet.  Each of the receiving RDCs
        is empowered with the IP generation task; as such it combines
        the LLA of the MN into an IPv6 (soft) CoA; it then performs an
        Indirect DAD on the SCoA by triggering a neighbour solicitation
        in a fashion similar to the one for aggregate DAD. It then
        generates a neighbour cache entry that is also marked with P flag
        enabled as soon as DAD has succeeded for this SCoA. The entry
        is also set to the PROACTIVELY REACHABLE state.  This neighbour

----------------------------
19. 2^64
20. by setting a flag that enables one of the two options.


Pagtzis, Kirstein             Expires 10 January 2002               [Page 24]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



        cache entry include the LLA of the MN rather than the LLA of
        the RDC itself.  The existence of the P flag together with the
        PROACTIVELY REACHABLE state for the particular neighbour cache
        entry, establish behaviour described for aggregate PI-DAD and
        illustrated in Figure 16.


        In response the neighbour RDC returns the SCoA into a unicast
        soft CoA Ready (SCoA-Ready).  It may be noted that the generation
        of the Soft CoAs is now distributed, while the DAD function is
        performed on the spot during address creation time.  As such no
        DAD function need be proxied by the CURRENT RDC. Each address is
        sent in a unicast message back to the CURRENT RDC which in turn
        combines them into the SCoA tuple ready to be provided to the MN.


    From the two alternatives for SCoA generation the proposed scheme
opts for the second approach as more compact and efficient from a
signaling perspective.  The signal interactions for the two approaches
are illustrated in figure 17.


                <figure provided in postscript version>

           Figure 17: Signaling for the provision of SCoA tuple


    The CURRENT RDC must now proceed to inject the Roaming context
established, to the admitted MN. This may be achieved through a
Proactive Roaming State Push (PRS-PSH). This message includes the number
of neighbours for which proactive roaming context state is established.
It further contains an SCoA tuple identifier which uniquely identifies
the particular SCoA tuple and is associated with the respective binding
cache entry for the MN provided this roaming state.  For each neighbour
RDC the following established state:


     -  the IPv6 address of the neighbour RDC interface that effects part
        of the mobility neighbourhood.  This is expected to be used in
        the update of the default router list, as provisional default
        router list entries that are provisionally effected during
        handoff.


     -  the prefix length valid on the above interface.  Essential to
        derive link layer information for fast update of the neihbour
        cache of the MN. Such information targets to minimize or
        eliminate neihgbour discovery signaling that will be required
        when the MN appears on-link to some neighbouring RDC.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 25]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



     -  the generated soft CoA for MN. A globaly routable IPv6 address
        that can communicate traffic on-link to some neighbouring RDC.


    From this information the MN can further reconstruct other routing
information that complement the roaming context in the mobility
neighbourhood.  This is:


     -  the link layer address of the neighbouring RDC. It may be derived
        by using the prefix length together with standard EUI-64 rules
        for interface identifier generation.  This is to be used in the
        neighbour cache of the MN with the flag P set (PROACTIVE) and set
        in the PROACTIVELY REACHABLE state.


     -  routing prefix.  This may be derived by straightforward use
        of the prefix length to determine the routing prefix of the
        neighbouring RDC and populate the prefix list of the MN.


    The PRS-PSH message from the RDC in the CURRENT state must  be
acknowledged by the MN with a PRS Reply (PRS-Rep).  It is important that
the CURRENT RDC receives feedback by the MN on the successful receipt
of the PRS-PSH since the SCoA tuple will be facilitated to signal the
current active CoA upon transit to a neighbouring subnet.  This message
simply contains the number of neighbours as well as the sequence number
included in the original PRS-PSH message.


                 <figure provided in postscript version>

       Figure 18: The proactive set of soft CoAs provides 1-domain
                        lookahead network connectivity



    It should noted that the proposed scheme does not encourage the
creation of the SCoA tuple at the MN (stateless address configuration).
Reason for that is the number of signaling interactions required for
the generation of the SCoA tuple.  The second and strongest reason is
dependence on the response of the MN back to the CURRENT RDC must be
avoided at all costs.  This is so because such dependence will mean:


     -  the neighbouring prefixes need to be transmitted to the MN for
        the purposes of the SCoA tuple generation.


     -  the probability of latency between RDC and MN increases, should
        the reply message from the MN (carrying the created SCoAT by
        the MN) gets corrupted due to harsh fading conditions when the
        response is propagated back to the CURRENT RDC.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 26]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



     -  in the event that a check (such as DAD or ND) of the created
        (by the MN) SCoAT is required then the MN would not be able to
        utilise any of the CoA in SCoAT (as descibed in later subsection)
        unless a response is sent back by the neighbouring RDCs back to
        the CURRENT RDC, which then has to be sent back to the MN.



4.5.  Abstracting the Routing Identifier on the RDC


    The CURRENT RDC is also required to map the SCoA tuple generated for
the MN, onto a single Proactive Care of Address (PCoA). The PCoA address
is not  a unicast but a multicast IPv6 address.  It is assumed that all
RDCs are multicast-enabled.  The IPv6 protocol architecture mandates
IPv6 Multicast capabilities on the routers as the replacement of
broadcast (in IPv4) for core routing.  As such, the previous assumption
is valid.  The mapping of the SCoA tuple onto a PCoA is effected only
at an RDC. Such mapping is transparent from the perspective of the peer
entities of an MN, namely its HA and CNs.  That implies that both HA and
CNs continue to send packets towards the MN through the CURRENT RDC with
no knowledge about the existance of such mapping.  The RDC by effecting
the PCoA abstract routing identifier mapping over the SCoA tuple allows
the MN to receive traffic on any of the candidate transition coverage
areas of the (CURRENT) RDC's mobility neighbourhood.  More accurately,
to receive traffic on any future coverage area for which the soft CoA
allocated participates in the mapping to the PCoA (multicast) routing
identifier.


    With respect to the aforementioned mapping (Figure 19), this
involves:


     -  allocation of the multicast Proactive CoA (PCoA).

     -  submission of PCoA group membership reports for the individual
        soft CoA instantiations that are valid for the MN over the
        different RDCs.


                   <figure provided in postscript version>

                 Figure 19: Mapping a multicast address to
                          unicast IPv6 CoA listeners


    The PCoA group allocation process takes place only once at the home
RDC, as soon as it transits into the CURRENT state for the particular
MN. PCoA group membership reports are expected to be performed by all
candidate RDCs that will be accomodating the MN during its movement from



Pagtzis, Kirstein             Expires 10 January 2002               [Page 27]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


one subnet to another.  These candidate RDCs are expected to be the RDC
neighbours for the CURRENT RDC that accomodates the visiting mobile
node.


    While the multicast address allocation and management is also an
important task for the scalability of the proposed model to dense
populations of MNs, we assume a multicast PCoA is uniquely allocated
for the purposes of this scheme.  Currently, this aspect is pursued by
the IETF Multicast Address Allocation WG (MALLOC); The MADCAP protocol
[18] proposed in the MALLOC WG fits exactly this purpose.  As such any
further analysis on multicast address allocation is out of the scope of
this document (21) .


    The allocated PCoA (multicast group) is placed in the PRS-PSH
message before this is sent to the MN; this provides the MN with its
abstract routing identifier that is effective during handoffs.  The
inclusion of the PCoA in the roaming state pushed to the MN allow the
latter to be autonomous over its roaming state in the event of losing
network connectivity or purposely switching off its network interface
while transiting to a different RDC where it attempts to re-establish
connectivity.  This scenario is fairly common for MNs moving under
constrained conditions like, underground, non-continuous coverage areas,
forced switch-offs for safety reasons (22) .



4.5.1.  PCoA membership management for RDC neighbours


    Following allocation, the CURRENT RDC needs to inform each of
the neighbouring RDCs for which there is a soft CoA listener in the
respective tuple, to enable forwarding of traffic destined to the
multicast PCoA group in their downstream interface for which the
allocated soft CoA is valid.  This would allow the respective RDC
neighbour to assume that there exists (or is probable to exist) at least
one host that is interested in the traffic destined to the multicast
PCoA group.  Since multicast forwarding is completely independent of
the number of listeners as well as their IP identity, the neighbouring
RDC needs minimal information to enable multicast forwarding for that
PCoA group.  In fact, it only requires the multicast PCoA group as
well as the IPv6 prefix that maps to the particular network interface
that should forward multicast traffic on that cell of the mobility
neighbourhood.

----------------------------
21. we investigate multicast address allocation and management issues
for the purposes of this scheme in a separate draft

22. like aircrafts or any other vehicle prone to RF interference



Pagtzis, Kirstein             Expires 10 January 2002               [Page 28]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



    The CURRENT RDC employs two potential approaches of informing
the entire RDC neighbourhood, including itself in an IGMP-compliant
[11, 14, 10] fashion.  These are:


     -  request an explicit 'join' from MN

     -  request an implicit 'join' from neighbouring RDCs


    In the case of the explicit join, the CURRENT RDC solicits  an
explicit request to join the PCoA group.  The join request is directed
towards the MN; this is because the CURRENT RDC must ensure that the
MN will configure its hardware interface for the particular multicast
P CoAMN   group.  This explicit join solicitation, is piggybacked in
the PRS-PSH message to the MN by means of a join-bit flag (J). Upon
receipt of the J flag the MN proceeds with a multicast join for the PCoA
group and the particular interface over which the PRS-PSH was received.
The particular multicast join effected by the MN will configure its
multicast filter on its hardware interface [7] and also provide the
CURRENT RDC with an IGMP membership report which enables multicast
forwarding for at least one listener on that link.  The Multicast
Listener Discovery Protocol [8] ensures that the IGMP membership report
is sent by the MN using its link-local IPv6 address as the source
address of the membership report.

    In the case of the implicit join, the CURRENT RDC solicits an
implicit join request.  This join request is solicited to some or all
of its neighbouring RDCs.  Each of the neighbouring RDCs receiving an
implicit join solicitation (I-Join Sol) need also  enable multicast
forwarding for a particular PCoA group over the link for which the
advertised prefix was originally used to construct a valid soft CoA;
i.e.  the link on which the soft CoA is topologically correct.

    The implicit join solicitation message sent by the CURRENT RDC
includes only the PCoA multicast address.  This so since in multicast a
router needs to learn only that a listener exists on link.  It does not
need to know the identity of the listener and as such does not need to
include either the SCoA or the link-local address that the MN would have
on that link.

    It is reminded that any standard Multicast Listener discovery (MLD)
message in terms of Queries and Reports must be sent with a link-local
source address at the local link, for the particular downstream RDC
interface to receive traffic sent to a multicast group.  That is to say
that under traditional MLD signaling, the MN must send an MLD membership
Report on-link by using its link-local address as the source address of
the MLD message.  Figure 20 illustrates the issue where a neighbouring
RDC (e.g RDC6) has to enable group membership by implicitly receiving a
join solicitation from the CURRENT RDC (RDC0).



Pagtzis, Kirstein             Expires 10 January 2002               [Page 29]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                  <figure provided in postscript version>

                  Figure 20: link-local addresses used for
                          conventional MLD messaging



    The soft CoAs effected in the mobility neighbourhood are only
instantiations of the MN on the link of the neighbouring RDC. The
MN is not physically on-link at that neighbour RDC yet.  It is thus
required that the group membership for the PCoA is managed indirectly.
The following section presents how the issue may be alleviated by
introducing indirect multicast group management.



4.5.2.  Requirement for indirect Group management


    As seen in Figure 20, a standard MLD Membership Report normally
reaches RDC1 through LL-CoA1.  However, for the purposes of the
proactive mobility model, such report must now come through RL6 and then
through RL4, since the MN is not currently residing in the respective
coverage area of RDC1 but in the one of RDC0.  For that purpose the
proactive mobility model proposed, extends the standard MLD protocol to
handle indirect multicast listener discovery which is triggered by a
solicited, indirect join request.


    In particular, on receipt of an I-Join Solicitation, the receiving
RDC sets an entry in its multicast group membership list.  The entry
records the PCoA group and sets a timer for the membership to the
Group_Membership_interval as defined by [14].  The receiving RDC
then generates an Indirect MLD Membership Query (I-MLD Query) with
destination address the CURRENT RDC which solicited the I-Join message.
The I-MLD Query message is a Multicast-Address-Specific  query and is
periodic; it targets membership on a specific multicast group (in this
case the PCoA group) and is sent by the querying neighbour RDC every
Query_interval.  An I-MLD Query contains the PCoA address for which
group membership is managed indirectly, as well as a maximum response
delay time within which the Reporting RDC must report back.


    On receipt of an I-MLD Query by some neighbouring RDC the CURRENT
RDC sets a delay timer for that PCoA group to a random value from the
range [0, Max_Response_Delay].  The timer adjustments obey the rules
defined in standard MLD [14].  On expiry of the delay timer the CURRENT
RDC transmits an Indirect MLD Membership Report (I-MLD Report) with
destination IP address the query-originating RDC. This is shown in
Figure 21.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 30]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                  <figure provided in postscript version>

              Figure 21: Periodic I-MLD messaging between RDCs


    Repeated I-MLD Reports refresh the timer set in the group membership
list of the neighbouring RDC that originated the I-MLD Group-specific
query.  If no I-MLD Reports for the PCoA are received at the querying
RDC after the response delay of the last I-MLD Query has passed, the
querying neighbour RDC assumes that indirect group membership for that
PCoA must cease to be in effect.  As such the PCoA address is removed
from the membership list and the removal is made known to the multicast
routing component (link prune).


    It is intuitive that the neighbour RDC that provides a soft CoA in
this proactive mobility model becomes also the Querier for indirect
group management (23)  over the PCoA mapping.


    Both I-MLD Query and Report messages must be sent with a max hop
limit of 7 and an IPv6 Router Alert option in a Hop-by-Hop Options
Header.  The router alert value for the P-MLD Report must be set to
13.  The hop limit assumes a hexagonal coverage area pattern and thus
a mobility neighbourhood of 7 RDCs.  If I-MLD messages traverse more
hops than the hop limit identified then either the coverage area has a
different pattern or there is an error in the realised topology.


    I-MLD messaging is exchanged between RDC entities.  It must not be
exchanged with a host/MN. It also requires the introduction of a P flag
in the group membership list of an RDC; this flag signifies a proactive
group membership entry that is valid on-link for the mobility enabled
interface of that RDC.



4.5.3.  Indirect group management considerations


    It is possible that when the first I-MLD Query message is sent by
a neighbour RDC to the CURRENT one, the Query_interval is set such
that PCoA group membership is marked as persistent until instructed
otherwise.  That implies that the choice of the query interval
is possible to instigate persistency in indirect group membership
management.

----------------------------
23. it becomes clear that if RDC do not initially provide
a soft CoA, they decline participation in this proactive mobility model.
For these RDCs proactive mobility will not be effected



Pagtzis, Kirstein             Expires 10 January 2002               [Page 31]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



    This may be effected by setting the Query_interval value for the
particular group membership entry to infinity and assume persistent
membership at the PCoA until instructed otherwise.  The query interval
that denotes infinity is set to be -1.  However, in that event both the
original query and the respective I-MLD Report must be acknowledged
in order to effect a robust indirect PCoA join.  Unacknowledged I-MLD
messages are retranmitted.  The set of involved interactions are shown
in Figure 22.


                   <figure provided in postscript version>

                   Figure 22: Persistent MLD join on PCoA


    A value of infinity (-1) for the Query interval of the querying RDC
neighbour implies that the latter effectively suppresses periodic I-MLD
messages for the particular interface, with multicast forwarding on
that interface persisting indefinetely.  To revoke this persistency the
CURRENT RDC after transiting to the PREVIOUS state must send an explicit
I-MLD Done message to the neighbouring RDC that initiated the original
I-MLD Query.  Transition to the PREVIOUS state implies a handoff of the
MN to a new RDC.

    In this manner, the PREVIOUS RDC explicitly directs some RDC
neighbour to stop forwarding traffic, destined to the PCoA group, on
its mobility-aware interfaces.  This is when an active primary CoA
transits to the inactive secondary state with lowest priority candidate
designation; namely the CoA is not the CURRENT one and it is not
an highest priority candidate for handoff.  The I-MLD Done excludes
the PREVIOUS RDC itself since it initially received an explicit join
(standard MLD Report); as such standard MLD will query the link every
query interval (125 sec) to confirm that membership on-link for the PCoA
group is still required.

    The primary advantage of this persistent  join approach is that I-MLD
signaling is saved in terms of queries and reports when PCoA membership
has to be maintained for all neighbouring RDCs.  The disadvantage is,
however, that explicit notification upon leave is required rather than
invalidating an expired group membership entry for the mobility-aware
interface.


    On the contrary, the periodicity of queries provides mainly
robustness to the group membership protocol; that is, if an initial
report gets lost, membership is recovered at the next query interval
while on a lost I-MLD Done  message, membership simply expires since
there is no response to periodic queries.  Eliminating periodic



Pagtzis, Kirstein             Expires 10 January 2002               [Page 32]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



querying and reports requires that this signalls are made robust so
that multicast can work effectively.  It is for this purpose that the
proactive mobility model opts for the non-peristent group membership
management.

    We should note that MLD is tracked also by availability of different
versions of IGMP. It is for this reason the correct version dependent
Query interval field is updated accordingly depending on the approach
followed above.


4.6.  Benefits from mapping of mobility neighbourhood on PCoA group


    The gains from mapping between unicast CoAs and a unique multicast
PCoA are significant for a number of reasons:


     -  The PCoA group abstracts bindings to multiple unicast (soft) CoAs
        at the CURRENT RDC. That implies that in essense handoffs over
        multicast are employed always at the RDC that is nearest to the
        MN.

     -  the above abstraction is hidden from HA and CN which operate
        transparently.

     -  eliminate dependency on updated unicast bindings until the
        MN is well-settled into a new RDC. This is because the MN is
        identified with a single routing identifier during handoff and
        for 1 RDC-controlled coverage area ahead.

     -  the only entity responsible for maintaining the mapping between
        the soft CoAs and the PCoA group is the CURRENT RDC. This RDC
        will always be closest to the MN before and during handoff.

     -  It abstracts more than one possible routing domains behind a
        single routing identifier.  As such that enables the PCoA to
        identify not only the current active CoA but, furthermore, a set
        of tendative  CoAs for that MN, comprizing its SCoA tuple.

     -  the CURRENT RDC, as the nearest point of attachment, has the
        necessary information to decide which CoA(s) from the SCoA
        tuple will join the PCoA. This caters for optimization over the
        selection of the best candidate (24) , multicast-forwarding, RDCs
        that need to receive traffic on the PCoA of the MN as the latter
        transits between these RDCs.

----------------------------
24. the ones that show the highest probability of transiting to the
CURRENT state



Pagtzis, Kirstein             Expires 10 January 2002               [Page 33]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



     -  As a corollary to the above coverage area bouncing effects are
        simply eliminated from the handoff process.


     -  each candidate RDC will receive a single copy of the traffic that
        is destined to the MN.


4.7.  Activity on the part of the MN

    The receipt of the SCoA tuple through the PRS-PSH message, provides
the MN with a one-level depth tree of proactively generated soft CoAs
representing a 1-hop lookahead view, shown in Figure 18, of the RDC
neighbourhood with respect to the CURRENT RDC. Each individual soft CoA
represents an instantiation of the MN in existence within the coverage
area of a neighbouring RDC.

    With respect to the SCoA tuple, available to the MN, it is
soft-enabled; this implies that a single CoA has been allocated for that
MN at some RDC neighbour but is yet to be used in the near future.  Full
routing information is also provided to the MN (through PRS-PSH) in
terms of default router (the neighbour RDC itself) as well as a prefix
size (i.e.  netmask).  Furthermore, the receipt of the PRS-PSH message
implies that each RDC neighbour has proactively updated its neighbour
cache with the LLA of the MN as described in previous sections.

    The receipt of the PRS-PSH message must trigger the following actions
on the part of the MN:

     -  it must return a PRS-Rep that acknowledges the receipt of the
        PRS-PSH message so that the CURRENT RDC can ensure that it
        can proceed robustly with the required set of interactions
        during handoff.  The PRS-Rep message includes the number of
        RDC neighbours that were received over the PRS-PSH message
        as well as the sequence number that identified the original
        PRS-PSH message.  If the PRS-Rep message is not received within
        Proactive_context_push_time the original PRS-PSH message must be
        retransmitted.

     -  it must join the PCoA group iff the J and M flags area set.  This
        is done by means of a standard MLD Report destined to the PCoA
        group and with source address the current link-local address.
        The standard unsolicited MLD Report is also expected to configure
        the LLA address of the MN for multicast filtering at its hardware
        network interface.  Robusteness of PCoA membership is sustained
        according to the robustness variable value of the MLD protocol
        [8].

     -  it must update its default router list with the set of
        neighbouring RDC IPv6 addresses.  These addresses are expected



Pagtzis, Kirstein             Expires 10 January 2002               [Page 34]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



        to be topologically correct on the link that identifies part of
        the mobility neighbourhood for that RDC neighbour.  Each default
        router entry for the neighbouring coverage areas of the mobility
        neighbourhood must be placed at the end of the default router
        list and must be marked with a P flag.  When the P flag is set
        the particular default router entry must not be used.  A P flag
        is removed from a default router entry as soon as a PCoA-Enable
        message is generated by the MN towards the CURRENT RDC. When a P
        flag is removed each of the proactively configured default router
        entries are used according to the standard forwarding mechanisms
        of [9, 31].

        Alternatively the MN should update its prefix list by deriving
        each neighbour RDC prefix through the neighbour RDC IPv6 address
        and its prefix size.  Each prefix list entry is also marked with
        a P flag.  The rules defined for the default router list apply
        also for the prefix list.

     -  it must update its own neighbour cache with an entry for the LLA
        of each neighbour RDCs.  Each such entry must be marked with the
        P flag and set to the PROACTIVELY REACHABLE (P-REACHABLE) state.
        Both P flag and P-REACHABLE state in a neighbour cache entry of
        the MN, signifies that the former must not be checked for address
        resolution or neighbour unreachability detection with a neighbour
        solicitation; this is so because a REACHABLE (albeit proactively)
        neighbour cache entry exists for the RDC neighbour in the MN.
        This is in effect until the P flag is removed from this entry.
        A P flag is removed from a neighbour cache entry if and only if
        the MN sets a soft CoA to the active state, becoming its primary
        IPv6 address.  The setting of the P flag intends to allow the
        MN to transmit upstream packets without having to engage into
        either address resolution or neighbour unreachability detection,
        when it arrives on-link within the coverage area controlled by a
        neighbour RDC.

     -  it may multi-home its interface with the available soft CoAs.
        In this case, the MN should transmit or receive on any of the
        soft CoAs if and only if a PCoA-Enable message is sent by the MN
        towards the CURRENT RDC.


4.8.  PCoA Activation Lifetimes

    Having configured group membership of the mobility neighbourhood for
the RDC neighbour, the CURRENT RDC must configure internally the PCoA
group with two lifetimes Ls and Ld.  The two lifetimes are mobility
management specific and extend the standard MLD protocol as follows:



Pagtzis, Kirstein             Expires 10 January 2002               [Page 35]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


     -  Ls (PCoA start lifetime):  represents the lifetime past which
        the CURRENT RDC should initiate sending of the unicast packets,
        that are destined to the MN, through the configured PCoA
        multicast address.  Its initial value should be -1 which is
        designated as infinity  for time values in the proposed scheme as
        described in previous sections.

     -  Ld (PCoA stop lifetime):  represents the lifetime past which
        the CURRENT RDC should stop sending of packets through the
        PCoA towards the MN. This situation occurs when the CURRENT
        RDC transits to the PREVIOUS state, i.e.  the MN hands-off to
        a NEW RDC. Effectively, Ld represents the lifetime for which
        the CURRENT RDC must forward the traffic destined towards the
        MN, through the PCoA group of the MN. Its initial value must be
        0.  It is expected that before the expiry of Ld lifetime, the
        MN will have informed its peers entities of its new active  CoA
        with a standard Binding Update.  In this manner, forwarding of
        traffic towards the MN over the PCoA group can be stopped from
        that particular RDC which has transited to PREVIOUS state.

    While forwarding of the traffic, towards the MN, through the
PCoA group is stopped locally  at the PREVIOUS RDC, it only suspends
globally.  This is because traffic will be sent to the MN through the
PCoA group during every handoff, from the next valid CURRENT RDC. This
is the reason for requiring that the particular PCoA allocated to the MN
should persist so as to avoid unnecessary reconfiguration costs of a new
PCoA. Future versions, however, of this proactive mobility management
scheme do not preclude PCoA reallocation under special conditions.
It is beyond the scope of this version of the document to engage in
analysis of such conditions.

    Furthermore, since the CURRENT RDC changes as the MN moves across
different cells (25) , the multicast core [3, 35 ] or RP [12] router will
effectively move together with the movement pattern of the MN. Since
the average cell size for PCS systems is bound to be reasonably large
(around 1-2.3 km), the movement of the multicast RP root (26)  (PIM-SM)
or core (CBT) will be relatively slow with respect to the movement speed
of the MN. Furthermore with respect to PIM-SM if the data rate of the
traffic destined to the MN, warrants it, the receiving active CoA will
be listening to the shortest path distribution tree [12].

    Ls and Ld is expected to be conditioned by the mobility vector of
the MN in the case that optimal lifetimes should be pursued.  The
intention for these fields is to provide a time window during which

----------------------------
25. when each cell or cell cluster is controlled by a different RDC
26. shared tree


Pagtzis, Kirstein             Expires 10 January 2002               [Page 36]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



handoff would be in progress as a rough estimate.  More accurate
lifetime refresh messages may be provided as the MN moves towards a
candidate RDC.


4.8.1.  Proactive Handoff transitions between neighbouring mobility links

    At some point in time, the MN reaches some overlap area between the
CURRENT RDC and one or more neighbour RDCs.  The router adverts sent
from the candidate RDCs (core MIPv6), over the all-nodes (link-local)
multicast address, would provide sufficient prefix information to allow
the MN to distinguish and enable one or more (27) , candidate CoAs from
the SCoA tuple.  At this point there is no setup required by the MN or
the candidate RDC.


    The MN would only need to inform the CURRENT RDC (which is soon to
transit to the PREVIOUS state) about the highest priority candidate
(soft) CoAs by simply raising a flag within an internal soft CoA Flag
Bitmap (sCoA-FB) kept within the MN for the SCoA tuple.  That flag sets
the respective CoAs in the SCoA tuple as inactive secondary with highest
priority candidate designation.


    In the proposed model a CoA may transit between the following states:

     -  active primary.  This is a single CoA that is actively used for
        communications with CNs and HA when the PCoA is not activated or
        gets de-activated.

     -  inactive secondary.  This is one or more CoA(s) that have been
        allocated for the particular MN over different RDCs.  An inactive
        CoA must in turn transit between lowest priority candidate  and
        highest priority candidate  state before it transits to the
        active primary state.  In particular:

         *  highest priority candidate.  This is one or more inactive CoA
            that has been determined to be the most likely candidates for
            activation.  The main criterion for candidacy is currently
            the based on a single RDC advertisment detection (28)  and
            mobility neighbourhood information surrounding that RDC
            advertisment.

         *  lowest priority candidate.  This is one or more inactive
            CoA(s) that are least likely candidates for activation.

----------------------------
27. at most 3 for a mobility neighbourhood of 6 cells.

28. Criteria for activation may comprize of link layer SNR stability
metrics over some time period



Pagtzis, Kirstein             Expires 10 January 2002               [Page 37]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



            Optimizations may provide some probability-oriented ordering
            of these least likely candidates, particularly in the event
            that the probability of candidacy for the highest priority
            candidate  CoA thresholds close to lowest priority candidate
            CoAs.  This may be viewed as movement of the MN on the
            boundaries of more than one neighbour RDC links.

    These states effectively denote when a soft CoA is actually promoted
towards an active primary CoA for the communications of the MN when the
PCoA group is not activated or gets deactivated.  This is the case at
the end of a stable  transition of the MN from the previous RDC to a new
one.

    As soon as the MN has set as inactive secondary with highest
priority  some CoA within its SCoA tuple, it generates a PCoA-Enable
(PCoA-E) message that includes, the sCoA-FB and a lifetime refresh on
both Ls, Ld.  In this message Ls is set to 0 while Ld is set to -1
(infinity).  The message includes also the SCoA tuple identifier from
the original PRS-PSH message to associate the PCoA activation signal
with the correct PCoA that is associated with the particular SCoA
tuple; the later is also associated with the binding cache entry for
the particular MMN. The PCoA-E message is then sent to the CURRENT RDC
through a unicast packet.  The receiver of the PCoA-E message, (i.e the
CURRENT RDC) is expected to enable sending packets immediately to the MN
through the PCoA multicast address, and stop sending unicast through its
primary active CoA, since the PCoA start lifetime has value Ls = 0.

    The traffic sent towards the MN is received transparently at the
CURRENT RDC and then forwarded to the MN over its PCoA as encapsulated
multicast payload.  To effect such type of forwarding, when the PCoA-E
messag has been received by the CURRENT RDC, packets arriving at the
CURRENT RDC are forwarded to the PCoA group of the MN. This is done by
matching the destination on-link CoA of the MN in each received packet
with the respective Binding Cache entry  at the CURRENT RDC which is now
extended to hold also:

     -  the Roaming state allocated for the particular MN. This includes
        the SCoA tuple allocated to the MN and gets associated with the
        PCN cache of the CURRENT RDC to locate routing information about
        the neighbour RDCs.

     -  the LLA of the MN

     -  the PCoA mapping of the Roaming state for the particular MN,
        together with the PCoA start and stop lifetimes

    Upon successfull match of the destination CoA, the received packet
at the CURRENT RDC is encapsulated into a multicast packet with
destination the PCoA group of the node.  Since the neighbour RDCs have


Pagtzis, Kirstein             Expires 10 January 2002               [Page 38]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


been configured to listen to the particular PCoA group and subsequently
forward traffic for that group on their mobility-enabled links, traffic
destined to the MN would be available to all the links of the mobility
neighbourhood of the CURRENT RDC and subsequently of the MN. It should
be reminded that the configuration of the hardware interface (LLA)
multicast filter at the MN, does not depend on the unicast IP CoA
allocated for the MN, but only on the PCoA (29) . That implies that the
MN would be able to receive traffic on any of the reachable links of the
mobility neighbourhood as soon as link-layer connectivity is established
with the particular mobility neighbouring link and the particular soft
CoA has been enabled on its multihomed interface.

    The proposed model introduces the notion of a multicast encapsulation
for the purposes of delivering the traffic to all neighbouring RDC
during activation of the PCoA group.  Encapsulation over multicast
encapsulates a normal unicast packet as the payload of a multicast
packet, while it introduces a special flag (MT) called multicast tunnel
placed as a destination option in the IPv6 header.  On receipt of such
packet, the MN must check the destination options of the packet whether
the MT flag has been set; if the flag is set, the MN decapsulates the
payload by removing both IP and UDP encapsulating headers from the
multicast packet, without submitting the packet to the (UDP) transport
layer.  The decapsulated packet is then submited back to the IP stack
for further processing.  The packet would now have as destination
address the on-link CoA at the CURRENT RDC which the MN must sustain
as an active CoA until a new active CoA has been selected and the
respective peer entities have informed through the standard Binding
Update.

    Traffic will be destined to the PCoA group for time Ld.  Since Ld
has been set to infinity the CURRENT RDC will continue to send traffic
towards the MN through the PCoA, until instructed otherwise.

    The rationale behind setting Ld to infinity and not to some finite
time period is because it is highly likely that the MN does not perform
what is termed as a clean handoff between two RDC and their underlying
coverage areas.  Instead, it is expected to bounce multiple times
between coverage areas.  Such bouncing effect is primarily related to
the direction of the MN with respect to the geographical position of
these coverage areas.  This may be dictated by various factors such as
direction-constrained movement, over roads, air, sea.  Currently the
road, air and sea path planning are completely uncorrelated to the
positioning of cells in cell positioning and planning.  It is, thus,
expected that movement of MNs is not bound to follow straight crossings
between cells.  This is illustrated in Figure 23.

----------------------------
29. its last four octets in particular



Pagtzis, Kirstein             Expires 10 January 2002               [Page 39]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                  <figure provided in postscript version>

              Figure 23: Bouncing effects incorporated in the
                          movement pattern of the MN


    It can be seen that within the overlap area some 3 different coverage
areas (mapping to different RDCs) are visited during MN's transition
over the overlap area and subsequent handoff.  To avoid oscillatory
signaling by the CURRENT RDC that enables or disables dispatch of
traffic over the PCoA or an active CoA, the initial PCoA-E message sent,
effect such PCoA start and stop timings that allow sending traffic to
the MN over the PCoA group until explicitly requested to stop doing so.

    The MN continues to receive traffic over the PCoA until it detaches
from the CURRENT RDC plus some random time Te that intialy varies
between 250 and 500 (30) ms.  Te is introduced for the purposes of
ensuring reception of traffic through PCoA during cell bouncing effects
in the MN's movement pattern between its CURRENT RDC and a neighbouring
RDC; The time period Te is defined as Extended PCoA-Rx Time.  The MN
maintains also a cell-bounce accumulator (CBA) that tracks the number of
bounces between the two RDCs.  This accumulator geometrically increases
Te for each increment of it counter for the individual MN. The delay
Te is bounded by an upper delay maximum defined as Max_Random_PCoA_Rx
Stop_Delay equal to 3000 ms (31)


    When the extended PCoA-Rx time elapses and the cell-bounce
accumulator has not increased, the MN proceeds to send a standard
Binding Update to the CNs and the HA to inform about the new, stable
and topologically correct CoA as activated by the MN (see Figure 24).
At the same time the MN sends a PCoA-Disable (PCoA-D) message to the
PREVIOUS RDC, through its new active CoA (i.e the new CURRENT RDC) to
inform about the deactivation of the PCoA in terms of forwarding traffic
towards the MN. The PCoA-D message contains the specific PCoA group
and updated lifetime values for Ls and Ld which are set to -1 and 0
respectively.

    The PCoA-D message instructs further the PREVIOUS RDC to manage
group membership of the PCoA group.  This mainly manifests itself as a
need to 'prune' some of the neighbour RDC 'listeners' (32)  that do not

----------------------------
30. this figure needs further experimentation

31. initial and max value should be conditioned by the overlap area
between two cells as well as the speed of the mobile

32. PCoA group forwarders



Pagtzis, Kirstein             Expires 10 January 2002               [Page 40]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                  <figure provided in postscript version>

                Figure 24: MN activates the correct soft CoA


match with the current view of the mobility neighbourhood of the new
CURRENT RDC. The PCoA-D message includes also the SCoA flag bitmap which
signifies which is the new active primary CoA.


4.8.2.  SCoA tracking and Cell-Bounce Accumulator

    The cell-bounce accumulator operates on the SCoA tuple represented
by the SCoA flag bitmap and is maintained at the MN. Such bitmap
includes a flag for each soft CoA, including the primary active one; it
is not expected to increase more than 7 bits for the entire mobility
neighbourhood, although it is not limited by such figure.  In this
bitmap, the accumulator tracks the CURRENT RDC by means of its CoA flag.
This is designated a parent status and takes a value of 1 at the CURRENT
RDC. As long as the parent flag does not flip to 0 (33) , then the MN is
expected to stay associated with its CURRENT RDC even if it is bordering
at the cell perimeter.  The parent status is not reset to a different
flag within the bitmap until the MN signals a new active primary CoA to
its peers (HA + CNs).

    Receipt of standard router advertisment flip the relevant flag within
the bitmap.  Thus, upon movement of the MN to an overlap area between
two coverage areas, the parent flag is flipped to 0; then the CBA seeks
for a single  CoA flag that has flipped to 1 within the bitmap while
the total number of flags marked with 1 stays the same.  In other words
the CBA scans for an equilateral value change between only two bits
within the bitmap.  Such change in the bitmap signifies a clean handoff
from the previous RDC. Because there is no way to distinguish between a
clean handoff and an imminent cell bounce, the reception at the PCoA is
sustained for the period defined as Extended PCoA-Rx Time.  This would
prevent oscillatory signaling from the MN to its peer entities about
switching between the PCoA group and some active CoA for the dispatch of
packets towards the MN.

    If a cell-bounce is, indeed, imminent the CBA will observe the parent
flag flipped back to 1, since the parent status must not be reset to
a new flag until a new CoA has been signaled (as active primary) to

----------------------------
33. due to lack in reception of the respective RDC router advert by the
MN


Pagtzis, Kirstein             Expires 10 January 2002               [Page 41]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


the peer entities by the MN. This, however, signifies cell-bouncing
candidacy, since the MN is still within the boundaries of the candidate
primary CoA activation.  It is for this reason, that the cell-bounce
accumulator does not consider the movement as yet a cell-bounce.  Thus,
the CBA does not yet affect the timer as it should not yet reset so as
to backoff from signifying to the peers the new active CoA.

    As it may be seen by Figure 4.8.1, the parent flag would be flipped
back to 1, when the MN would receive again a router advertisment from
the PREVIOUS RDC. The CBA identifies a cell-bounce candidate but does
not yet affect the PCoA-Rx timer since the MN is still within the cell
of the CoA that is set to highest priority candidate and its respective
RDC. As soon as it detaches from the latter a cell-bounce has been
established.  At this point the CBA, at the MN, triggers a backoff
for the dispatch of the PCoA-D signal by geometrically increasing the
PCoA-Rx timer value and continues tracking parent status, until the
timer expires while the SCoA flag bitmap stays unaltered.

    On expiry of the PCoA-Rx time, while no CBA backoff has been
triggered, the PCoA-D message is sent towards the PREVIOUS RDC (or to
the RDC that still remains in the CURRENT state) and the parent status
is either reset to a new CoA or stays the same flag in the bitmap; that
implies that either the new active primary CoA has been identified with
the MN moving to a new coverage area or the old CoA is still in effect
and movement still effect the same coverage area.  In the event of the
former, the MN:


     -  first configures its link-local address that is valid over the
        new link.

     -  sends a neighbour advertisment which removes the P flag from the
        neighbour cache of the RDC.

     -  send a Binding Update (BU) to the NEW RDC

     -  informs its peers about the new CoA with a standard BU, while the
        CBA is reset to 0 and reinitiates tracking for a new parent (new
        CURRENT RDC).

    It has been previously noted that a clean handoff, even on the verge
of an imminent cell-bounce is not always the case.  It is possible for
instance that a maximum or 3 RDC router advertisments can be heard by
the MN before it gets detached from its CURRENT RDC. That implies that
there exist more than one  alternative handoff candidates.  This is
manifested over the flag bitmap, as shown in part 2 of 4.8.1, by means
of having two CoA flags flipped to 1 when the parent has been flipped
to 0 (i.e.  got detached from CURRENT RDC). In that case the MN must
select one of the two CoAs as the one to be promoted from first as



Pagtzis, Kirstein             Expires 10 January 2002               [Page 42]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



highest priority candidate  and then to the active primary  state.  The
selection is bound to be probabilistic.

    Our model opts for two different selection criteria:

     -  maximally traversed cell/RDC selection.  This implies that, the
        MN would select to activate that CoA that maps to the cell that
        has been traversed most.  This can be determined by the flag
        bitmap at the IP layer although it is coarse (34) .

     -  minimally traversed cell/RDC selection.  The cell/RDC that has
        not been traversed much will be selected through the respective
        CoA activation.

    We should note that the above selection criteria are serving more
the MN rather than the network.  For instance it is possible that the
network needs to select that RDC which is less loaded.  We argue,
however, that such selection benefit is bound to be negated if it
opposes to the movement pattern of the MN. That is to say, that if the
MN needs to move towards the cell that serves its intents better, then
the load balancing decision would incur simply more handoffs between the
involved cells/RDCs.


4.8.3.  Refreshing the soft CoA tuple

    The proactive facilitation of the PCoA group for the traffic
forwarding towards the MN allows the latter to move around the mobility
neighbouhood of the CURRENT RDC with much greater freedom and without
the potential of packet loss during cell bounce effects during its
movement pattern.  To sustain such freedom of movement the MN must
maintain a fresh SCoA tuple that is valid over the new  mobility
neighbourhood of the new CURRENT RDC.

    A straightforward approach would be to drop all allocated soft CoAs
except for the active CoA that is valide at the NEW RDC. The NEW RDC
would then need to initiate the process of soft CoA allocation according
to the model already described.  That, however, would require that the
NEW RDC invalidates even these soft CoAs that would be common with the
routing neighbourhood of the PREVIOUS RDC.


----------------------------
34. however if
the neighbouring cell pattern contains more RDC neighbours, like 8 or 10
then traversal determination improves significantly at the IP layer



Pagtzis, Kirstein             Expires 10 January 2002               [Page 43]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



                   <figure provided in postscript version>

                  Figure 25: Router Advertisments and link
                          detection at overlap areas


    Consider for instance the example of Figure 4.8.3.  During its
transition path to a new RDC the MN is expected to establish receipt of
multiple RDC router advertisments over some overlap area between 2 or
3 cells.  In the event that the CURRENT RDC (C) opts for invalidating
the entire soft CoA tuple (except for its own active CoA), it would
essentially invalidate also re-usable soft CoA of the common RDC
neighbours between A  and C. That would require that:

     -  the NEW RDC informs the PREVIOUS RDC with an SCoAT invalidation
        request for the entire soft CoA tuple, while it excludes the
        originator of the request.

     -  it initiates a new SCoA tuple generation from scratch.  That
        would include also the common neighbours of (A) and (C).

    The above, while a cleaner solution, would effectively incur more
latency in the generation of valid soft CoAs in the newly generated
tuple.  This is so since, clearly, the NEW RDC could reuse the common
soft CoAs between the two neighbouring RDCs as the former transits to
the CURRENT state.

    Alternatively, the new CURRENT RDC need only provide the MN with a
specific soft CoA tuple update (SCoAT-Update) that would include only
the new  neighbouring soft CoAs that are valid in the neighbourhood
of the new RDC, together with the flag bitmap that invalidates soft
CoAs that are redundant in the mobility neighbourhood (35)  of that
CURRENT RDC. Furthermore, the PREVIOUS RDC should receive invalidation
information about the redundant soft CoA RDC neighbours.

    We should note that the new CURRENT RDC is aware of the LLA of the MN
since it created a soft CoA for that MN in the past and as such it has
stored it in some secondary store (36) .

----------------------------
35. but valid in the PREVIOUS RDC

36. a cache would probably be an overkill since that RDC does not know
when it will needed and it is not bound to be used soon before the MN
hands off to that RDC.


Pagtzis, Kirstein             Expires 10 January 2002               [Page 44]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


    Figure 26 illustrates the idea.  In a 6-cell mobility neighbourhood
the first SCoAT allocation would require six (6) new soft CoAs.  At the
next handoff the soft CoA tuple need only be refreshed with another 3
soft CoAs.  This is half the number of soft CoAs originally allocated.



                 <figure provided in postscript version>

            Figure 26: CoA resuse within the SCoA tuple during
                        continuous movement of the MN



    For the above approach to work efficiently and without extraneous
message overhead it is essential to see how the PREVIOUS RDC resolves
the identity of the true redundant RDCs and their respective soft CoA.



4.8.4.  Resolution of redundant SCoA RDC neighbours


    In the proposed model, an SCoAT-Update requires that the PREVIOUS RDC
resolves accurately the RDCs that are truly  redundant.  We emphasize on
'truly', because, the cell-bouncing effected by the mobility pattern of
the MN is likely to cause an inaccurate resolution of reduntant SCoAs at
the PREVIOUS RDC, when the MN 'settles' to a new active primary CoA at
some NEW RDC. This of course is higly dependent on the mobility pattern
of the MN and the correlation of its movement (37)  to the position of
the neighbouring cell RDCs.


    We argue that proactive resolution of the ultimate reduntant SCoAs
before the MN 'settles' with a single active primary CoA (from the
allocated SCoA tuple) is bound to result in significantly extraneous
signaling that may be rendered invalid by the movement pattern of the
MN. An MN is considered to have settled within a coverage area, as soon
as it has sent a Binding update towards its peers informing about the
new primary active CoA.


    The Binding Update sent by the MN towards the NEW RDC at the start
of the settlement period, provides the NEW RDC with the address of the
PREVIOUS RDC. The BU also encompasses a SCoAT invalidation request
(SCoAT-INReq) flag.  By setting such flag, the address of the PREVIOUS
RDC provided through the BU to the NEW RDC, triggers the latter to
determine the soft CoAs for the neighbouring RDCs that are common
to both NEW and PREVIOUS RDCs, as indicated by the contents of the
NEW RDC's PCN-Cache.  This is illustrated in Figures 28 and 27.  By

----------------------------
37. for instance road reconing


Pagtzis, Kirstein             Expires 10 January 2002               [Page 45]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



determining the common RDCs between the mobility neighbourhood of the
NEW and the PREVIOUS RDC, the two entities can proceed to include  new
RDC neighbours and exclude redundant RDC neighbours respectively as
follows:


    <Common, Include, Exclude sets denoted in postscript version>


    Where MNx is the mobility neighbourhood of RDC x maintained within
the PCN Cache of each RDC. RDC 14 represents the PREVIOUS RDC while
RDC 8 represents the NEW one.  While the common RDC neighbours are
determined at both the PREVIOUS and NEW RDC, the exclude operation is
scheduled at the PREVIOUS RDC where redundant soft CoA are removed from
the SCoA tuple.  This also implies that the respective RDCs must be
removed from listening at the PCoA group.  On the contrary, the include
operation is scheduled at the NEW RDC, where new valid soft CoAs need
to be generated and added to the SCoA tuple of the MN. This further
implies that the underlying PCN-Cache entries must be amended, while RDC
neighbours must be added as listeners to the PCoA accordingly.


                  <figure provided in postscript version>

    Figure 27: Resolving the RDC participants that need to be included
                      and excluded from the PCoA group


    On receipt of the BU with the SCoAT invalidation request flag set,
the NEW RDC, generates a similar message which is sent to the PREVIOUS
RDC such that the latter can proceed with release of the redundant soft
CoA. This is achieved by either suppressing the sending of I-MLD Reports
to the redundant RDCs or by explicitly sending an I-MLD Done message
to each of them.  In case of the former, each redundant RDC neighbour
expires from its group membership list the particular PCoA address
entry while it removes the neighbour cache entries that pertain to the
associated MN after receiving an indirect neighbour advertisment (I-NA).
In the case where the I-MLD Done message is sent to the redundant RDC,
the PCoA to be removed from the membership list is specified.  Similarly
an indirect neighbour advertisment invalidates the redundant neighbour
cache entry at that RDC.


    The inclusion of the NEW RDC neighbours in the PCN-Cache, triggers
the generation of a subset of new soft CoA for the SCoA tuple associated
with the MN. In this case the new PRS-PSH generated at the CURRENT
RDC sets an R flag; this denotes a refresh of the SCoA tuple and its
suplemental RDC information.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 46]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



4.8.5.  Managing the I-MLD Done at the PREVIOUS RDC


    Having identified the RDCs for exclusion at the PREVIOUS RDC, the
latter should issue a I-MLD Done unicast message to the specific RDCs
that should 'leave' the PCoA group, as shown in Figure 28.  The I-MLD
Done contains the PCoA group for which the RDC must stop forwarding of
traffic.

    It should be noted that the particular management of 'leaves' on the
PREVIOUS RDC need not necessarily be manifested through explicit I-MLD
Done messages towards redundant RDCs.  It may suppress any indirect
messaging towards these such that the group membership list entries
expire and get discarded.


                  <figure provided in postscript version>

     Figure 28: Sustaining accurate mapping of RDC neighbours on MN's
                        PCoA group routing identifier


4.8.6.  Managing the PCoA 'joins' at the PREVIOUS RDC

    In a much similar fashion the NEW RDC can resolve the new RDCs that
need to be included in the PCoA group.  This resolution triggers the
issue of a new indirect join solicitation message which initiates the
process of indirect multicast listener configuration.  The message is
sent in a unicast packet on a per-included-RDC basis.

    Past the inclusion of the NEW RDC neighbours in the PCoA group the
CURRENT RDC either constructs the relevant soft CoAs from the respective
new RDC prefixes or its distributes the task of soft CoA generation to
the included new RDCs as described in previous sections.  Part of the
soft CoA generation process, i.e.  the DAD check, ensures that the new
included RDC also amends appropriately its neighbour cache entry with
the LLA of the MN, the P flag while it sets the neighbour cache entry to
the PROACTIVELY REACHABLE state.  We remind that both the P flag and the
aforementioned state are removed only at the new CURRENT RDC for which
the MN has settled its active primary CoA.

    The newly created soft CoAs are pushed as part of the roaming context
for the MN, in a PRS-PSH message towards the MN with the SCoAT-Update
flag (R) set, to signify that this is only an update to the existing
SCoA tuple.  This message carries also a SCoA 'exclude' address bitmap
that signifies to the MN which soft CoAs it needs to discard from its
SCoA cache.


Pagtzis, Kirstein             Expires 10 January 2002               [Page 47]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



4.8.7.  HA and CN considerations


    The proactive mobility model will be transparent to the operation of
both the HA and the CNs.  Standard binding updates will be sent to the
peer HA and CN entities to inform about the new active CoA.



4.8.8.  Continuous vs disrupted connectivity during MN movement


    It is possible that the MN does not maintain a continuous movement
pattern over a set of adjacent (contiguous) adminstrative domains.  For
instance, the MN travels under such conditions that requires it to turn
off its network interface and as such disrupt its connectivity.  Typical
such examples is movement through road tunnels, by means of aircraft or
sea carriers or through underground train stations.

    It also possible that the MN encounters black holes of network
connectivity in the radio access network coverage area over some
specific geographic location.

    Under such circumstances the MN needs to maintain persistent state
about a minimal set of information.  These are:

     -  its home network HA IP address.

     -  its allocated PCoA.

     -  the last CURRENT RDC which upon turning on of the interface or
        bootstrap it checks whether it is still valid; otherwise the
        entry transits immediately to the PREVIOUS state.

    Depending on whether the MN switches off completely or just
its network interface as well as whether is has received any RDC
advertisment within DISRUPTED_CONNECTIVITY_TIME, the MN will need to
engage in different reconnection approaches.  In particular,

     -  if the MN is switched off completely, and assuming
        that the visiting RDC in which it will bootstrap is
        proactive-mobility-aware, the MN will need to obtain on-link
        IP connectivity before it can contact its HA and CNs according
        to the IPv6 base mobility rules.  The MN must inform its last
        PREVIOUS RDC about the new CURRENT RDC so that the former can
        request its neighbouring mobility RDCs to leave the PCoA for
        that MN. Upon receipt of such message the PREVIOUS RDC may (or
        may not) send a I-MLD Done since the Querier will expire the
        PCoA membership on the particular interface should it has not
        received an I-MLD Report update for some time.  If the NEW RDC IP
        address is not in the PCN-Cache of the PREVIOUS RDC, the latter
        invalidates the the entire old soft CoA tuple and propagates such


Pagtzis, Kirstein             Expires 10 January 2002               [Page 48]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



        invalidation to the respective RDC neighbours in terms of PCoA
        group membership and release of the allocated SCoAs through I-NA
        messages.  This is because the neighbours of the PREVIOUS and the
        new CURRENT RDC are completely different.

        Thus, a new SCoA tuple is being generated.  PCoA group membership
        is then reinitialised at the new CURRENT RDC from scratch,
        pending an optional acknowledgement from the PREVIOUS RDC to
        confirm invalidation of PCoA group membership and SCoAT bindings
        for the MN at its RDC neighbours.

     -  the MN has turned off its interface but is not completely
        switched off.  Here the MN needs to track the receipt of the
        last RDC advertisment or potential paging message (38)  for time
        Td termed as RDC-advert tracking time (TrackAd-T). This time is
        defined as the ratio of the cell's diameter Cd over the average
        movement of the MN per second (39)  SMN , times a cell boundary
        adjustment coefficient Cb, currently set to 1.5.  That is:


        <TrackAd-T formula is provided in postscript version>


        If no new RDC advertisment is received within time Td then
        the MN is considered switched off from the perspective of the
        network and thus the first case, described above, is followed.
        The above time allows the MN to remain disconnected for the
        entire transition of the MN from the CURRENT RDC to a new one
        without reseting the proactive mobility process.  Beyond that any
        connectivity of the MN with HA and CNs is considered as reset
        and, thus, must be re-established.


5.  Extended model optimizations

    In this section we elaborate on further optimizations that would
reduce the cycle of interactions required during the proactive setup
stage of the aforementioned roaming context.  However, the following
optimizations are beyond the scope of this document and as such any
further analysis and inclusion to the proposed protocol is the object of
future work.

----------------------------
38. for PCS systems

39. derived for some average speed metrics that are specific for
different kinds of MNs (vehicular)



Pagtzis, Kirstein             Expires 10 January 2002               [Page 49]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


5.1.  Coupling of MLD proxying and CoA allocation

    It should be noted that potential optimizations may be achieved if
the indirect join solicitation signal is responded with an indirect MLD
Query that contains a freshly generated and DAD-checked IPv6 soft CoA.
This is because MLD membership does not depend on the specifics of an
IP address; it only depends on the existence of a multicast listener
on-link at that interface.


    In this fashion, the CURRENT RDC combines signaling for I-MLD and the
soft CoA generation process.  Furthermore, the soft CoA generation is
purely distributed at the relevant constituencies (40) .


5.2.  Pessimistic and Optimistic Proactivity

    As currently specified in the proposed model, the intermediate
signaling for PCoA group membership interest follows a pessimistic
approach and declares indirectly receiver interest at all  immediate
neighbouring RDC link interfaces.  That indirectly implies that all
soft CoA could receive traffic at the PCoA since the particular RDC
link would be configured to forward packets destined to the particular
PCoA group of the MN. Such conservative approach is primarily due to
the possibility of harsh cell bouncing effects manifested during the
mobility pattern of the MN. We have argued that since there is no
insight in frequency of cell bouncing as the MN moves over some terrain
in a direction-constrained fashion (41)  the scheme pursues the sound
approach of including all RDC neighbours.

    It is possible, however, that the scheme could adopt a more
optimistic approach over RDC membership interest signalling if the model
has more information about the position of the MN (and subsequently its
direction) in relation to the position of neighbouring cells that are
controlled by different RDCs.  This should allow the CURRENT RDC to
declare PCoA membership interest only for those RDC neighbours that are
more probable to serve the MN in the immediate future.  The internals
of such optimistic approach are beyond the scope of this version of the
document.

----------------------------
40. i.e.  only the RDC over which the generated CoA is activatable
produces it

41. for instance road traffic



Pagtzis, Kirstein             Expires 10 January 2002               [Page 50]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



5.3.  Context Transfer over multicast channels


    Instead of pushing context state over ICMPv6 message between
neighbour RDCs or between the CURRENT RDC and the MN, each ontology of
context state may be channelised over a different well-known Proactive
context transfer group (PCT-G). This requires that all RDC neighbours of
the CURRENT RDC are listening on a different PCT group that is specified
as well-known for the relevant context ontology.  Management of each
group is done also indirectly as specified in previous sections of this
document.  To restrict, however, receipt of context state for some
ontology, over to the routing neighbourhood mapping to the mobility
neighbourhood surrounding the CURRENT RDC, the Hop Limit must be
restricted to 7, for a hexagonal coverage area shape model.  Assymetry
in the coverage range of adjacent access points may, however, introduce
extra factors that need be considered in the adjacency vector effected
in the routing neighbourhood of the CURRENT RDC. This is a topic for
further study, and as such any further analysis for introducing the
PCT-G alternative is out of the scope of this version of the document.


6.  Description of the messages

    In this sections the control signaling that effects the specified
proactive mobility scheme is also specified.  These are currently ICMPv6
messages.  All messages defined maintain a minimum set of 3 fields,
namely Type, Code and Checksum.  The Type and Code values differ for
each ICMP message while the Checksum field takes values as specified in
[6].


6.1.  Indirect RNV Update

    This message is used during incremental RNV acquisition through
reactive learning that is effected temporaly during the transition
process of an MN.


 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pref len pRDC |L|                 Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Sequence Number           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        Previous RDC LLA       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        Previous RDC                           |
|                   MNV-enabled IPv6 address                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 29: Indirect RNV Update



Pagtzis, Kirstein             Expires 10 January 2002               [Page 51]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


    Source Address :  The globaly routable IPv6 address of the MN.

    Destination Address :  The globally routable IPv6 address of the NEW
                           RDC currently transiting to the CURRENT state.

    Hop Limit:  1

    Type:  50 - It identifies indirect RNV information

    Code:  0 - The message type identified by Type is of class Update

    Reserved:  Must be initialized to zero.

    Sequence Number:  monotonically increasing 16-bit integer which must
                      be return on the respective Acknowledgement.

    L: flag to indicate that the LLA of the Previous RDC is also included
in the message



Pagtzis, Kirstein             Expires 10 January 2002               [Page 52]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


6.2.  Direct RNV Update

    Depending on the method employed for RNV acquisition for the purposes
of discovering the RNV that maps to the mobility neighbourhood of the
CURRENT RDC, a Direct RNV Update is sent accordingly from the CURRENT
RDC to the PREVIOUS one.

    If incremental RNV aquisition through temporal reactive learning is
effected then a D-RNV Update is sent by the CURRENT RDC to the PREVIOUS
on receipt of an I-RNV Update sent by a MN.

    If Complete RNV aquisition with fully proactive learning the D-RNV
Update is sent periodically from the CURRENT RDC to all of its upstream
interfaces, excluding the MNV-enabled interface.  In this case, the
destination address changes to the 'all-router' multicast address

    This message is sent only between RDC. Each Access Point is assumed
to have been configured with its Coverage Area tuple defined in previous
sections of this document.



 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Sequence Number         |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           CURRENT RDC LLA     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        CURRENT RDC                            |
|                   MNV-enabled IPv6 address                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDC-specific context/capability option(s)....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 30: Direct RNV Update


     -  Source Address:  It depends on the RNV acquisition scheme
        employed.  For:

         *  partial reactive learning (PRL): the global IPv6 address of
            the CURRENT RDC that receives an I-RNV Update message from
            some MN.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 53]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



         *  fully proactive learning (FPL): the link-local IPv6 address
            of the CURRENT RDC.

     -  Destination Address:  It depends on the RNV acquisition scheme
        employed.  For:


         *  PRL: the global IPv6 address of the PREVIOUS RDC as provided
            by the I-RNV Update message sent some MN

         *  FPL: the all-router multicast group.


     -  Hop Limit:  It depends on the RNV acquisition scheme employed.
        For:


         *  PRL: 1

         *  FPL: 255


     -  Type:  51 - identifies an Update message type

     -  Code:  identifies a bitmap that encodes one or more RDC-specific
        context capability options which identify the originating RDC in
        terms of itself.


         *  bit 0 (LSB) - identifies Roaming context information

         *  bit 1 - identifies compression context information

         *  bit 2 - identifies transport context information

         *  bit 3 - identifies security context information

         *  bit 4 - identifies session context information


     -  Sequence Number:  monotonically increasing 16-bit integer which
        must be return on the respective Acknowledgement

     -  RDC-specific context/capability option(s):  contains one or
        more RDC-specific context option that identify valid context
        capabilities on the originating RDC.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 54]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


6.3.  Roaming context option

    This option identifies information relevant to the resolution the
Routing neighbourhood vector of the originating RDC. It specifically
provides the Coverage Area tuple which identifies the Access Point of an
RDC.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Distance    |           Reserved            | Pref len RDC  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Latitude of sending RDC's AP lat                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Longitude of sending RDC's AP                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Radius of sending RDC's AP                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Height of sending RDC's AP                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 31: Roaming context option


     -  Distance:  7 - the number of hops that this signal is allowed
        to be forwarded before it gets discarded.  The value it
        takes represents the nominal number of neighbours.  For
        hexagonal-shaped cells this is assumed to be six.

     -  Pref len RDC: the prefix length of the CURRENT RDC IPv6 included
        in the message.

     -  AP lat:  The latitude of the Access Point of the RDC message
        originator

     -  AP Lon:  The Longitude of the Access Point of the RDC message
        originator

     -  AP Rad:  The radius (range) of the Access Point of the RDC
        message originator.

     -  AP Hei:  The height of the Access Point of the RDC message
        originator


Pagtzis, Kirstein             Expires 10 January 2002               [Page 55]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.4.  PCN Advertisment

    When the RNV neighbourhood of the CURRENT RDC has been established,
this message advertises RDC-specific roaming context through a unicast
message to each of the neighbour RDCs.  In this manner, each RDC becomes
aware implicitly of the mobility and routing neighbourhood of its
neighbours.

    The PCN-Advertisment includes one or more context ontology options.
A context ontology option may be populated with RDC-specific context for
the following context ontologies:

     -  roaming

     -  compression (header or other)

     -  transport (tcp, udp or other)

     -  security

     -  session (SIP, SAP, SDP or other)

     -  other


    The ontologies identify context capabilities that are enabled on
an individual RDC with respect to its neighbours.  This message is
exchanged only between RDCs.



  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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Sequence Number        |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context ontology/(ies) option ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 32: PCN Advertisment



     -  Source Address:  the global IPv6 address of the originating RDC.

     -  Destination Address:  the global IPv6 address of the RDC
        discovered as its neighbour RDC from its cached RNV vector.

     -  Hop Limit:  255



Pagtzis, Kirstein             Expires 10 January 2002               [Page 56]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



     -  Type:  70 - It identifies a Context Neighbour Discovery message

     -  Code:  identifies a bitmap that encodes one or more context
        state ontology options specific to the RDC. Thes context state
        ontology options identify not only the originating RDC but also
        its neighbours.


         *  bit 0 (LSB) - identifies the roaming context ontology

         *  bit 1 - identifies the compression context ontology

         *  bit 2 - identifies the transport context ontology

         *  bit 3 - identifies the security context ontology

         *  bit 4 - identifies the session context ontology, like SIP,
            SAP, etc.


     -  Sequence Number:  monotonically increasing 16-bit integer which
        must be return on the respective Acknowledgement.


Pagtzis, Kirstein             Expires 10 January 2002               [Page 57]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


6.4.1.  Roaming Context Ontology option

    This is the option included in the PCN advertisment when Roaming
context needs to be advertised between neighbouring RDC.



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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RDC Neigh No.| Pref Len RDC1 | Pref Len RDC2 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...                                           | Pref Len RDCn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                    Neighbour1 RDC IPv6 addr                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Neighbour2 RDC IPv6 addr                   |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    NeighbourN RDC IPv6 addr                   |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 33: Roaming Context Ontology option



     -  RDC Neigh No.:  number of RDC neighbours included

     -  Pref Len RDC1..n :  the prefix length for each RDC IPv6 address
        of the interface that belongs to the MNV of the RDC.

     -  Neighbour1 RDC IPv6 addr:  the globally routable IPv6 address of
        the RDC neighbour.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 58]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


6.5.  Aggregate PI-DAD Request

    As described previously the RDC may employ one two methods for
Duplicat Address detection:


     -  Agggregate Proactive Indirect DAD check

     -  Plain Proactive Indirect DAD check


    This is the message used for an aggregate proactive indirect DAD
check.  It initiates a request to the neighbour RDC for which the IPv6
addresses created by the CURRENT RDC are valid.  The RDC maintains a
record of the LLA of the MN for which it produces an IPv6 soft CoA.


     -  Source Address:  the global IPv6 address of the originating RDC

     -  Destination Address:  the global IPv6 address of the RDC
        neighbour for which the soft CoA generated by the originating
        RDC, are topologically correct.

     -  Hop Limit:  255

     -  Type:  75 - identifies aggregate PI-DAD check

     -  Code:  0 - identifies a request message for the above type

     -  SCoA1..n :  the soft CoA generated by the originating RDC for
        some MN, which is topologically correct at the receiving RDC
        neighbour.  The ordering of SCoAs in the request message is
        important for the purposes of the respective reply.

     -  MN1..n LLA: the link layer address of the Mobile Node for which
        the address has been generated.  The LLA of the MN is to be used
        for ND purposes (proactive neighbour caching)

     -  Aggregate PI-DAD Id :  an identifier to map the awaited aggregate
        PI-DAD reply to the correct set of SCoAs generated.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 59]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Aggregate PI-DAD Id        |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                            SCoA1                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            SCoA2                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                            SCoAn                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           MN1 LLA             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        MN2 LLA                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           MNn-1 LLA           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        MNn LLA                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 34: Aggregate PI-DAD Request


Pagtzis, Kirstein             Expires 10 January 2002               [Page 60]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.6.  Aggregate PI-DAD Reply


    This message is sent in response to an aggregate PI-DAD check
request.


 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Aggregate PI-DAD Id       |   Aggregate Address Bitmap    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 35: Aggregate PI-DAD Reply


     -  Source Address:  the global IPv6 address of the RDC neighbour
        that received the original aggregate PI-DAD request.

     -  Destination Address:  the global IPv6 address of the RDC that
        originated the aggregate PI-DAD request.

     -  Hop Limit:  255

     -  Type:  75 - identifies aggregate PI-DAD check

     -  Code:  1 - identifies a reply message for the above type

     -  Aggregate PI-DAD Id:  The identifier contained in the original
        aggregate PI-DAD request message.  This identifies will map

     -  Aggregate Address Bitmap:  an address bitmap that identifies
        the addresses for which the the DAD check was successfull.  It
        is assumed that the originator of the aggregate PI-DAD request
        maintains ordering information from the original DAD request to
        resolve this aggregate address bitmap.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 61]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.6.1.  Plain PI-DAD Request/Reply


    In the case of plain PI-DAD check the originating RDC simply provides
the RDC neighbour with the SCoA that must be checked for duplicates and
the LLA of the MN. The source and destination address follow the rules
provided for an aggregate PI-DAD check message.


    Thus the message for plain PI-DAD reduces to the following:


 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          PI-DAD Id            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        MN  LLA                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                            SCoA                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 36: Plain PI-DAD Request message


     -  Type:  76 - identifies PI-DAD check

     -  Code:  0 - identifies a request message

     -  PI-DAD Id:  identifier to be used in the reply for the PI-DAD
        check effected at the neighbour RDC for a particular node.

     -  MN LLA : the link layer address of the MN accomodated.

     -  SCoA: the soft Care-of Address generated for that MN.

     -  Type:  76 - identifies aggregate PI-DAD check

     -  Code:  1 - identifies a reply message for the above type

     -  PI-DAD Id:

        identifier to be used in the reply for the PI-DAD check request
        originated.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 62]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         PI-DAD Id             |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                 Figure 37: Plain PI-DAD Reply message


6.7.  Indirect SCoA-Create message

    This message is used in the event that address generation is
distributed to the RDC neighbours.  In this case, the originating RDC
does not generate the soft CoA itself, but distributes the task to the
RDC neighbours.


 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           MN LLA              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |       Reserved                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 38: SCoA-Create message



     -  Source Address:  the global IPv6 address of the CURRENT RDC that
        accomodates the MN.

     -  Destination Address:  the global IPv6 address of the RDC
        neighbour which is requested to create a soft CoA.

     -  Hop Limit:  255

     -  Type:  77 - identifies an indirect SCoA create message type

     -  Code:  0 - identifies a create request

     -  MN LLA: the link layer address of the MN for which a soft CoA is
        to be generated by the RDC neighbour.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 63]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.8.  SCoA-Ready message


    This message comprizes the response from the RDC neighbour on the
SCoA-Create request.  The response message simply includes the soft CoA
generated indirectly for the particular MN.


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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           SCoA                                |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 39: SCoA-Ready message



     -  Source Address:  the global IPv6 address of the RDC neighbour
        that generated the soft CoA.

     -  Destination Address:  the global IPv6 address of the RDC which
        originated the SCoA-Create request.

     -  Hop Limit:  255

     -  Type:  77 - identifies an indirect SCoA create message type

     -  Code:  1 - identifies a reply to an SCoA-Create request

     -  SCoA: the soft CoA generated by the neighbour RDC.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 64]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


6.9.  Proactive Roaming State Push

    When MN-specific roaming context has been generated by the CURRENT
RDC it must be pushed to the MN. This is achieved by means of a
Proactive Context State Push message which incorporates a Roaming State
option.  The Proactive Context State Push can take one or more different
context state options for the purposes of injecting different context
class state to the MN for the purposes of seamless mobility effected
over proactive context transfer.



 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Sequence Number           |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Context state options..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 40: Proactive Context State Push (PRS-PSH)



     -  Source Address:  the global IPv6 address of the CURRENT RDC that
        is accomodating the MN.

     -  Destination Address:  the current active primary IPv6 address of
        the MN as effected at the CURRENT RDC.

     -  Hop Limit:  255

     -  Type:  90 - It identifies a Proactive Context push message

     -  Code:  identifies a bitmap that encodes one or more context state
        options that are pushed towards the MN

         *  bit 0 (LSB) - identifies the roaming state class for the MN

         *  bit 1 - identifies the compression state class for the MN

         *  bit 2 - identifies the transport state class for the MN

         *  bit 3 - identifies the security state class for the MN

         *  bit 4 - identifies the session state class for the MN


     -  Sequence Number:  monotonically increasing 16-bit integer which
        must be return on the respective Acknowledgement.

     -  Context State push options:  contains one or more context state
        options that are specific to a single MN and are to be pushed to
        that MN.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 65]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


6.9.1.  Roaming State option

     -  RDC Neigh No.:  an 8-bit integer which identifies the number of
        RDC neighbours included.

     -  SCoA tuple identifier:  a 32-bit (or 16-bit) number that uniquely
        identifies the soft CoA tuple that is being pushed to the MN.

     -  M : PCoA is included

     -  I : incomplete proactive roaming state provided

     -  J : Explicit Join Solicitation flag

     -  R : SCoAT-Update flag

     -  E : flag that signifies that eh SCoA 'exclude' address bitmap is
        present

     -  Pref Len RDC1..n:  one or more 8-bit number that identifies the
        prefix length of the RDC neighbour IPv6 address that is included
        in the Roaming state option.  The number of prefix-length numbers
        present depends on the number of RDC neighbours stated in the
        push message option.

     -  Neighbour1..n RDC IPv6 addr:  one or more global IPv6 address of
        the RDC neighbours of the CURRENT RDC.

     -  SCoA1..n:  one or more generated soft CoAs that identify the
        mobility and routing neighbourhood of the CURRENT RDC.

     -  PCoA: The Proactive CoA multicast group that is mapped to the
        soft CoA tuple by the CURRENT RDC.

     -  SCoA 'exclude' address bitmap:  an address bitmap that identifies
        the soft CoA that must be excluded as redundant from the active
        soft CoA tuple as maintained at the MN. The size of this address
        bitmap is expected to be 8-bits.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 66]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RDC Neigh No.  |M|I|J|R|E|            Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       SCoA tuple identifier                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pref Len RDC1 | Pref Len RDC2 | ...           | Pref Len RDCn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Neighbour1 RDC IPv6 addr                   |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Neighbour2 RDC IPv6 addr                   |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    NeighbourN RDC IPv6 addr                   |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            SCoA1                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            SCoA2                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            SCoAn                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            PCoA                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SCoA 'exclude' address bitmap                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 41: Roaming State Ontology Push option


Pagtzis, Kirstein             Expires 10 January 2002               [Page 67]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.10.  Proactive Roaming State Reply


 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RDC Neigh No.  |        Sequence Number        |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 42: Proactive Roaming State Reply


     -  Source Address:  the global IPv6 address of the MN that received
        the PRS-PSH message.

     -  Destination Address:  the global IPv6 address of the CURRENT RDC
        that effected the PRS-PSH message towards the MN.

     -  Hop Limit:  255

     -  Type:  91 - It identifies a Proactive Context reply message

     -  Code:  identifies a bitmap that encodes one or more context state
        options that are pushed towards the MN


         *  bit 0 (LSB) - identifies the roaming state received by the MN

         *  bit 1 - identifies the compression state received the MN

         *  bit 2 - identifies the transport state received by the MN

         *  bit 3 - identifies the security state received by the MN

         *  bit 4 - identifies the session state received by the MN


     -  RDC Neigh No.:  an 8-bit integer which identifies the number of
        RDC neighbours received by the MN.

     -  Sequence Number:  a 16-bit integer which was originaly sent by
        the CURRENT through the PRS-PSH message.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 68]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.11.  Indirect MLD Messaging


6.11.1.  Implicit Join Solicitation

This message is sent by the CURRENT RDC towards the neighbour RDC.

 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     PCoA multicast address                    |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 43: Implicit Join Solicitation


     -  Source Address:  the global IPv6 address of the CURRENT RDC where
        the MN is accomodated.

     -  Destination Address:  the global IPv6 address of the RDC
        neihgbour which is required to maintain group membership for the
        provided PCoA group.

     -  Hop Limit:  255

     -  Type:  101 - It identifies a implicit join solicitation message

     -  Code:  0

     -  PCoA: A Proactive CoA multicast group that is has been mapped to
        some soft CoA tuple by the CURRENT RDC for some MN.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 69]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.11.2.  Indirect MLD Membership Query

This message is initiated by the neighbour RDC towards the CURRENT one.

 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Max Response Delay        |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     PCoA multicast address                    |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Figure 44: Indirect MLD Membership Query


     -  Source Address:  the global IPv6 address of the RDC neighbour
        that originaly received an implicit join solicitation message.

     -  Destination Address:  the global IPv6 address of the implicit
        join solicitation originator.  This is expected to be the source
        address of the implicit join solicitation.

     -  Hop Limit:  255

     -  Type:  102 - It identifies a implicit MLD Query message

     -  Code:  0

     -  Max Response Delay:  The maximum time that the receiving RDC
        can spend before it provides the sender RDC neighbour with an
        Indirect MLD report.

     -  PCoA: The Proactive CoA multicast group for which the neighbour
        RDC is required to maintain membership, pending receipt of an
        indirect MLD Report message.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 70]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.11.3.  Indirect MLD Report/Done

An indirect MLD Report or Done message is sent by the CURRENT RDC towards
a single RDC neighbour.

  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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     PCoA multicast address                    |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 45: Indirect MLD Report/Done message



     -  Source Address:  the global IPv6 address of the RDC that
        originaly received the I-MLD Query message.  This is the CURRENT
        RDC which accomdates currently the MN.

     -  Destination Address:  the global IPv6 address of the RDC
        neighbour that sent an I-MLD Query.

     -  Hop Limit:  255

     -  Router Alert value:  13

     -  Type:  103 - It identifies a implicit MLD Report/Done message

     -  Code:

         *  0 - identifies a report message

         *  1 - identifies a done message


     -  PCoA: The Proactive CoA multicast group for which the neighbour
        RDC is required to maintain membership, as received in the I-MLD
        Query message.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 71]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.12.  PCoA-Enable/Disable message



 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Reserved                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       SCoA flag bitmap        |     SCoA tuple identifier     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      PCoA Start lifetime      |      PCoA stop lifetime       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 46: PCoA-Enable/Disable message


     -  Source Address:  the global IPv6 address of the MN that received
        the original PRS-PSH message.

     -  Destination Address:  the global IPv6 address of the RDC that
        effected the PRS-PSH message towards that MN. If the message Code
        is:

         *  0:  this RDC destination is the CURRENT one.

         *  1:  this RDC destination has transitted to the PREVIOUS state
            and thus is the previous one.

     -  Type:  110 - It identifies a PCoA enable/disable message

     -  Code:

         *  0 - identifies an enable request

         *  1 - identifies a disable request.

     -  SCoA flag bitmap:  The flag bitmap, depending whether the message
        identifies an enable or disable request, provides the for an
        enable request the highest priority canditate(s) soft CoA(s),
        while for a disable request provides the active primary CoA of
        the MN at the new CURRENT RDC.

     -  SCoA tuple identifier:  This is a 16-bit integer which tracks at
        the CURRENT/PREVIOUS RDC the SCoA tuple generate for a particular
        MN. This identifier is only unique per RDC and depends on the
        PRS-PSH message.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 72]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



     -  PCoA Start lifetime:  This is a 16-bit time value on expiry of
        which the CURRENT/ PREVIOUS RDC must effect the enable or disable
        request for the PCoA group forwarding activation.

     -  For message code:

         *  0:  the CURRENT RDC must enable forwarding of traffic towards
            the MN over the PCoA group.

         *  1:  the PREVIOUS RDC must disable forwarding of traffic
            towards the MN over the PCoA group.


     -  PCoA stop lifetime:  This is a 16-bit time value which identifies
        the duration of an enable or disable request.  For message code:

         *  0:  the CURRENT RDC must set a duration for which the enabled
            forwarding of traffic towards the MN over the PCoA group will
            be valid.

         *  1:  the PREVIOUS RDC must disable forwarding of traffic
            towards the MN over the PCoA group for that duration.


     -  Valid value for both PCoA start and stop lifetime are also the
        valies:

         *  -1:  is the only valid negative time value and represents
            infinity

         *  0:  effecting immediate enable/disable over the PCoA group.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 73]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



6.13.  Indirect Neighbour advertisment


 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|I|L|        Reserved         |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           MN  LLA             |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            SCoA                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 47: Indirect Neighbour advertisment



     -  Source Address:  the global IPv6 address of the PREVIOUS RDC.

     -  Destination Address:  the global IPv6 address of some RDC
        neighbour of the PREVIOUS RDC.

     -  Type:  120 - It identifies a Indirect Neighbour advertisment

     -  Code:  0

     -  MN LLA: the link layer address for which a neighbour cache must
        be set proactively.  It requires the presence of the S and L
        flag.

     -  SCoA: the global/link-local IPv6 address for which a neighbour
        cache entry must either be created or invalidated.  It requires
        either the existence of the S or I flag, but not both.

     -  S: set a neighbour cache entry proactively

     -  I: invalidate the neighbour cache entry

     -  L: LLA of MN. The flag must be set if configuring a neighbour
        cache entry proactively



Pagtzis, Kirstein             Expires 10 January 2002               [Page 74]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


References


     [1] M. Parthasarathy A. E. Yegin and C. Williams.  Mobile ipv6
         neighborhood routing for fast handoff.  Internet Draft, Internet
         Engineering Task Force, October 2000.


     [2] C. Diot B. Levine, J. Crowcroft, J.J Garcia-Lune-Aceves, and
         J. Kurose.  Consideration of Receiver Interest for ip Multicast
         Delivery.  In Proceeding of INFOCOM 2000, July 2000.


     [3] A. Ballardie.  Core Based Trees (CBT version 2) Multicast
         Routing.  rfc 2189, Internet Engineering Task Force, September
         1997.


     [4] R. Boivie and N. Feldman.  Small Group Multicast.  Internet
         Draft, February 2001.


     [5] R. Coltun, D. Ferguson, and J. Moy.  OSPF for IPv6.  rfc 2740,
         Internet Engineering Task Force, December 1999.


     [6] A. Conta and S. Deering.  Internet Control Message Protocol
         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification.  rfc 2463, Internet Engineering Task Force,
         December 1998.


     [7] M. Crawford.  Transmission of IPv6 Packets over Ethernet
         Networks.  rfc 2464, Internet Engineering Task Force, December
         1998.


     [8] S. Deering, W. Fenner, and B. Haberman.  Multicast Listener
         Discovery (MLD) for IPv6.  rfc 2710, Internet Engineering Task
         Force, October 1999.


     [9] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
         Specification.  rfc 2460, Internet Engineering Task Force,
         December 1998.


    [10] S.E. Deering.  Host extensions for IP multicasting.  rfc 1112,
         Internet Engineering Task Force, August 1989.


    [11] Steve Deering, Bill Fenner, Brad Cain, A. Thyagarajan, and
         I Kouvelas.  Internet Group Management Protocol, Version 3.
         Internet Draft, March 2001.


    [12] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
         M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei.
         Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
         Specification.  rfc 2117, Internet Engineering Task Force, June
         1997.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 75]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001


    [13] Yutaka Ezaki and Yuji Imai.  Mobile IPv6 handoff by Explicit
         Multicast.  Internet Draft, May 2001.


    [14] W. Fenner.  Internet Group Management Protocol, Version 2.  rfc
         2236, Internet Engineering Task Force, November 1997.


    [15] William Fenner.  IGMP-based Multicast Forwarding ('IGMP
         Proxying').  Internet Draft, April 2001.


    [16] S. Floyd and V. Jacobson.  The synchronization of periodic
         routing messages.  In IEEE/ACM Transactions on Networking, April
         1994.


    [17] C. Perkins G. Tsirtsis, A. Yegin, G. Dommety, and K. El-Malki.
         Fast handovers for mobile ipv6 (work in progress).  Internet
         Draft, Internet Engineering Task Force, October 2000.


    [18] S. Hanna, B. Patel, and M. Shah.  Multicast Address Dynamic
         Client Allocation Protocol (M ADCAP).  rfc 2730, Internet
         Engineering Task Force, December 1999.


    [19] A. Helmy.  A multicast-based protocol for ip mobility
         support.  In ACM 2nd International Workshop on Networked Group
         Communication (NGC2000), November 2000.


    [20] R. Hinden and S. Deering.  IP Version 6 Addressing Architecture.
         rfc 2373, Internet Engineering Task Force, July 1998.


    [21] D. Johnson and C. Perkins.  Mobility support in IPv6 (work in
         progress).  Internet Draft, Internet Engineering Task Force,
         November 1998.


    [22] J. Kempf and P. Calhoun.  Foreign agent assisted hand-off (work
         in progress).  Internet Draft, Internet Engineering Task Force,
         January 2000.


    [23] R. Koodli and C. Perkins.  Fast handovers in mobile IPv6 (work
         in progress).  Internet Draft, Internet Engineering Task Force,
         October 2000.


    [24] R. Koodli and C. Perkins.  A framework for smooth handovers
         with mobile IPv6 (work in progress).  Internet Draft, Internet
         Engineering Task Force, November 2000.


    [25] Jiwoong Lee.  SGM support in Mobile IP.  Internet Draft, October
         2000.


    [26] Jiwoong Lee.  Explicit Multicast Extension (Xcast+) Supporting
         Receiver Initiated Join.  Internet Draft, February 2001.


Pagtzis, Kirstein             Expires 10 January 2002               [Page 76]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



    [27] K Leung, G Dommety, Madhavi Subbarao, and Raj Patil.  Local
         Mobility Agents in IPv6.  Internet Draft, October 2000.


    [28] J. Malinen and C. Perkins.  Mobile IPv6 regional registrations
         (work in progress).  Internet Draft, Internet Engineering Task
         Force, July 2000.


    [29] G. Malkin and R. Minnear.  RIPng for IPv6.  rfc 2080, Internet
         Engineering Task Force, January 1997.


    [30] J. Mysore and V. Bharghavan.  A new multicasting-based
         architecture for internet host mobility.  In Proceedings of ACM
         MobiCom 97, September 1997.


    [31] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
         IP Version 6 (IPv6).  rfc 2461, Internet Engineering Task Force,
         December 1998.


    [32] S. Seshan, H. Balakrishnan, and R. Katz.  Handoffs in cellular
         wireless networks:  The daedalus implementation and experience,
         1996.


    [33] S. Thomson and T. Narten.  IPv6 Stateless Address
         Autoconfiguration.  rfc 2462, Internet Engineering Task
         Force, December 1998.


    [34] Kazuaki Tsuchiya, Hidemitsu Higuchi, Sunao Sawada, and Shinji
         Nozaki.  An IPv6/IPv4 Multicast Translator based on IGMP/MLD
         Proxying (mtp).  Internet Draft, May 2001.


    [35] D. Waitzman, C. Partridge, and S.E. Deering.  Distance Vector
         Multicast Routing Protocol.  rfc 1075, Internet Engineering Task
         Force, November 1988.


    [36] Imai Yuji.  Multiple Destination option on IPv6(MDO6).  Internet
         Draft, September 2000.



Pagtzis, Kirstein             Expires 10 January 2002               [Page 77]


Internet Draft           Proactive Mobility in MIPv6             10 July 2001



7.  Acknowledgements


    We would like to thank Hannu Flinck, Jari Malinen, Vijay Devarapali
and Charlie Perkins (Nokia Research), for their valuable discussions
on problems encountered during the design of this draft specification.
This work has been sponsored by Nokia Research, NRC Mountain View, USA.


    We would also like to thank Bob Quinn (StartDust), Jon Crowcroft
(UCL) and Bill Fenner (ATT) for their comments over issues related to
multicast forwarding.


8.  Addresses


    The working group can be contacted via the current chairs:



       Basavaraj Patil                        Phil Roberts
       Nokia Corporation                      Motorola
       6000 Connection Drive                  1501 West Shure Drive
       M/S M8-540
       Irving, Texas 75039                    Arlington Heights, IL 60004
       USA                                    USA
       Phone: +1 972-894-6709                 Phone: +1 847-632-3148
       Fax :  +1 972-894-5349
       EMail: Basavaraj.Patil@nokia.com       EMail: QA3445@email.mot.com



    Questions about this memo can also be directed to the authors:



       Theo Pagtzis                         Peter Kirstein
       Dept. of Computer Science            Dept. of Computer Science
       University College London            University College London
       Gower Street                         Gower Street
       London WC1E 6BT                      London WC1E 6BT
       United Kingdom                       United Kingdom
       Phone: +44 (0)20 7679 3704           Phone: +44 (0)20 7679 7286
       EMail: t.pagtzis@cs.ucl.ac.uk        EMail: p.kirstein@cs.ucl.ac.uk
       Fax:    +44 (0)20 7387 1397          Fax:    +44 (0)20 7387 1397



Pagtzis, Kirstein             Expires 10 January 2002               [Page 78]