[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-ieprep-requirements

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/