idnits 2.17.1 draft-sarikaya-netext-fb-support-extensions-02.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 '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 and authors Copyright Line does not match the current year -- The document date (June 7, 2012) is 4334 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: 'RFC2629' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC5648' is defined on line 347, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-03 == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft F. Xia 4 Expires: December 9, 2012 Huawei 5 June 7, 2012 7 PMIPv6 Multihoming Support for Flow Mobility 8 draft-sarikaya-netext-fb-support-extensions-02 10 Abstract 12 This document specifies extensions to Proxy Mobile IPv6 (PMIPv6) for 13 flow mobility support. Binding cache, binding update list and home 14 network prefix option are slighlty extended to allow indicating the 15 home interface and other interfaces. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 9, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Multihoming Case . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. Extensions to Binding Cache Entry . . . . . . . . . . . . 5 57 6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6.1. Extensions to Binding Update List Entry Data Structure . . 7 59 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 11.2. Informative references . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 In Mobile IPv6 [RFC6275] multi-homing is supported efficiently due to 71 the use of home address. Mobile node uses its home address as the 72 source address and all incoming traffic is directed to the home 73 address (HoA). When multiple interfaces are concurrently active the 74 home agent (HA) has to decide how to route incoming packets to 75 different active interfaces. HA does this based on the flow 76 bindings. MN has to register its active flows with the HA and HA 77 keeps flow binding entries for each HoA. HA then forwards packets to 78 one of the care-of addresses of an active interface after matching it 79 with an ordered list of flow bindings. 81 Proxy Mobile IPv6 [RFC5213] lacks a similar mechanism because each 82 active interface is treated separately and a different binding cache 83 entry is created. This document proposes changes necessary to the 84 local mobility anchor (LMA) behaviour so that flow mobility can 85 seamlessly be supported in PMIPv6. The changes to the mobile node 86 considered in [I-D.ietf-netext-logical-interface-support] are also 87 needed to complement our solution on the host side. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 The terminology in this document is based on the definitions in 96 [RFC5213], [RFC6089] in addition to the ones specified in this 97 section: 99 Single-Radio MN: Consider MN with two interfaces. These interfaces 100 are implemented in such a way that MN can keep one radio module 101 (interface) active at a given time. 102 Dual/multiple-Radio MN: Consider MN with two interfaces. These 103 interfaces are implemented in such a way that both radio modules 104 can receive and transmit simultaneously. 105 Inter-technology handover: Sometimes called vertical handover. A 106 multi-homed MN communicates with one interface at any time to 107 conserve power. Each interface can support different access 108 technology. Inter-technology handover occurs when MN moves out of 109 coverage of one technology and moves into the coverage area of 110 another technology which will result in switching of the 111 communicating interface on MN 112 [I-D.ietf-netext-logical-interface-support]. 114 3. Problem Statement 116 In base Proxy Mobile IPv6 when MN connects simultaneously with 117 multiple interfaces each interface is treated independently and MN 118 uses different source addresses when sending packet over these 119 interfaces [RFC5213]. However in case of flow mobility, MN itself or 120 LMA might wish to move one flow from one interface to the other. 121 When a flow is moved from interface A to interface B, MN has to stop 122 sending packets on interface A, i.e. it should set the source address 123 to an address based on HNPs assigned to interface B. Forcing an MN to 124 do this after a flow is moved is difficult currently and is one of 125 the problems PMIPv6 flow mobility is facing. 127 The solution for this is to let MN always use a source address from 128 HNPs assigned to its home interface. When multiple interfaces are 129 active, incoming packets can be directed to different active 130 interfaces based on flow state established at LMA. 132 In based Proxy Mobile IPv6 LMA treats each interface independently of 133 the other interface(s) MN may have and tries to provide mobility 134 support for each interface. LMA does not manage bindings from 135 different interfaces of the mobile node in an integrated fashion. So 136 LMA can not be in control of moving the flows in between interfaces. 138 The solution to this is to modify the way the binding cache is 139 managed. Instead of creating an independent mobility session for 140 each interface, the bindings from each interface are kept together so 141 that the flows can be moved among interfaces. The extensions to the 142 base protocol needed for this should be minimal. 144 When MN does an inter-technology handover, the new MAG sends a Proxy 145 Binding Update (PBU) message to the local mobility anchor (LMA) to 146 register the new proxy care-of address. In the PBU, MAG sets the 147 access technology type (ATT) and handoff indicator (HI) values. If 148 ATT is different from the one stored in the existing binding cache 149 entry for this MN and if HI is set to 2 (Handoff between two 150 different interfaces of the mobile node), LMA concludes that an 151 inter-technology handover happened and assigns the same home network 152 prefix(es) to MN which enables IP session continuity. 154 Setting the handoff indicator correctly is also not so easy. Most 155 MAGs would tend to set HI to 1 (Attachment over a new interface) 156 which would result in LMA setting new prefix(es) to MN and creating a 157 new binding cache entry and allocating a new mobility session for 158 this new interface. This behaviour as described in Section 5.4 of 159 [RFC5213] needs to be changed. 161 4. Multihoming Case 163 When there is attachment over a new interface (HI value received in 164 the Binding Update from MAG is 1) LMA creates a new binding cache 165 entry and assigns the flag "S" defined in Section 5.1 to all home 166 network prefixes assigned to this interface. Also the corresponding 167 value is set to the (H) flag of the home network interface option 168 defined in Section 7 in the binding acknowledgement sent to MAG. LMA 169 MUST also include the home network prefixes with "H" flag in the BA 170 message. This should enable MN continue to send packets with source 171 addresses selected from HNPs with "H" flag on. 173 The new binding cache entry does not create a new mobility session. 174 The entry is considered as a pointer to another binding the same MN 175 has with LMA. MN may have as many such binding entries as it has 176 active interfaces. These secondary binding cache entries are 177 refreshed regularly by MAGs sending BUs. MAG MUST include HNPs both 178 with "H" and "S" flags in the BU message. LMA refreshes the binding 179 cache entry for the interface with only "S" flag. 181 5. LMA Operation 183 When LMA receives a Binding Update message which contains Handoff 184 Indication set to a value of 1 LMA MUST create a new binding cache 185 entry and assign new home network prefixes for this interface. In 186 the binding cache entry these HNPs MUST be flagged with a value of 0 187 representing "S". This binding cache entry becomes part of the 188 binding cache entry that contains home network prefixes with "H" 189 flag. "H" and "S" flags are as defined in Section 5.1. 191 LMA sends home network prefixes assigned to the new interface in the 192 Binding Acknowledgement message. LMA MUST also set the (H) Flag in 193 HNP option to 0. In the same BA message, LMA MAY also send home 194 network prefixes whose (H) flag is set to 1 in the same BA. 196 The modifications specified in this document allow a mobile node to 197 have a single interface connected at a given moment and that 198 interface has prefixes assigned an "S" flag, i.e. the binding with 199 the home interface may have expired. In this case LMA MUST also 200 store the home network prefixes with "H" flag in the binding cache 201 entry. 203 5.1. Extensions to Binding Cache Entry 205 One flag associated with the following binding cache entry: list of 206 IPv6 home network prefixes assigned to the mobile node's connected 207 interface and prefix length. The flag is set to 1 representing "H" 208 if the connected interface is the home interface and flag is set to 0 209 representing "S" if the connected interface is not the home interface 210 but it is one of the secondary interfaces. 212 The prefixes assigned after the very first PBU is received for this 213 MN are assigned the "H" flag. The handoff between two different 214 interfaces does not require the prefixes to be changed in order to 215 allow session continuity. Because of this the flag (of "H" or "S") 216 associated with the prefixes stays the same. 218 This specification also brings the change that binding cache entries 219 for the same MN-Identifier are considered together. The number of 220 entries is equal to the number of active interfaces of MN. If there 221 is a single entry it is assumed that the flag value is "H", otherwise 222 the prefixes with "H" flag should also be stored in the binding cache 223 entry. 225 For an incoming packet, the destination address MUST be selected from 226 the set of prefixes with "H" flag, i.e. MN always sends non-local 227 packets with source address assigned from HNPs of its home interface. 228 LMA decides to which interface to route this packet by consulting the 229 flow mobility cache [I-D.ietf-netext-pmipv6-flowmob], similar to the 230 case in Mobile IPv6 [RFC6089]. The packet will be matched against 231 the flow descriptions [RFC6088] in the flow mobility cache and Proxy- 232 CoA of the matching entry will be determined. Next, binding cache 233 entry for this MN will be searched and the packet will be directed to 234 the MAG to which the matching interface is connected. 236 6. MAG Operation 238 When MAG detects an attachment over a new interface it sets Handoff 239 Indicator field to 1 as described in [RFC5213] in the Binding Update 240 message that it sends to LMA. 242 MAG MUST store home network prefixes it receives in Binding 243 Acknowledgement message from LMA together with the flag in the 244 binding update list entry. If the flag is "S" MAG MUST also store 245 all home network prefixes in the BA message whose flag is "H" in the 246 corresponding binding update list entry. There will be a maximum of 247 two sets of HNPs for each MN if the MAG is not connected to the home 248 interface. 250 MAG receives packets from LMA, decapsulates them and searches the 251 binding update list to find the corresponding enrty (with the "H" 252 flag) and sends them to the MN with the corresponding "S" flag. 254 6.1. Extensions to Binding Update List Entry Data Structure 256 A flag associated with the following binding update list entry: list 257 of IPv6 home network prefixes assigned to the mobile node's connected 258 interface the corresponding prefix length. The flag is set to 0 259 representing "H" if the connected interface is the home interface and 260 is set to 1 representing "S" if the connected interface is not. 262 MAG MUST also store the home network prefixes with flag "H" in 263 addition to the prefixes associated with the connected interface if 264 the flag of the home network prefix assigned to the connected 265 interface is "S". MAG determines these flag values from the home 266 network prefix option's (H) flag. 268 7. Message Formats 270 Home Network Prefix Option defined in [RFC5213] is modified to 271 include a flag to indicate if home network prefixes are assocaited 272 with "H" flag or "S" flag in the binding cache entries. 274 This specification extends the Home Network Prefix Option with a new 275 flag. The flag is shown and described below. All other fields are 276 as described in [RFC5213]. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Length |H| Reserved | Prefix Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 + + 285 | | 286 + Home Network Prefix + 287 | | 288 + + 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 1: Home Network Prefix Option 294 H Flag 296 This flag is set to 1 when this prefix is assigned to a secondary 297 interface of the mobile node, i.e. when the binding cache entry 298 for this HNP has "S" flag set. This flag is set to 0 when this 299 prefix is assigned to the firstly connecting or the only connected 300 interface of the mobile node, i.e. when the binding cache entry 301 for this HNP has "H" flag set. 303 8. Security Considerations 305 This document does not define any new security issues. PMIPv6 306 security procedures apply. 308 9. IANA considerations 310 IANA is requested to add the H Flag into the reserved field in Home 311 Network Prefix Option defined in Section 8.3 in [RFC5213] as the 312 first bit, i.e. Bit number 16 and change the Reserved (R) field as 313 follows: 315 This 7-bit field is unused for now. The value MUST be initialized to 316 0 by the sender and MUST be ignored by the receiver. 318 10. Acknowledgements 320 The authors thank Hidetoshi Yokota who provided valuable comments. 322 11. References 324 11.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 330 June 1999. 332 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 333 in IPv6", RFC 6275, July 2011. 335 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 336 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 337 Network Mobility (NEMO) Basic Support", RFC 6089, 338 January 2011. 340 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 341 "Traffic Selectors for Flow Bindings", RFC 6088, 342 January 2011. 344 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 345 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 347 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 348 and K. Nagami, "Multiple Care-of Addresses Registration", 349 RFC 5648, October 2009. 351 11.2. Informative references 353 [I-D.ietf-netext-pmipv6-flowmob] 354 Cano, C., "Proxy Mobile IPv6 Extensions to Support Flow 355 Mobility", draft-ietf-netext-pmipv6-flowmob-03 (work in 356 progress), March 2012. 358 [I-D.ietf-netext-logical-interface-support] 359 Melia, T. and S. Gundavelli, "Logical Interface Support 360 for multi-mode IP Hosts", 361 draft-ietf-netext-logical-interface-support-05 (work in 362 progress), April 2012. 364 Authors' Addresses 366 Behcet Sarikaya 367 Huawei 368 5340 Legacy Dr. 369 Plano, TX 75074 371 Email: sarikaya@ieee.org 373 Frank Xia 374 Huawei 375 Nanjing, China 377 Phone: 378 Email: xiayangsong@huawei.com