NetLMM Working Group O. Blume Internet-Draft R. Sigle Expires: Aug 21, 2008 Alcatel-Lucent Bell Labs February 18, 2008 Secondary Binding Cache entries for Proxy MIPv6 draft-blume-netlmm-secondary-bce-proxymip6ho-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on Aug 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Blume & Sigle Expires Aug 21, 2008 [Page 1] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 Abstract The IETF is specifying Proxy Mobile IPv6 for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and can be connected over more than one network interface at the same time. This extension introduces a secondary binding at the local Mobility Anchor (LMA) that is valid for receiving uplink packets but is not used for tunneling downlink packets towards the MN. This allows for preparation of the new binding while avoiding that the LMA will prematurely forward data packets to the mobile node's new interface before the address configuration of this interface has completed. Furthermore, secondary bindings can be used to avoid loss of delayed packets arriving at the LMA after the Binding Cache has been updated by a Proxy Binding Update from a new MAG. With the proposed extension, packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be mitigated. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Functional Components . . . . . . . . . . . . 5 4. Problem Statement and Solution . . . . . . . . . . . . . . . . 6 4.1. Secondary Binding Cache entries during PMIP handoff . . . . 8 4.2. State diagamm with Secondary Binding Cache entries in PMIP 10 4.3. Usage of Secondary Binding Cache entries in client MIP . . 12 5. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Protocol Extension for signalling of MBB handoff capability 13 5.2. Protocol Extension for Secondary Binding Cache Entries . . 14 5.3 Protocol Extension for the MN . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1 Normative References . . . . . . . . . . . . . . . . . . . .19 9.2 Informative References . . . . . . . . . . . . . . . . . . .19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Blume & Sigle Expires Aug 21, 2008 [Page 2] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 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 [RFC2119]. Blume & Sigle Expires Aug 21, 2008 [Page 3] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 2. Introduction The IETF NetLMM WG is specifying Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and can be connected over more than one network interface at the same time. Such parallel use of interfaces allows for reduction of handoff delay and packet loss during handoff across network interfaces. As for Proxy Mobile IP the MN is not involved in the IP mobility signalling, a timing issue between MN and LMA prevents taking full benefit of the parallel interfaces, as discussed in the following. For inter-technology handover, the mobile node needs to perform address configuration for the new interface. For IPv6, the mobile node needs to wait for a Router Advertisement and to perform duplicate address detection. During this time, the mobile node's new interface is not yet ready to receive data packets, while the previous interface is still able to send and receive data. If the LMA decides to forward data packets for the mobile node via the new MAG, packet losses can occur. This extension introduces a "secondary binding" at the local Mobility Anchor (LMA) that is valid for receiving uplink packets but is not used for tunneling downlink packets towards the MN. This allows for preparation of the new binding while avoiding that the LMA will prematurely forward data packets to the mobile node's new interface before the address configuration of this interface has completed. Furthermore, secondary bindings can be used to avoid loss of delayed packets arriving at the LMA after the Binding Cache has been updated by a Proxy Binding Update from a new MAG. With the proposed extension, it is not necessary that the MN is aware of the point in time, when the Binding Cache entry is updated at the LMA, but still packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be mitigated. This document is based on an previous document submitted to 3GPP SA2 working group [1], which described a use case for secondary bindings during handoff between an interface with client based Mobile IPv6 bindings and an interface applying Proxy Mobile IPv6 bindings. A similar proposal has been described in an Internet Draft [2], where the secondary bindings are denomimated as "preliminary bindings". In that draft secondary bindings where not used after the Proxy Binding Update and it was not discussed how to discriminate multi-homing from intertechnology handoff between interfaces with simultaneous transmission capability. Blume & Sigle Expires Aug 21, 2008 [Page 4] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 3. Terminology and Functional Components o MAG - Mobility Access Gateway. PMIPv6 functional component defined in [I-D.ietf-netlmm-proxymip6]. The MAG function is assumed to be located on the PMIPv6 domain's access routers. o LMA - Local Mobility Anchor. PMIPv6 functional component defined in [I-D.ietf-netlmm-proxymip6]. o pAR - Previous Access Router. Equivalent to current access router. In a layer 3 handover situation, the access router which the mobile node is leaving from. o nAR - New Access Router. Equivalent to handover target access router. In a layer 3 handover situation, the access router towards which the mobile node is moving to. o pMAG - previous MAG. In a layer 3 handover situation, the MAG function located on the previous access router o nMAG - new MAG. In a layer 3 handover situation, the MAG function located on the new access router. o IF - Interface. Any network interface, which offers an MN wireless or wired access to the network infrastructure. In case an MN has multiple interfaces implemented, they are numbered (IF1, IF2, ...) o Inter-RAT handover. Handover between different radio access technologies. o BBM - Break-Before-Break. In a BBM-handover sequence the radio and IP connectivity to the nMAG can only be estabished after the connectivity to the pMAG is released. This requires only oeration of one interface at any time, but causes significant interruption during handoff performance. o MBB - Make-Before-Break. In a MBB-handover sequence the radio and IP connectivity to the nMAG are estabished while the connectivity to the pMAG is still maintained. This allows for seamless handoff performance but requires the capability of the MN to operate two radio links simultaneously. Blume & Sigle Expires Aug 21, 2008 [Page 5] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 4. Problem Statement and Solution Traditional radio mobility schemes only support radio layer mobility between base stations or access points within the same IP access network. IP mobility protocols based on MIPv4 or MIPv6 also allow to handoff an IP session to another L2 access technology. If the mobile node supports only the operation of a single radio interface the old IP and radio connection has to be torn down before setup of the new radio connection and an interruption time is inevitable (break-before-make handoff). But for mobile nodes supporting simultaneous radio transmission the handover sequence can be optimised by using multiple Care of Addresses to maintain communication seamlessly and losslessly throughout the handoff procedure (make-before-break handoff). In the ideal case, radio and IP connectivity are fully established and the impact of handoff execution is minimised to the change of the Binding Cache entry at the HA respectively the localised mobility agent (LMA). In client based mobility protocols the handoff sequence is fully controlled by the mobile node and the mobile node updates the binding update after IP connectivity has been established on the new link. On the contrary, Proxy Mobile IP aims to relieve the mobile node from the L3 mobility signalling, while the mobile node is still controlling the changing of the L2 configuration. This introduces a problem for HO optimisations using simultaneous radio transmission: According to the PMIP protocol [I-D.ietf-netlmm-proxymip6], the Access Authentication and the Proxy BU are triggered in the access network by the radio attach procedure, transparently for the MN. For a mobile node with simultaneous radio transmission this PMIP BU will disrupt the ability of the MN to communicate on the other interface during the IP configuration of the new interface. Figure 1 shows the interruption time that occurs in a PMIP handoff between interfaces with simultaneous radio capability. After the attachment of IF2 to the nMAG the LMA updates the Binding Cache and downlink packages will be inserted into the tunnel towards the nMAG. These packets can not be transmitted to the mobile node until it has finalised address configuration with Neighbourhood Advertisment to the nMAG. Depending on the RAT type, this may involve multiple roundtrips of signalling for configuration of the link. Even if the nMAG buffers the downlink packages until then there will be a perceivable delay in the packet flow. On the other hand, uplink packets the mobile node still sends on IF1 (not shown in figure 1) towards the pMAG will be rejected at the LMA because the binding has been replaced by the new binding with a different CoA. Blume & Sigle Expires Aug 21, 2008 [Page 6] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 Delaying the PBU of the nMAG to the LMA may seem to be a way to avoid the interruption of IP connectivity. In many cases the nMAG will be aware of the finalisation of IP connectivity in the mobile node (e.g. due to NAdv or 3GPP radio and S1 bearer setup complete message) and the nMAG might delay the PBU until this point in time. However, uplink packets from the new link on IF2 will get lost or need to be buffered in the nMAG because the mobile node is unaware of the Proxy Binding Update and may start sending IP packets to the nMAG before the Proxy Binding Update is finalised. This could only be avoided by signalling to the mobile node that the PBAck has been received at the nMAG, but such signalling is in contradiction to the aim of PMIP not to involve the mobile node in the mobility signalling. +------+ +----+ +----+ +---+ | MN | |pMAG| |nMAG| |LMA| +------+ +----+ +----+ +---+ IF2 IF1 | | | | | | | | | |- - - - - - - - - Attach | | | | |---------------PBU--------------->| | | |<--------------PBA----------------| | |--------RtSol------->| | | | |<-------RtAdv--------| | | | Addr. | | | | Conf. | | | | |<===================>|<=================data===========>|-- | | | | | |- - - - - - - - - - - - - - - - - Attach | | | | |----------PBU-------->| +--- | | | |<---------PBA---------| | |------RAT configuration--------------| | | | | |<=====data============|-- | | | | | | IP | | | |<=====data============|-- inter- | | | | | rupted |-----------RtSol(optional)---------->|<=====data============|-- | |<----------RtAdv---------------------| | | Addr. | | |<=====data============|-- | Conf. | | | | +--- | | | | | |<===================================>|<=====data===========>|-- | | | | | | |- - - - - - - - - Detach | | | | |---------------PBU(lifetime 0)--->| | | |<--------------PBA----------------| | | | | | Figure 1: Inter-RAT HO interruption during PMIP handoff Blume & Sigle Expires Aug 21, 2008 [Page 7] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 4.1. Secondary Binding Cache entries during PMIP handoff Therefore, as an optimisation for simultaneous radio handoffs this internet draft proposes a separation of the updating of the Binding Cache entry for uplink and downlink traffic. The change of the Binding Cache at the LMA is split into two steps before and after the setup of radio and IP connectivity between mobile node and nMAG. On the one hand, the LMA shall be able to accept uplink packets of the mobile node as soon as the mobile node has finalised address configuration and may start using the new IF2 for data traffic, i.e. the Proxy BU for the uplink shall be done before the radio setup procedure is finalised, as shown in figure 1. But, to allow the mobile to keep sending its data traffic on IF1 during the handover, UL packets with the previously existing binding on IF1 shall still be accepted by the LMA until the mobile node detaches IF1. This is important because the Proxy BU is transparent to the mobile node, i.e. the mobile node does not know when the BU has been performed. On the other hand, the switching of the downlink packets shall be performed at the LMA only after completion of the IP connectivity between mobile node and nMAG. How long this takes depends on the duration of target system radio layer protocols and this is transparent to the LMA. Thus, a second message to the LMA is required for the activation of the binding for the downlink traffic. Up to then, downlink packets are still routed into the previous tunnel to IF1, to avoid downlink packet loss or buffering in nMAG. As shown in figure 2, this is perceived by double signalling of the PBU from the nMAG to the LMA signalling. First a secondary PBU is indicated, used only for uplink traffic until a further PBU is requesting the switching of downlink traffic into the new PMIP tunnel. During this period it is up to the MN when to start using IF2 for uplink data. This handover sequence is only useful for handoff of mobile nodes with the capability of using simultaneous radio connectivity. If used for a single radio mobile node, the data sent to the pMAG after the secondary Proxy Binding update will be lost due to detachment of the radio link. (In some cases there may be additional mechanisms in place to forward data to nMAG to avoid the loss, but context transfer is required between pMAG and nMAG and still data is unnecessary delayed by this routing.) Only the MN can tell whether IF1 and IF2 are operated simultaneously: The nMAG is not aware of the state of the link on IF1. While the LMA does know about the binding of the link on IF1 it currently (section 5.4 of [I-D.ietf-netlmm-proxymip6]) cannot discriminate whether the new attachment is due to the beginning of a multihoming session of the MN or whether it is due to a simultaneous radio inter-RAT handoff. Therefore, the handoff between interfaces shall be performed as in figure 1, unless the mobile node indicates a simultaneous radio handoff during attachment with the nMAG, as with the extensions Blume & Sigle Expires Aug 21, 2008 [Page 8] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 described in section 5 of this internet draft. If the handoff type is unknown (as specified in PMIP [I-D.ietf-netlmm-proxymip6]), the LMA shall leave the binding of IF1 unchanged and assign a different home network prefix to the nMAG for IF2. +------+ +----+ +----+ +---+ | MN | |pMAG| |nMAG| |LMA| +------+ +----+ +----+ +---+ IF2 IF1 | | | | | | | | | |- - - - - - - - - Attach | | | | |---------------PBU--------------->| | | |<--------------PBA----------------| | |--------RtSol------->| | | | |<-------RtAdv--------| | | | Addr. | | | | Conf. | | | | |<====================|==================data===========>|-- | | | | | |- - - - - - - - - - - - - - - - Attach (simultaneous radio) | | | | |----PBU(secondary)--->| | | | |<---PBA(secondary)----| |------RAT configuration--------------| | | |<====================|==================data===========>|-- | | | | | |<====================|==================data===========>|-- | | | | | |-----------RtSol(optional)---------->| | |<----------RtAdv---------------------| | Addr. | | | | Conf |<====================|<=================data============|-- |====================================>|======data===========>|-- | | | | | |--------optional Trigger ----------->| | | | | |----------PBU-------->| | | | |<---------PBA---------| |<====================================|======data===========>|-- | | | | | | |- - - - - - --- - Detach | | | | |---------------PBU(lifetime 0)--->| | | |<--------------PBA----------------| | | | | | Figure 2: PMIP for make-before-break handoff. Blume & Sigle Expires Aug 21, 2008 [Page 9] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 The introduction of primary and secondary Binding Cache entries allows for a further improvement of make-before-break handoff with PMIP. During inter-RAT handoff the round trip time between mobile node and LMA can change significantly. For example the round trip time of 3GPP GSM is in the order of 150msec, while for IEEE WLAN it is in the order of a few milliseconds. Packets on the fly on a slow radio link may thus be overtaken by the handoff to a fast radio link and can arrive hundreds of milliseconds after the PBU, as has been experimentally verified [3]. As the binding chache entry has already been updated, these packets are dropped (Fig. 3). Such packet loss is avoided, if the second PBU in figure 2 does not delete the previous binding of the link on IF1, but turns this binding into a secondary binding, that is not used for downlink packets but allows for accepting delayed uplink packets. The secondary binding can be deleted after a timer runs out or when the pMAG signals detachment of this link in a PBU with lifetime 0. +------+ +----+ +---+ | MN | |nMAG| |LMA| +------+ +----+ +---+ IF2 IF1 | | | |\ | | | | \ | | |- -|- - - - \- - - - Attach | | | s\ |---------PBU--------->|primary binding | | l\ |<--------PBA----------|of IF2 | | o\ | | | | w\ | | | | d\ | | | | a\ | | | | t \ |packet still | | | a ->|accepted due to | | | |secondary binding | | | |of IF1 | | | | Figure 3: secondary binding for packets overtaken by PBU. 4.2. State diagamm with Secondary Binding Cache entries in PMIP Figure 4 shows the state diagramm of the Binding Cache entries that can exist in the LMA for one HNP of a MN with interfaces IF1 and IF2. The upper part shows the states as specified in PMIP [I-D.ietf- netlmm-proxymip6] with registration, BU refeshment, deregistration and BBM-handoff. Blume & Sigle Expires Aug 21, 2008 [Page 10] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 PBU(IF1,LT=0) +------------+ PBU(IF2,LT=0) +---------->| |<-----------+ | | no entry | | | +--------| |---------+ | BU(IF1,HI=5) | | +------------+ | | PBU(IF2,HI=5) +------+ | |PBU(IF1) PBU(IF2)| | +------+ | | | | | | | | | v | v v | v | | +----------------+ PBU(IF1,HI=2) +----------------+ | | | |<-----------------------| | | +--| IF1 (active) | <--BBM handoff--> | IF2 (active) |--+ | |----------------------->| | +----------------+ PBU(IF2,HI=2) +----------------+ | ^ | ^ | | | | | | | | | | <--MBB handoff--> | | | | | | | | | | PBU(IF2,HI=6) | |PBU(IF2,LT=0) PBU(IF1,HI=6)| |PBU(IF1,LT=0) | | | | v | v | +----------------+ PBU(IF1,HI=2) +----------------+ | |<-----------------------| | +--| IF1 (active) | | IF2 (active) |--+ | | IF2 (secondary)|----------------------->| IF1 (secondary)| | | +----------------+ PBU(IF2,HI=2) +----------------+ | | ^ ^ | | | | | +-----+ +-----+ PBU(IF1,HI=5) PBU(IF1,HI=5) PBU(IF2,HI=5) PBU(IF2,HI=5) Figure 4 State diagamm for Binding Cache entries of one HNP of a MN The lower shows the two new states that occur during a MBB handoff. If a MN with active binding of IF1 starts a MBB handoff to interface IF2, nMAG requests a secondary binding request for IF2 (handoff indicator is 6). After the IP configuration of IF2 is finalised, nMAG requests in a subsequent binding request (with handoff indicator 2) to turn the secondary binding for IF2 into an active binding, which starts tunneling of DL packets to IF2. LMA simultaneously degrades the binding of IF1 into a secondary binding, so that late UL-packets from IF1 are still accepted. Finally, at the dissociation of IF1 pMAG will send a PBU with lifetime 0 for IF1. The secondary binding for IF1 is deleted. Now the MBB handoff is finalised, Binding Cache entry is for IF2 and normal operation of PMIP is resumed. Blume & Sigle Expires Aug 21, 2008 [Page 11] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 4.3. Usage of Secondary Binding Cache entries in client MIP Secondary Binding Cache entries during radio setup can also be applied for handoff from client MIP binding to PMIP binding. During handoff from PMIP binding to client MIP binding secondary Binding Cache entries are not required during IP address configuration, because the mobile node is controlling the point in time when to send the BU and obviously will only do so after IP connectivity on IF2 is finalised. Nevertheless, secondary Binding Cache entries would be useful in client MIP for avoiding loss of packets overtaken by the BU. This would require to allow for secondary bindings also in Mobile IPv6 HA behaviour [RFC3775], without need of additional signalling between MN and HA (deletion of secondary binding can be done after a timer runs out or when a Binding Update with lifetime 0 for IF1 is received.) Blume & Sigle Expires Aug 21, 2008 [Page 12] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 5. PMIPv6 Extensions This section describes an extension to [I-D.ietf-netlmm-proxymip6] to solve the problem of packet loss due to missing synchronisation between MN and LMA, as resulting from the exclusion of the MN from mobility signalling in Proxy Mobile IP. The key extension is to introduce a secondary MN's Binding Cache entry that is not used for tunneling packets to the MN. Section 5.1 describes the extension for signalling between MAG and LMA that a MBB handover shall be executed. Section 5.2. describes Protocol Extension for Secondary Binding Cache Entries in the LMA. Finally, section 5.3. names issues for the MN but Protocol Extensions for the MN are out of scope of the current version of this internet draft. 5.1. Protocol Extension for signalling of MBB handoff capability When a PBU arrives at the LMA and there already exists a Binding Cache entry for the MN identifier contained in the PBU, a handoff procedure between interfaces needs to be executed at the LMA in three cases (according to [I-D.ietf-netlmm-proxymip6]): o if a NON_ZERO HNP value is present in the received proxy Binding Update message and this value matches the HNP in an existing Binding Cache Entry and the Handoff Indicator Option is set to value 2 (Handoff between interfaces) (see 5.4.1.1. in [I-D.ietf- netlmm-proxymip6]). [PBU(HNP) == BCE(HNP) AND HI=2] o if an ALL_ZERO HNP value is present in the received proxy Binding Update message and if an interface ID is present in the received proxy Binding Update message and there is no Binding Cache entry for that interface identifier and there exists one and only one currently active Binding Cache entry for the mobile node, and the Handoff Indicator Option is set to value 2 (Handoff between interfaces) (see 5.4.1.2. in [I-D.ietf- netlmm-proxymip6]). [PBU(HNP) == ALL_ZERO AND PBU(IF-ID) != BCE(IF-ID) AND exists_one_and_only_one(BCE) AND HI=2] o if an ALL_ZERO HNP value is present in the received proxy Binding Update message and if no interface ID is present in the received proxy Binding Update message and and there exists one and only one currently active Binding Cache entry for the mobile node, and the Handoff Indicator Option is set to value 2 (Handoff between interfaces) (see 5.4.1.3. in [I-D.ietf- netlmm-proxymip6]). [PBU(HNP) == ALL_ZERO AND PBU(IF-ID) == ALL_ZERO AND exists_one_and_only_one(BCE) AND HI=2] Blume & Sigle Expires Aug 21, 2008 [Page 13] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 Neither of these signalling options implies the simultaneous usage of the interfaces in the MN. Furthermore, this information cannot be taken from policy store, because the MBB ability may depend on the signal strength of the radio link between MN and pMAG and on the battery state of the MN. Thus, a make-before-break-handoff seqence acording to figure 2 MUST only be used if the MN has signalled in the radio attachment that IF1 and IF2 are used simultaneously during the handoff. Such MBB handoff hint requires according ammendments in the RAT standardisation, e.g. this could be perceived in the 3GPP RRC connection request [3GPP TS 25.331] as a new ESTABLISHMENT_CAUSE "Inter-RAT cell change withMBB". As another example, an "MBB- handoff"-reason code could be introduced into IEEE 802.11 MLME-associate.request (similar to the reason codes already used in the MLME-dissociate.request, see section 7.3.1.7. in [IEEE802.11]). When the MAG receives an attachment from a MN indicating a make- before-break-handoff, it shall send a secondary Proxy Binding Update request to the LMA. The secondary type of the Binding request could be indicated in two ways: o Assigning a new Indicator value in the Handoff Indicator Option The mandatory Handoff Indicator Option (section 8.4 in [I-D. ietf-netlmm-proxymip6] specifies the type of handoff. If IANA assigns a new value for "Handoff between interfaces with simultaneous operation" to the PMIP specification, this could be set by the MAG to indicate the MN's decison for a Make-Before- Break-handoff. o Specification of a new flag in the PBU request Alternatively a new "S"-Flag (simultaneous) could be specified for the PBU request (in addition to the "P"-Flag specified in section 8.1 in I-D.ietf-netlmm-proxymip6]). If the flag is set to one, this indicates both Interfaces operate simultaneously to perform a Make-before-Break-handoff execution. As the indication is closely related to the Handoff Indicator the former way is preferable to a flag in the PBU. 5.2. Protocol Extension for Secondary Binding Cache Entries Upon accepting of a Proxy Binding Update request with the MBB- indication of section 5.1 for a currently active binding entry the LMA SHALL create a Secondary Binding Cache Entry: o The LMA MUST create a binding chache entry for the new IF and MUST create a tunnel to the new mobile access gateway, as described in [RFC2473]. Blume & Sigle Expires Aug 21, 2008 [Page 14] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 o The LMA must assign the same HNP to this interface as is assigned to the currently active Binding Cache entry. o Instead of overwriting the previous Binding Cache entry and of deleting its tunnel to the pMAG after MinDelayBeforeBCEDelete wait period, the LMA SHALL keep the previous Binding Cache entry and mark the new Binding Cache entry as secondary. The LMA SHALL keep routing downlink traffic to the MN into the previously existing (primary) tunnel. The LMA SHALL continue to de- encapsulate and route the mobile nodes's uplink data traffic that arrives from that tunnel. o LMA MUST send a Proxy Binding Update Acknowledgement to the nMAG with the new Handoff Indicator value in the Handoff Indicator Option. From this nMAG learns that a secondary Binding Cache entry has been created and that nMAG MUST send a successive Proxy Binding Update request to turn this entry into primary. When the MN has completed address configuration (indicated to the nMAG by RAT specific L2 signalling, by a RAT specific timer in the nMAG, by transmission of a first IP packet or by other means) the o nMAG MUST send another Proxy Binding Update request to the LMA. The nMAG MUST NOT set the Handoff Indicator value to the new state (Handoff between interfaces with simultaneous operation), but MUST set it to state 2 (Handoff between two different interfaces of the mobile node). Upon reception of a successive Proxy Binding Update request with handoff indicator state 5 (Handoff state not changed (Re- registration) for which already a secondary Binding Cache entry exists : o the LMA MUST ignore this and leave the secondary Binding Cache entry and the tunnel routing unchanged. Upon accepting of the successive Proxy Binding Update request with handoff indicator state 2 (Handoff between two different interfaces of the mobile node) for which already a secondary Binding Cache entry exists the LMA switches the states of the Binding Cache entry: o the LMA MUST mark the previously secondary Binding Cache entry now as primary (active). It MUST route downlink traffic to the MN into the tunnel of this Binding Cache entry. o the LMA MUST mark the previously primary Binding Cache entry for the same MN's Home Network Prefix entry now as secondary Binding Cache entry. The LMA SHALL continue to route the mobile nodes's uplink data traffic that arrives from the tunnel of the secondary Binding Cache Entry. Blume & Sigle Expires Aug 21, 2008 [Page 15] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 When the MN detaches its connectivity to the pMAG, the pMAG SHALL send a Proxy Binding Update request with lifetime 0. When this arrives at the LMA for the now secondary Binding Cache entry or MinDelayBeforeBCEDelete amount of time after the successive Proxy Binding Update was received (whatever comes first) : o the LMA MUST remove the secondary Binding Cache entry and also delete the still existing tunnel. 5.3. Protocol Extension for the MN This internet draft focuses on extensions required in the MAG and in the LMA. It is out of the scope of the current version of this internet draft how the MN can perform address configuration of the IP addresses for the simultaneously attached interfaces. This issue is not specific for the MBB handoff from IF1 to IF2 with secondary Binding Cache entries, but already occurs in a BBM handoff for any of the three case described above in section in 5.1. PMIP [I-D. ietf-netlmm-proxymip6] specifies in these cases that LMA MUST assigne the same HNP as previously assigned to the pMAG. But still this may lead to a change of the IP address of the MN. For example, if stateless address autoconfiguration is used, the MN will configure a new IP address using the MAC address of the IF2 which will usually be different from the MAC address of IF 1. It is ffs how the MN can assure continuation of the ongoing IP sessions with its corresponding nodes. A further issues specific to the MBB handoff is related to the question whether the MN can handle the same IP address for both interfaces simultaneously during the MBB handoff or whether the MN is required to operate a shim layer between the IP layer and the L2 interfaces to hide the change of the interface from the IP stack. Blume & Sigle Expires Aug 21, 2008 [Page 16] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 6. Security Considerations Protocol extensions according to this internet draft do not change the security requirements of Proxy Mobile IP. Signaling between MAGs and LMAs as well as information carried by PBU and PBA messages is protected and authenticated according to the mechanisms described in [I-D.ietf-netlmm-proxymip6]. Blume & Sigle Expires Aug 21, 2008 [Page 17] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 7. IANA Considerations This documents introduces a new value to the Handoff Indicator Option in section 8.4 of [I-D.ietf-netlmm-proxymip6]. These values will be allocated and managed by IANA. Blume & Sigle Expires Aug 21, 2008 [Page 18] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 8. Acknowledgement The autors would like to thank Kuntal Chowdhury for his encouraging support of the idea, a detailed review and for fruitful discussions. 9. References 9.1 Normative References [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 (work in progress), February 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC2473] IETF Network Working Group, Conta, A., Deering S. "Generic Packet Tunneling in IPv6. Specification" December 1998 [3GPP TS 25.331] 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; "Radio Resource Control (RRC) Protocol Specification", Technical Specification 3GPP TS 25.331 V8.1.0 (2007-12) [IEEE802.11] ANSI/IEEE Std 802.11, "Local and metropolitan area networks - Specific requirements. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1999 9.2 Informative Reference [1] S2-074410 "Seamless Inter-technology Handover with simultaneous radio support", Alcatel-Lucent. 3GPP TSG SA WG2 Architecture, meeting S2#60, Kobe Oct. 2007 [2] "Inter-Technology Handover for Proxy MIPv6", M. Liebsch, L. Le. Internet-Draft draft-liebsch-netlmm-intertech-proxymip6ho-00.txt IETF NetLMM, Nov. 2007, work in progress [3] Measurements of packet arrival time and packet loss with OWPing tool in a testbed setup with multi-radio MN using 3GPP HSDPA and IEEE WLAN radio interfaces and Mobile IPv6 as handoff protocol. Alcatel-Lucent, 2007, unpublished results Blume & Sigle Expires Aug 21, 2008 [Page 19] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 Authors' Addresses Oliver Blume Alcatel-Lucent Deutschland AG Bell Labs Lorenzstr. 10 70435 Stuttgart Germany Phone: +49 711 821-47177 Email: oliver.blume@alcatel-lucent.de Rolf Sigle Alcatel-Lucent Deutschland AG Bell Labs Lorenzstr. 10 70435 Stuttgart Germany Phone: +49 711 821-36609 Email: rolf.sigle@alcatel-lucent.de Blume & Sigle Expires Aug 21, 2008 [Page 20] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007 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 ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Blume & Sigle Expires Aug 21, 2008 [Page 21]