> > Regarding using Ad Hoc networks as transit networks is very > important > > discussion, and the views in industry are mixed. I > personally believe > > this must be supported for emergency preparedness reasons and I can > come > > up with many others, and that the IETF community needs to develop Ad > Hoc > > network specs, ops views, etc that include viewing Ad Hoc nets as > > transit providers. This will have much debate is my guess. > > I would separate this into two cases, one being an AHN that > is a transit > to another AHN, which I would be interested in (or more generally, > AHNs which collectively are a stub, but individually may be transit > networks), the other being an AHN with multiple connections to the > fixed Internet (or any other network with significantly greater > stability, reliability and/or - usually and - bandwidth) the > AHN acting > as a transit for the other network. The latter I'd be happy > to exclude.
I still believe stub is poor explanation and I emphatically do not want to exclude AHN as transit to reach another fixed Internet. Earthquake takes out a town. AHNs form. Metro Fixed Internet is enabled (dark fiber to Wimax towers, or Satcom) consisting of distributed Internet (virtualized and I am not implying VPN tunnels). The primary fixed Metro Internet IX goes down and is re-established at different physical, mobile, or routing topology location. But, the AHN is aware of all nets from multiple interfaces. The AHN can be used to assist to announce all new converged routes to all nets to the new Metro Fixed Network, as a transit network. This needs to be dicussed in far greater depth is my point and why I am against exclusion at this point, it should be on the design center table of the IETF discussion. > I'd postpone considering the former too if it helped the process along > (or include it if that helped the proces along, but that seems less > likely). I don't agree. We have waited this long to standardize this entire space and it affects lives in several deployment models. What is out there today for Defense or 911 is not acceptable, and is not interoperable, and as you know does not meet the John Garstka principles of net centricity. It is high time the IETF now is discussing all these topics and are more than qualified with the technical wealth within our community to work on this objectively. When spec ops, policeman, fireman, or doctors have to pick up a cell phone to communicate because the AHN is broken is not good, and that is the case today, and the IETF can do a great service for networking by taking this on besides what the MANET WG has done at this juncture. > > [Incidentally I take your point about there being a logical difference > between MANETs and AHNs and have used the latter above. However in > practice the distinction blurs, I've presented results from a real > network which had non-mobile nodes, but was a non-static network > - and that was before allowing nodes to fail. I think what you really > want are protocols that can be adapted - or better yet adapt > themeselves > - to the range of conditions, and I hope at least some of this will > come out in Standards Track routing protocols. But that's off > the point > here I think, hence the brackets.] As you, I glean from your mail? I am working real live scenarios with real live direct participant input that what is there now is not working at all, and they are picking up cell phones. Clearly we cannot wait entirely for standards to complete. but the IETF moving in this direction and work is at least a hope for tomorrows interoperability. If we just follow the principles of net centricity then we have half the battle won, and the gaps for that to be deployed require some standardization for protocols, ops views, and updated lexicon from specs like 2501. We know more today about the Internet today for AHNs and Mobility than we did 10 years go when pioneers like Charlie Perkins and Dave Johnson began this form of work in the IETF. NB: Tenets of Net Centricity are as follows: end-to-end communications that supports connectivity, interoperability, security, and discovery. For IETF purposes across the Internet. For First Responders or 911 support within a Metropolitan network with access to some form of command control center, and for Defense these principles should work and apply across their Global Information Grid (not Grid per GGF or the SOA from Father of that Grid Dr. Ian Foster, but rather a network Grid). /jim _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
