idnits 2.17.1 draft-jikim-bpmipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** There are 135 instances of too long lines in the document, the longest one being 45 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [RFC3775], [5], [RFC2119], [RFC5213], [RFC5268], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2009) is 5342 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 297 looks like a reference -- Missing reference section? '4' on line 311 looks like a reference -- Missing reference section? 'RFC2119' on line 300 looks like a reference -- Missing reference section? '2' on line 305 looks like a reference -- Missing reference section? '3' on line 308 looks like a reference -- Missing reference section? '5' on line 313 looks like a reference -- Missing reference section? 'RFC 3775' on line 316 looks like a reference -- Missing reference section? 'RFC 5213' on line 319 looks like a reference -- Missing reference section? 'RFC 5268' on line 322 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Ji In, Kim, Seok Joo Koh 2 Internet Draft Kyungpook National University 3 Intended status: Informational September 3, 2009 4 Expires: March 2010 6 PMIPv6 with Bicasting for Soft Handover 7 draft-jikim-bpmipv6-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may not be modified, 16 and derivative works of it may not be created, and it may not be 17 published except as an Internet-Draft. 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be modified, 21 and derivative works of it may not be created, except to publish it 22 as an RFC and to translate it into languages other than English. 24 This document may contain material from IETF Documents or IETF 25 Contributions published or made publicly available before November 10, 26 2008. The person(s) controlling the copyright in some of this 27 material may not have granted the IETF Trust the right to allow 28 modifications of such material outside the IETF Standards Process. 29 Without obtaining an adequate license from the person(s) controlling 30 the copyright in such materials, this document may not be modified 31 outside the IETF Standards Process, and derivative works of it may 32 not be created outside the IETF Standards Process, except to format 33 it for publication as an RFC or to translate it into languages other 34 than English. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on March 6, 2009. 52 Copyright Notice 54 Copyright (c) 2009 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents in effect on the date of 59 publication of this document (http://trustee.ietf.org/license-info). 60 Please review these documents carefully, as they describe your rights 61 and restrictions with respect to this document. 63 Abstract 65 This document proposes an enhanced handover scheme on the Proxy 66 Mobile IPv6 (PMIPv6) with bicasting for IP handover (B-PMIPv6). In B- 67 PMIPv6, a mobile node (MN) performs binding update to Local Mobility 68 Anchor (LMA) in advance, and then the LMA begins the bicasting of 69 data packets to the new Mobile Access Gateway (N-MAG) as well as the 70 previous MAG (P-MAG). The B-PMIPv6 minimizes the possible packet 71 losses and handover latency during handover. 73 Table of Contents 75 1. Introduction ................................................ 3 76 2. Conventions used in this document ............................ 3 77 3. Protocol Detail ............................................. 3 78 4. Handover process ............................................ 7 79 5. Security Considerations ...................................... 7 80 6. IANA Considerations ......................................... 7 81 7. Conclusions ................................................. 7 82 8. References .................................................. 7 83 8.1. Normative References .................................... 7 84 8.2. Informative References .................................. 7 85 9. Acknowledgments ............................................. 8 86 1. Introduction 88 The Mobile IPv6 (MIPv6) can be used to support the IP handover in 89 Mobile networks [1]. However, there are still a lot of challenging 90 issues to be addressed in the MIPv6. One of them is how to reduce the 91 modification of mobile node (MN). For example, to perform the 92 mobility management signaling, each MN should be equipped with the 93 MIPv6 functionality. Such a protocol is referred to 'host-based 94 mobility management' protocol. 96 In the wireless network environment, however, it is not effective 97 that each MN performs the MIPv6 because of the short of resource in 98 wireless network such as link bandwidth or MM power. Above all, it is 99 not easy for MN to implement any mobility software such as MIPv6. 101 Recently, the Proxy Mobile IPv6 (PMIPv6) protocol provides the 102 network-based IP mobility management protocol. In PMIPv6, the mobile 103 agent located in the network will perform the mobility signaling 104 instead of MN and will keep track of the movement of MN. 106 It is noted that PMIPv6 is used mainly for binding update of the 107 location of MNs. A recent work has been made on the PMIPv6 handover. 108 However, there are still lots of issues that need to be solved in the 109 perspective of seamless handover. 111 This document describes a new handover scheme of PMIPv6 with 112 bicasting for seamless IP handover, in which the PMIPv6 Local 113 Mobility Agent (LMA) will bicast the data packets to the Previous- 114 Mobile Access Gateway (P-MAG) and New-Mobile Access Gateway (N-MAG) 115 toward MN, when MN is in the handover region. 117 2. Conventions used in this document 119 In examples, "C:" and "S:" indicate lines sent by the client and 120 server respectively. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC-2119 [1]. 126 3. Protocol Detail 128 This document extends the PMIPv6 handover scheme, which can be used 129 to reduce the packet loss and handover latency during handover using 130 bicasting in the PMIPv6 network. 132 +---------+ 133 | LMA | 134 +---------+ 135 // \\ 136 // \\ 137 // \\ 138 +--------------+ +--------------+ 139 | // | | \\ | 140 | +--------+ | | +--------+ | 141 | | P-MAG | | | | N-MAG | | 142 | +--------+ | | +--------+ | 143 | || | | || | 144 |Data Packet #1| |Data Packet #2| 145 | || | | || | 146 | /----------\ | | /----------\ | 147 | | P-AN || | | N-AN || 148 | \----------/ | | \----------/ | 149 | \\ | | // | 150 | \\ | | // | 151 | \\ |-| // | 152 | \\ // | 153 | +------+ | 154 | | MN | | 155 | +------+ | 156 +------------------------------ + 158 Figure 1 Network Architecture 160 The reference network configuration for B-PMIPv6 domain is shown in 161 Figure 1. MN moves from P-MAG region to N-MAG region. This document 162 supposes that there is overlapping region between MAGs. When MN is in 163 the overlapping region, and then the LMA begins the bicasting of data 164 packets to the N-MAG as well as P-MAG. This bicasting is performed to 165 minimize the possibility of packet losses and handover latency during 166 handover, because it is possible that the MN receives the data packet 167 from whether P-MAG or N-MAG. 169 MN P-AN N-AN P-MAG N-MAG LMA 170 | | | | | | 171 | | | |==== Bi-Directional ==== | 172 | | | | Tunnel | 173 | | | | | | 174 |<======= Data Packet #1 ========== |<==== Data Packet #1 ====| 175 | | | | | | 176 | Report | | | | | 177 |-(MN ID,->| | | | | 178 |New AP ID)| | | | | 179 | | HO Initiate | | | 180 | |--(MN ID, New AP ID)--> | | | 181 | | | | Handover | | 182 | | | |--- Init -->| | 183 | | | | |--- PBU --> | 184 | | | | |(Bicasting | 185 | | | | | Init) | 186 | | | | | | 187 | | | | |<--- PBA ---| 188 | | | | |(Bicasting | 189 | | | | | Ack) | 190 | | | | Handover | | 191 | | | |<--- Ack ---| | 192 | | | | | | 193 |<============== Data Packet #2 ================ |<== Data == | 194 | | | | | Packet #2 | 195 | | | | | | 196 ~~~ | | | | | 197 ~~~ | | | | | 198 | MN-AN connection | AN-MAG connection | | 199 |<----- establish ---->|<----- establish ------> | | 200 | | | | |--- PBU --> | 201 | | | | |(Bicasting | 202 | | | | | Com) | 203 | | | | | | 204 | | | | |<--- PBA ---| 205 | | | | |(Bicasting | 206 | | | | | Com Ack) | 207 | | | | | | 208 |<===X=== Data Packet #1 =====X==== |<==X= Data Packet #1 =X==| 209 | | | | | | 211 Figure 2 B-PMIPv6 handover procedure 213 The operation of the B-PMIPv6 is shown as figure 2. First, when MN 214 moves to the bicasting region, it detects that a handover is imminent 215 and reports the identifications of itself (MN-ID) and the access 216 point (New AP ID) to which the MN is most likely to move. The MN ID 217 could be the NAI or a Link Layer Address (LLA), or any other suitable 218 identifier. This step is access technology specific, In some cases, 219 the Previous-Access Network (P-AN) will determine which AP ID the MN 220 is moving to. The P-AN, to which the MN is currently attached 221 indicates the handover of the MN to the P-MAG. Detailed definition 222 and specification of this message are outside the scope of this 223 document. 225 After P-MAG receives an HO Initiate, the P-MAG sends Handover 226 Initiate (HI) message to N-MAG where the HI message includes MN's IP 227 address that are both Proxy-CoA (P-CoA) and Home address (MN-HoA), 228 LMA address (LMAA) and MN's Identifier. The N-MAG receives HI message, 229 it should examine whether a tunnel to the LMA exists or not. If the 230 tunnel has not been established, it should establish the tunnel from 231 LMA. 233 To establish the tunnel, the N-MAG sends a PBU (Bicasting Init) 234 message to the LMA. It includes MN-Identifier and MN-HoA. 236 When the LMA receives the PBU (Bicasting Init) message, it creates a 237 new binding entry. If the LMA successfully processes the PBU 238 (Bicasting Init), it sets the tunnel with N-MAG for sending and 239 receiving data packets. After successful establishment of the tunnel, 240 the LMA sends a PBA (Bicasting Ack) message, it examines whether or 241 not the PBU (Bicasting Init) message was processed successfully. If 242 there is a failure, the PBA (Bicasting Ack) message indicates the 243 failure. On the other hand, N-MAG creates a tunnel to the LMA and 244 ensures that the packets with destination address as P-CoA are copied 245 and forwarded over the tunnel. It also creates a host route for 246 forwarding packets to the MN. The N-MAG sends a Handover Ack message 247 back to the P-MAG to indicate whether handover procedure was 248 successfully done or not. 250 When the MN connects to the new link, the MN establishes a physical 251 link connection with the New Access Network (N-AN), for example, 252 radio channel assignment, which is turn triggers the establishment of 253 a link-layer connection between the N-AN and N-MAG if not yet 254 established. An IP layer connection setup may be performed at this 255 time (e.g., PPP IPv6CP) or at a later time (e.g., stateful or 256 stateless auto address configuration). This step can be a substitute 257 for the UNA in [4], but since they are all access technology specific, 258 details are outside the scope of this document. And then the N-MAG 259 sends a PBU (Bicasting Completion) message to the LMA. This message 260 includes MN-Identifier and P-CoA of N-MAG. On reception of this BC 261 message, the LMA deletes the binding cache entry associated with the 262 P-MAG, and stop the bicasting (i.e., release the tunnel between LMA 263 and P-MAG). In response to PBU (Bicasting Completion) message, the 264 LMA sends PBA (Bicasting Completion Ack) message to the N-MAG. By 265 thus, the bicasting operations are completed. 267 4. Handover process 269 MAG is responsible for detecting the mobile node's movements to and 270 from the access link and for initiating binding registrations to the 271 mobile node's LMA. 273 275 5. Security Considerations 277 TBD 279 6. IANA Considerations 281 TBD 283 7. Conclusions 285 This document described an enhanced handover scheme on the PMIPv6 286 with bicasting, in which binding update is performed in advance and 287 then perform the bicasting of data packets to the N-MAG as well as P- 288 MAG. From the performance analytical results, we can see that the 289 proposed scheme reduces the packet losses and handover latency when 290 it is compared with the two existing PMIPv6 handover schemes by 291 performing bicasting data packets from LMA to MN during handover. 293 8. References 295 8.1. Normative References 297 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 298 Levels", BCP 14, RFC 2119, March 1997. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 8.2. Informative References 305 [2] D. Johnson, C. Perkins, and K. Arkko, "Mobility support in 306 IPv6", RFC 3775, June 2004. 308 [3] S. Gundavelli, K. Leung, V. Decarapalli, K. Chowdhury, and B. 309 Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 311 [4] R, Koodli, "Mobile IPv6 Fast Handover", RFC 5268, June 2008. 313 [5] H. Yokota, K. Chowdhury, B. Patil, and F. Xia, "Fast Handovers 314 for Proxy Mibile IPv6", Internet-Draft, July 2009. 316 [RFC 3775] D. Johnson, C. Perkins, and K. Arkko, "Mobility support in 317 IPv6", RFC 3775, June 2004. 319 [RFC 5213] S. Gundavelli, K. Leung, V. Decarapalli, K. Chowdhury, and 320 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 322 [RFC 5268] R, Koodli, "Mobile IPv6 Fast Handover", RFC 5268, June 323 2008. 325 9. Acknowledgments 327 This document was prepared using 2-Word-v2.0.template.dot. 329 Authors' Addresses 331 Ji In Kim 332 Kyungpook National University, KOREA 334 Email: jiin16@gmail.com 336 Seok Joo Koh 337 Kyungpook National University, KOREA 339 Email: sjkoh@knu.ac.kr