idnits 2.17.00 (12 Aug 2021) /tmp/idnits1235/draft-bernardos-netext-pmipv6-mih-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE80221]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 26, 2009) is 4583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT Working Group CJ. Bernardos 3 Internet-Draft A. de la Oliva 4 Intended status: Informational UC3M 5 Expires: April 29, 2010 JC. Zuniga 6 InterDigital Communications, LLC 7 T. Melia 8 Alcatel-Lucent Bell Labs 9 S. Das 10 Telcordia Technologies Inc. 11 October 26, 2009 13 PMIPv6 operation with IEEE 802.21 14 draft-bernardos-netext-pmipv6-mih-01 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 29, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 53 enables mobile devices to connect to a PMIPv6 domain and roam across 54 gateways without changing the IP address. PMIPv6 also provides 55 limited multi-homing support to multi-mode mobile devices. 57 While the basic scenario addressed by PMIPv6 considers MNs with just 58 one interface, PMIPv6 also allows an MN to connect to the same PMIPv6 59 domain through different interfaces. This limited support of multi- 60 interfaced MNs is not fully specified, since the MAG needs to obtain/ 61 guess additional information from the MN, in order to decide whether 62 to treat an MN's interface attachment as a handover or as new 63 interface attachment (i.e. meaning the creation of a new mobility 64 session and, therefore, the allocation of new home network prefixes 65 to the MN). The use of the Media Independent Handover (MIH) Services 66 as defined in the IEEE 802.21-2008 specification [IEEE80221] may help 67 in obtaining this additional information. This I-D describes how 68 PMIPv6 would work in an 802.21-enabled scenario, and in particular, 69 analyzes how MIH primitives can be used to help the MAG deal with 70 multi-technology scenarios. The main objective of the IEEE 802.21- 71 2008 standard is to provide link layer intelligence to upper layers. 72 Hence, a more intelligent decision making capability leading to more 73 reliable and efficient handovers between heterogeneous networks can 74 be enabled. 76 Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. PMIPv6 (RFC 5213) and IEEE 802.21 operation . . . . . . . . . 6 87 4. PMIPv6 Extensions and IEEE 802.21 . . . . . . . . . . . . . . 9 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 90 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 96 1. Introduction 98 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network 99 based mobility management to hosts connecting to a PMIPv6 domain. 100 PMIPv6 introduces two new functional entities, the Local Mobility 101 Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 102 first layer three hop detecting Mobile Node's (MN) attachment and 103 providing IP connectivity. The LMA is the entity assigning one or 104 more Home Network Prefixes (HNPs) to the MN and is the topological 105 anchor for all traffic from/to the MN. 107 While the basic scenario addressed by PMIPv6 considers MNs with just 108 one interface, [RFC5213] also allows an MN to connect to the same 109 PMIPv6 domain through different interfaces. This limited support of 110 multi-interfaced MNs is not fully specified, since the MAG needs to 111 obtain/guess additional information from the MN, in order to decide 112 whether to treat an MN's interface attachment as a handover or as new 113 interface attachment (i.e. meaning the creation of a new mobility 114 session and, therefore, the allocation of new home network prefixes 115 to the MN). The use of IEEE 802.21 Media Independent Handover (MIH) 116 Services [IEEE80221] may help in obtaining this additional 117 information. This I-D describes how PMIPv6 would work in an 802.21- 118 enabled scenario, and in particular, analyzes how MIH primitives can 119 be used to help the MAG deal with multi-technology scenarios. 121 2. Terminology 123 Readers are expected to be familiar with all the terms defined in the 124 [RFC5213]. In addition, the following acronyms and terminology 125 (related to the IEEE 802.21 standard) are used in this document: 127 MIH (Media Independent Handover) 129 The handover support architecture defined by the IEEE 802.21-2008 130 specification that consists of the MIH Function (MIHF), MIH 131 Network Entities and MIH protocol messages. 133 MIHF (Media Independent Handover Function) 135 A switching function that provides handover services including the 136 Event Service (ES), Information Service (IS), and Command Service 137 (CS), through service access points (SAPs) defined by the IEEE 138 802.21 working group. 140 MIH User 141 An entity that uses the MIH SAPs to access MIHF services. 143 MIHF_ID (MIHF Identifier) 145 The MIHF_ID is a network access identifier (NAI). NAI shall be 146 unique as per IETF RFC 4282 [RFC5164]. 148 MoS (Mobility Services) 150 Those services, as defined in the MIH problem statement document 151 [RFC5164], which includes the MIH IS, CS, and ES services defined 152 by the IEEE 802.21-2008 standard. 154 ES (Event Service) 156 A MoS that originates at a remote MIHF or the lower layers of the 157 local protocol stack and sends information to the local MIHF or 158 local higher layers. The purpose of the ES is to report changes 159 in link status (e.g., Link Detected, Link Up, and Link Going Down 160 messages) and various lower layer events. 162 CS (Command Service) 164 MoS that sends commands from the remote MIHF or local upper layers 165 to the remote or local lower layers of the protocol stack to 166 switch links or to get link status. 168 PoS (Point of Service) 170 A network-side MIHF instance that exchanges MIH messages with a 171 MN-based MIHF. 173 PoA (Point of attachment) 175 Endpoint of a layer 2 link that includes the MN as the other 176 endpoint. 178 PMIPv6 client 180 From an IEEE 802.21 viewpoint, a mobility protocol making use of 181 the MIH Services (i.e. an MIH User) is called client. Therefore, 182 a PMIPv6 client on a given node (e.g., a MAG) is the PMIPv6 183 mobility stack of that node, which makes use of the MIH Services. 185 3. PMIPv6 (RFC 5213) and IEEE 802.21 operation 187 This section describes how Proxy Mobile IPv6 works in an IEEE 802.21- 188 enabled network. Although the use of IEEE 802.21 would also be 189 helpful in single technology access network deployments, in this 190 version of the draft we use a multiple-interface/access technology 191 scenario and we only consider mobile-initiated handovers. 193 Figure 1 shows an example of a multiple-access technology PMIPv6 194 deployment scenario (in this example WLAN and Cellular 3GPP Long Term 195 Evolution -- LTE -- are the access networks considered). In this 196 scenario, MNs can attach and roam using one or multiple interfaces. 197 Note that we also depict layer-2 entities (WLAN Access Points -- APs 198 -- and enhanced Nodes B -- eNBs) in the figure for completeness. 200 +-----+ 201 | LMA | 202 +-----+ 203 // \\ 204 +---------//---\\-------------+ 205 ( // \\ ) PMIPv6 domain 206 ( // \\ ) 207 +------//---------\\----------+ 208 // \\ 209 3GPP EPC// \\ WLAN 210 +---------+ +-------+ 211 |S-GW/MAG1| |AR/MAG2| 212 +---------+ +-------+ 213 /\ /\ 214 / \ / \ 215 / \ / \ 216 ----- ----- ---- ---- 217 |eNB| |eNB| --|AP| |AP|-- 218 -+--- ---+- | ---- ---- | 219 | | | | 220 << v >> << v >> (( o )) (( o )) 222 < v > ( o ) ( o ) 223 | | | 224 | ----- | ----- | 225 --|MN1|-- |MN2|-- 226 (if2) ----- (if1) ----- (if1) 228 Figure 1: Dual technology (WLAN & 3GPP LTE) PMIPv6 scenario 230 The equivalent IEEE 802.21-enabled scenario of Figure 1 is shown in 231 Figure 2. The PoS entity resides in the MAG, and the PoAs are the 232 layer-2 access points. The PMIPv6 client on the MAG plays the role 233 of MIHF user. We next focus on the signaling for the two main PMIPv6 234 procedures: bootstrapping (or initial MN attachment) and MN handover. 236 +-----+ 237 | LMA | 238 +-----+ 239 // \\ 240 +---------//---\\-------------+ 241 ( // \\ ) PMIPv6 domain 242 ( // \\ ) 243 +------//---------\\----------+ 244 // \\ 245 3GPP EPC// \\ WLAN 246 +---------+ +-------+ 247 |S-GW/MAG1| PoS1 |AR/MAG2| PoS2 248 +---------+ +-------+ 249 /\ /\ 250 / \ / \ 251 PoA1a / \PoA1b PoA2a/ \PoA2b 252 ------- ------- ------ ------ 253 |eNB a| |eNB b| --|AP a| |AP b|-- 254 --+---- ----+-- | ------ ------ | 255 | | | | 256 << v >> << v >> (( o )) (( o )) 258 < v > ( o ) ( o ) 259 | | | 260 | ----- | ----- | 261 --|MN1|-- |MN2|-- 262 (if2) ----- (if1) ----- (if1) 264 Figure 2: Dual technology (WLAN & 3GPP LTE) IEEE 802.21-enabled 265 PMIPv6 scenario 267 For both the initial MN's attachment and handover cases, the 268 candidate MAG needs to detect that a new MN is on its access link, 269 and then obtain all the parameters that are required to be included 270 in the Proxy Binding Update (PBU) message. We only list below those 271 where IEEE 802.21 may help: 273 o MN-Identifier: this is a stable identifier of the MN that 274 identifies it in the PMIPv6 domain. For instance, in an IEEE 275 802.21-enabled handover scenario, the PMIPv6 client in the MAG 276 receives an MIH_N2N_HO_Commit.indication message, informing about 277 the intention of the MN to perform a handover to the target 278 network. This message contains -- among other information -- the 279 MNIdentifier, which is the MIHF_ID of the MN that commits to 280 perform a handover (and therefore attaches to the candidate/new 281 MAG). The MIHF_ID can be used as MN-Identifier for PMIPv6 282 management and signaling purposes. According to [RFC5213], the 283 new MAG, after detecting an MN's attachment, has to identify the 284 MN, acquire its MN-Identifier and determine whether the network- 285 based mobility management service needs to be offered to the MN. 286 If so, the MAG will send a PBU message to the LMA. 288 o Handover Indicator (HI) option. This handoff hint is required for 289 the network to find out if the MN is either performing a handover 290 (and which type of handover) or not (just attaching a new 291 interface). The OldAccessRouter and IPRenewalFlag parameters 292 contained in the MIH_Link_Up.indication message may be used to 293 help the MAG detect the correct value to be included in the HI 294 option. The OldAccessRouter parameter contains the Link address 295 of old Access Router. The IPRenewalFlag parameter indicates 296 whether the MN needs to change IP Address in the new PoA. Based 297 on the presence and values of these two parameters, the HI can be 298 chosen by the MAG as follows: 300 * (OldAccessRouter and NewAccessRouter parameters are different) 301 AND (IPRenewalFlag == TRUE) ==> HI=1 (Attachment over a new 302 interface). If OldAccessRouter and NewAccessRouter parameters 303 are different and IPRenewalFlag is TRUE, it indicates a new 304 interface attachment. Therefore, the MAG has to request the 305 LMA to create a new mobility session for the MN. 307 * (no OldAccessRouter parameter present) AND (IPRenewalFlag == 308 FALSE) ==> HI=2 (Handoff between two different interfaces of 309 the mobile node). Again, the MN is not performing a handover 310 on the same interface (the layer-2 address of the old AR is not 311 provided) and the MN indicates that it wants to keep using the 312 same IP address(es). This means that the MN is performing a 313 vertical handover between two different interfaces. 315 * (OldAccessRouter parameter present) AND (IPRenewalFlag == 316 FALSE) ==> HI=3 (Handoff between mobile access gateways for the 317 same interface). The MN is performing a handover from a 318 previous PoS/MAG (the layer-2 address of the old AR is 319 available) and the MN wants to keep using the same IP 320 address(es). This means that the MN is performing a horizontal 321 handover. 323 * Any other combination ==> HI=4 (Handoff state unknown). 325 o Mobile Node Link-layer Identifier option. This identifies the 326 attached interface of a mobile node and can be obtained from the 327 LinkIdentifier parameter included in the MIH_Link_Up.indication 328 message received by the PMIPv6 client on the PoS/MAG. 330 o Access Technology Type (ATT) option. This option indicates the 331 type of access technology by which the MN is currently attached to 332 the MAG. This information may be obtained by the PMIPv6 client on 333 the PoS/MAG from the LinkIdentifier parameter included in the 334 MIH_Link_Up.indication message. 336 There are a number of parameters required for the proper use of PMIP 337 which are obtained from the MIH_Link_Up.indication message. 339 The remote exchange of events in IEEE 802.21 is defined as a service 340 based on subscription, where a network entity is able to receive 341 remote events generated, for example, in the MN, by subscribing to 342 these specific events through a defined set of primitives. The new 343 MAG, in order to receive the MN's MIH_Link_Up.Indication message, 344 must have subscribed to it previously. Note that this subscription 345 must be done before the handover. In order to do that, we propose 346 the following method: previously to the MN handover, the nMAG 347 receives a message indicating that a handover is going to be 348 performed. This message is the MIH_N2N_HO_Commit.indication and it 349 must be replied with an MIH_N2N_HO_Commit.response before the MN 350 performs the handover. In the MIH_N2N_HO_Commit.indication message 351 there is the information required to contact the MN, such as the MN's 352 MIHF_ID. Prior to send the MIH_N2N_HO_Commit.response message, the 353 new MAG must perform the remote event subscription to the Link_Up 354 message, by exchanging the appropriate IEEE 802.21 primitives. 356 4. PMIPv6 Extensions and IEEE 802.21 358 TBD in future revisions of this I-D. 360 5. IANA Considerations 362 This document makes no request of IANA. 364 6. Security Considerations 366 None. 368 7. Acknowledgments 370 The research of Carlos J. Bernardos and Antonio de la Oliva leading 371 to these results has received funding from the European Community's 372 Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 373 214994 (CARMEN project). The work of Carlos J. Bernardos has also 374 received funding from the Ministry of Science and Innovation of 375 Spain, under the QUARTET project (TIN2009-13992-C02-01). 377 8. References 379 8.1. Normative References 381 [IEEE80221] 382 ""IEEE Standard for Local and Metropolitan Area Networks - 383 Part 21: Media Independent Handover Services", IEEE LAN/ 384 MAN Std 802.21-2008, January 2009, http://www.ieee802.org/ 385 21/private/Published%20Spec/802.21-2008.pdf (access to the 386 document requires membership). Information technology - 387 Telecommunications and information exchange between 388 systems - Local and metropolitan area networks - Specific 389 requirements - Media Independent Handover Services", 390 IEEE Standard 802.21. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 396 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 398 8.2. Informative References 400 [RFC5164] Melia, T., "Mobility Services Transport: Problem 401 Statement", RFC 5164, March 2008. 403 Authors' Addresses 405 Carlos J. Bernardos 406 Universidad Carlos III de Madrid 407 Av. Universidad, 30 408 Leganes, Madrid 28911 409 Spain 411 Phone: +34 91624 6236 412 Email: cjbc@it.uc3m.es 413 URI: http://www.it.uc3m.es/cjbc/ 415 Antonio de la Oliva 416 Universidad Carlos III de Madrid 417 Av. Universidad, 30 418 Leganes, Madrid 28911 419 Spain 421 Phone: +34 91624 8803 422 Email: aoliva@it.uc3m.es 423 URI: http://www.it.uc3m.es/aoliva/ 425 Juan Carlos Zuniga 426 InterDigital Communications, LLC 428 Email: JuanCarlos.Zuniga@InterDigital.com 430 Telemaco Melia 431 Alcatel-Lucent Bell Labs 433 Email: Telemaco.Melia@alcatel-lucent.com 435 Subir Das 436 Telcordia Technologies Inc. 438 Email: subir@research.telcordia.com