Mipshop Working Group Henrik Petander Internet Draft National ICT Australia Expires: April 2007 October 16, 2006 Bicasting with Buffering and Selective Delivery for Fast Handovers for Mobile IPv6 draft-petander-mipshop-fmipv6-bbsd-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. This document may only be posted in an Internet-Draft. 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 April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract More and more mobile nodes are being equipped with multiple radios, such as 3G and 802.11. This document specifies use of Bicasting with Buffering and Selective Delivery (BBSD) with Fast Handovers for Petander Expires April 16, 2007 [Page 1] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 Mobile IPv6 (RFC 4068). The BBSD scheme takes advantage of the additional radio capabilities of Mobile Nodes. As in Simultaneous Bindings for Fast Handovers, the BBSD extension uses bicasting to allow a Mobile Node to continue receiving packets directly from the Previous Access Router during the handoff process. In addition, the selective delivery uses sequence numbers in the bicasted packets to enable the New Access Router to only deliver those packets from its buffer that the Mobile Node has not already received directly from the Previous Access Router. This reduces the overhead of bicasting and mitigates the negative impacts of packet duplication on the application performance in Mobile Node. Conventions used in this document 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 [1]. This document uses the terms and abbreviations defined in RFC 4068. 1. Introduction In a break-before-make (BBM) handoff, a Mobile Node (MN) loses connectivity with its old access network before connecting to a new one. In a make-before-break (MBB) handoff, the MN is still connected to its previous Access Router (PAR) while performing a handoff to a new Access Router (NAR). MNs equipped with multiple physical or logical interfaces can perform MBB handoffs. For example, inter access technology or vertical handoffs can often be performed as MBB handoffs. In this document, we specify the Bicasting with Buffering and Selective Delivery (BBSD) protocol extension to Fast Handovers for Mobile IPv6[2] (FMIPv6) to improve the performance of predictive MBB handoffs. We first describe the performance problems with FMIPv6 and FMIPv6 with simultaneous bindings [6] in a MBB handoff setting. We then describe the BBSD protocol extension to FMIPv6, which introduces a new ICMPv6 message, a new option to the Fast Neighbor Advertisement message defined in RFC 4086, and uses the bicast packet identification destination option[3] for identifying duplicate packets. Using the new mechanisms a MBB handoff capable MN can improve its handoff performance significantly with a small additional overhead, when compared to normal FMIPv6 operation. Petander Expires April 16, 2007 [Page 2] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 2. Performance limitations of FMIPv6 with buffering or simultaneous bindings in make-before-break handoffs In a MBB handoff, a MN can receive packets directly at its Previous Care-of Address (PCoA) until disconnecting from the PAR. However, the use of buffering and early forwarding of packets to its New Care-of Address (NCoA) in predictive FMIPv6 handoffs prevents the MN from receiving the packets, until it attaches to the NAR. This makes the handoff latency visible to the applications. Further, if the duration of the handoff is significant, which may often be the case in vertical handoffs, the emptying of the buffer will require significant bandwidth at the link of the NAR. If this bandwidth is not available, packet loss or long delays in packet delivery are hard to avoid. Use of simultaneous bindings may allow the PAR to multicast packets to the NCoA at the NAR and directly to the PCoA. This hides the handoff latency from applications in a MBB handoff. If buffering is used at the NAR, the MN can recover any packets it loses, if it disconnects from the PAR before connecting to the NAR (an incomplete MBB handoff). However, the use of buffering with bicasting requires additional bandwidth for delivery of the packets from the buffer of NAR, in spite of the high probability of the MN already having received the same packets at the link of PAR. The duplicate packets may also have a negative effect on the performance of TCP. 3. Overview of the BBSD protocol BBSD extends the FMIPv6 predictive mode with bicasting and buffering by delivering only those packets from the buffer of the NAR which the MN has not already received at link of the PAR. This eliminates the duplicate packets received by the MN and with it reduces the over the air overhead of bicasting. In the beginning of a predictive handoff, i.e. after the PAR receives HAck from the NAR, it continues to deliver packets to the PCOA of the MN directly. Additionally, it starts delivering copies of the packets to the NCoA of the MN at the NAR which buffers them. The PAR numbers the packets using a sequence number, so that both copies of the packet have the same counter value. The MN keeps track of which packets it receives directly from PAR by recording the counter values of received packets during the handoff. When the MN attaches to the NAR and sends a FNA to it, the MN includes a list of missed packets. Petander Expires April 16, 2007 [Page 3] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 Based on this list, the NAR flushes the packets the MN has already received from its buffer and delivers only the missed packets to the MN. Additionally, the NAR sends a stop Bicast message to the PAR, which instructs it to deliver packets destined to PCoA of the MN only by tunneling them to the NCoA. In case the MN is still connected to the PAR at the end of the handoff, the delays resulting from the indirect delivery of the Stop Bicast message may lead to a certain amount of duplicate packets being received by the MN. The MN can either filter these packets, or directly send a Stop Bicast message to the PAR. Figure 1 depicts the operation of FMIPv6 with the BBSD extension. MN PAR NAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------| | | | | |------FBU----------->|--------HI--------->| | |<------HAck---------| | <--FBack---|--FBack---> | |<=================bicast ================>| disconnect packets | | | | | connect | | | | |--------- FNA --------------------------->| |<=================================deliver packets |------SBC----------->| lost after disconnect | |<-------SBC---------| Petander Expires April 16, 2007 [Page 4] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 | | | Figure 1 : "Predictive" BBSD Fast Handover 4. New Message types 4.1. ICMPv6 Stop Bicast (SBC) message Stop Bicast message is sent by the NAR to the PAR. Optionally the MN can also send the stop bicast message for faster delivery. Figure 2 depicts the Stop Bicast Message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 2 : Stop BiCast (SBC) Message IP Fields: Source Address The IP address of the sender. If SBC is sent by the MN this would be PCoA. For the NAR this would be the NAR address used in FMIPv6. Destination Address The IP address of the PAR. Hop Limit 255. See RFC 2461 Authentication Header Petander Expires April 16, 2007 [Page 5] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 The authentication header MUST be used when this message is sent. See RFC 2402 [4]. ICMP Fields: Type The Experimental Mobility Protocol Type. See RFC 4065 [5]. Code 0. Checksum The ICMPv6 checksum. Subtype XX Reserved MUST be set to zero by the sender and ignored by the receiver. Valid options: Old Care-of Address option using the format of IPv6 address option defined in RFC 4068 with option code set to 1. 4.2. BBSD Received Packets Option The MN MAY insert the Received Packets Option to the FNA message to request the NAR to deliver any packets lost during the handoff from its buffer. Figure 3 depicts the Received Packets Option. Petander Expires April 16, 2007 [Page 6] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Option-Code | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received packet range 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received packet range 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received packet range N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 : Received Packets Option Format Type XX Length The size of this option in 8 octets including the Type, Option-Code and Length fields. Option-Code 0 Reserved MUST be set to zero by the sender and MUST be ignored by the receiver. Petander Expires April 16, 2007 [Page 7] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 Received packet range # First and last packet received. First 16 bits of the field indicate the first received packet and 2nd 16 bits indicate the last received packet in the range. If packets in between are missed multiple ranges may be included. The received packet ranges MUST be in ascending order, e.g. 0-1, 3-3. Padding Set to zero by sender. Depending on the number of received packet ranges in the packet, the packet length may not be a multiple of 8 octets. In this case, the sender MUST pad the option with zero bytes so that its length is a multiple of 8 octets. The receiver of the FNA message can calculate the number of received packet ranges based on the option length and zeroed padding fields. 5. New flags For interoperability with RFC 4068, the MN needs to request the use of BBSD and the PAR and the NAR need to confirm its use. For this purpose, the protocol extension introduces the BBSD flag, abbreviated to B-flag. 5.1. B-flag in FBU message MN sets the B-flag in the FBU to request the PAR to start bicasting and numbering packets. Figure 4 depicts the placement of the B-flag in the FBU message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|B| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobility options ... Petander Expires April 16, 2007 [Page 8] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 : FBU message with B-flag. 5.2. B-flag in Fast Binding Acknowledgment message PAR sets the B-flag in the FBAck message to acknowledge to the MN that the BBSD protocol will be used for the handoff. Figure 5 depicts the placement of the B-flag in the FBAck message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobility options ... +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 : FBAck message with B-flag. 5.3. B-flag in Handover Initiate message The PAR sets the B-flag in the HI message to request BBSD operation from the NAR. If the B-flag is set, the buffer flag (U-flag) MUST also be set. Figure 6 depicts the placement of the B-flag in the HI message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Petander Expires April 16, 2007 [Page 9] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype |S|U|B| Reserved| Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobility Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 6 : HI message with B-flag. 5.4. B-flag in Handover Acknowledge message The NAR sets the B-flag to confirm that it supports the BBSD protocol. Figure 7 depicts the placement of the B-flag in the HAck message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype |B| Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 7 : HAck message with B-flag. Petander Expires April 16, 2007 [Page 10] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 6. Numbering of the packets In bicasting, the PAR delivers the original packet to the MN at the PCoA and tunnels a copy of it to the NCoA at the NAR. The packets need to be numbered for the MN to request selective delivery of missed packets and there are two options for the numbering: A destination option containing a sequence number is inserted into the bicasted packets as specified in [3]. If the original packet is protected with IPsec Authentication Header [4], an IPv6 tunnel header with the destination option header can be added to the directly delivered packets. For the tunneled packets, the destination option header is inserted between the tunneling header and the original IP packet from Correspondent Node. 7. Operation of the PAR in the protocol The PAR operates as in FMIPv6 protocol, except for the changes specified in the following paragraphs. The PAR identifies the request to use BBSD from the B-flag in the FBU. Upon receiving a FBU with B-flag, the PAR SHOULD set the B-flag in the HI message to the NAR. If the NAR supports the BBSD protocol, it SHOULD set the S-flag in the HAck. After receiving a HAck message from the NAR confirming the success of the handoff with the B-flag set, the PAR SHOULD send a FBack message with the B-flag set. The PAR SHOULD also start bicasting packets to the new and previous Care-of Addresses of MN. If the PAR or the NAR do not support the protocol, they MUST not set the B-flag in the messages. Using the destination option defined in [3] the PAR sets the same counter value to the directly delivered packet and the tunneled copy. The value starts from zero and is incremented for each packet. The PAR continues bicasting until it receives a Stop Bicast message from the NAR or the MN. When the PAR receives the Stop Bicast message, it MUST stop sending packets directly to the MN at the PCoA and MUST only tunnel them to the NCoA. 8. Operation of the NAR in the protocol The protocol extends the NAR operation to use B-flag in the HAck and to send a Stop Bicast message to the PAR when it receives a FNA with the BBSD Received Packet Option and to deliver any lost packets from its buffer to the MN. Petander Expires April 16, 2007 [Page 11] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 Upon receiving a HI message from the PAR with the B-flag set, the NAR SHOULD set the B-flag in the HAck, if it supports the BBSD extension. Upon receiving the Received Packets Option, the NAR SHOULD go through its buffer of undelivered packets for the NCOA of MN and it SHOULD drop all packets which the MN already received at the previous link. The NAR SHOULD make the drop decision based on a comparison of the counter field in the buffered packets with the list of received packets option. In the common case of no packet loss during handoff, The NAR SHOULD drop all packets up to and including the last received packet. Additionally, the NAR MUST send a Stop Bicast message to the PAR, with the IP address option containing the PCoA of the MN. 9. Operation of MN in the protocol A MN which wants to use the BBSD protocol for a handoff MAY set the B-flag in the FBU, when it performs a predictive FMIPv6 handoff. MN MUST not set the flag in reactive handoffs. After receiving FBack from PAR, the MN SHOULD check whether the B-flag is set. If the B-flag in the FBack was set, the MN SHOULD start tracking the counter values of the received packets. The MN SHOULD keep a list of any gaps in packets and the largest counter value received. When the MN attaches to the NAR and sends a FNA, the MN SHOULD include the BBSD lost packets option with the counter value of the last received packet and include any lost packets using the lost packets range fields. After sending the FNA, the MN MAY also send a Stop Bicast message to PAR. The MN should only send the message, if the direct path from PCoA to PAR is still operational and is likely to be faster than the indirect path via the NAR. 10. Security Considerations The protocol introduces a new message, Stop Bicast, which stops bicasting of packets. To avoid denial-of service attacks against the mobile node, this message must be authenticated as coming from the MN owning the PCoA. In this protocol, IPsec Authentication Header[4] is used with the existing FMIPV6 security association between the NAR and the PAR or the existing security association between the MN and the PAR. Petander Expires April 16, 2007 [Page 12] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 11. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Koodli, R. (ed), "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [3] Petander, H., "Bicast packet identification extension header" draft-petander-mipshop-bicastexthdr-00.txt, October 2006, work in progress [4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [5] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005. 12. Informative References [6] El_Malki, K., and Soliman, H. "Simultaneous Bindings for Mobile IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6- 06.txt, July 2005 Author's Address Henrik Petander National ICT Australia Australian Technology Park Bay 15 Locomotive Workshop, Eveleigh NSW 1430 Australia Email: henrik.petander@nicta.com.au Petander Expires April 16, 2007 [Page 13] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 Intellectual Property Statement 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 Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Petander Expires April 16, 2007 [Page 14] Internet-Draft draft-petander-mipshop-fmipv6-bbsd-00.txt October 2006 Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Thanks to Max Ott for his constructive comments on the draft. Petander Expires April 16, 2007 [Page 15]