Re: [Ieprep] on the ieprep charter
Fred Baker <fred@cisco.com> Fri, 28 July 2006 18:43 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XIa-0002tp-Ky; Fri, 28 Jul 2006 14:43:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XIY-0002tT-L0 for ieprep@ietf.org; Fri, 28 Jul 2006 14:42:58 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XIW-0007IO-7X for ieprep@ietf.org; Fri, 28 Jul 2006 14:42:58 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2006 11:42:55 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SIgt6t010139; Fri, 28 Jul 2006 11:42:55 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6SIgtJi003279; Fri, 28 Jul 2006 11:42:55 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 11:42:55 -0700
Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 11:42:54 -0700
In-Reply-To: <1154103399.5427.366.camel@north-latitude.nps.navy.mil>
References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <B8C892A4-F711-4928-8EDA-FD7E717B702F@cisco.com> <44C9160F.1060001@jhuapl.edu> <DBC1A7C7-9F3C-4557-A7BC-E081C482A5C3@cisco.com> <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk> <1154103399.5427.366.camel@north-latitude.nps.navy.mil>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <042EB3AC-C5A9-463E-B2B6-308231411ED9@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] on the ieprep charter
Date: Fri, 28 Jul 2006 11:42:53 -0700
To: ken carlberg <carlberg@g11.org.uk>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 28 Jul 2006 18:42:54.0908 (UTC) FILETIME=[A36857C0:01C6B275]
DKIM-Signature: a=rsa-sha1; q=dns; l=3120; t=1154112175; x=1154976175; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20<fred@cisco.com> |Subject:Re=3A=20[Ieprep]=20on=20the=20ieprep=20charter; X=v=3Dcisco.com=3B=20h=3DhF46nYRTNqWFkPqT/8l/+JDUBL8=3D; b=XyfU1m1+J7yDS2h0MWCdAyFtC/wr8ZnJYSNoOyzXH+/iJjnWgdhlMKc/McRWEHoO6iIKNPHu oHj2gqh6e8Un60wvigNTCzDA6pssNyKYU9YdwpeSFZzavdkuXGNxy7NA;
Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: Rex Buddenberg <budden@nps.navy.mil>, Robert Cole <robert.cole@jhuapl.edu>, ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org
In the general case, I would expect push-to-talk to be handled by provisioning. I'm not certain that the capability is of an "emergency" nature. In civilian networks, it is commonly used on virtual trading floors and as a walkie-talkie replacement. I can't say I know for certain how it is used in military networks (they haven't told me), but I would expect that it permits communication among a physically distributed group of people that operate as a team, such as command/control operations. In civilian networks, the way it generally works is by ensuring (either by provisioning of bandwidth or by placing traffic into an appropriate class) that there is bandwidth available to the application at the time it needs it, and is generally a low capacity channel. On Jul 28, 2006, at 9:16 AM, Rex Buddenberg wrote: > Ken, > > You're correct on multicast. Reinforce: > > - demand side. A great deal of data in both military and emergency > services is multicast in nature. Much higher proportion than in > commercial world. And as soon as you factor in high availability > engineering, everything becomes multicast -- you send data >1 place > so a > lucky hit on target A doesn't take all the data. > > - supply side. Increasingly we can look at the radio-WANs as interior > network segments. Platforms have LANs in them and the radio-WAN > has no > end systems on it -- they're all on the LAN, other side of the router. > This is most obvious in the surface navy today, but it's a trend. > Both > LANs and the fixed internet are or can easily be provisioned at G and > 10G capacities (even in US DoD!). But as soon as you hit the radio- > WAN > in the middle, you suffer ~4 order of magnitude capacity hit -- best > numbers are in 10s of M. Multicast is the only offset to that > capacity > hit. > > PTT radios are just one instantiation of this observation. > > > On Thu, 2006-07-27 at 23:27 -0400, ken carlberg wrote: >>> What the charter should, perhaps, address, is the status of >>> multicast in this. We all agree we need unicast solutions. RSVP >>> assumes that multicast is also a requirement, while NSIS presumes >>> that it can be summarily set aside. In civilian networks where >>> multicast is not widely deployed as a service, the point may be >>> moot. I am told that in your organization and others in coalition >>> with it, there are places where multicast is the predominant >>> traffic type, however. So we have to decide whether we need to >>> address that. >> >> I'll chime up and say we *definitely* need to address multicast. its >> fundamental in the context of efficiently supporting push-to-talk >> applications as one pushes IP further into the infrastructure of Land >> Mobile Radio. and the subject becomes more of a headache since the >> establishment of talk groups are not based on explicitly signaled CAC >> >> -ken >> >> >> _______________________________________________ >> Ieprep mailing list >> Ieprep@ietf.org >> https://www1.ietf.org/mailman/listinfo/ieprep > -- > b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Howard C. Berkowitz
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Nguyen, An P CIV NCS NC2
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Howard C. Berkowitz
- Re: [Ieprep] on the ieprep charter Fred Baker
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Rex Buddenberg
- Re: [Ieprep] on the ieprep charter ken carlberg
- [Ieprep] Question about the IEPREP Recharting Pro… Hannes Tschofenig
- Re: [Ieprep] on the ieprep charter Rex Buddenberg
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Janet P Gunn
- Re: [Ieprep] on the ieprep charter ken carlberg
- Re: [Ieprep] Question about the IEPREP Recharting… ken carlberg
- Re: [Ieprep] Question about the IEPREP Recharting… Hannes Tschofenig