idnits 2.17.1 draft-jiang-netext-ft-pmip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2012) is 4312 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) == Missing Reference: 'RFC2119' is mentioned on line 125, but not defined == Unused Reference: 'RFC6275' is defined on line 245, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Jiang 3 Intended Status: Proposed Standard Huawei 4 Expires: December 31, 2012 June 29, 2012 6 Fault Tolerant Support for The Multihomed MN in Proxy Mobile IPv6 7 draft-jiang-netext-ft-pmip-00 9 Abstract 11 Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility 12 management for mobile nodes (MN) in a local small area. If the 13 multihomed MN attaches to multiple MAGs by multiple links, then the 14 mobility session in each link is independent. As the ongoing 15 communication interface breaking down, the mobility session in the 16 link is also broke and the traffic packets are lost. This document 17 mainly proposes a fault tolerant scheme. When an interface of the 18 multihomed MN broke down, the fault tolerant scheme can be used to 19 handover the interface and realize the flow migration and maintain 20 the integrity of data transmission During the handover process. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 62 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Fault Tolerant Scheme . . . . . . . . . . . . . . . . . . . . 4 65 3.1 LMA Operation . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2 Fault Tolerant Handover . . . . . . . . . . . . . . . . . . 4 67 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 With the development of the Internet business, the customer cannot 76 obtain the consecutive and high quality communication service as 77 adopting one access technology to join the network. The emerging of 78 the new technologies results in the situation that the Mobile Node 79 (MN) can use multiple interfaces to access the network with multiple 80 technologies, which can be summarized as multihoming. Especially in 81 the future network, multihoming will absolutely be the necessary 82 technology and be used to increase the reliability of the network 83 application. In order to promoting the widespread deployment of the 84 MN, mobile operators should consider the mobility management in the 85 network. Thus the network based mobility management protocol - Proxy 86 Mobile IPv6 (PMIPv6) was proposed to fulfill the mobility management 87 requirements. 89 PMIPv6 network mainly includes two function entities: Mobile Access 90 Gateway (MAG) and Local Mobility Anchor (LMA). MAG takes the place of 91 MN to deal with the mobility relating signaling. Generally the first 92 hop router which MN is attaching takes this role. In the meanwhile 93 MAG SHOULD track the MN in the PMIPv6 domain. The number of MAGs in a 94 single domain is not limited. LMA SHOULD be responsible for 95 associating MN with MAG and storing all the routing information to 96 reach each MN. The Tunnel between LMA and MAG is used by MN to 97 transmit the traffic flow. 99 In PMIPv6, Binding Cache Entry (BCE) is created in LMA to binding the 100 MAG with MN. Each BCE entry is only corresponding to one mobility 101 session of the MN. If the multihomed MN attaches to multiple MAGs by 102 multiple links, then the mobility session in each link is 103 independent. When the ongoing communication interface breaking down, 104 the mobility session in the link is also broke and the traffic 105 packets are lost. LMA will remove the BCE entry that corresponding to 106 the interface, thus the multihomed MN cannot receive data packets 107 from this interface. Because MN does not involve in the signaling 108 handover, MAG is unable to distinguish whether the handover was 109 occurred between the two interfaces of the MN. 111 Based on the problem stated above, this document proposes a fault 112 tolerant scheme focusing on the multihomed MN in the PMIPv6 network. 113 Two aspects are considered: 1) when an interface of the multihomed MN 114 breaks down, the fault tolerant scheme can be used to handover the 115 interface; 2) the fault tolerant scheme can realize the flow 116 migration and maintain the integrity of data transmission in the 117 process of interface handover. 119 2. Requirements and Terminology 120 2.1 Requirements 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 [RFC2119]. 126 2.2 Terminology 128 All of the terminology used in this document are already defined in 129 [RFC5213]. 131 3. Fault Tolerant Scheme 133 3.1 LMA Operation 135 In order to achieve the interface handover for the multihomed MN 136 without transmission interruption, the data structure of the original 137 BCE table SHOULD be extended as follows: the multihoming flag and the 138 Status flag SHOULD be included in the new BCE entry. The multihoming 139 flag is used to identify if the MN is the multihomed. When the 140 multihomed MN joins the network, MAG is used to communicate with LMA 141 to register the location information for MN and sends the Proxy 142 Binding Update (PBU) message to LMA. LMA creates a BCE entry for each 143 interface of MN. If the received PBU messages from different MAGs 144 with the same MN-ID, the multihoming flag is set as 1; otherwise the 145 value is set as 0. The status flag is used to identify whether the 146 interface that the BCE entry corresponds is available, or whether the 147 state of the interface is in use. The value is set as 1 when the 148 interface is available; otherwise the value is set as 0. 150 3.2 Fault Tolerant Handover 152 Considering that the multihomed MN attaches MAG1 and MAG2 through 153 interface IF1 and IF2 respectively to join the PMIPv6 domain. After 154 the access authentication, LMA allocates the same HNP (HNP1) for IF1 155 and IF2. Then LMA creates the BCE entries Entry1 and Entry2. By 156 comparing the MN-ID of Entry1 and Entry2, LMA identifies that the MN- 157 ID of Entry1 and Entry2 is the same, which implies that Entry1 and 158 Entry2 belonging to the same MN. Then LMA associates Entry1 with 159 Entry2 by MN-ID to facilitate the lookup and storage. After that two 160 bi-direction data tunnel Tunnel1 and Tunnel2 are setup from LMA to 161 MAG1 and MAG2. LMA respectively send PBA messages to inform MAG1 and 162 MAG2. Afterwards MAG1 and MAG2 all send the Router Advertisement 163 messages to inform IF1 and IF2 to configure the IP address. Then the 164 multihomed MN actively communicates with Corresponding Node (CN) 165 through IF1. 167 When IF1 is breaking down, the data of CN sent from LMA to MAG1 168 cannot reach the MN, and then MAG1 begins to cache the data for MN; 169 At the same time MAG1 sends the DeReg PBU message to LMA for 170 informing the IF1 fault; After receiving the DeReg PBU message, LMA 171 begins to update the BCE entry; then LMA sends the PBA message to 172 MAG1; MAG1 forwards the cached data to LMA by Tunnel; then LMA checks 173 the BCE table and finds out that IF2 is available, so the cached data 174 are sent to MAG2 by Tunnel2; then CN will communicates with the 175 multihomed MN by Tunnel2. The detailed process is shown in Figure 1. 177 +----+----+ +------+ +------+ +------+ +----+ 178 | IF1| IF2| | MAG1 | | MAG2 | | LMA | | CN | 179 +----+----+ +------+ +------+ +------+ +----+ 180 | | | | | | 181 |IF1 is unreachable| CN sends packets to IF1 of MN by Tunnel1 | 182 |<-----------------|<---------------------------------------------| 183 | | | | | | 184 | | Caching data for MN | | | 185 | | | | | | 186 | | | MAG1 sends DeReg PBU to LMA | | 187 | | |----------------------------->| | 188 | | | | | | 189 | | | | Updating the BCE entry for MN | 190 | | | |------------------------------>| 191 | | | | | | 192 | | | LMA sends PBA to MAG1 | | 193 | | |<-----------------------------| | 194 | | | | | | 195 | | | MAG1 sends cached data to LMA| | 196 | | |----------------------------->| | 197 | | | | | | 198 | | MAG2 forwards the cached |LMA sends cached | 199 | | data to IF2 of MN | data to MAG2 | | 200 | |<---------------------------|<--------------| | 201 | | | | | | 202 | | CN communicates with the IF2 of MN by Tunnel2 | 203 | |<-----------------------------------------------------------| 204 | | | | | | 205 | | | | | | 206 Figure 1: the signaling process of interface handover 208 (1) CN sends the data packets to MN through the bi-direction Tunnel 209 between LMA and MAG1; 211 (2) MAG1 detects that IF1 is unreachable and begins to cache data 212 for MN; 214 (3) MAG1 sends the DeReg PBU message to LMA (see RFC5213) to 215 feedback; 217 (4) After receiving the DeReg PBU message, LMA updates the BCE entry 218 for the multihomed MN; 220 (5) LMA sends the PBA message to MAG1 for confirmation; 222 (6) MAG1 sends the cached data to LMA; 224 (7) The cached data from LMA will be forwarded to MAG2 through 225 Tunnel2 and reach the destination MN; 227 (8) CN keeps on sending data packets to MN through Tunnel2 between 228 LMA and MAG2. 230 4 Security Considerations 232 This document raises no new security issues for PMIPv6 network. 234 5 IANA Considerations 236 None 238 6 References 240 6.1 Normative References 242 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 243 and B. Patil, "Proxy Mobile IPv6", RFC5213, August 2008. 245 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 246 in IPv6", RFC6275, July 2011. 248 Authors' Addresses 250 Haisheng Jiang 251 Huawei Building, No.156 Beiqing Rd. 252 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 253 Beijing 100095 P.R. China 255 EMail: haisheng.jiang@huawei.com