idnits 2.17.1 draft-xia-mipshop-ha-buffering-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Expires: May 5, 2009 Huawei USA 5 B. Patil 6 Nokia 7 November 1, 2008 9 Mobile IPv6 Handover Using Home Agent Buffering 10 draft-xia-mipshop-ha-buffering-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 5, 2009. 37 Abstract 39 In Mobile IPv6, when a Mobile Node (MN) moves from one Access 40 Router(AR) to another, there is a period during which the MN is 41 unable to send or receive packets because of link switching delay and 42 IP protocol operations. This document specifies a mechanism to 43 reduce packet loss through a Home Agent (HA) buffering downlink 44 packets during the handover period. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. General Approach . . . . . . . . . . . . . . . . . . . . . 4 52 3.2. Mobile Node Operations . . . . . . . . . . . . . . . . . . 5 53 3.3. Home Agent Operations . . . . . . . . . . . . . . . . . . . 5 54 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.1. Packet Buffering option . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 61 8.2. Informative references . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . . . 9 65 1. Introduction 67 When a MN moves from one AR to another, there is a period during 68 which the MN is unable to send or receive packets because of link 69 switching delay and IP protocol operations. 71 Fast handovers for Mobile IPv6 (FMIPv6) [RFC5268] describes a 72 mechanism that reduces the handover latency and packet loss through 73 signalling between a previous AR and a new AR. Hierarchical Mobile 74 IPv6 (HMIPv6)[RFC5380] introduces a network entity named Mobility 75 Anchor Point (MAP) which is used for reducing the amount of 76 signalling between the MN, its Correspondent Node (CN), and its Home 77 Agent (HA). Either of these local mobility handling mechanisms, 78 FMIPv6 or HMIPv6, is dealing with some extra mobility management 79 entities besides the MN and HA ( such as previous AR (PAR) and new AR 80 (NAR) in FMIPv6, or MAPs in HMIPv6). In some scenarios, e.g. the MN 81 moves from one administrative domain to another, it is very hard to 82 deploy FMIPv6 or HMIPv6. 84 As a complimentary solution, a HA based handover mechanism is 85 proposed here. When the MN decides to switch to another access 86 router, the MN indicates the HA to buffer incoming packets. After 87 the HA receives an indication that the MN has completed the handover 88 process, the HA delivers the buffered packets. This enhancement can 89 improve greatly the performance of mobile internet applications 90 mostly relying on TCP which is packet-loss sensitive. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Protocol Operation 99 3.1. General Approach 101 +-----+ +-----+ +-----+ +-----+ 102 | MN | | PAR | | NAR | | HA | 103 +-----+ +-----+ +-----+ +-----+ 104 | | | | 105 | 1 Network Entry | | | 106 |<------------------->| | | 107 | | 2 BU | | 108 |------------------------------------------------------->| 109 | | 3 BA | | 110 |<------------------------------------------------------>| 111 | | | | 112 | 4 bi-directional tunnel | 113 |<======================================================>| 114 | | | | 115 5 Handover trigger | | | 116 | | | | 117 | 6 BU(transient) | 118 |------------------------------------------------------->| 119 | | | | 120 | | | 7 forwarding 121 | | | and buffering 122 | 8 BA(transient) | 123 |<-------------------------------------------------------| 124 | | | | 125 | 9 Network Re-entry | | 126 |<------------------------------->| | 127 | | | | 128 | 10|BU(new CoA)| | 129 |------------------------------------------------------->| 130 | | | | 131 | 11|BA(new CoA)| | 132 |<-------------------------------------------------------| 133 | | | 12 stopping buffering and 134 | | | delivering buffered packets 135 | | | | 136 | 13 bi-directional tunnel | 137 |<======================================================>| 139 Figure 1: General Approach 141 1. The MN enters into network and attaches a PAR. Authentication 142 is usually necessary in this step. 144 2. After successful CoA (hereafter called previous CoA to 145 differentiate new CoA) configuration and bootstraping 146 processing, the MN sends Binding Update (BU) message to register 147 the CoA in the HA. 148 3. In reply to the BU, a Binding Acknowledgement (BA) is delivered 149 to the MN from the HA. 150 4. A bi-directional tunnel is established after the BU/BA exchange. 151 All of the previous steps are in line with specification 152 described in [RFC3775] 153 5. When signal strength is degrading or packet loss rate is 154 increasing the MN may decide to change links. Alternatively, 155 the network can also initiate handover by signaling the MN. 156 6. After receiving the handover trigger MN sends a BU message. A 157 Packet Buffering option defined in Section 4.1 is included in 158 the message. The source address of the message is the CoA 159 configured when the MN attaches the PAR. 160 7. In addition to forwarding downlink packets to the MN, the HA 161 begins to buffer them for a duration which is indicated in the 162 lifetime field of Packet Buffering option Section 4.1. On the 163 other hand, the HA updates binding cache entry of the MN with 164 new lifetime of the BU message. 165 8. The HA acknowledges the MN with BA message. 166 9. When the MN moves to the NAR, the MN performs network entry 167 procedure. A new CoA is configured. 168 10. The MN sends a BU message with the new CoA as the source 169 address. 170 11. Once receiving the BU, the HA creates a new binding cache entry 171 which binds the MN's home address with the new CoA. 172 12. The HA stops buffering downlink packets for MN, delivers all 173 buffered packets to MN's new CoA, and obsoletes the old binding 174 cache with previous CoA registered. 175 13. All traffic destined to the MN is conveyed through the newly 176 established bi-directional tunnel. 178 3.2. Mobile Node Operations 180 As an optional enhancement, this document provides an mechanism to 181 reduce packet loss during handovers. When the MN decides to switch 182 to another access router, the MN indicates the HA to buffer incoming 183 packets through a transient BU/BA exchange. Once successfully 184 attaching to a new access router, all the buffered packets are 185 delivered from the HA to the MN. 187 3.3. Home Agent Operations 189 The enhancement capability is configurable in the HA. When the 190 feature is disabled, the HA just ignores the Packet Buffering option 191 defined in Section 4.1. Otherwise, the HA SHOULD buffer the downlink 192 traffic. 194 4. Message Format 196 4.1. Packet Buffering option 198 The Packet Buffering option described in this section can be present 199 in a BU or BA. The HA receiving BU message with this option will 200 buffer the incoming packets destined to the MN for a lifetime which 201 is negotiated through BU/BA exchange. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | Reserved | Lifetime | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Type: TBD by IANA 211 Length: 8-bit unsigned integer indicating the length of the option 212 in octets, excluding the Type and the Length fields. 214 Reserved: To be used in the future. 216 Lifetime: Lifetime in the unit of 100ms. When lifetime expires, the 217 HA will purge all the buffered packets for the MN. 219 TBD. 221 5. Security Considerations 223 Malicious MNs may make use of the mechanism to deplete HA's buffer 224 space. The HA can configure limited buffering space for each MN to 225 counteract the impact. Only one mobility option is defined in this 226 document, and there are no additional security concerns introduced. 228 6. IANA Considerations 230 This document defines one mobility header option called Packet 231 Buffering option. This option is described in Section 4.1. The Type 232 value for this option should be assigned from the same numbering 233 space as allocated for the other mobility options, as defined in 234 [RFC3775]. 236 7. Acknowledgements 238 TBD. 240 8. References 242 8.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 248 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 249 Management", RFC 5380, October 2008. 251 [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, 252 June 2008. 254 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 255 in IPv6", RFC 3775, June 2004. 257 8.2. Informative references 258 Authors' Addresses 260 Frank Xia 261 Huawei USA 262 1700 Alma Dr. Suite 500 263 Plano, TX 75075 265 Phone: +1 972-509-5599 266 Email: xiayangsong@huawei.com 268 Behcet Sarikaya 269 Huawei USA 270 1700 Alma Dr. Suite 500 271 Plano, TX 75075 273 Phone: +1 972-509-5599 274 Email: sarikaya@ieee.org 276 Basavaraj Patil 277 Nokia 278 6000 Connection Drive 279 Irving, TX 75039 281 Phone: 282 Email: basavaraj.patil@nokia.com 284 Full Copyright Statement 286 Copyright (C) The IETF Trust (2008). 288 This document is subject to the rights, licenses and restrictions 289 contained in BCP 78, and except as set forth therein, the authors 290 retain all their rights. 292 This document and the information contained herein are provided on an 293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 295 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 296 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 297 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org.