idnits 2.17.00 (12 Aug 2021) /tmp/idnits51349/draft-hkang-nemo-ro-tlmr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 218 has weird spacing: '...set, it indic...' == Line 240 has weird spacing: '...LMR and updat...' == Line 324 has weird spacing: '... to the home ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: P 1-bit parent mobile router flag. When set, it indicates that this message contains the CoA of the parent mobile router. The CoA of the parent mobile router is used for tunneling between TLMR and the parent mobile router. T flag and P flag SHOULD not be set at the same time. -- 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 (June 2003) is 6915 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) == Unused Reference: '2' is defined on line 350, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 353, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 356, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 359, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 362, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 366, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 369, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '7') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 -- Duplicate reference: draft-ietf-nemo-terminology, mentioned in '8', was also mentioned in '4'. ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '8') Summary: 7 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission 2 Internet Draft Hyunsik Kang 3 Document: draft-hkang-nemo-ro-tlmr-00.txt Keecheon Kim 4 Sunyoung Han 5 Konkuk University 6 Kyeong-Jin Lee 7 Jung-Soo Park 8 ETRI 9 Expires: December 20023 June 2003 11 Route Optimization for Mobile Network by Using Bi-directional 12 Between Home Agent and Top Level Mobile Router 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 except that the right to 18 produce derivative works is not granted [1]. 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 Abstract 38 This document shows how to route optimization by using bi-directional 39 tunnel between home agent and top level mobile router. A packet will 40 be transmitted directly from the home link of the mobile node to top 41 level mobile router of the correspondent node through this tunnel. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119. 49 Table of Contents 51 1. Introduction...................................................2 52 2. Overview.......................................................2 53 3. Mobile Router extension : mobile router of mobile subnetwork...3 54 4. Mobile Router extension : Top level mobile router..............4 55 5. Home agent extension for Mobile Router.........................4 56 6. New RA message and mobility option.............................4 57 6.1 RA message with TLMR option................................4 58 6.2 New mobility option........................................5 59 7. Procedure of Route Optimization................................6 60 7.1 Receiving RA message from TLMR.............................6 61 7.2 Registration to TLMR and binding update to home agent with 62 TLMR address...................................................7 63 7.3 Delivery of Data Packets...................................7 64 7.3.1 CN transmit to MN (or Fixed Node in MR)7 65 7.3.2 MN (or Fixed Node in MR) transmits to CN 7 66 Security Considerations...........................................8 67 References........................................................8 68 Author's Addresses................................................8 70 1. Introduction 72 The basic support of mobile network (NEMO) enables mobile network 73 nodes and correspondent nodes to communicate through bi-directional 74 tunnels. However, using MIPv6 for mobile network will introduce a 75 problem of dog-leg routing. In order to communicate from foreign 76 networks with mobile nodes, packets are usually transmitted via the 77 home link of the mobile node. Dog-leg routing may cause a 78 transmission latency, this subsequently causes the difficulty for a 79 real time service and the delay in binding update. This document 80 specifies how we can optimize the routing in NEMO [2]-[4]. 82 2. Overview 84 A possible solution to routing optimization is to make tunnels 85 between top level mobile router of NEMO and home agent of each mobile 86 router. When a mobile node detects an access to a foreign network, a 87 mobile router does binding update to home agent. At this time, mobile 88 router detects IP address of the top level mobile router(TLMR) by 89 router advertisement extension message(see figure 1.). And then, the 90 mobile router registers to TLMR and notifies address of TLMR to its 91 own home agent. When TLMR receives a registration message from the 92 mobile router, it detects a relationship between mobile router and 93 its access router. From this information, TLMR forms a mobile 94 sub-network topology table. Using this table, TLMR creats a tunnel to 95 each mobile router, if necessary, to communicate with mobile router. 96 This tunnel is used by the encapsulated packets to be transmitted 97 between TLMR and mobile router. (see Section 7.4) 99 +-----+ 100 |TLMR | 101 RA(TMLR) |+--+--+ 102 V | 103 ----------+---------------+-------------+----------- Link1 104 | | 105 +-+-+ +-+-+ 106 |MR1| |MR2| 107 RA(MR1+TLMR) | +-+-+ RA(MR2+TLMR)| +-+-+ 108 V | V | 109 ---+-----+-----+--- Link2 ---+------+-----+--- Link3 110 | | | | 111 +-+-+ +-+-+ +-+-+ +-+-+ 112 |MN1| |FN1| |MN2| |MR3|RA(MR3+TLMR) 113 +---+ +---+ +---+ +---+ | 114 | V 115 Link4 ---+-----+-----+--- 116 | | 117 +-+-+ +-+-+ 118 |MN3| |FN2| 119 +-+-+ +-+-+ 121 Figure 1. Routing advertisement message extension for route optimize 123 *********** 124 +///////////+ |#########|###########+ FN2 125 CN ----------------|===========+=+=========+===========+-------- 126 +///////////+ |#########|###########+ 127 *********** MR3 128 MR3_HA TLMR MR2 130 ------- : original packet 131 +=====+ : tunneling between HA of MR3 and MR3 132 +/////+ : tunneling between HA of MR3 and TLMR 133 +#####+ : tunneling between TLMR and MR3 134 +*****+ : tunneling between TLMR and MR2 136 Figure 2. all tunneling model of RO solution 138 3. Mobile Router extension : mobile router of mobile subnetwork 140 Mobile router MUST relay extended router advertisement message of 141 TLMR that has been transmitted from its parent mobile router to its 142 child mobile router. If a mobile router receives an extended router 143 advertisement message of TLMR, it MUST notify the TLMR's address to 144 its own home agent to set up a direct tunnel between the home agent 145 and TLMR. The mobile router registers its address and the address of 146 its parent router to TLMR to set up a tunnel between TLMR and mobile 147 router. 149 When a mobile router receives a packet from its children nodes, if 150 the packet's destination address is TLMR, then the mobile router does 151 encapsulation to make the destination address to be TLMR, not its 152 home agent. This makes a direct communication between mobile router 153 and TLMR. Therefore, this packet doesn't have to pass the home agent 154 of the parent mobile router. 156 4. Mobile Router extension : Top level mobile router 158 If the mobile router doesn't receive an extended router advertisement 159 with TLMR option, it becomes a TLMR. The TLMR MUST advertise that it 160 is TLMR by an extentded router advertisement message with TLMR option 161 (see Section 6.1). When a mobile router receives this message, it 162 requests a registration to TLMR by sending registration request 163 message. This message includes its address and the address of the 164 access router(parent router). When the TLMR recieves a registration 165 request message, if it accepts the registration, it determines the 166 path to mobile router from the addresses in this message. 168 Based on this routing information, TLMR decides how to encapsulate 169 the packet to the mobile router or a home agent of a mobile router. 171 5. Home agent extension for Mobile Router 173 The home agent of mobile router SHOULD bind the CoA of the mobile 174 router and address of TLMR of the mobile router from new binding 175 update message which has the TLMR address option. The home agent 176 SHULD adds TLMR field to its own binding table. This field is used 177 for encapsulating a pakcet to TLMR. When a home agent receives a 178 packet to the mobile router, it SHOULD encapsulate the packet to send 179 to the CoA of the mobile router. But, for a route optimization, the 180 home agent SHOULD perform one more encapsulation to have its 181 destination address is TLMR. Similarly, when a home agent receives a 182 packet from TLMR, it can find an original packet encapsulated by a 183 mobile router through decapsulating the packet encapsulated by TLMR 185 6. New RA message and mobility option 187 This approach needs some new message formats or options such as 188 router advertisement message, registration request message to TLMR, 189 and binding request message to home agent with TLMR address for route 190 optimization [5]-[8]. 192 6.1 RA message with TLMR option 193 The router advertisement messages with TLMR option is needed by a 194 mobile router to create a bi-directional tunnel between TLMR and the 195 home agent of mobile router. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | Prefix Length |L|A|R|T|P|Res 1| 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Valid Lifetime | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Preferred Lifetime | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Reserved2 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 + + 210 | | 211 + Address + 212 | | 213 + + 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Field: 218 T 1-bit TLMR flag. When set, it indicates that the 219 message contains the address of the TLMR 221 P 1-bit parent mobile router flag. When set, it 222 indicates that this message contains the CoA of 223 the parent mobile router. The CoA of the parent mobile 224 router is used for tunneling between TLMR and the 225 parent mobile router. 226 T flag and P flag SHOULD not be set at the same time. 228 Address This address is an address of the TLMR or parent 229 mobile router. 231 Figure 3. Modified Prefix Information Option Format for RO 233 When T flag is set, it indicates that this message includes the 234 address of the TLMR. This option is used by a mobile router to send 235 binding update to home agent and registration message to TLMR. 237 6.2 New mobility option 239 A modified binding update message is used when a mobile router 240 registers to TLMR and updates its binding to home agent. The TLMR 241 determines the path to the mobile router from the address in this 242 message. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type = 6 | Option Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 + + 251 | | 252 + Address + 253 | | 254 + + 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Field: 259 Address The address is an address of the parent mobile router 260 of the mobile router or CoA of TLMR. When this message 261 is used for registering to TLMR, this field contains 262 the CoA of parent mobile router. When TLMR needs to 263 send a packet, TLMR creats a tunnel to this address. 264 On the other hand, when this message is used for 265 sending binding update to home agent, this field 266 contains an address of TLMR. The home agent SHOULD 267 create a bi-directional tunnel to TLMR. 269 Figure 4. Modified binding update message 270 272 7. Procedure of Route Optimization 274 7.1 Receiving RA message from TLMR 276 A mobile router waits for an extended router advertisement message. 277 If the mobile router receives an extended router advertisement 278 message, it does binding update to TLMR and home agent with modified 279 binding update message. The mobile router MUST relay this message to 280 its child mobile router. 282 If the mobile router doesn't receive an extended router advertisement 283 message, it means the router is TLMR. The mobile router becomes TLMR, 284 and it sends an extended router advertisement message with the 285 address of TLMR which is the address of mobile router itself. 287 7.2 Registration to TLMR and binding update to home agent with TLMR 288 address 290 When the mobile router receives an extended router advertisement 291 message, it SHOULD register to TLMR and send binding update to its 292 home agent. 294 When TLMR receives a registration request message from a mobile 295 router, it makes a tunneling table to mobile router from this 296 message. The tunneling table is composed of mobile router and its 297 access router. When the home agent receives this binding update 298 message, it creates a bi-directional tunnel between the home agent 299 and TLMR, which will be used for direct communication without dog-leg 300 routing. 302 7.3 Delivery of Data Packets 304 7.3.1 CN transmit to MN (or Fixed Node in MR) 306 A correspondent node sends a packet to a node in mobile router, and 307 this packet goes to the home network of mobile router. The home agent 308 intercepts this packet, and encapsulates it to send to a mobile 309 router. In order to communicate with a mobile router directly, the 310 home agent encapsulates again to send the packet to TLMR. When TLMR 311 receives this packet, it decapsulates the packet. TLMR finds the 312 destination address to determine the path to the mobile router by 313 using the tunneling table. In order to send to a mobile router, TLMR 314 does encapsulation for ecah mobile routers that are between TLMR and 315 destination mobile router. In this way, TLMR sends a pakcet to a 316 mobile router. When a mobile router receives a packet, it first 317 decapsulates the packet encapsulated by TLMR, and it does one more 318 decapsulation encapsulated by its home agent. This packet will be 319 sent to the destination node. 321 7.3.2 MN (or Fixed Node in MR) transmits to CN 323 When a node in mobile network sends a packet to CN, this packet is 324 encapsulated by a mobile router to be sent to the home agent of 325 mobile router. The mobile router encapsulates the packet again to 326 directly communicate with TLMR. This packet goes to the parent mobile 327 router, the parent mobile router does encapsulation again for direct 328 communication with TLMR. Likewise, this packet is encapsulated by 329 each mobile router located between TLMR and mobile router. When this 330 packet arrives on TLMR, TLMR decapsulates all the encapsulation 331 headers made by intermediate mobile routers except for the 332 encapsulation made by the end-point mobile router. And then, TLMR 333 encapsulates the packet to send to the home agent of mobile router. 335 When the mobile router receives this packet, it decapsulates the 336 packet ecapsulated by the TLMR and end-point mobile router. The 337 packet decapsulated by home agent is the original packet that has 338 been sent to the correspondent node. 340 Security Considerations 342 The route optimization in this document does not add any other 343 security problems to the NEMO or Mobile IPv6. 345 References 347 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 348 9, RFC 2026, October 1996. 350 [2] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for 351 IP version 6", RFC 2461. 353 [3] Dave Thaler and Chistian Huitema, "Multi-link Subnet Support in 354 IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, June 2002. 356 [4] Thierry Ernst, "Network Mobility Support Terminology", draft- 357 ietf-nemo-terminology-00.txt, May 2003. 359 [5] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 360 draft-ietf-mobileip-ipv6-22.txt, May 2003. 362 [6] Ryuji Wakikawa, Keisuke Uehara, Koshiro Mitsuya, Thierry Ernst, 363 "Basic Network Mobility Support", draft-wakikawa-nemo-basic- 364 00.txt, Feb 2003. 366 [7] Thierry Ernst, "Network Mobility Support Goals and Requirements", 367 draft-ietf-nemo-requirements-01.txt, May 2003 369 [8] Thierry Ernst, Hong-Yon Lach, "Network Mobility Support 370 Terminology", draft-ietf-nemo-terminology-00.txt, May 2003 372 Author's Addresses 374 Hyunsik Kang 375 Department of Computer Science & Engineering, Konkuk University 376 Whayangdong 1, Kwangjin-ku 377 Seoul 143-701 378 Korea 380 Phone: +82 2 450 3518 381 EMail: bigbomb@konkuk.ac.kr 382 Keecheon Kim 383 Department of Computer Science & Engineering, Konkuk University 384 Whayangdong 1, Kwangjin-ku 385 Seoul 143-701 386 Korea 388 Phone: +82 2 450 3518 389 EMail: kckim@konkuk.ac.kr 391 Sunyoung Han 392 Department of Computer Science & Engineering, Konkuk University 393 Whayangdong 1, Kwangjin-ku 394 Seoul 143-701 395 Korea 397 Phone: +82 2 450 3537 398 EMail: syhan@cclab.konkuk.ac.kr 400 Kyeong-Jin Lee 401 ETRI / PEC 402 161 Gajong-Dong, Yusong-Gu 403 Daejon 305-350 404 Korea 406 Phone: +82 42 860 6484 407 EMail: leekj@etri.re.kr 409 Jung-Soo Park 410 ETRI / PEC 411 161 Gajong-Dong, Yusong-Gu 412 Daejon 305-350 413 Korea 415 Phone: +82 42 860 6514 416 EMail: pjs@etri.re.kr