IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-05-0325-01-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-01-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-01-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 Focus is specifically on IS 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-01-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 Current assumption: for the identification of requirements they are considered separately What are the requirements needed to support such scenarios? 21-05-0325-01-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-01-0000

Scenarios for MIIS with “L3 and above” transport Three main scenarios identified for IS: MIHF in UE communicates with 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 communicates with 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 MIHF in UE communicates with MIHF in sPoA using L2 or L3, MIHF in sPoA communicates with other MIHF in network using L3 E.g. proxy case, retrieval of IS info from “deeper” in the network, retrieval of dynamic IS information from new/target network/access All these 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-01-0000

Requirements Two types of requirements: Transport requirements Architectural/protocol requirements Protocol vs. interfaces: two interfaces considered (separately) to identify requirements UE MIHF  MIHF on network side (here referred to as “access” MIIS I/F) MIHF on network side  MIHF on network side (here referred to as “network” MIIS I/F) 21-05-0325-01-0000

Transport Requirements for MIIS “access” MIIS I/F: Reliability: ? Please add “network” MIIS I/F 21-05-0325-01-0000

Architectural/Protocol Requirements for MIIS “access” MIIS I/F: Discovery capability: The MIHF in the UE must be able to discover presence of MIHF in the sPoA/cPoA/network The MIHF in the UE must be able to discover address of MIHF in the sPoA/cPoA/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/cPoA/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 Protocol requirements: Capable to transport MIIS IEs according to current 802.21 draft (and future evolutions) in an efficient manner “network” MIIS I/F Please add 21-05-0325-01-0000

Scenarios for MIES/MICS TBD (current discussion focuses mainly on IS) 21-05-0325-01-0000

Requirements for MIES/MICS TBD (current discussion focuses mainly on IS) 21-05-0325-01-0000