idnits 2.17.1 draft-wakikawa-mext-haha-interop2008-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (July 8, 2008) is 5768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'ID-HAHA' on line 364 looks like a reference -- Missing reference section? 'ID-HAHAPROTO' on line 368 looks like a reference -- Missing reference section? 'PAPER-CONEXT' on line 380 looks like a reference -- Missing reference section? 'INTEROP-TOKYO' on line 385 looks like a reference -- Missing reference section? 'WIDE' on line 387 looks like a reference -- Missing reference section? 'SHISA' on line 389 looks like a reference -- Missing reference section? 'RFC-5142' on line 271 looks like a reference -- Missing reference section? 'RFC-3775' on line 342 looks like a reference -- Missing reference section? 'RFC-3963' on line 345 looks like a reference -- Missing reference section? 'RFC-2991' on line 352 looks like a reference -- Missing reference section? 'RFC-3753' on line 349 looks like a reference -- Missing reference section? 'RFC-4885' on line 355 looks like a reference -- Missing reference section? 'RFC-4888' on line 358 looks like a reference -- Missing reference section? 'RFC-4889' on line 361 looks like a reference -- Missing reference section? 'ID-AEROREQ' on line 372 looks like a reference -- Missing reference section? 'ID-AUTOREQ' on line 376 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group R. Wakikawa (Editor) 3 Internet-Draft Toyota ITC 4 Intended status: Informational K. Shima 5 Expires: January 9, 2009 IIJ Research Laboratory 6 N. Shigechika 7 Keio University 8 July 8, 2008 10 The Global HAHA Operation at the Interop Tokyo 2008 11 draft-wakikawa-mext-haha-interop2008-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 9, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes the protocol design consideration of the 45 correspondent router for the NEMO Basic Support Protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Operational Configuration . . . . . . . . . . . . . . . . . . 4 53 3. Global HAHA Protocol . . . . . . . . . . . . . . . . . . . . . 5 55 4. Experimentation Result . . . . . . . . . . . . . . . . . . . . 9 57 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 11 62 A.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 A.2. Informative References . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . . . 14 68 1. Introduction 70 The Global HAHA protocol [ID-HAHA] has been discussed for long time 71 in MIP6, NEMO and now MEXT working group. We have published several 72 documents [ID-HAHA] [ID-HAHAPROTO] and presented several time in IETF 73 meetings. We implemented a protocol for the global HAHA and tested 74 it in the real networks. Some results can be found in [PAPER- 75 CONEXT]. 77 We have tested a Global HAHA protocol at the Interop Tokyo 2008 78 [INTEROP-TOKYO]. The Interop is a global event of the networking 79 products and services. There are more than 300 exhibitors and about 80 150,000 visitors in this year. In the Interop Tokyo, the Network 81 Operation Center (NOC) team builds an experimental advanced network 82 called "ShowNet" as a backbone of the event. The experimental 83 network was connected to several peering points (Internet Exchange 84 Point) by more than 120G bps links in this year. Our global HAHA 85 experimentation was served as a part of "ShowNet". 87 As additional information, the WIDE project [WIDE] is operating the 88 global HAHA testbed with IIJ and other network operators. The three 89 home agents are configured in Tokyo, Los Angeles, and Seoul. We have 90 a dedicated autonomous system number (AS4690) for this 91 experimentation and operates the huge block of prefix (/35) as a home 92 prefix. 94 2. Operational Configuration 96 In the Interop Tokyo 2008, we setup two home agents in the ShowNet. 97 Figure 1 is the overview of ShowNet. More detail topology can be 98 found in [INTEROP-TOKYO]. In the event, we used 6 halls for the 99 exhibits and one conference hall for the tutorial and technical 100 sessions. In ShowNet, two NOCs (operational center) were located in 101 both Hall2 and Hall4. We configured the home agents in both NOCs. 103 For IP anycast routing, the upper router of the home agent advertise 104 the routes of the home prefix by OSPF with equal cost. The home 105 agents did not advertise the route by themselves. If a mobile node 106 attaches to the networks in the hall 1 to 3, it associates with the 107 home agent in the Hall-2 (HA1 in Figure 1). Otherwise, the mobile 108 node registers to the home agent in the Hall-4 (HA2). 110 Internet 111 Server Segement || Segement 112 in Hall-1-3 || in Hall-4-6 113 | || | 114 |--------- BackBone ----------| 115 HA1 ---+ / \ +--- HA2 116 | / \ | 117 | | 118 | | 119 Segments Segments 120 in Hall-1-3 in Conference-Hall 122 Figure 1: SHOWNET Overview and HAs Location 124 Implementation informations: 126 For the home agents, we uses the NetBSD current version (20080128). 127 The global HAHA is implemented on top of the SHISA package [SHISA]. 129 For the mobile nodes, we prepare two different operating systems. 130 One is NetBSD current (20080128) with the SHISA package. Another is 131 Ubuntu LINUX and MIPL package. The SHISA and MIPL packages were 132 modified to support the Home Agent Switch message [RFC-5142]. We 133 setup 6 NetBSD machines (ThinkPAD) and also distributed the virtual 134 machine image for the Ubuntu mobile node to the experimentation 135 participants. The mobile nodes for this experimentation was not open 136 to the public users due to security reason, because the mobile node 137 was grant for the permission to access the ShowNet. 139 3. Global HAHA Protocol 141 We describe a global HAHA protocol implementing on NetBSD SHISA 142 package in this section. This protocol is defined as an extension to 143 the Home Agent Reliability protocol. Figure 2 shows the protocol 144 sequence of the Global HAHA. Some new terms are introduced to 145 explain the protocol as follows: 147 Global Home Agent Set 149 The set of home agents serving the same home prefix. The home 150 agents can be located in different locations. 152 HAHA link 154 For the global HAHA, each home agent maintain a link to other home 155 agents. The link can be IP-in-IP tunnel, some L2 technology like 156 L2TP or even direct dedicated link. If the HAHA link is a 157 dedicated fiber link, the global HAHA can be easily operated 158 without any complexity or protocol extensions described in this 159 section. 161 Primary Home Agent 163 The home agent which a mobile node is currently registering. This 164 primary home agent must be the closest home agent of the mobile 165 node. The primary home agent is defined per a mobile node. 167 Initial Binding Registration (1-2 in Figure 2) 169 As Mobile IPv6 [RFC-3775] and the NEMO Basic Support protocol [RFC- 170 3963], the mobile node attempts the binding registration to its home 171 agent. In the global HAHA, the binding update is routed to the 172 closest home agent of the mobile node by IP anycast routing. The 173 home prefix is advertised from different location by anycast 174 technology. As soon as the primary home agent (HA1) creates a 175 binding cache for the mobile node, it sends a Binding Notification 176 message to the other home agents (HA2) in the same global home agent 177 set. 179 HA2 creates a host route to the mobile node with the next hop set to 180 the HAHA link of HA1 and HA2. For a mobile router, it can be the 181 network route to the mobile network prefix of the mobile router. 182 With that route, when HA2 receives the traffic meant to the mobile 183 node, it can forward the traffic to the HA1 over the HAHA link. The 184 route must be maintained with the lifetime and should be available 185 while the binding is active on the HA1. How to maintain the host 186 route is out of scope in this document. In our implementation, we 187 use the same lifetime of the binding cache entry at HA1. Therefore, 188 whenever HA1 receives a binding update from the mobile node for 189 extending the binding lifetime , it also sends another Binding 190 Notification message to the HA2. There might be scalable issue for 191 this periodic update approach, but we can fix this. For example, the 192 route on HA2 is activated until the HA1 sends a new signaling 193 indicating the route deletion (on-demand management). 195 MN HA1 HA2 CN 196 | | | | 197 |----> (Primary) | | 1. Binding Registration (HA1) 198 | |-------->| | 2. Binding Notification 199 |<========|<========|<--------| 3. From CN to MN 200 |========>|------------------>| 4. From MN to CN 201 | | | | 202 : : : : MN MOVEMENT 203 | | | | 204 |------------------+| | 5. Binding Registration 205 | |<=======+| | 206 |<--------| | | 6. Home Agent Switch 207 |--------------> (Primary) | 7. Binding Re-registration 208 | |<--------| | 8. Binding Notification 209 |<==================|<--------| 9. From CN to MN 210 |==================>|-------->| 10. From MN to CN 211 | | | | 213 Figure 2: Overview of Global HAHA 215 Binding Update after Movement (5-8 in Figure 2) 217 After the mobile node changes its point of attachment, it sends a 218 Binding Update to renew its binding as [RFC-3775]. In this case, if 219 the closest home agent is changed to HA2, the Binding Update is 220 arrived at the HA2 according to the IP anycast routing. The primary 221 home agent of the mobile node is changed from HA1 to HA2. However, 222 the destination address of the Binding Update is still the address of 223 the HA1 because the mobile node is unaware of the primary home agent 224 change. Therefore, the HA2 forwards the Binding Update to the HA1 225 over the HAHA link. The HA1, then, detects that the primary home 226 agent is now changed to the HA2 because the Binding Update is 227 forwarded from the HA2. It first processes the Binding Update and 228 returns a Binding Acknowledgment to the mobile node. In parallel, it 229 triggers a Home Agent Switch message [RFC-5142] to the mobile node. 230 In the Home Agent switch message, the address of the HA2 is stored in 231 the Home Agent Address field. 233 When the mobile node receives the Home Agent Switch message from the 234 HA1, it processes it according to [RFC-5142] and switches its home 235 agent to the HA2. The mobile node sends another Binding Update to 236 the HA2. After receiving the Binding Update, the HA2 creates the 237 binding cache and sends a Binding Notification message to the other 238 Home Agents (i.e. HA1) in the global home agent set. The HA1 239 removes the binding cache entry of the mobile node and creates the 240 route for the mobile node with the next hop set to the HA2 over the 241 HAHA link. 243 Figure 3 shows the new message named "Binding Notification message". 244 This message is used for the active home agent to notify the mobile 245 node registration to the other home agents in the global home agent 246 set. 248 Routing Packets (3-4, 9-10 in Figure 2) 250 The packets originated by the mobile node are always routed through 251 the primary home agent as shown in Figure 2. They are tunneled to 252 the primary home agent to which the mobile node is currently 253 registering and, then, routed directly to the CN. The primary home 254 agent does not have the state of the correspondent node and cannot 255 forward the packets to the closest home agent of the correspondent 256 node. 258 On the other hand, the packets originated by the correspondent node 259 are routed to the closest home agent by IP anycast routing. If the 260 home agent is not the active home agent of the mobile node 261 (destination), the home agent looks up the routing table and routes 262 them to the active home agent of the mobile node over the HAHA link. 263 Then, the active home agent routes the packets to the mobile node 264 over the bi-directional tunnel. 266 Mobile Node/Router Requirements 268 For mobile nodes and mobile routers, no modification specific to the 269 global HAHA is required. In addition to [RFC-3775] and [RFC-3963], 270 the Home Agent Switch message is required. It is already 271 standardized as [RFC-5142]. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | PfxLen | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 + + 280 | | 281 + Target Addresses + 282 | | 283 + + 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: Binding Notification Message 289 Type 291 8-bit unsigned integer. 293 PfxLen 295 The length of the Prefix. If the message is for a home address, 296 the prefix length is set to 128. 298 Target Address 300 This field is set to either Home Address or Mobile Network Prefix 302 4. Experimentation Result 304 During the five days event, the global HAHA was successfully 305 operated. We had about 30 mobile nodes registering to our home 306 agents. For the network setting, we needed special consideration on 307 the configurations of IP anycast routing. When we setup the IP 308 anycast for the home prefix, the upper routers of both home agents 309 advertise the home prefix with equal OSPF cost. If a router receives 310 two different routing updates for the same prefix with the equal 311 cost, it often operates the equal-cost multipath routing. This is a 312 natural behavior of most of routers today when multiple routes for a 313 same prefix with an equal cost are received. In our experimentation, 314 if the router switches the nexthop for the home prefix in the round- 315 robin fashion, the mobile node sometime switched the active home 316 agent per binding update. In order to avoid the equal-cost multipath 317 routing, we set the static route to these routers who is receiving 318 the equal cost routes by OSPF. The equal-cost multipath routing is 319 discussed in [RFC-2991]. 321 The IP anycast must be carefully configured for the global HAHA 322 specially when multiple home agents are distributed in the same 323 autonomous system due to the equal-cost multipath routing. The IP 324 anycast routing of the global HAHA is not effected to other parts of 325 networks. The influence to the networks is only limited to the home 326 network (i.e. Mobile IPv6 or NEMO operations). 328 5. IANA considerations 330 This document does not require any IANA action. 332 6. Security Considerations 334 Security vulnerability is not introduced in this specification. 336 Appendix A. References 338 A.1. Normative References 340 A.2. Informative References 342 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 343 in IPv6", RFC 3775, June 2004. 345 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 346 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 347 January 2005. 349 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 350 RFC 3753, June 2004. 352 [RFC-2991] D. Thaler and C. Hopps, "Multipath Issues in Unicast and 353 Multicast Next-Hop Selection", RFC 2991, November 2000. 355 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 356 Terminology", RFC 4885, July 2007. 358 [RFC-4888] C. Ng, et. al, "Network Mobility Route Optimization 359 Problem Statement", RFC 4888, July 2007. 361 [RFC-4889] C. Ng, et. al, "Network Mobility Route Optimization 362 Solution Space Analysis", RFC 4889, July 2007. 364 [ID-HAHA] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA 365 to HA protocol", draft-thubert-mext-global-haha-00.txt (Work in 366 Progress), March 2008 368 [ID-HAHAPROTO] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter 369 Home Agents Protocol Specification", 370 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), March 2006. 372 [ID-AEROREQ] W. Eddy, et. al,"NEMO Route Optimization Requirements 373 for Operational Use in Aeronautics and Space Exploration Mobile 374 Networks", draft-ietf-mext-aero-reqs-02.txt, May 2008. 376 [ID-AUTOREQ] R. Baldessari, et. al, "Automotive Industry Requirements 377 for NEMO Route Optimization", 378 draft-ietf-mext-nemo-ro-automotive-req-00.txt, February 2008. 380 [PAPER-CONEXT] Ryuji wakikawa, Guillaume Valadon, Jun Murai., 381 "Migrating Home Agents towards Internet-Scale Mobility Deployments", 382 ACM 2nd CoNEXT Conference on Future Networking Technologies, Lisbon, 383 Portugal. 4-7 December 2006 385 [INTEROP-TOKYO] http://www.interop.jp/ (2008, July) 387 [WIDE] http://www.wide.ad.jp/ (2008, July) 389 [SHISA] http://sourceforge.net/projects/shisa/ (2008, July) 391 Authors' Addresses 393 Ryuji Wakikawa 394 Toyota ITC / Keio University 395 6-6-20 Akasaka, Minato-ku 396 Tokyo 107-0052 397 Japan 399 Phone: +81-3-5561-8276 400 Fax: +81-3-5561-8292 401 Email: ryuji@jp.toyota-itc.com 403 Keiichi Shima 404 Research Laboratory, Internet Initiative Japan Inc. 405 Jinboucho Mitsui Building 406 1-105 Jinboucho, Kanda 407 Chiyoda-ku, Tokyo 101-0051 408 JAPAN 410 Phone: +81 3 5205 6464 411 Email: keiichi@iijlab.net 412 URI: http://www.iij.ad.jp/ 413 Noriyuki Shigechika 414 Keio University 415 Department of Environmental Information, Keio University. 416 5322 Endo 417 Fujisawa, Kanagawa 252-8520 418 Japan 420 Phone: +81-466-49-1100 421 Fax: +81-466-49-1395 422 Email: nazo@sfc.wide.ad.jp 424 Full Copyright Statement 426 Copyright (C) The IETF Trust (2008). 428 This document is subject to the rights, licenses and restrictions 429 contained in BCP 78, and except as set forth therein, the authors 430 retain all their rights. 432 This document and the information contained herein are provided on an 433 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 434 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 435 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 436 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 437 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 438 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 440 Intellectual Property 442 The IETF takes no position regarding the validity or scope of any 443 Intellectual Property Rights or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; nor does it represent that it has 447 made any independent effort to identify any such rights. Information 448 on the procedures with respect to rights in RFC documents can be 449 found in BCP 78 and BCP 79. 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 458 The IETF invites any interested party to bring to its attention any 459 copyrights, patents or patent applications, or other proprietary 460 rights that may cover technology that may be required to implement 461 this standard. Please address the information to the IETF at 462 ietf-ipr@ietf.org. 464 Acknowledgment 466 Funding for the RFC Editor function is provided by the IETF 467 Administrative Support Activity (IASA).