Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.21] Question about IEEE 802.21 PAR



Tony,
I don't disagree with you, perhaps it's a matter of terminology and I apologize if I used the wrong terminology. Please note that I don't state that 802.21 PAR is a vehicle to develop a L3 protocol in IETF. My statement is that even with the current PAR I do not see any conflict if 802.21 members get involved with influencing activities in IETF.
Stefano

> -----Original Message-----
> From: ext Tony Jeffree [mailto:tony@jeffree.co.uk]
> Sent: Wednesday, August 24, 2005 02:38
> To: Faccin Stefano (Nokia-NRC/Dallas)
> Cc: STDS-802-21@listserv.ieee.org
> Subject: RE: [802.21] Question about IEEE 802.21 PAR
> 
> 
> I think you have to be clear about what a PAR is, and what it is not.
> 
> A PAR is basically permission to do a specific piece of work within a 
> standards body sanctioned by the IEEE, where "piece of work" means a 
> standard, a guide, or a recommended practice. In other words, 
> a PAR is 
> authorization to write an IEEE standards document.
> 
> A PAR is NOT granted to facilitate or influence work in other 
> (non-IEEE) 
> standards fora; therefore the 802.21 PAR is not, and never will be, a 
> vehicle to "develop a L3 protocol ... in IETF". The IETF has its own 
> analogous mechanisms for sanctioning their standards development 
> activities, and they don't need ours.
> 
> Working groups in 802 can, and indeed very often do, get involved in 
> liaison activities aimed at ensuring that the work they do 
> (under their 
> PARs) is relevant, and aimed at influencing other organizations to do 
> complimentary pieces of work, but there is no mechanism 
> whereby we can set 
> up a project, or modify an existing project, such that its 
> scope is to get 
> a piece of work done elsewhere.
> 
> Regards,
> Tony
> 
> At 07:02 24/08/2005, stefano.faccin@nokia.com wrote:
> >Ajoy,
> >one question for clarification. I do not disagree with your 
> comments on 
> >the PAR. However, I am not sure at all why you see the PAR 
> in conflict 
> >with or not allowing to "develop a L3 protocol ... in IETF". 
> Even if the 
> >PAR does not state it explicitly, that does not mean that 
> the group cannot 
> >contribute to the development of solutions in IETF. 
> Specifically, I'm not 
> >sure how you go from saying "develop a L3 protocol ... in 
> IETF" to saying 
> >"influence development of L3 mobility management protocol in 
> IETF". I may 
> >be missing something here, but I have not witnessed any 
> efforts whatsoever 
> >of 802.21 in trying to influence the design of any L3 
> mobility mechanisms. 
> >If you're referring to the work related to 802.21 that will 
> take place in 
> >MIPSHOP, please be aware that work is not about designing a mobility 
> >management protocol or modifying an existing one. It is 
> about developing 
> >solutions to allow deployment of 802.21 services with a 
> transport and 
> >architecture @ L3 and above. Such soluti!
> >  ons shall be usable with existing mobility protocols. Such 
> solution can 
> > be based on existing protocols if any exist that match the 
> requirements. 
> > I hope we do not need to go once again through the whole 
> discussion that 
> > took place before the last MIPSHOP meeting and at the 
> MIPSHOP meeting.
> >
> >Stefano
> >
> >-----Original Message-----
> >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@MOTOROLA.COM]
> >Sent: Tuesday, August 23, 2005 12:17
> >To: STDS-802-21@listserv.ieee.org
> >Subject: [802.21] Question about IEEE 802.21 PAR
> >
> >
> >
> >Hi Ajay / All,
> >
> >
> >
> >I have a procedural question about 802.21 PAR. Please 
> clarify if I missed 
> >something
> >
> >as I was not part of PAR discussion. I asked this question during L3 
> >conference call today,
> >
> >but we could not complete the discussion.  I am just 
> wondering if current 
> >802.21 PAR allows
> >
> >us to develop a L3 protocol or influence development of L3 mobility 
> >management protocol in IETF.
> >
> >Based upon my understanding of PAR, 802.21 is going to 
> define mechanisms 
> >that would
> >
> >facilitate existing higher layer protocol such as Mobile / 
> IP etc. to 
> >optimize layer 3 handoff. Please see
> >
> >below a quote from PAR ( 
> >Five  <http://www.ieee802.org/21/802_21_5Criteria.doc> Criteria doc):
> >
> >
> >
> >" This standard shall facilitate optimization of Mobile IP handover, 
> >however this does not preclude the standard
> >
> >from being used to optimize handovers of other layer 3 protocols. "
> >
> >
> >
> >I would appreciate if you point me to appropriate sections 
> of PAR that 
> >enable us to influence the design of
> >
> >higher layer protocol as part of 802.21 activity. It is 
> likely that I 
> >missed something here as I was not involved in
> >
> >original PAR discussion.  Also, see below a text from (Five 
> Criteria Doc) 
> >that I think was used to justify the
> >
> >PAR of current 802.21 work:
> >
> >
> >
> >" Handover is a common mechanism, present in many systems 
> such as cellular 
> >systems or 802.11 ESSs. Mobile IP,
> >
> >in both v4 and v6 forms, has shown that roaming across heterogeneous 
> >systems is possible. Work in the IETF SEAMOBY,
> >
> >TRIGTRAN, CAPWAP/LWAPP projects has highlighted the need for greater 
> >interaction between 802 MAC and PHY
> >
> >layers and a roaming layer 3 in order to coordinate smoother, faster 
> >handovers. Accordingly it is clear that roaming within
> >
> >the confines of different 802 technologies is feasible and 
> that approaches 
> >that might be adopted for roaming at higher
> >
> >layers are feasible. Since the IETF has published in draft 
> form, a role 
> >that 802 networks can play in higher layer (above the LLC)
> >
> >handover it is clear that it is possible to incorporate such 
> mechanisms 
> >into the 802 framework.
> >
> >
> >
> >The proven ability to handover within 802.11 networks, 
> within cellular 
> >networks and within IP networks has proved a minimum
> >
> >set of capabilities for mobile technologies. The nature of 
> message passing 
> >protocols is such that the timing and passage of the
> >
> >messages is subject to observation and testing. Methods of testing 
> >interruptions to established sessions while being handed 
> over are well 
> >established in telephony and data networking practices.
> >
> >
> >
> >Neither security algorithms nor security protocols shall be 
> defined in the 
> >specification. This does not preclude the propagation
> >
> >of authentication or authorization information to support network 
> >detection and selection.
> >
> >
> >
> >This standard will provide services both across an 802 link 
> and to upper 
> >layers to
> >
> >*           Facilitate the optimization of detection and 
> selection of networks
> >
> >*           Provide a source of extensible and semantically defined 
> >information to facilitate optimized handover decision making
> >
> >*           Provide a mechanism to access this information 
> over an 802 link.
> >
> >*           Provide triggers to upper layers
> >
> >
> >
> >So, should 't we be defining mechanisms that would enable 
> the deployment
> >
> >of existing IETF protocols rather than trying to influence their 
> >design?  I guess IETF is anyway working to
> >
> >standardize various building blocks of Mobility Management 
> protocols. 
> >Anyway if we really
> >
> >want to influence IETF mobility management protocol design, 
> perhaps we 
> >should modify
> >
> >PAR to indicate this.
> >
> >
> >
> >Regards,
> >
> >Ajoy
> >
> >
> >
> >
> >
> >
> 
> Regards,
> Tony
> 
> 
>