doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 1 Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at enhancements to facilitate L3 interworking with other networks

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 2 Abstract A few points on L2/L3 interworking to support requirements definition.

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 3 Content Two main points: –Relation of L2/L3 handoff with same DS/different DS issue –Analysis of previous submission wrt actual issues and requirements

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 4 Previous Submissions IEEE /504r0, “Awareness of the handover to be distinguished from a L2 or L3” IEEE /710r0, “Access Router Identifier (ARID) for supporting L3 mobility”

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 5 Issues with L2/L3 Handoff STA doesn’t know whether handoff implies only change of AP or if L3 handoff procedure is required (I.e. inter-ESS handoff to another IP subnet or domain) IETF (DNA) has identified issues with delays in detecting the need to gain new IP connectivity Two sides of the problem: –STA cannot consider whether candidate APs are in same DS and/or subnet during selection of target AP for roaming/handoff –In case of handoff to AP in different subnet, this leads to slower overall handoff

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 6 Current Requirements REQ15: –Need a mechanism by which a STA can determine which APs are connected to the same DS as the current AP, and hence are preferred for roaming. –Sometimes called “ARID” because of the (incorrect) assumption that what is required is some means of identifying the routers connected to the DS. ASK THEM! Valid requirement, however this helps only with part of the issue (i.e. selection of preferred AP for roaming/handoff wrt DS/subnet) Does not help with speeding up L3 handoff Also: is determination of whether target AP is in same DS in scope of TGu (different DS vs same DS has nothing to do with IW with External Networks)?

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 7 Scope issues Is “L2/L3 Handoff” part of “IW with external networks”? –Handoff to different technology implies L3 handoff, but it’s not an issue for TGu to help with such L3 handoff –Inter-ESS handoff: not in scope of r –Inter-ESS handoff: in scope of –Inter-ESS handoff: in scope of TGu? Yes, essential for IW with external network

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 8 Questions Regarding requirement 15, what does “same DS” actually mean? –Should be defined carefully since implications of requirement on solution can be major Most typically “same DS” = “same subnet”, but –can “same DS” = “different subnet” as visible to STA? –can “different DS” = same subnet as visible to STA? Answers to these questions would help significantly in the identification of a solution Also, it may help frame the issue in such a way that the question is not just “same/different DS”, but “same/different subnet” and becomes completely in scope

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 9 Some Ideas Submitted: ARID (1) Use of ARID (AR Identifier) in beacons and Probe Response message to inform STA of change of AR Analysis (from IEEE /710r0): –Pros: Removing unnecessary packet exchanges between MN and AR when L2 handover. Reducing handover latency. Well managed method against SSID –Cons: Putting ARID in the beacon. Limited length (8-bits of reserved field). Requiring admin configurations.

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 10 Some Ideas Submitted: ARID (2) Additional analysis: –Requires administrative interface between AR and AP (not in scope of ) –Not flexible (i.e. based on a single identifier, not currently used for any L2 or L3 procedure) –Does not necessarily help with speeding up L3 handoff ARID does not help with DNA issues, unless further signaling is used

doc.: IEEE /402r0 Submission May 2005 Stefano M. FaccinSlide 11 Requirements/Suggestions Target a solution that allows both –Determining if AP is in same DS/different DS (e.g. different subnet) –Helping speeding up L3 handoff, e.g. allow L3 mobility to determine change of subnet ASAP help STA get a correct IP address ASAP Add a requirement –Req xx: A functionality is required to enable an STA to determine whether mobility to a different AP implies change of IP subnet, and to allow the STA to obtain sufficient information to speed up the L3 handoff