Last Modified: 2004-06-15
Three examples of emergency communications include:
1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN.
2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health.
3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging.
Initial documents will describe the problem space and its salient characteristics. In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. The working group may also develop a Framework for Supporting Internet Emergency Preparedness in IP Telephony RFC if it is determined that IP telephony requires special treatment above what would be in the requirements document.
The international community needs advice as to what standards to rely on, in the form of a BCP. This BCP needs to identify mechanisms to provide deterministic behavior of applications, mechanisms for authentication and authorization, and recommendations for application design with existing protocols. In the IETF considerations for treatment and security of emergency communications stretch across a number of Areas and Working Groups, notably including the various telephony signaling working groups, Differentiated Services, Protocol for carrying Authentication for Network Access (pana), and various operational groups, so the IEPREP working group will have to cooperate closely with these groups and with groups outside of the IETF such as various ITU-T study groups.
The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. The working group will not focus on particular national regulations.
Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done.
Informational: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony.
|Done||Submit initial I-D of Requirements|
|Done||Submit initial I-D of Framework|
|Done||Submit initial I-D of Recommendations BCP|
|Done||Submit Requirements I-D to IESG for publication as an Informational RFC.|
|Done||Submit Framework I-D to IESG for publication as an Informational RFC.|
|Dec 03||Submit Recommendations I-D to IESG for publication as a BCP.|
|RFC3487||I||Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)|
|RFC3523||I||Internet Emergency Preparedness (IEPREP)Telephony Topology Terminology|
|RFC3690||I||IP Telephony Requirements for Emergency Telecommunication Service|
|RFC3689||I||General Requirements for Emergency Telecommunication Service|
Internet Emergency Preparedness WG (ieprep)
Wednesday, August 4 at 1530-1730 PDT
CHAIRS: Scott Bradner <firstname.lastname@example.org>
Kimberly King <email@example.com>
MINUTES: These minutes were created by Scott combining notes taken by Andrew Thiessen with the session jabber log (the jabber scribe was Lisa ).
I: Agenda Bashing: Chair
No agenda changes requested
Scott Bradner: introduces agenda
II: Ken Carlberg's presentation:
AD comments on status of documents
reviewed by IESG & were some comments
Ken has them now (as of 5 minutes ago)
single domain drafts
things have just been cleaned up
nothing on the list when the old version came out
wants to wrap it up
Scott Bradner: any comments? (none)
will do a chair review and then a last call
II: Fred Baker's presentation:
Fred B - background of this talk is a combination of many meetings.
On March 24th visited NCS they asked a lot of questions, working with the Air Force.
On April 2nd had a meeting with Pete Fonash (sp?) - context of the meeting: interested in voice and video over IP, instant messaging and prioritized mail in a military context. Need maximum delay of 7 minutes guaranteed in both the civilian and military Internet.
Col. Tim Gibson has been giving money for research. He wants to launch a missile and download the missile data over a satellite link and using TCP in a predictable fashion before launch.
note well: talking about elastic services not real-time services
Wouldn't it be nice if we could simply use diffserv? A little more to it than that. How do we keep script kiddies off of the network?
two approaches slides
proposals on the table with SPAWAR
16 apps going into 12 queues using drop preference
also talking with military in other than US countries
drop precedence effects (slides)
gives example of admiral controlling a fleet
wants on demand bandwidth
drop precedence doesn't really accomplish what the admiral wants, and its not predictable
effects of a class definition slides
has the ability to make a guarantee to a lower bound
allows to discriminate between various classes
building preferential classes
military models are looking at between 5-7 classes total
big problem: how do we keep the script kiddies from using
identification, authentication, and authorization must authenticate the user after he requests the service
are we talking about two networks here, or one Internet network where we have a GETS policy available to everyone
in a military network you can treat it as one network
authenticate the user slide many ways to do it, someone must make a decision need appropriately strong credentials to make it work properly (crypto)
which protocol do you intend to use between the user and the network
we can discuss that
asked Fred to talk about the philosophy and the concepts not a particular implementation
the selection of the choice of protocol between the end user and the network will be the most difficult
are you starting with link layer?
going to have to go end to end
access a database that is somewhere else
needs to be able to scale
needs to be able to identify people or people in a class
appropriate authentication, not individual
wouldn't the AAA precedence need to be given to other protocols
not necessarily, it could become a DOS attack
authorize the usage slide:
talking about having some kind of limited access, that you cant get in unless you are authorized
do you have to have location information?
those are questions that are specific to the authorization service
geopriv working group is working the location issue
since the public network doesn't care about the DSCP code point does the service extend from the secure or whatever network, all the way to the end users hotspot?
it will have to be done contractually
some networks may not allow you to come in with a specific DSCP codepoint
they still have to authenticate first before getting access to the network
- once an IP address is authenticated, not every service being run from that IP needs the precedence missles and porn example
note that diffserv design is that the code point can be overwritten
the grey network is what's been contracted with the white network is Starbucks - if it goes through borders in Starbucks, the DSCP codepoint could be stripped off
Voice at the back:
Preferentially, we want to have all gray, but we can't have it we must have a patchwork grey
Best case, but unlikely case.
let him/her request the service slide:
If we let the user request the service, we could RSVP for a TCP session on a given port, with DSCP -- but we don't necessarily know the port - There be dragons here. "Traditionally", what a bandwidth broker does is different on every broker.
Chris Christian (??):
is the bandwidth broker doing admission control and assigning resources, or just authentication
In fact, if you know the sum total of the requests would exceed the capacity, something will have to be decided
reiterate must scale - anything that is IP, that is elastic, will get bandwidth in the network
file transfer is particularly part of this slide: to have predictable TCP behavior, need something new - gives example from Amsterdam to Alaska
Interesting work done recently by a guy named Case - Case has a computer on a network, 622 megabit network, he's the only one on it. He thinks he should be able to actually get 622 megabit, but he doesn't, he only gets 70 megabits. Case is happier, but not happy, after Cisco upgrade, when he gets 400 megabits. Problem is TCP. TCP has an averaging behavior, and ran into problems
Australian defense slide:
ship to shore radio, high BER - uses iterative process of sending datagrams and acking each datagram. Unless the error rate approaches 1, we're eventually going to get the file across. Throughput rate = effective-window / round-trip-time. RFC2581 and a CalTech FAST TCP project have different measurements Is there a way I could measure capacity and choose an appropriate window to maximize throughput rate? Srinivasan was figuring out how to send two packets across a link to have a micro-measurement of the rate of the link. That's one data point. Can we generate a filtered mean rate? That allows us to send at a more optimal rate to get high throughput. Next-generation SACK procedures can increase the effective window. I can keep transmitting at the calculated rate and pick up the retransmissions later. Now I can deliver a whole file at a predictable time. Electronic mail could be a privileged service, attempting to deliver each email in a finite known time. But how can this work, when I asserted an identity only known to the first domain in the email delivery? Today, when I connect to my email server and start downloading mail, I have to download them all before seeing one of them is super important. We're going to have to apply priorities every step of the way: from me to my SMTP server, from that SMTP serer to the ISP, and so on to the end machine. Another thing we need is quick failure. If something's going to take an hour rather than 7 minutes, don't just leave it in the queue, let me know.
How do we prevent the spammers from putting priority on their messages?
don't authorize them
what if they authorize themselves?
I don't know that answer, it's going to have to be addressed.
is the military saying that they want an end to end solution? satcom has some interesting capabilities if its not encrypted
US Navy is in fact looking for E2E solutions including undersea cable hops. They drew a picture of a ship on the way to Bahrain from Norfolk - The message had to go undersea cable to Italy, in air to ship, with a hop to Bahrain in there. But to authenticate it, it had to go to Norfolk. It ended up with a 2 sec roundtrip delay.
I'm stuck on the differences between the military solution, where there's a hierarchy of overrides, with the civilian emergency case. Compare the CEO and the cleaner, trying to use the emergency services, where the cleaner is actually the important person communicating with emergency services.
right, We can't just take all the routine traffic and put it in the dumpster. At the beginning, I was saying that we do not want to assign priorities. Priority, as a scheduling algorithm, is a way to reduce jitter. So yes, you actually want to reserve traffic for *each* traffic class, not bump the lowest priorities right off. You could use round-robin to allocate for each for the classes. If some class isn't using its bandwidth, it's proportionally allocated to the other classes. So normally that means that routine traffic gets 100% of bandwidth.
1) want the slides
2) likelihood that you will have small stream with big files over big delay links are a corner case - not sure that there is a problem that needs to be solved here
3) when you started talking about the bandwidth broker, flag set off.
because none work
you are taking something that doesn't work, and making it more complicated
This isn't the Internet2 bandwidth broker; it's not mosaic.
In the last slide, you had two items, priority and smptauth Three years ago a fellow submitted a draft on prioritized SMTP. It's expired but maybe good background reading, including the list discussion at that time.
Do you expect somebody from the agency to authenticate themselves to their NAS server, then use that to access a server in some enterprise?
You'd have to talk to the government, but I wouldn't have them going to a single-point-of-failure server to do that. I'd want an instance of that server in each of UUNet's datacenters, for example. In the military probably one auth throughout. When you talk to GETS (?) it's different
This is a response to Steve: to the extent this corresponds to what's done in WPS and GETS, this needs to be available to everybody, and you don't know who's going to be important ahead of time. That's different from the emergency preparedness where we know who needs the special service.
what class will be used for an elastic service?
elastic traffic will need a class
IV - Scott Bradner:
where do we go from here is next on the agenda? We have one more item on our charter, a recommendations I-D, recommending to service providers, ISPs, how to do something using available technology. We were hoping to use the ID Fred did before to meet that milestone since he covered the gamut of things assumed to be required in emergency cases. I think some of these things are potentially important, some we can do something with, but not all of them. How we can constrain the problem if ieprep to something we can deal with. Some of the work has limited applicability to a single domain with unified authentication
The individual pieces have a lot in common with a lot of other stuff going on maybe a needs statement should be sent out
The first thing this group did was develop requirements for SIP resource priority headers, then shifted that work to SIP WG to actually do the work. We give the requirements, not how to do it. I would propose to interact with the IESG to extend the charter to work on the things Baker describes here - but as requirements, not as solutions.
The requirements need to be very clear that this is not ETS we're talking about here. To me, ETS as been defined in ITU and so forth is the 999, 911 services.
just to clarify ETS is not 911
lets just make that clear in the charter
there is a design team in SIP addressing 911
two big issues with E911 in VoIP - where are you and where is the PSAP?
Some high level architecture would be useful for the industry.
Important work, just not in the charter of this WG.
I found that many people making design decisions are not people you'd typically find at an IETF meeting though many are in this room. I chaired TCP over Satellite WG,.. people don't necessarily know the right combination of RFCs to use to put the network It may be useful not only to make requirements to other WGs, but also to explain what services providers should use to put together ETS services. ETS == Emergency Telecommunication
RFC 3889 provides some examples.
This working group is about non-911 emergency communications. But if you're saying that clue exists outside the IETF, I definitely want to encourage input, etc.
Is this more for the Internet or for military or private networks has this WG been mainly involved with the public internet not private?
the IETF has had a schism for a long time about whether something that is specific to a private internet is out of scope for the IETF but this WG is to look at the public internet, but those technologies are not turned off on private networks.
Does anybody think it's a bad idea to pursue charter change with the IESG and IAB?
Any other issues?
I work with a government sponsored program named SafeCom, we work with fire, police and EMS. (www.safecomprogram.gov) When you look at first-responder infrastructure, it's owned by the states and locals themselves. This work is certainly of interest to SafeConn and first responders. We want to liaise with IETF to see how we can best use the good work done here. I've done this before, an "easy reading guide" for this.
It would be great if you could do this as a I-D
question about name spaces with the SIP RP header - who handles it?
Once we handed the priority headers to SIPPING, that's their bailywick. It's not our responsibility any more. You can join that list and discuss the topic there.