[Mipshop] transient binding draft update
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mipshop] transient binding draft update



Dear all,

please find below a list of changes for the transient binding draft update.
Thanks for all comments. We'll post the update in a next step.

marco


* some editorial revision for clarification to address various comments

* removed access-specific forwarding from the Abstract

   This document specifies a mechanism which enhances Proxy Mobile IPv6
   protocol signaling to support the creation of a transient binding
   cache entry which is used to optimize the performance of dual radio
   handover, as well as single radio handover. ...


* revised text about Local Information in Introduction:
  
   MAGs can establish settings of a transient binding on the
   LMA by means of signaling.  An LMA can establish or change the
   settings of a transient binding according to events, such as a
   timeout, a change of the radio technology due to a handover or a
   completed set up of a radio bearer or configuration of an MN's IP
   address .  Such event may also be triggered by other protocols, e.g.
   Diameter messages from the AAA infrastructure.  

* revise title of section 3.3 Demand for a common solution -> Need for
  a common solution

* Activation of a transient BCE --> Revised to avoid "activation",
  but write "turn a transient BCE into an active BCE".

* clarification about in which detail the "LMA must know the access technology".
  issues resolved on the list, no modification in the draft

* removed section about MN operation

* added example about configuration data "link local address" in section 3.2.1

   "...delaying the PBU, which is sent from the new MAG to the LMA after the
   MN's new interface has attached to the network, is not possible, as
   the new MAG retrieves configuration data for the MN from the LMA in
   the PBA, such as the MN's HNP and the link local address to be used
   at the MAG."

* added text about the need of radio access forwarding to benefit from
  transient binding in a single radio handover and added reference to
  Appendix Use Cases

   ... Such downlink forwarding characteristic is
   denoted as 'Late path switch' (L).  Whereas during a dual radio
   handover an MN can receive downlink packets via its previous
   interface, during a single radio handover the late path switch
   supports re-using available forwarding mechanisms in the radio access
   network.  Appendix A describes both use cases.
 

* revised Intro to avoid confusion with "premature" forwarding of packets

  old text:

  ".. Address configuration as well
   as possible access technology specific radio bearer setup may delay
   the complete set up of the mobile node's new interface before it is
   ready to receive or send data packets.  In case the LMA prematurely
   forwards packets towards the mobile node's new interface, some
   packets may get lost or experience major packet delay. 

  new text:

  "... Address configuration as well
   as possible access technology specific radio bearer setup may delay
   the complete set up of the mobile node's new interface before it is
   ready to receive or send data packets.  In case the LMA performs
   operation according to [RFC5213] and forwards packets to the mobile
   node's new interface after the reception of the PBU from the nMAG,
   some packets may get lost or experience major packet delay. "

*  Added note about static implementation specific approach and reference
   to Appendix B to the Introduction.

   "..Some implementation specific solutions, such as static configuration
   and introducing some delays, may help to reduce some issues addressed
   in this draft, which is discussed in Appendix B.  A dynamic solution
   by means of the proposed protocol operation helps to optimize the
   performance for a variety of handover situations and different radio
   characteristics."
 

* added examples from 3GPP to 3.2.1 where e.g. radio bearer setup etc. is being
  performed after PBU/PBA. 

  "...Both scenarios as depicted above can be found in [TS23.402], where
   the protocol sequence during a handover between different accesses
   considers a PMIPv6 handshake between the nMAG and the LMA to retrieve
   the MN's HNP before access specific operations can be completed."

* Made the use of DAD a "may" in the problem statement 

* revised appendix B.3, removed "secure and stable handover..."

   ".... Only additional signaling as provided by this document provides
   the information that late
   switching is applicable and enables a synchronization of the handover
   sequence, .i.e. the switching is adapted both to the finalization of
   the link between mobile terminal and nMAG and to the release of the
   link between mobile terminal and pMAG, whatever comes first.  Stable
   handover performance is achieved using protected PMIPv6 signaling as
   per [RFC5213]."

* revised appendix B.2, revised last paragraph about static timer
  based actication

  "...In order to handle all handoff circumstances, the activation mechanism
   as described in this draft is preferable over a statically configured
   timer and it would dynamically help in ending the late forwarding from
   the pMAG based on a protected signaling from the pMAG."


* revised last two paragraphs of appendix B.1

   "...Allowing the LMA to forward the received uplink traffic from the nMAG
   to the Internet while the MN BCE points to the pCoA hosted at the
   pMAG is a violation of all mobility protocols which require secure
   signaling exchange between the nMAG and the LMA before forwarding
   such traffic to the Internet.  Otherwise, the LMA will be modifying
   the mobile node's routing entry based on an unsecured data traffic
   packet coming from the nMAG.

   Therefore, this case can not be addressed by any statically
   configured information on the LMA.  On the contrary, a secure
   signaling using Transient Binding option as detailed in this draft is
   required to create a transient state for the mobile node BCE at the
   LMA.  This transient state will allow a temporary routing entry of
   the mobile node to point to the nMAG Proxy-CoA."
 












Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.