First part : UHMMA protocol 1 overview of UHMMA 1.1 basic operation 1.2 packet format 1.3 lifetime / refresh rate 1.4 sequence number 1.5 data structures 2 new sub-options 2.1 mobility support sub-option in binding update destination option 2.2 home agent sub-option in home address destination option 2.3 VCOA sub-option in binding acknowledgement destination option 3 new flags in binding update destination option 3.1 E flag 3.2 P flag 4 requirements for nodes 4.1 for mobility support 4.2 for mobile 4.3 for correspondent / home agent 5 mobility support operations 5.1 receiving registration packet 5.2 receiving old position packet 5.3 sending binding acknowledgement to the mobile 5.4 sending binding update to the home agent 5.5 sending binding update to the correspondent 5.6 managing VCOA 5.7 managing the mobile list 6 mobile operations 6.1 sending registration packet 6.2 receiving binding acknowledgement from home agent 6.3 receiving binding acknowledgement from mobility support 6.4 movement detection 6.5 previous mobility support 6.6 sequence counter Second part : micro mobile IP 1 overview 1.1 basic operation 1.2 correspondent list 1.3 smooth handoff 1.4 flipping MIP mode / UHMMA mode 1.5 packet format 2 new options 2.1 mobility agent announce destination option 2.2 correspondent list sub-option 3 new flags in binding update option 3.1 S flag 3.2 F flag 4 requirements for nodes 4.1 for mobility agent 4.2 for mobile 5 mobility agent operations 5.1 receiving registration packet 5.2 sending smooth handoff packet 5.3 receiving smooth handoff packet 5.4 receiving smooth handoff acknowledgement 5.5 learning new correspondent 5.6 intercepting BR 6 mobile operations 6.1 sending smooth handoff packet 6.2 sending registration packet 6.3 receiving smooth handoff acknowledgement --------------------------------------------------------------------- ********************************************************************* ********************************************************************* --------------------------------------------------------------------- First part : UHMMA protocol 1 overview of UHMMA The UHMMA protocol is used by the mobile to perform a registration. A site must deploy a mobility support to allow the mobile to use UHMMA. A mechanism must be used to communicate the mobility support's address to the new mobile (DHCP, router advertisement). 1.1 basic operation - the mobile moves, - it detects the local mobility support address by using DHCP, router advertisement, ... (depends on the micro mobility scheme). - it sends a registration packet to this mobility support, - it waits for binding acknowledgment. It should retransmit its registration until it receives the matching acknowledgment. - periodically the mobile must send old position packet to the mobility support. Without this packet, the mobility support will stop managing the mobile's mobility. 1.2 packet format The registration packet has a fixed format. It must contain the PCOA, the home address, the home agent's address and the old mobility support's address. The old mobility support was the mobility support in the previous site. The packet is built with a binding update option and a home address option. We add two new sub-options to include the mobility support's address and the home agent's address. The mobility support sub-option is included in the binding update option and the home agent sub-option in the home address option. The old position packet is a Mobile IPv6 binding update. The binding acknowledgement sent by the mobility support to the mobile may contain a VCOA sub-option. There is a VCOA sub-option only for the first mobile registration in a site. The mobility support builds a VCOA and transmits it to the mobile by using the binding acknowledgement. If a mobile moves inside a site, it keeps the same VCOA. So the binding acknowledgement for its later movements does not contain VCOA sub-option. The binding acknowledgement sent by the home agent is a standard binding acknowledgement. 1.3 lifetime / refresh rate The mobile indicates the time it needs to be managed by the mobility support by using the lifetime field in the binding update option of the registration packet. The mobile should send old destination packet to the mobility support to increase the lifetime. The mobility support returns a refresh rate to the mobile by using the refresh field in the binding acknowledgement. The mobile should use it to periodically send old position packet. 1.4 sequence number The sequence number field in the binding update and in the binding acknowledgement are used like in Mobile IPv6. - a binding acknowledgement must have the same sequence number that the registration packet. - the mobility support memorizes the last sequence number for each mobile. If it receives a packet with a sequence number smaller that the last saved number, the packet is dropped. 1.5 data structures The mobile must memorize : - some addresses : its home agent's address, the local mobility support's address, the last mobility support's address - a sequence counter ; the value of this counter is put in the sequence number field of a registration packet and of an old position packet. - a lifetime ; this lifetime is set in the lifetime field of the registration packet. The mobility support manages the mobile during a time equal to this lifetime. This lifetime should be initialized when the mobile boots. The mobile's user should change this value by using a configuration file or a command. - a rate ; this rate is read in the mobility support binding acknowledgement and used to periodically send old position packets. 2 new sub-options 2.1 mobility support sub-option in binding update destination option This sub-option is used to built the UHMMA's registration packet. It is inserted in the sub-option field of the binding update. mobility support sub-option format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobility Support's Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type = we choose 102. length = length of the sub-option in bytes, excluding the type and the length field. This field must contain 18. Mobility Support's Address = this is the address of the mobility support in the previous site the mobile visited. If the mobile moves from its home network, it does not have a previous mobility support, so the field contains the unspecified address. 2.2 home agent sub-option in home address destination option This sub-option is used to built the UHMMA's registration packet. It is inserted in the sub-option field of the home address destination option. home agent sub-option format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Agent's Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type = we choose 103. length = length of the sub-option in bytes, excluding the type and the length field. This field must be 18. Home Agent's Address = the address of the mobile's home agent. This address is used by the mobility support to send binding update to register the mobile. 2.3 VCOA sub-option in binding acknowledgement destination option This sub-option is used to communicate the VCOA built by the mobility support to the mobile. It is inserted in the binding acknowledgement. VCOA sub-option format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Virtual Care of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type = we choose 101. length = length of the sub-option in bytes, excluding the type and the length field. This field must be 18. Virtual Care of Address = the virtual address built by the mobility support for the mobile. This address must be set to the default network interface. Without this address, the mobile is not able to receive forwarded packets by the mobility support. 3 new flags in binding update destination option 3.1 E flag The mobile asks the mobility support to send no binding update to the correspondents by setting the E flag in the binding update option of the registration packet. The correspondents join the mobile using it home address. The home agent redirects all the packets from the correspondent. 3.2 P flag A mobile must send periodically old position packet to its mobility support. The mobility support deals with the mobility of a mobile during a time equal to the lifetime field of the registration packet. The mobility support starts a timer for each mobile. If a timer expires the mobility support should stop managing the mobile. An old position packet resets the timer. An old position packet is a binding update (i.e. binding update option and home address option). We just add the P flag in order to be different of standard binding update. The mobile sends old position packet periodically. The periodicity is read in the refresh field of the binding acknowledgement sent by the mobility support. 4 requirements for nodes 4.1 for mobility support The mobility support must be able to : - register a mobile (i.e. manage a list of mobile) - build / manage VCOA - send binding update to the mobile correspondents - learn mobile correspondents - intercept packets sent to VCOA and redirect to PCOA - intercept binding requests and drop them 4.2 for mobile The mobile must be able to : - detect inter site and intra site movement - discover and memorize mobility support's address - register to the mobility support, and send old position packet - run Mobile IP and / or UHMMA 4.3 for correspondent / home agent The correspondent is a Mobile IPv6 correspondent. 5 mobility support operations 5.1 receiving registration packet There is several cases of recording. We will index all these cases by using an algorithm. The registration packet contains home address / home agent / PCOA / previous mobility support. We will note the packet by pkt. Each information of this package will be noted pkt.home agent, pkt.PCOA... We indicate the list of the mobile managed by listMH, an element of this list will be represented by listMH(MH1). A field of a mobile of the list will be noted listMH(MH1).VCOA The very first step for the mobility support is to check if address PCOA is an authorized address, i.e. an address of the site. If it is not the case, the request must be dropped. for all x if pkt.home address == listMH(x).home address then the mobile is already registered. if listMH(x).PCOA == pkt.PCOA then the mobile resends a registration packet. An other packet was received and the mobile was registered. But the mobile does not received the binding acknowledgements it is waiting for. The mobility support must determine the kind of mobility the mobile performed. if pkt.MAold == local mobility agent then the mobile performed a micro mobility movement (1) else macro mobility movement (2) if listeMH(x).PCOA != pkt.PCOA then the mobile performed an intra site movement, it communicates its new PCOA (3) for all x if pkt.home address != listMH(x).home address then the mobile comes from an other site if pkt.MAold == unspecified address then the mobile comes from its home network (4) else if pkt.home address == pkt.PCOA then the mobile is going to its home network. (5) else the mobile is coming from an other site. (6) (1) the mobility support acknowledges the mobile by sending a binding acknowledgement. The lost binding acknowledgement must be the mobility support's one because no binding update was sent to the home agent because the mobile performed an intra site movement. (2) the mobility support acknowledges the mobile by sending a binding acknowledgement with the VCOA in a VCOA sub-option. We could not determine the lost binding acknowledgement, therefore both are re-emitted. To cause the sending of a binding acknowledgement by the home agent, mobility support sends it a home registration (a binding update VCOA/home address). (3) the mobility support modifies its mobile list to memorize the new PCOA of the mobile. This address is read in the source field of the registration packet. The mobility support acknowledges the mobile by sending a simple binding acknowledgement, the VCOA is not sent because unchanged. (4) the mobility support creates an input in its mobile list for the new mobile and affects it a VCOA. It acknowledges the mobile by sending a binding acknowledgement and a VCOA sub-option. It sends a binding update (home registration) to the home agent, this binding contains the C flag and the VCOA in the Care-of address field. (5) (6) This case are not described here. They depend on the macro mobility scheme. If something goes wrong during the registration process, the mobility support must send a binding acknowledgement with the status field initialized with the kind of error. 5.2 receiving old position packet The mobility support decodes the lifetime field and restarts the timer for the mobile with a time counter equal to the value of this lifetime. 5.3 sending binding acknowledgement to the mobile The mobility support must acknowledge the mobile for its registration. According to the type of mobility (intra site or inter site movement) the mobility support must build a VCOA for the mobile and send it by adding it in the binding acknowledgement. The VCOA is built and sent the very first time that the mobile arrives in the site. Then the VCOA does not change anymore. If something goes wrong during the registration operation, the mobility support must send a binding acknowledgement with the status field initialized with the kind of error. We use the Mobile IPv6 error status and add a new one : 138 receiver is not a mobility support 5.4 sending binding update to the home agent A mobile arrives in the site. It sends a registration packet to the mobility support. The mobility support builds a VCOA and sends a binding acknowledgement with the VCOA in sub-option to the mobile. Then it sends a binding update to the home agent to communicate the new position of the mobile to him. This binding contains a C flag and the VCOA in the field Care-of address. The sequence number of this first binding must be 1. The lifetime field should contain the default lifetime for a binding. This packet is a home registration binding update, so the AH flags must be set. The mobility support must send periodically a new binding update to the home agent. The format is the same that the first, and the sequence number is incremented each time. 5.5 sending binding update to the correspondent The mobility support must able to send binding update for the mobile's correspondent. It uses a timer for each correspondent. Each time a timeout expires, the mobility support should sends the correspondent a binding update with the C flag and the VCOA in the Care-of address field. 5.6 managing VCOA The ms is a router. One of its interface network should be connected on a virtual network. This network should not contain any physical machine. The VCOA will be the addresses of this network. A VCOA will be built by using the virtual network's prefix and the EUI64 of the mobile's interface network. The EUI64 is deduced from the PCOA of the mobile. The PCOA is in the source field of the registration packet. 5.7 managing the mobile list The mobility support manages a mobile list. Each record in this list contains : - some addresses : PCOA, VCOA, home address, home agent's address - a correspondents list - a timer - a sequence counter - a refresh rate - a lifetime * The timer is started when the mobile sends its first registration packet. It is restarted for each old position packet received. If the timer expires, the mobile mobility is no longer manages by the mobility support. The mobility support should remove the mobile record of its list. * The sequence counter is used to back up the last sequence number received in a registration packet or an old position packet. If a registration packet or an old position packet is received with a sequence number field smaller than the sequence counter, the packet is dropped. * The refresh rate is the default rate sent to the mobile in the binding acknowledgement. The mobile should send old position packet periodically by using this rate. * The lifetime is the time during the mobility support manages the mobile's mobility. This value is read in the lifetime field of the registration packet. It is used to initialize the timer. Each correspondent is a record in the correspondent list. A record contains : - the correspondent address - some flags (AH for the home agent) - a timer - a lifetime * The timer is used to schedule the binding update retransmission. Each time the timer expires, the mobility support sends a binding update to the correspondent. This binding contains the C flag and the VCOA in the Care-of address field. * The lifetime is the default lifetime for a binding. This value is put in the lifetime field of the binding update packet. The correspondent will maintain the binding in its cache a time equal to this lifetime. The mobility support creates the mobile record when it receives the first registration packet. It builds the home agent record for this mobile, and stores it in the corespondent list. 6 mobile operations 6.1 sending registration packet The packet is built like shown in section 1.2 The mobile must be able to determine the kind of movement it performed. For an intra site movement, the mobile will receive only one acknowledgement, it will come from the mobility support. For an inter site movement, the mobile will receive two acknowledgements. One from the mobility support (with a VCOA sub-option) and one from the home agent. The mobile resends a registration packet until it receives the matching acknowledgements. 6.2 receiving binding acknowledgement from home agent The home agent acknowledgement is not checked, it is always accepted. 6.3 receiving binding acknowledgement from mobility support There are two different mobility support acknowledgements. The first one is a binding acknowledgement to acknowledge an intra site movement. This is a classical binding acknowledgement. The sequence number field must contain the same value that the registration packet. If its not the case, the binding acknowledgement is dropped. The second one is a binding acknowledgement to acknowledge an inter site movement. This is a classical binding acknowledgement plus an VCOA sub-option. If the sequence number is valid, the VCOA must be decoded and put on the network interface. When the mobile receives the matching acknowledgements, it backs up the address of the local mobility support as last mobility support's address. If the mobile comes back on its home network, it backs up the unspecified address. 6.4 movement detection The mobile may determine the king of movement by comparing the address of the local mobility support and the address of the last mobility support. If the addresses are the same, the movement was an intra site movement. 6.5 previous mobility support The mobile memorizes the address of the previous mobility support. This address is set in the registration packet, in a sub-option of the binding update. The local mobility support may use this address to communicate with the previous mobility support. When the mobile is on its home network, it does not need a mobility support to manage its mobility. The address must be the unspecified address. When the mobile arrives in a new site, it discovers the mobility support address and sends it a registration packet. When the mobile receives the matching acknowledgements, it backs up the address of the local mobility support as previous mobility support's address. If the mobile comes back on its home network, it backs up the unspecified address. 6.6 sequence counter The mobile uses a counter to store the sequence number. When it is on his home network the counter is set to 0. When it moves outside this network, the mobile sends a registration packet and the counter is set to 1. For each old position packet or registration packet sent, the counter is incremented by 1 and copied in the sequence number field of the packet. When the mobile is back on its home network, the counter is reset to 0. ------------------------------------------------------------------------- ------------------------------------------------------------------------- Second part : micro mobile IP 1 overview Micro Mobile IP manages the mobility into a site. The mobility support becomes the Mobility Agent, mobility agent. The role of the mobility agent is to manage the mobility of the mobile in visit in its site. For each recorded mobile, the mobility agent manages a list of correspondents. It sends binding updates to this correspondents. The mobility agent manages these lists in a dynamic way. It is able to learn from new correspondents. The protocol used between correspondent and mobility agent is Mobile IPv6. There will be no modification to the correspondent. The protocol used between mobility agent and mobile is UHMMA. The mobility agent intercepts all the packets for the mobiles. The packets are encapsulated and directed towards the corresponding PCOA. In certain cases, other actions are to be performed. They relate to the management of correspondent, we will describe them further. 1.1 basic operation After a move a mobile sends a registration packet to the local mobility agent. The packet contains its home address, home agent' address, PCOA and previous mobility agent's address. The mobility agent must determine the type of movement : inter site or intra site. It compares the previous mobility agent's address and its own address. According to the type of mobility, binding update will be sent towards the correspondent. The mobility agent must send a binding home address / PCOA to local correspondents and a binding home address / VCOA to the external correspondents. All binding contain the C flag, and an address in the Care-of address field. This address is the PCOA or the VCOA. The mobility agent sends a binding acknowledgement to the mobile (with the VCOA if the mobile has just arrived in the site). 1.2 correspondent list 1.3 smooth handoff The smooth handoff is the operation witch transfer the correspondent list from a mobility agent to another. Example : A mobile M is on a site S1. Its mobility is managed by the mobility agent of S1, MA1. M is joined by using VCOA1. Its physical address is PCOA1. M moves to a new site, S2. It registers to the local mobility agent, MA2. It gets its physical address PCOA2 and its virtual address VCOA2. The registration packet contains PCOA2, home address, home agent's address and MA1's address. MA2 send a smooth handoff packet to S1. It resends this packet until it receives the matching acknowledgement. The smooth handoff packet is a binding update. It is composed of a binding update option and a home address option. The C flag of the binding is set, and the Care-of address field contains the new mobile VCOA, VCOA2. MA1 receives the packet. It builds and sends the acknowledgement to MA2. This acknowledgement contains the correspondent list of M. MA1 must forward the packets with VCOA1 destination to VCOA2. MA1 performs this forwarding during a time equal to the lifetime field of the smooth handoff packet. 1.4 flipping MIP mode / UHMMA mode A mobile must able to run Mobile IPv6 and UHMMA, and to switch between this modes. UHMMA -> Mobile IPv6 : The mobile runs UHMMA and needs to switch to Mobile IPv6 mode. Its correspondent list is in the last mobility support which managed it (If the mobile just goes out of its home network, there is no list, so nothing to do). The mobile sends a smooth handoff packet to its last mobility support. The Care-of address field contains the mobile's PCOA, there is no VCOA in Mobile IPv6. This mobility support receives the packet and does the same thing that for a standard smooth handoff. Its builds and sends the acknowledgement to the smooth handoff sender (i.e. the mobile). This acknowledgement contains the correspondent list. The mobility support will forward the packets with old VCOA destination to the new mobile position. Mobile IPv6 -> UHMMA The mobile runs Mobile Ipv6. It manages its correspondent list itself. It needs to switch in UHMMA mode, so it has to transfer the list to the local mobility agent. The mobile builds a UHMMA registration packet and adds it a correspondent list sub-option. The sub-option is put in the sub-option field of the binding update destination option. The mobility agent receives the packet. Its creates a record for this mobile in its mobile list and stores the correspondent list. It must send a binding update to all the correspondents to register the new position of the mobile (PCOA for the local correspondents, VCOA for the external). When the mobiles receives the acknowledgement from the mobility agent it should remove its correspondent list. 1.5 packet format The smooth handoff packet is composed : - a binding update destination option with the S flag and the C flag, the VCOA in the Care-of address field. - a home address option. The smooth handoff acknowledgement is a Mobile IP binding acknowledgement plus a correspondent list sub-option. The correspondent list sub-option is described bellow. 2 new options 2.1 mobility agent announce destination option The mobility agent emits an advertisement periodically containing its address. This advertisement is sent to certain routers of the sites. These routers are the routers of networks able to be attachment of mobile in visit. This advertisement will be a new destination IPv6 option: mobility agent announces. Mobility agent destination option format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobility Agent Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type = the type of the destination option, we propose xxx. length = option length in bytes without type and length field, this field must contain 24. mobility agent address = the mobility agent address. 2.2 correspondent list sub-option This new sub-option is used to transfer the correspondent list of a mobile from a mobility agent to another. It is inserted in the sub-option field of the binding acknowledgement. Correspondent list Sub-option format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + mobile home address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CH1 flags | prefix length | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + correspondent 1 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CH2 flags | prefix length | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + correspondent 2 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type = we propose 104. length = the length field must contain the length of the sub-option, excluding the type and the length field. The length is equal to 18 + 20 per correspondent. mobile home address = the home address of the mobile. CH1 flags = the correspondent flags. prefix length = the length of the correspondent prefix. sequence number = the last sequence number used to send binding update to this correspondent. correspondent address = the address of the correspondent. 3 new flags in binding update option 3.1 S flag The S flag is used to differentiate smooth handoff packets of the Mobile IP binding update packets. 3.2 F flag 4 requirements for nodes 4.1 for mobility agent 4.2 for mobile 5 mobility agent operation 5.1 receiving registration packet We already have seen what the mobility agent (mobility support) should do when it receives registration packets in the section 5.1 of the UHMMA protocol. There are one case not seen yet. The sub-option mobility support contains an address that it is not the unspecified address and not the local mobility support address. The mobile arrives in a site from another. The mobility agent have send a smooth handoff packet to the previous mobility agent. The sequence number of the registration packet is copied in the sequence number field of the smooth handoff packet. The lifetime of the registration packet is copied in the smooth handoff packet too. This lifetime will be used to forward packet from old position to news one by the previous mobility agent. The mobility agent resends a smooth handoff packet until it receives the matching acknowledgements. - if the field Care-of address in the registration packet contains the home address, the mobiles comes back on its home network. The mobility agent must not create a record for this mobile in its mobile list. - if the field Care-of address in the registration packet does not contain the home address, the mobility agent must create a record for this mobile in its mobile list. - if something goes wrong during the smooth handoff process, the mobility agent must send a binding acknowledgement with the error in the status field to the mobile. 5.2 sending smooth handoff packet c.f. section 5.1 5.3 receiving smooth handoff packet The mobility agent decodes the packet and first checks the sequence number field. It compares it with the sequence counter of its mobile list. It the sequence number is smaller the smooth handoff is dropped. The PCOA field of the mobile record in the mobile list is initialized with the address read in the Care-of address field of the smooth handoff packet. The mobile timer is restarted with a time equal to the lifetime field of the smooth handoff packet. The mobile is no longer in the site, its sends no more old position packet. The timer will expire and the mobility agent will remove the mobile record from its list. - if the Care-of address field contains the home address of the mobile, it means that the mobile is back on its home network. The mobility agent have to send a binding update (home address / home address) to all the correspondents. It must acknowledge the sender with a standard binding acknowledgement. - if the Care-of address field does not contain the home address, the mobility agent builds and sends a smooth handoff acknowledgement like seen in section 1.5. The correspondents list of the mobile is copied in the correspondent list sub-option. - if something goes wrong during the smooth handoff process, the mobility agent must send a binding acknowledgement with the error in the status field to the sender. The sender is a mobility agent too, it will retransmit the status to the mobile. 5.4 receiving smooth handoff acknowledgement The sequence number of the acknowledge must be the same that in the smooth handoff packet. - if the status of the packet is not 0 ("accepted"), the mobility agent must build a binding acknowledgement with the same status and send it to the mobile. - if the acknowledgement contains a correspondent list sub-option, the mobility agent must copied all the list in the mobile record in the mobile list. The mobile is identified by using its home address. A binding update must be sent to all the correspondents. The local correspondents will receive a binding home address / PCOA, and the external correspondents a binding home address / VCOA. - if there is no sub-option, the mobile comes back on its home network, nothing to do here. 5.5 learning new correspondent The mobility agent intercepts and forwards all packets with VCOA destination to the PCOA. Some of this packets may be encapsulated packets. This packets come from a correspondent which does not yet know the new position of the mobile. The mobility agent must forward this packets and send a binding update to the correspondent. The binding update must be home address / PCOA for a local correspondent or home address / VCOA for an external correspondent. 5.6 intercepting BR The mobile will not accept any binding request, so the mobility agent may intercept and dropped binding request with VCOA destination. To prevent local correspondents to send binding request direct to the PCOA, the mobility agent should send binding update to the local correspondent with a small refresh rate. 6 mobile operation 6.1 sending smooth handoff packet The mobile runs UHMMA and needs to switch in Mobile IPv6 mode. It builds a smooth handoff packet (a binding update option and a home address option) and sends it to its last mobility agent. The address of this mobility agent has been backed up in a local variable (c.f. section 1.5, UHMMA protocol). The sequence counter is incremented and used to fill the sequence number filed in the smooth handoff packet. The mobile resends this packet until its receives the acknowledgement. 6.2 sending registration packet The mobile needs to switch in UHMMA mode. It must transfer its correspondent list to the mobility agent it want to register. The list is used to fill in a correspondent list sub-option. This sub-option is added in the sub-option field of the binding update of the registration packet, following the mobility support sub-option. 6.3 receiving smooth handoff acknowledgement The mobile receives a smooth handoff acknowledgement when it switches from the UHMMA mode to the Mobile IP mode. It sends a smooth handoff packet to its last mobility agent to get back its correspondent list. The list is in the sub-option of the binding acknowledgement. The mobile have to copy this its in its own list, and to send binding update to all the correspondent.