RE: On the MIHEP initiative in IETF
Hi,
sorry for a minor typo below. Please find enclosed the correct mailing list information.
Stefano
To subscribe, send an e-mail to majordomo@ecselists.eng.monash.edu.au, with the words
"subscribe mihep" in the message body. A confirmation e-mail will be sent to you.
To post, send an e-mail to mihep@eng.monash.edu.au.
The mailing list archive can be found on the WWW at:
http://ecselists.eng.monash.edu.au/~warchive/mihep/
(archive not completely up and running yet)
> -----Original Message-----
> From: Faccin Stefano (Nokia-NRC/Dallas)
> Sent: Wednesday, July 13, 2005 10:11
> To: STDS-802-21@listserv.ieee.org
> Subject: On the MIHEP initiative in IETF
>
> Dear colleagues,
>
> please find enclosed a copy of an IETF BOF request submitted to IETF and closely related to 802.21. The BOF has not been approved due to insufficient discussion on mailing lists (i.e. we started the discussion late wrt the deadlines for next IETF meeting). A bar BOF will take place at the IETF meeting in August in Paris (with an agenda along the line of the one proposed below). MIHEP also has a time slot in the MIPSHOP WG agenda.
>
> Additional information will be discussed at the next week 802.21 meeting. If interested in following/participating, please find enclosed the mailing list information. Your feedback and contributions would be highly appreciated.
>
> Best regards,
> Stefano
>
> MIHEP (Media Independent Handoff Enabling Protocols)
> Target area: Internet area
> CHAIRS:
> Stefano Faccin (stefano.faccin@nokia.com)
> Greg Daley (Greg.Daley@eng.monash.edu.au)
> AGENDA:
> - Agenda bashing
> (Stefano Faccin/Greg Daley, The BOF chairpersons) - 5 minutes
> - Background & Status
> (Stefano Faccin/Greg Daley, The BOF chairpersons) - 5 minutes
> - Background on IEEE 802.21
> (IEEE 802.21 chair - Ajay Rajkumar - or vice-chair - Michael Williams)
> 15 minutes
> - Requirements for a Media Independent Handoff Information Service
> draft-faccin-mih-infoserv-00.txt
> (http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt)
> (Daley) - 10 minutes
> - Requirements for Media Independent Handoff Event and Command Services
> (Faccin) - 10 minutes
> - Neighborhood Information Elements Discovery
> draft-kempf-mobopts-nhood-discovery-00.txt
> (http://www.geocities.com/kempf42/draft-kempf-mobopts-nhood-discovery-00.txt)
> (Kempf/Koodli) - 10 minutes
> - Draft of the charter
> (Faccin/Daley) - 15 minutes
> - Open Discussion - 20 minutes
> "Should a WG exist"-consensus-question; relation with other WGs (e.g.
> MIPSHOP), discuss how the work could be included in MIPSHOP.
> DESCRIPTION:
> Work within the IEEE's 802.21 working group (Media Independent Handoff) is aimed at providing
> media independent handoff service, to assist with handoffs between heterogeneous link-layer
> technologies, and across upper-layer subnet boundaries. IEEE 802.21 has recently harmonized
> on a proposal which has been accepted as a basis for standardizing a Media Independent
> Handoff (MIH) Service (http://www.ieee802.org/21/may05_meeting_docs/21-05-0271-00-0000).
> This document is aimed at providing a framework for implementation of MIH service access
> points (SAPs) to interface with upper layer protocols, as well as interfaces for communicating
> handoff centric information between peer 802 or cellular network entities. The information
> exchanges are classified as MIH Event Service (MIHES), MIH Command Service (MIHCS), or
> MIH Information Service (MIHIS).
> The MIH Event Services provide immediate communications to within a Media Independent
> Handoff Function - MIHF (e.g. with an event generated from link layer and delivered to
> upper-layers) or to a peer MIHF on the other end of the Link-layer medium. Events indicate that
> changes are occurring in the wireless environment: for example, that it is now possible to send>
> generic upper-layer frames. Events delivered to a peer MIHF on the other end of the link-layer
> medium are called remote events.
> The MIH Command Services are instructions from upper layer handoff controlling entities to
> change the state of the wireless link, and may be sent within a stack, or passed to a peer MIH
> entity on the other side of a wireless link. For example: the network may be able to instruct a
> station to handoff to another network or link layer technology within the same domain.
> Commands delivered to a peer MIHF on the other end of the link-layer medium are called remote
> commands. Such command mechanisms may cause further event generation, either from the
> local Medium Independent Handoff Function, or on the peer.
> The MIH Information Service provides topological and location related information of service
> networks to end devices' Layer-2 media independent handoff function (MIHF). The data received
> in the Media Independent Handoff Function would be passed to interested upper layer protocols,
> potentially filtered for content, as is appropriate.
> The MIHIS distinguishes itself from the other mechanisms in that the messages are typically
> larger and do not have the same time critical delivery requirements. The MIHES and MIHCS have
> typically strong requirements for reliable and timely delivery of events/commands.
> IEEE 802.21 foresees delivery of information related to the MIH services through link layer specific
> solutions (e.g. enhancements of IEEE 802.11 MAC management/action frames) or through an
> upper- layer protocol. Though IEEE 802.21 will define the semantic and information of the MIH
> services, it will specify neither the delivery through link layer nor through upper layer protocols.
> The endpoint for remote communications in MIH services may be a device other than the directly
> adjacent link-layer peer. As described in the current 802.21 draft, in this case, it is believed an
> upper-layer protocol should be used to deliver information. In that case, it is possible that network
> information may be either centrally stored on a server or distributed in each individual access
> network. Presumably, an L2 or L3 based mechanism to identify a valid information server would be
> required. Delivery of MIH services though an upper-layer protocol also enables deployment of MIH
> services independently of the functionality available at link layer, i.e. it does not require the
> modification of link layer devices (e.g. access networks), therefore enabling MIH services even if
> IEEE standardization has not yet define how MIH services are implemented through link layer
> specific mechanisms.
> For MIH Information Services, several network-layer schemes have been proposed in IETF which
> provide information related to mobility. FMIPv6 Proxy Router Advertisement, and the Candidate
> Access Router Discovery Protocol both define experimental schemes for delivering network state
> information to moving hosts. What is not clear is the mapping of these onto the existing MIH
> requirements from 802.21. Additionally, more general information and message exchange services
> are available through SNMP, LDAP, and BEEP.
> In assessing the best form for delivery of MIH information services over IP, the prior experience of
> both network layer mobility and information service developers is sought. It is intended that this
> experience may allow adoption or adaptation of existing schemes, rather than reinvention of
> mechanisms, if they meet the requirements of 802.21.
> MIHEP does not focus on development of mobility solutions, and therefore aims at coordinating
> with the work on-going in MIPSHOP MIP4, DNA and Mobopts groups, while at the same time not
> overlapping with the work on-going in such groups.
> The MIHEP effort focused on the MIH information service aims at defining a protocol solution to>
> deliver information related to a network point of attachment; specifically, at the link layer the
> information service will provide information such as the cost of the access, the type of credentials
> to be used for authenticating the access, the type of services available (e.g. IP4 versus IPv6
> connectivity, guaranteed QoS at link layer and /or at IP layer, access to the Internet, access to
> 3GPP/3GPP2 services), and a variety of other information. MIHEP does not focus on providing
> configuration information like the DHC group does, i.e. for automated allocation, configuration and
> management of IP addresses and TCP/IP protocol stack parameters.
> The aim of the MIHEP WG is at:
> - investigating requirements (based on the work done in 802.21) for protocols to support MIHIS,
> MIHCS and MIHES
> - investigating if any protocols currently existing can satisfy the requirements in the current form
> or with extensions
> - defining the protocol (or protocol enhancements) for MIHIS
> - defining the protocol (or protocol enhancements) for MIHES and MIHCS
> As a result of the investigation, the WG may determine that a single protocol can be used for
> MIHIS, MIHCS and MIHES.
> A set of IDs has recently been created that relate to this work:
> - Requirements for a Media Independent Handoff Information Service
> (draft-faccin-mih-infoserv-00.txt, Greg Daley & Stefano Faccin)
> - Neighborhood Information Elements Discovery
> (draft-kempf-mobopts-nhood-discovery-00.txt, Rajeev Koodli and James Kempf).
> GOALS AND MILESTONES:
> Jul 05 MIHEP BOF meets
> Nov 05 Submit to IESG Goals for Media Independent Handoff Enabling Protocols
> Mar 06 Submit to IESG a set of requirements for a MIHEP protocol for IEEE 802.21 MIHIS
> Mar 06 Submit to IESG a set of requirements for a MIHEP protocol for IEEE 802.21 MIHES
> and MIHCS
> Jul 06 Submit to IESG Framework document for MIHEP solutions
> Mar 07 Submit to IESG MIHEP Enhancements for Information Service
> Jun 07 Submit to IESG MIHEP Enhancements for Event and Command Services
> MAILING LIST
> A mailing list for discussion has been created.
> To subscribe, send an e-mail to majordomo@eceslists.eng.monash.edu.au, with the words
> "subscribe mihep" in the message body. A confirmation e-mail will be sent to you.
> To post, send an e-mail to mihep@eng.monash.edu.au.
> The mailing list archive can be found on the WWW at:
> http://ecselists.eng.monash.edu.au/~warchive/mihep/
> (archive not completely up and running yet)