Subject: [Ieprep] on the ieprep charter

From: "Robert G. Cole" <[email-masked]>
Date: Wed, 12 Jul 2006 08:56:27 -0400

Kimberly,

I am not sure of the lastest revision to the charter, so will make a few 
general comments on various versions and discussions.  I am also curious 
of the target date for completing the charter revision.

+ I agree with expanding the scope of the WG away from solely an 
emergency Telecomm focus to a more general emergency communications 
focus.  I do not think a totally military focus is correct however; this 
is only one of several sectors the IETF needs to address.  There is 
significant overlap in the needs for emergency services within 
Enterprise, Public and Military networks, that to focus on a single 
sector would represent a disservice to all of these communities.

+ I agree with the suggestion to expand beyond requirements and 
informational to standard track RFCs, if necessary.  There are clearly 
gaps in the current set of standards within the scope of emergency services.

That being said, I have a few specific comments:

+ I would shy away from the term 'Telecommunications' and use 
'Communications' when refering to working group scope.  Using it as an 
example is fine.

+ I generally prefer to use the term 'Precedence' in place of 
'Prioritization' when refering to general capabilities and requirements. 
  Prioritization implies (to some) a (queuing)mechanism, which may not 
be required in many instances.

+ A 'Feb 07 draft on mechanisms' is suggested.  Is this to focus on 
transport service mechanisms and/or application level mechanisms?

+ Perhaps the WG should consider drafting an I-D on Application 
Considerations when accessing emergency transport services.  I know 
there has been some discussion of Email/SMTP in this group.  Should the 
charter make discussion of application considerations in scope?  I think 
yes. I think such a document would point out some interesting 
interactions required between the network and the applications, e.g., 
access control, multiplexing, etc.

Thanks,
Bob

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Jul 2006 12:49:07 -0400

On Jul 12, 2006, at 8:56 AM, Robert G. Cole wrote:
> focus.  I do not think a totally military focus is correct however;  
> this is only one of several sectors the IETF needs to address.   
> There is significant overlap in the needs for emergency services  
> within Enterprise, Public and Military networks, that to focus on a  
> single sector would represent a disservice to all of these  
> communities.

yes.

My observation here is that in the PSTN there is a single common set  
of tools used, the information elements in SS7. The implementation of  
these vary: some networks use preemption (my observation is that most  
networks I have spoken with use preemption), and some use other  
techniques like call queuing, trunk queuing, and alternative call  
routing. That argues that it is not necessary and is perhaps  
inappropriate to attempt to mandate that a difference in underlying  
implementation forces a difference in protocol.

I would go a step further. At the end of the day, carriers and  
vendors are being asked to implement one thing or another, with  
enough options to cover the needs of their various countries. In the  
PSTN, this was done in an international body, the SS7 protocols are  
used world-wide, and basically those two options are used in common  
implementation throughout the world. This vendor sells not only to US  
DoD and US DHS/NCS and their contractors. Cisco sells to many service  
providers that offer service in multiple countries; one of such told  
me that their services were offered in 70 countries. Cisco also sells  
to NATO, which in the final analysis means that it provides tools to  
military networks i roughly 90 countries. Asking for this DHS/NSC vs  
DoD division is a microcosm of the reality that this working group  
needs to address.

In my humble opinion, which is of course always right (but I am too  
humble to say so), what we really need is a single common solution  
that can be interoperably deployed in preemption-ok and preemption- 
not-ok networks in a wide variety of countries, with configuration  
options to deal with the differences in implementation approach. If  
that is in the end not the objective, then I believe the working  
group should not be chartered. This ultimately hurts everyone, and is  
not my desire, but is the only thing that would make sense in the  
context.

---

From: "Robert G. Cole" <[email-masked]>
Date: Thu, 27 Jul 2006 14:40:30 -0400

Fred,

So do you think the following statement is roughly true?

"There is enough similarities in the needs of these broad industry 
segements with respect to communications requirements/needs in emergency 
situations that:

a) Protocols can be enhanced (or in some cases developed) to handle the 
similarities, while

b) Differences are relegated to implementations or behavior descriptions."

Thanks,

Bob

Fred Baker wrote:
> 
> My observation here is that in the PSTN there is a single common set  of 
> tools used, the information elements in SS7. The implementation of

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 Jul 2006 12:19:49 -0700

On Jul 27, 2006, at 11:40 AM, Robert G. Cole wrote:
> segements with respect to communications requirements/needs in  
> emergency situations that:
>
> a) Protocols can be enhanced (or in some cases developed) to handle  
> the similarities, while
>

Yes, that is my opinion. Just an opinion, mind you. But I should  
think that a common UNI and NNI signaling mechanism could be  
described that enabled every implementation (regardless of nation or  
type of network) to classify requests in an appropriate manner  
(routine or whatever other level might apply, and whether the  
customer was authorized to make the request) and then implement what  
needs to be done. In some networks, for some services such as VoIP  
and Video/IP, that will include preemption; in other networks, the  
same services will include trunk queuing or other approaches. For  
other services, such as preferring some elastic traffic over others  
and the transitive trust issues in delivering an email within a short  
stated interval, other considerations may also come into play.

Note that I carefully separated that into three broad categories:  
UNI, NNI, and everything else. "everything else" is within a network,  
and I think that is the network's problem although I may have some  
suggestions. NNI may be able to be handled by SLAs, although one  
could argue that the entire discussion here is regarding edge  
conditions in SLAs. It is the UNI that concerns me the most, as it  
tends to be the place where the biggest problems occur, and where  
problems occur at NNIs they can be treated as a variety of aggregated  
UNI. It is the NNI and the UNI that are most in view in RFC 4542.

One thing to consider is that the intra-network case and the NNI case  
are somewhat specialized( we are simply looking at IP traffic,  
usually in an aggregated form), while the UNI crosses a variety of  
types of products including SMTP servers, telephones and telephone  
middleware, etc ad nauseum. I think the UNI is the most interesting  
and important case.

---

From: "Robert G. Cole" <[email-masked]>
Date: Thu, 27 Jul 2006 15:37:51 -0400

Is this something that is or should be captured within the text of the 
IEPREP charter, i.e., objectives for paritioning work into protocols at 
UNIs and NNIs and behaviors (where appropriate) within network interiors?

Bob

Fred Baker wrote:
> Yes, that is my opinion. Just an opinion, mind you. But I should  think 
> that a common UNI and NNI signaling mechanism could be  described that 
> enabled every implementation (regardless of nation or  type of network) 
> to classify requests in an appropriate manner  (routine or whatever 
> other level might apply, and whether the  customer was authorized to 
> make the request) and then implement what  needs to be done. In some 
> networks, for some services such as VoIP  and Video/IP, that will 
> include preemption; in other networks, the  same services will include 
> trunk queuing or other approaches. For  other services, such as 
> preferring some elastic traffic over others  and the transitive trust 
> issues in delivering an email within a short  stated interval, other 
> considerations may also come into play.
> 
> Note that I carefully separated that into three broad categories:  UNI, 
> NNI, and everything else. "everything else" is within a network,  and I 
> think that is the network's problem although I may have some  
> suggestions. NNI may be able to be handled by SLAs, although one  could 
> argue that the entire discussion here is regarding edge  conditions in 
> SLAs. It is the UNI that concerns me the most, as it  tends to be the 
> place where the biggest problems occur, and where  problems occur at 
> NNIs they can be treated as a variety of aggregated  UNI. It is the NNI 
> and the UNI that are most in view in RFC 4542.
> 
> are somewhat specialized( we are simply looking at IP traffic,  usually 
> in an aggregated form), while the UNI crosses a variety of  types of 
> products including SMTP servers, telephones and telephone  middleware, 
> etc ad nauseum. I think the UNI is the most interesting  and important 
> case.

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 27 Jul 2006 14:54:46 -0500

> UNI. It is the NNI and the UNI that are most in view in RFC 4542.

As a newbie to the list, but not necessarily emergency operations, there may be
additional cases. In a large disaster, it may well be that telecommunications
operating facilities may be the only available buildings with adequate backup
power, HVAC, and physical ruggedness to stay in service. I've encountered some
very ad hoc situation where emergency responders, PSAPs, etc., temporarily
operated out of telco COs and the like. 

It's not inconceivable, in such a circumstance, that such people may bring
equipment meant for UNI, in a facility with mostly NNI and other interfaces. I'd
encourage thinking about that sort of ad hoc operational requirement.

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Thu, 27 Jul 2006 16:26:20 -0400

Classification:  UNCLASSIFIED 
Caveats: NONE

Howard,

Please see below.
>
>-----Original Message-----
>From: Howard C. Berkowitz [mailto:[email-masked]] 
>Sent: Thursday, July 27, 2006 3:55 PM
>To: [email-masked]
>Subject: Re: [Ieprep] on the ieprep charter
>

>As a newbie to the list, but not necessarily emergency operations,
there >may be
>power, HVAC, and physical ruggedness to stay in service. I've
encountered >some
>encourage thinking about that sort of ad hoc operational requirement. 

For ad hoc communications, do you think the IEEE 802.16x (a.k.a. WiMAX)
and maybe with IEEE 802.11x (WiFi) would satisfy your requirements? If
the answer is yes, then does the UNI include the WiMAX interface?

Best,

An
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
Classification:  UNCLASSIFIED 
Caveats: NONE

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 27 Jul 2006 15:48:11 -0500

> the answer is yes, then does the UNI include the WiMAX interface?
That's a good question. My immediate thought is that potentially either would
work, probably more likely 802.11 if someone is moving temporary equipment into
carrier facilities. If the equipment speaks VoIP, and can use it as needed to
interface to tactical voice and data radio, an 802.3 interface puts us in
reasonable shape. That should cover many requirements.

My concern, and I agree some of this is hypothetical, is that some EOCs expect
PDH or ATM links to their switch. We'd need some survey data to find out how
frequently this would arise, and whether transportable gateways need to be
available.

There's a reverse side of this to consider, although it won't have as many
interfacing issues since the equipment is more self-contained. Consider the
situation where the telco offices are flooded, but a local hospital is on high
ground, has adequate generators, etc. It's a plausible place for helicopter
delivery of emergency radio repeaters, cellular base stations, etc.

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 Jul 2006 14:05:46 -0700

I think it is possible to over-constrain the working group outputs,  
and so would not go into that level of detail in the charter. For  
example, we might decide in the course of working the issue that the  
division isn't worthwhile, and then find that we have to change the  
charter to ignore it.

The important thing to me is that the charter should describe us  
providing a signaling solution that is
  - applicable to a variety of implementations, including preemptive  
and non-preemptive,
  - appropriate throughout the Internet, not just in the subset that  
happens to be relevant
    to the US Government, whether civil or military, and
  - addresses both inter-provider and provider/customer connectivity.

I think it should also very clearly require both application layer  
CAC (eg, "who are you" and "what are you authorized to do" for some  
appropriate set of definitions) and network layer CAC (eg, at this  
instant, does the network have resources to address your  
requirements, and if not what is it going to do about that). Since  
the two questions are very different, there should be no assumption  
that only one needs to be solved or that one solution solves both.

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.

On Jul 27, 2006, at 12:37 PM, Robert G. Cole wrote:
> Is this something that is or should be captured within the text of  
> the IEPREP charter, i.e., objectives for paritioning work into  
> protocols at UNIs and NNIs and behaviors (where appropriate) within  
> network interiors?
>
> Bob
>
> Fred Baker wrote:
>>> "There is enough similarities in the needs of these broad  
>>> industry  segements with respect to communications requirements/ 
>>> needs in  emergency situations that:
>>>
>>> a) Protocols can be enhanced (or in some cases developed) to  
>>> handle  the similarities, while
>>>
>> described that enabled every implementation (regardless of nation  
>> or  type of network) to classify requests in an appropriate  
>> manner  (routine or whatever other level might apply, and whether  
>> the  customer was authorized to make the request) and then  
>> implement what  needs to be done. In some networks, for some  
>> services such as VoIP  and Video/IP, that will include preemption;  
>> in other networks, the  same services will include trunk queuing  
>> or other approaches. For  other services, such as preferring some  
>> elastic traffic over others  and the transitive trust issues in  
>> delivering an email within a short  stated interval, other  
>> UNI, NNI, and everything else. "everything else" is within a  
>> network,  and I think that is the network's problem although I may  
>> have some  suggestions. NNI may be able to be handled by SLAs,  
>> although one  could argue that the entire discussion here is  
>> regarding edge  conditions in SLAs. It is the UNI that concerns me  
>> the most, as it  tends to be the place where the biggest problems  
>> occur, and where  problems occur at NNIs they can be treated as a  
>> variety of aggregated  UNI. It is the NNI and the UNI that are  
>> most in view in RFC 4542.
>>
>> One thing to consider is that the intra-network case and the NNI  
>> case  are somewhat specialized( we are simply looking at IP  
>> traffic,  usually in an aggregated form), while the UNI crosses a  
>> variety of  types of products including SMTP servers, telephones  
>> and telephone  middleware, etc ad nauseum. I think the UNI is the  
>> most interesting  and important case.

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 27 Jul 2006 14:27:27 -0700

> Quoting "Nguyen, An P CIV NCS NC2" <[email-masked]>:
[deletia]
> reasonable shape. That should cover many requirements.

Howard,  WiMAX payloads are wrapped in ethernet frames just like WiFi,
DOCSIS, ... and ethernet itself.  In 802 SAP terms, all use the 802.2
LLC.   (And so will 802.20 and 802.22 if they ever see light of day,
which is looking more and more problematic).  

The 802.16 gear we have in lab -- 2-3 generations worth now -- all has
ethernet interfaces to the next network over.  Both BS and SS.  So my
students simply see an RJ-45 plug ... and it works the same way their
cable modem at home works.  Bridging is so ubiquitous that nobody
notices it anymore. 

> PDH or ATM links to their switch. 

The 802.16 literature says 'does ATM' but I'm not entirely sure what
that means.  And because the military infrastructure has so little of
it ... and definitely NOT on the battlefield, I've never worried
farther.  

>  Consider the

This is the situation we found when a colleague of mine looted my lab,
grabbed a bunch of students and headed to New Orleans last fall.  Ended
up setting up in Waveland, Ms where there was essentially no
infrastructure left -- no wired phone, no cellphone, and no electricity.
The laydown consisted of:
	- an 802.16 backbone
	- an 802.11 access network at each .16 node (lit up schools, fire and
police stations, a hospital and a couple other sites).  J-random laptops
could connect up.
	- concentrate the .16 stuff to a router that has a satcom link to
undamaged internet (DoD-speak is 'reachback').  
	The kit the guys took had generators and assorted camping gear.

---

From: ken carlberg <[email-masked]>
Date: Thu, 27 Jul 2006 23:27:06 -0400

> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 28 Jul 2006 09:33:01 +0200

Hi all,

I haven't follwed the IEPREP working group too closely in the past. This 
week I read through all the documents and I also went through the 
rechartering proposal.

As an "outsider" I was not quite sure what exactly you would like todo? 
(i.e., what should the new documents cover that is not addressed in 
previous docs).
Do you have some documents that could tell me what you guys plan todo?
How do these documents relate to the new charter items?

Sorry, if I appear a little bit lost...

Ciao
Hannes

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 28 Jul 2006 09:16:39 -0700

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.

-- 
b

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Jul 2006 11:42:53 -0700

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.

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 28 Jul 2006 15:07:23 -0400

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
(Sorry all- I've been told I am not allowed to delete this)

Fred,

My understanding is that, on the civilian side, "Push to Talk" is quite
widely used by "first responders", and by the groups responsible for
repairing/maintaining "the infrastructure" (e.g., telephone networks, power
grids, water and sewage systems, highways, oil pipelines) .  These are
considered part of the "National Security/Emergency Preparedness"
functionality.  At least one of the deployed services  uses 5 levels of
priority.

Janet

---

From: ken carlberg <[email-masked]>
Date: Fri, 28 Jul 2006 15:52:40 -0400

Fred,

> 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.

a good read on things, though the headache arises in the details.   
Today, provisioning in LMR systems used by first responders (police,  
firemen, EMS, etc.) is accomplished by man-in-the-loop dispatchers  
that assign channels per talkgroup (analogous to per multicast  
group).  and what is known as "radio discipline" (by end users) is  
primarily used to control contention on the channel.  failing that,  
the dispatcher manages the group and can assign more talkgroups/ 
channels, though these are limited.

and as Janet mentioned, prioritization in LMR (layer 2) packets has  
recently been added tot he mix.  Project 16a of APCO defined a set of  
5 priorities, and Project 25 defines 7 levels.  one moral in that  
story is not to be fixated on the number of levels....they may change.

my understanding is that the number of towers involved in a talkgroup  
generally range from 0 (direct communication between end users) to 4,  
with a gausian decay after that.  today, these towers don't have IP  
embedded within them, but that will come in time.  outside of this,  
there are also remote observer participants that receive the  
communications from remote geographic regions.

-ken

---

From: ken carlberg <[email-masked]>
Date: Fri, 28 Jul 2006 15:59:50 -0400

Hannes,

in a nutshell, the intent of the re-charter was to go beyond  
requirements and in some form consider solutions that do not fall  
within the charter of other working groups.

I believe that there are some other interested parties that have been  
working on drafts that go beyond previous work done by the group, but  
that they are awaiting the results of the proposed rechartering  
discussions.  However, others should probably speak up on that matter.

-ken

On Jul 28, 2006, at 3:33 AM, Hannes Tschofenig wrote:

> Hi all,
>
> I haven't follwed the IEPREP working group too closely in the past.  
> This week I read through all the documents and I also went through  
> the rechartering proposal.
>
> As an "outsider" I was not quite sure what exactly you would like  
> todo? (i.e., what should the new documents cover that is not  
> addressed in previous docs).

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Jul 2006 21:40:45 +0200

Rechartering is a lot simpler if first document versions are available 
and the group can look at them in order to decide whether it makes sense 
to extend the charter in a particular way.

Ciao
Hannes