. /----------/ .. ../ 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.
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.
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
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.
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,
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
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.
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.
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