Network Working Group F. Baker
Internet-Draft Cisco Systems
Expires: August 15, 2002 February 15, 2002
IEPS Requirement Statement
draft-baker-ieprep-requirements-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The requirements for an Internet Emergency Preference Scheme
comparable to the US Government Emergency Telecommunications Service
are explored.
Baker Expires May 15, 2002 [Page 1]
Internet-Draft Document November 2001
1. Introduction
Some countries have deployed a telecommunications access service to
expedite emergency services and government functionality in times of
crisis. With the increased utility of the Internet, there is
interest in creating a similar service in the Internet. This paper
attempts to capture the technical problems related to that.
1.1 GETS - Government Emergency Telecommunications Service
In the United States, the existing service is GETS, the Government
Emergency Telecommunications Service; some other countries have
equivalent services. In essence, GETS is a program that specifies a
uniform set of services that government agencies may refer to in
contracting emergency use of a telephone system. The key aspects of
this service are that:
o Personnel gain access to GETS by calling a specified telephone
number and presenting a credit-card type of authentication.
o Having authenticated themselves, the call is completed on
preferential basis; if the system must choose between placing a
GETS call and another call to the same destination, it will choose
the GETS call.
o If fundamental telephone services are compromised, services
contracted under GETS are restored first.
The telephone circuits (which is to say, the medium for the content
of a telephone connection) given to GETS users are no different from
other telephone circuits. The key consideration is that, under GETS,
some people have a higher probability of placing a telephone call
when common people cannot or are delayed. GETS calls receive
priority treatment over normal calls through:
o Controls such as trunk queuing, trunk subgrouping, or trunk
reservation.
o Exemption from restrictive network management controls that are
used to reduce network congestion.
o High Probability of Completion Standard (ANSI T1.631-1993)
application to provide:
* National Security and Emergency Preparedness (NS/EP)
identification
* Priority signaling.
Baker Expires May 15, 2002 [Page 2]
Internet-Draft Document November 2001
* Alternate carrier routing
These features enhance the capability of NS/EP calls to be completed
in congested networks. GETS will not preempt public telephone calls,
nor are there levels of precedence within GETS.
1.2 Internet Emergency Preference Scheme (IEPS)
Emergency management agencies in many countries are contemplating an
Internet Emergency Preference Scheme [2] similar to GETS. The IEPS
is envisaged as a program that specifies a uniform set of network
services that government agencies may refer to in contracting
emergency use of the Internet. The key aspects of this service are
that:
o Personnel granted access to the IEPS carry identification in a
secure form, which allows them to authenticate with an Internet
Service Provider.
o Having authenticated themselves, they may enjoy preferred access
to Voice on IP and data services at times when others are being
denied service.
o If fundamental Internet access is compromised, services contracted
under IEPS are restored first.
o Internet routers, switches, and computers deployed by emergency
services personnel have a standard configuration which may be used
with any IEPS network.
Just as the telephone circuits provided under GETS does not differ
from standard telephone circuits, the fundamental Internet access
service provided under IEPS is not necessarily different from other
Internet access service. The key consideration is that, during times
of emergency, the contracted services are available to IEPS-
authenticated personnel if they are available to anyone, and that the
ISP treats provision of those services as of greater immediate
importance than provision of those services to other customers.
Where signaling is required or limitations are imposed to limit
congestion, IEPS access is intended to circumvent those limits.
In the GETS system, a standard configuration is unnecessary, as by
tariff telephones use one of a small set of standard interfaces to
the telephone network. This is by no means true of the Internet,
however, and configuration issues are legendary causes of delay in
deployment of IP services. For this reason, a standard configuration
which may be used with any IEPS-contracted ISP, to which the
equipment is configured before deployment, is contemplated.
Baker Expires May 15, 2002 [Page 3]
Internet-Draft Document November 2001
The services contemplated in the IEPS are in no sense limited, but
potentially include the following applications:
o Voice on IP, using such signaling architectures as H.323 or SIP
[24].
o Video on IP, using the same services.
o Shared real-time whiteboard.
o Instant messaging and presence
o Databases such as the Japanese "I am Alive" [1] service, for
communication with persons not involved in the crisis.
o Database services for managing the crisis, including calendaring,
contact management, order and trouble report management, legal
services, medical services, etc.
o Electronic mail.
o File transfer.
o World Wide Web.
1.3 Issues in the IEPS
These services have obviously different requirements, and may have
different plans for provisioning them. For example, the "I am Alive"
[1] service would appear to be a good candidate for outsourcing
lookup engines to web hosting providers, while crisis management
services may have strong security requirements that call for
positioning in a closely managed data center. Similarly, voice
traffic has specific delay requirements, database access has total-
system-delay requirements, and file transfer tends to call for high
throughput rates.
Preliminary discussion of the IEPS has suffered from mismatched
language and concepts between the Internet Engineering community and
the emergency preparedness community, which is used to the GETS
telephone service.
A key point of confusion has been the issue of "priority". The
telephone system may be viewed as a control plane and a data plane,
with no concept of priority in the data plane, but a potential for
choice in the placement and routing of calls. The control plane in
the Internet is more difficult to discern; it exists, along with a
Baker Expires May 15, 2002 [Page 4]
Internet-Draft Document November 2001
data plane, but apart from telephone-system-emulation has no concept
of a call or of routing of a call. For most Internet applications,
the closest analogs are in middleware such as the Domain Name System,
application proxies that enable firewall traversal, or in servers for
address management.
Another key point has been the deployment of services. In GETS, it
is sufficient for an individual to find a standard telephone and
place a call to the GETS number. The closest analogs in the Internet
may be the use of an Internet Cafe, a commandeered ISP access link
(home or corporate), or the rapid deployment of an office-in-a-box
requiring the deployment of a standard internet service to a new
service location.
A last point of confusion has been the perception that all
requirements to support IEPS are targeted for deployment over the
Internet and ISPs. It is conceivable that recommendations to augment
IP-based protocols will only be deployed in closed networks (e.g., IP
backbone networks connecting signaling gateways at the edges, which
in turn peer only with the PSTN). In this case, the IP network is
private and isolated from the rest of the Internet.
In short, from an end-user perspective, while there are strong
similarities when viewed at a very high level, there are large
operational differences, which require careful thought in specifying.
Baker Expires May 15, 2002 [Page 5]
Internet-Draft Document November 2001
2. Key problem areas to consider
We turn to a quick review of the issues involved in an IEPS service
deployment.
One scenario is the interaction of IP telephony with the existing
PSTN. As mentioned above, some parts of PSTN provide additional
support for emergency-related calls. In the case of systems like
GETS, a code point exists for use by the PSTN, which at a minimum
distinguishes an emergency call from others. The problem that arises
with respect to the IEPS is how to bridge this service to the PSTN.
Another scenario is two variants of a common setting, the deployment
of a crisis-related service center. Before an emergency occurs,
someone decides that an emergency might come into existence, such as
a war, a natural disaster, or other contingency. They determine that
meeting that disaster is going to require a specified set of
electronically connected services. Portions of the projected
services use permanent computing sites, perhaps in a redundant
configuration, running specific applications. Other portions may be
mobile, may require emergency deployment, or may be accessible from
other locations
One example of such a service is deployed by the US Federal Emergency
Management Agency (FEMA). FEMA has central computing equipment
running specific applications in various locations. On demand, it
can deploy what one might think of as an office in a box, consisting
of a small-aperture satellite earth station, a router, and some
number of VoIP telephones and computers, plus lightweight office
infrastructure. Such rapid-deployment offices enable FEMA to quickly
set up offices to serve victims of a disaster.
The most important part of setting up such electronic crisis
management services is, of course, the preparatory planning and
application design that permits the service to be useful on short
notice. However, with respect to the rapidly-deployable offices,
there are a list of additional issues which must be addressed:
security, service quality, and commonality of configuration.
2.1 Security
The first issue is the security of the facilities themselves. Some
issues are non-technical in nature but may have technical solutions:
When a link is commandeered or an ISP is asked to deploy service
under an IEPS contract, how does it know that the request is valid?
Some of the issues are common to any Internet access point: in what
way is a computer or computing facility protected from electronic
warfare, garden variety viruses, denial of service attacks, and so
Baker Expires May 15, 2002 [Page 6]
Internet-Draft Document November 2001
on? How does one know that users of an IEPS service are authorized to
do so?
The Security Architecture for the Internet Protocol [11] addresses a
subset of these issues; other issues will require application layer
security approaches, and some will require legal solutions.
2.1.1 Deployment and authentication of IEPS personnel and sites
The deployment of an IEPS site may be part of a long-term plan, or
may be set up under emergency conditions. To obtain ISP services
pursuant to an IEPS contract, the deploying agency will need to
present credentials of type specified by law and contract. Three
fundamental scenarios exist:
o In the normal case, one would expect that an IEPS site would
either be a permanent site, or (like the FEMA example) will
provide its own bandwidth on a temporary basis. In such cases,
normal contract procedures apply.
o In dealing with a major issue, an office-in-a-box may be converted
over time to a more permanent facility. The administration may
find it appropriate to contract bandwidth from a local ISP to
support the site. In such cases, again, normal contract
procedures apply.
o During the early hours of an emergency, however, IEPS-authorized
officials may find a need to commandeer Internet access, and
identify themselves to the supporting ISP as requiring IEPS-
contracted services. The initial emergency recovery support
requires readily available public telecommunication services to
start organizing and coordinating. There is no time to deploy
special facilities. In such cases, immediately available
capabilities must be use, such as cell phones, PDAs, IP phones,
computer terminals on Internet, etc. The ISP will need to be
advised of the emergency condition, and may need to modify its
configurations appropriately to support the site. In this case,
electronic identification such as a one-time password or
cryptographic identification may be appropriate.
Internet access sites, like telephone equipment installation, are
generally fairly permanent. Unlike telephone calls, however, the use
of an Internet site also has aspects of permanence; even a site
deployed in a park must have supporting infrastructure prepared in
advance, and that infrastructure has long-term contractual aspects.
Security issues in this matter therefore are primarily those related
to the the access to and deployment of any Internet access facility.
Where electronic identification is appropriate, it would likely be of
Baker Expires May 15, 2002 [Page 7]
Internet-Draft Document November 2001
a type commonly used for strong Internet authentication.
2.1.2 Defense of an IEPS site against common attacks
IEPS sites are vulnerable to attacks common to the Internet. Such
attacks include:
o Attacks from within, including:
* disruption,
* unauthorized disclosure of, access to, or alteration of
information, or
* unauthorized issuance of instructions,
o Attacks from without, such as denial of service attacks on the
IEPS equipment or the routing infrastructure supporting it,
o Attacks that transcend boundaries, such as viruses and worms.
While some of the ramifications of such attacks may transcend normal
consequences (the fire department may fail to be dispatched or may be
sent to the wrong part of town, or the "I Am Alive" database service
may find itself the vehicle for distribution of the nimda virus),
these are not fundamentally different kinds of attacks than those
experienced by other Internet sites.
One must therefore assume that the prevention and management of such
attacks is similarly common to the Internet.
2.1.3 Potentials for abuse of IEPS sites
There are also a number of ways that IEPS sites may be abused. For
example, if a wireless LAN is used to implement a site in a park, any
person with a compatible wireless LAN card can, at least
theoretically, obtain an IP Address and use the LAN for non-IEPS
purposes. If one assumes that the device will not be configured to
use IEPS DSCP values or applications, then it may be acceptable to
limit the case to a small percentage of available bandwidth and for
get it. Part of the requirement is to assess such risks, and in some
cases address them.
2.2 Call prioritization
The GETS service specifies that its telephone calls should be placed
in preference to other calls, should a situation arise in which some
Baker Expires May 15, 2002 [Page 8]
Internet-Draft Document November 2001
calls are not being placed. In SS7, it does this by specifying that
the call is an "authorized emergency" call in the ISUP IAM message.
There are two possible approaches to translating this into H.323 or
SIP: we can include the policy, in a call priority, or we can label
the call expecting external policy to have the necessary result. SIP
[24] has a priority field which is used for user to user
communication of call importance, but is not generally used by the
network. H.323 lacks both capabilities. In a situation where a
large number of people are attempting to place calls simultaneously,
the ability to select authenticated call requestors seems important.
An alternative approach is to label calls. For example, if the SS7
tag "authorized emergency" is to be translated to a corresponding SIP
or H.323 tag, that tag can be interpreted as implying a call
preference. Proposals are in place to label calls "authorized
emergency" in both H.323 and SIP [3], using priority (a policy) as a
label.
2.3 Routing Algorithms
IP Routing is generally performed on the basis of the destination
address prefix. In edge networks, and in backbones of ISPs, this is
often performed using "best path" protocols like OSPF [10]IS-IS [6].
Between ISPs, and between ISPs and their more sophisticated
customers, routing is performed using the policy-based Border Gateway
Protocol [7].
Routing paths will be chosen by the ISPs en route based on their
inter-carrier contracts and other parameters to meet their service
commitments. Generally speaking, ISPs are able to provide service
level agreements, which may include rate and delay characteristics,
within their networks; multi-provider routes offer less guarantees.
2.4 Quality of Service Algorithms and Configurations
The IEPS community is interested in tagging their information and
having it dealt with appropriately. The architecture for doing this
is a combination of the Differentiated Services Architecture [22] and
the Framework for Integrated Services Operation over Differentiated
Services Networks [37].
Such a configuration might, for example, provide seven classes of
traffic with specific support:
o EF [28] service for voice, with signaling of bandwidth [9][37],
o AF4 [27] service for video, with signaling of bandwidth [9][37],
Baker Expires May 15, 2002 [Page 9]
Internet-Draft Document November 2001
o AF3 [27] service for voice/video signaling,
o AF2 [27] service for transaction/ERP traffic,
o AF1 [27] service for traffic that will potentially move large
volumes,
o Class selector '110000' [21] for IP Routing traffic,
o Class selector '000000' [21] for everything else (interloper, DNS,
and anything we haven't thought of).
Such a definition, if it is to work well, must take into account the
various application's requirements, and meet them directly. These
requirements may be in the form of delay or jitter limits, rate
enforcement (whether as an upper or a lower bound), or enforcement of
access controls.
2.4.1 Voice and video services
If Voice on IP is in view, the key issues are loss, one-way delay and
variation in that delay. One-way delay is the sum of the
serialization and propagation delays of the various links en route,
plus the variable queuing delays. Data is generated in small voice
samples, which are either generated at a constant rate or are
suppressed when they contain silence. If the one-way delay is within
acceptable bounds, and variation in delay end to end is sufficiently
small, voice on IP is an effective application. Making that happen
can be hard; it requires either a sufficient over-supply of bandwidth
that all applications are served with essentially no jitter, or
separation of voice traffic into a queue that gives it essentially no
jitter.
Video on IP is a related application. As with voice, the key issues
are loss, one-way delay and variation in that delay. Video, however,
occupies a much higher data rate, one to three orders of magnitude
faster, and consists of fixed or variable data bursts in application
frame windows. Video is acceptable when all of the messages in a
frame arrive during either that frame window or the subsequent frame
window, which is a looser requirement than that of voice. Making
that happen can be hard none-the-less; it requires either a
sufficient over-supply of bandwidth that all applications are served
with no more jitter or loss than a video session can accept.
Accomplishing these goals in an environment which is not
significantly overprovisioned, or in which the degree of
overprovisioning is not known, requires ensuring proper behavior
becomes the responsibility of the bottleneck device. Accomplishing
Baker Expires May 15, 2002 [Page 10]
Internet-Draft Document November 2001
the goal requires the application of appropriate bandwidth admission
and queuing algorithms, such as Assured Forwarding [27], Expedited
Forwarding [28], RSVP [9], and the Integration of the Integrated and
Differentiated Services Architectures [37].
It is important to note that the action of assuring resources and
admission control for voice/video service to the general public may
in turn contribute to congestion. This may prevent new call from
being accepted, as opposed to all flows experiencing the same measure
of packet loss (and corresponding degraded service). The is the
fundamental reason to increase the probability that a call would pass
admission control.
2.4.2 Signaling information
The example configuration above calls for separate classes for voice
signaling (H.323 or SIP [24]). and for IP Routing. These have the
same basic requirements: while they are low volume overhead traffic,
their loss at critical junctures can be very unfortunate. They
should therefore not be unduly delayed, and they should not be
dropped.
Whether they should be classified separately is debated. One line of
reasoning suggests that they are both signaling with essentially the
same requirement, and so belong in the same class. Another line of
reason suggests that if IP Routing fails, everything fails, while if
voice signaling fails, a single Voice/Video on IP Call fails. The
separation in class proposed is due to the latter line of reasoning.
2.4.3 TCP- and SCTP-based applications
Most internet applications, however, are unlike voice or video in
their requirements. They are said to be "elastic", meaning that they
adapt themselves somewhat to available bandwidth, even if that
bandwidth fluctuates over time due to competing traffic demands.
These applications generally use TCP [4] or SCTP [36] as their
transport, but may use other transports. For convenience,
applications may be broken down by their dominant traffic
characteristics: some tend to have short exchanges during which
humans await the outcome, which we generically call "transaction" or
"interactive applications", and some move volumes of information in a
background mode, which we refer to as "file transfer" applications.
Examples of transaction applications include most database protocols,
but the most familiar is the World Wide Web [29]. An example of a
file transfer application is the File Transfer Protocol [5].
In general, transaction applications generate relatively low traffic
rates. The exchanges are sensitive to loss, in that a single packet
Baker Expires May 15, 2002 [Page 11]
Internet-Draft Document November 2001
loss may significantly extend the duration of an exchange. File
transfers, however, may consume the entire bandwidth of a link if
left unchecked, and especially on lower speed links can disrupt voice
and video applications, or may dramatically increase the delay
experienced by transaction applications.
At this point, the recommendation of the internet community is that
any TCP should implement TCP Congestion Avoidance [25], along with
the New Reno Modifications [26]. Regardless of transport (although
this is normally implemented by the transport), applications should
comply with the IETF Congestion Control Principles [35]. The
combined effects of these recommendations are to maximize the
throughput rates of TCP sessions while also making them very adaptive
to loss in the network. While not widely deployed at this writing,
there is also significant reason to believe that Explicit Congestion
Notification [42] has the effect of making TCP adapt well to
congestion without requiring loss to detect it.
Routers used in supporting bottleneck points in an IEPS service
should therefore also support Assured Forwarding [27], which combines
the concepts of giving a class of traffic a rate using a queue, using
active queue management to manage throughput, and potentially
metering arriving traffic when the rate is appropriate. If Explicit
Congestion Notification [42] is configurable in the routers, AQM's
random marking should be accomplished using that rather than
dropping.
In the FEMA example, satellites were used to provide rapidly
deployable mobile bandwidth. Satellites are an example of high
delay*bandwidth product links; the specifications developed for them
are applicable to any link having a high delay*bandwidth product,
such as transoceanic cable. Applications using such facilities
should review and apply Enhancing TCP Over Satellite Channels using
Standard Mechanisms [23]Ongoing TCP Research Related to Satellites
[31]
Baker Expires May 15, 2002 [Page 12]
Internet-Draft Document November 2001
3. Security Considerations
This document contains a section which addresses security
considerations.
Baker Expires May 15, 2002 [Page 13]
Internet-Draft Document November 2001
4. Acknowledgements
Scott Bradner, Hal Folts, Ken Carlberg, and Rei Atarashi reviewed
this draft.
Baker Expires May 15, 2002 [Page 14]
Internet-Draft Document November 2001
References
[1] , "IAA System (I Am Alive): The Experiences of the Internet
Disaster Drills", INET 2000, June 2000.
[2] "International Emergency Preparedness Scheme", ITU E.106, March
2000.
[3] Polk, J. and H. Schulzrinne, "SIP Communications Resource
Priority Header", draft-polk-sip-resource-00 (work in
progress), November 2001.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[6] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990.
[7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[10] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[11] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
AH", RFC 2403, November 1998.
[14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998.
[15] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
With Explicit IV", RFC 2405, November 1998.
Baker Expires May 15, 2002 [Page 15]
Internet-Draft Document November 2001
[16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[17] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[18] Maughan, D., Schneider, M. and M. Schertler, "Internet Security
Association and Key Management Protocol (ISAKMP)", RFC 2408,
November 1998.
[19] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[20] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[21] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[22] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[23] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, RFC
2488, January 1999.
[24] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[25] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[26] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
Fast Recovery Algorithm", RFC 2582, April 1999.
[27] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[28] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[29] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[30] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
Baker Expires May 15, 2002 [Page 16]
Internet-Draft Document November 2001
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
October 1999.
[31] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann,
S., Scott, K. and J. Semke, "Ongoing TCP Research Related to
Satellites", RFC 2760, February 2000.
[32] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B. and
J. Segers, "Megaco Protocol version 0.8", RFC 2885, August
2000.
[33] Taylor, T., "Megaco Errata", RFC 2886, August 2000.
[34] Cromwell, D., "Proposal for an MGCP Advanced Audio Package",
RFC 2897, August 2000.
[35] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[36] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[37] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
Felstaine, "A Framework for Integrated Services Operation over
Diffserv Networks", RFC 2998, November 2000.
[38] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and
J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November
2000.
[39] Blatherwick, P., Bell, R. and P. Holland, "Megaco IP Phone
Media Gateway Application Profile", RFC 3054, January 2001.
[40] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001.
[41] Srinath, A., Levendel, G., Fritz, K. and R. Kalyanaram, "MGCP
Business Phone Packages", RFC 3149, September 2001.
[42] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[43] Brown, I., "Securing prioritised emergency traffic", draft-
brown-ieprep-sec-00 (work in progress), July 2001.
Baker Expires May 15, 2002 [Page 17]
Internet-Draft Document November 2001
[44] Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP
Telephony", draft-carlberg-ieprep-framework-02 (work in
progress), October 2001.
[45] Carlberg, K., "The Classifier Extension Header for RTP", draft-
carlberg-rtp-classifier-extension-00 (work in progress),
October 2001.
[46] Folts, H., "Emergency Telecommunications Service in Next-
Generation Networks", draft-folts-ieprep-white-paper-00 (work in
progress), October 2001.
Author's Address
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117
US
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred.baker@cisco.com
Baker Expires May 15, 2002 [Page 18]
Internet-Draft Document November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker Expires May 15, 2002 [Page 19]
