idnits 2.17.1 draft-wakikawa-netext-pmip-cp-up-separation-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 (July 16, 2013) is 3937 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) 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 NETEXT WG R. Wakikawa 3 Internet-Draft Softbank Mobile 4 Intended status: Standards Track R. Pazhyannur 5 Expires: January 17, 2014 S. Gundavelli 6 Cisco 7 July 16, 2013 9 Separation of Control and User Plane for Proxy Mobile IPv6 10 draft-wakikawa-netext-pmip-cp-up-separation-00.txt 12 Abstract 14 This document describes splitting of Control Plane (CP) and User 15 Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. 16 Existing specifications allow a MAG to perform splitting of its 17 control and user plane using Alternate Care of address mobility 18 option for IPv6, or Alternate IPv4 Care of Address option for IPv4. 19 However, the current specification does not have semantics for 20 allowing the LMA to perform such functional split. To realize this 21 requirement, this specification defines a mobility option that 22 enables a local mobility anchor to provide an alternate LMA address 23 to be used for the bi-directional tunnel between the MAG and LMA. 24 With this extension, a local mobility anchor will be able to use an 25 IP address for its user plane which is different than what is used 26 for the control plane. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 17, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 64 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. LMA User Plane Address Mobility Option . . . . . . . . . . . 5 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 7.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Widely deployed mobility management systems for wireless 78 communications have isolated the path for forwarding data packets 79 from the control plane signaling for mobility management. To realize 80 this requirement, Proxy Mobile IPv6 requires that the control plane 81 functions of the local mobility anchor to be addressable at a 82 different IP address than the IP address used for the user plane. 83 However, the current specification does not have semantics for 84 allowing the LMA to perform such functional split. The local 85 mobility anchor is required to associate the IP address of the tunnel 86 source with the target IP address of the control messages received 87 from the MAG. Note that the concept of control- and user- planes are 88 well established and understood in cellular networks. 90 A PMIPv6 infrastructure contains of two primary entities: MAG and 91 LMA. The interface between MAG and LMA consists of two components: 92 control plane and user plane. The control plane is responsible for 93 signaling messages between MAG and LMA such as the Proxy Binding 94 Update and Proxy Binding Acknowledge messages to establish a mobility 95 binding. In addition, the control plane components in the MAG and 96 LMA are also responsible for setting up and tearing down of the bi- 97 directional tunnel between the MAG and LMA. The user plane is 98 responsible for forwarding the mobile node's IP packets between the 99 MAG and the LMA over the bi-directional tunnel. 101 In most deployments, the control plane and user plane components (of 102 the MAG and LMA) are co-located in the same physical entity. 103 However, there are deployments where it is desirable to have the 104 control and user plane of the MAG and LMA in separate physical 105 entities. For example, in a WLAN (Wireless LAN) deployment, it may 106 be desirable to have the control plane component of the MAG to be on 107 Access Controller (also sometimes referred to as Wireless LAN 108 Controller) while the user plane component of the MAG on the WLAN 109 Access Point. This would enable all the signaling messages to the 110 LMA to be centralized while the user plane would be distributed 111 across the multiple Access Points. Similarly there is a case to 112 split the control and user plane component of the LMA motivated by 113 different scaling requirements on the control and user plane 114 components or need to centralize the control plane in one geo- 115 location while distributing the user plane component across multiple 116 geo-locations 118 [RFC6463] and [RFC6275] contains a mechanism of splitting the control 119 and user plane in MAG. Specifically, [RFC6463] defines an Alternate 120 IPv4 Proxy Care of Address Option while [RFC6275] defines an 121 Alternate Care of Address for IPv6 address. The MAG can provide an 122 Alternate Care of Address in the Proxy Binding Update (PBU) and if 123 the LMA supports this option then a bidirectional tunnel is setup 124 between the LMA address and the MAG's alternate Care of address. 125 However, there is no corresponding option for the LMA to provide an 126 alternate address to the MAG. 128 CP: Control Plane 129 UP: User Plane 130 +------------+ +------------+ 131 | MAG | | LMA | 132 | +--------+ | | +--------+ | 133 +------+ | | MAG-CP |-|-------------|-| LMA-CP | | _----_ 134 | MN | | | | | PMIPv6 | | | | _( )_ 135 | |-----| +--------+ | | +--------+ |===( Internet ) 136 +------+ | : | | : | (_ _) 137 | +--------+ | | +--------+ | '----' 138 | | MAG-UP |-|-------------|-| LMA-UP | | 139 | | | |GRE/IP-in-IP | | | | 140 | +--------+ | | +--------+ | 141 +------------+ +------------+ 143 Figure 1: Functional Split of the Control and User Plane 145 This specification therefore defines a new mobility option that 146 enables a local mobility anchor to provide an alternate LMA address 147 to be used for the bi-directional tunnel between the MAG and LMA. 149 2. Conventions and Terminology 151 2.1. Conventions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 2.2. Terminology 159 All the mobility related terms used in this document are to be 160 interpreted as defined in [RFC5213] and [RFC5844]. 3GPP terms can be 161 found at [RFC6459]. Additionally, this document uses the following 162 terms: 164 LMA User Plane Address (LMA-UPA) 166 The IP address on the LMA that is used for establishing tunnels 167 with the mobile access gateway. 169 3. LMA User Plane Address Mobility Option 171 A new mobility header option, LMA User Plane Address mobility option 172 is defined for use with Proxy Binding Acknowledgment message sent 173 from the local mobility anchor to the mobile access gateway. This 174 option is used for notifying the LMA's user plane IPv4/IPv6 address. 175 There can be multiple instances of the LMA User Plane Address 176 mobility option present in the message, one for IPv4 and the other 177 for IPv6 transport. 179 The LMA User Plane Address mobility option has an alignment 180 requirement of 8n+2. Its format is as follows: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Length | Reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 + + 189 | | 190 . . 191 + LMA User Plane Address + 192 | | 193 + + 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Type 199 To be assigned by IANA. 201 Length 203 8-bit unsigned integer indicating the length of the option in 204 octets, excluding the type and length fields. 206 Reserved 208 This field is unused for now. The value MUST be initialized to 0 209 by the sender and MUST be ignored by the receiver. 211 LMA User Plane Address 213 Contains the IPv4/IPv6 user plane address of the LMA. 215 4. IANA Considerations 217 This document requires the following IANA action. 219 o Action-1: This specification defines a new Mobility Header option, 220 LMA User Plane Address mobility option. This mobility option is 221 described in Section 3. The type value for this message 222 needs to be allocated from the Mobility Header Types registry at 223 http://www.iana.org/assignments/mobility-parameters. RFC Editor: 224 Please replace in Section 3 with the assigned value, and 225 update this section accordingly. 227 5. Security Considerations 229 The LMA User Plane Address mobility Option defined in this 230 specification is for use in Proxy Binding Acknowledgement message. 231 This option is carried like any other mobility header option as 232 specified in [RFC5213]. Therefore, it inherits from [RFC5213] its 233 security guidelines and does not require any additional security 234 considerations. 236 6. Acknowledgements 238 Authors would like Acknowledge all the discussions on this topic in 239 the NETLMM Working group. 241 7. References 243 7.1. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 249 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 251 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 252 Mobile IPv6", RFC 5844, May 2010. 254 7.2. Informative References 256 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 257 in IPv6", RFC 6275, July 2011. 259 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 260 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 261 Partnership Project (3GPP) Evolved Packet System (EPS)", 262 RFC 6459, January 2012. 264 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 265 "Runtime Local Mobility Anchor (LMA) Assignment Support 266 for Proxy Mobile IPv6", RFC 6463, February 2012. 268 Authors' Addresses 270 Ryuji Wakikawa 271 Softbank Mobile 272 1-9-1,Higashi-Shimbashi,Minato-Ku 273 Tokyo 105-7322 274 Japan 276 Email: ryuji.wakikawa@gmail.com 278 Rajesh S. Pazhyannur 279 Cisco 280 170 West Tasman Drive 281 San Jose, CA 95134 282 USA 284 Email: rpazhyan@cisco.com 286 Sri Gundavelli 287 Cisco 288 170 West Tasman Drive 289 San Jose, CA 95134 290 USA 292 Email: sgundave@cisco.com