idnits 2.17.1 draft-sijeon-netlmm-fastro-pmip6-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 304. 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 : ---------------------------------------------------------------------------- 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 (February 14, 2008) is 5909 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) -- Looks like a reference, but probably isn't: 'RFC3775' on line 217 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-10 -- Possible downref: Normative reference to a draft: ref. '3' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Seil Jeon 3 Internet-Draft Univ. of Soongsil, Korea 4 Expires: August 14, 2008 Younghan Kim 5 Univ. of Soongsil, Korea 6 February 14, 2008 8 Fast Route Optimization for PMIPv6 handover 9 draft-sijeon-netlmm-fastro-pmip6-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 14, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 To solve the inefficient route problem of PMIPv6, a variety of 43 mechanisms were proposed. The mechanism was also proposed to support 44 PMIPv6 RO handover according mobile node's movements. Efficient 45 PMIPv6 RO handover SHOULD be considered to reduce handover latency 46 and to support communication with route optimization disabled mobile 47 node's remote node. In this draft, we proposed a mechanism that can 48 solve handover latency in PMIPv6 RO handover. And we introduce a few 49 of messages to apply proposed mechanism. 51 Table of Contents 53 1. Introduction.....................................................3 54 2. Terminology and Functional Components............................3 55 3. Protocol Operation...............................................5 56 4. Message Formats..................................................6 57 5. IANA Considerations..............................................6 58 6. Security Considerations..........................................6 59 7. Acknowledgment...................................................7 60 8. References.......................................................7 61 8.1. Normative References.........................................7 62 Author's Address....................................................8 63 Full Copyright Statement............................................9 64 Intellectual Property and Copyright Statements......................9 66 1. Introduction 68 In PMIPv6 domains[2], all data packets will always traverse a MN's 69 MAG and its LMA irrespective of location of the MN's remote node. 70 This results high packet delivery latency. To solve this problem, a 71 mechanism to provide an optimal route between two MNs within the same 72 PMIPv6 domain was proposed[3]. And they include the method, thiat is 73 called PMIPv6 RO handover, to support route optimization considering 74 MN's frequent movements. But, in this mechanism, packet resumption 75 latency with MN's remote node is not considered. In order to solve 76 the problem, we propose a mechanism that Fast Route Optimizaiton. It 77 also supports RO-disabled MN's remote node due to operator's policy. 79 2. Terminology and Functional Components 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [1]. 85 o Mobile Node (MN) 87 o Route Optimization (RO) 89 o Previous Mobile Access Gateway (pMAG) - The MAG that manages 90 mobility relaged signaling for a MN before handover. In this 91 document, a MAG and Access Router (AR) are collocated 93 o New Mobile Access Gateway (nMAG) - The MAG that manages mobility 94 related signaling for the MN after handover 96 o Mobile node's LMA (mnLMA) 98 o Correspondent node's MAG (cnMAG) 100 o Correspondent node's LMA (cnLMA) 102 o Fast Route Optimization (FRO) - The mechanism to reduce handover 103 latency mobile node will experice after mobile node's PMIPv6 RO 104 handover. 106 o FRO Init - It is used to know whether MN's remote node is 107 supporting FRO or not. 109 o FRO Update - It is used to create MAG-to-MAG tunnel between nMAGs 110 and cnMAG. 112 o FRO Advertisement - It is used to notify to cnMAG that the fact MN 113 is arrived to current MAG. As soon as cnMAG receives this message, 114 the packet delivered after changing destination IP of tunnel 115 interface without ack. 117 o FRO Complete - It is used to update cnLMA that the fact changed 118 MN's information. 120 o Context Transfer (CT) - It is transmitted by pMAG forecasting MN's 121 destination nMAG. This message include MN ID, MN home network 122 prefix and cnMAG IP. The nMAG performs FRO Update with cnMAG. 124 ---- Internet Backbone ---- 125 : : 126 : : 127 | | 128 +-------+ +-------+ 129 | mnLMA |--------------------| cnLMA | 130 +-------+ +-------+ 131 | | 132 | | 133 +-------+ | 134 | | | 135 +------+ +----+ +------+ +-------+ 136 |nMAG_1| |pMAG| |nMAG_2| | cnMAG | 137 +------+ +----+ +------+ +-------+ 138 : : 139 +----+ +----+ 140 | MN | -----> | CN | 141 +----+ +----+ 143 Figure 1: Reference architecture for fast route optimization in 144 PMIPv6 domain 146 3. Protocol Operation 148 nMAG_1 pMAG mnLMA nMAG_2 cnLMA cnMAG 149 | | | | | | 150 | Link_Going_Down | | | | 151 | |-FRO Init->| | | | 152 | | |------ FRO Init ------>| | 153 | | | | | | 154 | | |<---- FRO Init Ack ----| | 155 | |<-FRO Init-| | | | 156 | | Ack | | | | 157 | | | | | | 158 | Disconnect | | | | 159 |<--- CT ---|--- CT --->| | | | 160 | | | | | | 161 |--------------------- FRO Update ------------------------->| 162 | | | | | | 163 | | | |----- FRO Update ----->| 164 | | | | | | 165 |<-------------------- FRO Update Ack ----------------------| 166 | | | | | | 167 | | | |<---- FRO Update Ack --| 168 | | | | | | 169 | | | MN_Attach | | 170 | | |<-- PBU ---|-- FRO Advertisement-->| 171 | | | | | | 172 | | |--- PBA -->|=======================| 173 | | | | packet delivered | 174 | | | | via optimized route | 175 | | | | | | 176 | | | | |<-- FRO ---| 177 | | | | | Complete | 178 | | | | | | 179 | | | | | --FRO --->| 180 | | | | | Complete | 181 | | | | | Ack | 182 | | | | | | 184 Figure 2: Fast Route Optmization for PMIPv6 handover procedure 186 The pMAG initiate the FRO Init process by L2 trigger, which notify 187 link will be down. The link event information indicates the MN will 188 soon be handed over from one MAG to another MAG. Then, mnLMA transmit 189 FRO Init to the cnLMA. If the cnLMA does not support FRO due to oper- 190 ator's policy, the cnLMA responds to mnLMA FRO rejection. As soon as 191 the pMAG receives L2 trigger that current MN's link is disconnected, 192 pre-updating processes are performed. 194 The nMAGs which received handover context message perform FRO Update 195 to establish nMAGs-to-cnMAG tunnel. After that, MN ID is created in 196 FRO binding list table. The nMAGs have timer to count from the time 197 received FRO Update Ack to the time MN is handed over. If MN handed 198 over the nMAG_2 of them, the nMAG_2 detecting MN's attachment trans- 199 mits Proxy Binding Update to mnLMA. At once, the nMAG_2 sends FRO 200 Advertisement to the cnMAG if received MN ID is in FRO binding list 201 table. After that, a MAG-to-MAG tunnel activated between nMAG_2 and 202 cnMAG. If the other nMAGs does not receive L2 signal notifying MN's 203 arrival, pre-established tunnel and MN ID in FRO binding list table 204 are deleted. Since FRO Ack process has been completed, data communi- 205 cation is available using optimized route. And FRO Complete procedure 206 is performed to inform the result of MN's handover to each LMA. So, a 207 MN can reduce communication resumption latency. 209 4. Message Formats 211 To suit the format of the Proxy MIPv6 messages, FRO Init, FRO Update 212 and FRO Advertisement, FRO Complete messages are encoded according to 213 the message data encoding rules for the Mobility Header (MH) as spec- 214 ified in [RFC3775]. Messages for RO are extensions to [I-D.ietf- 215 netlmm-proxymip6] and identified by the MH Type. Parameters being 216 carried by any of these messages are encoded as message options 217 according to the type-length-value format specified in [RFC3775]. 218 Specified about the message and message option format are TBD. 220 5. IANA Considerations 222 TBD. 224 6. Security Considerations 226 This document does not discuss any special security concerns in 227 detail. The protocol of this document is built on the assumption 228 that all participating nodes are trusted each other as well as there 229 is no adversary who modifies/injects false messages to corrupt the 230 procedures. 232 7. Acknowledgment 234 Funding for the RFC Editor function is provided by the IETF Adminis- 235 trative Support Activity (IASA). 237 8. References 239 8.1. Normative References 241 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 242 Levels", BCP 14, RFC 2119, March 1997. 244 [2] Gundavelli, S., "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 245 (work in progress), February 2008. 247 [3] Abeill, J., "Route Optimization for Proxy Mobile IPv6", draft- 248 abeille-netlmm-proxymip6ro-01 (work in progress), November 2007. 250 Author's Addresses 252 Seil Jeon 253 University of Soongsil in Seoul 254 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 255 Dongjak-Gu, Seoul 156-743 Korea 256 Phone: +82 2 814 0151 257 E-mail: sijeon@dcn.ssu.ac.kr 259 Younghan Kim 260 University of Soongsil in Seoul 261 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 262 Dongjak-Gu, Seoul 156-743 Korea 263 Phone: +82 2 820 0904 264 E-mail: yhkim@dcn.ssu.ac.kr 266 Full Copyright Statement 268 Copyright (C) The IETF Trust (2008). 270 This document is subject to the rights, licenses and restrictions 271 contained in BCP 78, and except as set forth therein, the authors 272 retain all their rights. 274 This document and the information contained herein are provided on an 275 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 276 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 277 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 278 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 279 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 280 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 282 Intellectual Property Statement 284 The IETF takes no position regarding the validity or scope of any 285 Intellectual Property Rights or other rights that might be claimed to 286 pertain to the implementation or use of the technology described in 287 this document or the extent to which any license under such rights 288 might or might not be available; nor does it represent that it has 289 made any independent effort to identify any such rights. Information 290 on the procedures with respect to rights in RFC documents can be 291 found in BCP 78 and BCP 79. 293 Copies of IPR disclosures made to the IETF Secretariat and any 294 assurances of licenses to be made available, or the result of an 295 attempt made to obtain a general license or permission for the use of 296 such proprietary rights by implementers or users of this 297 specification can be obtained from the IETF on-line IPR repository at 298 http://www.ietf.org/ipr. 300 The IETF invites any interested party to bring to its attention any 301 copyrights, patents or patent applications, or other proprietary 302 rights that may cover technology that may be required to implement 303 this standard. Please address the information to the IETF at ietf- 304 ipr@ietf.org.