RE: [802.21] On the MIHEP initiative in IETF
Hi Stefano,
Please find my inline replies.
Regards,
Ajoy
-----Original Message-----
From: stefano.faccin@nokia.com [mailto:stefano.faccin@nokia.com]
Sent: Wednesday, July 13, 2005 12:38 PM
To: Singh Ajoy-ASINGH1; STDS-802-21@listserv.ieee.org
Subject: RE: [802.21] On the MIHEP initiative in IETF
Ajoy,
please forgive me if I'm wrong, you seem to have the impression that somebody is stating that CARD cannot be the protocol selected for L3 transport of 802.21 services.
Ajoy-> This is not my point. IETF has no background in IEEE 802.21 work so I am not sure if we can make good choice in IETF about IEEE problem. During CARD development, IETF has extensively discussed pros and cons of various approaches required for information service protocol. So, I am not sure if starting the same discussion again will add much value. So, if we think we need an information service protocol then perhaps we should justify why existing protocol won't be able to address the problem or cannot be extended to address the problem.
Please keep in mind that nobody is saying that CARD cannot be the protocol that will be selected.
Ajoy-> I am not sure why IETF should define multiple similar protocols and then make a determination about which one to use. Sorry if I am not following your argument here. CARD was made a work item based IETF consensus.
What is being said is that the evaluation of existing protocols must be made against a set of requirements. Exactly because you worked in IETF you should be well aware that IETF must always start from requirements and then go through a process of evaluating existing protocols against the requirements before making a decision. That is the only way to guarantee that an optimal solution is found.
Ajoy-> Note that IETF has extensively discussed information service protocol earlier so I am not sure why there is need to do similar exercise again. If you think existing protocol would require change or enhancement please send an email to the authors so that proposed changes are discussed. If there is a need to start a working group then that can addressed as well.
As for which protocol we may like or not, as Daniel suggests the location for that discussion is IETF, not 802.21. For that reason, through the MIHEP initiative we're trying to create a venue in IETF where the work can be discussed and carried out.
Stefano
-----Original Message-----
From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]On
Behalf Of ext Singh Ajoy-ASINGH1
Sent: Wednesday, July 13, 2005 12:00
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] On the MIHEP initiative in IETF
Hi Stefano,
Thanks for your reply. Having worked in IETF (CARD) and little bit in IEEE 802.21, I really feel that starting with a protocol that has already undergone numerous reviews in IETF is better idea. Also, it is much more easier to extend an existing RFC to make it usable for 802.21 than trying to re-invent a new protocol. My intention here is to help IEEE 802.21 to resolve the L3 transport issue as fast as possible.
Regards,
Ajoy
-----Original Message-----
From: stefano.faccin@nokia.com [mailto:stefano.faccin@nokia.com]
Sent: Wednesday, July 13, 2005 11:47 AM
To: Singh Ajoy-ASINGH1; STDS-802-21@listserv.ieee.org
Subject: RE: [802.21] On the MIHEP initiative in IETF
Ajoy,
glad to see you're still following this. Yes, I do recall you making such comments and proposal. Please keep in mind it is premature to start pushing for one protocol or another, since we don't even yet have any WG that is chartered to pick up this work item. Discussing about pros and cons of protocols now would only hinder our abilities to get IETF to work on the L3 transport needs of 802.21. If and once a WG is chartered to work on this (a new WG or an extension of an existing one), after a requirements definition analysis (that I expect will be based mostly on 802.21 requirements but that still needs to happen in IETF to avoid giving IETF the feeling that we just want their stamp of approval), I expect that the next step would be a process of evaluating if existing protocols can satisfy the requirements. that would be the perfect phase to push for CARD if you believe it is a valid candidate.
Thanks for bringing this up.
Best regards,
Stefano
-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
Sent: Wednesday, July 13, 2005 11:41
To: Faccin Stefano (Nokia-NRC/Dallas); 'STDS-802-21@listserv.ieee.org'
Subject: RE: [802.21] On the MIHEP initiative in IETF
Stefano,
I made comment in IETF mailing regarding the possibility of using / extending CARD RFC 4066 for IEEE 802.21 activity. I am also attaching for the benefit of folks who do not attend IETF.
Regards,
Ajoy
Hi Michael,
I do not see any mention of CARD protocol here. I think CARD is more appropriate candidate for IEEE 802.21 information service protocol. CARD is now published as experimental RFC. So, I would request that we should focus to advance CARD protocol to standard track and then use CARD for information service unless we can really find good reason to define a new protocol.
Perhaps you might remember that I have mentioned use of CARD protocol in one of earlier IEEE 802.21 meetings but I could not continue to participate in subsequent IEEE meeting due to personal reason.
Regards,
Ajoy
-----Original Message-----
From: mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] On Behalf Of Michael.G.Williams@nokia.com
Sent: Wednesday, July 06, 2005 5:02 PM
To: mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au
Cc: kempf@docomolabs-usa.com; gabriel_montenegro_2000@yahoo.com; rajeev@iprg.nokia.com; margaret@thingmagic.com; Basavaraj.Patil@nokia.com
Subject: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES
Colleagues,
The IEEE 802.21 working group is developing services for facilitating IP address mobility and service mobility, especially handoff across a variety of media. The group is interested in working with the relevant IETF/IRTF working groups to develop methods of carrying these services across the network. It would be ideal to discuss this at the next IETF meeting.
There are multiple drafts currently issued or in development that are interesting and could serve as the basis for starting the work.
Drafts of interest include but are not limited to :
"Neighborhood Information Elements Discovery (NED) (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic protocol for carrying information elements of interest to IEEE 802.21."
"Some Requirements for a Media Independent Handover Information Service"
(draft-faccin-mih-infoserv-00.txt,
http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt
<http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt> ).
"Architectural Implications of Link Indications"
http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt
<http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt>
"Unified L2 Abstractions for L3-Driven Fast Handover"
http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0
2.txt
"A Framework of Media-Independent Pre-Authentication (MPA)"
http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00.
txt
Best Regards,
Michael G. Williams
IEEE 802.21 Working Group Vice Chair
_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts
Hi James,
I finally managed to read your proposed nhodd draft.
After reading the draft, I am not really convinced why we need to define a new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I am still trying to understand how the newly proposed draft solves the problem of IEEE 802.21 any better than existing CARD protocol. In my view perhaps taking the CARD protocol to standard track is better idea than trying to invent a new protocol to solve the problem.
Regards,
Ajoy
-----Original Message-----
From: mobopts-bounces@rtf.org [mailto:mobopts-bounces@irtf.org] On Behalf Of James Kempf
Sent: Friday, July 08, 2005 11:05 AM
To: mipshop@ietf.org
Cc: mobopts@irtf.org
Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt
Folks,
I've posted the Neighborhood Discovery draft by Rajeev and myself to the Internet Drafts directory. Until it is available, you can find it here:
http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt
This is the same draft as I previously posted for Mobopts, except I changed the filename to reflect the fact that this topic is now going to be discussed in MIPSHOP (I think, discussion is still ongoing).
This draft is intended to partially fufill the IEEE 802.21 requirement for network information discovery.
Please send comments if you have any.
jak
_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts
-----Original Message-----
From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org] On Behalf Of Stefano M. Faccin
Sent: Wednesday, July 13, 2005 10:11 AM
To: STDS-802-21@listserv.ieee.org
Subject: [802.21] 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)