10
Mobility Management in WLAN IW Inma Carrion, Vijay Devarapalli Nokia Raymond Hsu Qualcomm Inc. Pete McCann, Frank Alfano Lucent Serge Manning Sprint Notice: Contributors grant free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any

Mobility Management in WLAN IW Inma Carrion, Vijay DevarapalliNokia Raymond HsuQualcomm Inc. Pete McCann, Frank AlfanoLucent Serge ManningSprint Notice:

Embed Size (px)

Citation preview

Mobility Management in WLAN IW

Inma Carrion, Vijay Devarapalli Nokia

Raymond Hsu Qualcomm Inc.

Pete McCann, Frank Alfano Lucent

Serge Manning Sprint

Notice: Contributors grant free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.

General• Similar solutions for MIP4 and MIP6 whenever possible

• MS indicates mode of operation (e.g., MIPv4 FA or CCoA) via new vendor attributes in CFG_REQUEST of IKEv2 negotiation. Network authorizes the mode the MS uses based on user profile or network policy.

• MS may request MIP bootstrap info. PDIF replies bootstrap info in new vendor attributes in CFG_REPLY

General note: issues marked with * are still open and even if kept for clarity they are still under ongoing work. Slide 10 includes a list of open issues.

• MS Behaviors:• MS sends IKE-AUTH[CFG_REQUEST] with CONFIG-PAYLOAD (INTERNAL-IP4-ADDRESS).

• If MS initiates a new MIPv4 session, MS sets INTERNAL-IP4-ADDRESS to 0 (* or don’t include it at all) and may request for MIP bootstrap info.

• If MS is handoff from 1x system, MS doesn’t request for MIP bootstrap info.

• If FA mode is used, MS sets INTERNAL-IP4-ADDRESS to HoA.

• If CCoA mode is used, MS sets INTERNAL-IP4-ADDRESS to 0.

• If FA mode is used, MS MIP registers TIA as HoA. • PDIF Behaviors:

• PDIF contacts HAAA. If the MS requested MIP info, PDIF may return static MIP info if provisioned in the HAAA.

• PDIF replies with TIA in CONFIG-PAYLOAD.• If FA mode is used, PDIF sends HoA as TIA to the MS and uses HoA as TIA in the SPD entries.

• If CCoA mode is used, PDIF allocates TIA (local to the PDIF) to the MS.

• If PDIF gets HoA (from HAAA or *HA),PDIF sends it in a vendor payload.

IKEv2 Behaviors for MIPv4 Support

• MS Behaviors:• MS sends IKE-AUTH[CFG_REQUEST] with CONFIG-PAYLOAD (INTERNAL-IP6-ADDRESS set to 0)

• If MS initiates a new MIP6 session, MS may request for MIP bootstrap info.

• If MS is handoff from 1x system, MS doesn’t request for MIP bootstrap info.

• MS sends binding update to HA using PDIF allocated TIA as the CoA and PDIF allocated HoA as the HoA.

• PDIF Behaviors:• PDIF contacts HAAA. If the MS requested MIP info, PDIF may return static MIP info if provisioned in the HAAA.

• PDIF allocates TIA (local to the PDIF) and sends it in CONFIG-PAYLOAD to the MS.

• If PDIF gets HoA (from HAAA or HA), PDIF sends it in a vendor payload.

IKEv2 Behaviors for MIP6 Support

Scenario 3 + MIP bootstrappingMS H-AAAPDIF

IKE_AUTH_req

CFG_REQUEST for TIA

RADIUS Access-Request/ Diameter-EAP-Request/AA-Request

IP Service Identifier

1

2

3

4

5

6

RADIUS Access-Challenge/Diameter-EAP-Answer

HA (opt), HoA (opt)

HA

IKE_AUTH_res

TIA, HA, HoA, home prefix

MIP service allowed?IPv4 or IPv6?FA mode or CCoA mode?Static TIA for MS?HA for the user/service?

* Request HoA (if not received from H-AAA)OPEN

* HoA, prefix (if requested)OPEN

MIP 4 FA modeMS H-AAAPDIF/FA

IKE_AUTH_req

CFG_REQUEST: TIA and HA, HoA (opt)RADIUS Access-Request/

Diameter-EAP-Request/AA-RequestIP Service Identifier

1

2

3

4

5

6

7

RADIUS Access-Challenge/Diameter-EAP-Answer

HA, HoA (opt)

HA

IKE_AUTH_res

TIA= HoA

MIP service allowed?IPv4 or IPv6?FA mode or CCoA mode?TIA for user/service?HoA for user/service?HA for the user/service?

(7) PDIF does not need to assign TIAHoA is the same address as TIAPDIF gets HoA either from HAAA (static) or from * HA (dynamic)

AGENT ADVERTISEMENTS

RRQ

(it may include HoA if received in IKEv2 payload otherwise it sets it to 0.0.0.0)

RRQ

(it may receive HoA if it set HoA to 0.0.0.0)

(1) MS may req mip bootstrap info, it also may indicate mode, HA and hoa if it is doing vertical handoff

(3) optional since the MS may have HoA already if it is doing handoff

* Request HoA (if not received from H-AAA)OPEN

* HoA, prefix (if requested)OPEN

8

9

MIP4 CCoA modeMS H-AAAPDIF/FA

IKE_AUTH_req

CFG_REQUEST for TIAand HA, HoA

RADIUS Access-Request/ Diameter-EAP-Request/AA-Request

IP Service Identifier

1

2

3

4

5

6

7

RADIUS Access-Challenge/Diameter-EAP-Answer

HA (opt), HoA (opt)

8

HA

IKE_AUTH_res

TIA, HoA, prefix

MIP service allowed?IPv4 or IPv6?FA mode or CCoA mode?Static TIA for MS?HA for the user/service?

PDIF assigns TIAPDIF includes HoA in the response (opt)

RRQ TIA, HoA

(it if didn’t received HoA in ikev2 payload, then HoA=0.0.0.0)

RRP

(it may receive HoA if it set HoA to 0.0.0.0)

(1) MS may req mip bootstrap info, it also may indicate mode, HA and HoA if it is doing vertical handoff

* Request HoA (if not received from H-AAA)OPEN

* HoA, prefix (if requested)OPEN

MIP6MS H-AAAPDIF

IKE_AUTH_req CFG_REQUEST for TIA

and HA, HoARADIUS Access-Request/

Diameter-EAP-Request/AA-RequestIP Service Identifier

1

2

3

5

6

RADIUS Access-Challenge/Diameter-EAP-Answer

TIA (opt), HA, HoA, prefix

HA

IKE_AUTH_res

TIA, HA, HoA, prefix

MIP service allowed?IPv4 or IPv6?FA mode or CCoA mode?Static TIA for MS?HA for the user/service?

PDIF assigns TIAPDIF includes HoA in the response (opt)

BU

TIA=CoA, HoA

BACK

(1) MS may req mip bootstrap info, it also may indicate mode, HA and hoa if it is doing vertical handoff

* Request HoA (if not received from H-AAA)OPEN

* HoA, prefix (if requested)OPEN

4

7

8

New attributes in IKEv2 CONFIG payload

New Attributes: 3GPP2_MIP4_MODE, 3GPP2_MIP4_HA, 3GPP2_MIP4_HOA, 3GPP2_MIP6_HA, 3GPP2_MIP6_HOA

Usage Examples:1. MS initiates a new MIPv4 session in FA CoA mode and wants HoA

bootstrap3GPP2_MIP4_MODE (set to FACOA)3GPP2_MIP4_HOA (set to 0)*INTERNAL_IP4_ADDRESS (set to 0)

2. MS initiates a new MIPv4 session in CCoA mode and wants MIP bootstrap

3GPP2_MIP4_HOA (set to 0)INNER_IP4_ADDRESS (set to 0)

3. MS is handoff an existing MIP session in FA COA mode3GPP2_MIP4_MODE (set to FACOA)3GPP2_MIP4_HOA (set to existing HoA)*INTERNAL_IP4_ADDRESS(set to existing HoA)

4. MS is handoff an existing MIP session in CCOA modeINNER_IP4_ADDRESS (set to 0)

Issues for Further Study

• If the MS initiates a MIPv4 session using FA CoA and wants a HoA dynamically assigned by the network, the solution proposed in this contribution supports static HoA assignment by the HAAA. In addition to that, a solution for dynamic HoA assignment by the HA as is still under discussion and therefore marked as open along the slide set (see * marked messages between PDIF-HA in slides 5-8).

• How does the MS bootstrap HA information? The solution proposed in this contribution allows the network to select HA and convey it to the MS via IKEv2 vendor payload. The issue is that in addition do we want to allow the MS to use DNS to discover HA?

• If the PDIF doesn’t indicate to the HAAA to send MIP6 bootstrap info, should the HAAA send it anyway (based on operator policy)?

• Whether to address the scenario where the PDIF and the HA are in the same subnet. Need to study the impact on the MS and network behaviors.