Standards Track S. Faccin Internet Draft B. Patil Document: draft-sreeman-enhance-beth-ipv6-00.txt R. Purnadi Expires: March 2002 S. Sreemanthula September 2001 Nokia Enhancements to Bi-directional Edge Tunnel Handover for IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This is an individual draft for consideration by the Mobile IP Working Group. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses enhancements to the Bi-directional Edge Tunnel Handover for IPv6 protocol described in draft-kempf-beth-ipv6-02.txt. Such draft proposes the use of bi-directional edge tunnels and deferred Care of Address establishment to eliminate L3 signaling during handover, thereby achieving a rapid and efficient handover mechanism. The proposal in the present draft offers some improvements to the draft-kempf-beth-ipv6-02.txt in several respects. It proposes an enhanced negotiation during the tunnel establishment to allow tunnel lifetime negotiation based on policies, the indication of one-time only tunnels and an explicit acknowledgement from Mobile Node to indicate the successful completion of L3 switching. In addition, it proposes a mechanism to force the mobile node to obtain a new Care of Address as and when determined by the Access Routers according to policies used by the network. Also, we propose to enhance the mechanism for subsequent handovers (Handoff to Third) by providing a means to allow "chained" tunnels instead of anchored tunnels. Faccin, Patil, Purnadi, Sreemanthula [Page 1] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 Table of Contents 1. Introduction ....................................................2 1.1. Terminology ...................................................4 1.2. Standards Language ............................................5 2. Protocol Behavior ...............................................6 2.1. BET Lifetime and BET Renewal Negotiation ......................6 2.2. PrRtrAdv from nAR .............................................6 2.3. Chain Tunneling ...............................................7 2.4. MN Acknowledgement after Adopting nCoA ........................9 2.5. PrRtrAdv from oAR .............................................9 3. Application Scenarios ...........................................10 3.1. Tunnel Negotiation ............................................10 3.2. Chain Tunneling ...............................................11 3.3. MN Acknowledgement after Adopting nCoA ........................14 3.4. PrRtrAdv from oAR .............................................15 4. Conclusions .....................................................15 5. References ......................................................16 6. Authors' addresses ..............................................16 1. Introduction It can be easily assumed that different IP networks will have different network policies regarding several aspects, e.g. policies on QoS, on access control for roaming nodes, and in case several options exist for a given mobility mechanisms (e.g. Fast Handoff, BETH, etc.) policies on what mechanism is to be used in a given network. While some policies are statically configured by the service provider and may need to be seldom changed, others can be a function of several parameters such as dynamic traffic load conditions, service level agreements, etc. In the simplest case, the ARs interacting with each other and belonging to the same domain are likely to have the same or very similar policies set by the service provider. However, it is possible that different ARs in the same domain can be provided with different policies based on the traffic load or other factors. In other cases, ARs may belong to different domains where the network policies may be different. In such cases, negotiation of some parameters may be needed as a way of respecting each other's policies. Currently, the lifetime for the BET tunnel is determined always by the anchor AR. In the presence of different policies in the old and new AR, it would be beneficial to be able to perform a negotiation of the tunnel lifetime between the new and old AR. Moreover, we propose the adoption of a tunnel renewal option during the negotiation to indicate whether or not the tunnel can be renewed after the lifetime expires. If the tunnel cannot be renewed, according to draft- kempf-beth-ipv6-02.txt the nAR will request the MN to get a new CoA before the tunnel expires. The same can be achieved by the two ARs trying to renew the tunnel and by one of them indicating that it is not possible. However, although this should still be possible, if one of the two ARs knows at the time of the tunnel establishment that the tunnel should not be renewed (based on local policies), it is more efficient to indicate this at that time. Faccin, Patil, Purnadi, Sreemanthula [Page 2] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 In draft-kempf-beth-ipv6-02.txt, after the completion of the L2 handoff procedure, the MN may start to receive the RtrAdv from the new AR. However, according to the current specifications, the MN is not required to create a new CoA when it receives a RtrAdv with a different network prefix (MN already has a CoA and has reachability to the old AR). The MN can, therefore, continue to use the old CoA and the tunnels formed using BETH procedure. According to the current specifications, the network can request the MN to obtain a new CoA in some specific conditions (e.g. if the tunnel cannot be renewed). In addition to the reasons described, we propose that the either the new AR (nAR) or the old AR (oAR) should be able to "force" the MN to obtain a new CoA after the BETH procedure is completed based on policies established either in the nAR or the oAR. This enhancement will give the flexibility to the oAR and the nAR to optimize the routing of packets to/from the MN according to its local policies to provide QoS or to perform load sharing. Moreover, this would allow for a smoother integration of domains supporting BETH and domain supporting other mechanisms. According to the current proposal, once the (BET) tunnels are established they can be torn down only automatically at the expiry of the lifetime. An optimized way to save the resources would be to tear down the tunnel when it is not required anymore. In fact, a MN may have started to use the new CoA sometime before the expiration of the tunnel and, if QoS has been established in such a way that resources are actually allocated for the tunnel and cannot be used for other traffic, it would be beneficial to release the tunnel as soon as possible. The focus of the BET handover procedure is to provide a L2 connection to the MN and delay the establishment of the nCoA until the realtime traffic subsides or MN movement is slow enough to obtain a new CoA. The implication of this objective is to continue to anchor the BET at the aAR while the MN moves quickly from one AR to another AR until a nCoA is obtained. This kind of mechanism requires that the (BET) tunnels be established between any set of ARs within or across different networks and the tunnels must be capable of handling the QoS required for the MN traffic. In some domains, based on the service provider decisions on how to provide QoS and manage IP traffic, this requirement may introduce some issues (e.g. QoS negotiations may have to take place during BET establishment thus introducing some latency). In this draft, in the Handoff to Third case, a new tunnel is added to connect the latest serving AR (oAR) to the target AR (nAR), instead of connecting the anchor AR (aAR) directly to the nAR. This enhancement allows some domains to "pre-allocate" the QoS supported for BETs between each AR to the Physically Adjacent ARs (PAARs) to support handoff. In a time critical radio handoff that requires bi-directional tunneling between ARs, "pre-allocated" QoS promotes faster handoff without need for QoS negotiation. The current BET scheme may require in some domains complex QoS predefinition among each AR to all ARs in the serving network to which the MN can move to while maintaining anchored BETs, or may require QoS negotiation between aAR and nAR. Although chained tunnels may lead to some issues, e.g. number of tunnels and state information kept by several ARs, when considered together with the ability of ARs to "force" the MN to form a new CoA, long tunnel chains can be avoided. Faccin, Patil, Purnadi, Sreemanthula [Page 3] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 We discuss these as a set of enhancements to the BETH handover model to provide flexible and optimized solutions in view of the network policies. Each of the enhancements can be individually evaluated and applied as extensions to the BETH proposal. 1.1. Terminology This section introduces some terminology used throughout the draft. oAR - old Access Router, the AR involved in handling a MN's traffic prior to an L2 handover. nAR - new Access Router, the AR anticipated to be handling a MN's traffic after completion of an L2 handover. aAR - anchor Access Router, the AR that is currently handling the network end of the BET, where the MN originally established its aCoA. oCoA - old Care of Address, the Care of Address prior to the MN's first movement. In this document, it may be reused until the MN determines an appropriate time to change it, even if the MN changes subnet. nCoA - new Care of Address, the Care of Address in the new subnet. In this document, configuration with a nCoA may be delayed while the MN is engaged in latency-sensitive real time traffic or is rapidly moving across a series of ARs. aCoA - anchor Care of Address, the Care of Address after a MN has moved and elected not to establish a nCoA at nAR. HRqst(s)(resp. HRply(s)) - Designates a Handover Request (resp. Handover Reply) message that results from a source L2 trigger. The HRqst message is a variant of the HI message described in [3], the HRply is a variant of the HACK. bi-directional edge tunnel (BET) - A bi-directional tunnel placed between the AR where the MN first established its current CoA and a new AR to which the MN is attached, where the CoA would be topologically incorrect if used. The new AR tunnels packets from the MN and having the source address as the MN's old CoA to the old AR. The old AR tunnels packets to the MN and having the destination address as the MN's old CoA to new AR. The new AR detunnels the MN-directed packets and sends them over the radio link to the MN (and hence there is no BET tunnel overhead on the air link). The old AR detunnels CN-directed packets and sends them into the subnet where the old CoA is topologically correct. BETs allow use of the old CoA without running the risk of ingress or egress filtering. Faccin, Patil, Purnadi, Sreemanthula [Page 4] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 bi-directional edge tunnel handover (BETH) - Handover that involves establishing a new BET, or moving the radio interface end of the BET from oAR to nAR while keeping aAR unchanged. L2 handover - Movement of a MN's point of Layer 2 (L2) connection from one wireless access point to another. Depending on the L2, an L2 handover may traverse both a wireless and a wired link, or just a wired link. L3 handover - The process by which a MN obtains a new CoA from the AR, thus updating its routing reachability. L3 handover may occur partially before and partially after L2 handover, or it may occur entirely after L2 handover. L2 trigger - Information from L2 that informs L3 of the detailed events involved in handover sequencing at L2. L2 triggers are not specific to any particular L2, but rather represent generalizations of L2 information available from a wide variety of L2 protocols. See [2] for more detail on L2 triggers. source trigger - An L2 trigger that occurs at oAR, informing the oAR that L2 handover is about to occur. target trigger - An L2 trigger that occurs at nAR, informing the nAR that an MN is about to be handed over to nAR. ping-ponging - Rapid back and forth movement between two wireless access points due to failure of L2 handover. Ping- ponging can occur if radio conditions for both the old and new access points are about equivalent and less than optimal for establishing a good, low error L2 connection. AdCompAck û A message from MN to the Access Router to indicate that it has completed the process of obtaining a new CoA and has completed all the necessary MIPv6 procedures to discard the use of the oCoA. 1.2. Standards Language 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 RFC-2119 [5]. Faccin, Patil, Purnadi, Sreemanthula [Page 5] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 2. Protocol Behaviour 2.1. BET Lifetime and BET Renewal Negotiation The use of network policies and the negotiation in the establishment of the BETH tunnels can be applied to the lifetime of the BETs. In the current proposal of BETH, the lifetime option that determines the lifetime of the BET (tunnels) is solely determined by the aAR for both cases of HRqst originating from oAR as well as the nAR. However, the nAR could have policies indicating not to exceed a certain lifetime in support of the tunnels. Hence, we propose a way to negotiate a lifetime value in the HRqst and HReply. The AR initiating the HRqst shall, according to local policies, initially provide a BET Lifetime value that is supported on its end. The other end can accept it, or propose a lower BET Lifetime value according to local policies. The AR receiving the HRply shall adjust the tunnel lifetime to the new value if it is different from what was requested. This negotiation would provide means for both nAR and the oAR to determine a suitable tunnel lifetime value. The actual benefit of this negotiation is to reduce the failure cases and provide a better chance for successful exchange of messages. For example, as per the current proposal, when the nAR is not able to support the duration of the tunnel lifetime indicated by the aAR it can respond with a negative HRply, resulting in the failure of the tunnel establishment and hence the handover. The negotiation would allow the nAR to provide a lesser value, according to the local policy, when it is not capable of supporting the requested lifetime. Besides the use of the BET Lifetime negotiation for the tunnel creation, there could be deployment scenarios where there are local policies on whether each AR (aAr and/or oAR) can allow the renewal of the tunnels at the end of the lifetime. Currently, the AR assumes that the tunnels are renewable and hence initiates a HRqst for the extension of the tunnel lifetime. While there is nothing wrong in renewing the tunnel, it may not be within the policies of one of the two ARs to allow tunnels to be renewed. We propose to add a new parameter for the renewal option (BET Tunnel Renewal) to indicate whether the tunnel is renewable or not after the expiry of the current lifetime. If a BET cannot be renewed, according to draft-kempf-beth-ipv6-02.txt the nAR will request the MN to get a new CoA before the tunnel expires. The same objective can be already achieved by simply having the two ARs try to renew the tunnel and by one of them indicating that it is not possible. However, although this should still be possible, if one of the two ARs knows at the time of the tunnel establishment that the tunnel should not be renewed (based on local policies), it is more efficient to indicate this at that time. 2.2 PrRtrAdv from nAR The BETH proposal discusses three events that can lead to the need to terminate the tunneling service to the MN and therefore, requiring MN to obtain a nCoA. The first event is based on MN's own decision to obtain a nCoA because of its movement and traffic patterns, which leads to sending a RtrSol or a PrRtrSol to the nAR according to [mipv6] or [fmipv6]. Following this, the nAR responds with a RtrAdv or a modified PrRtrAdv. The other events are due to the need to terminate the BET due to pending request to renewal or a failure of BET procedure. However, unless explicitly indicated by the nAR to MN that a new CoA must be formed, there is no need for the MN to obtain a new CoA. Faccin, Patil, Purnadi, Sreemanthula [Page 6] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 Under these circumstances described above, the tunnels could be renewed and kept in use for a long time. The current BETH proposes to use either a RtrAdv or a PrRtrAdv to indicate the MN to get a new CoA after the BET handover. However, according to current specifications, upon receiving RtrAdv there is no hard requirement for MN to form a new CoA with the new network prefix. The MN, therefore, can continue to use the old CoA and the tunnels formed using BETH procedure. Thus, the use of RtrAdv does not allow the network to "force" the MN to get an nCoA. It would be beneficial to be able to allow the AR to force the MN to get an nCoA as determined by the network after the BETH handoff is complete. This mechanism would allow the network to control and initiate, based on local policies, the assignment of nCoA to the MN at an appropriate time after the tunnels are established. An explicit message such as a modified PrRtrAdv should be adopted for this purpose. The modified PrRtrAdv would contain the usual RtrAdv parameters like the nAR network prefix and the interface identity and in addition, it may contain the nCoA that is statically assigned to the MN by the AR. This message indicates to the MN that the nCoA must be formed or used as indicated in the message. This enhancement gives the flexibility to the old or the new AR to optimize the routing of packets to/from the MN according to its local policies. Moreover, this would also allow for a smoother integration of domains supporting BETH and domain supporting other mechanisms. 2.3. Chain tunneling In current BETH [beth02], tunnels are anchored at the aAR while the MN moves from one AR to another AR until a nCoA is obtained. This kind of mechanism requires that the (BET) tunnels be established between any set of ARs within or across different networks and the tunnels must be capable to support the QoS required for the MN traffic. In some domains, based on the service provider decisions on how to provide QoS and manage IP traffic, this requirement may introduce some issues (e.g. QoS negotiations may have to take place during BET establishment thus introducing some latency). In this draft, in the Handoff to Third case, a new tunnel is added to connect the latest serving AR (oAR) to the target AR (nAR), instead of connecting the anchor AR (aAR) directly to the nAR. This enhancement allows some domains to "pre-allocate" the QoS supported for BETs between each AR to the Physically Adjacent ARs (PAARs) to support handoff. In a time critical radio handoff that requires bi-directional tunneling between ARs, "pre-allocated" QoS promotes faster handoff without need for QoS negotiation. The current BET scheme may require in some domains complex QoS predefinition among each AR to all ARs in the serving network to which the MN can move to while maintaining anchored BETs, or may require QoS negotiation between aAR and nAR. Faccin, Patil, Purnadi, Sreemanthula [Page 7] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 new tunnel || ==============================================|| || || +-------+ +-------+ +-------+ | | old tunnel | | | | | aAR | ================ | oAR | | nAR | | | | | | | +-------+ +-------+ +-------+ Figure 1. Original BETH procedure +-------+ +-------+ +-------+ | | old tunnel | | new tunnel | | | aAR | ================ | oAR | ===============| nAR | | | | | | | +-------+ +-------+ +-------+ Figure 2. Proposed BETH Enhancement When the MN moves from oAR to nAR, before the L3 handoff takes place, a new tunnel is created between the oAR and the nAR. The oAR does not send any message to the aAR such as the HTT message. The procedure when the oAR adds tunnel to the nAR is similar to the procedure when the aAR adds tunnel to the oAR; the oAR sends HRqst(s) and the nAR replies with HRply(s), same procedures and messages as proposed in [beth02]. From the L3 point of view, the MN is still connected to the aAR. Although chained tunnels may lead to some issues, e.g. number of tunnels and state information kept by several ARs, additional complexity in oAR, when considered together with the ability of ARs to "force" the MN to form a new CoA, long tunnel chains can be avoided. Chained tunnel together with the ability of ARs to "force" the MN to form a new CoA allow for networks to implement a fast handoff based on BETs to minimize the disruption to the MN flows of IP packets, while allowing the network to tear down the tunnels sequentially to the MN movement. The scenario that can be achieved is: - the MN moves due to BETH from AR1 to AR2 - asynchronously: - AR2 indicates to the MN to get a new CoA - MN moves to AR3 due to BETH - MN gets a new CoA according to AR2, and the BET between AR1 and AR2 are deleted - AR3 indicates to the MN to get a new CoA - etc. In this way, the presence of multiple BET tunnels for a MN may be limited to a few of them in cases where the MN moves very quickly, and the presence of multiple tunnels is only temporary. Faccin, Patil, Purnadi, Sreemanthula [Page 8] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 Moreover, this option has other advantages: 1. QoS can be predefined between each AR to the adjacent ARs to support handoff. The time critical radio handoff that requires tunneling between AR can be executed faster without QoS negotiation. The current scheme may require QoS negotiation between aAR to nAR or requires complex QoS predefinition among each AR to all ARs in the serving network 2. Reduce the amount of signaling (although the signaling is not over the air interface) 3. More uniform procedure, no different between two party handoff and handoff to third 4. In case of pingpong back from nAR to the oAR, the already established tunnel between the oAR and the anAR can be reuse instead of having to re-establish a new tunnel between the oAR and naAR. 2.4. MN Acknowledgement after Adopting nCoA After the MN discards the use of previous CoA and all packets to and from the MN contain the nCoA, there is no use of the previously established (BET) tunnels. However, presently, there is no mechanism to indicate to the network to tear down the tunnel when they are not required, since both oAR and the nAR are not aware of the MN status in using the nCoA. Although, the tunnel can be automatically torn down at the end of the lifetime, there is a definite cost, in terms of router and tunnel resources, associated with keeping the tunnels up when not required. For this purpose, we propose that the MN explicity sends a message indicating it has successfully obtained a nCoA and performed all the mobility procedures requested (e.g. MIPv6 and any LMM needed) either to the nAR or oAR since both of them may have sent the command to get a new CoA, or it could be nAR if the MN has obtained a nCoA by itself without anybody forcing it. This message indication can be used to tear down the tunnel. The MN can determine the time when to acknowledge this message. For example, after sending BUs to the HA and the CN and receiving all the BAcks from HA and CN, the MN can be certain that the switching is complete and is now ready to initiate the acknowledgment. It is also possible for the MN to use other means to determine the opportune time to send the acknowledgment. It must be noted the use of this acknowledgment is to tear down the tunnel and release the tunnel resources. Therefore, the acknowledgement could be received by either the nAR or the oAR as it does not matter who initiates the tunnel teardown. 2.5. PrRtrAdv from oAR As explained in the section 2.1, it is possible for the oAR, during BET establishment, based on the local policies, resource availability, etc. may indicate that the tunnel lifetime is not renewable. Once the tunnel lifetime is about to expire or for other reasons as discussed in section 2.2, the nAR sends a PrRtrAdv to the MN to obtain a new CoA by sending a PrRtrAdv. However, due to changing conditions at the oAR due to traffic load or any other reason, oAR may realize that it cannot continue to hold the BET tunnel for a long time, in spite of negotiating a lifetime at the BET establishment. Therefore, it must be possible for allow the oAR to be able send a PrRtrAdv and force the MN to obtain a new CoA before the tunnel lifetime expires. Faccin, Patil, Purnadi, Sreemanthula [Page 9] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 In order for the oAR to perform an optimal and efficient route optimization and since MN has already moved at L2 and the BET has been already established, instead of using its own network prefix in PrRtrAdv, it could use the prefix of the nAR. This requires that the oAR receives the network prefix of the nAR interface where the MN will be connected during the BET establishement. The nAR network interface prefix can be carried in the HRply(s) or in the HRqst(t) message. So, when the MN receives PrRtrAdv message, regardless from nAR or oAR, it will have the same network prefix of the nAR to compute the new CoA. However, it may be possible for the MN to receive the PrRtrAdv from both the oAR and the nAR. In such case, a certain algorithm can be followed to let the MN to determine the action based on the content of both PrRtrAdv messages. For example, when both the oAR and the nAR indicate the same parameter options including the network prefix, the MN could proceed according to the first one and send a negative response to the second PrRtrAdv. If the parameter options are different, in the simplest case, the MN could send a negative response to the first PrRtrAdv and accept the second one. It is also possible for the MN to use other information such as L2 information to selectively accept PrRtrAdv from the nAR only and send negative response to the oAR. In either case, the MN must send the acknowledgment after adopting the nCoA as a response to the AR from which the MN accepted the PrRtrAdv. 3. Application Scenarios 3.1 Tunnel Negotiation With the help of the following figure, we explain some scenarios to discuss the enhancements provided in this document. The following enhancements are discussed. i) Lifetime Negotiation ii) Renewal Option iii) nAR forcing MN with PrRtrAdv to form CoA MN nAR oAR HA | | 1. HRqst | | | |<-------------| | | | 2. HRply | | | |------------->| | | +----------------------------+ | | | 3. Tunnel Established at | | | | time of L2 handover | | | +----------------------------+ | | +--+ | | | |4.| | | | +--+ | | | 5. PrRtrAdv | | | |<---------------| | | | 6. DAD | | | |<-------------->| | | | 7. BU | | | |----------------|--------------|------------->| | 8. BAck | | | |<---------------|--------------|--------------| Figure 3. Tunnel Negotiation Faccin, Patil, Purnadi, Sreemanthula [Page 10] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 1. For source-initiated handover, the oAR sends a HRqst with a certain Lifetime value and the renewal flag based on the local policies and network resources. 2. The nAR evaluates the HRqst and stores the lifetime and the renewal option of the nAR, if they are acceptable. If the values are not acceptable based on its own policies and network resources it responds with a lower value for the tunnel lifetime. It may also reset the renewal flag to indicate that it is not willing to renew the tunnel in the future. The oAR, upon receiving the HRply, must adjust the tunnel lifetime and also note the renewal capability of the nAR. This completes the tunnel properties negotiation. 3. The MN switches its link to a new access point within nAR. The packets now are tunneled from the oAR to the nAR to/from the mobile node. 4. Decision to either extend the tunnel lifetime or send PrRtrAdv to force MN to obtain a CoA due to i) Expiring BET and lifetime is not renewable or ii) Local policies or load conditions 5. An explicit command PrRtrAdv is sent to the MN to compute the nCoA either stateless or stateful based on the parameter options provided in the command. However, MN can also compute the new CoA from the RtrAdv. 6. The MN performs DAD for the nCoA. 7. The MN sends a BU to the HA and CN to update their binding with the nCoA. 8. The MN receives BAck for all the BU in its binding list. MN discards the use of the oCoA and uses nCoA for all traffic. The lifetime of BET (tunnel) automatically expires and are torn down. The above scenario covers the cases when the tunnel lifetime and renewal options are negotiable. It also shows the case when nAR, based on either load conditions or the local policies, can send the PrRtrAdv and force the MN to obtain a new CoA. In general, the PrRtrAdv indicates to the MN that it must obtain a nCoA immediately as indicated in the parameter options. It must be noted that the MN could have, already, started to form a nCoA when it receives the PrRtrAdv, in which case the MN can proceed, without interruption, with DAD and MIP procedures after ensuring that it uses the right network prefix as indicated in the PrRtrAdv. In some special cases, like handoff to third, the MN may be forming a new CoA belonging to the oAR, in which case, the MN must stop the current procedure and form a new CoA as per PrRtrAdv. 3.2 Chain Tunneling MN nAR oAR aAR | | | 1. L2-ST ~~~~~> | | | | 2. HRqst(s) | | | |<-------------------| | | | 3. HRply(s) | | | |------------------->| |---------------------|---------------------|--------------------| | 4. L2 Handover | | |---------------------|---------------------|--------------------| | | | BET-1 | | | |====================| | 5. MN's Traffic on aCoA | | |<----------------------------------------->| | | | | | Faccin, Patil, Purnadi, Sreemanthula [Page 11] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 | | 6. L2-ST ~~~~~>| | | | 7. HRqst(s) | | | | <------------------ | | | | 8. HRply(s) | | | | ------------------> | | |---------------------|---------------------| | | |9. L2 Handover | | |---------------------|---------------------| | | | BET-2 | | | |=====================| | |10.MN Traffic on BET-2 | | |<------------------->| | | | +---+ | | | |11.| | | | +---+ | | | 12.PrRtrAdv | | | |<--------------------| | | | | 13.BU | | |---------------------|-------------------- |-------> HA | | | 14.BAck | | |<--------------------|<------------------- |-------- HA | |15.MN Traffic on nCoA| | | |<------------------->| | | Figure 4. Chain Tunneling Up to step no.5 are BETH Two Party Source Trigger Handover procedures, except the HRqst(s) will carry new parameters to indicate the proposed tunnel lifetime and whether the tunnel lifetime is renewable or not. The HRply(s) can counter offer with a new proposed tunnel lifetime, as long as the new tunnel lifetime is smaller than the original proposed tunnel life time. The smaller tunnel life time should be honored by the aAR and the oAR. 6. Before L3 handoff takes place, the oAR receives another L2 trigger indicating that L2 handoff is required 7. The oAR sends HRqst(s) to the nAR similar to BETH two party handoff procedures when the aAR sends HRqst(s) to the oAR. This L3 message will initiate the L2 procedure in nAR. Similarly, the HRqst(s) will carry new parameters to indicate the proposed tunnel lifetime and whether the tunnel lifetime is renewable or not. 8. Upon completion of the L2 procedure the nAR sends HRply(s) to the oAR. The HRply(s) can counter offer with a new proposed tunnel lifetime, as long as the new tunnel life time is smaller than the original proposed tunnel life time. The smaller tunnel life time should be honored by the aAR and the oAR. 9. The L2 Handover procedures are executed. It involves the MN, the nAR and the oAR. 10. MN obtains L2 connection with the nAR and now the MN traffic used BET-2. Faccin, Patil, Purnadi, Sreemanthula [Page 12] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 At this point the tunnels are formed between the aAR - oAR and between the oAR - nAR. During this procedure the oAR may need to renew BET to the aAR and the procedure follows section 2.4 of [beth02]. After a certain waiting period (for example to accommodate possible pingpong), the nAR then starts the procedure of L3 handoff. 11. Decision to either extend the tunnel lifetime or send PrRtrAdv to force MN to obtain a CoA due to i) Expiring BET and lifetime is not renewable or ii) Local policies or load conditions 12. nAR sends PrRtrAdv to the MN with indication that the MN must obtained a new CoA. It includes the prefix of the nAR and in case of stateful CoA, this message can also carry nCoA. The nAR sends the PrRtrAdv due to the expiration of the tunnel lifetime with indication it is not renewable or based on other local policies. 13. Upon receiving the commands to obtain a new CoA through the PrRtrAdv message, the MN form a nCoA (stateless) or accept nCoA from the nAR (stateful), the MN starts the Neighbor Discovery (ND) procedures. If the ND is successful, the MN sends BU (Binding Update) to the HA. The BU will be routed through the tunnels to the HA 14. The HA sends BAck (Binding Acknowlegement) to the MN via nAR At this state, the packets are routed directly to the nAR and the network is optimized. The MN then proceeds with BU/BAck procedures to each CN that the MN is communicating with. The MN knows when it receives the last BAck. The MN can send an acknowledgement to the nAR and this acknowlegement is the trigger to tear down of the tunnel before the lifetime expires 15. MN traffic now uses the nCoA. At the expiry of the lifetime, the BET-1 and BET-2 are torn down automatically. In this example only the source trigger case is explained. The idea can be extended to the target trigger case. The scenario above explains the procedures when the MN moves from oAR to nAR before the oAR sends PrRtrAdv. There is the possibility that the MN moves to nAR after receiving PrRtrAdv from the oAR. The MN will have formed the oCoA (based on prefix of oAR) and proceeds with ND procedures at nAR. According to the current ND procedure [rfc2461], the ND may fail and the MN starts listening to the PrRtrAdv from nAR, then MN will form the nCoA based on the nAR prefix and proceeds with the ND and BU procedures. If the MN has passed the ND procedures with the oAR then the MN moves before executing the BU procedure, the MN will send BU to the nAR. But this BU has source address equals to the oCoA, that makes the nAR reject this packet since it come from unknown prefix and it is not recognized as an address to tunnel it since the tunnel oAR - nAR was created with aCoA as the recognized address. Since the BU is rejected, and the MN starts listening to a new PrRtrAdv, then MN Faccin, Patil, Purnadi, Sreemanthula [Page 13] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 will form the nCoA based on the nAR prefix and proceeds with the ND and BU procedures. The MN may also receive a new PrRtrAdv from the nAR before the MN starts the BU procedure. Upon reciving the new PrRtrAdv from the nAR, the MN may terminate the BU procedure using the oCoA and create nCoA based on the nAR prefix, then proceeds with the ND and BU procedures. 3.3 MN Acknowledgement after Adopting nCoA The following figure shows the scenario where the MN sends an explicit acknowledgement after completing the switch to use the nCoA. This could be in response to the PrRtrAdv or due to voluntary MN action in response to RtrAdv. The MN continues to use the oCoA as the source address and receives the packets destined to oCoA through the BET tunnel. In this example, we show that the MN decides that after receiving the responses (BAck) for all the BU sent to HA and the CN that it knows the use of oCoA can be discarded and it has completely adopted the use of nCoA. After receiving the PrRtrAdv or from the periodic RtrAdv from the nAR, the MN creates nCoA either by stateless autoconfiguration or uses the stateful address, if provided by the nAR. After successful completion of the DAD it sends BU to the HA and all the CN it has been in communication. The MN received BAck for each of the BU it sends. After sending Back, HA and CN update their binding cache and discard the use of the oCoA as the destination address and immediately start to use the nCoA. Hence, the use of the BET is not required since there will not be any packets destined to oCoA. At the receipt of the last BAck, the MN sends a AdCompAck as an acknowledgement to the nAR. The nAR uses this message to tear down the tunnel between the oAR and the nAR by sending a HRqst for renewal with zero lifetime. The oAR responds with a HRply with the same value. MN nAR oAR HA CN +--------------------------------+ | | | | L2 BETH Procedure | | | | +--------------------------------+ | | | | | BET | | | | |==============| | | | 1. PrRtrAdv | | | | |<---------------| | | | | 2. DAD | | | | |<-------------->| | | | | 3. BU | | | | |----------------|--------------|------------->| | | 4. BAck | | | | |<---------------|--------------|--------------| | | 4'. BU | | | | |----------------|--------------|--------------|------------>| | 5'. BAck | | | | |<---------------|--------------|--------------|-------------| | 6. AdCompAck | | | | |--------------->| | | | | | 7.HRqst(r) | | | | |------------> | | | | | 8.HRply(r) | | | | |<-------------| | | Figure 4. Address Completion Acknowledgment from MN Faccin, Patil, Purnadi, Sreemanthula [Page 14] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 3.4 PrRtrAdv from oAR In this scenario, the oAR initiates the PrRtrAdv request to the MN to form a new CoA due to any of the reasons explained before. During the exchange of the HRqst and HRply, the nAR provides the network prefix of the interface or even the stateful address on which the MN will be performing the handover to. The MN at the receipt of PrRtrAdv, computes a new CoA and performs the following procedures. At the completion of switching over to the use of the nCoA, it sends an AdCompAck to the oAR. The oAR tears down the BET with HRqst lifetime parameter set to zero. MN nAR oAR HA CN | | 1. HRqst | | | | |<-------------| | | | | 2. HRply | | | | |------------->| | | +--------------------------------+ | | | | L2 Handover | | | | +--------------------------------+ | | | | | BET | | | | |==============| | | | 3. PrRtrAdv | | | | |<---------------|--------------| | | | 4. DAD | | | | |<-------------->| | | | | 5. BU | | | | |----------------|--------------|------------->| | | 6. BAck | | | | |<---------------|--------------|--------------| | | 5'. BU | | | | |----------------|--------------|--------------|------------>| | 6'. BAck | | | | |<---------------|--------------|--------------|-------------| | 7'. AdCompAck| | | | |----------------|------------->| | | | | | 8.HRqst(r) | | | | |------------->| | | | | 9.HRply(r) | | | | |<-------------| | Figure 5. PrRtAdv from oAR For simplicity, a likely PrRtrAdv from the nAR to MN is not shown in the figure. However, it is a valid scenario and MN action is explained in the protocol behavior in the previous sections. 4. Conclusions The enhancements proposed in this draft are optional enhancements to the BETH framework, i.e. each networks may adopt them or not based on network policies. The authors believe that the enhancements proposed, while still applicable to the scenarios that triggered the development of BETH, contribute to widen the applicability of BETH and allow service providers more flexibility in deploying BET handover in their networks. Faccin, Patil, Purnadi, Sreemanthula [Page 15] INTERNET-DRAFT Enhancements to Bi-directional Edge Tunnel Handover Sept, 01 5. References [wcdma-umts] Holma, H. and Toskala, A., "WCDMA for UMTS," John Wiley and Sons, Chichester, 2000. [beth02] Kempf, J., et. al., "Bidirectional Edge Tunnel Handover for IPv6," draft-kempf-beth-ipv6-02.txt, a work in progress. [fmipv6] Tsirtsis, G., "Fast Handovers for Mobile IPv6," draft-ietf-mobileip-fast-mipv6-01.txt, a work in progress. [mipv6] Johnson, D., and Perkins, C., "Mobility Support in IPv6," draft-ietf-mobileip-ipv6-13.txt, a work in progress. 6. Authors' Addresses Stefano Faccin Nokia Research Center 6000 Connection Drive Phone: +1 972 894 4994 Irving, Texas Fax: +1 972 894 4589 75039 Email: stefano.faccin@nokia.com Basavaraj Patil Nokia Networks 6000 Connection Drive Phone: +1 972 894 6709 Irving, Texas Fax: +1 972 894 4589 75039 Email: basavaraj.patil@nokia.com Rene Purnadi Nokia Research Center 6000 Connection Drive Phone: +1 972 894 4897 Irving, Texas Fax: +1 972 894 4589 75039 Email: rene.purnadi@nokia.com Srinivas Sreemanthula Nokia Research Center 6000 Connection Drive Phone: +1 972 894 4356 Irving, Texas Fax: +1 972 894 4589 75039 Email: srinivas.sreemanthula@nokia.com Faccin, Patil, Purnadi, Sreemanthula [Page 16]