Subject: [Mipshop] Re: AD review of mipshop-3gfh

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Jan 2008 19:05:53 +0200

Any news on a new revision?

Jari

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 22 Jan 2008 23:39:04 +0900

Hi Jari,

First of all, thanks for the detailed review and very sorry for this 
late response. I'm asking for the reviewing by 3GPP experts. Please find 
the answers and revised texts inline:

Jari Arkko wrote:
> I have done my AD review on this document as well. It still
> needs work. Here are my comments:
 >
> 1. References should be updated to point to RFC 4068bis.

->Removed RFC4096 and corrected the description of the UNA.

> 2. The spec needs to be clearer about when FMIP procedures are
>    needed upon link change, and when not. Is a link change in 3G
>    CDMA networks always a subnet change, too? Text several places
>    in the document appears to assume this is so.

-> Changed the text in the first paragraph on p.7 as follows:

[Original text:]
If the serving access network finds that the sector associated with the 
highest pilot strength belongs to a different AR, it attempts to close 
the connection with the MN. The MN then attempts to get a new traffic 
channel assigned in the new access network, which is followed by 
establishing a new connection with the new AR. The MN can continually 
search for pilots without disrupting the data communication and a timely 
handover is assisted by the network. If the air interface information 
can be used as a trigger for the handover between access routers, fast 
and smooth handover of Mobile IPv6 can be realized in 3G CDMA networks.

[Proposed text:]
As far as the sector to which the MN is going to move belongs to the 
same access network, the mobility within that access network is handled 
by the access specific interfaces [A.S0007-A_v2.0] and the link-layer 
connection between the MN and AR can be maintained without a 
reestablishment. The MN can continually search for pilots without 
disrupting the data communication and a timely handover is assisted by 
the network. If, however, the serving access network finds that the 
sector associated with the highest pilot strength belongs to a different 
AR, it attempts to close the connection with the MN. The MN then 
attempts to get a new traffic channel assigned in the new access 
network, which is followed by establishing a new connection with the new 
AR. This could cause a noticeable communication disruption and lead to a 
serious degradation of the user experience. In order to minimize the 
service degradation during the handover between ARs, an IP-level fast 
handover approach as defined in RFC4068 needs to be involved. If the air 
interface information can be used as a trigger for the handover between 
access routers, fast and smooth handover of Mobile IPv6 can be realized 
in 3G CDMA networks.

> 3. The spec needs to document how it deals with the issues
>    from RFC 4907 Section 2.

-> This section suggests 11 architectural principles on the link 
indication. This I-D relies on the 3G CDMA network regarding the link 
indication, which is precisely specified by 3GPP2. Therefore, principles 
(1) to (5), (7), (8) and (11) are considered by those specs. Principle 
(6) mentions the effectiveness of the optimization. This I-D bases its 
effectiveness on RFC4068bis. Therefore this principle is dealt by this 
RFC. Principle (9) mentions inconsistencies between link and routing 
layer metrics. This spec does not change the routing metrics and 
multi-homing is not considered. Finally, principle (10) mentions 
overhead reduction scheme and interoperability. This I-D does not deal 
with overhead reduction and therefore this principle does not apply.

[Proposed text at the end of Section 5:]
RFC4902 Section 2 suggests architectural principles on the link 
indication and the effectiveness of the optimization. The link 
indication of this document relies on 3G CDMA networks and the 
effectiveness of the optimization is attributed to RFC4068bis. The above 
principles are thus considered by the related specs that this document 
is based on.

> 4. A review from 3GPP2 or experts in 3GPP2 networks is required.

-> Reviews are on going by 3GPP2 experts.

> 5. I do not understand how it is possible to use the interface
>    ID (you mean the IP layer interface ID, right?) in the
>    MN-LLA option, as suggested in Section 5.1.

-> 3GPP2 assumes a unique interface ID to configure its IPv6 address. 
Since an interface ID is often constructed by a link-layer address by 
encapsulating it within the EUI-64 value, the link-layer address could 
be inversely configured by the interface ID by assigning the interface 
ID as such. Otherwise, more oft-used IDs such as the MN ID (e.g. IMSI) 
can be used. If this is the case, the Handover Assist Information option 
should be used since the length of this value is not necessarily 
multiples of 8 octets.

[Original text:]
As for the MN-LLA option, the only available identifier is the interface 
ID, so it SHOULD be used for the MN-LLA.

[Proposed text on p.10:]
As for the MN-LLA option, a possible identifier is the interface ID, 
which can be used to construct the LLA of the MN. Otherwise, more 
oft-used 3G specific IDs such as the MN ID (e.g. IMSI) can be used. If 
this is the case, however, the Handover Assist Information option SHOULD 
be used since the length of this value is not necessarily multiples of 8 
octets.

> 6. I do not understand the instructions in Section 5.1
>    regarding UNA. It appears that this draft is disobeying
>    a MUST from RFC 4068bis. If UNA is not applicable in all
>    cases, is there something that needs to be fixed RFC 4068bis?

-> The draft may not come to a complete transition from RFC4068 to 
RFC4068bis. Further check will be done.

> 7. I do not understand what "SHOULD be confirmed that NAR
>    supports this [IPCP] option" means. Confirm how? The delay
>    that you try to avoid is part of normal PPP processing, so
>    are you expecting something to be done configuration-wise?

->This confirmation is not meant to be supported by the protocol, but 
the operator should confirm that this mode is supported.

[Original text:]
it SHOULD be confirmed that the NAR supports this option,

[Proposed text:]
it SHOULD be administrated that the NAR supports this option,

> 8. In the end of Section 5.1, the advantage of being able to
>    avoid PPP authentication, RA, etc is brought up. Some of
>    these optimizations are potentially very useful, but I would
>    argue that it is not the place of FMIP-over-Foo to define
>    everything that can be optimized in Foo. It should only
>    define how to run FMIP over Foo.

-> The related sentence was removed.

[Original text:]
Therefore, the procedures (g-4) to (g-7) can be skipped from the 
standard MIPv6 operation in Figure 3. Also, if the security policy 
permits and the PPP state can be transferred from the PAR to the NAR, 
the PPP link setup (g-1) and the authentication in (g-2) may be omitted.

[Proposed text:]
Therefore, the procedures (g-4) to (g-7) can be skipped from the 
standard MIPv6 operation in Figure 3.

> 9. The spec needs to talk about the case where L2 indications
>    that Section 5.2 relies on are unreliable or turn out to be
>    wrong. E.g., the connection was closed but came back to the
>    same router again.

-> It may be more appropriate to specify how to handle this type of 
error case in RFC4068bis. In 3G CDMA network, the handover is performed 
when the link in the target network is sufficiently stable; however, if 
the connection is closed and the MN comes back to the same router, the 
attachment procedure will be performed in the previous network. It would 
be desirable to be able to deliver the packets buffered at the PAR to 
the MN, but this spec does not mandate it.

[Proposed text at the end of Section 5.2]
If the target link is not available after the handover (step (d)) and 
the MN comes back to the PAR after the connection was closed, the 
attachment procedure is performed on the previous link. The packet 
buffered at the PAR may be delivered to the MN after the connection is 
re-established.

> 10. It is unclear how Steps a-b differ from each other in Sections
>     5.1 and 5.2. Step b in the latter says that prefix information
>     is not sent. How do the devices know whether reactive or predictive
>     mode is being employed? Section 5.1 Step a talks about data that
>     the MN needs to attach to the proxy solicitation. Is such data
>     required, allowed, or disallowed in Section 5.2 step a?

-> Whether the network supports the predictive or reactive mode is 
administrated by the network operator. The MN may be informed about the 
capability of the network by other means (e.g. AAA server). As one 
approach, if the MN does not obtain the prefix information for the NCoA 
by the PrRtAdv, the MN can infer that the network does not support the 
predictive mode and behaves as the reactive mode. If this approach is 
worth describing, I will add it in the document.

> 11. Flows in both Section 5.1 and 5.2 appear to missing the
>     security details outlined in mipshop-handover-key.

-> The following text is added in Section 7 (Security Considerations):

[Original text:]
The security considerations for Mobile IPv6 fast handover are described 
in [3]. When a 3G network is considered, the PAR and the NAR have a 
trusting relationship and the links between them and those between the 
ARs and the MN are usually secured.

[Proposed text:]
The security considerations for Mobile IPv6 fast handover are described 
in [3]. When a 3G network is considered, the PAR and the NAR have a 
trusting relationship and the links between them and those between the 
ARs and the MN are usually secured ; therefore additional security 
mechanisms to protect FMIP signaling are not required. However, 
depending on the operator’s requirement, SEND [xxx] and the shared 
handover key defined in [yyy] can be used.

> 12. Section 5.3, network controlled handover. This is a possible use
>     of the router-to-router messages of FMIP. But would such use follow
>     all the requirements in the FMIP spec? I'm not sure the spec has
>     all the details, how would the routers know about the interface IDs
>     in use by the mobile node, for instance. Also, my read of the charter
>     does not include development of network-based version of FMIP.

-> The 3GPP2 document that this draft is intended to apply to included 
this mode of operation, but since this work is not included in the 
charter, Section 5.3 is removed.

> 13. Section 6.1, handover assist information option. I have
>     interoperability concerns about this, and in general we should
>     not define completely open options. Please replace by a more
>     specific option that can carry the information needed for 3GPP2
>     network identification, not a container that can carry anything
>     by anyone.

-> Code-options to identify ANID, MNID and Sector ID are defined in 
Section 6.1. Also these parameters are added in the Terminology section 
(Section 3).

> 14. Section 6.2, the B option. If such instruction for buffering
>     is needed, why isn't it a part of the base protocol?

Section 4 of RFC4068bis mentions buffering at the PAR. While the base 
protocol does not prohibit this implementation, the PAR is required to 
forward packets to the PCOA at the same time. Since this buffer and 
forward approach is not a common approach in 3GPP2, buffering only 
approach is taken in this document. In this case, an explicit indication 
is needed for the MN to be able to received packet without fail.

> 15. Section 7, s/trusting/trust/. Is draft-ietf-mipshop-handover-key
>     required or not?

-> The above typo is fixed and a new text described in (11) is added in 
Section 7.

> I am expecting a revised draft and answers to the questions above.

Attached please find the revised draft. There may be more revisions 
according to further reviews.

Best regards,
-- 
Hidetoshi

> Jari

Network Working Group                                          H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Informational                                G. Dommety
Expires: July 25, 2008                               Cisco Systems, Inc.
                                                        January 22, 2008

            Mobile IPv6 Fast Handovers for 3G CDMA Networks
                     draft-ietf-mipshop-3gfh-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Yokota & Dommety          Expires July 25, 2008                 [Page 1]

Internet-Draft            3G CDMA Fast Handover             January 2008

Abstract

   Mobile IPv6 is designed to maintain its connectivity while moving
   from one network to another.  It is adopted in 3G CDMA networks as a
   way to maintain connectivity when the mobile node moves between
   access routers.  However, this handover procedure requires not only
   movement detection by the MN, but also the acquisition of a new
   care-of address and Mobile IPv6 registration with the new care-of
   address before the traffic can be sent or received in the target
   network.  During this period, packets destined for the mobile node
   may be lost, which may not be acceptable for real-time application
   such as Voice over IP (VoIP) or video telephony.  This document
   specifies fast handover methods in the 3G CDMA networks in order to
   reduce latency and packet loss during handover.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Network reference model for Mobile IPv6 over 3G CDMA
       networks . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Fast handover procedures . . . . . . . . . . . . . . . . . . .  8
     5.1.  Predictive fast handover . . . . . . . . . . . . . . . . .  8
     5.2.  Reactive fast handover . . . . . . . . . . . . . . . . . . 13
   6.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 17
     6.1.  Handover Assist Information Option . . . . . . . . . . . . 17
     6.2.  New flag extension to FBU message  . . . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 21
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     11.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26

Yokota & Dommety          Expires July 25, 2008                 [Page 2]

Internet-Draft            3G CDMA Fast Handover             January 2008

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

Yokota & Dommety          Expires July 25, 2008                 [Page 3]

Internet-Draft            3G CDMA Fast Handover             January 2008

2.  Introduction

   Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IP
   connectivity while the MN moves around in the IPv6 network.  It is
   adopted in 3G CDMA networks for handling host based mobility
   management [8].  During handover, however, the mobile node (MN) needs
   to switch the radio link, to obtain a new Care-of Address (CoA) and
   to re-register with the home agent (HA), which may cause a
   communication disruption.  This is not desirable for real-time
   applications such as VoIP and video telephony.  To reduce this
   disruption time or latency, a fast handover protocol for Mobile IPv6
   [3] is proposed.  RFC4260 [4] further describes how this Mobile IPv6
   Fast Handover could be implemented on link layers conforming to the
   IEEE802.11 suite of specifications.  However, 3G CDMA and IEEE802.11
   networks are substantially different in the radio access, the
   representations of the network nodes or parameters and the network
   attachment procedures; for example, the beacon scanning or NAR
   discovery based on [AP-ID, AR-info] tuples specified in RFC4260 can
   not be directly applied to 3G CDMA networks.  This document therefore
   specifies how Mobile IPv6 fast handovers can be applied in the 3G
   CDMA networks.  In addition to the predictive and reactive fast
   handovers defined in RFC4068, if the lower layer can provide
   necessary information for handover, network-controlled fast handover
   can also be applied and hence defined in this document.

Yokota & Dommety          Expires July 25, 2008                 [Page 4]

Internet-Draft            3G CDMA Fast Handover             January 2008

3.  Terminology

   This document refers to [3] for Mobile IPv6 fast handover
   terminology.  Terms that first appear in this document are defined
   below:

   Forward Pilot Channel:
        A portion of the Forward Channel that carries the pilot.  The
        Forward Channel is a portion of the physical layer channels
        transmitted from the 3G CDMA access network to the MN.  Further,
        several sets of pilots (e.g. the active set or neighbor set) are
        defined to determine when and where to handover.

   Sector:
        A typical cell divides its coverage area into several sectors.
        In 3G CDMA systems, each sector uses a different PN (Pseudo
        Noise) code offset and associated with SectorID.

   Home Link Prefix (HLP):
        The prefix address assigned to the home link where the MN should
        send the binding update message.  This is also called as Home
        Network Prefix (HNP) and one of the bootstrap parameters for the
        MN.

   Packet Data Serving Node (PDSN):
        An entity that routes MN originated or MN terminated packet data
        traffic.  A PDSN establishes, maintains and terminates link-
        layer sessions to MNs.  A PDSN is the access router in the
        visited access provider network.

   Access Network Identifier (ANID)
        An identifier that is used by the PDSN to determine whether the
        MN is being handed off from the access network that was not
        previously using this PDSN.  Anytime the MN crosses into a new
        region, which is defined by the ANID, it must re-register with
        that Access Network.  The ANID is further composed of the System
        ID (SID), Network ID (NID) and Packet Zone ID (PZID) and these
        values are administrated by the operator.

   Mobile Identity (MN ID)
        An Identify used by the access network to provide the Mobile
        Node Identification.  The value (e.g.  IMSI) is unique within
        the operator's network.

Yokota & Dommety          Expires July 25, 2008                 [Page 5]

Internet-Draft            3G CDMA Fast Handover             January 2008

4.  Network reference model for Mobile IPv6 over 3G CDMA networks

   Figure 1 shows a simplified reference model of the Mobile IP enabled
   3G CDMA networks.  The home agent (HA) and AAA server (AAA) of the
   mobile node (MN) reside in the home IP network and the MN roams
   within or between the access provider network(s).  Usually, the home
   IP network is not populated by the MNs, which are instead connected
   only to the access provider networks.  Prior to the Mobile IPv6
   registration, the MN establishes a 3G CDMA access technology specific
   link-layer connection with the access router (AR).  When the MN moves
   from one AR to another, the link-layer connection is re-established
   and a Mobile IPv6 handover is performed.  Those ARs reside in either
   the same or different access provider network(s).  The figure shows
   the situation, where the MN moves from the previous access router
   (PAR) to the new access router (NAR) via the radio access network
   (RAN).

                                      Home IP Network
                                 +........................+
                                 . +--------+  +--------+ .
                                 . |   HA   |--|  AAA   | .
                                 . +--------+  +--------+ .
                                 +../......\..............+
                                   /        \
                             Access Provider Network(s)
                      +.............+      +.............+
                      . +---------+ .      . +---------+ .
                      . |   PAR   | .      . |   NAR   | .
                      . +---------+ .      . +---------+ .
                      .      |:     .      .     :|      .
                      .      |:L2link      L2link:|      .
                      .      |:     .      .     :|      .
                      . +----+:---+ .      . +---:+----+ .
                      . |   RAN   | .      . |   RAN   | .
                      . +----+:---+ .      . +---:+----+ .
                      .      |:     .      .     :|      .
                      .    +----+   .      .   +----+    .
                      .    | MN |  --------->  | MN |    .
                      .    +----+   .      .   +----+    .
                      +.............+      +.............+

                  Figure 1: Reference Model for Mobile IP

   In 3G CDMA networks, pilot channels transmitted by base stations
   allow the MN to obtain a rapid and accurate C/I (carrier to
   interference) estimate.  This estimate is based on measuring the
   strength of the Forward Pilot Channel or the pilot, which is
   associated with a sector of a base station (BS).  The MN searches for

Yokota & Dommety          Expires July 25, 2008                 [Page 6]

Internet-Draft            3G CDMA Fast Handover             January 2008

   the pilots and maintains those with sufficient signal strength in the
   pilot sets.  The MN sends measurement results, which include the
   offsets of the PN code in use and the C/Is in the pilot sets, to
   provide the radio access network (RAN) with the estimate of sectors
   in its neighborhood.  There are several triggers for the MN to send
   those estimates, e.g. when the strength of a pilot in the pilot sets
   is higher enough than that of the current pilot, the MN sends the
   estimates to the access network.  As far as the sector to which the
   MN is going to move belongs to the same access network, the mobility
   within that access network is handled by the access specific
   interfaces [6] and the link-layer connection between the MN and AR
   can be maintained without a reestablishment.  The MN can continually
   search for pilots without disrupting the data communication and a
   timely handover is assisted by the network.  If, however, the serving
   access network finds that the sector associated with the highest
   pilot strength belongs to a different AR, it attempts to close the
   connection with the MN.  The MN then attempts to get a new traffic
   channel assigned in the new access network, which is followed by
   establishing a new connection with the new AR.  This could cause a
   noticeable communication disruption and lead to a serious degradation
   of the user experience.  In order to minimize the service degradation
   during the handover between ARs, an IP-level fast handover approach
   as defined in RFC4068 needs to be involved.  If the air interface
   information can be used as a trigger for the handover between access
   routers, fast and smooth handover of Mobile IPv6 can be realized in
   3G CDMA networks.  The MN can continually search for pilots without
   disrupting the data communication and a timely handover is assisted
   by the network.  If the air interface information can be used as a
   trigger for the handover between access routers, fast and smooth
   handover of Mobile IPv6 can be realized in 3G CDMA networks.

   To assist the handover of the MN to the new AR, various types of
   information can be considered: the pilot sets, which include the
   candidates of the target sectors or BSs, the cell information where
   the MN resides, the serving nodes in the radio access network and the
   location of the MN if available.  To identify the access network that
   the MN moves to or from, the Access Network Identifiers (ANID) or the
   subnet information can be used [5][6].  In this document, a
   collection of such information is called "handover assist
   information".  In 3G CDMA networks, the link-layer address of the new
   access point defined in [3] may not be available.  If this is the
   case, the handover assist information SHOULD be used instead.

Yokota & Dommety          Expires July 25, 2008                 [Page 7]

Internet-Draft            3G CDMA Fast Handover             January 2008

5.  Fast handover procedures

   There are two modes defined in [3] according to the time of sending
   the FBU (Fast Binding Update); one is called "predictive mode," where
   the MN sends the FBU and receives the FBAck (Fast Binding Ack) on the
   PAR (Previous Access Router)'s link and the other is called "reactive
   mode," where the MN sends the FBU from the NAR (New Access Router)'s
   link.  In the predictive mode, the time and place the MN hands off
   must be indicated sufficiently before the time it actually happens.
   In cellular systems, since handovers are controlled by the network,
   the predictive mode is well applied.  However, if the network is not
   configured to be able to identify the new AR, to which the MN is
   moving next, in a timely manner, the reactive mode is better applied.

   RFC4902 Section 2 suggests architectural principles on the link
   indication and the effectiveness of the optimization.  The link
   indication of this document relies on 3G CDMA networks and the
   effectiveness of the optimization is attributed to RFC4068bis.  The
   above principles are thus considered by the related specs that this
   document is based on.

5.1.  Predictive fast handover

   Figure 2 shows the predictive mode of MIPv6 fast handover operation.
   When the MN finds a sector or a BS whose pilot signal is sufficiently
   strong, it initiates handover according to the following sequence:

      (a) A router solicitation for proxy router advertisement is sent
      to the PAR.  Handover assist information for the target 3G CDMA
      network (e.g. pilot sets as described in Section 4) is attached to
      this message.

      (b) Based on the received handover assist information, the NAR is
      determined and a proxy router advertisement containing the prefix
      in the NAR is sent back to the MN.

      (c) The MN creates an NCoA (new CoA) and sends the Fast Binding
      Update (FBU) with the NCoA to the PAR, which in turn sends the
      Handover Initiate (HI) to the NAR.

      (d) The NAR sends the Handover Acknowledge (HAck) back to the PAR,
      which in turn sends the FBU acknowledgment (FBAck) to the MN.

      (e) The PAR starts forwarding packets toward the NCoA and the NAR
      captures and buffers them.

      (f) The link-layer connection associated with the PAR is closed
      and a new traffic channel is assigned in the new access network.

Yokota & Dommety          Expires July 25, 2008                 [Page 8]

Internet-Draft            3G CDMA Fast Handover             January 2008

      (g) The MN attaches to the new access network.  The attachment
      procedure is access technology specific and that for 3G CDMA
      network including the PPP transactions is described later.

      (h) The MN sends the Unsolicited Neighbor Advertisement (UNA).

      (i) The NAR starts delivering packets to the MN.

      (j) The MN sends the BU to the HA to update the BCE with the NCoA
      and the HA sends back the BA to the MN.

         MN            PAR             NAR            HA             AAA
         |    RtSolPr   |               |              |              |
    (a)  |------------->|               |              |              |
         |    PrRtAdv   |               |              |              |
    (b)  |<-------------|               |              |              |
         |      FBU     |      Hl       |              |              |
    (c)  |------------->|-------------->|              |              |
         |     FBack    |     HAck      |              |              |
    (d)  |<-------------|<--------------|              |              |
         |              |forward packets|              |              |
    (e)  |              |==============>|(buffering)   |              |
         |              |               |              |              |
    (f) handover        |               |              |              |
         |              |               |              |              |
        +--------------------------------------------------------------+
    (g) |                     Attachment procedure                     |
        +--------------------------------------------------------------+
         |             UNA              |              |              |
    (h)  |----------------------------->|              |              |
         |       deliver packets        |              |              |
    (i)  |<=============================|              |              |
         |              |        BU/BA  |              |              |
    (j)  |<------------------------------------------->|              |
         |              |               |              |              |

         Figure 2: MIPv6 Fast handover operation (predictive mode)

   It is assumed that the NAR can be identified by the PAR leveraging
   the handover assist information from the MN.  To perform the
   predictive mode, the MN MUST send the FBU before the connection with
   the current access network is closed.  If the MN fails to send the
   FBU before handover, it SHOULD fall back to the reactive mode.  Even
   if the MN successfully sends the FBU, its reception by the PAR may be
   delayed for various reasons such as congestion.  If the NAR receives
   the HI triggered by the delayed FBU after the reception of the UNA
   ((c) comes after (h)), then the NAR SHOULD send the HAck with

Yokota & Dommety          Expires July 25, 2008                 [Page 9]

Internet-Draft            3G CDMA Fast Handover             January 2008

   handover not accepted and behave as the reactive mode.

   In (a), it is mandated that RtSolPr includes the New Access Point and
   the MN Link-Layer Address (LLA) options (Option Code=1 and 2,
   respectively) according to [3].  As for the MN-LLA option,a possible
   identifier is the interface ID, which can be used to construct the
   LLA of the MN.  Otherwise, more oft-used 3G specific IDs such as the
   MN ID (e.g.  IMSI) [7] can be used.  If this is the case, however,
   the Handover Assist Information option SHOULD be used since the
   length of this value is not necessarily multiples of 8 octets.  As
   for the MN-LLA option , the only available identifier is the
   interface ID, so it SHOULD be used for the MN-LLA.  As for the New
   AP-LLA option, however, the handover assist information MAY replace
   it in 3G CDMA networks.  Since the LLA is assumed to be an IEEE
   identifier, even if the length field of the LLA option is in units of
   8 octets, the actual length can be obtained by knowing that the
   length of an IEEE identifier is 6 octets.  If the interface ID of the
   MN is generated in the EUI-64-based format, the MN-LLA can be
   constructed from it.  However, if the type of the MN-LLA is not
   known, the length of the LLA becomes ambiguous.  If this is the case,
   it is necessary to use a new option defined in Section 6.1 and the
   corresponding length in it.

   In (b), PrRtAdv MUST include options for the IP address of the NAR,
   which may be the link-local address, and the prefix for the MN.  The
   PAR SHOULD be able to identify the NAR from the handover assist
   information provided by the MN.

   Figure 3 shows the call flow for the initial attachment in the 3G
   CDMA network [8].  After the traffic channel is assigned, the MN
   first establishes a link-layer connection between itself and the
   access router.  As the link-layer protocol, PPP can be considered and
   in this figure, a PPP handshake is depicted as an example.  Then the
   MN registers with the HA by sending a Binding Update message.  There
   are several parameters for using Mobile IPv6 such as the home address
   (HoA), the care-of address (CoA), the home agent address (HA) and the
   home link prefix (HLP).  In [8], obtaining these values is called
   bootstrapping and the bootstrapping information can be obtained
   during the link-layer establishment phase and/or the mobility binding
   phase [10].

Yokota & Dommety          Expires July 25, 2008                [Page 10]

Internet-Draft            3G CDMA Fast Handover             January 2008

                 MN            PAR         NAR         HA          AAA
          /       |     (serving PDSN) (target PDSN)    |           |
          |       |        LCP  |           |           |           |
          | (1)   |<----------------------->|           |           |
          |       |        CHAP/PAP         | Access-Request/Accept |
          | (2)   |<----------------------->|<-------------|------->|
          |.      |             |        +------+       |  |        |
          |.(3)*  |             |        |  HA  |<---------+        |
          |.      |             |        +------+       |           |
          |+........................................+   |           |
          |.      |                         |       .   |           |
          |.      |    IPv6CP(IF-ID)        |       .   |           |
          |.(4)*  |<---------|------------->|       .   |           |
      (g)< .    +---------+  |  |           |       .   |           |
          |.(5)*| LL-addr |<-+  |           |       .   |           |
          |.    +---------+     |           |       .   |           |
          |.      |                         |       .   |           |
          |.      |       RA(prefix)        |       .   |           |
          |.(6)*  |<---------|--------------|       .   |           |
          |.    +-----+      |  |           |       .   |           |
          |.(7)*| CoA |<-----+  |           |       .   |           |
          |.    +-----+         |           |       .   |           |
          |+........................................+   |           |
          |       |      DHCPv6(HA)         |           |           |
          | (8)   |<---------------+------->|           |           |
          |     +-----+         |  |        |           |           |
          | (9) | HA  |<-----------+        |           |           |
          |     +-----+         |           |           |           |
          |       |             |           |           |           |
          \       |             |           |           |           |

             Figure 3: Attachment procedure in 3G CDMA network

   The procedure for the initial attachment is as follows:

   (g)    The link-layer connection establishment and the bootstrapping
          phase

   (g-1)  The LCP (Link Control Protocol) configure-request/response
          messages are exchanged.

   (g-2)  User authentication (e.g.  CHAP or PAP) is conducted.

   (g-3)  The static bootstrapping information is conveyed from the AAA
          and stored in the NAR (target PDSN).  The HoA and HLP can be
          dynamically assigned by the HA in the mobility binding phase.
          This step can be skipped in the handover case.

Yokota & Dommety          Expires July 25, 2008                [Page 11]

Internet-Draft            3G CDMA Fast Handover             January 2008

   (g-4)  Unique interface IDs are negotiated in IPv6CP.

   (g-5)  The MN configures its link-local address based on the obtained
          interface ID.

   (g-6)  A router advertisement containing the prefix is received by
          the MN.

   (g-7)  The MN configures its CoA based on the obtained prefix.

   (g-8)  DHCPv6 is used to obtain the static bootstrap information
          (e.g. the HA address).  This step is performed in the initial
          attachment and can be skipped once the MN obtains those
          parameters.

   (g-9)  The MN installs the bootstrap information for further
          procedures (e.g. the mobility binding).

   As is shown in Figure 3, it takes a considerable amount of time to
   establish a link-layer connection and almost all of the above
   sequences run every time the MN attaches to a new access network.  It
   is therefore beneficial if packets in transit to the MN are saved not
   only during the time period where the MN switches to the new radio
   channel but also during the time period where the MN establishes the
   link-layer connection.

   There are several ways to configure a unique IP address for the MN.
   If a globally unique prefix is assigned per link as introduced in
   [8], the MN can use any interface ID except that of the other peer
   (the AR to which the MN is attached) to create a unique IP address.
   If this is the case, however, the PAR cannot provide the MN with a
   correct prefix for the new network in the PrRtAdv since such a prefix
   is selected by the NAR and provided in the router advertisement.  The
   MN therefore configures a temporary NCoA with the prefix provided by
   the PAR and the correct NCoA MUST be assigned by the NAR.  Therefore,
   in 3G CDMA network, the PAR MUST send the HI with the S flag set when
   it receives the FBU from the MN at step (c) in Figure 2.

   In [3], the UNA MUST include the LLA of the MN, but the point-to-
   point link-layer connection makes it unnecessary.  The only required
   information is the NCoA to check if there is a corresponding buffer.
   Thus, in (h) function of the UNA can be realized in several ways:

   o  Since the establishment of the link-layer connection in (g)
      indicates readiness of data communication on the MN side, the NAR
      immediately checks if there is a buffer that has packets destined
      for the NCoA, which was configured at steps (c) - (d), and starts
      delivering if any. (elimination of UNA)

Yokota & Dommety          Expires July 25, 2008                [Page 12]

Internet-Draft            3G CDMA Fast Handover             January 2008

   o  The UNA equivalent information can be conveyed in the phase of the
      link-layer connection, e.g. by conveying the NCoA in a PPP IPCP
      with vendor specific extension as defined in [9].  Only when this
      message is received by the NAR, it checks if there is a buffer for
      the NCoA.  (L2 implementation of UNA)

   o  The MN sends the UNA as defined in [3] with the LLA of the MN,
      which may be derived from the EUI-64 based interface ID. (standard
      implementation of UNA)

   If PPP IPCP option can be and is used as the means for the L2
   implementation of UNA, it SHOULD be confirmed that the NAR supports
   this option, otherwise it may cause a longer delay by the Configure-
   Reject message.

   The primary benefit of this mode is that the packets destined for the
   MN can be buffered at the NAR, and packet loss due to handover will
   be much lower than that of the normal MIPv6 operation.  Regarding the
   bootstrapping, the following benefit can be obtained, too:

   o  Since the NCoA can be configured via the fast handover procedures,
      a router advertisement is not required.

   Therefore, the procedures (g-4) to (g-7) can be skipped from the
   standard MIPv6 operation in Figure 3.

5.2.  Reactive fast handover

   When the MN cannot receive the FBAck on the PAR's link or the PAR in
   the 3G CDMA network cannot accurately resolve the address of the NAR,
   the reactive fast handover can be applied.  To minimize packet loss
   in this situation, the PAR instead of the NAR can buffer packets for
   the MN until the MN regains connectivity with the NAR.  The NAR
   obtains the information of the PAR from the MN on the NAR's link and
   receives packets buffered at the PAR.  In this case, the PAR does not
   need to know the IP address of the NAR or the NCoA and just waits for
   the NAR to contact the PAR.  However, since the PAR needs to know
   when to buffer packets for the MN, the PAR obtains the timing of
   buffering from the MN via the FBU or the lower layer signaling, e.g.
   an indication of the release of the connection with the MN.  Details
   of the procedure are as follows:

      (a) A router solicitation for proxy router advertisement MAY be
      sent to the PAR.

      (b) The proxy router advertisement MAY be sent to the MN, but the
      prefix of the NAR MAY not be included.

Yokota & Dommety          Expires July 25, 2008                [Page 13]

Internet-Draft            3G CDMA Fast Handover             January 2008

      (c) The MN sends the FBU or the access network indicates the close
      of the connection with the MN by the lower layer signaling.  If
      the B flag is set in the FBU, the PAR SHOULD start buffering
      packets destined for the PCoA.

      (d) The link-layer connection associated with the PAR is closed
      and a new traffic channel is assigned in the new access network.

      (e) The MN attaches to the new access network.  This part is the
      same as described in Section 5.1 and illustrated in Figure 3.

      (f) The MN MAY send the UNA to the NAR.  Since the attachment
      procedure in the previous step guarantees the uniqueness of the
      NCoA in the new access network, the UNA is not mandatory.

      (g) The MN sends the Fast Binding Update (FBU) to the NAR.

      (h) The NAR sends the FBU to the PAR.

      (i) The PAR sends the Handover Initiate (HI) to the NAR with the
      Code set to 1.

      (j) The NAR sends the Handover Acknowledge (HAck) back to the PAR.

      (k) The PAR sends the FBAck to the NAR.

      (l) If the PAR is buffering packets destined for the PCoA, it
      starts forwarding them as well as newly arriving ones to the NAR.

      (m) The NAR delivers the packets to the MN.

      (n) The MN sends the BU to the HA to update the BCE with the NCoA
      and the HA sends back the BA to the MN.

Yokota & Dommety          Expires July 25, 2008                [Page 14]

Internet-Draft            3G CDMA Fast Handover             January 2008

         MN            PAR             NAR             HA            AAA
         |   RtSolPr    |               |              |              |
    (a)  |------------->|               |              |              |
         |   PrRtAdv    |               |              |              |
    (b)  |<-------------|               |              |              |
         |     FBU      |               |              |              |
    (c)  |- - - - - - ->|(buffering)    |              |              |
         |              |               |              |              |
    (d) handover        |               |              |              |
         |              |               |              |              |
        +--------------------------------------------------------------+
    (e) |                    Attachment procedure                      |
        +--------------------------------------------------------------+
         |             UNA              |              |              |
    (f)  |----------------------------->|              |              |
         |             FBU              |              |              |
    (g)  |----------------------------->|              |              |
         |              |     FBU       |              |              |
    (h)  |              |<--------------|              |              |
         |              |      HI       |              |              |
    (i)  |              |-------------->|              |              |
         |              |     HAck      |              |              |
    (j)  |              |<--------------|              |              |
         |              |     FBack     |              |              |
    (k)  |              |-------------->|              |              |
         |              |forward packets|              |              |
    (l)  |              |==============>|              |              |
         |        deliver packets       |              |              |
    (m)  |<=============================|              |              |
         |              |        BU/BA  |              |              |
    (n)  |<------------------------------------------->|              |
         |              |               |              |              |

          Figure 4: MIPv6 Fast handover operation (reactive mode)

   To indicate the PAR to buffer packets destined for the PCoA, in step
   (c), a new flag 'B' is defined in the FBU.  When the PAR receives the
   FBU with this flag set, it SHOULD buffer packets for the MN.  The PAR
   MAY also start buffering packets for the MN based on lower layer
   signal during handover.  Since the packets are buffered at the PAR in
   this scenario, the UNA, which is received and processed by the NAR,
   can not be used to trigger to forward the buffered packets at the
   PAR.  In Figure 4, the HAck from the NAR is used as the trigger for
   forwarding.

   If the target link is not available after the handover (step (d)) and
   the MN comes back to the PAR after the connection was closed, the
   attachment procedure is performed on the previous link.  The packet

Yokota & Dommety          Expires July 25, 2008                [Page 15]

Internet-Draft            3G CDMA Fast Handover             January 2008

   buffered at the PAR may be delivered to the MN after the connection
   is re-established.

Yokota & Dommety          Expires July 25, 2008                [Page 16]

Internet-Draft            3G CDMA Fast Handover             January 2008

6.  Message Format

6.1.  Handover Assist Information Option

   If the lower layer information of the new point of attachment is not
   represented as the Link-Layer Address, the following option SHOULD be
   used.  The primary purpose of this option is to convey the handover
   assist information described in Section 4.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type       |    Length     |  Option-Code  |   AS-Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           AS-Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           T.B.D.

   Length         The size of this option in 8 octets including the
                  Type, Length, Option-Code and AS-Length fields.

   Option-Code    0 Access Network Identifier (AN ID)
                  1 Mobile Node Identification (MN ID)
                  2 Sector ID

   AS-Length      The size of the AS-Value field in octets.

   AS-Value       Zero or more octets of handover assist information
                  data.  Handover assist information (e.g. pilot set or
                  cell information) described in Section 4 SHOULD use
                  this option.

   This option MUST be understood by the sender (typically the MN) and
   the receiver (typically the AR).  If nodes in between do not support
   this option, they SHOULD treat this option as opaque and MUST NOT
   drop it.

   Option-Code Indicates the particular type of handover assist
   information.  This value is administrated by the vendor or
   organization that uses this option (typically 3GPP2).

   Depending on the size of the AS-Value field, appropriate padding MUST
   be used to ensure that the entire option size is a multiple of 8
   octets.  The AS-Length is used to disambiguate the size of the AS-
   Value.

Yokota & Dommety          Expires July 25, 2008                [Page 17]

Internet-Draft            3G CDMA Fast Handover             January 2008

6.2.  New flag extension to FBU message

   The MN MUST send the FBU to the PAR with the following new (B) flag
   set in the previous network to indicate the PAR to buffer packets
   destined for the PCoA.  The rest of the Binding Update message format
   remains the same as defined in [2] and with the additional (M), (R)
   and (P) flags as specified in [11], [12] and [13], respectively.

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|H|L|K|M|R|P|B|   Reserved    |            Lifetime           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   B flag:        If the 'B' flag is set, the PAR SHOULD start buffering
                  the packets destined for the MN as specified in
                  Section 5.2.

Yokota & Dommety          Expires July 25, 2008                [Page 18]

Internet-Draft            3G CDMA Fast Handover             January 2008

7.  Security Considerations

   The security considerations for Mobile IPv6 fast handover are
   described in [3].  When a 3G network is considered, the PAR and the
   NAR have a trust relationship and the links between them and those
   between the ARs and the MN are usually secured. therefore additional
   security mechanisms to protect FMIP signaling are not required.
   However, depending on the operator's requirement, SEND [15] and the
   shared handover key defined in [14] can be used.

Yokota & Dommety          Expires July 25, 2008                [Page 19]

Internet-Draft            3G CDMA Fast Handover             January 2008

8.  IANA Considerations

   This document defines one new Neighbor Discovery [16] option called
   the handover assist information option, which is described in
   Section 6.1.

Yokota & Dommety          Expires July 25, 2008                [Page 20]

Internet-Draft            3G CDMA Fast Handover             January 2008

9.  Conclusions

   The handover performance of the standard Mobile IPv6 is not
   sufficient for real-time communications that are not resilient to
   packet loss.  The Mobile IPv6 fast handover methods are effective for
   these applications.  This document described how these methods can be
   applied to 3G CDMA networks by specifying the three approaches: the
   predictive, reactive and network-controlled fast handovers.

Yokota & Dommety          Expires July 25, 2008                [Page 21]

Internet-Draft            3G CDMA Fast Handover             January 2008

10.  Acknowledgements

   The authors would like to thank Kuntal Chowdhury, Ashutosh Dutta, Ved
   Kafle and Vijay Devarapalli for providing feedback and support for
   this work.

Yokota & Dommety          Expires July 25, 2008                [Page 22]

Internet-Draft            3G CDMA Fast Handover             January 2008

11.  References

11.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004.

   [3]   Koodli, R., Ed., "Mobile IPv6 Fast Handovers",
          draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt, October 2007.

11.2.  Informative References

   [4]   McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks",
         RFC 4260, November 2005.

   [5]   3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability
         Specification", A.S0001-A v.2.0, June 2001.

   [6]   3GPP2 TSG-A, "Interoperability Specification for High Rate
         Packet 1 2 Data (HRPD) Access Network Interfaces - Rev A.",
         A.S0007-A v.2.0, May 2003.

   [7]   3GPP2 TSG-A, "Interoperability Specification (IOS) for High
         Rate Packet Data (HRPD) Access Network Interfaces", 3GPP2
         A.S0008-0 v3.0, May 2003.

   [8]   3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP
         and Mobile IP services", X.S0011-002-D v.1.0, February 2006.

   [9]   Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.

   [10]  Devarapalli, V., Patel, A., Keung, K., and K. Chowdhury,
         "Mobile IPv6 Bootstrapping for the Authentication Option
         Protocol",
          draft-devarapalli-mip6-authprotocol-bootstrap-03.txt,
         September 2007.

   [11]  Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
         "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
         RFC 4140, August 2005.

   [12]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

   [13]  Gundavell, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K.,

Yokota & Dommety          Expires July 25, 2008                [Page 23]

Internet-Draft            3G CDMA Fast Handover             January 2008

         and B. Patil, "Proxy Mobile IPv6",
          draft-ietf-netlmm-proxymip6-07.txt, September 2007.

   [14]  Kempf, J., Ed. and R. Koodli, "Distributing a Symmetric FMIPv6
         Handover Key using SEND",
          draft-ietf-mipshop-handover-key-03.txt, November 2007.

   [15]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [16]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
         "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
         September 2007.

Yokota & Dommety          Expires July 25, 2008                [Page 24]

Internet-Draft            3G CDMA Fast Handover             January 2008

Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   JP

   Phone: +81 49 278 7894
   Fax:   +81 49 278 7510
   Email: [email-masked]

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Phone: +1 408 525 1404
   Email: [email-masked]

Yokota & Dommety          Expires July 25, 2008                [Page 25]

Internet-Draft            3G CDMA Fast Handover             January 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Yokota & Dommety          Expires July 25, 2008                [Page 26]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Jan 2008 14:45:05 +0200

Hidetoshi,

> ->Removed RFC4096 and corrected the description of the UNA.

Good.

> If the serving access network finds that the sector associated with
> the highest pilot strength belongs to a different AR, it attempts to
> close the connection with the MN. The MN then attempts to get a new
> traffic channel assigned in the new access network, which is followed
> by establishing a new connection with the new AR. The MN can
> continually search for pilots without disrupting the data
> communication and a timely handover is assisted by the network. If the
> air interface information can be used as a trigger for the handover
> between access routers, fast and smooth handover of Mobile IPv6 can be
> realized in 3G CDMA networks.
>
> [Proposed text:]
> same access network, the mobility within that access network is
> handled by the access specific interfaces [A.S0007-A_v2.0] and the
> link-layer connection between the MN and AR can be maintained without
> a reestablishment. The MN can continually search for pilots without
> sector associated with the highest pilot strength belongs to a
> different AR, it attempts to close the connection with the MN. The MN
> then attempts to get a new traffic channel assigned in the new access
> network, which is followed by establishing a new connection with the
> new AR. This could cause a noticeable communication disruption and
> lead to a serious degradation of the user experience. In order to
> minimize the service degradation during the handover between ARs, an
> IP-level fast handover approach as defined in RFC4068 needs to be
> involved. If the air interface information can be used as a trigger
> for the handover between access routers, fast and smooth handover of
> Mobile IPv6 can be realized in 3G CDMA networks.

OK

> indication, which is precisely specified by 3GPP2. Therefore,
> principles (1) to (5), (7), (8) and (11) are considered by those
> specs. Principle (6) mentions the effectiveness of the optimization.
> This I-D bases its effectiveness on RFC4068bis. Therefore this
> principle is dealt by this RFC. Principle (9) mentions inconsistencies
> between link and routing layer metrics. This spec does not change the
> routing metrics and multi-homing is not considered. Finally, principle
> (10) mentions overhead reduction scheme and interoperability. This I-D
> does not deal with overhead reduction and therefore this principle
> does not apply.
>

I would like to see a new section devoted to this in the draft (perhaps
starting along the lines of your explanation above).

> -> Reviews are on going by 3GPP2 experts.

Good. Any news on when we will get results?

> can be used. If this is the case, the Handover Assist Information
> option should be used since the length of this value is not
> necessarily multiples of 8 octets.
>
> [Original text:]
> As for the MN-LLA option, the only available identifier is the
> interface ID, so it SHOULD be used for the MN-LLA.
>
> [Proposed text on p.10:]
> this is the case, however, the Handover Assist Information option
> SHOULD be used since the length of this value is not necessarily
> multiples of 8 octets.

It is true that an EUI-64 is sometimes used to create an IP layer IID.
However, not always, and we cannot assume that IID can be used to derive
the MAC address.

In general, text in the draft should state what information goes into
the MN-LLA option exactly. I would assume that this the L2 address of
the 3G network, if it has an L2 address. If it does not use L2
addresses, maybe you should not specify the use of MN-LLA at all, and
should only employ the Handover Assition Information option?

> RFC4068bis. Further check will be done.

Ok.

> it SHOULD be administrated that the NAR supports this option,

This is not quite right either. Perhaps you want to say something along
the lines of this:

By default, the MN SHOULD NOT use the IPCP option. If the administrators
have ensured that the NAR supports the IPCP option, they can turn on a
configuration flag for the MN to employ IPCP.

> standard MIPv6 operation in Figure 3.

Good.

> error case in RFC4068bis. In 3G CDMA network, the handover is
> performed when the link in the target network is sufficiently stable;
> however, if the connection is closed and the MN comes back to the same
> router, the attachment procedure will be performed in the previous
> network. It would be desirable to be able to deliver the packets
> buffered at the PAR to the MN, but this spec does not mandate it.
>

This is good, but is this the only one? I think we need to describe the
reliability of each indication, and also explain what to do if/when it
turns out to be wrong.

> administrated by the network operator. The MN may be informed about
> the capability of the network by other means (e.g. AAA server). As one
> approach, if the MN does not obtain the prefix information for the
> NCoA by the PrRtAdv, the MN can infer that the network does not
> support the predictive mode and behaves as the reactive mode. If this
> approach is worth describing, I will add it in the document.

That particular way to interprete PrRtAdv would be something more
appropriate for the FMIP base spec.

Its not clear that AAA is the right place for this, because you may not
want to download the whole capability list for all ARs upon network
attachment. And AAA is typically not run in the middle of the session.
Besides, MN is not a party in the AAA transaction.

I would like to see one of the following:

 1) explicit new option/error code/something in the PrRtAdv to indicate
that no support for predictive mode exists
 2) some other way to use FMIP to convey this (e.g., would never
responding to PrRtSol help?)
 3) removal of the functionality, just require that all ARs support both
modes.

> described in [3]. When a 3G network is considered, the PAR and the NAR
> have a trusting relationship and the links between them and those
> between the ARs and the MN are usually secured.
>
> [Proposed text:]
> described in [3]. When a 3G network is considered, the PAR and the NAR
> have a trusting relationship 
trust relationship
> and the links between them and those between the ARs and the MN are
> usually secured ; therefore additional security mechanisms to protect
> FMIP signaling are not required. However, depending on the operator’s
> requirement, SEND [xxx] and the shared handover key defined in [yyy]
> can be used.

This seems very inadequate. The point of the FMIP+Handoverkey security
design is that on the first link you establish a key with your PAR. Then
when you are on the next link, you can employ this key to convince the
PAR to redirect *your* packets.

How do you do this if you only rely on L2 security? Note that that even
if everyone's L2 is secured, you still have the vulnerability where node
A can claim that it wants to receive node B's traffic from an access
router. L2 security only provides a secure channel and guarantees that
you should be let to the network.

The easy way out of this is to require handoverkey draft for this usage
as well. There are other ways out.

> charter, Section 5.3 is removed.

OK

> Section 6.1. Also these parameters are added in the Terminology
> section (Section 3).

OK, but I want to see what the text is. Checking... no, the new text
does not go quite far enough. Do this:

1) remove the word "typically" from the text
2) make this an option that is defined here in this document, not
something that is administered by 3GPP2
3) specify what data goes into AS-Value when different option-codes are used
4) add iana considerations section text that says new option-code values
can be allocated through "IETF Review or IESG Approval".

> approach is taken in this document. In this case, an explicit
> indication is needed for the MN to be able to received packet without
> fail.
>
OK

Jari

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 01 Feb 2008 06:26:19 +0900

Hi Jari,

Thanks for your valuable comments. My current understanding is:

Resolved: (1), (2), (8), (12), (14), (15)
Pending: (4), (6)

In the revised version attached to this mail,
Modified: (3), (7), (9), (10), (13)
Question: (5), (9), (11)

Please see inline:

> starting along the lines of your explanation above).

HY> The above text is added in the new section 5.3.

> Good. Any news on when we will get results?

HY> Actually, Kuntal, who is a super 3GPP2 expert, has already reviewed 
this document rigorously, so the quality should be good enough, but I'm 
asking a couple of other experts for review just in case. I hope the 
review result will be coming soon.

> should only employ the Handover Assition Information option?

HY> I would like to use the MN ID (e.g. IMSI) with the Handover Assist 
Information option instead of the MN-LLA option, but RFC4068bis mandates 
the MN-LLA option in the HI message or UNA message. Is it ok to relax 
this mandatory option? (Should I ask Rajeev about this question?)

> configuration flag for the MN to employ IPCP.

HY>Thanks for the text proposal. The above sentence replaced the 
corresponding old paragraph.

> reliability of each indication, and also explain what to do if/when it

HY> May I ask a question for clarification? The network receives 
periodic reports from the MN and the handover indication is usually sent 
to the MN only when the condition of the target link is sufficient 
enough. Therefore the possibility to send false handover indications is 
not considered to be so high, but there is a much higher possibility 
that the MN could not move to the target link for various reasons. This 
situation happens whether FMIP is used or not and the fallback 
mechanisms are provided by the 3G CDMA network. So what should be 
specified here is how the FMIP should behave when the MN could not 
handover and falls back to the original link, correct? I think that the 
critical part is buffering. If packets are buffered at the PAR before 
the handover, this buffering should be stopped and the buffered packets 
should be released (preferably delivered to the MN, which returned to 
the original link) Is this what you suggested, or something else?

>  3) removal of the functionality, just require that all ARs support both

HY> A new flag is defined in PrRtAdv to indicate that the network does 
not support the predictive fast handover mode. Accordingly, section 5.1 
and section 5.2 are modified.

> as well. There are other ways out.

HY>Again, I have a question for clarification. If the AR authenticates 
each MN at every attachment and identifies it by the unique ID, which is 
supposed to be unbreakable, then is there still a threat of 
impersonating another MN requesting its traffic? If so, the handoverkey 
should be mandatory.

> can be allocated through "IETF Review or IESG Approval".

HY> Section 6.1 and 8 are now modified to reflect the above comments.

I will update the document again soon.

Regards,
-- 
Hidetoshi

Network Working Group                                          H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Informational                                G. Dommety
Expires: August 4, 2008                              Cisco Systems, Inc.
                                                        February 1, 2008

Status of this Memo

   This Internet-Draft will expire on August 4, 2008.

Copyright Notice

Yokota & Dommety         Expires August 4, 2008                 [Page 1]

Internet-Draft            3G CDMA Fast Handover            February 2008

Abstract

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Network reference model for Mobile IPv6 over 3G CDMA
       networks . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Fast handover procedures . . . . . . . . . . . . . . . . . . .  8
     5.1.  Predictive fast handover . . . . . . . . . . . . . . . . .  8
     5.2.  Reactive fast handover . . . . . . . . . . . . . . . . . . 13
     5.3.  Considerations on the link indications . . . . . . . . . . 16
   6.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 17
     6.1.  Handover Assist Information Option . . . . . . . . . . . . 17
     6.2.  New flag extension to FBU message  . . . . . . . . . . . . 17
     6.3.  New flag extension to PrRtAdv message  . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25

Yokota & Dommety         Expires August 4, 2008                 [Page 2]

Internet-Draft            3G CDMA Fast Handover            February 2008

1.  Requirements notation

Yokota & Dommety         Expires August 4, 2008                 [Page 3]

Internet-Draft            3G CDMA Fast Handover            February 2008

2.  Introduction

Yokota & Dommety         Expires August 4, 2008                 [Page 4]

Internet-Draft            3G CDMA Fast Handover            February 2008

3.  Terminology

   Forward Pilot Channel:

   Sector:

   Home Link Prefix (HLP):

   Mobile Identity (MN ID)

Yokota & Dommety         Expires August 4, 2008                 [Page 5]

Internet-Draft            3G CDMA Fast Handover            February 2008

                                      Home IP Network

Yokota & Dommety         Expires August 4, 2008                 [Page 6]

Internet-Draft            3G CDMA Fast Handover            February 2008

Yokota & Dommety         Expires August 4, 2008                 [Page 7]

Internet-Draft            3G CDMA Fast Handover            February 2008

      (a) A router solicitation for proxy router advertisement is sent
      to the PAR.  Handover assist information for the target 3G CDMA
      network is attached to this message.

      (b) Based on the received handover assist information, the NAR is
      determined and a proxy router advertisement (PrRtAdv) containing
      the prefix in the NAR is sent back to the MN.  The MN also checks
      that the R flag is not set in the PrRtAdv message, which indicates
      the network supports the predictive fast handover mode (defined
      later).

Yokota & Dommety         Expires August 4, 2008                 [Page 8]

Internet-Draft            3G CDMA Fast Handover            February 2008

         MN            PAR             NAR            HA             AAA
         |    RtSolPr   |               |              |              |

Yokota & Dommety         Expires August 4, 2008                 [Page 9]

Internet-Draft            3G CDMA Fast Handover            February 2008

   respectively) according to [3].  As for the MN-LLA option, a possible

Yokota & Dommety         Expires August 4, 2008                [Page 10]

Internet-Draft            3G CDMA Fast Handover            February 2008

                 MN            PAR         NAR         HA          AAA

Yokota & Dommety         Expires August 4, 2008                [Page 11]

Internet-Draft            3G CDMA Fast Handover            February 2008

Yokota & Dommety         Expires August 4, 2008                [Page 12]

Internet-Draft            3G CDMA Fast Handover            February 2008

   By default, the MN SHOULD NOT use the IPCP option.  If the
   administrators have ensured that the NAR supports the IPCP option,
   they can turn on a configuration flag for the MN to employ IPCP.

   When the networks does not support the predictive fast handover mode,
   the reactive fast handover is applied.  In this document, a new flag
   is defined in PrRtAdv to inform the MN about the capability of the
   network (see Section 6.3).  To minimize packet loss in this
   situation, the PAR instead of the NAR can buffer packets for the MN
   until the MN regains connectivity with the NAR.  The NAR obtains the
   information of the PAR from the MN on the NAR's link and receives
   packets buffered at the PAR.  In this case, the PAR does not need to
   know the IP address of the NAR or the NCoA and just waits for the NAR
   to contact the PAR.  However, since the PAR needs to know when to
   buffer packets for the MN, the PAR obtains the timing of buffering
   from the MN via the FBU or the lower layer signaling, e.g. an
   indication of the release of the connection with the MN.  Details of
   the procedure are as follows:

Yokota & Dommety         Expires August 4, 2008                [Page 13]

Internet-Draft            3G CDMA Fast Handover            February 2008

Yokota & Dommety         Expires August 4, 2008                [Page 14]

Internet-Draft            3G CDMA Fast Handover            February 2008

         MN            PAR             NAR             HA            AAA
         |   RtSolPr    |               |              |              |

Yokota & Dommety         Expires August 4, 2008                [Page 15]

Internet-Draft            3G CDMA Fast Handover            February 2008

5.3.  Considerations on the link indications

   This section discusses if the link indications assumed in this
   document meet the principles defined in RFC4907[17] Section 2, which
   suggests 11 architectural principles on the link indication and the
   effectiveness of the optimization.  This document relies on the 3G
   CDMA network regarding the link indication, which is precisely
   specified by 3GPP2.  Therefore, principles (1) to (5), (7), (8) and
   (11), that is, "Model Validation", "Clear Definition", "Robustness",
   "Recovery from Invalid Indications", "Congestion Control",
   "Interoperability", "Race Condition" and "Transport of Link
   Indications" are considered by those specs.  Principle (6)
   "Effectiveness" mentions the effectiveness of the optimization.  This
   document bases its effectiveness on RFC4068bis.  Therefore this
   principle is dealt by that RFC.  Principle (9) "Metric Consistency"
   mentions inconsistencies between link and routing layer metrics.  The
   spec of this document does not change the routing metrics and multi-
   homing is not considered.  Finally, principle (10) "Layer
   Compression", mentions overhead reduction scheme and
   interoperability.  This document does not deal with overhead
   reduction and therefore this principle does not apply.

Yokota & Dommety         Expires August 4, 2008                [Page 16]

Internet-Draft            3G CDMA Fast Handover            February 2008

6.  Message Format

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type       |    Length     |  Option-Code  |   HAI-Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            HAI-Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           T.B.D.

   HAI-Length     The size of the HAI-Value field in octets.

   HAI-Value      The value specified by the Option-Code.

   If those which received this message do not support this option, they
   SHOULD treat this option as opaque and MUST NOT drop it.

   Option-Code Indicates the particular type of handover assist
   information.  Currently, three types of information are defined to
   specify the location of the MN or to uniquely identify the MN (See
   Section 3).

Yokota & Dommety         Expires August 4, 2008                [Page 17]

Internet-Draft            3G CDMA Fast Handover            February 2008

6.3.  New flag extension to PrRtAdv message

   A new flag 'R' is defined in the PrRtAdv to inform the MN about the
   fast handover mode that the network supports.

        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            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Subtype    |R|  Reserved   |           Identifier          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Options ...
       +-+-+-+-+-+-+-+-+-+-+-+-

   R flag:        If the 'R' flag is set, the network supports only the
                  reactive handover mode.  Otherwise, the network
                  supports both the predictive and reactive fast
                  handover mode.

Yokota & Dommety         Expires August 4, 2008                [Page 18]

Internet-Draft            3G CDMA Fast Handover            February 2008

   between the ARs and the MN are usually secured.  Therefore additional

Yokota & Dommety         Expires August 4, 2008                [Page 19]

Internet-Draft            3G CDMA Fast Handover            February 2008

8.  IANA Considerations

   This document defines one new Neighbor Discovery [16] option called
   the handover assist information option, which is described in
   Section 6.1.  New option-code values in this option can be allocated
   through "IETF Review or IESG Approval"

Yokota & Dommety         Expires August 4, 2008                [Page 20]

Internet-Draft            3G CDMA Fast Handover            February 2008

9.  Acknowledgements

Yokota & Dommety         Expires August 4, 2008                [Page 21]

Internet-Draft            3G CDMA Fast Handover            February 2008

10.  References

10.1.  Normative References

10.2.  Informative References

Yokota & Dommety         Expires August 4, 2008                [Page 22]

Internet-Draft            3G CDMA Fast Handover            February 2008

   [17]  Aboba, B., "Architectural Implications of Link Indications",
         RFC 4907, June 2007.

Yokota & Dommety         Expires August 4, 2008                [Page 23]

Internet-Draft            3G CDMA Fast Handover            February 2008

Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   JP

   Phone: +81 49 278 7894
   Fax:   +81 49 278 7510

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Phone: +1 408 525 1404

Yokota & Dommety         Expires August 4, 2008                [Page 24]

Internet-Draft            3G CDMA Fast Handover            February 2008

Full Copyright Statement

Intellectual Property

Acknowledgment

Yokota & Dommety         Expires August 4, 2008                [Page 25]

_______________________________________________
Mipshop mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mipshop