Re: [802.21] On the MIHEP initiative in IETF
Hi Ajoy,
With regard to the use of CARD for 802.21 IS, I don't understand why
every access router should implement CARD and act as a server or proxy
of IS. I think one advantage of the use of IP protocol for IS is to
be flexible enough to have a server of proxy of IS to anywhere in the
network.
Regards,
Yoshihiro Ohba
On Wed, Jul 13, 2005 at 11:41:28AM -0500, Singh Ajoy-ASINGH1 wrote:
> 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)