One document matched: draft-baker-tsvwg-mlpp-that-works-00.txt
Network Working Group F. Baker
Internet-Draft Cisco Systems
Expires: May 31, 2004 December 2003
Implementing MLPP in the Internet Protocol Suite
draft-baker-tsvwg-mlpp-that-works-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 31, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Defense Information Systems Agency of the United States
Department of Defense, with is contractors, has proposed a service
architecture for military (NATO and related agencies) telephone
systems. This is called the Assured Service, and is defined in two
documents: "Architecture for Assured Service Capabilities in Voice
over IP" and "Requirements for Assured Service Capabilities in Voice
over IP". Responding to these are three documents: "Reason Header
Field for the Session Initiation Protocol", "Extending the Session
Initiation Protocol Reason Header to account for Preemption Events",
"Communications Resource Priority for the Session Initiation
Protocol".
What remains to this specification is to provide a Call Admission
Baker Expires May 31, 2004 [Page 1]
Internet-Draft MLPP for VoIP December 2003
Control procedure and a Per Hop Behavior for the data which meet the
needs of this architecture.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Multi-Level Preemption and Precedence . . . . . . . . . . . 3
1.2 Assumptions about the Network . . . . . . . . . . . . . . . 5
1.3 Assumptions about application behavior . . . . . . . . . . . 5
1.4 Desired Characteristics in an Internet Environment . . . . . 6
1.5 The use of bandwidth as a solution for QoS . . . . . . . . . 7
2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . 9
2.1 Call admission/preemption procedure . . . . . . . . . . . . 10
2.2 Voice handling characteristics . . . . . . . . . . . . . . . 10
2.3 Bandwidth admission procedure . . . . . . . . . . . . . . . 11
2.3.1 Alternatives that fall short . . . . . . . . . . . . . . . . 11
2.3.2 Recommended procedure: explicit call admission - RSVP
Admission using Policy . . . . . . . . . . . . . . . . . . . 12
2.4 Authentication and authorization of calls placed . . . . . . 14
2.5 Defined User Interface . . . . . . . . . . . . . . . . . . . 14
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . 22
Baker Expires May 31, 2004 [Page 2]
Internet-Draft MLPP for VoIP December 2003
1. Overview
The Defense Information Systems Agency of the United States
Department of Defense, with is contractors, has proposed a service
architecture for military (NATO and related agencies) telephone
systems. This is called the Assured Service, and is defined in two
documents: "Architecture for Assured Service Capabilities in Voice
over IP" [25] and "Requirements for Assured Service Capabilities in
Voice over IP" [26]. Responding to these are three documents: "Reason
Header Field for the Session Initiation Protocol" [22], "Extending
the Session Initiation Protocol Reason Header to account for
Preemption Events" [23], "Communications Resource Priority for the
Session Initiation Protocol" [24].
What remains to this specification is to provide a Call Admission
Control procedure and a Per Hop Behavior for the data which meet the
needs of this architecture.
1.1 Multi-Level Preemption and Precedence
Before doing so, however, let us discuss the problem that MLEF is
intended to solve and the architecture of the system. 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 [27][28][29], 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 priority communication at the expense of
lower priority communications. These priorities, 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.
Flash Override: used by Commander in Chief, Secretary of Defense, and
Joint Chiefs of Staff, Commanders of combatant commands when
declaring the existence of a state of war.
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
Baker Expires May 31, 2004 [Page 3]
Internet-Draft MLPP for VoIP December 2003
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,
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.
The rule, in MLPP, is that more important calls override less
important calls. 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 there is end to end capacity to place a call, any call may
be placed at any time. However, when any trunk (in the circuit world)
or interface (in an IP world) reaches utilization capacity, a choice
must be made as to which call continues. The system will seize the
trunks 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.
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) is a good example of this
situation. This is occurs when the called handset is in use (the
general calls the colonel, who at the time is talking with the
captain), or may be used to clear a circuit (all circuits are busy,
but a lower precedence call may be cleared to create room for the
higher precedence call). When preemption happens, each preempted
speaker will hear an audible tone indicating they have just been
preempted. In this example, the colonel and the captain will each
hear a audible tone indicating s/he must hang up; upon doing so, the
colonel will receive the incoming call from the general.
Baker Expires May 31, 2004 [Page 4]
Internet-Draft MLPP for VoIP December 2003
1.2 Assumptions about the Network
IP networks generally fall into two categories: those with
constrained bandwidth, and those that are massively overprovisioned.
In a network wherein 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 ATM, MPLS, and GMPLS can be used to explicitly
place routes, and so improve the odds a bit.
Between those networks, in places commonly called "inter-campus
links", "access links" or "access networks", for various reasons
including technology 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, and those
NOCs are in turn interconnected via the DISA backbone. A typical ship
may have between two and six radio systems aboard, and it is unusual
for any of them to exceed 64 KBPS due to a combination of encryption
and allocation constraints. In US Army networks, current radio
technology likewise limits tactical communications to links below 100
KBPS. Future radio capabilities are projected to be on the order of
1-10 MBPS, and certainly less than 45 MBPS.
Over this infrastructure, military communications expect to deploy
voice communication systems (30-80 KBPS per session), 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.3 Assumptions about application behavior
Parekh and Gallager [30][31] published a series of papers 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
o what network elements will do, in terms of the departure
Baker Expires May 31, 2004 [Page 5]
Internet-Draft MLPP for VoIP December 2003
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 do not tune their behavior to that of the
network. 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 RFC 1633 [1], 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 that loss and jitter are nominal. Where that cannot be
accomplished, one must use queuing technology to deterministically
apply bandwidth to accomplish the goal.
1.4 Desired Characteristics in an Internet Environment
The key elements of the MLPP service include the following:
Baker Expires May 31, 2004 [Page 6]
Internet-Draft MLPP for VoIP December 2003
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 which assert any of several levels
of precedence, and in the event that there is need 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 calls
are 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 MLPP service must, by definition,
provide those characteristics.
1.5 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 ten gigabit Ethernet.
Similarly, in optical networking environments, the simplest and
cheapest solution is often to increase the data rate of the optical
Baker Expires May 31, 2004 [Page 7]
Internet-Draft MLPP for VoIP December 2003
path either by selecting a faster optical carrier or deploying an
additional lambda. In places where the bandwidth can be
overprovisioned to a point where loss or queuing delay are
negligible, 10:1 overprovisioning is often the cheapest and surest
solution, and by the way offers a growth path for future
requirements. However, there are places in communication networks
where bandwidth is not free and is therefore not effectively
infinite. It is in these places, and only these places, where the
question of resource management is relevant.
The places where bandwidth constriction takes place is typically
where one pays a significant amount for bandwidth, such as in access
paths, or where available technology limits the options. In military
networks, Type 1 encryption often presents such a barrier, as do
satellite links and various kinds of radio systems.
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. Get over it. However much we might like to, in those
places we are not solving this with bandwidth.
Baker Expires May 31, 2004 [Page 8]
Internet-Draft MLPP for VoIP December 2003
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 that figure, it becomes obvious that 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 switches or circuit multiplexors. 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 a given call use only data paths in the Asia/Pacific
region, data paths provided by a different company, and often
multiple companies.
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?
Baker Expires May 31, 2004 [Page 9]
Internet-Draft MLPP for VoIP December 2003
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 it actually work?
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 specialized policy like call preemption, two capabilities are
necessary from an administrative perspective: "Reason Header Field
for the Session Initiation Protocol" [22] 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. "Communications Resource Priority for the
Session Initiation Protocol" [24] provides a way to communicate
policy-related information regarding the precedence of the call. This
informs both the use of 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.
2.2 Voice handling characteristics
The Quality of Service architecture used in the data path is that
ofDifferentiated Services [6]. Differentiated Services uses a flag in
the IP header called the DSCP [5] to identify a data stream, and then
applies a procedure called a Per Hop Behavior, or PHB, to it.
In the data path, the Expedited Forwarding [19][20] PHB describes the
fundamental needs of voice and video traffic. This PHB entails
ensuring that sufficient bandwidth is dedicated to real-time traffic
to ensure minimal variation in delay and a minimal loss rate, as
codecs are hampered by excessive loss[32][33][34][35][36][37]. In
parts of the network where bandwidth is heavily overprovisioned,
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
Baker Expires May 31, 2004 [Page 10]
Internet-Draft MLPP for VoIP December 2003
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.
For policy reasons, DISA would like to mark traffic with various code
points marked with code points appropriate to the service level 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 they get the
packets into the right service class. The question is primarily one
of appropriate policing of traffic, especially around route changes.
SRTCM [7] or TRTCM [8], in their color-aware modes, can be trivially
extended to an arbitrary number of colors given that one knows the
bandwidth to be admitted into each service class.
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 the 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.
2.3.1 Alternatives that fall short
There have been many proposals for measurement-based admission.
Fundamentally, these work on the same principle as Keshav's
packet-pair algorithm: if a pair of packets or a data stream are
added to a stable network data flow, and the result is acceptable,
then adding the voice or video data stream is acceptable, and the end
system can presume the data flow to have been accepted by the
network. While the case can be made in theory for fixed volume data
streams, variable data streams such as G.711/G.729 voice with Voice
Activity Detection (VAD), the Internet Limited Bandwidth Codec [21],
or MPEG-4 video do not work well. These have the property that they
can behave benignly for a while, and then change their behavior
dramatically. Voice with VAD, for example, may send no data at all
for an extended period of time, or only a modicum of comfort noise,
and then suddenly jump to life. MPEG-4 will send about 80 KBPS while
the camera is pointed at the wall, and jump to 800 KBPS when the
camera is pointed at a moving field such as a waving hand. ILBC will
Baker Expires May 31, 2004 [Page 11]
Internet-Draft MLPP for VoIP December 2003
send at a relatively low bit rate under normal circumstances, but
when loss sets in will increase its offered load by as much as 50%.
The effect of these is all too predictable with end system
measurement-based admission: many data flows will be admitted during
periods of lower activity, only to be trashed as a class when
activity increases.
The most sensible end system behavior in a situation where loss sets
in, under end system measurement-based admission, is opt-out
admission - the system detecting that it is being adversely affected
drops its call. In such a case, however, end systems can be expected
to detect the condition - if they detect it at all - in random order,
and therefore apply their admission policy randomly, with little real
policy control. Many may suddenly detect the condition and drop their
calls, resulting in more calls than necessary being lost, and any
affected call may be dropped, not just the new ones being added to
the mix. One could argue, academically, that a sufficiently complex
and randomized opt-out policy could be designed to minimize the
issues in this, and maybe one would be right. The fine tuning that
would be involved, however, would be extensive, and would not be
easily done under combat conditions.
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 SIP proxy near a
single ingress/egress to the network. This is able to impose an upper
bound on the total number of call sin 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 requires a single ingress/egress - a single
point of failure. 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.
2.3.2 Recommended procedure: explicit call admission - RSVP Admission
using Policy
The "Integrated Services in the Internet Architecture: an Overview"
[1] provides for signalled admission. This is currently implemented
using the "Resource ReSerVation Protocol" [2][4](RSVP). As originally
written, RSVP had scaling limitations due to its data plane behavior.
This has, in time, largely been corrected. 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
Baker Expires May 31, 2004 [Page 12]
Internet-Draft MLPP for VoIP December 2003
figure 1, these would normally be the links that cross network
boundaries, and may also include any type 1 encrypted interface, as
these are generally limited in bandwidth by the encryption.
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 and of networks that carry traffic from an encryptor to a
decryptor, and also of VPNs - applicable technologies include those
documents in "RSVP Extensions for IPSEC Data Flows" [3], "RSVP
Operation Over IP Tunnels" [9], and "Differentiated Services and
Tunnels" [13]. Other networks may simply choose to aggregate the
reservations across themselves as described in "Aggregation of RSVP
for IPv4 and IPv6 Reservations" [16].
In the PATH message, the DCLASS object described in "Format of the
RSVP DCLASS Object" [14] is used to indicate the DSCP that will be
used for the data in the stream. This is reflected back in the RESV
message. This permits both bandwidth admission within a class and the
building up of the various rates or token buckets for the extended
color-aware SRTCM or TRTCM algorithm.
Policy is carried and applied as described in "A Framework for
Policy-based Admission Control" [12]. The "RSVP Extensions for Policy
Control" [11], which include the "Signaled Preemption Priority Policy
Element" [17] and the "Identity Representation for RSVP" [18], allow
for policies which 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 to
disconnect its call, with a reason code of "bandwidth preemption".
One will ask the value of the multiple DSCPs. They are, in fact, of
limited to no value in normal operation, as all vice and video
traffic should have been admitted, and therefore capacity will have
been assigned to them. The behavior of this service will be
indistinguishable from the EF PHB regardless of traffic marking.
However, around route changes - common in manet networks - IP data
streams will be shifted around before RSVP admission gets to verify
the utility of the new path. While this is normally at most a few
seconds, military policy attempts to preserve call quality for more
important data flows first. An extended SRTCM or TRTCM, in the
color-aware mode, will accomplish this, reducing call quality from
lower precedence data flows, while RSVP decides to either admit them
Baker Expires May 31, 2004 [Page 13]
Internet-Draft MLPP for VoIP December 2003
(changing affected xxTCM quanta) or preempt them.
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; it is the capabilities assigned to an
authenticated user that may be considered to have been authorized for
use in the network. For bandwidth admission, this will require the
utilization of "RSVP Cryptographic Authentication" [10][15]. 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 MLPP PSTN. This, of course, depends
on positive signals, not unreliable measures based on changing
measurements.
Baker Expires May 31, 2004 [Page 14]
Internet-Draft MLPP for VoIP December 2003
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Baker Expires May 31, 2004 [Page 15]
Internet-Draft MLPP for VoIP December 2003
4. 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.
Baker Expires May 31, 2004 [Page 16]
Internet-Draft MLPP for VoIP December 2003
5. Acknowledgements
This document was developed with the knowledge and input of many
people, far too numerous to be mentioned by name. Key contributors of
thoughts include, however, Francois Le Faucheur, Haluk Keskiner,
James Polk, Pete Babendreier, Rohan Mahy, Scott Bradner, Scott
Morrison, and Subha Dhesikan.
Baker Expires May 31, 2004 [Page 17]
Internet-Draft MLPP for VoIP December 2003
References
[1] Braden, B., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[3] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC 2207, September 1997.
[4] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP)
-- Version 1 Message Processing Rules", RFC 2209, September
1997.
[5] 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.
[6] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[7] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker",
RFC 2697, September 1999.
[8] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker",
RFC 2698, September 1999.
[9] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
[10] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[11] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[12] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[13] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
Baker Expires May 31, 2004 [Page 18]
Internet-Draft MLPP for VoIP December 2003
[15] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication --
Updated Message Type Value", RFC 3097, April 2001.
[16] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[17] Herzog, S., "Signaled Preemption Priority Policy Element", RFC
3181, October 2001.
[18] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC
3182, October 2001.
[19] 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.
[20] 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.
[21] Andersen, S., "Internet Low Bit Rate Codec",
draft-ietf-avt-ilbc-codec-03 (work in progress), October 2003.
[22] Oran, D., Schulzrinne, H. and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol",
draft-ietf-sip-reason-01 (work in progress), May 2002.
[23] Polk, J., "Extending the Session Initiation Protocol Reason
Header to account for Preemption Events",
draft-polk-sipping-reason-header-for-preemption-00 (work in
progress), October 2003.
[24] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)",
draft-ietf-sip-resource-priority-01 (work in progress), July
2003.
[25] Pierce, M. and D. Choi, "Architecture for Assured Service
Capabilities in Voice over IP",
draft-pierce-ieprep-assured-service-arch-01 (work in progress),
June 2003.
[26] Pierce, M. and D. Choi, "Requirements for Assured Service
Baker Expires May 31, 2004 [Page 19]
Internet-Draft MLPP for VoIP December 2003
Capabilities in Voice over IP",
draft-pierce-ieprep-assured-service-req-01 (work in progress),
June 2003.
[27] International Telecommunications Union, "Multilevel Precedence
and Preemption Service (MLPP)", ITU-T Recommendation I.255.3,
1990.
[28] American National Standards Institute, "Telecommunications -
Integrated Services Digital Network (ISDN) - Multi-Level
Precedence and Preemption (MLPP) Service Capability", ANSI
T1.619-1992 (R1999), 1992.
[29] American National Standards Institute, "MLPP Service Domain
Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990.
[30] 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.
[31] 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.
[32] Viola Networks, "Netally VoIP Evaluator", January 2003, <http:/
/www.sygnusdata.co.uk/white_papers/viola/
netally_voip_sample_report_preliminary.pdf>.
[33] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July 1999,
<http://docbox.etsi.org/tiphon/tiphon/archives/1999/
05-9907-Amsterdam/14TD113.pdf>.
[34] Nortel Networks, "Packet Loss and Packet Loss Concealment",
2000, <http://www.nortelnetworks.com/products/01/succession/es/
collateral/tb_pktloss.pdf>.
[35] Clark, A., "Modeling the Effects of Burt Packet Loss and
recency on Subjective Voice Quality", 2000, <http://
www.telchemy.com/references/tech_papers/iptel2001.pdf>.
[36] Cisco Systems, "Understanding Codecs: Complexity, Hardware
Support, MOS, and Negotiation", 2003, <http://www.cisco.com/en/
US/tech/tk652/tk701/
technologies_tech_note09186a00800b6710.shtml#mos>.
[37] Chen, M. and M. Murthi, "On The Performance Of ILBC Over
Networks With Bursty Packet Loss", July 2003.
Baker Expires May 31, 2004 [Page 20]
Internet-Draft MLPP for VoIP December 2003
Author's Address
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
Baker Expires May 31, 2004 [Page 21]
Internet-Draft MLPP for VoIP December 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Baker Expires May 31, 2004 [Page 22]
Internet-Draft MLPP for VoIP December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker Expires May 31, 2004 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 14:51:44 |