1. 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 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.

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 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
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development

3. 802.21 Higher Layer requirements for IETF
Purpose of discussion:
Identify the scenarios that wants to enable through “L3 and above transport”
Identify the requirements 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)
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 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 work
However, even with re-chartering, MIPSHOP can cater mainly for IS aspects. ES and CS might need a different location

4. 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?

5. 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 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.

6. 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

7. 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)

8. Transport Requirements for MIIS
“access” MIIS I/F:
Reliability: ?
Please add
“network” MIIS I/F

9. 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 wrt 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 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 draft (and future evolutions) in an efficient manner
“network” MIIS I/F
Please add

10. Scenarios for MIES/MICS
TBD (current discussion focuses mainly on IS)

11. Requirements for MIES/MICS
TBD (current discussion focuses mainly on IS)