doc: Add RFC documents

1 files changed, 2355 insertions, 0 deletions

diff --git a/doc/rfc/rfc4542.txt b/doc/rfc/rfc4542.txt
new file mode 100644
index 0000000..06944de
--- /dev/null
+++ b/doc/rfc/rfc4542.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                           F. Baker
+Request for Comments: 4542                                       J. Polk
+Category: Informational                                    Cisco Systems
+                                                                May 2006
+
+
+    Implementing an Emergency Telecommunications Service (ETS) for
+           Real-Time Services in the Internet Protocol Suite
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                      [Page 1]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+Table of Contents
+
+   1. Overview of the Internet Emergency Preference Service
+      Problem and Proposed Solutions ..................................3
+      1.1. Emergency Telecommunications Services ......................3
+           1.1.1. Multi-Level Preemption and Precedence ...............4
+           1.1.2. Government Emergency Telecommunications Service .....6
+      1.2. Definition of Call Admission ...............................6
+      1.3. Assumptions about the Network ..............................7
+      1.4. Assumptions about Application Behavior .....................7
+      1.5. Desired Characteristics in an Internet Environment .........9
+      1.6. The Use of Bandwidth as a Solution for QoS ................10
+   2. Solution Proposal ..............................................11
+      2.1. Call Admission/Preemption Procedure .......................12
+      2.2. Voice Handling Characteristics ............................15
+      2.3. Bandwidth Admission Procedure .............................17
+           2.3.1. RSVP Admission Using Policy for Both
+                  Unicast and Multicast Sessions .....................17
+           2.3.2. RSVP Scaling Issues ................................19
+           2.3.3. RSVP Operation in Backbones and Virtual
+                  Private Networks (VPNs) ............................19
+           2.3.4. Interaction with the Differentiated
+                  Services Architecture ..............................21
+           2.3.5. Admission Policy ...................................21
+      2.4. Authentication and Authorization of Calls Placed ..........23
+      2.5. Defined User Interface ....................................23
+   3. Security Considerations ........................................24
+   4. Acknowledgements ...............................................24
+   5. References .....................................................25
+      5.1. Normative References ......................................25
+      5.2. Informative References ....................................27
+   Appendix A.  2-Call Preemption Example using RSVP .................29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                      [Page 2]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+1.  Overview of the Internet Emergency Preference Service Problem and
+    Proposed Solutions
+
+   [RFC3689] and [RFC3690] detail requirements for an Emergency
+   Telecommunications Service (ETS), of which an Internet Emergency
+   Preference Service (IEPS) would be a part.  Some of these types of
+   services require call preemption; others require call queuing or
+   other mechanisms.  The key requirement is to guarantee an elevated
+   probability of call completion to an authorized user in time of
+   crisis.
+
+   IEPS requires a Call Admission Control procedure and a Per Hop
+   Behavior 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.  These obviously include
+   but are not limited to Voice and Video applications, although at this
+   writing the community is mostly thinking about Voice on IP, and many
+   of the examples in the document are taken from that environment.
+
+   In a network where a call permitted initially is not denied or
+   rejected at a later time, capacity admission procedures performed
+   only at the time of call setup may be sufficient.  However, in a
+   network where session status can be reviewed by the network and
+   preempted or denied due to changes in routing (when the new routes
+   lack capacity to carry calls switched to them) or changes in offered
+   load (where higher precedence calls supersede existing calls),
+   maintaining a continuing model of the status of the various calls is
+   required.
+
+1.1.  Emergency Telecommunications Services
+
+   Before doing so, however, let us discuss the problem that ETS (and
+   therefore IEPS) is intended to solve and the architecture of the
+   system.  The Emergency Telecommunications Service [ITU.ETS.E106] is a
+   successor to and generalization of two services used in the United
+   States: Multi-Level Precedence and Preemption (MLPP), and the
+   Government Emergency Telecommunication Service (GETS).  Services
+   based on these models are also used in a variety of countries
+   throughout the world, both Public Switched Telephone Network (PSTN)
+   and Global System for Mobile Communications (GSM)-based.  Both of
+   these services are designed to enable an authorized user to obtain
+   service from the telephone network in times of crisis.  They differ
+   primarily in the mechanisms used and number of levels of precedence
+   acknowledged.
+
+
+
+
+
+
+
+Baker & Polk                 Informational                      [Page 3]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+1.1.1.  Multi-Level Preemption and Precedence
+
+   The Assured Service is designed as an IP implementation of an
+   existing ITU-T/NATO/DoD telephone system architecture known as
+   Multi-Level Precedence and Preemption [ITU.MLPP.1990]
+   [ANSI.MLPP.Spec] [ANSI.MLPP.Supp], or MLPP.  MLPP is an architecture
+   for a prioritized call handling service such that in times of
+   emergency in the relevant NATO and DoD commands, the relative
+   importance of various kinds of communications is strictly defined,
+   allowing higher-precedence communication at the expense of lower-
+   precedence communications.  This document describes NATO and US
+   Department of Defense uses of MLPP, but the architecture and standard
+   are applicable outside of these organizations.
+
+   These precedences, in descending order, are:
+
+   Flash Override Override:  used by the Commander in Chief, Secretary
+      of Defense, and Joint Chiefs of Staff, commanders of combatant
+      commands when declaring the existence of a state of war.
+      Commanders of combatant commands when declaring Defense Condition
+      One or Defense Emergency or Air Defense Emergency and other
+      national authorities that the President may authorize in
+      conjunction with Worldwide Secure Voice Conferencing System
+      conferences.  Flash Override Override cannot be preempted.  This
+      precedence level is not enabled on all DoD networks.
+
+   Flash Override:  used by the Commander in Chief, Secretary of
+      Defense, and Joint Chiefs of Staff, commanders of combatant
+      commands when declaring the existence of a state of war.
+      Commanders of combatant commands when declaring Defense Condition
+      One or Defense Emergency and other national authorities the
+      President may authorize.  Flash Override cannot be preempted in
+      the DSN.
+
+   Flash:  reserved generally for telephone calls pertaining to command
+      and control of military forces essential to defense and
+      retaliation, critical intelligence essential to national survival,
+      conduct of diplomatic negotiations critical to the arresting or
+      limiting of hostilities, dissemination of critical civil alert
+      information essential to national survival, continuity of federal
+      government functions essential to national survival, fulfillment
+      of critical internal security functions essential to national
+      survival, or catastrophic events of national or international
+      significance.
+
+   Immediate:  reserved generally for telephone calls pertaining to
+      situations that gravely affect the security of national and allied
+      forces, reconstitution of forces in a post-attack period,
+
+
+
+Baker & Polk                 Informational                      [Page 4]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+      intelligence essential to national security, conduct of diplomatic
+      negotiations to reduce or limit the threat of war, implementation
+      of federal government actions essential to national survival,
+      situations that gravely affect the internal security of the
+      nation, Civil Defense actions, disasters or events of extensive
+      seriousness having an immediate and detrimental effect on the
+      welfare of the population, or vital information having an
+      immediate effect on aircraft, spacecraft, or missile operations.
+
+   Priority:  reserved generally for telephone calls requiring
+      expeditious action by called parties and/or furnishing essential
+      information for the conduct of government operations.
+
+   Routine:  designation applied to those official government
+      communications that require rapid transmission by telephonic means
+      but do not require preferential handling.
+
+   MLPP is intended to deliver a higher probability of call completion
+   to the more important calls.  The rule, in MLPP, is that more
+   important calls override less important calls when congestion occurs
+   within a network.  Station-based preemption is used when a more
+   important call needs to be placed to either party in an existing
+   call.  Trunk-based preemption is used when trunk bandwidth needs to
+   be reallocated to facilitate a higher-precedence call over a given
+   path in the network.  In both station- and trunk-based preemption
+   scenarios, preempted parties are positively notified, via preemption
+   tone, that their call can no longer be supported.  The same
+   preemption tone is used, regardless of whether calls are terminated
+   for the purposes of station- of trunk-based preemption.  The
+   remainder of this discussion focuses on trunk-based preemption
+   issues.
+
+   MLPP is built as a proactive system in which callers must assign one
+   of the precedence levels listed above at call initiation; this
+   precedence level cannot be changed throughout that call.  If an
+   elevated status is not assigned by a user at call initiation time,
+   the call is assumed to be "routine".  If there is end-to-end capacity
+   to place a call, any call may be placed at any time.  However, when
+   any trunk group (in the circuit world) or interface (in an IP world)
+   reaches a utilization threshold, a choice must be made as to which
+   calls to accept or allow to continue.  The system will seize the
+   trunk(s) or bandwidth necessary to place the more important calls in
+   preference to less important calls by preempting an existing call (or
+   calls) of lower precedence to permit a higher-precedence call to be
+   placed.
+
+
+
+
+
+
+Baker & Polk                 Informational                      [Page 5]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   More than one call might properly be preempted if more trunks or
+   bandwidth is necessary for this higher precedence call.  A video call
+   (perhaps of 384 KBPS, or 6 trunks) competing with several lower-
+   precedence voice calls is a good example of this situation.
+
+1.1.2.  Government Emergency Telecommunications Service
+
+   A US service similar to MLPP and using MLPP signaling technology, but
+   built for use in civilian networks, is the Government Emergency
+   Telecommunications Service (GETS).  This differs from MLPP in two
+   ways: it does not use preemption, but rather reserves bandwidth or
+   queues calls to obtain a high probability of call completion, and it
+   has only two levels of service: "Routine" and "Priority".
+
+   GETS is described here as another example.  Similar architectures are
+   applied by other governments and organizations.
+
+1.2.  Definition of Call Admission
+
+   Traditionally, in the PSTN, Call Admission Control (CAC) has had the
+   responsibility of implementing bandwidth available thresholds (e.g.,
+   to limit resources consumed by some traffic) and determining whether
+   a caller has permission (e.g., is an identified subscriber, with
+   identify attested to by appropriate credentials) to use an available
+   circuit.  IEPS, or any emergency telephone service, has additional
+   options that it may employ to improve the probability of call
+   completion:
+
+   o  The call may be authorized to use other networks that it would not
+      normally use;
+
+   o  The network may preempt other calls to free bandwidth;
+
+   o  The network may hold the call and place it when other calls
+      complete; or
+
+   o  The network may use different bandwidth availability thresholds
+      than are used for other calls.
+
+   At the completion of CAC, however, the caller either has a circuit
+   that he or she is authorized to use or has no circuit.  Since the act
+   of preemption or consideration of alternative bandwidth sources is
+   part and parcel of the problem of providing bandwidth, the
+   authorization step in bandwidth provision also affects the choice of
+   networks that may be authorized to be considered.  The three cannot
+   be separated.  The CAC procedure finds available bandwidth that the
+   caller is authorized to use and preemption may in some networks be
+   part of making that happen.
+
+
+
+Baker & Polk                 Informational                      [Page 6]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+1.3.  Assumptions about the Network
+
+   IP networks generally fall into two categories: those with
+   constrained bandwidth, and those that are massively over-provisioned.
+   In a network where over any interval that can be measured (including
+   sub-second intervals) capacity exceeds offered load by at least 2:1,
+   the jitter and loss incurred in transit are nominal.  This is
+   generally a characteristic of properly engineered Ethernet LANs and
+   of optical networks (networks that measure their link speeds in
+   multiples of 51 MBPS); in the latter, circuit-switched networking
+   solutions such as Asynchronous Transfer Mode (ATM), MPLS, and GMPLS
+   can be used to explicitly place routes, which improves the odds a
+   bit.
+
+   Between those networks, in places commonly called "inter-campus
+   links", "access links", or "access networks", for various reasons
+   including technology (e.g., satellite links) and cost, it is common
+   to find links whose offered load can approximate or exceed the
+   available capacity.  Such events may be momentary or may occur for
+   extended periods of time.
+
+   In addition, primarily in tactical deployments, it is common to find
+   bandwidth constraints in the local infrastructure of networks.  For
+   example, the US Navy's network afloat connects approximately 300
+   ships, via satellite, to five network operation centers (NOCs), and
+   those NOCs are in turn interconnected via the Defense Information
+   Systems Agency (DISA) backbone.  A typical ship may have between two
+   and six radio systems aboard, often at speeds of 64 KBPS or less.  In
+   US Army networks, current radio technology likewise limits tactical
+   communications to links below 100 KBPS.
+
+   Over this infrastructure, military communications expect to deploy
+   voice communication systems (30-80 KBPS per session) and video
+   conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800
+   KBPS), in addition to traditional mail, file transfer, and
+   transaction traffic.
+
+1.4.  Assumptions about Application Behavior
+
+   Parekh and Gallagher published a series of papers [Parekh1] [Parekh2]
+   analyzing what is necessary to ensure a specified service level for a
+   stream of traffic.  In a nutshell, they showed that to predict the
+   behavior of a stream of traffic in a network, one must know two
+   things:
+
+   o  the rate and arrival distribution with which traffic in a class is
+      introduced to the network, and
+
+
+
+
+Baker & Polk                 Informational                      [Page 7]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   o  what network elements will do, in terms of the departure
+      distribution, injected delay jitter, and loss characteristics,
+      with the traffic they see.
+
+   For example, TCP tunes its effective window (the amount of data it
+   sends per round trip interval) so that the ratio of the window and
+   the round trip interval approximate the available capacity in the
+   network.  As long as the round trip delay remains roughly stable and
+   loss is nominal (which are primarily behaviors of the network), TCP
+   is able to maintain a predictable level of throughput.  In an
+   environment where loss is random or in which delays wildly vary, TCP
+   behaves in a far less predictable manner.
+
+   Voice and video systems, in the main, are designed to deliver a fixed
+   level of quality as perceived by the user.  (Exceptions are systems
+   that select rate options over a broad range to adapt to ambient loss
+   characteristics.  These deliver broadly fluctuating perceived quality
+   and have not found significant commercial applicability.)  Rather,
+   they send traffic at a rate specified by the codec depending on what
+   it perceives is required.  In an MPEG-4 system, for example, if the
+   camera is pointed at a wall, the codec determines that an 80 KBPS
+   data stream will describe that wall and issues that amount of
+   traffic.  If a person walks in front of the wall or the camera is
+   pointed an a moving object, the codec may easily send 800 KBPS in its
+   effort to accurately describe what it sees.  In commercial broadcast
+   sports, which may line up periods in which advertisements are
+   displayed, the effect is that traffic rates suddenly jump across all
+   channels at certain times because the eye-catching ads require much
+   more bandwidth than the camera pointing at the green football field.
+
+   As described in [RFC1633], when dealing with a real-time application,
+   there are basically two things one must do to ensure Parekh's first
+   requirement.  To ensure that one knows how much offered load the
+   application is presenting, one must police (measure load offered and
+   discard excess) traffic entering the network.  If that policing
+   behavior has a debilitating effect on the application, as non-
+   negligible loss has on voice or video, one must admit sessions
+   judiciously according to some policy.  A key characteristic of that
+   policy must be that the offered load does not exceed the capacity
+   dedicated to the application.
+
+   In the network, the other thing one must do is ensure that the
+   application's needs are met in terms of loss, variation in delay, and
+   end-to-end delay.  One way to do this is to supply sufficient
+   bandwidth so that loss and jitter are nominal.  Where that cannot be
+   accomplished, one must use queuing technology to deterministically
+   apply bandwidth to accomplish the goal.
+
+
+
+
+Baker & Polk                 Informational                      [Page 8]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+1.5.  Desired Characteristics in an Internet Environment
+
+   The key elements of the Internet Emergency Preference Service include
+   the following:
+
+   Precedence Level Marking each call:  Call initiators choose the
+      appropriate precedence level for each call based on the user-
+      perceived importance of the call.  This level is not to be changed
+      for the duration of the call.  The call before and the call after
+      are independent with regard to this level choice.
+
+   Call Admission/Preemption Policy:  There is likewise a clear policy
+      regarding calls that may be in progress at the called instrument.
+      During call admission (SIP/H.323), if they are of lower
+      precedence, they must make way according to a prescribed
+      procedure.  All callers on the preempted call must be informed
+      that the call has been preempted, and the call must make way for
+      the higher-precedence call.
+
+   Bandwidth Admission Policy:  There is a clear bandwidth admission
+      policy: sessions may be placed that assert any of several levels
+      of precedence, and in the event that there is demand and
+      authorization is granted, other sessions will be preempted to make
+      way for a call of higher precedence.
+
+   Authentication and Authorization of calls placed:  Unauthorized
+      attempts to place a call at an elevated status are not permitted.
+      In the telephone system, this is managed by controlling the policy
+      applied to an instrument by its switch plus a code produced by the
+      caller identifying himself or herself to the switch.  In the
+      Internet, such characteristics must be explicitly signaled.
+
+   Voice handling characteristics:  A call made, in the telephone
+      system, gets a circuit and provides the means for the callers to
+      conduct their business without significant impact as long as their
+      call is not preempted.  In a VoIP system, one would hope for
+      essentially the same service.
+
+   Defined User Interface:  If a call is preempted, the caller and the
+      callee are notified via a defined signal, so that they know that
+      their call has been preempted and that at this instant there is no
+      alternative circuit available to them at that precedence level.
+
+   A VoIP implementation of the Internet Emergency Preference Service
+   must, by definition, provide those characteristics.
+
+
+
+
+
+
+Baker & Polk                 Informational                      [Page 9]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+1.6.  The Use of Bandwidth as a Solution for QoS
+
+   There is a discussion in Internet circles concerning the relationship
+   of bandwidth to QoS procedures, which needs to be put to bed before
+   this procedure can be adequately analyzed.  The issue is that it is
+   possible and common in certain parts of the Internet to solve the
+   problem with bandwidth.  In LAN environments, for example, if there
+   is significant loss between any two switches or between a switch and
+   a server, the simplest and cheapest solution is to buy the next
+   faster interface: substitute 100 MBPS for 10 MBPS Ethernet, 1 gigabit
+   for 100 MBPS, or, for that matter, upgrade to a 10-gigabit Ethernet.
+   Similarly, in optical networking environments, the simplest and
+   cheapest solution is often to increase the data rate of the optical
+   path either by selecting a faster optical carrier or deploying an
+   additional lambda.  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 many places in communication networks where the provision
+   of effectively infinite bandwidth is not feasible, including many
+   access networks, satellite communications, fixed wireless, airborne
+   and marine communications, island connections, and connections to
+   regions in which fiber optic connections are not cost-effective.  It
+   is in these places where the question of resource management is
+   relevant.  Specifically, we do not recommend the deployment of
+   significant QoS procedures on links in excess of 100 MBPS apart from
+   the provision of aggregated services that provide specific protection
+   to the stability of the network or the continuity of real-time
+   traffic as a class, as the mathematics of such circuits do not
+   support this as a requirement.
+
+   In short, the fact that we are discussing this class of policy
+   control says that such constrictions in the network exist and must be
+   dealt with.  However much we might like to, in those places we are
+   not solving the problem with bandwidth.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 10]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+2.  Solution Proposal
+
+   A typical voice or video network, including a backbone domain, is
+   shown in Figure 1.
+
+      ...............             ......................
+     .                .          .                      .
+    .  H  H  H  H      .        .   H  H  H  H           .
+   .  /----------/      .       .  /----------/           .
+   .     R     SIP      .       .    R      R              .
+   .      \             .       .   /        \              .
+   .       R  H  H  H   . .......  /          \             .
+   .      /----------/  ..      ../            R     SIP    .
+    .              R  ..         /.           /----------/  .
+      .....       ..\.    R-----R  .           H  H  H  H   .
+            ......  .\   /       \  .                      .
+                    . \ /         \  .                    .
+                     .  R-----------R  ....................
+                     .   \         /   .
+                     .    \       /   .
+                     .     R-----R   .
+                      .             .
+                       ............
+
+           SIP   = SIP Proxy
+           H     = SIP-enabled Host (Telephone, call gateway or PC)
+           R     = Router
+           /---/ = Ethernet or Ethernet Switch
+
+              Figure 1: Typical VoIP or Video/IP Network
+
+  Reviewing the figure above, it becomes obvious that Voice/IP and
+  Video/IP call flows are very different than call flows in the PSTN.
+  In the PSTN, call control traverses a switch, which in turn controls
+  data handling services like ATM or Time Division Multiplexing (TDM)
+  switches or multiplexers.  While they may not be physically co-
+  located, the control plane software and the data plane services are
+  closely connected; the switch routes a call using bandwidth that it
+  knows is available.  In a voice/video-on-IP network, call control is
+  completely divorced from the data plane: It is possible for a
+  telephone instrument in the United States to have a Swedish telephone
+  number if that is where its SIP proxy happens to be, but on any given
+  call for it to use only data paths in the Asia/Pacific region, data
+  paths provided by a different company, and, often, data paths provided
+  by multiple companies/providers.
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 11]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+  Call management therefore addresses a variety of questions, all of
+  which must be answered:
+
+   o  May I make this call from an administrative policy perspective?
+      Am I authorized to make this call?
+
+   o  What IP address correlates with this telephone number or SIP URI?
+
+   o  Is the other instrument "on hook"?  If it is busy, under what
+      circumstances may I interrupt?
+
+   o  Is there bandwidth available to support the call?
+
+   o  Does the call actually work, or do other impairments (loss, delay)
+      make the call unusable?
+
+2.1.  Call Admission/Preemption Procedure
+
+   Administrative Call Admission is the objective of SIP and H.323.  It
+   asks fundamental questions like "What IP address is the callee at?"
+   and "Did you pay your bill?".
+
+   For a specialized policy like call preemption, two capabilities are
+   necessary from an administrative perspective: [RFC4412] provides a
+   way to communicate policy-related information regarding the
+   precedence of the call; and [RFC4411] provides a reason code when a
+   call fails or is refused, indicating the cause of the event.  If it
+   is a failure, it may make sense to redial the call.  If it is a
+   policy-driven preemption, even if the call is redialed it may not be
+   possible to place the call.  Requirements for this service are
+   further discussed in [RFC3689].
+
+   The SIP Communications Resource Priority Header (or RP Header) serves
+   the call setup process with the precedence level chosen by the
+   initiator of the call.  The syntax is in the form:
+
+        Resource Priority: namespace.priority level
+
+   The "namespace" part of the syntax ensures the domain of significance
+   to the originator of the call, and this travels end-to-end to the
+   destination (called) device (telephone).  If the receiving phone does
+   not support the namespace, it can easily ignore the setup request.
+   This ability to denote the domain of origin allows Service Level
+   Agreements (SLAs) to be in place to limit the ability of an unknown
+   requester to gain preferential treatment into an IEPS domain.
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 12]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   For the DSN infrastructure, the header would look like this for a
+   routine precedence level call:
+
+        Resource Priority: dsn.routine
+
+   The precedence level chosen in this header would be compared to the
+   requester's authorization profile to use that precedence level.  This
+   would typically occur in the SIP first-hop Proxy, which can challenge
+   many aspects of the call setup request including the requester's
+   choice of precedence levels (verifying that they are not using a
+   level they are not authorized to use).
+
+   The DSN has 5 precedence levels of IEPS, in descending order:
+
+        dsn.flash-override
+
+        dsn.flash
+
+        dsn.immediate
+
+        dsn.priority
+
+        dsn.routine
+
+   The US Defense Red Switched Network (DRSN), as another example that
+   was IANA-registered in [RFC4412], has 6 levels of precedence.  The
+   DRSN simply adds one precedence level higher than flash-override to
+   be used by the President and a select few others:
+
+        drsn.flash-override-override
+
+   Note that the namespace changed for this level.  The lower 5 levels
+   within the DRSN would also have this as their namespace for all
+   DRSN-originated call setup requests.
+
+   The Resource-Priority Header (RPH) informs both the use of
+   Differentiated Services Code Points (DSCPs) by the callee (who needs
+   to use the same DSCP as the caller to obtain the same data path
+   service) and to facilitate policy-based preemption of calls in
+   progress, when appropriate.
+
+   Once a call is established in an IEPS domain, the Reason Header for
+   Preemption, described in [RFC4411], ensures that all SIP nodes are
+   synchronized to a preemption event occurring either at the endpoint
+   or in a router that experiences congestion.  In SIP, the normal
+   indication for the end of a session is for one end system to send a
+   BYE Method request as specified in [RFC3261].  This, too, is the
+   proper means for signaling a termination of a call due to a
+
+
+
+Baker & Polk                 Informational                     [Page 13]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   preemption event, as it essentially performs a normal termination
+   with additional information informing the peer of the reason for the
+   abrupt end: it indicates that a preemption occurred.  This will be
+   used to inform all relevant SIP entities, and whether this was an
+   endpoint-generated preemption event, or that the preemption event
+   occurred within a router along the communications path (described in
+   Section 2.3.1).
+
+   Figure 2 is a simple example of a SIP call setup that includes the
+   layer 7 precedence of a call between Alice and Bob.  After Alice
+   successfully sets up a call to Bob at the "Routine" precedence level,
+   Carol calls Bob at a higher precedence level (Immediate).  At the SIP
+   layer (this has nothing to do with RSVP yet; that example, involving
+   SIP and RSVP signaling, is in the appendix), once Bob's user agent
+   (phone) receives the INVITE message from Carol, his UA needs to make
+   a choice between retaining the call to Alice and sending Carol a
+   "busy" indication, or preempting the call to Alice in favor of
+   accepting the call from Carol.  That choice in IEPS networks is a
+   comparison of Resource Priority headers.  Alice, who controlled the
+   precedence level of the call to Bob, sent the precedence level of her
+   call to him at "Routine" (the lowest level within the network).
+   Carol, who controls the priority of the call signal to Bob, sent her
+   priority level to "Immediate" (higher than "Routine").  Bob's UA
+   needs to (under IEPS policy) preempt the call from Alice (and provide
+   her with a preemption indication in the call termination message).
+   Bob needs to successfully answer the call setup from Carol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 14]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+      UA Alice                     UA Bob                       UA Carol
+         |    INVITE (RP: Routine)    |                             |
+         |--------------------------->|                             |
+         |           200 OK           |                             |
+         |<---------------------------|                             |
+         |            ACK             |                             |
+         |--------------------------->|                             |
+         |            RTP             |                             |
+         |<==========================>|                             |
+         |                            |                             |
+         |                            |   INVITE (RP: Immediate)    |
+         |                            |<----------------------------|
+         |      ************************************************    |
+         |      *Resource Priority value comparison by Bob's UA*    |
+         |      ************************************************    |
+         |                            |                             |
+         | BYE (Reason: UA preemption)                              |
+         |<---------------------------|                             |
+         |                            |           200 OK            |
+         |                            |---------------------------->|
+         |       200 OK (BYE)         |                             |
+         |--------------------------->|                             |
+         |                            |            ACK              |
+         |                            |<----------------------------|
+         |                            |            RTP              |
+         |                            |<===========================>|
+         |                            |                             |
+
+    Figure 2: Priority Call Establishment and Termination at SIP Layer
+
+   Nothing in this example involved mechanisms other than SIP.  It is
+   also assumed each user agent recognized the Resource-Priority header
+   namespace value in each message.  Therefore, it is assumed that the
+   domain allowed Alice, Bob, and Carol to communicate.  Authentication
+   and Authorization are discussed later in this document.
+
+2.2.  Voice Handling Characteristics
+
+   The Quality of Service architecture used in the data path is that of
+   [RFC2475].  Differentiated Services uses a flag in the IP header
+   called the DSCP [RFC2474] to identify a data stream, and then applies
+   a procedure called a Per Hop Behavior, or PHB, to it.  This is
+   largely as described in [RFC2998].
+
+   In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247]
+   describes the fundamental needs of voice and video traffic.  This PHB
+   entails ensuring that sufficient bandwidth is dedicated to real-time
+   traffic to ensure that variation in delay and loss rate are minimal,
+
+
+
+Baker & Polk                 Informational                     [Page 15]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   as codecs are hampered by excessive loss [G711.1] [G711.3].  In parts
+   of the network where bandwidth is heavily over-provisioned, there may
+   be no remaining concern.  In places in the network where bandwidth is
+   more constrained, this may require the use of a priority queue.  If a
+   priority queue is used, the potential for abuse exists, meaning that
+   it is also necessary to police traffic placed into the queue to
+   detect and manage abuse.  A fundamental question is "where does this
+   policing need to take place?".  The obvious places would be the
+   first-hop routers and any place where converging data streams might
+   congest a link.
+
+   Some proposals mark traffic with various code points appropriate to
+   the service precedence of the call.  In normal service, if the
+   traffic is all in the same queue and EF service requirements are met
+   (applied capacity exceeds offered load, variation in delay is
+   minimal, and loss is negligible), details of traffic marking should
+   be irrelevant, as long as packets get into the right service class.
+   Then, the major issues are appropriate policing of traffic,
+   especially around route changes, and ensuring that the path has
+   sufficient capacity.
+
+   The real-time voice/video application should be generating traffic at
+   a rate appropriate to its content and codec, which is either a
+   constant bit rate stream or a stream whose rate is variable within a
+   specified range.  The first-hop router should be policing traffic
+   originated by the application, as is performed in traditional virtual
+   circuit networks like Frame Relay and ATM.  Between these two checks
+   (at what some networks call the Data Terminal Equipment (DTE) and
+   Data Communications Equipment (DCE)), the application traffic should
+   be guaranteed to be within acceptable limits.  As such, given
+   bandwidth-aware call admission control, there should be minimal
+   actual loss.  The cases where loss would occur include cases where
+   routing has recently changed and CAC has not caught up, or cases
+   where statistical thresholds are in use in CAC and the data streams
+   happen to coincide at their peak rates.
+
+   If it is demonstrated that routing transients and variable rate beat
+   frequencies present a sufficient problem, it is possible to provide a
+   policing mechanism that isolates intentional loss among an ordered
+   set of classes.  While the ability to do so, by various algorithms,
+   has been demonstrated, the technical requirement has not.  If
+   dropping random packets from all calls is not appropriate,
+   concentrating random loss in a subset of the calls makes the problem
+   for those calls worse; a superior approach would reject or preempt an
+   entire call.
+
+   Parekh's second condition has been met: we must know what the network
+   will do with the traffic.  If the offered load exceeds the available
+
+
+
+Baker & Polk                 Informational                     [Page 16]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   bandwidth, the network will remark and drop the excess traffic.  The
+   key questions become "How does one limit offered load to a rate less
+   than or equal to available bandwidth?" and "How much traffic does one
+   admit with each appropriate marking?"
+
+2.3.  Bandwidth Admission Procedure
+
+   Since many available voice and video codecs require a nominal loss
+   rate to deliver acceptable performance, Parekh's first requirement is
+   that offered load be within the available capacity.  There are
+   several possible approaches.
+
+   An approach that is commonly used in H.323 networks is to limit the
+   number of calls simultaneously accepted by the gatekeeper.  SIP
+   networks do something similar when they place a stateful SIP proxy
+   near a single ingress/egress to the network.  This is able to impose
+   an upper bound on the total number of calls in the network or the
+   total number of calls crossing the significant link.  However, the
+   gatekeeper has no knowledge of routing, so the engineering must be
+   very conservative and usually presumes a single ingress/egress or the
+   failure of one of its data paths.  While this may serve as a short-
+   term work-around, it is not a general solution that is readily
+   deployed.  This limits the options in network design.
+
+   [RFC1633] provides for signaled admission for the use of capacity.
+   The recommended approach is explicit capacity admission, supporting
+   the concepts of preemption.  An example of such a procedure uses the
+   Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP).  The use of
+   Capacity Admission using RSVP with SIP is described in [RFC3312].
+   While call counting is specified in H.323, network capacity admission
+   is not integrated with H.323 at this time.
+
+2.3.1.  RSVP Admission Using Policy for Both Unicast and Multicast
+        Sessions
+
+   RSVP is a resource reservation setup protocol providing the one-way
+   (at a time) setup of resource reservations for multicast and unicast
+   flows.  Each reservation is set up in one direction (meaning one
+   reservation from each end system; in a multicast environment, N
+   senders set up N reservations).  These reservations complete a
+   communication path with a deterministic bandwidth allocation through
+   each router along that path between end systems.  These reservations
+   set up a known quality of service for end-to-end communications and
+   maintain a "soft-state" within a node.  The meaning of the term "soft
+   state" is that in the event of a network outage or change of routing,
+   these reservations are cleared without manual intervention, but must
+   be periodically refreshed.  In RSVP, the refresh period is by default
+   30 seconds, but may be as long as is appropriate.
+
+
+
+Baker & Polk                 Informational                     [Page 17]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   RSVP is a locally-oriented process, not a globally- or domain-
+   oriented one like a routing protocol or H.323 Call Counting.
+   Although it uses the local routing databases to determine the routing
+   path, it is only concerned with the quality of service for a
+   particular or aggregate flow through a device.  RSVP is not aware of
+   anything other than the local goal of QoS and its RSVP-enabled
+   adjacencies, operating below the network layer.  The process by
+   itself neither requires nor has any end-to-end network knowledge or
+   state.  Thus, RSVP can be effective when it is enabled at some nodes
+   in a network without the need to have every node participate.
+
+                 HOST                              ROUTER
+    _____________________________       ____________________________
+   |  _______                    |     |                            |
+   | |       |   _______         |     |            _______         |
+   | |Appli- |  |       |        |RSVP |           |       |        |
+   | | cation|  | RSVP <---------------------------> RSVP  <---------->
+   | |       <-->       |        |     | _______   |       |        |
+   | |       |  |process|  _____ |     ||Routing|  |process|  _____ |
+   | |_._____|  |       -->Policy|     ||       <-->       -->Policy||
+   |   |        |__.__._| |Cntrl||     ||process|  |__.__._| |Cntrl||
+   |   |data       |  |   |_____||     ||__.____|     |  |   |_____||
+   |===|===========|==|==========|     |===|==========|==|==========|
+   |   |   --------|  |    _____ |     |   |  --------|  |    _____ |
+   |   |  |        |  ---->Admis||     |   |  |       |  ---->Admis||
+   |  _V__V_    ___V____  |Cntrl||     |  _V__V_    __V_____ |Cntrl||
+   | |      |  |        | |_____||     | |      |  |        ||_____||
+   | |Class-|  | Packet |        |     | |Class-|  | Packet |       |
+   | | ifier|==>Schedulr|================> ifier|==>Schedulr|=========>
+   | |______|  |________|        |data | |______|  |________|      data
+   |                             |     |                            |
+   |_____________________________|     |____________________________|
+
+                    Figure 3: RSVP in Hosts and Routers
+
+   Figure 3 shows the internal process of RSVP in both hosts (end
+   systems) and routers, as shown in [RFC2209].
+
+   RSVP uses the phrase "traffic control" to describe the mechanisms of
+   how a data flow receives quality of service.  There are 3 different
+   mechanisms to traffic control (shown in Figure 2 in both hosts and
+   routers).  They are:
+
+   A packet classifier mechanism: This resolves the QoS class for each
+      packet; this can determine the route as well.
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 18]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   An admission control mechanism: This consists of two decision
+      modules: admission control and policy control.  Determining
+      whether there are satisfactory resources for the requested QoS is
+      the function of admission control.  Determining whether the user
+      has the authorization to request such resources is the function of
+      policy control.  If the parameters carried within this flow fail,
+      either of these two modules errors the request using RSVP.
+
+   A packet scheduler mechanism:  At each outbound interface, the
+      scheduler attains the guaranteed QoS for that flow.
+
+2.3.2.  RSVP Scaling Issues
+
+   As originally written, there was concern that RSVP had scaling
+   limitations due to its data plane behavior [RFC2208].  This either
+   has not proven to be the case or has in time largely been corrected.
+   Telephony services generally require peak call admission rates on the
+   order of thousands of calls per minute and peak call levels
+   comparable to the capacities of the lines in question, which is
+   generally on the order of thousands to tens of thousands of calls.
+   Current RSVP implementations admit calls at the rate of hundreds of
+   calls per second and maintain as many calls in progress as memory
+   configurations allow.
+
+   In edge networks, RSVP is used to signal for individual microflows,
+   admitting the bandwidth.  However, Differentiated Services is used
+   for the data plane behavior.  Admission and policing may be performed
+   anywhere, but need only be performed in the first-hop router (which,
+   if the end system sending the traffic is a DTE, constitutes a DCE for
+   the remaining network) and in routers that have interfaces threatened
+   by congestion.  In Figure 1, these would normally be the links that
+   cross network boundaries.
+
+2.3.3.  RSVP Operation in Backbones and Virtual Private Networks (VPNs)
+
+   In backbone networks, networks that are normally awash in bandwidth,
+   RSVP and its affected data flows may be carried in a variety of ways.
+   If the backbone is a maze of tunnels between its edges (true of MPLS
+   networks, networks that carry traffic from an encryptor to a
+   decryptor, and also VPNs), applicable technologies include [RFC2207],
+   [RFC2746], and [RFC2983].  An IP tunnel is, simplistically put, a IP
+   packet enveloped inside another IP packet as a payload.  When IPv6 is
+   transported over an IPv4 network, encapsulating the entire v6 packet
+   inside a v4 packet is an effective means to accomplish this task.  In
+   this type of tunnel, the IPv6 packet is not read by any of the
+   routers while inside the IPv4 envelope.  If the inner packet is RSVP
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 19]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   enabled, there must be an active configuration to ensure that all
+   relevant backbone nodes read the RSVP fields; [RFC2746] describes
+   this.
+
+   This is similar to how IPsec tunnels work.  Encapsulating an RSVP
+   packet inside an encrypted packet for security purposes without
+   copying or conveying the RSVP indicators in the outside IP packet
+   header would make RSVP inoperable while in this form of a tunnel.
+   [RFC2207] describes how to modify an IPsec packet header to allow for
+   RSVP awareness by nodes that need to provide QoS for the flow or
+   flows inside a tunnel.
+
+   Other networks may simply choose to aggregate the reservations across
+   themselves as described in [RFC3175].  The problem with an individual
+   reservation architecture is that each flow requires a non-trivial
+   amount of message exchange, computation, and memory resources in each
+   router between each endpoint.  Aggregation of flows reduces the
+   number of completely individual reservations into groups of
+   individual flows that can act as one for part or all of the journey
+   between end systems.  Aggregates are not intended to be from the
+   first router to the last router within a flow, but to cover common
+   paths of a large number of individual flows.
+
+   Examples of aggregated data flows include streams of IP data that
+   traverse common ingress and egress points in a network and also
+   include tunnels of various kinds.  MPLS LSPs, IPsec Security
+   Associations between VPN edge routers, IP/IP tunnels, and Generic
+   Routing Encapsulation (GRE) tunnels all fall into this general
+   category.  The distinguishing factor is that the system injecting an
+   aggregate into the aggregated network sums the PATH and RESV
+   statistical information on the un-aggregated side and produces a
+   reservation for the tunnel on the aggregated side.  If the bandwidth
+   for the tunnel cannot be expanded, RSVP leaves the existing
+   reservation in place and returns an error to the aggregator, which
+   can then apply a policy such as IEPS to determine which session to
+   refuse.  In the data plane, the DSCP for the traffic must be copied
+   from the inner to the outer header, to preserve the PHB's effect.
+
+   One concern with this approach is that this leaks information into
+   the aggregated zone concerning the number of active calls or the
+   bandwidth they consume.  In fact, it does not, as the data itself is
+   identifiable by aggregator address, deaggregator address, and DSCP.
+   As such, even if it is not advertised, such information is
+   measurable.
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 20]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+2.3.4.  Interaction with the Differentiated Services Architecture
+
+   In the PATH message, the DCLASS object described in [RFC2996] is used
+   to carry the determined DSCP for the precedence level of that call in
+   the stream.  This is reflected back in the RESV message.  The DSCP
+   will be determined from the authorized SIP message exchange between
+   end systems by using the R-P header.  The DCLASS object permits both
+   bandwidth admission within a class and the building up of the various
+   rates or token buckets.
+
+2.3.5.  Admission Policy
+
+   RSVP's basic admission policy, as defined, is to grant any user
+   bandwidth if there is bandwidth available within the current
+   configuration.  In other words, if a new request arrives and the
+   difference between the configured upper bound and the currently
+   reserved bandwidth is sufficiently large, RSVP grants use of that
+   bandwidth.  This basic policy may be augmented in various ways, such
+   as using a local or remote policy engine to apply AAA procedures and
+   further qualify the reservation.
+
+2.3.5.1.  Admission for Variable Rate Codecs
+
+   For certain applications, such as broadcast video using MPEG-1 or
+   voice without activity detection and using a constant bit rate codec
+   such as G.711, this basic policy is adequate apart from AAA.  For
+   variable rate codecs, such as MPEG-4 or a voice codec with Voice
+   Activity Detection, however, this may be deemed too conservative.  In
+   such cases, two basic types of statistical policy have been studied
+   and reported on in the literature: simple over-provisioning, and
+   approximation to ambient load.
+
+   Simple over-provisioning sets the bandwidth admission limit higher
+   than the desired load, on the assumption that a session that admits a
+   certain bandwidth will in fact use a fraction of the bandwidth.  For
+   example, if MPEG-4 data streams are known to use data rates between
+   80 and 800 KBPS and there is no obvious reason that sessions would
+   synchronize (such as having commercial breaks on 15 minute
+   boundaries), one could imagine estimating that the average session
+   consumes 400 KBPS and treating an admission of 800 KBPS as actually
+   consuming half the amount.
+
+   One can also approximate to average load, which is perhaps a more
+   reliable procedure.  In this case, one maintains a variable that
+   measures actual traffic through the admitted data's queue,
+   approximating it using an exponentially weighted moving average.
+   When a new reservation request arrives, if the requested rate is less
+   than the difference between the configured upper bound and the
+
+
+
+Baker & Polk                 Informational                     [Page 21]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   current value of the moving average, the reservation is accepted, and
+   the moving average is immediately increased by the amount of the
+   reservation to ensure that the bandwidth is not promised out to
+   several users simultaneously.  In time, the moving average will decay
+   from this guard position to an estimate of true load, which may offer
+   a chance to another session to be reserved that would otherwise have
+   been refused.
+
+   Statistical reservation schemes such as these are overwhelmingly
+   dependent on the correctness of their configuration and its
+   appropriateness for the codecs in use.  However, they offer the
+   opportunity to take advantage of statistical multiplexing gains that
+   might otherwise be missed.
+
+2.3.5.2.  Interaction with Complex Admission Policies, AAA, and
+          Preemption of Bandwidth
+
+   Policy is carried and applied as described in [RFC2753].  Figure 4,
+   below, is the basic conceptual model for policy decisions and
+   enforcement in an Integrated Services model.  This model was created
+   to provide the ability to monitor and control reservation flows based
+   on user identify, specific traffic and security requirements, and
+   conditions that might change for various reasons, including a
+   reaction to a disaster or emergency event involving the network or
+   its users.
+
+     Network Node       Policy server
+    ______________
+   |   ______     |
+   |  |      |    |      _____
+   |  | PEP  |    |     |     |------------->
+   |  |______|<---|---->| PDP |May use LDAP,SNMP,COPS...for accessing
+   |     ^        |     |     | policy database, authentication, etc.
+   |     |        |     |_____|------------->
+   |   __v___     |
+   |  |      |    |     PDP = Policy Decision Point
+   |  | LPDP |    |     PEP = Policy Enforcement Point
+   |  |______|    |    LPDP = Local Policy Decision Point
+   |______________|
+
+         Figure 4: Conceptual Model for Policy Control of Routers
+
+   The Network Node represents a router in the network.  The Policy
+   Server represents the point of admission and policy control by the
+   network operator.  Policy Enforcement Point (PEP) (the router) is
+   where the policy action is carried out.  Policy decisions can be
+   either locally present in the form of a Local Policy Decision Point
+   (LPDP), or in a separate server on the network called the Policy
+
+
+
+Baker & Polk                 Informational                     [Page 22]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   Decision Point.  The easier the instruction set of rules, the more
+   likely this set can reside in the LPDP for speed of access reasons.
+   The more complex the rule set, the more likely this is active on a
+   remote server.  The PDP will use other protocols (LDAP, SNMP, etc.)
+   to request information (e.g., user authentication and authorization
+   for precedence level usage) to be used in creating the rule sets of
+   network components.  This remote PDP should also be considered where
+   non-reactive policies are distributed out to the LPDPs.
+
+   Taking the above model as a framework, [RFC2750] extends RSVP's
+   concept of a simple reservation to include policy controls, including
+   the concepts of Preemption [RFC3181] and Identity [RFC3182],
+   specifically speaking to the usage of policies that preempt calls
+   under the control of either a local or remote policy manager.  The
+   policy manager assigns a precedence level to the admitted data flow.
+   If it admits a data flow that exceeds the available capacity of a
+   system, the expectation is that the RSVP-affected RSVP process will
+   tear down a session among the lowest precedence sessions it has
+   admitted.  The RESV Error resulting from that will go to the receiver
+   of the data flow and be reported to the application (SIP or H.323).
+   That application is responsible for disconnecting its call, with a
+   reason code of "bandwidth preemption".
+
+2.4.  Authentication and Authorization of Calls Placed
+
+   It will be necessary, of course, to ensure that any policy is applied
+   to an authenticated user; the capabilities assigned to an
+   authenticated user may be considered authorized for use in the
+   network.  For bandwidth admission, this will require the utilization
+   of [RFC2747] [RFC3097].  In SIP and H.323, AAA procedures will also
+   be needed.
+
+2.5.  Defined User Interface
+
+   The user interface -- the chimes and tones heard by the user --
+   should ideally remain the same as in the PSTN for those indications
+   that are still applicable to an IP network.  There should be some new
+   effort generated to update the list of announcements sent to the user
+   that don't necessarily apply.  All indications to the user, of
+   course, depend on positive signals, not unreliable measures based on
+   changing measurements.
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 23]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+3.  Security Considerations
+
+   This document outlines a networking capability composed entirely of
+   existing specifications.  It has significant security issues, in the
+   sense that a failure of the various authentication or authorization
+   procedures can cause a fundamental breakdown in communications.
+   However, the issues are internal to the various component protocols
+   and are covered by their various security procedures.
+
+4.  Acknowledgements
+
+   This document was developed with the knowledge and input of many
+   people, far too numerous to be mentioned by name.  However, key
+   contributors of thoughts include Francois Le Faucheur, Haluk
+   Keskiner, Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan,
+   and Tony De Simone.  Pete Babendreier, Ken Carlberg, and Mike Pierce
+   provided useful reviews.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 24]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC3689]         Carlberg, K. and R. Atkinson, "General Requirements
+                     for Emergency Telecommunication Service (ETS)", RFC
+                     3689, February 2004.
+
+   [RFC3690]         Carlberg, K. and R. Atkinson, "IP Telephony
+                     Requirements for Emergency Telecommunication
+                     Service (ETS)", RFC 3690, February 2004.
+
+   Integrated Services Architecture References
+
+   [RFC1633]         Braden, B., Clark, D., and S. Shenker, "Integrated
+                     Services in the Internet Architecture: an
+                     Overview", RFC 1633, June 1994.
+
+   [RFC2205]         Braden, B., Zhang, L., Berson, S., Herzog, S., and
+                     S.  Jamin, "Resource ReSerVation Protocol (RSVP) --
+                     Version 1 Functional Specification", RFC 2205,
+                     September 1997.
+
+   [RFC2207]         Berger, L. and T. O'Malley, "RSVP Extensions for
+                     IPSEC Data Flows", RFC 2207, September 1997.
+
+   [RFC2208]         Mankin, A., Baker, F., Braden, B., Bradner, S.,
+                     O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
+                     "Resource ReSerVation Protocol (RSVP) Version 1
+                     Applicability Statement Some Guidelines on
+                     Deployment", RFC 2208, September 1997.
+
+   [RFC2209]         Braden, B. and L. Zhang, "Resource ReSerVation
+                     Protocol (RSVP) -- Version 1 Message Processing
+                     Rules", RFC 2209, September 1997.
+
+   [RFC2746]         Terzis, A., Krawczyk, J., Wroclawski, J., and L.
+                     Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
+                     January 2000.
+
+   [RFC2747]         Baker, F., Lindell, B., and M. Talwar, "RSVP
+                     Cryptographic Authentication", RFC 2747, January
+                     2000.
+
+   [RFC2750]         Herzog, S., "RSVP Extensions for Policy Control",
+                     RFC 2750, January 2000.
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 25]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   [RFC2753]         Yavatkar, R., Pendarakis, D., and R. Guerin, "A
+                     Framework for Policy-based Admission Control", RFC
+                     2753, January 2000.
+
+   [RFC2996]         Bernet, Y., "Format of the RSVP DCLASS Object", RFC
+                     2996, November 2000.
+
+   [RFC2998]         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.
+
+   [RFC3097]         Braden, R. and L. Zhang, "RSVP Cryptographic
+                     Authentication -- Updated Message Type Value", RFC
+                     3097, April 2001.
+
+   [RFC3175]         Baker, F., Iturralde, C., Le Faucheur, F., and B.
+                     Davie, "Aggregation of RSVP for IPv4 and IPv6
+                     Reservations", RFC 3175, September 2001.
+
+   [RFC3181]         Herzog, S., "Signaled Preemption Priority Policy
+                     Element", RFC 3181, October 2001.
+
+   [RFC3182]         Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
+                     Moore, T., Herzog, S., and R. Hess, "Identity
+                     Representation for RSVP", RFC 3182, October 2001.
+
+   [RFC3312]         Camarillo, G., Marshall, W., and J. Rosenberg,
+                     "Integration of Resource Management and Session
+                     Initiation Protocol (SIP)", RFC 3312, October 2002.
+
+   Differentiated Services Architecture References
+
+   [RFC2474]         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.
+
+   [RFC2475]         Blake, S., Black, D., Carlson, M., Davies, E.,
+                     Wang, Z., and W. Weiss, "An Architecture for
+                     Differentiated Services", RFC 2475, December 1998.
+
+   [RFC2983]         Black, D., "Differentiated Services and Tunnels",
+                     RFC 2983, October 2000.
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 26]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   [RFC3246]         Davie, B., Charny, A., Bennet, J., Benson, K., Le
+                     Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
+                     and D.  Stiliadis, "An Expedited Forwarding PHB
+                     (Per-Hop Behavior)", RFC 3246, March 2002.
+
+   [RFC3247]         Charny, A., Bennet, J., Benson, K., Boudec, J.,
+                     Chiu, A., Courtney, W., Davari, S., Firoiu, V.,
+                     Kalmanek, C., and K.  Ramakrishnan, "Supplemental
+                     Information for the New Definition of the EF PHB
+                     (Expedited Forwarding Per-Hop Behavior)", RFC 3247,
+                     March 2002.
+
+   Session Initiation Protocol and Related References
+
+   [RFC2327]         Handley, M. and V. Jacobson, "SDP: Session
+                     Description Protocol", RFC 2327, April 1998.
+
+   [RFC3261]         Rosenberg, J., Schulzrinne, H., Camarillo, G.,
+                     Johnston, A., Peterson, J., Sparks, R., Handley,
+                     M., and E.  Schooler, "SIP: Session Initiation
+                     Protocol", RFC 3261, June 2002.
+
+   [RFC4411]         Polk, J., "Extending the Session Initiation
+                     Protocol (SIP) Reason Header for Preemption
+                     Events", RFC 4411, February 2006.
+
+   [RFC4412]         Schulzrinne, H. and J. Polk, "Communications
+                     Resource Priority for the Session Initiation
+                     Protocol (SIP)", RFC 4412, February 2006.
+
+5.2.  Informative References
+
+   [ANSI.MLPP.Spec]  American National Standards Institute,
+                     "Telecommunications - Integrated Services Digital
+                     Network (ISDN) - Multi-Level Precedence and
+                     Preemption (MLPP) Service Capability", ANSI
+                     T1.619-1992 (R1999), 1992.
+
+   [ANSI.MLPP.Supp]  American National Standards Institute, "MLPP
+                     Service Domain Cause Value Changes", ANSI ANSI
+                     T1.619a-1994 (R1999), 1990.
+
+   [G711.1]          Viola Networks, "Netally VoIP Evaluator", January
+                     2003, <http://www.brainworks.de/Site/hersteller/
+                     viola_networks/Dokumente/Compr_Report_Sample.pdf>.
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 27]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   [G711.3]          Nortel Networks, "Packet Loss and Packet Loss
+                     Concealment", 2000, <http://www.nortelnetworks.com/
+                     products/01/succession/es/collateral/
+                     tb_pktloss.pdf>.
+
+   [ITU.ETS.E106]    International Telecommunications Union,
+                     "International Emergency Preference Scheme for
+                     disaster relief operations (IEPS)", ITU-T
+                     Recommendation E.106, October 2003.
+
+   [ITU.MLPP.1990]   International Telecommunications Union, "Multilevel
+                     Precedence and Preemption Service (MLPP)", ITU-T
+                     Recommendation I.255.3, 1990.
+
+   [Parekh1]         Parekh, A. and R. Gallager, "A Generalized
+                     Processor Sharing Approach to Flow Control in
+                     Integrated Services Networks: The Multiple Node
+                     Case", INFOCOM 1993: 521-530, 1993.
+
+   [Parekh2]         Parekh, A. and R. Gallager, "A Generalized
+                     Processor Sharing Approach to Flow Control in
+                     Integrated Services Networks: The Single Node
+                     Case", INFOCOM 1992: 915-924, 1992.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 28]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+Appendix A.  2-Call Preemption Example Using RSVP
+
+   This appendix will present a more complete view of the interaction
+   among SIP, SDP, and RSVP.  The bulk of the material is referenced
+   from [RFC2327], [RFC3312], [RFC4411], and [RFC4412].  There will be
+   some discussion on basic RSVP operations regarding reservation paths;
+   this will be mostly from [RFC2205].
+
+   SIP signaling occurs at the Application Layer, riding on a UDP/IP or
+   TCP/IP (including TLS/TCP/IP) transport that is bound by routing
+   protocols such as BGP and OSPF to determine the route the packets
+   traverse through a network between source and destination devices.
+   RSVP is riding on top of IP as well, which means RSVP is at the mercy
+   of the IP routing protocols to determine a path through the network
+   between endpoints.  RSVP is not a routing protocol.  In this
+   appendix, there will be an escalation of building blocks getting to
+   how the many layers are involved in SIP.  QoS Preconditions require
+   successful RSVP signaling between endpoints prior to SIP successfully
+   acknowledging the setup of the session (for voice, video, or both).
+   Then we will present what occurs when a network overload occurs
+   (congestion), causing a SIP session to be preempted.
+
+   Three diagrams in this appendix show multiple views of the same
+   example of connectivity for discussion throughout this appendix.  The
+   first diagram (Figure 5) is of many routers between many endpoints
+   (SIP user agents, or UAs).  There are 4 UAs of interest; those are
+   for users Alice, Bob, Carol, and Dave.  When a user (the human) of a
+   UA gets involved and must do something to a UA to progress a SIP
+   process, this will be explicitly mentioned to avoid confusion;
+   otherwise, when Alice is referred to, it means Alice's UA (her
+   phone).
+
+   RSVP reserves bandwidth in one direction only (the direction of the
+   RESV message), as has been discussed, IP forwarding of packets are
+   dictated by the routing protocol for that portion of the
+   infrastructure from the point of view of where the packet is to go
+   next.
+
+   The RESV message traverses the routers in the reverse path taken by
+   the PATH message.  The PATH message establishes a record of the route
+   taken through a network portion to the destination endpoint, but it
+   does not reserve resources (bandwidth).  The RESV message back to the
+   original requester of the RSVP flow requests for the bandwidth
+   resources.  This means the endpoint that initiates the RESV message
+   controls the parameters of the reservation.  This document specifies
+   in the body text that the SIP initiator (the UAC) establishes the
+   parameters of the session in an INVITE message, and that the INVITE
+   recipient (the UAS) must follow the parameters established in that
+
+
+
+Baker & Polk                 Informational                     [Page 29]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   INVITE message.  One exception to this is which codec to use if the
+   UAC offered more than one to the UAS.  This exception will be shown
+   when the INVITE message is discussed in detail later in the appendix.
+   If there was only one codec in the SDP of the INVITE message, the
+   parameters of the reservation will follow what the UAC requested
+   (specifically to include the Resource-Priority header namespace and
+   priority value).
+
+   Here is the first figure with the 4 UAs and a meshed routed
+   infrastructure between each.  For simplicity of this explanation,
+   this appendix will only discuss the reservations from Alice to Bob
+   (one direction) and from Carol to Dave (one direction).  An
+   interactive voice service will require two one-way reservations that
+   end in each UA.  This gives the appearance of a two-way reservation,
+   when indeed it is not.
+
+           Alice -----R1----R2----R3----R4------ Bob
+                      | \  /  \  /  \  / |
+                      |  \/    \/    \/  |
+                      |  /\    /\    /\  |
+                      | /  \  /  \  /  \ |
+           Carol -----R5----R6----R7----R8------ Dave
+
+            Figure 5: Complex Routing and Reservation Topology
+
+   The PATH message from Alice to Bob (establishing the route for the
+   RESV message) will be through routers:
+
+      Alice -> R1 -> R2 -> R3 -> R4 -> Bob
+
+   The RESV message (and therefore the reservation of resources) from
+   Bob to Alice will be through routers:
+
+      Bob -> R4 -> R3 -> R2 -> R1 -> Alice
+
+   The PATH message from Carol to Dave (establishing the route for the
+   RESV message) will be through routers:
+
+      Carol -> R5 -> R2 -> R3 -> R8 -> Dave
+
+   The RESV message (and therefore the reservation of resources) from
+   Dave to Carol will be through routers:
+
+      Dave -> R8 -> R3 -> R2 -> R5 -> Carol
+
+   The reservations from Alice to Bob traverse a common router link:
+   between R3 and R2 and thus a common interface at R2.  Here is where
+   there will be congestion in this example, on the link between R2 and
+
+
+
+Baker & Polk                 Informational                     [Page 30]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   R3.  Since the flow of data (in this case voice media packets)
+   travels the direction of the PATH message, and RSVP establishes
+   reservation of resources at the egress interface of a router, the
+   interface in Figure 6 shows that Int7 will be what first knows about
+   a congestion condition.
+
+             Alice                               Bob
+                \                                /
+                 \                              /
+                  +--------+          +--------+
+                  |        |          |        |
+                  |   R2   |          |   R3   |
+                  |       Int7-------Int5      |
+                  |        |          |        |
+                  +--------+          +--------+
+                 /                              \
+                /                                \
+            Carol                                Dave
+
+                  Figure 6: Reduced Reservation Topology
+
+   Figure 6 illustrates how the messaging between the UAs and the RSVP
+   messages between the relevant routers can be shown to understand the
+   binding that was established in [RFC3312] (more suitably titled "SIP
+   Preconditions for QoS" from this document's point of view).
+
+   We will assume all devices have powered up and received whatever
+   registration or remote policy downloads were necessary for proper
+   operation.  The routing protocol of choice has performed its routing
+   table update throughout this part of the network.  Now we are left to
+   focus only on end-to-end communications and how that affects the
+   infrastructure between endpoints.
+
+   The next diagram (Figure 7) (nearly identical to Figure 1 from
+   [RFC3312]) shows the minimum SIP messaging (at layer 7) between Alice
+   and Bob for a good-quality voice call.  The SIP messages are numbered
+   to identify special qualities of each.  During the SIP signaling,
+   RSVP will be initiated.  That messaging will also be discussed below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 31]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+      UA Alice                                      UA Bob
+          |                                            |
+          |                                            |
+          |-------------(1) INVITE SDP1--------------->|
+          |                                            |   Note 1
+          |<------(2) 183 Session Progress SDP2--------|     |
+       ***|********************************************|***<-+
+       *  |----------------(3) PRACK------------------>|  *
+       *  |                                            |  * Where
+       *  |<-----------(4) 200 OK (PRACK)--------------|  * RSVP
+       *  |                                            |  * is
+       *  |                                            |  * signaled
+       ***|********************************************|***
+          |-------------(5) UPDATE SDP3--------------->|
+          |                                            |
+          |<--------(6) 200 OK (UPDATE) SDP4-----------|
+          |                                            |
+          |<-------------(7) 180 Ringing---------------|
+          |                                            |
+          |-----------------(8) PRACK----------------->|
+          |                                            |
+          |<------------(9) 200 OK (PRACK)-------------|
+          |                                            |
+          |                                            |
+          |<-----------(10) 200 OK (INVITE)------------|
+          |                                            |
+          |------------------(11) ACK----------------->|
+          |                                            |
+          |         RTP (within the reservation)       |
+          |<==========================================>|
+          |                                            |
+
+        Figure 7: SIP Reservation Establishment Using Preconditions
+
+   The session initiation starts with Alice wanting to communicate with
+   Bob.  Alice decides on an IEPS precedence level for their call (the
+   default is the "routine" level, which is for normal everyday calls,
+   but a priority level has to be chosen for each call).  Alice puts
+   into her UA Bob's address and precedence level and (effectively) hits
+   the send button.  This is reflected in SIP with an INVITE Method
+   Request message [M1].  Below is what SIP folks call a well-formed SIP
+   message (meaning it has all the headers that are mandatory to
+   function properly).  We will pick on the US Marine Corps (USMC) for
+   the addressing of this message exchange.
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 32]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+      [M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
+      INVITE sip:bob@usmc.example.mil SIP/2.0
+      Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
+        ;branch=z9hG4bK74bf9
+      Max-Forwards: 70
+      From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
+      To: Bob <sip:bob@usmc.example.mil>
+      Call-ID: 3848276298220188511@pc33.usmc.example.mil
+      CSeq: 31862 INVITE
+      Require: 100rel, preconditions, resource-priority
+      Resource-Priority: dsn.routine
+      Contact: <sip:alice@usmc.example.mil>
+      Content-Type: application/sdp
+      Content-Length: 191
+
+      v=0
+      o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
+      c=IN IP4 10.1.3.33
+      t=0 0
+      m=audio 49172 RTP/AVP 0 4 8
+      a=rtpmap:0 PCMU/8000
+      a=curr:qos e2e none
+      a=des:qos mandatory e2e sendrecv
+
+   From the INVITE above, Alice is inviting Bob to a session.  The upper
+   half of the lines (above the line "v=0") is SIP headers and header
+   values, and the lower half is Session Description Protocol (SDP)
+   lines.  SIP headers (after the first line, called the Status line)
+   are not mandated in any particular order, with one exception: the Via
+   header.  It is a SIP hop (through a SIP Proxy) route path that has a
+   new Via header line added by each SIP element this message traverses
+   towards the destination UA.  This is similar in function to an RSVP
+   PATH message (building a reverse path back to the originator of the
+   message).  At any point in the message's path, a SIP element knows
+   the path to the originator of the message.  There will be no SIP
+   Proxies in this example, because for Preconditions, Proxies only make
+   more messages that look identical (with the exception of the Via and
+   Max-Forwards headers), and it is not worth the space here to
+   replicate what has been done in SIP RFCs already.
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 33]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   SIP headers that are used for Preconditions are as follows:
+
+   o  Require header, which contains 3 option tags: "100rel" mandates a
+      reliable provisional response message to the conditions requesting
+      in this INVITE (knowing they are special), "preconditions"
+      mandates that preconditions are attempted, and "resource-priority"
+      mandates support for the Resource-Priority header.  Each of these
+      option tags can be explicitly identified in a message failure
+      indication from the called UA to tell the calling UA exactly what
+      was not supported.
+
+      Provided that this INVITE message is received as acceptable, this
+      will result in the 183 "Session Progress" message from Bob's UA, a
+      reliable confirmation that preconditions are required for this
+      call.
+
+   o  Resource-Priority header, which denotes the domain namespace and
+      precedence level of the call on an end-to-end basis.
+
+   This completes SIP's functions in session initiation.  Preconditions
+   are requested, required, and signaled for in the SDP portion of the
+   message.  SDP is carried in what's called a SIP message body (much
+   like the text in an email message is carried).  SDP has special
+   properties (see [RFC2327] for more on SDP, or the MMUSIC WG for
+   ongoing efforts regarding SDP).  SDP lines are in a specific order
+   for parsing by end systems.  Dialog-generating (or call-generating)
+   SDP message bodies all must have an "m=" line (or media description
+   line).  Following the "m=" line are zero or more "a=" lines (or
+   Attribute lines).  The "m=" line in Alice's INVITE calls for a voice
+   session (this is where video is identified also) using one of 3
+   different codecs that Alice supports (0 = G.711, 4 = G.723, and 18 =
+   G.729) that Bob gets to choose from for this session.  Bob can choose
+   any of the 3.  The first a=rtpmap line is specific to the type of
+   codec these 3 are (PCMU).  The next two "a=" lines are the only
+   identifiers that RSVP is to be used for this call.  The second "a="
+   line:
+
+      a=curr:qos e2e none
+
+   identifies the "current" status of qos at Alice's UA.  Note:
+   everything in SDP is with respect to the sender of the SDP message
+   body (Alice will never tell Bob how his SDP is; she will only tell
+   Bob about her SDP).
+
+      "e2e" means that capacity assurance is required from Alice's UA to
+      Bob's UA; thus, a lack of available capacity assurance in either
+      direction will fail the call attempt.
+
+
+
+
+Baker & Polk                 Informational                     [Page 34]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+      "none" means there is no reservation at Alice's UA (to Bob) at
+      this time.
+
+   The final "a=" line (a=des) identifies the "desired" level of qos:
+
+      a=des:qos mandatory e2e sendrecv
+
+      "mandatory" means this request for qos MUST be successful, or the
+      call fails.
+
+      "e2e" means RSVP is required from Alice's UA to Bob's UA.
+
+      "sendrecv" means the reservation is in both directions.
+
+   As discussed, RSVP does not reserve bandwidth in both directions, and
+   it is up to the endpoints to have 2 one-way reservations if that
+   particular application (here, voice) requires it.  Voice between
+   Alice and Bob requires 2 one-way reservations.  The UAs will be the
+   focal points for both reservations in both directions.
+
+   Message 2 is the 183 "Session Progress" message sent by Bob to Alice,
+   which indicates to Alice that Bob understands that preconditions are
+   required for this call.
+
+      [M2 - 183 "Session Progress"]
+      SIP/2.0 183 Session Progress
+      Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
+        ;branch=z9hG4bK74bf9 ;received=10.1.3.33
+      From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
+      To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
+      Call-ID: 3848276298220188511@pc33.usmc.example.mil
+      CSeq: 31862 INVITE
+      RSeq: 813520
+      Resource-Priority: dsn.routine
+      Contact: <sip:bob@usmc.example.mil>
+      Content-Type: application/sdp
+      Content-Length: 210
+
+      v=0
+      o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
+      c=IN IP4 10.100.50.51
+      t=0 0
+      m=audio 3456 RTP/AVP 0
+      a=rtpmap:0 PCMU/8000
+      a=curr:qos e2e none
+      a=des:qos mandatory e2e sendrecv
+      a=conf:qos e2e recv
+
+
+
+
+Baker & Polk                 Informational                     [Page 35]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   The only interesting header in the SIP portion of this message is the
+   RSeq header, which is the "Reliable Sequence" header.  The value is
+   incremented for every Reliable message that's sent in this call setup
+   (to make sure none are lost or to ignore duplicates).
+
+   Bob's SDP indicates several "a=" line statuses and picks a codec for
+   the call.  The codec picked is in the m=audio line (the "0" at the
+   end of this line means G.711 will be the codec).
+
+   The a=curr line gives Alice Bob's status with regard to RSVP
+   (currently "none").
+
+   The a=des line also states the desire for mandatory qos e2e in both
+   directions.
+
+   The a=conf line is new.  This line means Bob wants confirmation that
+   Alice has 2 one-way reservations before Bob's UA proceeds with the
+   SIP session setup.
+
+   This is where "Note-1" applies in Figure 7.  At the point that Bob's
+   UA transmits this 183 message, Bob's UA (the one that picked the
+   codec, so it knows the amount of bandwidth to reserve) transmits an
+   RSVP PATH message to Alice's UA.  This PATH message will take the
+   route previously discussed in Figure 5:
+
+      Bob -> R4 -> R3 -> R2 -> R1 -> Alice
+
+   This is the path of the PATH message, and the reverse will be the
+   path of the reservation setup RESV message, or:
+
+      Alice -> R1 -> R2 -> R3 -> R4 -> Bob
+
+   Immediately after Alice transmits the RESV message towards Bob, Alice
+   sends her own PATH message to initiate the other one-way reservation.
+   Bob, receiving that PATH message, will reply with a RESV.
+
+   All this is independent of SIP.  However, during this time of
+   reservation establishment, a Provisional Acknowledgement (PRACK) [M3]
+   is sent from Alice to Bob to confirm the request for confirmation of
+   2 one-way reservations at Alice's UA.  This message is acknowledged
+   with a normal 200 OK message [M4].  This is shown in Figure 7.
+
+   As soon as the RSVP is successfully completed at Alice's UA (knowing
+   that it was the last in the two-way cycle or reservation
+   establishment), at the SIP layer an UPDATE message [M5] is sent to
+   Bob's UA to inform his UA that the current status of RSVP (or qos) is
+   "e2e" and "sendrecv".
+
+
+
+
+Baker & Polk                 Informational                     [Page 36]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+      [M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
+      UPDATE sip:bob@usmc.example.mil SIP/2.0
+      Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
+        ;branch=z9hG4bK74bfa
+      From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
+      To: Bob <sip:bob@usmc.example.mil>
+      Call-ID: 3848276298220188511@pc33.usmc.example.mil
+      Resource-Priority: dsn.routine
+      Contact: <sip:alice@usmc.example.mil>
+      CSeq: 10197 UPDATE
+      Content-Type: application/sdp
+      Content-Length: 191
+
+      v=0
+      o=alice 2890844528 2890844528 IN IP4 usmc.example.mil
+      c=IN IP4 10.1.3.33
+      t=0 0
+      m=audio 49172 RTP/AVP 0
+      a=rtpmap:0 PCMU/8000
+      a=curr:qos e2e send
+      a=des:qos mandatory e2e sendrecv
+
+   This is shown by the matching table that can be built from the a=curr
+   line and a=des line.  If the two lines match, then no further
+   signaling needs take place with regard to "qos".  [M6] is the 200 OK
+   acknowledgement of this synchronization between the two UAs.
+
+      [M6 - 200 OK to the UPDATE from Bob indicating synchronization]
+      SIP/2.0 200 OK sip:bob@usmc.example.mil
+      Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
+        ;branch=z9hG4bK74bfa
+      From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
+      To: Bob <sip:bob@usmc.example.mil>
+      Call-ID: 3848276298220188511@pc33.usmc.example.mil
+      Resource-Priority: dsn.routine
+      Contact: < sip:alice@usmc.example.mil >
+      CSeq: 10197 UPDATE
+      Content-Type: application/sdp
+      Content-Length: 195
+
+      v=0
+      o=alice 2890844529 2890844529 IN IP4 usmc.example.mil
+      c=IN IP4 10.1.3.33
+      t=0 0
+      m=audio 49172 RTP/AVP 0
+      a=rtpmap:0 PCMU/8000
+      a=curr:qos e2e sendrecv
+      a=des:qos mandatory e2e sendrecv
+
+
+
+Baker & Polk                 Informational                     [Page 37]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   At this point, the reservation is operational and both UAs know it.
+   Bob's UA now rings, telling Bob the user that Alice is calling him.
+   ([M7] is the SIP indication to Alice that this is taking place).
+   Nothing up until now has involved Bob the user.  Bob picks up the
+   phone (generating [M10], from which Alice's UA responds with the
+   final ACK), and RTP is now operating within the reservations between
+   the two UAs.
+
+   Now we get to Carol calling Dave.  Figure 6 shows a common router
+   interface for the reservation between Alice to Bob, and one that will
+   also be the route for one of the reservations between Carol to Dave.
+   This interface will experience congestion in our example.
+
+   Carol is now calling Dave at a Resource-Priority level of
+   "Immediate", which is higher in priority than Alice to Bob's
+   "routine".  In this continuing example, Router 2's Interface-7 is
+   congested and cannot accept any more RSVP traffic.  Perhaps the
+   offered load is at interface capacity.  Perhaps Interface-7 is
+   configured with a fixed amount of bandwidth it can allocate for RSVP
+   traffic, and it has reached its maximum without one of the
+   reservations going away through normal termination or forced
+   termination (preemption).
+
+   Interface-7 is not so full of offered load that it cannot transmit
+   signaling packets, such as Carol's SIP messaging to set up a call to
+   Dave.  This should be by design (that not all RSVP traffic can starve
+   an interface from signaling packets).  Carol sends her own INVITE
+   with the following important characteristics:
+
+   [M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
+
+   This packet does *not* affect the reservations between Alice and Bob
+   (SIP and RSVP are at different layers, and all routers are passing
+   signaling packets without problems).  Dave sends his M2:
+
+   [M2 - 183 "Session Progress"]
+
+   with the SDP chart of:
+
+      a=curr:qos e2e none
+
+      a=des:qos mandatory e2e sendrecv
+
+      a=conf:qos e2e recv
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 38]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   indicating he understands RSVP reservations are required e2e for this
+   call to be considered successful.  Dave sends his PATH message.  The
+   PATH message does *not* affect Alice's reservation; it merely
+   establishes a path for the RESV reservation setup message to take.
+
+   To keep this example simple, the PATH message from Dave to Carol took
+   this route (which we make different from the route in the reverse
+   direction):
+
+      Dave -> R8 -> R7 -> R6 -> R5 -> Carol
+
+   causing the reservation to be this route:
+
+      Carol -> R5 -> R6 -> R7 -> R8 -> Dave
+
+   The Carol-to-Dave reservation above will not traverse any of the same
+   routers as the Alice-to-Bob reservation.  When Carol transmits her
+   RESV message towards Dave, she immediately transmits her PATH message
+   to set up the complementary reservation.
+
+   The PATH message from Carol to Dave be through routers:
+
+      Carol -> R5 -> R2 -> R3 -> R8 -> Dave
+
+   Thus, the RESV message will be through routers:
+
+      Dave -> R8 -> R3 -> R2 -> R5 -> Carol
+
+   This RESV message will traverse the same routers, R3 and R2, as the
+   Alice-to-Bob reservation.  This RESV message, when received at
+   Interface-7 of R2, will create a congestion situation such that R2
+   will need to make a decision on whether:
+
+   o  to keep the Alice-to-Bob reservation and error the new RESV from
+      Dave, or
+
+   o  to error the reservation from Alice to Bob in order to make room
+      for the Carol-to-Dave reservation.
+
+   Alice's reservation was set up in SIP at the "routine" precedence
+   level.  This will equate to a comparable RSVP priority number (RSVP
+   has 65,535 priority values, or 2*32 bits per [RFC3181]).  Dave's RESV
+   equates to a precedence value of "immediate", which is a higher
+   priority.  Thus, R2 will preempt the reservation from Alice to Bob
+   and allow the reservation request from Dave to Carol.  The proper
+   RSVP error is the ResvErr that indicates preemption.  This message
+   travels downstream towards the originator of the RESV message (Bob).
+   This clears the reservation in all routers downstream of R2 (meaning
+
+
+
+Baker & Polk                 Informational                     [Page 39]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+   R3 and R4).  Once Bob receives the ResvErr message indicating
+   preemption has occurred on this reservation, Bob's UA transmits a SIP
+   preemption indication back towards Alice's UA.  This accomplishes two
+   things: first, it informs all SIP Servers that were in the session
+   setup path that wanted to remain "dialog stateful" per [RFC3261], and
+   second, it informs Alice's UA that this was a purposeful termination,
+   and to play a preemption tone.  The proper indication in SIP of this
+   termination due to preemption is a BYE Method message that includes a
+   Reason Header indicating why this occurred (in this case, "Reserved
+   Resources Preempted").  Here is the message from Bob to Alice that
+   terminates the call in SIP.
+
+      BYE sip:alice@usmc.example.mil SIP/2.0
+      Via: SIP/2.0/TCP swp34.usmc.example.mil
+        ;branch=z9hG4bK776asegma
+      To: Alice <sip:alice@usmc.example.mil>
+      From: Bob <sip:bob@usmc.example.mil>;tag=192820774
+      Reason: preemption ;cause=2 ;text=reserved resourced preempted
+      Call-ID: 3848276298220188511@pc33.usmc.example.mil
+      CSeq: 6187 BYE
+      Contact: <sip:bob@usmc.example.mil>
+
+   When Alice's UA receives this message, her UA terminates the call,
+   sends a 200 OK to Bob to confirm reception of the BYE message, and
+   plays a preemption tone to Alice the user.
+
+   The RESV message from Dave successfully traverses R2, and Carol's UA
+   receives it.  Just as with the Alice-to-Bob call setup, Carol sends
+   an UPDATE message to Dave, confirming she has QoS "e2e" in "sendrecv"
+   directions.  Bob acknowledges this with a 200 OK that gives his
+   current status (QoS "e2e" and "sendrecv"), and the call setup in SIP
+   continues to completion.
+
+   In summary, Alice set up a call to Bob with RSVP at a priority level
+   of Routine.  When Carol called Dave at a high priority, their call
+   would have preempted any lower priority calls if there were a
+   contention for resources.  In this case, it occurred and affected the
+   call between Alice and Bob.  A router at this congestion point
+   preempted Alice's call to Bob in order to place the higher-priority
+   call between Carol and Dave.  Alice and Bob were both informed of the
+   preemption event.  Both Alice and Bob's UAs played preemption
+   indications.  What was not mentioned in this appendix was that this
+   document RECOMMENDS that router R2 (in this example) generate a
+   syslog message to the domain administrator to properly manage and
+   track such events within this domain.  This will ensure that the
+   domain administrators have recorded knowledge of where such events
+   occur, and what the conditions were that caused them.
+
+
+
+
+Baker & Polk                 Informational                     [Page 40]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+Authors' Addresses
+
+   Fred Baker
+   Cisco Systems
+   1121 Via Del Rey
+   Santa Barbara, California  93117
+   USA
+
+   Phone: +1-408-526-4257
+   Fax:   +1-413-473-2403
+   EMail: fred@cisco.com
+
+
+   James Polk
+   Cisco Systems
+   2200 East President George Bush Turnpike
+   Richardson, Texas  75082
+   USA
+
+   Phone: +1-817-271-3552
+   EMail: jmpolk@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 41]
+
+RFC 4542                  ETS in an IP Network                  May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Baker & Polk                 Informational                     [Page 42]
+