IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-05-0325-00-0000 Title: Higher Layer Requirements Strawman Date Submitted: July 26, 2005 Presented at IEEE 802.21 session #NN in City Authors or Source(s):  Stefano Faccin Abstract: This is the abstract text. Replace this text with a short statement of the contents and purpose of the presentation. Communicate well, you only have a few lines or so to convey the essence of the slides. 21-05-0325-00-0000

IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. 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. 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 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>  21-05-0325-00-0000

802.21 Higher Layer requirements for IETF Purpose of discussion: Identify the scenarios that 802.21 wants to enable through “L3 and above transport” Identify the requirements 802.21 has for IETF in order to Steer the creation of a work item in IETF Steer the work progress in IETF Summary of situation wrt IETF: No conclusions yet Internet AD and MIPSHOP WG chair have offered to host the work in MIPSHOP after an appropriate re-chartering of the WG At next IETF (Aug. 1-5) 802.21 has a slot for IS requirements in MIPSHOP under “Some Requirements for a Media Independent Handover Information Service” (draft-faccin-mih-infoserv-00.txt). Authors will give up willingly the slot for more generic presentation on 802.21 requirements A MIHEP bar BOF still will take place (details TBD, waiting on AD for room assignment) to discuss further with experts present at IETF (and to create more awareness) Though MIPSHOP is currently very FMIP oriented, there is actual willingness to re-charter and include 802.21 work However, even with re-chartering, MIPSHOP can cater mainly for IS aspects. ES and CS might need a different location 21-05-0325-00-0000

Some Questions for 802.21 What scenarios do we want to enable? Essential to identify requirements Independently of what is in current draft, Are we willing, or Do we need to consider IS separately from ES and CS from an IETF point of view? We need to keep in mind requirements from a “L3 and above transport” may be quite different Suggestion: for the identification of requirements, let’s consider them separately If requirements match, then we know we can consider them together What are the requirements needed to support such scenarios? 21-05-0325-00-0000

802.21 “L3 and above “ transport: what do we mean? When approaching IETF, it is essential to clarify what we mean Defining “L3 and above transport” for 802.21 implies: Defining architectural aspects: MIHF discovery  IETF Security aspects (e.g. )  IETF Addressing? What messages and IEs and according to MIH logic Reliable transport versus not-reliable Etc. 21-05-0325-00-0000

Scenarios for MIIS with “L3 and above” transport Three main scenarios identified for IS: MIHF in UE contacts MIHF in cPoA using L3 connectivity over current access when no MIHF is present in sPoA cPoA is used as transport for L3 connectivity when MIHF in sPoA has no relationship with MIHF in cPoA and no data can be retrieved, but UE ahs visibility of MIHF in cPoA MIHF in UE contacts MIHF in sPoA using L3 connectivity E.g. when L2 transport for specific access technology has not yet been defined or has not yet been deployed/implemented Please add … All three scenarios can be used to help with network selection problem at roaming/handoff Initial network selection (I.e. no connection established with any access/network/domain yet) cannot be supported through “L3 or above” transport, unless specific tricks are done at L2 21-05-0325-00-0000

Requirements for MIIS Discovery capability: The MIHF in the UE must be able to discover presence of MIHF in the sPoA/network The MIHF in the UE must be able to discover address of MIHF in the sPoA/network to exchange L3 or above traffic It should be possible to drive discovery of MIHF though information provided by UE (e.g. UE indicates that MIHF for 802.11 wrt 802.16 is needed, if there is one) Security: As part of discovery, the MIHF in the UE must be able to discover whether a security association can/shall be established with the MIHF in sPoA/network, and if yes which credentials can be used to authenticate with MIHF in sPoA/network Encryption: encryption of 802.21 traffic on “L3 transport and above) for MIIS can optionally be used On/off decision can be made during discovery phase (e.g. mandated by UE or network policies) Integrity protection Replay detection: optional for MIIS The MIHF in the UE must be capable to discover presence of MIHF in the sPoA/network Reliability: ? Protocol requirements: Capable to transport MIIS IEs according to current 802.21 draft (end future evolutions) in an efficient manner 21-05-0325-00-0000

Scenarios for MIES/MICS TBD 21-05-0325-00-0000

Requirements for MIES/MICS TBD 21-05-0325-00-0000