Skip to main content

Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
RFC 4542

Revision differences

Document history

Date Rev. By Action
2018-12-20
04 (System)
Received changes through RFC Editor sync (changed abstract to 'RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet …
Received changes through RFC Editor sync (changed abstract to 'RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.

This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.')
2015-10-14
04 (System) Notify list changed from mankin@psg.com, jmpolk@cisco.com, jon.peterson@neustar.biz, jon@unreason.com to jon@unreason.com, jon.peterson@neustar.biz, mankin@psg.com
2012-08-22
04 (System) post-migration administrative database adjustment to the Yes position for Allison Mankin
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for David Kessens
2006-05-17
04 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-05-17
04 Amy Vezza [Note]: 'RFC 4542' added by Amy Vezza
2006-05-16
04 (System) RFC published
2006-03-13
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-03-03
04 Amy Vezza IESG state changed to Approved-announcement sent
2006-03-03
04 Amy Vezza IESG has approved the document
2006-03-03
04 Amy Vezza Closed "Approve" ballot
2006-03-02
04 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Yes from Discuss by Allison Mankin
2006-03-02
04 Allison Mankin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin
2006-03-02
04 Allison Mankin Note field has been cleared by Allison Mankin
2006-03-02
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-03-02
04 (System) New version available: draft-ietf-tsvwg-mlpp-that-works-04.txt
2006-03-01
04 Allison Mankin
03->04:
ATO/US gov - add specificity: MLPP and GETs protocols are focus here, but the
protocols and architectures can be used by others

Section on …
03->04:
ATO/US gov - add specificity: MLPP and GETs protocols are focus here, but the
protocols and architectures can be used by others

Section on qos choices no longer says that bandwidth is free even in
overprovisioning choices.
2006-03-01
04 Allison Mankin State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Allison Mankin
2006-03-01
04 Allison Mankin [Note]: 'waiting for 04 to post...' added by Allison Mankin
2006-02-10
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-02-10
03 (System) New version available: draft-ietf-tsvwg-mlpp-that-works-03.txt
2006-01-13
04 Allison Mankin Spoke to James yesterday and talked through all the revision requirements -
he had been away, then Fred had been
2006-01-12
04 Allison Mankin State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Allison Mankin
2006-01-06
04 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-01-06
04 (System) Removed from agenda for telechat - 2006-01-05
2006-01-05
04 Allison Mankin
[Ballot discuss]
Need to handle Alex, Russ, Bert comments, and
make the text change from the Discuss that David
cleared - need to clear these …
[Ballot discuss]
Need to handle Alex, Russ, Bert comments, and
make the text change from the Discuss that David
cleared - need to clear these with the WG.  I
took the Discuss for all these.
2006-01-05
04 Alex Zinin
[Ballot comment]
The documents starts as a general technology discussion, and then gives
so much NATO/US gov/DoD context that it makes me uneasy. It would …
[Ballot comment]
The documents starts as a general technology discussion, and then gives
so much NATO/US gov/DoD context that it makes me uneasy. It would be good
if the document either explicitly set the expectations that this is documentation
of a specific architecture used by NATO/US gov/DoD by changing the title and
the abstract, or the main body of the doc could be made more technology-centric
and those details moved to an appendix.
2006-01-05
04 Allison Mankin [Ballot discuss]
Alex requires mention of MLPP/GETS in the Intro and Abstract
and I'm going to handle Russ's comments - removal of HAIPE
2006-01-05
04 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2006-01-05
04 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Discuss from Yes by Allison Mankin
2006-01-05
04 David Kessens [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens
2006-01-05
04 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2006-01-05
04 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2006-01-05
04 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2006-01-05
04 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2006-01-05
04 Bert Wijnen
[Ballot comment]
In fugures 8, 9, 10, 11 it is using IPv4 addresses in examples
that do not comply with the recommended 192.0.2.0/24 as
documented …
[Ballot comment]
In fugures 8, 9, 10, 11 it is using IPv4 addresses in examples
that do not comply with the recommended 192.0.2.0/24 as
documented in RFC3330.
2006-01-05
04 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2006-01-04
04 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2006-01-04
04 David Kessens
[Ballot discuss]
In section '1.6.  The use of bandwidth as a solution for QoS':

In places where the bandwidth can be over-provisioned to a point …
[Ballot discuss]
In section '1.6.  The use of bandwidth as a solution for QoS':

In places where the bandwidth can be over-provisioned to a point
where loss or queuing delay are negligible, 10:1 over-provisioning is
often the cheapest and surest solution, and by the way offers a
growth path for future requirements. However, there are places in
communication networks where bandwidth is not free and is therefore
not effectively infinite. It is in these places, and only these
places, where the question of resource management is relevant.

I believe the wording here is misleading: bandwidth is never free.
Adding a switch costs money in terms of capital applied but also the
operational cost for installing the next best switch.

Despite this, in general, overprovisioning is indeed the right and
only answer to a capacity problem.

The only case where this doesn't work is not the case where bandwidth
is infinite but the case where it simply is physically impossible or
where the cost of adding bandwidth is that prohibitive that it can be
considered equal to impossible.

However, even if in such cases, it is still not necessarily a
justification for QoS. In many situations, this is just a clear sign
that one has to abandon the technology and do something radically
different.

Basically, I think the the whole paragraph should go as it is way to
supportive of the idea that QoS can solve your problems.

What about replacing it with something very short and simple:

In general, the use of overprovisioning is the most effective solution
to solve QoS issues. However, this is not always possible due to cost
or physical limitations.

This document deals with the cases where the use of bandwidth is not a
practical solution.
2006-01-04
04 David Kessens [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens
2006-01-04
04 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-01-04
04 Michelle Cotton IANA Comments:
We understand this document to have NO IANA Actions.
2006-01-04
04 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2006-01-03
04 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2006-01-03
04 Ted Hardie
[Ballot comment]
Section 1.1 begins:

    Before doing so, however, let us discuss the problem that ETS (and
  therefore IEPS) is intended to …
[Ballot comment]
Section 1.1 begins:

    Before doing so, however, let us discuss the problem that ETS (and
  therefore IEPS) is intended to solve and the architecture of the
  system. 

It's not clear what "before doing so" refers to.

Reading through it, seems like one of the main issues would be the topological placement of the server managing call placement and pre-emption, especially in relation to the resource-constrained links.  It may be elided here because it is obvious or covered elsewhere, but some reference to the problem would help.
2006-01-03
04 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2006-01-01
04 Russ Housley
[Ballot comment]
The last part of the 2nd paragraph in the Abstract seems misplaced.  It
  also appear on the Introduction, where it is very …
[Ballot comment]
The last part of the 2nd paragraph in the Abstract seems misplaced.  It
  also appear on the Introduction, where it is very appropriate.  A more
  succinct Abstract is desirable.

  Section 1.1.1: s/end to end capacity/end-to-end capacity/

  Section 1.6: s/Type 1 encryption/military-grade encryption/

  Section 2.1: s/Figure X/Figure 2/

  Section 2.3.1: s/shown in Figure 2/shown in Figure 3/

  Section 2.3.3: s/IPSEC/IPsec/

  Section 2.3.3: What is the point of including HAIPE?  It does not add
  any value beyond the IPsec tunnel discussion.  Further, no description
  of HAIPE is provided.
2006-01-01
04 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-12-26
04 Allison Mankin State Changes to IESG Evaluation from AD is watching by Allison Mankin
2005-12-26
04 Allison Mankin Placed on agenda for telechat - 2006-01-05 by Allison Mankin
2005-12-26
04 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin
2005-12-26
04 Allison Mankin Ballot has been issued by Allison Mankin
2005-12-26
04 Allison Mankin Created "Approve" ballot
2005-12-26
04 (System) Ballot writeup text was added
2005-12-26
04 (System) Last call text was added
2005-12-26
04 (System) Ballot approval text was added
2005-12-26
04 Allison Mankin
Needs minor changes to address Ken Karlberg's comments, and
I would like it to mention that NSIS protocols could be used
in future - that …
Needs minor changes to address Ken Karlberg's comments, and
I would like it to mention that NSIS protocols could be used
in future - that this describes what is done with presently
standardized protocols.  We'll fix these with Note to the
RFC Editor.
2005-11-15
04 Allison Mankin WGLC
2005-11-15
04 Allison Mankin Draft Added by Allison Mankin in state AD is watching
2005-08-23
02 (System) New version available: draft-ietf-tsvwg-mlpp-that-works-02.txt
2005-07-19
01 (System) New version available: draft-ietf-tsvwg-mlpp-that-works-01.txt
2005-02-08
00 (System) New version available: draft-ietf-tsvwg-mlpp-that-works-00.txt