idnits 2.17.1 draft-patil-dmm-issues-and-approaches2dmm-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 : ---------------------------------------------------------------------------- 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 (March 5, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission B. Patil, Ed. 3 Internet-Draft Nokia 4 Intended status: Informational C. Williams 5 Expires: September 6, 2012 MCSR Labs 6 J. Korhonen 7 Nokia Siemens Networks 8 March 5, 2012 10 Approaches to Distributed mobility management using Mobile IPv6 and its 11 extensions 12 draft-patil-dmm-issues-and-approaches2dmm-00 14 Abstract 16 Mobility solutions at the IP layer have been specified in the IETF 17 for IPv4 and IPv6. These solutions include host and network based 18 mobility. All of the mobility protocols enable IP session continuity 19 by providing the mobile host with an IP address or prefix that 20 remains constant even as the host moves and attaches to different 21 access networks and points of attachment. Mobile hosts are anchored 22 at a gateway via a tunnel and the address/prefix provided to the host 23 via the gateway remains unchanged across mobility events. All IP 24 sessions initiated or terminated at a mobile host are anchored via 25 the gateway. A gateway centric approach such as Mobile IP, raises 26 certain concerns in terms of cost and efficiency. A mobility model 27 wherein the network entities enabling mobility are distributed is a 28 way of alleviating the concerns of a gateway centric approach. This 29 document considers ways to alleviate anchored mobility issues with 30 approaches that could be considered in a deployment. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 6, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Issues with current mobility models . . . . . . . . . . . . . 5 70 4.1. Backhauling all traffic to a centralized GW . . . . . . . 5 71 4.2. Latency Considerations . . . . . . . . . . . . . . . . . . 6 72 4.3. Inefficient Routing and signaling overhead . . . . . . . . 6 73 4.4. Scalability and cost . . . . . . . . . . . . . . . . . . . 6 74 5. Enhancements to improve mobility . . . . . . . . . . . . . . . 7 75 5.1. HMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.2. Dynamic assignment of HA . . . . . . . . . . . . . . . . . 7 77 5.3. Route Optimization . . . . . . . . . . . . . . . . . . . . 7 78 6. Distributed mobility - What does it imply . . . . . . . . . . 8 79 7. Approaches using current protocols for distributed mobility . 9 80 8. Potential future work . . . . . . . . . . . . . . . . . . . . 10 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 11 84 12. Informative References . . . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Mobility solutions at the IP layer have been specified in the IETF 90 for IPv4 and IPv6. These solutions include host and network based 91 mobility. All of the mobility protocols enable IP session continuity 92 by providing the mobile host with an IP address or prefix that 93 remains constant even as the host moves and attaches to different 94 access networks and points of attachment. Mobile hosts are anchored 95 at a gateway via a tunnel and the address/prefix provided to the host 96 via the gateway remains unchanged across mobility events. All IP 97 sessions initiated or terminated at a mobile host are anchored via 98 the gateway. There are issues and concerns with such a mobility 99 model which are discussed in this document. A mobility model wherein 100 the mobility functions that reside in the network are distributed, is 101 a way of alleviating the concerns of a gateway centric approach. 102 This document also considers ways to alleviate anchored mobility 103 issues with approaches that could be considered in a deployment. 105 Mobile IPv6 as specified in [RFC6275] [RFC3776] is a host based 106 mobility protocol. It requires the MN to be anchored at a home 107 agent. The home agent assigns the MN an IPv6 address or prefix that 108 is static for the duration of the registration period. Similarly 109 Proxy Mobile IPv6 [RFC5213] is a network based mobility protocol in 110 which the mobility access gateway (MAG) assigns the MN a prefix 111 provided by the local mobility anchor (LMA) for the duration of a 112 valid registration. This prefix does not change across mobility 113 events. The home agent and LMA entities can be viewed as centralized 114 gateways. These gateways generally serve a large number of mobile 115 hosts. All traffic to/from mobile hosts associated with an HA/LMA is 116 routed through these gateways and as a result raises concerns such as 117 : 119 1. single point of failure, 121 2. backhauling traffic to the gateway, 123 3. latency as a result of backhauling and additional processing, 125 4. cost and complexity, etc. 127 These issues are discussed in further detail in the document. It 128 should also be noted that in addition to mobility for hosts, there is 129 also specifications that deal with networks that are mobile. Network 130 mobility is specified in [RFC3963] 132 The mobility working groups in the IETF have extended the basic 133 protocols to address various issues and concerns. Hierarchical 134 Mobile IP [RFC5380] and flow mobility [RFC6088], [RFC6089] are just a 135 few examples. Many of these extensions can be utilized in 136 deployments to alleviate the issues that arise from an anchored 137 mobility solution. A few approaches to how a distributed mobility 138 model could be deployed using current protocols and extensions are 139 also discussed in this document. 141 2. Terminology 143 Distributed Mobility 145 The term distributed mobility refers to an architecture in which 146 the mobility function (entitie(s) in the network that are 147 responsible for IP mobility) is distributed across multiple levels 148 of hierarchy in a deployment. The mobility function(s) could be 149 provided by an access point or base-station, or it could be a part 150 of the access network. Distributed mobility would enable session 151 continuity for hosts while not requiring that they be anchored at 152 a single gateway (such as a home agent or Local Mobility Agent) 153 all the time. 155 3. Problem statement 157 The lack of support for mobility at the IP layer has been addressed 158 in IPv6 with the specification of Mobile IPv6 [RFC6275]. Various 159 extensions to the protocol such as support for multiple care-of- 160 addresses as well as the ability to operate while attached to an IPv4 161 network using Dual-stack Mobile IPv6 [RFC5555] have been specified. 162 The protocol has not been widely implemented or deployed as of date 163 for various reasons. 165 The Internet has evolved to support real-time applications such as 166 voice, multimedia streaming etc. These applications require low 167 latency as well as no (or minimal) interruptions when switching 168 interfaces or networks. Current IP mobility solutions based on 169 Mobile IPv6 are well suited for non-real-time applications which are 170 able to handle the delay which is caused by a mobile node doing a 171 handover between networks or switching interfaces. Optimizations to 172 support real time applications have also been specified such as 173 FMIPv6 [RFC5568]. The centralized gateway approach of Mobile IPv6 174 has multiple issues and raises concerns that are captured in this 175 document. One of the ideas is to move the mobility gateway closer to 176 the actual point of attachment. This has benefits in terms of 177 reduced latency but it also causes other issues such as the ability 178 to support mobility when the MN moves to a different access network 179 or the ability to do charging at a central node. Distributed 180 mobility is an approach that has some merit and worth studying 181 further. At the same time the issues that are driving the mobility 182 solutions towards a different model can be addressed by existing 183 protocols with various extensions. The problems of a centralized 184 gateway approach and reasons for considering distributed mobility 185 need to be deeply analyzed and understood before beginning work on 186 entirely new protocols for solving IP mobility. 188 4. Issues with current mobility models 190 Current mobility protocols have been designed with a stable 191 topologically correct anchoring gateway in mind. They just do not 192 tolerate mid-session anchor relocation. HMIP6, HA Switch, HA- 193 reliability and LMA Redirect are attempts in that direction but fail 194 or fall short. 196 In addition, one of the key deployment considerations of Mobile IPv6 197 is the location of each of the home agents or gateways, both 198 initially and over time. Each operator has unique requirements; 199 therefore, no single deployment model will suit all operators. The 200 operator's own organizational structure could also influence the 201 mobility architecture. Some operators have network OAM 202 responsibilities that are assigned geographically, while others use a 203 more centralized model. The deployment architecture that has been 204 traditionally put forth is to have centralized gateway elements where 205 all mobility control and data traffic is routed through them. 207 4.1. Backhauling all traffic to a centralized GW 209 A centralized home agent/gateway approach leads to backhauling all 210 traffic to the node which has unfavorable operational consequences. 212 The sheer volume of the aggregated throughput traffic to backhaul all 213 user data from a local aggregation anchor to centralized data centers 214 with home gateways can be expensive in many scenarios. With high 215 density deployments, the centralized architecture leads to heavy 216 backhaul utilization, and the inability to distribute load quickly 217 manifests unfavorably. In addition, local user traffic does not 218 remain local. User traffic must travel all the way to the 219 centralized gateway and back, even if the corresponding peer is 220 topologically closer. 222 In addition, a centralized gateway model increases the cost of 223 backhaul by preventing the off-loading of high-bandwidth services 224 locally. Instead high-bandwidth services have their traffic 225 backhauled to a centralized gateway in a data center. This will 226 increase the distances and possibly the capacity associated with any 227 backhaul. 229 4.2. Latency Considerations 231 While the support for Internet offload of user data can significantly 232 reduce the core network backhaul, the mobility management element may 233 be strategically positioned deeper in the network to efficiently 234 set-up and process the signaling and control including optional 235 policies. Such a hybrid architecture can provide for supporting a 236 mix of real-time and non-real-time broadband services. Real-time 237 applications can benefit from lower latencies by having data closer 238 to the subscriber and peers and not backhauled. Non-real-time 239 applications (such as e-mail) derive no such performance benefit and 240 may have a more centralized traffic approach. 242 Current mobility models handle offload cases poorly. A consideration 243 may be to clearly make a working toolbox for applications to select a 244 prefix with anchored mobility and a prefix without anchoring. 246 4.3. Inefficient Routing and signaling overhead 248 Inefficient routing mechanism of a completely centralized mobility 249 deployment approach causes QoS deterioration and may lead to heavy 250 network congestion in the core. 252 In the centralized approach only the HA and the CNs manage a nodes 253 mobility. Mobility signaling occurs each time a mobile node changes 254 its point-of-attachment regardless of the locality and amplitude of 255 its movement. As a consequence, the same level of signaling load is 256 introduced independently of the user's mobility pattern. For 257 example, if the HA and/or CNs are far from the MN, even if the MNs 258 movement is small, the mobility signaling messages travel across 259 several IP networks, the latencies of which reduce handover speed. 260 Furthermore, route optimization which supports direct routing from 261 CNs to the mobile node, generates excessive mobility messages and 262 adds a significant extra load to the network. 264 4.4. Scalability and cost 266 In a completely centralized Mobile IPv6-based deployment approach, 267 the home agent becomes a single point of failure. Also, a 268 distributed deployment approach may provide better overall capacity 269 and performance, but this must be weighed against the increase in 270 capital costs for deployment of local distributed gateways. In 271 addition, a completely centralized deployment model makes it 272 difficult to scale with a large number of mobile nodes. Scalability 273 costs are weighted from many perspectives such as the number of nodes 274 in the overall system, the geographic distance of the traffic, the 275 number of autonomous parties in the deployment approach and others. 277 5. Enhancements to improve mobility 279 Enhancements to the Mobile IPv6 protocol have been done to improve 280 mobile communications in certain scenarios so that mobility 281 operations are efficient and optimized.. A key area of enhancements 282 is in reducing the delays in the data path redirection operation that 283 is defined in Mobile IPv6 operations. Mobile IPv6 has adopted route 284 optimization and HMIPv6 to reduce the traversal of data traffic to 285 the mobile nodes new location changes in its point of attachment. 286 Delays in data traffic redirection will depend upon the location of 287 the anchor agent that performs the redirection. As such enhancements 288 focus on moving these anchor agents closer to the mobile node. 290 5.1. HMIPv6 292 Using Mobile IPv6, a mobile node sends location updates to any node 293 it corresponds with each time it changes its location, and at 294 intermittent intervals otherwise. This involves a lot of signaling 295 and processing, and requires a lot of resources. Furthermore, 296 although it is not necessary for external hosts to be updated when a 297 mobile nodes moves locally, these updates occur for both local and 298 global moves. Hierarchical Mobile IPv6 (HMIPv6)is designed to 299 enhance mobility support in MIPv6 and micro-mobility management. The 300 benefit of the HMIPv6 enhancement is to reduce the amount of 301 signaling required and to improve handoff speed. 303 The key concept behind HMIPv6 is to locally handle handovers by the 304 usage of an entity called the Mobility Anchor Point (MAP) located at 305 any level in a hierarchical network of routers. The major issue on 306 HMIPv6 is designing the MAP selection scheme that can reduce frequent 307 handover mobility signaling and improve handover performance. 309 5.2. Dynamic assignment of HA 311 Dynamic assignment of HA is an enhancement to reduce both the 312 signaling traffic and the data traffic to the home network. The 313 dynamic HA assignment may take into account the geographical 314 proximity of the HA to the mobile node. It may also consider 315 performance factors such as HA load-balancing or other criteria. 317 5.3. Route Optimization 319 Mobile IPv6 Route optimization is an enhancement to optimize the data 320 path between two communicating nodes despite changes in the IP 321 connectivity on the mobile node side. The data path reduction 322 between the communicating nodes helps to reduce one way packet delay 323 when both nodes are under the same localized domain and the mobility 324 gateway is far away. The process of reducing data path is referred 325 to as route optimization. Route optimization helps reduce the delay 326 and thus important for real-time applications. An enhanced version 327 of route optimization may also enable continued communications during 328 periods of temporary home-agent unavailability. 330 6. Distributed mobility - What does it imply 332 Mobility is a service that provides significant value to a network 333 operator. The ability to offer connectivity and services that work 334 seamlessly across mobility events such as the switching of an access 335 network type etc. creates a much superior end-user experience and 336 thereby a demand for such service. Cellular networks have offered 337 mobility for voice and messaging (short message service) since the 338 late 80s and early 90s. These networks have been evolving and are 339 now offering broadband data services and Internet connectivity. The 340 network architectures are also using Internet protocols and 341 technologies to a significant extent. Traditionally the 342 architectures of these networks has been hierarchical in nature. 343 While such an architecture served operators well in the past, it has 344 limitations when it comes to offering data services and Internet 345 connectivity. There is an effort to distribute functionality that 346 generally has resided in centralized gateways much more closer to the 347 edge of the network. The line between the access and core network is 348 fading and hence a need to rethink how mobility service is affected 349 in such an evolving architecture. 351 Distributed mobility is a way to deploy existing mobility solutions 352 that do not require a mobile host to be anchored at a gateway all the 353 time but instead be attached to different mobility agents/gateways in 354 the network depending on the access, location and other factors. 355 Session continuity via distributed mobility is expected to be on par 356 with that provided by an anchored mobility solution. 358 Does it require an entirely new approach to mobility architectures 359 that would be based on the goal of distributing mobility related 360 functions? It is an easy option to consider redesigning on a clean 361 sheet of paper. However this is not a pragmatic approach. It is 362 much more optimal to consider what are the issues that are created as 363 a result of a centralized gateway architecture and then develop 364 extensions to the protocols and, deployment models, that can address 365 those issues. The implications of distributed mobility architectures 366 on access and core networks needs to be also considered in any 367 design. 369 7. Approaches using current protocols for distributed mobility 371 We believe that most of the needed basic protocol functionality for 372 distributed mobility management is already there. What is missing 373 seem to be related to general system level design and lack of 374 mobility aware APIs for application developers. One of the simple 375 approaches for distributed mobility management is to avoid 376 traditional "anchored mobility" like Mobile IPv6 when possible and 377 rather use local (care-of) addresses for the communication. Use of 378 local addressing also implies less mobility related signaling load in 379 the network. For example [RFC5014] already provides means for an 380 application to explicitly request for a prefix that has mobility 381 characteristics (IPV6_PREFER_SRC_HOME) or a prefix that is local to 382 the current access network (IPV6_PREFER_SRC_COA). It is not 383 guaranteed that the IP stack in the MN would always respect the 384 suggestion received from the application. In general it is also 385 important that possible solutions in distributed mobility management 386 space requires minimal changes in mobile hosts. 388 Another aspect that is in interest of distributed mobility management 389 concentrates on allocating mobility anchors that are topologically 390 close to the MN. Existing protocols such as HMIPv6 [RFC5380] provide 391 a solution that is close what is needed. What might be needed in 392 addition is a mechanism to "chain" multiple MAP-domain to extend the 393 micro-mobility area, or provide another RFC5014 like prefix type 394 (IPV6_PREFER_SRC_MAP). We could also consider Mobile IPv6 + Proxy 395 Mobile IPv6 interactions Scenario A.1 in 396 [I-D.ietf-netlmm-mip-interactions] a similar solution. Finally, yet 397 another approach for exploiting locality are Proxy Mobile IPv6 398 localized routing solutions [I-D.ietf-netext-pmip6-lr-ps] which 399 allows bypassing the remote central Local Mobility Anchor when ever 400 possible and have a direct communication via closer to MNs Mobile 401 Access Gateways. 403 Home Agent Switch [RFC5142] extension to Mobile IPv6, Runtime LMA 404 assignment [I-D.ietf-netext-redirect] extension to Proxy Mobile IPv6 405 and Mobile IPv4 Dynamic HA Assignment [RFC4433] all provide solutions 406 to dynamically assign a mobility anchor to the MN. What is missing 407 from these solutions, is a protocol or rather a system level solution 408 for a "seamless mobility anchor relocation" during an existing 409 mobility session. However, that would be rather challenging due the 410 fact that a mobility anchor relocation usually implies topological 411 location chance in the network, which would also mean different 412 prefixes/subnetworks for home addresses from the IP routing point of 413 view. Within a reasonably small autonomous system or otherwise 414 restricted area maybe some kind of interior routing solution could be 415 used to assist mobility anchor relocation. 417 8. Potential future work 419 As the MEXT working group evolves and transitions to one that is 420 focused on dealing with distributed mobility, there is a need to 421 clearly understand the drivers for such an approach and whether these 422 could be dealt with via a framework that uses existing mobility 423 protocols and extensions and can be applied in a manner that deals 424 with those concerns. 426 One of the key efforts could be in understanding the key concerns 427 driving the need for a distributed mobility solution and identifying 428 various approaches using existing protocols and extensions to 429 overcome them. 431 1. Work on the generic solution for anchor relocation. This might 432 be a architecture describing work, rather than protocol work. I 433 believe we have most protocols already in place but not glued 434 together. 436 2. Work on address selection beyond RFC 5014 (with coloring i.e. the 437 end host stack knows properties of the prefix it got) and rapid 438 deprecation/renumbering of prefixes (needed when CoAs change and 439 applications try to use CoA for something local). This could 440 potentially be new protocol work an containers for coloring 441 prefixes (RA and DHCPv6) and how to handle local prefix 442 deprecation during handovers. 444 3. Work on localized mobility that does not involve signaling with 445 gateways or "mobility signaling". This could lead to work below 446 the IP layer, e.g. intra-AS mobility is handled using some 447 interior routing protocol enhancement. 449 9. IANA Considerations 451 This document has no requests to IANA. 453 10. Security Considerations 455 This document is a discussion of distributed mobility solutions. 456 Some of the approaches that are considered for deployment do have 457 security implications. However since the approaches being discussed 458 are based on existing mobility specifications developed within the 459 IETF, they have already been reviewed for security. This document 460 does not raise any new security concerns. 462 11. Summary and Conclusion 464 Distributed mobility is a way of deploying mobility protocols that 465 minimise the issues that arise from a centralized gateway centric 466 approach that comes from a hierarchical model. As the amount of 467 traffic in a network grows, operators are less willing to transport 468 all the traffic to a centralized gateway just for the sake of 469 enabling mobility. The mobility models have to evolve to meet the 470 changing environment of mobile networks and traffic patterns. 472 Using many of the extensions and protocols that have been defined for 473 Mobile IPv6 it is possible to deploy a mobility solution that meets 474 the criteria of distributed mobility architecture. The concerns fo a 475 centralized gateway approach can be addressed using deployment 476 techniques effectively. 478 12. Informative References 480 [I-D.ietf-netext-pmip6-lr-ps] 481 Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized 482 Routing Problem Statement", 483 draft-ietf-netext-pmip6-lr-ps-06 (work in progress), 484 March 2011. 486 [I-D.ietf-netext-redirect] 487 Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 488 "Runtime LMA Assignment Support for Proxy Mobile IPv6", 489 draft-ietf-netext-redirect-12 (work in progress), 490 October 2011. 492 [I-D.ietf-netlmm-mip-interactions] 493 Giaretta, G., "Interactions between PMIPv6 and MIPv6: 494 scenarios and related issues", 495 draft-ietf-netlmm-mip-interactions-07 (work in progress), 496 October 2010. 498 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 499 Protect Mobile IPv6 Signaling Between Mobile Nodes and 500 Home Agents", RFC 3776, June 2004. 502 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 503 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 504 RFC 3963, January 2005. 506 [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 507 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006. 509 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 510 Socket API for Source Address Selection", RFC 5014, 511 September 2007. 513 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 514 "Mobility Header Home Agent Switch Message", RFC 5142, 515 January 2008. 517 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 518 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 520 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 521 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 522 Management", RFC 5380, October 2008. 524 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 525 Routers", RFC 5555, June 2009. 527 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 528 July 2009. 530 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 531 "Traffic Selectors for Flow Bindings", RFC 6088, 532 January 2011. 534 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 535 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 536 Network Mobility (NEMO) Basic Support", RFC 6089, 537 January 2011. 539 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 540 in IPv6", RFC 6275, July 2011. 542 Authors' Addresses 544 Basavaraj Patil (editor) 545 Nokia 546 6021 Connection drive 547 Irving, TX 75039 548 USA 550 Email: basavaraj.patil@nokia.com 551 Carl Williams 552 MCSR Labs 553 Palo Alto, CA 94306 554 USA 556 Email: carlw@mcsr-labs.org 558 Jouni Korhonen 559 Nokia Siemens Networks 560 Linnoitustie 6 561 FI-02600 Espoo 562 FINLAND 564 Email: jouni.nospam@gmail.com